Subject: [dna] next steps on draft-ietf-dna-simple

From: Jari Arkko <[email-masked]>
Date: Fri, 20 Nov 2009 10:39:39 +0200

The IESG reviewed this draft in our meeting yesterday. A number of 
issues were brought up, most of it already resolved but some still 
remain. Here are the changes that I've entered as RFC Editor notes:

1) Updates 4861 issue per Brian Carpenter's review comments:

  Please remove the "Updates 4861" claim from the header.

2) Unclear specification with respect to what the draft requires about 
fast RAs. I believe the current wording referred to draft-ietf-dna-frd. 
Some readers thought our specification was requiring a change from the 
4861 rules that dictate a delay before the RS can go out.

  Please remove the following text from Section 2.4:

  As a result, in addition to implementing simple DNA, it is desirable
  that routers adopt procedures which allow for fast unicast Router
  Advertisement (RA) messages.

3) An additional security consideration issue was brought in secdir review.

  Please add the following text to the end of the security
  considerations section:

  The DNA procedure does not in itself provide positive, secure 
  authentication of the router(s) on the network, or authentication of
  the network itself, as e.g. would be provided by mutual authentication
  at the link layer. Therefore when such assurance is not available, the
  host MUST NOT make any security-sensitive decisions based on the DNA
  procedure. In particular, it MUST NOT decide it has rejoined a network
  known to be physically secure, and proceed to abandon cryptographic
  protection.

4) Lars Eggert was happy that the draft included retransmission rules, 
but noted that the draft should also set an upper limit on how many 
previous routers are probed.

  Please add the following text to end of Section 4.4:

  A Simple DNA implementation SHOULD limit probing to at most
  six previously seen routers.

Everyone happy with these changes? Also, we have a few remaining issues:

5) Lars asked whether some of the SHOULDs in the document should really 
be MUSTs. In my review this is not universally true at least. For 
instance, you may give some freedom for implementations to avoid sending 
probes if there are too many link up events in a short time period. 
However, we'd like you Suresh go through the document and for each 
SHOULD think about what the right keyword is. Sometimes it might be a 
MUST, sometimes a SHOULD. In some of the cases where its a SHOULD, it 
might be good to include a sentence or two about what issues might be 
considered when implementing it.

6) We need to respond to Ralph Droms' detailed review. (Thank you 
Ralph!) I think we can forget the Updates 4861 part of his discuss, but 
the rest is relevant. I'm including his Discuss here for completeness sake:

This document calls for the transmission of an initial DHCPv6 message 
without the
initial delay specified in section 17.1.2 of RFC 3315.  The document
also modifies the retransmission rules for several messages.  And,
although I hate to raise this issue, this document suggests that
a DHCPv6 transaction is initiated before the hsot has seen the M/O
bits in an RA.

In section 4.1, I think each table entry should include:

  o  Link-local IPv6 address of the router that advertised the prefix.

  o  Link-layer (MAC) address of the router that advertised the prefix.

  o  One or more IPv6 addresses; for each address include:
      * flag to indicate whether the address was obtained through
        SLAAC or DHCPv6
      * preferred lifetime
      * valid lifetime
      * other configuration information if address was obtained
        through DHCPv6:
        - DUID
        - IA_ID
        - flag indicating IA_NA/IA_TA
        - other configuration information (DNS recursive servers, NTP
          servers, etc.)

  o One or more prefixes assigned to the link
      * preferred lifetime
      * valid lifetime
      * on-link flag

In section 4.2:

  o  Sending of neighbor discovery or DHCPv6 probes

is incorrect ("or").  The host always sends NS probes and RS requests;
it *may* send a DHCPv6 confirmation early as an optimization.

In section 4.4:

  For the purpose of sending neighbor solicitations to previous
  routers, the host first identifies the set of operable IPv6 addresses
  (candidate set) that it wishes to use.  If the addresses obtained
  from a previous router are no longer valid, the host does not include
  these addresses in the candidate set for NS based probing.

s/operable/valid/  At this point, the host does not know what link it
is attached to, so it cannot determine which addresses are operable.
Also, the second sentence in this paragraph is redundant assuming the
change to "valid" is made.

More abstractly, I would rewrite this paragraph and the following
paragraph to allow for multiple addresses on an interface:

  For the purpose of sending Neighbor Solicitation messages to
  previous routers, the host first identifies the set of candidate
  routers to probe.  Any router in the SDAT for which there is at
  least one valid address is in the set of candidate routers.

  For each router in the candidate set, the host obtains the
  link-local and MAC addresses of the router from the SDAT.  The host
  then sends a unicast Neighbor Solicitation to the router's
  link-local address.

In the next paragraph, make "Router Solicitations" singular.  The
first paragraph in this section has a MUST requirement that the host
only send one Router Solicitation.

In section 4.5.1, I am baffled by the last paragraph.  No DHCPv6
address is used anywhere else in the probe NS message and I can think
of no reason why "The probing node SHOULD include a Source link-layer
address option in the probe messages if the address was obtained using
DHCPv6".

Section 4.6 is somewhat problematic, in that a host is expected to use
a Confirm message if it already has assigned addresses and a Solicit
message if not.  Thinking about the problem a little, I would suggest
turning the solution around as follows:

* Send a Solicit message
* Compare the addresses in the Advertise message to the addresses in
  the SDAT
* If a match is found, assume connection to the corresponding link;
  otherwise
* Complete the DHCPv6 message exchange with a Request and wait for the
  Reply

Otherwise, the host will need to send a Confirm message for each of
candidate links and a Solicit message in case it is attached to a new
link.

In section 4.7, 2nd para, if the host receives an RA, why wouldn't it 
just use
the current info in the RA; why would it try to reuse any cached info
from a previous attachment?

Also in the same para, what does it mean to receive a "DHCPv6 message [...]
which contains prefixes that intersect with those previously
advertised by a known router"?  A DHCPv6 message contains assigned
addresses  and other configuration information, but no prefixes.  I'm
guessing the idea is to use the DHCPv6 response as an optimization, in
case it is received before any NA or RA messages.  If I have that
right, then the check would have to be that the set of addresses in
the DHCPv6 message matches the set of previously assigned addresses
associated with the probed router.

Comment:
[2009-11-19] The authors should take a pass over the entire document to 
confirm that all descriptions of the purpose of this mechanism is to 
determine if the host has reattached to *any* previously attached link, 
rather than determining if the host has reattached to the link the host 
just left.

For example:

4.  Host Operations

  When a host has an existing configuration for IP address prefixes and
  next hop routing, it may be disconnected from its link-layer, and
  then subsequently reconnect the link-layer on the same interface.

  When the link-layer becomes available again, it is important to
  determine whether the existing addressing and routing configuration
  are still valid.

  In order to determine this, the host performs the detecting network
  attachment procedure.

This document describes more than just detecting change; it describes 
how to find any link the host to which the host might have been 
previously connected.

In the Introduction:

Why do

  "Hosts require procedures to simply and reliably identify if they have
  moved to a different IP network"

I think all of the text in the first paragraph of the introduction is
more or less at odds with the rest of the document.  Moving to a
different IP network is not what this document is about.  The
machinery in this document identifies if a host reattaches to a link
to which it has been previously attached.  It accomplishes that result
by determining if it has reachability to a router it has previously
used as a default router.  If the host determines it has been
previously attached to its current link, it reuses the previously used
addresses and other configuration information.

Similarly, section 2.1 has several goals that mention "link change"
when, in fact, Simple DNA is all about determining link reattachment.

Section 2.2:

  When a host moves to a completely new link that
  is previously unknown, the performance of the Simple DNA protocol
  will be identical to that using standard neighbor discovery
  procedures [RFC4861].

But, section 4.6 suggests initiating DHCPv6 before receiving an RA,
which reduces latency in completing DHCPv6 transaction for address
assignment on a new link.

Section 2.4:

  Since simple DNA does not modify the
  DHCPv6 protocol or state machine, the operation of DHCPv6 is
  unchanged.

Not true.  Simple DNA hanges the timing of DHCPv6 transmission and
uses Solicit when Confirm would be appropriate.

In section 2.5, if assumption 1 does not hold, a host may make an
incorrect determination of which link it has attached to.

In section 4, the second paragraph describes reattaching to the same
link, while Simple DNA determines whether the host has reattached to
*any* link to which it has previously been attached.

In section 4.5.2, is there any difference between this RS message
contents and the RS message contents specified in RFC 4861?  If there
is no difference, just reference the appropriate section of RFC 4861.

