draft-ietf-6man-rfc4941bis-09.txt   draft-ietf-6man-rfc4941bis-10.txt 
IPv6 Maintenance (6man) Working Group F. Gont IPv6 Maintenance (6man) Working Group F. Gont
Internet-Draft SI6 Networks / UTN-FRH Internet-Draft SI6 Networks / UTN-FRH
Obsoletes: rfc4941 (if approved) S. Krishnan Obsoletes: rfc4941 (if approved) S. Krishnan
Intended status: Standards Track Ericsson Research Intended status: Standards Track Kaloom
Expires: October 8, 2020 T. Narten Expires: February 27, 2021 T. Narten
IBM Corporation IBM Corporation
R. Draves R. Draves
Microsoft Research Microsoft Research
April 6, 2020 August 26, 2020
Temporary Address Extensions for Stateless Address Autoconfiguration in Temporary Address Extensions for Stateless Address Autoconfiguration in
IPv6 IPv6
draft-ietf-6man-rfc4941bis-09 draft-ietf-6man-rfc4941bis-10
Abstract Abstract
This document describes an extension that causes nodes to generate This document describes an extension that causes nodes to generate
global scope addresses with randomized interface identifiers that global scope addresses with randomized interface identifiers that
change over time. Changing global scope addresses over time limits change over time. Changing global scope addresses over time limits
the window of time during which eavesdroppers and other information the window of time during which eavesdroppers and other information
collectors may trivially perform address-based network activity collectors may trivially perform address-based network activity
correlation when the same address is employed for multiple correlation when the same address is employed for multiple
transactions by the same node. Additionally, it reduces the window transactions by the same node. Additionally, it reduces the window
of exposure of a node via an addresses that becomes revealed as a of exposure of a node via an address that becomes revealed as a
result of active communication. This document obsoletes RFC4941. result of active communication. This document obsoletes RFC4941.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 8, 2020. This Internet-Draft will expire on February 27, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 38 skipping to change at page 2, line 38
3. Protocol Description . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Description . . . . . . . . . . . . . . . . . . . . 6
3.1. Design Guidelines . . . . . . . . . . . . . . . . . . . . 6 3.1. Design Guidelines . . . . . . . . . . . . . . . . . . . . 6
3.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Generation of Randomized Interface Identifiers . . . . . 8 3.3. Generation of Randomized Interface Identifiers . . . . . 8
3.3.1. Simple Randomized Interface Identifiers . . . . . . . 8 3.3.1. Simple Randomized Interface Identifiers . . . . . . . 8
3.3.2. Hash-based Generation of Randomized Interface 3.3.2. Hash-based Generation of Randomized Interface
Identifiers . . . . . . . . . . . . . . . . . . . . . 9 Identifiers . . . . . . . . . . . . . . . . . . . . . 9
3.4. Generating Temporary Addresses . . . . . . . . . . . . . 10 3.4. Generating Temporary Addresses . . . . . . . . . . . . . 10
3.5. Expiration of Temporary Addresses . . . . . . . . . . . . 12 3.5. Expiration of Temporary Addresses . . . . . . . . . . . . 12
3.6. Regeneration of Temporary Addresses . . . . . . . . . . . 12 3.6. Regeneration of Temporary Addresses . . . . . . . . . . . 12
3.7. Implementation Considerations . . . . . . . . . . . . . . 13 3.7. Implementation Considerations . . . . . . . . . . . . . . 14
3.8. Defined Constants . . . . . . . . . . . . . . . . . . . . 14 3.8. Defined Constants and Configuration Variables . . . . . . 14
4. Implications of Changing Interface Identifiers . . . . . . . 15 4. Implications of Changing Interface Identifiers . . . . . . . 15
5. Significant Changes from RFC4941 . . . . . . . . . . . . . . 15 5. Significant Changes from RFC4941 . . . . . . . . . . . . . . 16
6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
skipping to change at page 4, line 35 skipping to change at page 4, line 35
Note that an attacker, who is on path, may be able to perform Note that an attacker, who is on path, may be able to perform
significant correlation on unencrypted packets based on significant correlation on unencrypted packets based on
o The payload contents of the packets on the wire o The payload contents of the packets on the wire
o The characteristics of the packets such as packet size and timing o The characteristics of the packets such as packet size and timing
Use of temporary addresses will not prevent such payload-based Use of temporary addresses will not prevent such payload-based
correlation, which can only be addressed by widespread deployment of correlation, which can only be addressed by widespread deployment of
encryption as advocated in [RFC7624]. Nor will it prevent an on-link encryption as discussed in [RFC7624]. Nor will it prevent an on-link
observer (e.g. the node's default router) to track all the node's observer (e.g. the node's default router) to track all the node's
addresses. addresses.
2. Background 2. Background
This section discusses the problem in more detail, and provides This section discusses the problem in more detail, and provides
context for evaluating the significance of the concerns in specific context for evaluating the significance of the concerns in specific
environments and makes comparisons with existing practices. environments and makes comparisons with existing practices.
2.1. Extended Use of the Same Identifier 2.1. Extended Use of the Same Identifier
skipping to change at page 8, line 39 skipping to change at page 8, line 39
2. The Interface Identifier is obtained by taking as many bits from 2. The Interface Identifier is obtained by taking as many bits from
the random number obtained in the previous step as necessary. the random number obtained in the previous step as necessary.
Note: there are no special bits in an Interface Identifier Note: there are no special bits in an Interface Identifier
[RFC7136]. [RFC7136].
We note that [RFC4291] requires that the Interface IDs of all We note that [RFC4291] requires that the Interface IDs of all
unicast addresses (except those that start with the binary unicast addresses (except those that start with the binary
value 000) be 64 bits long. However, the method discussed in value 000) be 64 bits long. However, the method discussed in
this document could be employed for generating Interface IDs this document could be employed for generating Interface IDs
of any arbitrary length, albeit at the expense of reduced of any arbitrary length, albeit at the expense of reduced
entropy (when employing Interface IDs smaller than 64 bits). entropy (when employing Interface IDs smaller than 64 bits)
The privacy implications of the IID length are discussed in and increased likelihood of collision. The privacy
[RFC7421]. implications of the IID length are discussed in [RFC7421].
3. The resulting Interface Identifier SHOULD be compared against the 3. The resulting Interface Identifier MUST be compared against the
reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID] reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID]
and against those Interface Identifiers already employed in an and against those Interface Identifiers already employed in an
address of the same network interface and the same network address of the same network interface and the same network
prefix. In the event that an unacceptable identifier has been prefix. In the event that an unacceptable identifier has been
generated, a new interface identifier should be generated, by generated, a new interface identifier should be generated, by
repeating the algorithm from the first step. repeating the algorithm from the first step.
3.3.2. Hash-based Generation of Randomized Interface Identifiers 3.3.2. Hash-based Generation of Randomized Interface Identifiers
The algorithm in [RFC7217] can be augmented for the generation of The algorithm in [RFC7217] can be augmented for the generation of
skipping to change at page 10, line 32 skipping to change at page 10, line 32
secret_key: secret_key:
A secret key that is not known by the attacker. The secret A secret key that is not known by the attacker. The secret
key SHOULD be of at least 128 bits. It MUST be initialized to key SHOULD be of at least 128 bits. It MUST be initialized to
a pseudo-random number (see [RFC4086] for randomness a pseudo-random number (see [RFC4086] for randomness
requirements for security) when the operating system is requirements for security) when the operating system is
"bootstrapped". "bootstrapped".
2. The Interface Identifier is finally obtained by taking as many 2. The Interface Identifier is finally obtained by taking as many
bits from the RID value (computed in the previous step) as bits from the RID value (computed in the previous step) as
necessary, starting from the least significant bit. The necessary, starting from the least significant bit. The
resulting Interface Identifier SHOULD be compared against the resulting Interface Identifier MUST be compared against the
reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID] reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID]
and against those Interface Identifiers already employed in an and against those Interface Identifiers already employed in an
address of the same network interface and the same network address of the same network interface and the same network
prefix. In the event that an unacceptable identifier has been prefix. In the event that an unacceptable identifier has been
generated, the value DAD_Counter should be incremented by 1, and generated, the value DAD_Counter should be incremented by 1, and
the algorithm should be restarted from the first step. the algorithm should be restarted from the first step.
3.4. Generating Temporary Addresses 3.4. Generating Temporary Addresses
[RFC4862] describes the steps for generating a link-local address [RFC4862] describes the steps for generating a link-local address
skipping to change at page 11, line 45 skipping to change at page 11, line 45
* Its Preferred Lifetime is the lower of the Preferred Lifetime * Its Preferred Lifetime is the lower of the Preferred Lifetime
of the prefix and TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR. of the prefix and TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR.
5. A temporary address is created only if this calculated Preferred 5. A temporary address is created only if this calculated Preferred
Lifetime is greater than REGEN_ADVANCE time units. In Lifetime is greater than REGEN_ADVANCE time units. In
particular, an implementation MUST NOT create a temporary address particular, an implementation MUST NOT create a temporary address
with a zero Preferred Lifetime. with a zero Preferred Lifetime.
6. New temporary addresses MUST be created by appending a randomized 6. New temporary addresses MUST be created by appending a randomized
interface identifier (generates as described in Section 3.3 of interface identifier (generated as described in Section 3.3 of
this document) to the prefix that was received. this document) to the prefix that was received.
7. The node MUST perform duplicate address detection (DAD) on the 7. The node MUST perform duplicate address detection (DAD) on the
generated temporary address. If DAD indicates the address is generated temporary address. If DAD indicates the address is
already in use, the node MUST generate a new randomized interface already in use, the node MUST generate a new randomized interface
identifier, and repeat the previous steps as appropriate up to identifier, and repeat the previous steps as appropriate up to
TEMP_IDGEN_RETRIES times. If after TEMP_IDGEN_RETRIES TEMP_IDGEN_RETRIES times. If after TEMP_IDGEN_RETRIES
consecutive attempts no non-unique address was generated, the consecutive attempts no non-unique address was generated, the
node MUST log a system error and MUST NOT attempt to generate node MUST log a system error and SHOULD NOT attempt to generate a
temporary addresses for that interface. This allows hosts to temporary address for the given prefix for the duration of the
recover from occasional DAD failures, or otherwise log the node's attachment to the network via this interface. This allows
recurrent address collisions. hosts to recover from occasional DAD failures, or otherwise log
the recurrent address collisions.
3.5. Expiration of Temporary Addresses 3.5. Expiration of Temporary Addresses
When a temporary address becomes deprecated, a new one MUST be When a temporary address becomes deprecated, a new one MUST be
generated. This is done by repeating the actions described in generated. This is done by repeating the actions described in
Section 3.4, starting at step 4). Note that, except for the Section 3.4, starting at step 4). Note that, except for the
transient period when a temporary address is being regenerated, in transient period when a temporary address is being regenerated, in
normal operation at most one temporary address per prefix should be normal operation at most one temporary address per prefix should be
in a non-deprecated state at any given time on a given interface. in a non-deprecated state at any given time on a given interface.
Note that if a temporary address becomes deprecated as result of Note that if a temporary address becomes deprecated as result of
skipping to change at page 14, line 22 skipping to change at page 14, line 29
other global prefixes. Another site might wish to enable temporary other global prefixes. Another site might wish to enable temporary
address generation only for the prefixes 2001:db8:1::/48 and address generation only for the prefixes 2001:db8:1::/48 and
2001:db8:2::/48 while disabling it for all other prefixes. To 2001:db8:2::/48 while disabling it for all other prefixes. To
support this behavior, implementations SHOULD provide a way to enable support this behavior, implementations SHOULD provide a way to enable
and disable generation of temporary addresses for specific prefix and disable generation of temporary addresses for specific prefix
subranges. This per-prefix setting SHOULD override the global subranges. This per-prefix setting SHOULD override the global
settings on the node with respect to the specified prefix subranges. settings on the node with respect to the specified prefix subranges.
Note that the per-prefix setting can be applied at any granularity, Note that the per-prefix setting can be applied at any granularity,
and not necessarily on a per subnet basis. and not necessarily on a per subnet basis.
Use of the extensions defined in this document may complicate 3.8. Defined Constants and Configuration Variables
debugging and other operational troubleshooting activities.
Consequently, it may be site policy that temporary addresses should
not be used. Consequently, implementations MUST provide a method for
the end user or trusted administrator to override the use of
temporary addresses.
3.8. Defined Constants
Constants defined in this document include: Constants and configuration variables defined in this document
include:
TEMP_VALID_LIFETIME -- Default value: 2 days. Users should be able TEMP_VALID_LIFETIME -- Default value: 2 days. Users should be able
to override the default value. to override the default value.
TEMP_PREFERRED_LIFETIME -- Default value: 1 day. Users should be TEMP_PREFERRED_LIFETIME -- Default value: 1 day. Users should be
able to override the default value. able to override the default value.
Note:
The TEMP_PREFERRED_LIFETIME value MUST be less than the
TEMP_VALID_LIFETIME value.
REGEN_ADVANCE -- 5 seconds REGEN_ADVANCE -- 5 seconds
MAX_DESYNC_FACTOR -- 10 minutes. Upper bound on DESYNC_FACTOR. MAX_DESYNC_FACTOR -- 10 minutes. Upper bound on DESYNC_FACTOR.
DESYNC_FACTOR -- A random value within the range 0 - DESYNC_FACTOR -- A random value within the range 0 -
MAX_DESYNC_FACTOR. It is computed once at system start (rather than MAX_DESYNC_FACTOR. It is computed once at system start (rather than
each time it is used) and must never be greater than each time it is used) and must never be greater than
(TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE). (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE).
TEMP_IDGEN_RETRIES -- Default value: 3 TEMP_IDGEN_RETRIES -- Default value: 3
skipping to change at page 17, line 16 skipping to change at page 17, line 16
[The RFC-Editor should remove this section before publishing this [The RFC-Editor should remove this section before publishing this
document as an RFC] document as an RFC]
The following are known implementations of this document: The following are known implementations of this document:
o FreeBSD kernel: There is a FreeBSD kernel implementation of this o FreeBSD kernel: There is a FreeBSD kernel implementation of this
document, albeit not yet committed. The implementation has been document, albeit not yet committed. The implementation has been
done in April 2020 by Fernando Gont <fgont@si6networks.com>. The done in April 2020 by Fernando Gont <fgont@si6networks.com>. The
corresponding patch can be found at: corresponding patch can be found at:
<https://www.gont.com.ar/code/fgont-patch-linux-net-next- <https://www.gont.com.ar/code/fgont-patch-freebsd-rfc4941bis.txt>
rfc4941bis.txt>
o Linux kernel: There is a Linux kernel implementation of this o Linux kernel: A Linux kernel implementation of this document has
document for the net-next tree, albeit not yet committed. The been committed to the net-next tree. The implementation has been
implementation has been done in April 2020 by Fernando Gont produced in April 2020 by Fernando Gont <fgont@si6networks.com>.
<fgont@si6networks.com>. The corresponding patch can be found at: The corresponding patch can be found at:
<https://www.gont.com.ar/code/fgont-patch-linux-net-next- <https://patchwork.ozlabs.org/project/netdev/
rfc4941bis.txt> patch/20200501035147.GA1587@archlinux-current.localdomain/>
o slaacd(8): slaacd(8) has traditionally used different randomized o slaacd(8): slaacd(8) has traditionally used different randomized
interface identifiers for each prefix, and it has recently reduced interface identifiers for each prefix, and it has recently reduced
the Valid Lifetime of temporary addresses as specified in the Valid Lifetime of temporary addresses as specified in
Section 3.8, thus fully implementing this document. The Section 3.8, thus fully implementing this document. The
implementation has been done by Florian Obser implementation has been done by Florian Obser
<florian@openbsd.org>, with the update to the temporary address <florian@openbsd.org>, with the update to the temporary address
Valid Lifetime applied in March 2020. The implementation can be Valid Lifetime applied in March 2020. The implementation can be
found at: <https://github.com/openbsd/src/tree/master/sbin/slaacd> found at: <https://github.com/openbsd/src/tree/master/sbin/slaacd>
skipping to change at page 22, line 23 skipping to change at page 22, line 23
SI6 Networks / UTN-FRH SI6 Networks / UTN-FRH
Evaristo Carriego 2644 Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706 Haedo, Provincia de Buenos Aires 1706
Argentina Argentina
Phone: +54 11 4650 8472 Phone: +54 11 4650 8472
Email: fgont@si6networks.com Email: fgont@si6networks.com
URI: https://www.si6networks.com URI: https://www.si6networks.com
Suresh Krishnan Suresh Krishnan
Ericsson Research Kaloom
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Email: suresh.krishnan@ericsson.com Email: suresh@kaloom.com
Thomas Narten Thomas Narten
IBM Corporation IBM Corporation
P.O. Box 12195 P.O. Box 12195
Research Triangle Park, NC Research Triangle Park, NC
USA USA
Email: narten@us.ibm.com Email: narten@us.ibm.com
Richard Draves Richard Draves
 End of changes. 20 change blocks. 
42 lines changed or deleted 37 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/