Subject: [dna] AD review of draft-ietf-dna-simple

From: Jari Arkko <[email-masked]>
Date: Thu, 09 Jul 2009 15:28:45 +0300

Suresh,

I have reviewed this draft. Overall, the draft was easy to read and well 
written. I have no problem with the specified algorithms. However, the 
draft appears to contain a fair amount of extra material on Fast RAs and 
the full-blown dna-protocol that WG worked earlier on. These need to be 
removed; the specification can and should stand on its own, and not 
depend on these other components. In addition, there are a few technical 
issues, including the use of SLLA and lack of clear specification for a 
general purpose implementation wrt configuration.

Here are my specific comments:

Substantial:

> The probing node SHOULD include a Source link-layer address option in 
> the probe messages.  If the node believes that the source address of 
> the NS may not be unique on the newly attached link, it MAY omit the 
> Source link-layer address option in the probe messages.

I would like to understand this better.  How does a general purpose 
operating system implementation deal with the above? How does it know 
that "the source address of the NS may not be unique"?

AFAICT, if you omit the SLLA and no link change happened, then most 
likely the router will remember your NC anyway, and be able to respond. 
However, if it does not remember you, a new NS/NA would be required, but 
DNA would still succeed, albeit a bit slower.

However, if the host did move to a new link, then including the SLLA 
might cause disruption for another host that already holds the same 
address but uses a different link layer address.

Why is the recommendation written as it is above? Is the assumption that 
colliding addresses are so rare that the optimization makes sense? On 
the other hand, it would appear that even without the SLLA DNA would 
still work in most cases.

In any case, I don't think we can require general purpose 
implementations to assess the likelihood of collisions. Perhaps it would 
be easier to require that by default, no SLLA is included and that only 
through specific configuration option the SLLA use can be turned on and 
DNA made to operate faster/more reliably.

>    For the purpose of sending neighbor solicitations to previous
>    routers, the host first needs to pick a subset of operable IPv6
>    addresses (candidate set) that it wishes to use.  How this subset of
>    addresses is picked is based on host configuration. e.g.  The host
>    may select configured addresses from each of zero, one or two
>    previously connected links.

Please specify a default strategy. E.g., "How this subset of addresses 
is picked is based on host configuration. By default the host should 
select configured addresses from two previously connected links."

> Where flooding may cause performance issues within the LAN, host 
> SHOULD limit the number of unicast solicitations.

Again, the guidance for general purpose implementations in inadequate. 
Please specify a default strategy. I believe limiting the number of 
unicast solicitations to some small number (4?) by default is adequate 
(there are a number of messages on a new link even on DNAv4 and regular ND).

>    The probing node SHOULD NOT include a Source link-layer address
>    option if it has not performed duplicate address detection [RFC4862],
>    for the source address of the NS, on the newly attached link.
>

Performed DAD, when? Presumably it has been performed when the address 
first configured, no? And since DNA is the first thing that runs after a 
link change, DAD has not been run at this point either. So what does 
your recommendation really mean here? Never include SLLA?

In any case, at this point we do not yet *know* if we are on a newly 
attached link or not. Therefore, we do not know if we've run DAD in the 
past on this link.

Please clarify.

>    Hosts checking their network attachment are unsure of their address
>    status, and may be using Tentative link-layer addressing information
>    in their router or neighbour solicitations.
>
>    A router which desires to support hosts' DNA operations MUST process
>    Tentative Options from unicast source addressed Router and Neighbour
>    Solicitations, as described in [I-D.ietf-dna-tentative].

This is the first time dna-tentative is referenced in this document. I 
wonder if there's really a need to have a normative reference, or even 
mention this.

> 7. Constants
>
>
>    These constants are described as in [I-D.ietf-dna-protocol].
>
>       UNICAST_RA_INTERVAL
>
>          Definition: The interval corresponding to the maximum average
>          rate of Router Solicitations that the router is prepared to
>          service with unicast responses.  This is the interval at which
>          the token bucket controlling the unicast responses is
>          replenished.
>
>          Value: 50 milliseconds
>
>       MAX_UNICAST_RA_BURST
>
>          Definition: The maximum size burst of Router Solicitations that
>          the router is prepared to service with unicast responses.  This
>          is the maximum number of tokens allowed in the token bucket
>          controlling the unicast responses.
>
>          Value: 20
>

None of these appear to have anything to do with the Simple DNA 
procedure. Please remove. The only item that I can see be of relevance 
in this section is SEND_NA_GRACE_TIME.

>    When providing fast responses to router solicitations, it is possible
>    to cause collisions with other signaling packets on contention based
>    media.  This can cause repeated packet loss or delay when multiple
>    routers are present on the link.
>
>    As such the fast router advertisement system is NOT RECOMMENDED in
>    this form for media which are susceptible to collision loss.  Such
>    environments may be better served using the procedures defined in
>    [I-D.ietf-dna-protocol].

This does not appear to have anything to do with Simple DNA either 
(router-side fast responses are not a subject of this specification). 
Delete?

>    The host MAY delay SEND_NA_GRACE_TIME after transmission before
>    adopting a new default router, if it is operating on a network where
>    there is significant threat of RA spoofing.

I would simply say that this delay MAY be imposed when the host's 
current default router is a SEND-secured one. This prevents the 
downgrade from SEND to non-SEND, but does not require any configuration, 
and it doesn't slow things down when you were already using a non-SEND 
router.

>    It is easy for hosts soliciting without SEND to deplete a SEND
>    router's fast advertisement token buckets, and consume additional
>    bandwidth.  As such, a router MAY choose to preserve a portion of
>    their token bucket to serve solicitations with SEND signatures.

Again, this has very little to do with this specification. Move this to 
the fast RA spec instead.

Editorial:

Move draft-ietf-dna-protocol to informative references.

> After the indication is received, the host considers all currently 
> configured (non-tentative) IP addresses to as deprecated until the 
> change detection process completes.

s/to as/to be/

> addresses is picked is based on host configuration. e.g.  The host

s/The/the/

> If systems do not meet these assumptions or if systems seek 
> deterministic change detection operations they are directed to follow 
> the complete dna procedure as defined in [I-D.ietf-dna-protocol].
I would just delete this. I do not think we want to make what sounds 
like a fairly strong recommendation.

Section 4.5.1 mentions that there are no options, while Setion 4.5.2 
does not.

>    message contains an Identity Addociation for either a Temporary
Association?

Jari

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 9 Jul 2009 10:20:53 -0700

> that "the source address of the NS may not be unique"?

The goal of DNA is not only to detect network attachment, but also to 
seed the ND cache so as to immediately enable incoming and outgoing 
communications.  By including the SLLA in unicast probe messages, the
node can seed the ND cache of the router tgo enable communications
in the opposite direction.  

> likely the router will remember your NC anyway, and be able to respond. 

Only if the ND cache entry had not expired.   Remember, the biggest win
for DNA is when moving between links. 

> address but uses a different link layer address.

The probes are sent to a unicast IP and MAC address.  Therefore they
can only be received if the node moves to a link on which the node has
a valid IP address. 

> still work in most cases.

There are situations in which a node is unlikely to encounter
collisions, and therefore DAD is not required.  One is where the IP address 
was allocated via DHCP, and the lease has not yet expired.  If the DHCP 
server is properly implemented, it will not hand out the same address to 
more than one host.  DNAv4 makes this assumption. 

During development of the draft, there was discussion as to whether there
were other situations in which this assumption could be made as well. 
For example, in situations where an IPv6 address is not manually or
randomly assigned, but is based on a MAC address, would it be 
reasonable to include the SLLA (and also not to do DAD).   As I
recall, the decision was made *not* to override any of the existing
recommendations on DAD.  For consistency's sake then, the SLLA
should not be included in those same cases. 

> implementations to assess the likelihood of collisions. 

Sure -- but the document should be written so as to clearly spell
out the situations under which the SLLA is included.  Those are the
same circumstances in which the document should enable DAD to
be avoided.  However, currently the document is not consistent in
this regard. 

> Perhaps it would  be easier to require that by default, no SLLA is included 
> and that only  through specific configuration option the SLLA use can be turned on and 