There should be some text somewhere about when info is cached in the
SDAT and when info is flushed from the SDAT.

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 20 Nov 2009 05:30:13 -0800

Jari said:

[BA] Where SEND is in use, DNA *does* provide positive, secure
authentication of the router(s) on the network.  Also, the procedures
of Section 4.7.1 ensure that DNA does not override secure mechanisms
available on a network, such as DHCPv6 security or SEND.   Therefore,
DNA provides security equivalent to existing procedures. While it's 
true that a host should not make security decisions based on insecure
mechanisms (e.g. insecure DHCPv6 or RS/RA), that advice is not unique
to simple DNA. 

[BA] This is fine; existing implementations typically have such a limit.

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 20 Nov 2009 05:37:20 -0800

I believe that many of Ralph's issues below are the result of poor wording
in the document. 

The draft specifically says that it does not change the DHCPv6
protocol, state machine or timers, so that any situation in which
there is an implied DHCPv6 change represents an error. 

So if a host delays transmission of an initial DHCPv6 message that 
should still be the case with DNA.   Also, the draft should not 
change the retransmission rules for DHCPv6.  The paragraph in question,
(which is not well worded) was intended to refer only to NS retransmission.

With respect to the M/O bits, the draft should not change the behavior
of an implementation.  So if an implementation ignores the M/O bits
(as some do), then that behavior should continue.  If it
doesn't ignore them, then it will continue to take them into account as
it did before.  

Also, DNA does not change the assumptions which DHCPv6 uses to obtain
an address. If DHCPv6 would normally attempt to confirm a previously 
held address, it should continue to do so;  if it would normally 
attempt to obtain a new address, it will do that instead.  

Given the above, DHCPv6 and DNA largely operate as "ships in the 
night";  the only interaction comes when the two procedures come
to different conclusions, in which case the text in Section 4.7.1
comes into play.

---

From: Ralph Droms <[email-masked]>
Date: Fri, 20 Nov 2009 09:23:10 -0500

Bernard - thanks for the clarifications; I've included some comments  
inline.

Also adding dhc WG for comments.

> there is an implied DHCPv6 change represents an error.

It makes sense to me that DHCPv6 would not be changed by this  
document.  DHCPv6 already has a mechanism through which a host can  
determine, in one DHCPv6 message exchange, if it has reattached to its  
most recently attached link.  If the host has moved to a new link, an  
additional 4 message exchange (possibly optimized to 2 messages) is  
necessary to get configuration information for the new link.

In addition to the text that may imply skipping an initial delay when  
sending an initial DHCPv6 message, the third paragraph of section 4.6  
of this document changes the DHCPv6 protocol by specifying that a host  
always send a Solicit message first, possibly including addresses from  
previously visited links as hints.  I think the text about this step  
is a little fuzzy about which addresses should be sent and how they  
should be sent.

I could imagine an argument for a change to DHCPv6 that requires the  
host to send a Confirm message for each of its currently valid  
addresses and a Solicit message, all in a burst, to probe all possible  
links in parallel, rather than just checking for reattachment to the  
most recently attached link.  However, it would be a significant  
change to DHCPv6 that has the potential for significant load on the  
DHCPv6 service.

Another link between Simple DNA and DHCPv6 comes to mind at this  
point.  Here is the second paragraph of section 4.7:

    On reception of a Router Advertisement or advertising DHCPv6 message
    (a REPLY or ADVERTISE) which contains prefixes that intersect with
    those previously advertised by a known router, the host utilizes the
    configuration associated with the detected network.

What, exactly, does "utilize the configuration" mean, in relation to  
DHCPv6?  Does the host use any DHCPv6-assigned addresses without  
sending a Confirm message to the DHCPv6 service?  If the host has not  
reattached to its most recently attached link, presumably the host  
will have received a NAK from the DHCPv6 service from its initial  
Confirm (which checked just the most recently attached link).   
Depending on the timing, the host may have already initiated a DHCPv6  
message exchange for the current link.

Also, this paragraph specifies "prefixes that intersect with those  
previously advertised by a known router".  Suppose the set of prefixes  
intersects but is not identical to those previously advertised?  I  
assume the host uses the newly received configuration.  But, by now  
the host has all the current configuration information from its local  
router, so what's the point?

