Subject: [IPsec] Comments on draft-ietf-ipsecme-roadmap-00

From: Yaron Sheffer <[email-masked]>
Date: Tue, 13 Jan 2009 18:14:47 +0200

Hi Sheila, Suresh,

Overall, this is a very impressive document, both clear and extensive. Thanks so much!

Here are some comments, and some suggested text. Everyone on the list is most welcome to suggest text for their favorite RFCs.

- 2.1: I suggest to unify the 3 Algorithm boxes in the figure into one, "Algorithms". There are also documents describing HMAC, and describing D-H groups.
- 2.2: for the "earlier version", please mention the RFC numbers (1825-1829).
- 2.2.1: but in IPsec-v3 you still need the dest address to distinguish SAs, e.g. if you're on a gateway.
- 2.3.1: why use the older term "IPsec SA", instead of the newer "Child SA"?
- 2.3.1: I think the incorporation of EAP is important enough to be on the list of changes.
- 2.4: suggest to remove the last 3 bullets, which are way outside the core IPsec.
- 3.2: RFC 3585, please add "this RFC has not been widely adopted". Similarly (AFAIK) for RFC 4807 in Sec. 3.3, and RFC 3884 in Sec. 3.4.
- 3.4: suggested blurb for draft-ietf-ipsecme-traffic-visibility:

ESP, as defined [RFC4303], does not allow a network device to easily determine whether protected traffic that is passing through the device is encrypted, or only integrity-protected. This document extends ESP to provide explicit notification of integrity-protected packets, and extends IKEv2 to negotiate this capability between the IPsec peers.

- 4.1.1: I suggest to add the following introductory paragraph.

While historically IKEv1 was created by combining two security protocols, ISAKMP and Oakley, in practice the combination (along with the IPsec DOI) has commonly been viewed as one protocol, IKEv1. The protocol's origins can be seen in the organization of the documents that define it.

- 4.1.2: suggested blurb for Bis:

This document combines the original IKEv2 RFC with the Clarifications, and resolves many implementation issues discovered by the community since the publication of these two documents.

- 4.2.3: the section number appears twice!
- 4.2.3: DPD: mention that in IKEv2 this has been incorporated into the protocol.
- 5: typo: SA}s
- 5.1: the note that claims "by inference" that RFC 4835 applies to IPsec-v2 seems debatable to me, in view of Sec. 6 of that document.
- 5.2: I have an issue with the distinction we're making between stream ciphers and block ciphers. We should not be sending the message that integrity protection can be sometimes omitted.
- 5.3: just because we don't like HMAC-MD5, this is no reason not to cover RFC 2403. Moreover, it is still a MAY in RFC 4835, which also says, "Weaknesses have become apparent in MD5 [MD5-COLL]; however, these should not affect the use of MD5 with HMAC".
- 5.4: please add an introductory note explaining combined algorithms.
- 5.5: similarly, please add an introductory note explaining pseudo-random functions.
- 5.7: SMIME => S/MIME. And you probably meant TLS/SSL, not SSH.
- 7.4: we should point out that there are no known KINK implementations (AFAIK).
- 7.5: similarly, are there any implementations of DHCP as described in RFC 3456?
- 7.6: and IPsecKEY, too.

Thanks,
            Yaron

Email secured by Check Point

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

---

From: Sheila Frankel <[email-masked]>
Date: Tue, 13 Jan 2009 12:00:19 -0500

Thank you for your comments, Yaron. We'll incorporate them into the doc.

Regards,
Sheila

At 11:14 AM 1/13/2009, Yaron Sheffer wrote:
>Here are some comments, and some suggested text. Everyone on the 
>list is most welcome to suggest text for their favorite RFCs.
>
>- 2.1: I suggest to unify the 3 Algorithm boxes in the figure into 
>one, "Algorithms". There are also documents describing HMAC, and 
>describing D-H groups.
>- 2.2.1: but in IPsec-v3 you still need the dest address to 
>distinguish SAs, e.g. if you're on a gateway.
>- 3.2: RFC 3585, please add "this RFC has not been widely adopted". 
>Similarly (AFAIK) for RFC 4807 in Sec. 3.3, and RFC 3884 in Sec. 3.4.
>ESP, as defined [RFC4303], does not allow a network device to easily 
>determine whether protected traffic that is passing through the 
>device is encrypted, or only integrity-protected. This document 
>extends ESP to provide explicit notification of integrity-protected 
>packets, and extends IKEv2 to negotiate this capability between the 
>IPsec peers.
>
>While historically IKEv1 was created by combining two security 
>protocols, ISAKMP and Oakley, in practice the combination (along 
>with the IPsec DOI) has commonly been viewed as one protocol, IKEv1. 
>The protocol's origins can be seen in the organization of the 
>documents that define it.
>
>This document combines the original IKEv2 RFC with the 
>Clarifications, and resolves many implementation issues discovered 
>by the community since the publication of these two documents.
>
>- 5.1: the note that claims "by inference" that RFC 4835 applies to 
>IPsec-v2 seems debatable to me, in view of Sec. 6 of that document.
>- 5.2: I have an issue with the distinction we're making between 
>stream ciphers and block ciphers. We should not be sending the 
>message that integrity protection can be sometimes omitted.
>- 5.3: just because we don't like HMAC-MD5, this is no reason not to 
>cover RFC 2403. Moreover, it is still a MAY in RFC 4835, which also 
>says, "Weaknesses have become apparent in MD5 [MD5-COLL]; however, 
>these should not affect the use of MD5 with HMAC".

