Subject: [IPsec] Roadmap doc updated in response to Gen-ART Review

From: "Frankel, Sheila E." <[email-masked]>
Date: Tue, 10 Aug 2010 13:30:46 -0400

An updated IPsec/IKE roadmap (version 09) was submitted in response to the Gen-ART review. 
Here are the changes that were made in response to that review:

> I found one open issue - Sections 5.4.1 and 5.4.2 mis-state the applicability 
> of combined mode algorithms to IPsec-v2.  All of the other comments in this 
> review are minor.

See below.

> Section 2.2 lists the RFC # range for IPsec-v1.  Please also list the RFC 
> # ranges for IPsec-v2 and IPsec-v3.

The v1 RFCs are mentioned here for completeness, since they are not included
elsewhere. For v2 and v3, added the phrase "see Section 3.1.x for the RFC 
descriptions."

> ** Sections 5.4.1 and 5.4.2 both contain a NOTE stating that combined mode 
> algorithms are "not a feature of IPsec-v2" and hence lists them as N/A.  
> That's not correct.  The correct situation is:
> - Combined mode algorithms for ESP can be negotiated as encryption
>         algorithms (the integrity protection algorithm would typically
>         be omitted proposals that do this).
> - Combined mode algorithms cannot be used with IKEv1, as they're
>         incompatible with its design (see the Introduction section of
>         RFC 5282 for a more detailed explanation).
> Hence the N/A entries for IKEv1 are correct, but both AES-CCM and AES-GCM 
> should be "optional" for ESPv2 (and the NOTE should be revised accordingly).

The roadmap already includes the following statement in Section 5.4: 
   Although ESP-v2 did not originally include combined mode algorithms,
   some IKEv1 implementations have added the capability to negotiate
   combined mode algorithms for use in IPsec SAs; these implementations
   do not include the capability to use combined mode algorithms to
   protect IKE SAs. 

Added the following to the NOTEs for the combined mode algorithms:
  Although some IKEv1/IPsec-v2 implementations include this capability
  (see Section 5.4), it is not part of the protocol.

> Section 5.4.3 - RFC 5282 is based on a combined mode framework in RFC 5116.

RFC 5116 described the underlying framework, but does not mention IKE or IPsec.
Just as this doc does not include the RFCs that define the SHA-1 algorithm or
the HMAC algorithm, it does not include this framework RFC.

> Section 8.4.1 appears to apply to IPsec-v2 only, and not IPsec-v3.  If that 
> is correct, it should be stated.

Added "This document applies only to IKEv1 and IPsec-v2; it does not apply to IKEv2 and IPsec-v3."

> Section 8.8.1 also appears to be IPsec-v2 only, and in addition to stating 
> that should comment that this was not widely adopted, and NAT traversal 
> is the commonly used mechanism to deal with NATs.

Added "Although the model presented here uses terminology from IKEv1, it can be deployed within 
IKEv1, IKEv2, IPsec-v2 and IPsec-v3.

> In Section 9.2.1, "Fibre Channel/SCSI" --> "Fibre Channel".  If you want 
> to cite the RFCs involved, IP over FC is RFC 4338 and FC over IP is RFC 3821.

Deleted "/SCSI" In general, the roadmap only cites IKE/IPsec-related RFCs, but
not the RFCs that define the non-IKE/IPsec underlying protocols. Although
RFC 3821 mentions the use of IKE/IPsec for Fibre Channel, unlike RFC 4595, it
does not alter IKE/IPsec in any way.

> idnits 2.12.04 found some minor nits:

>   ** There are 4 instances of too long lines in the document, the longest one
>      being 3 characters in excess of 72.

Fixed this.

Sheila and Suresh

---

From: <[email-masked]>
Date: Tue, 10 Aug 2010 16:41:38 -0400

Sheila and Suresh,

These changes look good.  The only thing I would have added is a
sentence in Section 8.8.1 to say that RFC 2709's security model has not
been widely adopted, and the more common approach is NAT traversal.
Whether to add this is a matter of editorial taste, as NAT traversal is
covered earlier in the draft (Sections 3.2.1 and 4.1.2.1), so the -09
version of this draft is fine with me

Many thanks for all the time and effort that you've put into this draft.

Thanks,
--David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Frankel, Sheila E.
> Sent: Tuesday, August 10, 2010 1:31 PM
> To: Black, David; [email-masked]; [email-masked];
[email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [IPsec] Roadmap doc updated in response to Gen-ART Review
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec