Subject: Re: [Gen-art] Gen-ART telechat review of draft-ietf-ipsecme-traffic-visibility-11

From: "McCann Peter-A001034" <[email-masked]>
Date: Wed, 16 Dec 2009 11:22:51 -0500

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
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html> ). 

Please wait for direction from your document shepherd or AD before
posting a new version of the draft. 

Document: draft-ietf-ipsecme-traffic-visibility-11
Reviewer: Pete McCann
Review Date: 16 Dec 2009
IESG Telechat date: 17 Dec 2009 

Summary: Ready

Major issues: none
Minor issues: none
Nits/editorial comments: none

This version addresses my previous comment adequately.

-Pete

McCann Peter-A001034 wrote:
> 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
> <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-ipsecme-traffic-visibility-09
> Reviewer: Pete McCann
> Review Date: 2009-10-29
> IETF LC End Date: 2009-10-28
> IESG Telechat date: unknown
> 
> Summary: One minor issue to discuss
> 
> Major issues: none
> 
> Minor issues:
> 
> Section 2:
>    As can be seen, the WESP format extends the standard ESP header
>    by the first 4 octets for IPv4 and by 8 octets for IPv6. The
>    WESP header is integrity protected, along with all the fields
>    specified for ESP in RFC 4303.
> Normally ESP wouldn't need to process encapsulation headers that
> appear prior to the SPI.  Won't this require modification of the ESP
> implementation, possibly breaking its modularity?  Would it be
> problematic for certain algorithms to include this data? It might be
> good to state that.   
> 
> Nits/editorial comments: none

---

From: Scott C Moonen <[email-masked]>
Date: Wed, 16 Dec 2009 13:30:07 -0500

Peter, your comment below made me go back and re-read the draft.  Section 
2.2 of this draft makes this statement:

   In the diagrams below, "WESP ICV" refers to the ICV computation as
   modified by this specification. Namely, the ESP ICV computation is
   augmented to include the four octets that constitute the WESP header.
   Otherwise, the ICV computation is as specified by ESP [RFC4303].

In general I wonder if this paragraph should be beefed up a bit.  Tables 1 
and 2 of RFC 4303 go into specific detail as to the order in which things 
are included in the ICV calculation, and simply saying "augmented" leaves 
some ambiguity as to where the WESP data appears.  This paragraph should 
also probably say "four or eight" instead of "four".  Finally, I wonder if 
the document should go into even more detail on how the WESP header is 
authenticated for combined-mode algorithms.  Typically those algorithms 
have "additional authentication data", and I wonder if we should document 
specifically how the WESP header appears in the AAD for currently 
specified algorithms, and also document the expectation that future 
combined-mode RFCs should explicitly mention how a WESP header would 
appear in their AAD.

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

From:
"McCann Peter-A001034" <[email-masked]>
To:
<[email-masked]>, 
<[email-masked]>
Cc:
[email-masked]
Date:
12/16/2009 12:20 PM
Subject:
Re: [IPsec] Gen-ART telechat review of 
draft-ietf-ipsecme-traffic-visibility-11

Summary: Ready

Major issues: none
Minor issues: none

-Pete

> Nits/editorial comments: none

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Wed, 16 Dec 2009 13:45:18 -0500

Hi, Scott,

Your comments make sense; I had assumed that "augmented" meant 
that the bytes would be logically prepended to the existing ESP
data before the ICV was calculated, and that this notion was
well-defined wrt existing ESP ICV methods.  I am not as familiar
with the combined mode AAD and how that works, so I'd defer to
your and the authors' judgement on whether additional specification
is needed.

I do agree that the "four" should be changed.  We should also keep
in mind the UDP encapsulation described in section 2.1, which adds
a header of 16 bytes, so we could say, "four, eight, or sixteen".

-Pete

Scott C Moonen wrote:
> Peter, your comment below made me go back and re-read the draft. 
> Section 2.2 of this draft makes this statement: 
> 
>    augmented to include the four octets that constitute the WESP
>    header. Otherwise, the ICV computation is as specified by ESP
> [RFC4303]. 
> 
> In general I wonder if this paragraph should be beefed up a bit. 
> Tables 1 and 2 of RFC 4303 go into specific detail as to the order in
> which things are included in the ICV calculation, and simply saying
> "augmented" leaves some ambiguity as to where the WESP data appears. 
> This paragraph should also probably say "four or eight" instead of
> "four".  Finally, I wonder if the document should go into even more
> detail on how the WESP header is authenticated for combined-mode
> algorithms.  Typically those algorithms have "additional
> authentication data", and I wonder if we should document specifically
> how the WESP header appears in the AAD for currently specified
> algorithms, and also document the expectation that future
> <http://www.linkedin.com/in/smoonen>  
> 
> 
> 
> From: 	"McCann Peter-A001034" <[email-masked]>
> To: 	<[email-masked]>,
> Cc: 	[email-masked]
> Date: 	12/16/2009 12:20 PM
> Subject: 	Re: [IPsec] Gen-ART telechat review of       
> ________________________________
> 
> 
> 
> 
> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>
> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html
> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html> > ).    
> 
>> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>
>> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html
>> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html> > ).  
>> 
> <https://www.ietf.org/mailman/listinfo/ipsec>

---

From: "Grewal, Ken" <[email-masked]>
Date: Thu, 17 Dec 2009 10:19:00 -0700

Hi Scott, Peter,
This text was kept simple deliberately, so we would not need to cover every single case of different algorithm permutations.  
The intention was as Peter indicates below "... "augmented" meant that the bytes would be logically prepended to the existing ESP data before the ICV was calculated...".

This is the same intention for AEAD algorithms, where the WESP header would be prepended to the ESP header and part of the AAD. 

If you think it adds additional clarity by explicitly specifying these 'rules', then we could certainly elaborate on the section as you describe below. 

And I agree that the '"four" should be changed' comment, which was an oversight due to last minute addition for IPv6 padding requirements. 

Thanks, 
- Ken

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of McCann Peter-A001034
>Sent: Wednesday, December 16, 2009 10:45 AM
>To: Scott C Moonen
>Cc: [email-masked]; [email-masked]; [email-masked]; draft-
>[email-masked]
>Subject: Re: [IPsec] WESP and combined-mode algorithms
>
>Hi, Scott,
>