If the SLLA is only included in situations where DAD can be avoided, then
I don't think this is an issue.  That's how DNAv4 works. 

> select configured addresses from two previously connected links."

DNAv4 enables the host to send probes to all routers representing links
with valid IP addresses.  There is no language about subsets.  This hasn't
been an issue in practice, since a host will typically not have a large number
of valid IP addresses.  So I'd prefer that this language be removed entirely. 

> > SHOULD limit the number of unicast solicitations.

This is a red herring that should have been removed from the document long
ago.  The initial deployment of DNAv4 uncovered some AP implementations
that were non-compliant with IEEE 802.1D, but those issues have long since
been fixed.  There is no known "flooding" issue at this time. 

> your recommendation really mean here? Never include SLLA?

It means that you only include SLLA in situations in which DAD can be
avoided (such as where DHCPv6 is in use). 
 
> attached link or not. Therefore, we do not know if we've run DAD in the 

The probe is constructed to test whether the node is on the link or not. 
If the address was assigned by DHCPv6 on the link, then the probe can
omit the SLLA and if the probe succeeds, then DAD is not required. 

> wonder if there's really a need to have a normative reference, or even 

I don't think so, since the WG decided to not modify DAD procedures
except for the DHCPv6 case. 

> in this section is SEND_NA_GRACE_TIME.

I agree. Not sure why this material remains in the document. 

> (router-side fast responses are not a subject of this specification). 

Yup. 

> Move draft-ietf-dna-protocol to informative references.

Right.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 09 Jul 2009 21:04:59 +0300

Bernard,

Thanks for your response. I think I understand the logic better now. 
Suresh, can we change the draft as suggested by Bernard?

Jari

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 09 Jul 2009 18:24:23 -0400

Hi Jari/Bernard,
   I will try to come up with a new revision incorporating your comments 
by the deadline.

Thanks
Suresh

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 16 Jul 2009 10:38:59 -0700

I think that there are still some issues in the revised draft. 

"

4.5.1.  Neighbor Solicitation messages

   This section describes the contents of the neighbor solicitation
   probe messages sent during the probing procedure.

   Source Address:           A link-local address assigned to the
                             probing host.

   Destination Address:      The link-local address of the router being
                             probed as learnt from the SDAT.

   Hop Limit:                255

   ND Options:

   Target Address:           The link-local address of the router being
                             probed as learnt from the SDAT.

   The probing node SHOULD include a Source link-layer address option in
   the probe messages if the address was obtained using DHCPv6 and the
   lease has not expired.  Otherwise the probing node SHOULD NOT include
   the Source link-layer address option in the probe messages.
"

[BA] This section does not mention the destination MAC address.   Unless that is set to the unicast MAC address of the router, it is possible that the NS could be received by another router using the same linklocal address.  After all, linklocal addresses need not be globally unique. 

"

4.5.2.  Router Solicitation messages

   This section describes the contents of the router solicitation probe
   message sent during the probing procedure.

   Source Address:           A link-local address assigned to the
                             probing host.

   Destination Address:      The all-routers multicast address.

   Hop Limit:                255

   The probing node SHOULD include a Source link-layer address option in
   the probe messages if the address was obtained using DHCPv6 and the
   lease has not expired.  Otherwise the probing node SHOULD NOT include
   the Source link-layer address option in the probe messages.

"

[BA] Including the SSLAO in the RS seems odd because it is sent to a multicast address.  Unlike the NS, the RS is not constructed for a particular router, and therefore its construction should not depend how the address was obtained -- since another router could receive it.  In the case where the address was obtained from DHCPv6, and the host is on one of the probed links, we'd expect the unicast NS to be responded to, and since that does include the SSLAO, I think we're covered. 

4.6.  Sending DHCPv6 probes

   Where the host has acquired addresses from DHCPv6 or the host does
   not have a global prefix, it MAY prefer to use DHCPv6 messages either
   before or simultanously with Neighbour Discovery probing.

[BA] Doing DHCPv6 *before* NS probing does not make sense to me.  Earlier, it is said that NS probing occurs simulataneously with sending the RS, right after "link up".  This sentence seems to contradict that. 

