Subject: [Gen-art] Gen-ART review of draft-ietf-msec-ipsec-extensions-06.txt

From: Miguel Garcia <[email-masked]>
Date: Thu, 22 Nov 2007 14:12:18 +0200

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-msec-ipsec-extensions-06.txt
Reviewer: Miguel Garcia <[email-masked]>
Review Date: 2007-11-22	
IETF LC End Date: 2007-11-23

Summary: The document s ready fr publication is a standards track RFC

Comments: The document is very well written. I have a comment and a nit. 
Treat them at your own discretion.

1) Section 4.2.1 the leading edge IPsec SA. There is a paragraph that 
describes how to send the RKE multicast with new keying material. The 
text says:

    - After waiting a sufficiently long enough period such that all of
      the Group Members have processed the RKE multicast, the Group
      Sender begins to transmit using the leading edge IPsec SA with
      its data encrypted by the new keying material. Only authorized
      Group Members can decrypt these IPsec SA multicast transmissions.
      The time delay that a Group Sender waits before starting its
      first leading edge SA transmission is a GKM/IPsec policy
      parameter. This value SHOULD be configurable at the Group Owner
      management interface on a per group basis.

The comment is: I think the draft should provide guidelines with respect 
the duration of "long enough period" that it refers. Are we speaking 
about seconds, minutes, hours, or days? What are the input variables 
that this value depends on? Does the value depend on the number of group 
members, the distance among them, or something else? I can see what are 
the implications of selecting a short value for this period of time, but 
I don't know what are the implications for selecting a very high value. 
I think this is important to provide these guidelines, otherwise, if the 
value is short and a host has not received the new keying material when 
the first packet arrives, it will be hard, if not impossible to trace 
the error.

The recommendation is to add some discussion that can help people to 
select either the default or actual values. The discussion should answer 
the questions I indicated above.

2) According to the RFC Editor, an abstract should not contain citations:

Source: http://www.rfc-editor.org/policy.html#policy.abstract

"An Abstract should be complete in itself; it should not contain 
citations unless they are completely defined within the Abstract. "

This applies to the occurrence of "[RFC4301]" in the abstract.

/Miguel
-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Brian Weis <[email-masked]>
Date: Tue, 27 Nov 2007 11:10:21 -0800

Hi Miguel,

Thank you for your careful review. We'll address comment 1) by adding  
a paragraph containing guidance, as you suggest. Both comments will  
be addressed in the next draft.

Brian

On Nov 22, 2007, at 4:12 AM, Miguel Garcia wrote:

> Comments: The document is very well written. I have a comment and a  
> nit. Treat them at your own discretion.
>
> 1) Section 4.2.1 the leading edge IPsec SA. There is a paragraph  
> that describes how to send the RKE multicast with new keying  
> material. The text says:
>
> The comment is: I think the draft should provide guidelines with  
> respect the duration of "long enough period" that it refers. Are we  
> speaking about seconds, minutes, hours, or days? What are the input  
> variables that this value depends on? Does the value depend on the  
> number of group members, the distance among them, or something  
> else? I can see what are the implications of selecting a short  
> value for this period of time, but I don't know what are the  
> implications for selecting a very high value. I think this is  
> important to provide these guidelines, otherwise, if the value is  
> short and a host has not received the new keying material when the  
> first packet arrives, it will be hard, if not impossible to trace  
> the error.
>
> The recommendation is to add some discussion that can help people  
> to select either the default or actual values. The discussion  
> should answer the questions I indicated above.
>
>

-- 
Brian Weis
Advanced Security Development, Security Technology Group, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]