---

From: Yoav Nir <[email-masked]>
Date: Tue, 13 Jan 2009 22:19:49 +0200

Hi Yaron,

Two comments about your comments.

> Hi Sheila, Suresh,
<snip/>

> - 2.3.1: why use the older term "IPsec SA", instead of the newer  

A child SA is not the same as an IPsec SA, so the latter term is not  
deprecated. A child SA is an SA that is created from the IKE SA and  
could be an IPsec SA, an IKE SA or something that we haven't yet  
defined. Note that in IKEv2 the way to rekey an IKE SA is through a  
Create Child SA exchange, so the new IKE SA is also a child SA.

<snip/>
> - 7.4: we should point out that there are no known KINK  

Not so. Racoon2 supports KINK as well as both versions of IKE.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Tue, 13 Jan 2009 22:15:43 +0200

Hi Yaron,

<snip/>

<snip/>

Yoav

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 15 Jan 2009 18:55:37 +0200

Hi Yoav,

IKEv2 is quite clear on the definition of the Child SA. Quoting: "We call the IKE SA an "IKE_SA".  The SAs for ESP and/or AH that get set up through that IKE_SA we call "CHILD_SAs"."

The name of the CREATE_CHILD_SA exchange is indeed unfortunate.

Thanks,
            Yaron

________________________________
From: Yoav Nir [mailto:[email-masked]]
Sent: Tuesday, January 13, 2009 22:16
To: Yaron Sheffer
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-roadmap-00

Hi Yaron,

Hi Sheila, Suresh,

<snip/>

A child SA is not the same as an IPsec SA, so the latter term is not deprecated. A child SA is an SA that is created from the IKE SA and could be an IPsec SA, an IKE SA or something that we haven't yet defined. Note that in IKEv2 the way to rekey an IKE SA is through a Create Child SA exchange, so the new IKE SA is also a child SA.

<snip/>

Yoav

---

From: "Rajeshwar Singh Jenwar (rsj)" <[email-masked]>
Date: Sat, 17 Jan 2009 08:12:17 +0530

Hi Yaron/Yoav,
 
If you see section 1 (Introduction) of RFC4306 and IKEv2bis, in IKEv2bis
"We call the IKE SA an "IKE_SA" has been removed.
I request IKEV2bis authors to comment on this. 
Is above sentence has been removed to change the definition of CHILD_SAs
to the definition as mentioned by Yoav in mail below ?
 
Thanks,
Raj

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Yaron Sheffer
Sent: Thursday, January 15, 2009 10:26 PM
To: Yoav Nir
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-roadmap-00

Hi Yoav,

IKEv2 is quite clear on the definition of the Child SA. Quoting: "We
call the IKE SA an "IKE_SA".  The SAs for ESP and/or AH that get set up
through that IKE_SA we call "CHILD_SAs"."

Thanks,

            Yaron

From: Yoav Nir [mailto:[email-masked]] 
Sent: Tuesday, January 13, 2009 22:16
To: Yaron Sheffer
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-roadmap-00

Hi Yaron, 

Hi Sheila, Suresh,

<snip/>

- 2.3.1: why use the older term "IPsec SA", instead of the newer "Child
SA"?

<snip/>

- 7.4: we should point out that there are no known KINK implementations
(AFAIK).

Yoav

---

From: "Rajeshwar Singh Jenwar (rsj)" <[email-masked]>
Date: Thu, 22 Jan 2009 15:47:55 +0530

Hi Youv,
 
I agree with your definition of CHILD SAs.
Please update your definition of CHILD SA in IKEv2bis.
IKEv2bis says clearly in 1. Introduction, "The SAs for ESP or AH that
get set up though IKE SA we call 'CHILD SAs' ".
It would be better as "The SAs that get set up though IKE SA we call
'CHILD SAs' ".
The mention of only ESP or AH create a bit of confusion.
 
Regards,
Raj

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Yoav Nir
Sent: Wednesday, January 14, 2009 1:50 AM
To: Yaron Sheffer
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-roadmap-00

Hi Yaron,  

	
	Hi Sheila, Suresh,

<snip/>

	- 2.3.1: why use the older term "IPsec SA", instead of the newer
"Child SA"?

<snip/>

	
	- 7.4: we should point out that there are no known KINK
implementations (AFAIK).

Yoav