> (which is not well worded) was intended to refer only to NS  

OK.

> doesn't ignore them, then it will continue to take them into account  

OK.

> attempt to obtain a new address, it will do that instead.

As I mentioned above, I don't think the behavior you describe here is  
currently described in the document.

> to different conclusions, in which case the text in Section 4.7.1

OK.

- Ralph

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 20 Nov 2009 08:39:47 -0800

> I believe that many of Ralph's issues below are the result of poor  
> wording in the document.
>

"It makes sense to me that DHCPv6 would not be changed by this  
document.  DHCPv6 already has a mechanism through which a host can  
determine, in one DHCPv6 message exchange, if it has reattached to its  
most recently attached link.  If the host has moved to a new link, an  
additional 4 message exchange (possibly optimized to 2 messages) is  
necessary to get configuration information for the new link."

[BA] Right.  That mechanism should be used as is, with no changes.

"In addition to the text that may imply skipping an initial delay when  
should be sent."

[BA] The contents of DHCPv6 packets shouldn't be dependent on any aspect of
DNA. 
For example, DNA shouldn't influence whether a Solicit message is sent first
nor
what addresses are used as hints.  Whatever any implementation already
does should be left alone.  After all, DNA is just an optimization.  

"I could imagine an argument for a change to DHCPv6 that requires the  
DHCPv6 service."

[BA] I don't see a need to change DHCPv6, particularly if this would
create potential problems. 

"Another link between Simple DNA and DHCPv6 comes to mind at this  
point.  Here is the second paragraph of section 4.7:

message exchange for the current link."

[BA] I have no idea what this paragraph means (or even why it is necessary).

Shouldn't a host just do what it would normally do in response to these
messages?  After all, DNA is only really about use of neighbor discovery,
not RS/RA or DHCPv6. 

"Also, this paragraph specifies "prefixes that intersect with those  
previously advertised by a known router".  Suppose the set of prefixes  
intersects but is not identical to those previously advertised?  I  
assume the host uses the newly received configuration.  But, by now  
the host has all the current configuration information from its local  
router, so what's the point?"

[BA] As far as I can see, the only case worth additional discussion is
the one in which there are prefixes that don't intersect. 

"As I mentioned above, I don't think the behavior you describe here is  
currently described in the document."

[BA] Right.  My take is that this (and other DHCPv6 changes you mention) 
are unnecessary and should be removed.

---

From: Ralph Droms <[email-masked]>
Date: Fri, 20 Nov 2009 12:13:59 -0500

So, would this be an accurate description of Simple DNA:

* Send NS for each candidate link to the default router for that link
* Initiate RS/RA exchange as specified in RFC 4861
* Initiate DHCPv6 exchange as specified in RFC 3315

* If an NA is received, used cached info for corresponding link from  
SDAT
* Process any received RAs as specified in RFC 4861
* Use info from DHCPv6 exchange as specified in RFC 3315
* Info from RA and/or DHCPv6 overrides any reused cached info based on  
NA

- Ralph

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 20 Nov 2009 10:15:07 -0800

"So, would this be an accurate description of Simple DNA:

* If an NA is received, used cached info for corresponding link from  
SDAT
* Process any received RAs as specified in RFC 4861
* Use info from DHCPv6 exchange as specified in RFC 3315
* Info from RA and/or DHCPv6 overrides any reused cached info based on NA"

[BA] I believe so, yes.  Aside from the DHCPv6 issues, there were a few
deviations with respect to RS/RA that were raised in the IESG review. 
I think we need to look at those carefully as well.

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 20 Nov 2009 10:35:57 -0800

One potential wrinkle occurs in the case where the NS/NA, RS/RA and DHCPv6
exchanges have unequal levels of security.  For example, Section 4.7.1
states that if the NS/NA is secured with SEND and the DHCPv6 exchange is
not, then DNA takes priority.  However, where there are equal levels of
security (or insecurity), then I believe DNA should work as per below. 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Friday, November 20, 2009 10:15 AM
To: 'Ralph Droms'
Cc: 'DNA'; [email-masked]; 'Suresh Krishnan (QB/EMC)';
[email-masked]; 'Jari Arkko'; 'IESG IESG'; 'dhc WG'
Subject: [DNA] RE: DNA and DHCPv6