IPv6 Address Usage Recommendations
draft-gont-6man-address-usage-recommendations-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Fernando Gont , Guillermo Gont , Madelen Garcia Corbo , Christian Huitema | ||
| Last updated | 2017-03-13 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-gont-6man-address-usage-recommendations-02
IPv6 maintenance Working Group (6man) F. Gont
Internet-Draft SI6 Networks / UTN-FRH
Intended status: Best Current Practice G. Gont
Expires: September 14, 2017 SI6 Networks
M. Garcia Corbo
SITRANS
C. Huitema
Private Octopus Inc.
March 13, 2017
IPv6 Address Usage Recommendations
draft-gont-6man-address-usage-recommendations-02
Abstract
This document analyzes the security and privacy implications of IPv6
addresses based on a number of properties such as address scope,
stability, and usage type. It analyzes what properties are desirable
for some popular scenarios, and provides advice regarding the
configuration and usage of such addresses.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 14, 2017.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Gont, et al. Expires September 14, 2017 [Page 1]
Internet-Draft IPv6 Address Recommendations March 2017
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Testing for the Presence of Node in the Network . . . . . 4
3.2. Unexpected Address Discovery . . . . . . . . . . . . . . 4
3.3. Availability Outside the Expected Scope . . . . . . . . . 4
3.4. Limited Address Selection API . . . . . . . . . . . . . . 5
4. Predictability Considerations . . . . . . . . . . . . . . . . 5
5. Address Scope Considerations . . . . . . . . . . . . . . . . 6
6. Address Stability Considerations . . . . . . . . . . . . . . 6
7. Usage Type Considerations . . . . . . . . . . . . . . . . . . 8
8. Advice on IPv6 Address Configuration . . . . . . . . . . . . 9
9. Advice on IPv6 Address Usage . . . . . . . . . . . . . . . . 9
10. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 10
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
12. Security Considerations . . . . . . . . . . . . . . . . . . . 10
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
14.1. Normative References . . . . . . . . . . . . . . . . . . 10
14.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
IPv6 hosts typically configure a number of IPv6 addresses, which may
differ in multiple aspects, such as address scope and stability (e.g.
stable addresses vs. temporary addresses). For example, a host may
configure one stable and one temporary address per each
autoconfiguration prefix advertised on the local network. The
addresses to be configured typically depend on local system policy
configuration, with the aforementioned policy being static and
irrespective of the network the host attaches to.
There are three parameters that affect the security and privacy
properties of an address:
o Scope
o Stability
Vollbrecht, et al. Informational [Page 5]
RFC 4137 EAP State Machines August 2005
block appears to be atomic with respect to the execution of any
other state block, and the transition condition to that state from
the previous state is TRUE when execution commences. The order of
execution of state blocks in different state machines is undefined
except as constrained by their transition conditions. A variable
that is set to a particular value in a state block retains this
value until a subsequent state block executes a procedure that
modifies the value.
On completion of all the procedures within a state, all exit
conditions for the state (including all conditions associated with
global transitions) are evaluated continuously until one of the
conditions is met. The label ELSE denotes a transition that
occurs if none of the other conditions for transitions from the
state are met (i.e., ELSE evaluates to TRUE if all other possible
exit conditions from the state evaluate to FALSE). Where two or
more exit conditions with the same level of precedence become TRUE
simultaneously, the choice as to which exit condition causes the
state transition to take place is arbitrary.
Where it is necessary to split a state machine description across
more than one diagram, a transition between two states that appear
on different diagrams is represented by an exit arrow drawn with
dashed lines, plus a reference to the diagram that contains the
destination state. Similarly, dashed arrows and a dashed state
box are used on the destination diagram to show the transition to
the destination state. In a state machine that has been split in
this way, any global transitions that can cause entry to states
defined in one of the diagrams are deemed potential exit
conditions for all the states of the state machine, regardless of
which diagram the state boxes appear in.
Should a conflict exist between the interpretation of a state
diagram and either the corresponding global transition tables or
the textual description associated with the state machine, the
state diagram takes precedence. The interpretation of the special
symbols and operators used in the state diagrams is as defined in
Section 3.2; these symbols and operators are derived from the
notation of the C++ programming language, ISO/IEC 14882. If a
boolean variable is described in this clause as being set, it has
or is assigned the value TRUE; if it is described as being reset
or clear, it has the value FALSE.
In addition to the above notation, there are a couple of
clarifications specific to this document. First, all boolean
variables are initialized to FALSE before the state machine execution
begins. Second, the following notational shorthand is specific to
this document:
Vollbrecht, et al. Informational [Page 6]
RFC 4137 EAP State Machines August 2005
<variable> = <expression1> | <expression2> | ...
Execution of a statement of this form will result in <variable>
having a value of exactly one of the expressions. The logic for
which of those expressions gets executed is outside of the state
machine and could be environmental, configurable, or based on
another state machine, such as that of the method.
3.2. State Machine Symbols
( )
Used to force the precedence of operators in Boolean expressions
and to delimit the argument(s) of actions within state boxes.
;
Used as a terminating delimiter for actions within state boxes.
If a state box contains multiple actions, the order of execution
follows the normal English language conventions for reading text.
=
Assignment action. The value of the expression to the right of
the operator is assigned to the variable to the left of the
operator. If this operator is used to define multiple assignments
(e.g., a = b = X), the action causes the value of the expression
following the right-most assignment operator to be assigned to all
the variables that appear to the left of the right-most assignment
operator.
!
Logical NOT operator.
&&
Logical AND operator.
||
Logical OR operator.
if...then...
Conditional action. If the Boolean expression following the "if"
evaluates to TRUE, then the action following the "then" is
executed.
Vollbrecht, et al. Informational [Page 7]
RFC 4137 EAP State Machines August 2005
{ statement 1, ... statement N }
Compound statement. Braces are used to group statements that are
executed together as if they were a single statement.
!=
Inequality. Evaluates to TRUE if the expression to the left of
the operator is not equal in value to the expression to the right.
==
Equality. Evaluates to TRUE if the expression to the left of the
operator is equal in value to the expression to the right.
>
Greater than. Evaluates to TRUE if the value of the expression to
the left of the operator is greater than the value of the
expression to the right.
<=
Less than or equal to. Evaluates to TRUE if the value of the
expression to the left of the operator is either less than or
equal to the value of the expression to the right.
++
Increment the preceding integer operator by 1.
+
Arithmetic addition operator.
&
Bitwise AND operator.
3.3. Document Authority
Should a conflict exist between the interpretation of a state diagram
and either the corresponding global transition tables or the textual
description associated with the state machine, the state diagram
takes precedence. When a discrepancy occurs between any part of this
document (text or diagram) and any of the related documents
([RFC3748], [RFC3579], etc.), the latter (the other document) is
considered authoritative and takes precedence.
Vollbrecht, et al. Informational [Page 8]
RFC 4137 EAP State Machines August 2005
Gont, et al. Expires September 14, 2017 [Page 2]
Internet-Draft IPv6 Address Recommendations March 2017
o Usage type (client-like "outgoing connections" vs. server-like
"incoming connections")
Section 4, Section 5, Section 6, and Section 7 discuss the security
and privacy implications (and associated tradeoffs) of the scope,
stability and usage type properties of IPv6 addresses, respectively.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Problem Statement
Applications use system API's to select the IPv6 addresses that will
be used for incoming and outgoing connections. This choices have
consequences in terms of privacy, security, stability and
performance.
Default Address Selection for IPv6 is specified in [RFC6724]. The
selection starts with a set of potential destination addresses, such
as returned by getaddrinfo(), and the set of potential source
addresses currently configured for the selected interfaces. For each
potential destination address, the algorithm will select the source
address that provides the best route to the destination, while
choosing the appropriate scope and preferring temporary addresses.
The algorithm will then select the destination address, while giving
a preference to reachable addresses with the smallest scope. The
selection may be affected by system settings.
We note that [RFC6724] only applies for outgoing connections, such as
those made by clients trying to contact services. When devices
provide a service, the common pattern is to just wait for connections
over all addresses configured on the device. For example,
applications using the Sockets API will commonly bind() the listening
socket to undefined address. This long-established behavior is
appropriate for devices providing public services, but may have
unexpected results for devices providing semi-private services, such
as various forms of peer-to-peer or local-only applications.
This behavior leads to three problems: device tracking, discussed in
Section 3.1; unexpected address discovery, discussed in Section 3.2;
and availability outside the expected scope, discussed in
Section 3.3. These problems are caused in part by the limitations of
available address selection API, presented in Section 3.4.
Gont, et al. Expires September 14, 2017 [Page 3]
Internet-Draft IPv6 Address Recommendations March 2017
3.1. Testing for the Presence of Node in the Network
The stable addresses recommended in [RFC8064] use stable IID defined
in [RFC7217]. One key part of that algorithm is that if a device
connects to a given network at different times, it will always
configure the same IPv6 addresses on that network. If the device
hosts a service ready to accept connections on that stable address,
adversaries can test the presence of the device on the network by
attempting connections to that stable address. Stable addresses used
by listening services will thus enable testing whether a specific
device is returning to a particular network, which in many cases will
be considered a privacy issue.
3.2. Unexpected Address Discovery
Systems like DNS-Based Service Discovery [RFC6763] allows clients to
discover services within a limited scope, that can be defined by a
domain name. These services are not advertised outside of that
scope, and thus do not expect to be discovered by random parties on
the Internet. Yet it appears that such services are easily
discoverable if they listen for connections to IPv6 addresses that a
client process also uses as source address when connecting to remote
servers.
An example of such unexpected discovery is described in [Hein]. A
network manager observed scanning traffic directed at the
temporary addresses of local devices. Analysis shows that the
scanners learned the addresses by observing the device contact an
NTP service ([RFC5905]). The remote scanning was possible because
the local devices were also accepting connections directed to the
temporary addresses.
It is obvious from the example that the "attack surface" of the
services is increased because it listens to the same IPv6 addresses
that are also used by clients for outgoing communications with remote
systems. But the overlap between "client" and "server" addresses is
only one part of the problem. Suppose that a devices hosts both a
video game and a home automation application. The video game users
will be able to discover the IPv6 address of the game server. If the
home automation server listens to the same IPv6 addresses, it is now
exposed to connection attempts by all these users. That, too,
increases the attack surface of the home automation server.
3.3. Availability Outside the Expected Scope
The IPv6 addressing architecture [RFC4291] defines multiple address
scopes. In practice, devices are often configured with globally
reachable unicast addresses, link local addresses, and Unique Local
Gont, et al. Expires September 14, 2017 [Page 4]
Internet-Draft IPv6 Address Recommendations March 2017
IPv6 Unicast Addresses (ULA) [RFC4193]. Availability outside the
expected scope happens when a service is expected to be only
available in some local scope, but inadvertently becomes available to
remote parties. That could happen for example if a service is meant
to be available only on a given link, but becomes reachable through
ULA or through globally reachable addresses, or if a service is meant
to be available only inside some organization's perimeter and becomes
reachable through globally reachable addresses. It will happen in
particular if a service intended for some local scope is programmed
to bind to "unspecified" addresses, which in practice means every
address configured for the device.
3.4. Limited Address Selection API
Application developers using the Sockets API can "bind" a listening
socket to a specific address, and ensure that the application is only
reachable through that address. In theory, careful selection of the
binding address could mitigate the three problems mentioned above.
Binding services to temporary address could mitigate device tracking.
Binding different services to different addresses could mitigate
unexpected discovery. Binding services to link local addresses or
ULA could mitigate availability outside the expected scope. However,
explicitly managing addresses adds significant complexity to the
application development. It requires that application developers
master addressing architectures subtleties, and implement logic that
reacts adequately to connectivity events and address changes.
Experience shows that application developers would probably prefer
some much simpler solution.
In addition, we should note that many application developers use high
level APIs that listen to TLS, HTTP, or some other application
protocol. These high level APIs seldom provide detailed access to
specific IP addresses, and typically default to listening to all
available addresses.
4. Predictability Considerations
Predictable IPv6 addresses result in a number of security and privacy
implications. For example, [Barnes2012] discusses how patterns in
network prefixes can be leveraged for IPv6 address scanning. On the
other hand, [RFC7707], [RFC7721] and [RFC7217] discuss the security
and privacy implications of predictable IPv6 Interface Identifiers
(IIDs).
Given the aforementioned previous work in this area, and the formal
specification update produced by [RFC8064], we expect (and assume in
the rest of this document) that implementations have replaced any
schemes that produce predictable addresses with alternative schemes
Gont, et al. Expires September 14, 2017 [Page 5]
Internet-Draft IPv6 Address Recommendations March 2017
that avoid such patterns (e.g., RFC7217 in replacement of the
traditional SLAAC addresses that embed link-layer addresses).
5. Address Scope Considerations
The IPv6 address scope can, in some scenarios, limit the attack
exposure of a node as a result of the implicit isolation provided by
a non-global address scope. For example, a node that only employs
link-local addresses may, in principle, only be exposed to attack
from other nodes in the local link. Hosts employing only Unique
Local Addresses (ULAs) may be more isolated from attack than those
employing Global Unicast Addresses (GUAs), assuming that proper
packet filtering is enforced at the network edge.
The potential protection provided by a non-global addresses should
not be regarded as a complete security strategy, but rather as a form
of "prophylactic" security (see
[I-D.gont-opsawg-firewalls-analysis]).
We note that the use of non-global addresses is usually limited to a
reduced type of applications/protocols that e.g. are only meant to
operate on a reduced scope, and hence their applicability may be
limited.
A discussion of ULA usage considerations can be found in
[I-D.ietf-v6ops-ula-usage-considerations].
6. Address Stability Considerations
The stability of an address has two associated security/privacy
implications:
o Ability of an attacker to correlate network activity
o Exposure to attack
For obvious reasons, an address that is employed for multiple
communication instances allows the aforementioned network activities
to be correlated. The longer an address is employed (i.e., the more
stable it is), the longer such correlation will be possible. In the
worst-case scenario, a stable address that is employed for multiple
communication instances over time will allow all such activities to
be correlated. On the other hand, if a host were to generate (and
eventually "throw away") one new address for each communication
instance (e.g., TCP connection), network activity correlation would
be mitigated.
Gont, et al. Expires September 14, 2017 [Page 6]
Internet-Draft IPv6 Address Recommendations March 20174. Peer State Machine
The following is a diagram of the EAP peer state machine. Also
included is an explanation of the primitives and procedures
referenced in the diagram, as well as a clarification of notation.
(see the .pdf version for missing diagram or
refer to Appendix A.1 if reading the .txt version)
Figure 3: EAP Peer State Machine
4.1. Interface between Peer State Machine and Lower Layer
The lower layer presents messages to the EAP peer state machine by
storing the packet in eapReqData and setting the eapReq signal to
TRUE. Note that despite the name of the signal, the lower layer does
not actually inspect the contents of the EAP packet (it could be a
Success or Failure message instead of a Request).
When the EAP peer state machine has finished processing the message,
it sets either eapResp or eapNoResp. If it sets eapResp, the
corresponding response packet is stored in eapRespData. The lower
layer is responsible for actually transmitting this message. When
the EAP peer state machine authentication is complete, it will set
eapSuccess or eapFailure to indicate to the lower layer that the
authentication has succeeded or failed.
4.1.1. Variables (Lower Layer to Peer)
eapReq (boolean)
Set to TRUE in lower layer, FALSE in peer state machine.
Indicates that a request is available in the lower layer.
eapReqData (EAP packet)
Set in lower layer when eapReq is set to TRUE. The contents of
the available request.
portEnabled (boolean)
Indicates that the EAP peer state machine should be ready for
communication. This is set to TRUE when the EAP conversation is
started by the lower layer. If at any point the communication
port or session is not available, portEnabled is set to FALSE, and
the state machine transitions to DISABLED. To avoid unnecessary
resets, the lower layer may dampen link down indications when it
believes that the link is only temporarily down and that it will
Vollbrecht, et al. Informational [Page 9]
RFC 4137 EAP State Machines August 2005
soon be back up (see [RFC3748], Section 7.12). In this case,
portEnabled may not always be equal to the "link up" flag of the
lower layer.
idleWhile (integer)
Outside timer used to indicate how much time remains before the
peer will time out while waiting for a valid request.
eapRestart (boolean)
Indicates that the lower layer would like to restart
authentication.
altAccept (boolean)
Alternate indication of success, as described in [RFC3748].
altReject (boolean)
Alternate indication of failure, as described in [RFC3748].
4.1.2. Variables (peer to lower layer)
eapResp (boolean)
Set to TRUE in peer state machine, FALSE in lower layer.
Indicates that a response is to be sent.
eapNoResp (boolean)
Set to TRUE in peer state machine, FALSE in lower layer.
Indicates that the request has been processed, but that there is
no response to send.
eapSuccess (boolean)
Set to TRUE in peer state machine, FALSE in lower layer.
Indicates that the peer has reached the SUCCESS state.
eapFail (boolean)
Set to TRUE in peer state machine, FALSE in lower layer.
Indicates that the peer has reached the FAILURE state.
Vollbrecht, et al. Informational [Page 10]
RFC 4137 EAP State Machines August 2005
eapRespData (EAP packet)
Set in peer state machine when eapResp is set to TRUE. The EAP
packet that is the response to send.
eapKeyData (EAP key)
Set in peer state machine when keying material becomes available.
Set during the METHOD state. Note that this document does not
define the structure of the type "EAP key". We expect that it
will be defined in [Keying].
eapKeyAvailable (boolean)
Set to TRUE in the SUCCESS state if keying material is available.
The actual key is stored in eapKeyData.
4.1.3. Constants
ClientTimeout (integer)
Configurable amount of time to wait for a valid request before
aborting, initialized by implementation-specific means (e.g., a
configuration setting).
4.2. Interface between Peer State Machine and Methods
IN: eapReqData (includes reqId)
OUT: ignore, eapRespData, allowNotifications, decision
IN/OUT: methodState, (method-specific state)
The following describes the interaction between the state machine and
EAP methods.
If methodState==INIT, the method starts by initializing its own
method-specific state.
Next, the method must decide whether to process the packet or to
discard it silently. If the packet appears to have been sent by
someone other than the legitimate authenticator (for instance, if
message integrity check fails) and the method is capable of treating
such situations as non-fatal, the method can set ignore=TRUE. In
this case, the method should not modify any other variables.
If the method decides to process the packet, it behaves as follows.
Vollbrecht, et al. Informational [Page 11]
RFC 4137 EAP State Machines August 2005
o It updates its own method-specific state.
o If the method has derived keying material it wants to export, it
stores the keying material to eapKeyData.
o It creates a response packet (with the same identifier as the
request) and stores it to eapRespData.
o It sets ignore=FALSE.
Next, the method must update methodState and decision according to
the following rules.
methodState=CONT: The method always continues at this point (and the
peer wants to continue it). The decision variable is always set
to FAIL.
methodState=MAY_CONT: At this point, the authenticator can decide
either to continue the method or to end the conversation. The
decision variable tells us what to do if the conversation ends.
If the current situation does not satisfy the peer's security
policy (that is, if the authenticator now decides to allow access,
the peer will not use it), set decision=FAIL. Otherwise, set
decision=COND_SUCC.
methodState=DONE: The method never continues at this point (or the
peer sees no point in continuing it).
If either (a) the authenticator has informed us that it will not
allow access, or (b) we're not willing to talk to this
authenticator (e.g., our security policy is not satisfied), set
decision=FAIL. (Note that this state can occur even if the method
still has additional messages left, if continuing it cannot change
the peer's decision to success).
If both (a) the server has informed us that it will allow access,
and the next packet will be EAP Success, and (b) we're willing to
use this access, set decision=UNCOND_SUCC.
Otherwise, we do not know what the server's decision is, but are
willing to use the access if the server allows. In this case, set
decision=COND_SUCC.
Finally, the method must set the allowNotifications variable. If the
new methodState is either CONT or MAY_CONT, and if the method
specification does not forbid the use of Notification messages, set
allowNotifications=TRUE. Otherwise, set allowNotifications=FALSE.
Vollbrecht, et al. Informational [Page 12]
RFC 4137 EAP State Machines August 2005
4.3. Peer State Machine Local Variables
4.3.1. Long-Term (Maintained between Packets)
selectMethod (EAP type)
Set in GET_METHOD state. The method that the peer believes is
currently "in progress"
methodState (enumeration)
As described above.
lastId (integer)
0-255 or NONE. Set in SEND_RESPONSE state. The EAP identifier
value of the last request.
lastRespData (EAP packet)
Set in SEND_RESPONSE state. The EAP packet last sent from the
peer.
decision (enumeration)
As described above.
NOTE: EAP type can be normal type (0..253,255), or an extended type
consisting of type 254, Vendor-Id, and Vendor-Type.
4.3.2. Short-Term (Not Maintained between Packets)
rxReq (boolean)
Set in RECEIVED state. Indicates that the current received packet
is an EAP request.
rxSuccess (boolean)
Set in RECEIVED state. Indicates that the current received packet
is an EAP Success.
rxFailure (boolean)
Set in RECEIVED state. Indicates that the current received packet
is an EAP Failure.
Vollbrecht, et al. Informational [Page 13]
RFC 4137 EAP State Machines August 2005
reqId (integer)
Set in RECEIVED state. The identifier value associated with the
current EAP request.
reqMethod (EAP type)
Set in RECEIVED state. The method type of the current EAP
request.
ignore (boolean)
Set in METHOD state. Indicates whether the method has decided to
drop the current packet.
4.4. Peer State Machine Procedures
NOTE: For method procedures, the method uses its internal state in
addition to the information provided by the EAP layer. The only
arguments that are explicitly shown as inputs to the procedures are
those provided to the method by EAP. Those inputs provided by the
method's internal state remain implicit.
parseEapReq()
Determine the code, identifier value, and type of the current
request. In the case of a parsing error (e.g., the length field
is longer than the received packet), rxReq, rxSuccess, and
rxFailure will all be set to FALSE. The values of reqId and
reqMethod may be undefined as a result. Returns three booleans,
one integer, and one EAP type.
processNotify()
Process the contents of Notification Request (for instance,
display it to the user or log it). The return value is undefined.
buildNotify()
Create the appropriate notification response. Returns an EAP
packet.
processIdentity()
Process the contents of Identity Request. Return value is
undefined.
Vollbrecht, et al. Informational [Page 14]
RFC 4137 EAP State Machines August 2005
buildIdentity()
Create the appropriate identity response. Returns an EAP packet.
m.check()
Method-specific procedure to test for the validity of a message.
Returns a boolean.
m.process()
Method procedure to parse and process a request for that method.
Returns a methodState enumeration, a decision enumeration, and a
boolean.
m.buildResp()
Method procedure to create a response message. Returns an EAP
packet.
m.getKey()
Method procedure to obtain key material for use by EAP or lower
layers. Returns an EAP key.
4.5. Peer State Machine States
DISABLED
This state is reached whenever service from the lower layer is
interrupted or unavailable. Immediate transition to INITIALIZE
occurs when the port becomes enabled.
INITIALIZE
Initializes variables when the state machine is activated.
IDLE
The state machine spends most of its time here, waiting for
something to happen.
RECEIVED
This state is entered when an EAP packet is received. The packet
header is parsed here.
Vollbrecht, et al. Informational [Page 15]
RFC 4137 EAP State Machines August 2005
GET_METHOD
This state is entered when a request for a new type comes in.
Either the correct method is started, or a Nak response is built.
METHOD
The method processing happens here. The request from the
authenticator is processed, and an appropriate response packet is
built.
SEND_RESPONSE
This state signals the lower layer that a response packet is ready
to be sent.
DISCARD
This state signals the lower layer that the request was discarded,
and no response packet will be sent at this time.
IDENTITY
Handles requests for Identity method and builds a response.
NOTIFICATION
Handles requests for Notification method and builds a response.
RETRANSMIT
Retransmits the previous response packet.
SUCCESS
A final state indicating success.
FAILURE
A final state indicating failure.
Vollbrecht, et al. Informational [Page 16]
RFC 4137 EAP State Machines August 2005
5. Stand-Alone Authenticator State Machine
The following is a diagram of the stand-alone EAP authenticator state
machine. This diagram should be used for those interested in a
self-contained, or non-pass-through, authenticator. Included is an
explanation of the primitives and procedures referenced in the
diagram, as well as a clarification of notation.
(see the .pdf version for missing diagram or
refer to Appendix A.2 if reading the .txt version)
Figure 4: EAP Stand-Alone Authenticator State Machine
5.1. Interface between Stand-Alone Authenticator State Machine and
Lower Layer
The lower layer presents messages to the EAP authenticator state
machine by storing the packet in eapRespData and setting the eapResp
signal to TRUE.
When the EAP authenticator state machine has finished processing the
message, it sets one of the signals eapReq, eapNoReq, eapSuccess, and
eapFail. If it sets eapReq, eapSuccess, or eapFail, the
corresponding request (or success/failure) packet is stored in
eapReqData. The lower layer is responsible for actually transmitting
this message.
5.1.1. Variables (Lower Layer to Stand-Alone Authenticator)
eapResp (boolean)
Set to TRUE in lower layer, FALSE in authenticator state machine.
Indicates that an EAP response is available for processing.
eapRespData (EAP packet)
Set in lower layer when eapResp is set to TRUE. The EAP packet to
be processed.
portEnabled (boolean)
Indicates that the EAP authenticator state machine should be ready
for communication. This is set to TRUE when the EAP conversation
is started by the lower layer. If at any point the communication
port or session is not available, portEnabled is set to FALSE, and
the state machine transitions to DISABLED. To avoid unnecessary
resets, the lower layer may dampen link down indications when it
believes that the link is only temporarily down and that it will
Vollbrecht, et al. Informational [Page 17]
RFC 4137 EAP State Machines August 2005
soon be back up (see [RFC3748], Section 7.12). In this case,
portEnabled may not always be equal to the "link up" flag of the
lower layer.
retransWhile (integer)
Outside timer used to indicate how long the authenticator has
waited for a new (valid) response.
eapRestart (boolean)
Indicates that the lower layer would like to restart
authentication.
eapSRTT (integer)
Smoothed round-trip time. (See [RFC3748], Section 4.3.)
eapRTTVAR (integer)
Round-trip time variation. (See [RFC3748], Section 4.3.)
5.1.2. Variables (Stand-Alone Authenticator To Lower Layer)
eapReq (boolean)
Set to TRUE in authenticator state machine, FALSE in lower layer.
Indicates that a new EAP request is ready to be sent.
eapNoReq (boolean)
Set to TRUE in authenticator state machine, FALSE in lower layer.
Indicates the most recent response has been processed, but there
is no new request to send.
eapSuccess (boolean)
Set to TRUE in authenticator state machine, FALSE in lower layer.
Indicates that the state machine has reached the SUCCESS state.
eapFail (boolean)
Set to TRUE in authenticator state machine, FALSE in lower layer.
Indicates that the state machine has reached the FAILURE state.
Vollbrecht, et al. Informational [Page 18]
RFC 4137 EAP State Machines August 2005
eapTimeout (boolean)
Set to TRUE in the TIMEOUT_FAILURE state if the authenticator has
reached its maximum number of retransmissions without receiving a
response.
eapReqData (EAP packet)
Set in authenticator state machine when eapReq, eapSuccess, or
eapFail is set to TRUE. The actual EAP request to be sent (or
success/failure).
eapKeyData (EAP key)
Set in authenticator state machine when keying material becomes
available. Set during the METHOD state. Note that this document
does not define the structure of the type "EAP key". We expect
that it will be defined in [Keying].
eapKeyAvailable (boolean)
Set to TRUE in the SUCCESS state if keying material is available.
The actual key is stored in eapKeyData.
5.1.3. Constants
MaxRetrans (integer)
Configurable maximum for how many retransmissions should be
attempted before aborting.
5.2. Interface between Stand-Alone Authenticator State Machine and
Methods
IN: eapRespData, methodState
OUT: ignore, eapReqData
IN/OUT: currentId, (method-specific state), (policy)
The following describes the interaction between the state machine and
EAP methods.
m.init (in: -, out: -)
Vollbrecht, et al. Informational [Page 19]
RFC 4137 EAP State Machines August 2005
When the method is first started, it must initialize its own method-
specific state, possibly using some information from Policy (e.g.,
identity).
m.buildReq (in: integer, out: EAP packet)
Next, the method creates a new EAP Request packet, with the given
identifier value, and updates its method-specific state accordingly.
m.getTimeout (in: -, out: integer or NONE)
The method can also provide a hint for retransmission timeout with
m.getTimeout.
m.check (in: EAP packet, out: boolean)
When a new EAP Response is received, the method must first decide
whether to process the packet or to discard it silently. If the
packet looks like it was not sent by the legitimate peer (e.g., if it
has an invalid Message Integrity Check (MIC), which should never
occur), the method can indicate this by returning FALSE. In this
case, the method should not modify its own method-specific state.
m.process (in: EAP packet, out: -)
m.isDone (in: -, out: boolean)
m.getKey (in: -, out: EAP key or NONE)
Next, the method processes the EAP Response and updates its own
method-specific state. Now the options are to continue the
conversation (send another request) or to end this method.
If the method wants to end the conversation, it
o Tells Policy about the outcome of the method and possibly other
information.
o If the method has derived keying material it wants to export,
returns it from m.getKey().
o Indicates that the method wants to end by returning TRUE from
m.isDone().
Otherwise, the method continues by sending another request, as
described earlier.
Vollbrecht, et al. Informational [Page 20]
NOTE: the use of constant IIDs (as in traditional SLAAC) result in
addresses that, while not constant as a whole (since the prefix
changes), contain a globally-unique value that leaks out the node
"identity". Such addresses result in the worst possible security
and privacy implications, and their use has been deprecated by
[RFC8064].
Typically, when it comes to attack exposure, the longer an address is
employed the longer an attacker is exposed to attacks (e.g. an
attacker has more time to find the address in the first place
[RFC7707]). While such exposure is traditionally associated with the
stability of the address, the usage type of the address (see
Section 7) may also have an impact on attack exposure.
A popular approach to mitigate network activity correlation is the
use of "temporary addresses" [RFC4941]. Temporary addresses are
typically configured and employed along with stable addresses, with
the temporary addresses employed for outgoing communications, and the
stable addresses employed for incoming communications.
NOTE: Ongoing work [I-D.gont-6man-non-stable-iids] aims at
updating [RFC4941] such that temporary addresses can be employed
without the need to configure stable addresses.
We note that the extent to which temporary addresses provide improved
mitigation of network activity correlation and/or reduced attack
exposure may be questionable and/or limited in some scenarios. For
example, a temporary address that is reachable for, say, a few hours
has a questionable "reduced exposure" (particularly when automated
attack tools do not typically require such a long period of time to
complete their task). Similarly, if network activity can be
correlated for the life of such address (e.g., on the order of
several hours), such period of time might be long enough for the
attacker to correlate all the network activity he is meaning to
correlate.
In order to better mitigate network activity correlation and/or
possibly reduce host exposure, an implementation might want to either
reduce the preferred lifetime of a temporary address, or even better,
generate one new temporary address for each new transport protocol
instance. However, the associated lifetime/stability of an address
may have a negative impact on the network. For example, if a node
were to employ "throw away" IPv6 addresses, or employ temporary
addresses [RFC4941] with a short preferred lifetime, local nodes
might need to maintain too many entries in their Neighbor Cache, and
a number of devices (possibly enforcing security policies) might also
need to keep such additional state.
Gont, et al. Expires September 14, 2017 [Page 7]
Internet-Draft IPv6 Address Recommendations March 2017
Additionally, enforcing a maximum lifetime on IPv6 addresses may
cause long-lived TCP connections to fail. For example, an address
becoming "Invalid" (after transitioning through the "Preferred" and
"Deprecated" states) would cause the TCP connections employing them
to break. This, in turn, would cause e.g. long-lived SSH sessions to
break/fail.
In some scenarios, attack exposure may be reduced by limiting the
usage of temporary addresses to outbound connections, and prevent
such addresses from being used for inbound connections (please see
Section 7).
7. Usage Type Considerations
A node that employs one of its addresses to communicate with an
external server (i.e., to perform an "outgoing connection") may cause
such address to become exposed to attack. For example, once the
external server receives an incoming connection, the corresponding
server might launch an attack against the aforementioned address. A
real-world instance of this type of scenario has been documented in
[Hein].
However, we note that employing an IPv6 address for an outgoing
communications need not increase the exposure of local services to
other parties. For example, nodes could employ temporary addresses
only for outgoing connections, but not for incoming connections.
Thus, external nodes that learn about client's addresses could not
really leverage such addresses for actively contacting the clients.
There are multiple ways in which this could possibly be achieved,
with different implications. Namely:
o Run a host-based or network-based firewall
o Bind services to specific (explicit) addresses
o Bind services only to stable addresses
A client could simply run a host-based firewall that only allows
incoming connections on the stable addresses. This is clearly more
of an operational way of achieving the desired functionality, and may
require good firewall/host integration (e.g., the firewall should be
able to tell stable vs. temporary addresses), may require the client
to run additional firewall software for this specific purpose, etc.
In other scenarios, a network-based firewall could be configured to
allow outgoing communications from all internal addresses, but only
allow incoming communications to stable addresses. For obvious
Gont, et al. Expires September 14, 2017 [Page 8]
Internet-Draft IPv6 Address Recommendations March 2017
reasons, this is generally only applicable to networks where incoming
communications are allowed to a limited number of hosts/servers.
Services could be bound to specific (explicit) addresses, rather than
to all locally-configured addresses. However, there are a number of
short-comings associated with this approach. Firstly, an application
would need to be able to learn all of its addresses and associated
stability properties, something that tends to be non-trivial and non-
portable, and that also makes applications protocol-dependent,
unnecessarily. Secondly, the Sockets API does not really allow a
socket to be bound to a subset of the node's addresses. That is,
sockets can be bound to a single address or to all available
addresses (wildcard), but not to a subset of all the configured
addresses.
Binding services only to stable addresses provides a clean separation
between addresses employed for client-like outgoing connections and
server-like incoming connections. However, we currently lack an
appropriate API for nodes to be able to specify that a socket should
only be bound to stable addresses. Development of such an API should
be considered for future work.
8. Advice on IPv6 Address Configuration
[TBD]
TODO: This section is expected to provide advice regarding the
configuration of different addresses for different typical scenarios.
e.g., when nodes may want to configure stable-only, temporary-only,
or stable+temporary. In the most simple analysis, one might expect
nodes in a typical enterprise network to employ only stable
addresses. General-purpose nodes in a home or "trusted" network may
want to employ both stable and temporary addresses. Finally, mobile
nodes (e.g. when roaming across non-trusted networks) may want to
employ only temporary addresses).
9. Advice on IPv6 Address Usage
[TBD]
TODO: This section is expected to provide recommendations regarding
the usage of IPv6 addresses. Among others, it is expected to provide
recommendations regarding the usage of IPv6 addresses when providing
network services. In the mos simple form, one argue that nodes may
want to employ only the smallest-scope applicable addresses (if
available) and, if stable addresses are available, nodes may want to
accept incoming connections on such addresses but *not* on temporary
addresses.
Gont, et al. Expires September 14, 2017 [Page 9]
Internet-Draft IPv6 Address Recommendations March 2017
10. Future Work
Some of the discussion in this document suggest that in order to
fully benefit from the IPv6 addresses (in terms of e.g. increased
availability of addresses and address types) additional work may be
required in this areas:
o Sockets API: The API may need to be extended such that a node may
bind() only a subset of the available addresses, possibly by
specifying a criteria (e.g. "only stable addresses", "only
global", "only local", etc.).
The aforementioned work may be carried out in this document, or as a
result of spin off documents.
11. IANA Considerations
There are no IANA registries within this document. The RFC-Editor
can remove this section before publication of this document as an
RFC.
12. Security Considerations
The security and privacy implications associated with the
predictability and lifetime of IPv6 addresses has been analyzed in
[RFC7217] [RFC7721], and [RFC7707]. This document complements and
extends the aforementioned analysis by considering other IPv6
properties such as the address scope and address usage type.
This document also analyzes what properties are desirable for some
popular scenarios, and provides advice regarding the configuration
and usage of such addresses. Finally, it describes possible future
standards-track work to allow for greater flexibility in IPv6 address
usage.
13. Acknowledgements
The authors would like to thank [TBD] for providing valuable comments
on earlier versions of this document.
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
Gont, et al. Expires September 14, 2017 [Page 10]
Internet-Draft IPv6 Address Recommendations March 2017
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<http://www.rfc-editor.org/info/rfc4193>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<http://www.rfc-editor.org/info/rfc4941>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<http://www.rfc-editor.org/info/rfc6724>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<http://www.rfc-editor.org/info/rfc6763>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014,
<http://www.rfc-editor.org/info/rfc7217>.
[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,
"Recommendation on Stable IPv6 Interface Identifiers",
RFC 8064, DOI 10.17487/RFC8064, February 2017,
<http://www.rfc-editor.org/info/rfc8064>.
14.2. Informative References
[RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
<http://www.rfc-editor.org/info/rfc7707>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016,
<http://www.rfc-editor.org/info/rfc7721>.
Gont, et al. Expires September 14, 2017 [Page 11]
Internet-Draft IPv6 Address Recommendations March 2017
[I-D.ietf-v6ops-ula-usage-considerations]
Liu, B. and S. Jiang, "Considerations For Using Unique
Local Addresses", draft-ietf-v6ops-ula-usage-
considerations-02 (work in progress), March 2017.
[I-D.gont-6man-non-stable-iids]
Gont, F., Huitema, C., Gont, G., and M. Corbo,
"Recommendation on Temporary IPv6 Interface Identifiers",
draft-gont-6man-non-stable-iids-01 (work in progress),
March 2017.
[I-D.gont-opsawg-firewalls-analysis]
Gont, F. and F. Baker, "On Firewalls in Network Security",
draft-gont-opsawg-firewalls-analysis-02 (work in
progress), February 2016.
[Barnes2012]
Barnes, R., Altmann, R., and D. Kerr, "Mapping the Great
Void Smarter scanning for IPv6", ISMA 2012 AIMS-4 -
Workshop on Active Internet Measurements, February 2012,
<https://www.caida.org/workshops/isma/1202/slides/
aims1202_rbarnes.pdf>.
[Hein] Hein, B., "The Rising Sophistication of Network Scanning",
January 2016, <http://netpatterns.blogspot.be/2016/01/
the-rising-sophistication-of-network.html>.
Authors' Addresses
Fernando Gont
SI6 Networks / UTN-FRH
Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706
Argentina
Phone: +54 11 4650 8472
Email: fgont@si6networks.com
URI: http://www.si6networks.com
Gont, et al. Expires September 14, 2017 [Page 12]
Internet-Draft IPv6 Address Recommendations March 2017
Guillermo Gont
SI6 Networks
Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706
Argentina
Phone: +54 11 4650 8472
Email: ggont@si6networks.com
URI: https://www.si6networks.com
Madeleine Garcia Corbo
Servicios de Informacion del Transporte
Neptuno 358
Havana City 10400
Cuba
Email: madelen.garcia16@gmail.com
Christian Huitema
Private Octopus Inc.
Friday Harbor, WA 98250
U.S.A.
Email: huitema@huitema.net
URI: http://privateoctopus.com
Gont, et al. Expires September 14, 2017 [Page 13]
RFC 4137 EAP State Machines August 2005