Subject: Re: [secdir] SecDir review of draft-ietf-dna-simple-11

From: Suresh Krishnan <[email-masked]>
Date: Wed, 9 Dec 2009 18:34:32 -0500

Hi Yaron,
     Thanks for your detailed review. Sorry for the delayed response.

On 09-11-18 12:56 PM, Yaron Sheffer wrote:
> The Security Considerations are focused on one specific aspect, namely 
> the use of SEND. I think we should make clear here that none of the DNA 
> operations by themselves add any measure of security, unless SEND is 
> actually used. Specifically, I suggest to add the text: “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.”

Sounds good. Will add the text into the Security considerations.

> 
>  
> 
> Other Comments
> 
>  
> 
> 4.1: DUID - is this the host’s DUID or the router's? Per RFC 3315, both 
> have such a value.

The client's DUID. This section probably needs a rework anyway to add a 
few more fields. I will clarify this in the next rev.

> 
> 4.3: "all currently configured IP addresses" - but only for this 
> physical interface, right?

Yes. Propose rewording to

"After the indication is received on an interface, the host considers 
all  (non-tentative) IP addresses currently configured on this interface 
to be deprecated until the change detection process completes."

> 
> 4.8: why is no DAD performed? Someone else might have joined the network 
> while I was disconnected, and has a duplicate of my address.

One reason is that this issue can already occur in current networks due 
to network partioning and merging, DAD packet loss etc. We attempted to 
quantify the conditions under which DAD should or should not be 
performed but there was strong working group consensus against doing so 
and strong consensus for adding this current text.

Thanks
Suresh

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 28 Dec 2009 13:54:38 +0200

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This document presents a conceptual framework for aggregating and composing network performance measurements in service provider networks.

I am entirely happy with the Security Considerations section, in fact I believe it is somewhat of an overkill for a document at this level of abstraction.

Thanks,
	Yaron