Also, linking DHCPv6 procedures to DNA seems odd.  In DNAv4, it is made clear that DNA did not resut in any changes to DHCPv4 procedures.  Is that the intent here, or does DNA have some impact on how/when DHCPv6 messages are sent? 

4.7.  Response Gathering

   When a responding Neighbour Advertisement is received from a test
   node, the host MUST verify that both the IPv6 and link layer (MAC)
   addresses of the test node match the expected values before utilizing
   the configuration associated with the detected network (prefixes, MTU
   etc.).

[BA] It seems odd to check the MAC address in a response, but not to talk about the destination MAC address in the request. Was this intentional? 

Section 4.9

  If the confirmed address was assigned manually, the implementation SHOULD
   NOT unconfigure the manually assigned address and SHOULD log an error
   about the mismatching prefix.

[BA] Elsewhere the draft talks about stateless autoconfig and DHCPv6-assigned addresses, but not manual assignment.   Is the intent of the document to suggest use of DNAv6 for configuration of manually assigned addresses?  If so, then some of the caveats discussed in the DNAv4 document could apply.   For example, NS probes don't need much if any retransmission because alternatives (RS, DHCPv6) are retransmitted.  But if we are talking about manual assignment, then these alternate mechanisms may not help -- and NS probe retransmission can become more important. 

From: [email-masked]
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Date: Thu, 9 Jul 2009 10:20:53 -0700
Subject: Re: [dna] AD review of draft-ietf-dna-simple

 

Yup. 

Right.

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 16 Jul 2009 18:38:54 -0400

Hi Bernard,
   Thanks for the comments.

On 09-07-16 01:38 PM, Bernard Aboba wrote:
> [BA] This section does not mention the destination MAC address.   Unless 
> that is set to the unicast MAC address of the router, it is possible 
> that the NS could be received by another router using the same linklocal 
> address.  After all, linklocal addresses need not be globally unique.

Agree. I will make this change.

>  
> "
>   
> 
> 
>         *4.5.2**.  Router Solicitation messages*
> 
> 
> 
> [BA] Including the SSLAO in the RS seems odd because it is sent to a 
> multicast address.  Unlike the NS, the RS is not constructed for a 
> particular router, and therefore its construction should not depend how 
> the address was obtained -- since another router could receive it.  In 
> the case where the address was obtained from DHCPv6, and the host is on 
> one of the probed links, we'd expect the unicast NS to be responded to, 
> and since that does include the SSLAO, I think we're covered.

We do not know which probe will succeed first, the RS or the NS, since 
they are sent in parallel. To expedite the proceedings we include the 
SLLAO on the RS. But when we reattach to a known link (which is the case 
we optimize for) the NS will succeed and we probably don't need the 
SLLAO in the RS. I will go ahead and remove this.

>  
> 
> 
>       *4.6**.  Sending DHCPv6 probes*
> 
> 
> 
> [BA] Doing DHCPv6 *before* NS probing does not make sense to 
> me.  Earlier, it is said that NS probing occurs simulataneously with 
> sending the RS, right after "link up".  This sentence seems to 
> contradict that.

It refers to "neighbor discovery" probing, which includes both RS and NS 
probing. Please see below.

>  
> Also, linking DHCPv6 procedures to DNA seems odd.  In DNAv4, it is made 
> clear that DNA did not resut in any changes to DHCPv4 procedures.  Is 
> that the intent here, or does DNA have some impact on how/when DHCPv6 
> messages are sent?

It does not have any impact on when DHCPv6 messages are sent. Would you 
like this text to be removed?

>  
>   
> 
> 
>       *4.7**.  Response Gathering*
> 
> 
> 
> [BA] It seems odd to check the MAC address in a response, but not to 
> talk about the destination MAC address in the request. Was this 
> intentional?

No. I will add the destination MAC address to the request as well.

> [BA] Elsewhere the draft talks about stateless autoconfig and 
> DHCPv6-assigned addresses, but not manual assignment.   Is the intent of 
> the document to suggest use of DNAv6 for configuration of manually 
> assigned addresses?  If so, then some of the caveats discussed in the 
> DNAv4 document could apply.   For example, NS probes don't need much if 
> any retransmission because alternatives (RS, DHCPv6) are retransmitted.  
> But if we are talking about manual assignment, then these alternate 
> mechanisms may not help -- and NS probe retransmission can become more 
> important.

