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

From: Suresh Krishnan <[email-masked]>
Date: Wed, 9 Dec 2009 19:13:25 -0500

Hi Jari,
   Thank you for setting a good way forward with this document and sorry 
for the delayed response. Please see my responses inline.

On 09-11-20 03:39 AM, Jari Arkko wrote:
> 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.

OK. Since a new rev is needed anyway, I will update the draft itself so 
that the RFC Ed note is not required.

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

Will do.

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

Will add this text.

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

Will do.

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

I have identified a bunch of SHOULDs that need to be changed to MUSTs. I 
will try to add explanatory text to the other SHOULDs.

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

I will go over the document and change/remove any text that insinuates 
that simple dna changes either DHCPv6 or RFC4861 procedures in any way. 
That should resolve most of the concerns Ralph has raised in this review.

Thanks
Suresh

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 9 Dec 2009 17:04:25 -0800

>   known to be physically secure, and proceed to abandon cryptographic

This text doesn't make sense.  In the case where DNA is based on SEND, DNA
does provide positive,
secure authentication of the router(s) on the network.  Also, the document
describes how 
secure address determination, where present, takes precedence over DNA.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 10 Dec 2009 18:51:57 +0200

Bernard,

> secure address determination, where present, takes precedence over DNA. 

Ok. How about this:

"Unless SEND or other form of secure address configuration is used, 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 alone. 
In particular, it MUST NOT decide it has rejoined a network known to be 
physically secure, and proceed to abandon cryptographic protection."

Jari

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 10 Dec 2009 08:57:48 -0800

This is fine.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 10 Dec 2009 19:08:02 +0200

Ok. Suresh, can you make this a part of the new version? Thanks.

Jari

---

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Dec 2009 11:08:31 -0600

On Dec 10, 2009, at 10:51 AM, Jari Arkko wrote:
> In particular, it MUST NOT decide it has rejoined a network known to be physically secure, and proceed to abandon cryptographic protection.

I really don't like this language, because it implies that there is such a thing as a network that's physically secure, and because it suggests that there are networks on which secure protocols need not be run.   Recent history would suggest otherwise (see yesterday's articles about penetration of ATM networks, for instance).

I would rather see something like this:

In particular, it MUST NOT decide that it has moved from an untrusted to a trusted network, and MUST NOT make any security decisions that depend on the determination that such a transition has occurred.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 10 Dec 2009 19:10:04 +0200

Thanks. This is better. Suresh, more text for you to include...

Jari

Ted Lemon wrote:
> _______________________________________________
> dna mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dna
>
>

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 10 Dec 2009 15:41:44 -0500

Hi Jari/Ted/Bernard,
  Sounds good. I will add the following text to the security 
considerations section.

Unless SEND or other form of secure address configuration is used, 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 alone.
In particular, it MUST NOT decide that it has moved from an untrusted to 
a trusted network, and MUST NOT make any security decisions that depend 
on the determination that such a transition has occurred.

Thanks
Suresh

---

From: Jari Arkko <[email-masked]>
Date: Fri, 11 Dec 2009 09:51:04 +0200

Your plans sound good, Suresh. Thanks.

Jari

Suresh Krishnan wrote:
> Hi Jari,
>   Thank you for setting a good way forward with this document and 
> sorry for the delayed response. Please see my responses inline.
>
> OK. Since a new rev is needed anyway, I will update the draft itself 
> so that the RFC Ed note is not required.
>
>>
>> 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.
>>
>> 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.
>>
>> 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.
>
> I have identified a bunch of SHOULDs that need to be changed to MUSTs. 
> I will try to add explanatory text to the other SHOULDs.
>
>>
>> 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:
>
> that simple dna changes either DHCPv6 or RFC4861 procedures in any 
> way. That should resolve most of the concerns Ralph has raised in this 
> review.
>
> Thanks
> Suresh
>
>