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

From: Jari Arkko <[email-masked]>
Date: Mon, 24 Aug 2009 10:47:01 +0300

This is just a reminder -- we are very near in getting this document 
shipped. Lets get the final details agreed, a new draft posted so that 
we can focus on other stuff.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 24 Aug 2009 10:47:06 +0300

Suresh,

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

My preference would be to leave explicitly state that DNAv6 does not 
apply to such addresses. I don't really see the use case to begin with...

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 24 Aug 2009 10:52:50 +0300

Bernard, Suresh, Greg,

> 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?

The existing draft already talks about the "stickiness" of SEND 
configuration -- you wait longer to lose your SEND router. I think this 
is sufficient and in line with the thinking in RFC 3971, which 
emphasizes the ability to work in mixed environments.

However, there is no text associated with DHCPv6 security or interaction 
of ND/DHCPv6 security. Perhaps something is needed there as well.

Jari

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 24 Aug 2009 21:16:31 -0700

In DNAv4 we examined the use case of switching between manually configured addresses.   

This is something that could not be done prior to DNAv4, but is possible with it. 

However, it became clear that there were some problems:

1. DNA probe retransmission strategy.  In typical situations little or no retransmission of DNA probes is required, since if the probes are lost, the normal dynamic assignment mechanisms (with their retransmission schemes) will still function.  However, if the address is assigned manually, the dynamic assignment alternative may not be available.  Therefore DNA probe retransmission needs to be more aggressive, or else risk not assigning an address at all, or possibly (see below) assigning the wrong address. 

2. Where an address is assigned manually in one network but dynamically assigned on another, it is necessary for the host to use dynamic assignment mechanisms, in case it turns out to be attached to a network on which dynamic assignment is practiced.  However, when it is attached to the "manual assignment" network using both DNA probes and dynamic assignment, this could result in the host obtaining two valid addresses -- a "manual" and a "dynamic" one.  In that case, the standard advice of "take the dynamically assigned address if it conflicts with the DNA probe result" is no longer valid -- a manually assigned address needs to take priority.  One might also argue that when attached to a "manual" network, dynamic assignment mechanisms should be treated as a confirmed probe, in that once connection to the "manual" network is confirmed, the manual address should be plumbed, and the dynamic address should be thrown away. 

Given these issues, the DNAv4 document cites some of the above concerns and recommends against use for manual addressing.  If and when manual addressing is implemented for DNAv4, we will probably learn enough to provide some guidance about how it can be done effectively.  But we don't appear to have that understanding now. 

My recommendation for the DNAv6 document would be to include a small section outlining the above concerns for DNAv6, indicating that manual addressing is NOT RECOMMENDED.  

> Date: Mon, 24 Aug 2009 10:47:06 +0300
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [dna] AD review of draft-ietf-dna-simple
> 
> Suresh,
>

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 24 Aug 2009 21:25:15 -0700

Jari said: 

> There is no text associated with DHCPv6 security or interaction 

The basic question is how the host should behave in situations where security is available. For example, where SEND is available, but not DHCPv6 security, is it always appropriate to prefer the DHCPv6-assigned address?  One one hand, the address determined from SEND is "more secure";  on the other hand, it is also possible that the DHCPv6-assigned address, albeit without security, is correct (e.g. DHCPv6 server might have lost state and assigned the address to someone else, now suggests another one).  

Where DHCPv6 security is available, but not SEND, it would probably make sense to prefer the DHCPv6-assigned address.  Since the document already says that, much more may not be needed, except to point out that the host could end up with an "insecure" address for a short period of time.

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 25 Aug 2009 20:57:13 -0400

Hi Jari,
   We will try to ship out a new revision next week after we agree on 
the proposed fixes.

Thanks
Suresh