I will try to add more text regarding manually configured addresses.

Thanks
Suresh

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 16 Jul 2009 22:56:22 -0700

> like this text to be removed?

All that needs to be said is that DHCPv6, if it is triggered, occurs in parallel, and that
DNA does not imply any changes to the DHCPv6 protocol or state machine.  It also
would make sense to state that if DHCPv6 completes with a different result, that
(as with RS) this takes precedence over DNA.

> I will try to add more text regarding manually configured addresses.

OK.  The DNAv4 draft talks a bit about manually configured addresses, but my
understanding is that this functionality has not been implemented.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 16 Jul 2009 23:19:45 -0700

That brings up another point -- security.  The DNAv4 document states
that DNA is not appropriate for use in situations where security is
required -- such as where DHCP authentication would be used.  

So if you're looking to secure configuration with SEND or authenticated
DHCPv6, does it make sense to use DNA? 

Subject: RE: [dna] AD review of draft-ietf-dna-simple
Date: Fri, 17 Jul 2009 16:06:16 +1000
From: [email-masked]
To: [email-masked]; [email-masked]
CC: [email-masked]; [email-masked]; [email-masked]

Hi Bernard,
 
Would it be possible to say that if DHCPv6 completes with a different 
value to DNA, it takes precedence
so long as this does not override a SEND advertisement where DHCPv6 
is unauthenticated?
 
Greg Daley
Security Consultant
NetStar Australia Pty Ltd

E-mail: 
[email-masked]
Mobile: +61 401 772 770
Direct: +61 3 8532 
4042
Fax:    +61 3 8532 4032 

  
  From: Bernard Aboba 
  [mailto:[email-masked]] 
Sent: Friday, 17 July 2009 3:56 
  PM
To: Suresh Krishnan
Cc: Jari Arkko; 
  [email-masked]; [email-masked]
Subject: RE: 
  [dna] AD review of draft-ietf-dna-simple

> like this text to be removed?

All that needs to be 
  said is that DHCPv6, if it is triggered, occurs in parallel, and that
DNA 
  does not imply any changes to the DHCPv6 protocol or state machine.  It 
  also
would make sense to state that if DHCPv6 completes with a different 
  result, that
(as with RS) this takes precedence over DNA.

> > any retransmission because 
  alternatives (RS, DHCPv6) are retransmitted. 
> > But if we are 
  talking about manual assignment, then these alternate 
> > mechanisms 
  may not help -- and NS probe retransmission can become more 
  important.
> I will try to add more text regarding 
  manually configured addresses.

OK.  The DNAv4 draft talks a bit 
  about manually configured addresses, but my
understanding is that this 
  functionality has not been implemented.

---

From: "Greg Daley" <[email-masked]>
Date: Fri, 17 Jul 2009 16:06:16 +1000

Hi Bernard,
 
Would it be possible to say that if DHCPv6 completes with a different
value to DNA, it takes precedence
so long as this does not override a SEND advertisement where DHCPv6 is
unauthenticated?

Greg Daley
Security Consultant

E-mail: [email-masked]
Mobile: +61 401 772 770
Direct: +61 3 8532 4042
Fax:    +61 3 8532 4032 

________________________________

	From: Bernard Aboba [mailto:[email-masked]] 
	Sent: Friday, 17 July 2009 3:56 PM
	To: Suresh Krishnan
	Cc: Jari Arkko; [email-masked];
[email-masked]
	Subject: RE: [dna] AD review of draft-ietf-dna-simple

	> like this text to be removed?
	
	All that needs to be said is that DHCPv6, if it is triggered,
occurs in parallel, and that
	DNA does not imply any changes to the DHCPv6 protocol or state
machine.  It also
	would make sense to state that if DHCPv6 completes with a
different result, that
	(as with RS) this takes precedence over DNA.
	
	> I will try to add more text regarding manually configured
addresses.
	
	OK.  The DNAv4 draft talks a bit about manually configured
addresses, but my
	understanding is that this functionality has not been
implemented.