From paul.hoffman@vpnc.org Fri Jan 1 11:29:47 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E7BA3A6A38 for ; Fri, 1 Jan 2010 11:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.545 X-Spam-Level: X-Spam-Status: No, score=0.545 tagged_above=-999 required=5 tests=[AWL=-6.366, BAYES_50=0.001, FH_DATE_PAST_20XX=10.357, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0R02X2O6Yae for ; Fri, 1 Jan 2010 11:29:46 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id B1F163A69EB for ; Fri, 1 Jan 2010 11:29:46 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o01JT9Ed002570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Jan 2010 12:29:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <19257.58134.758647.17743@fireball.kivinen.iki.fi> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C46D7@il-ex01.ad.checkpoint.com> <19257.58134.758647.17743@fireball.kivinen.iki.fi> Date: Fri, 1 Jan 2010 11:29:07 -0800 To: Tero Kivinen , Yaron Sheffer From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG Subject: Re: [IPsec] Clarifying what happens with INITIAL_CONTACT X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2010 19:29:47 -0000 At 1:08 PM +0200 12/29/09, Tero Kivinen wrote: >Paul Hoffman writes: >> At 5:28 PM +0200 12/28/09, Yaron Sheffer wrote: >> > You are adding two MUSTs, which we SHOULD NOT do unless we have >> > very good reasons, such as interop problems, security issues, or >> > major functionality problems (like memory leaks). I'm not sure any >> > of these apply, so I suggest that you change the wording to be >> > non-normative. >> >> Whoops, all good points. I got carried away. How about: >> >> When an initiator receives an INITIAL_CONTACT notification in >> response to its IKE_AUTH request, it silently deletes any IKE SAs and >> associated Child SAs for that responder without sending any >> notifications to the responder. If a responder receives an >> INITIAL_CONTACT notification in an IKE_AUTH request, it silently >> deletes any IKE SAs and associated Child SAs for that initiator >> without sending any notifications to the initiator. > >I would actually keep the keyword we have in the RFC4306, i.e. "MAY". >It says "... recipient MAY use this information to delete any other >IKE_SAs ...". I am not sure what you say above and the MAY are really >same. For me the text above says you need to do it, even when it does >not have word "MUST" in it, as it only gives you exactly one option. > >As implementations are not required to understand (or send) >INITIAL_CONTACT notifications writing text like you have is bit >dangerous, as some people might still read that recipient of >INITIAL_CONTACT needs to silently delete any IKE SAs when it receives >INITIAL_CONTACT. Hrm. Another good point. Ignore this proposed change. FWIW, what I was really trying to get at in the addition was that, if you delete SAs when you get an INITIAL_CONTACT, you should do it silently, not by sending Delete notifications. But I don't see how to do that without adding normative-like language; if others can see how to say that, by all means let me know. --Paul Hoffman, Director --VPN Consortium From yaronf@checkpoint.com Mon Jan 4 14:27:17 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9814B28C0E2 for ; Mon, 4 Jan 2010 14:27:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSC+8CArRSNr for ; Mon, 4 Jan 2010 14:27:16 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 73B3B3A69F2 for ; Mon, 4 Jan 2010 14:27:16 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o04MRET7002471 for ; Tue, 5 Jan 2010 00:27:14 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 5 Jan 2010 00:27:27 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Tue, 5 Jan 2010 00:27:26 +0200 Thread-Topic: Traffic visibility - consensus call Thread-Index: AQHKjYZTQaGsaxOJ1EKbzfglwJmR2ZGF/Xel Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2010 22:27:17 -0000 Hi, We have had a few "discusses" during the IESG review of the WESP draft. To = help resolve them, we would like to reopen the following two questions to W= G discussion. Well reasoned answers are certainly appreciated. But plain "y= es" or "no" would also be useful in judging the group's consensus. - The current draft (http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-= visibility-11) defines the ESP trailer's ICV calculation to include the WES= P header. This has been done to counter certain attacks, but it means that = WESP is no longer a simple wrapper around ESP - ESP itself is modified. Do = you support this design decision? - The current draft allows WESP to be applied to encrypted ESP flows, in ad= dition to the originally specified ESP-null. This was intended so that encr= ypted flows can benefit from the future extensibility offered by WESP. But = arguably, it positions WESP as an alternative to ESP. Do you support this d= esign decision? Thanks, Yaron= From welterk@us.ibm.com Mon Jan 4 18:08:45 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A95463A67CC for ; Mon, 4 Jan 2010 18:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtQu182S1rW6 for ; Mon, 4 Jan 2010 18:08:44 -0800 (PST) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by core3.amsl.com (Postfix) with ESMTP id 20A553A67A6 for ; Mon, 4 Jan 2010 18:08:44 -0800 (PST) Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e39.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id o0521bKZ030122 for ; Mon, 4 Jan 2010 19:01:37 -0700 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o0528W5k100924 for ; Mon, 4 Jan 2010 19:08:32 -0700 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o0528WIw024270 for ; Mon, 4 Jan 2010 19:08:32 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av05.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o0528W90024267 for ; Mon, 4 Jan 2010 19:08:32 -0700 In-Reply-To: References: To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: 27852D54:49B76AEE-882576A2:00005F7C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Keith Welter X-MIMETrack: S/MIME Sign by Notes Client on Keith Welter/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/04/2010 06:08:34 PM, Serialize by Notes Client on Keith Welter/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/04/2010 06:08:35 PM, Serialize complete at 01/04/2010 06:08:35 PM, S/MIME Sign failed at 01/04/2010 06:08:35 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 01/04/2010 19:08:32, Serialize complete at 01/04/2010 19:08:32 Message-ID: Date: Mon, 4 Jan 2010 18:08:31 -0800 Content-Type: multipart/alternative; boundary="=_alternative 000BC5A7882576A2_=" Subject: Re: [IPsec] IPsec Digest, Vol 68, Issue 49 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 02:08:45 -0000 This is a multipart message in MIME format. --=_alternative 000BC5A7882576A2_= Content-Type: text/plain; charset="US-ASCII" Tero Kivinen writes: > David Wierbowski writes: > > I think it is reasonable to expect that an IKEv2 bis implementation would > > use an IF statement to control sending the new Notify types. > > No they should just use new notifies, as all old complient > implementations will work with those new error messages also. They will work when an unrecognized notify type is received but they may not work as well as if they had received a recognized notify type such as NO_PROPOSAL_CHOSEN. > > There is no reason to send old error notifications. A recognized (old) notify type like NO_PROPOSAL_CHOSEN may be used as a hint to do something special like try again later, a notion the RFC 4718 authors exploited because they didn't have the luxury of introducing new notify types. So, sending a new notify type to a peer that does not recognize it could be viewed as preventing the peer from making the most informed decision. > > > If the minor number was changed an implementation could check the > > minor version and send the new notify types when the minor version > > was 1 and send the notify types recommended in RFC 4718 if the minor > > number was 0. > > There is no point of supporting old RFC4718 error notifications after > you implement IKEv2bis as new error notifications are backward > compatible with old ones. I think there is a point to supporting the old notifies. If you have a deployed implementation then you have to consider patching it to at least recognize the new notification types. If you have an undeployed implementation in development you still might have to interoperate with unpatched peers. On the other hand, if ikev2bis increments the minor version number then you may code the ikev2bis implementation to not send the new notify types to down-level peers rather than patching already deployed implementations. I also think that calling the new error notifications "backwards compatible" is misleading. If you send a new notification to a peer that does not recognize it then the behavior may be different, possibly worse, than if you had sent an old, recognized notification. > Also RFC4718 used text like "thus failing > the request with something non-fatal such as NO_PROPOSAL_CHOSEN seems > like a reasonable approach." which clearly indicates that other error > notifications are also possible, thus whether other end sends > NO_PROPOSAL_CHOSEN or CHILD_SA_NOT_FOUND error notification, as > recipient will process them both in a same way, and expect that > exchange failed. The quoted RFC 4718 text suggested using a "non-fatal" notify type. However, a new notify type if it is unrecognized by the peer constitutes a fatal notify type. The recipient will probably not process NO_PROPOSAL_CHOSEN and an unrecognized error-type notify the same way. > > > That is what my implementation plans to do if the minor version > > number is bumped. > > I do not think I will ever implement RFC4718 error notifications (we > have not implemented it yet, and now when we have IKEv2bis almost > ready, I do not think we ever will), thus for me it does not really > matter, but I think it would be much easier to just change those error > notifications you already have in the code to use CHILD_SA_NOT_FOUND > and TEMPORARY_FAILURE instead of NO_ADDITIONAL_SAS and > NO_PROPOSAL_CHOSEN without adding any extra logic based on the minor > version number. > > > I'm not sure I agree with Tero that an implementation getting an unknown > > TEMPORARY_FAILURE notify would always take the same action that it would if > > it received NO_PROPOSAL_CHOSEN as suggested by RFC 4718. > > Then it is not complient to RFC4306, as RFC4306 clearly says that if > you get uknown error notification then you "MUST assume that the > corresponding request has failed entirely". Certainly an RFC 4306 compliant implementation would fail a "request" entirely if it got an unknown error notification in the response. However, an RFC 4306 compliant implementation might also retry the request later with a different message ID after receiving NO_PROPOSAL_CHOSEN whereas it almost certainly would not do such a thing after receiving an unknown error notification. > > RFC4718 does not (and cannot) modify the meaning of NO_PROPOSAL_CHOSEN > error notification it just gives you examples what kind error > notifications could be used in which case, but I do not think it gives > you instructions what to do when you receive such error notifications. > > This was one of the things needed to be added to the IKEv2bis, and > that was the reason we needed to have separate error notifications as > we wanted to be sure that it is easy to decide what to do when you get > error notification back (i.e. in addition to assuming that exchange > failed). > -- > kivinen@iki.fi I think this thread has been heading in the direction that it is not necessary to increment the minor version based on the incorrect assertion that old implementations will work just as well when they receive the new notify types as they did before. Old implementations will continue to work but they may not work *as well* when the new notify types are introduced unless the old implementations are patched. Some old implementations may even work worse if they receive the new notifications rather than those originally suggested in RFC 4718 section 5.11.10. I think there is a tangible benefit to be gained from incrementing the minor version number. Specifically, to enable an implementation to avoid sending the new notify types to a peer that won't recognize them. I understand the potential risk of incrementing the minor version but I think we ought to weigh that against the potential benefits. Keith Welter --=_alternative 000BC5A7882576A2_= Content-Type: text/html; charset="US-ASCII"
Tero Kivinen writes:
> David Wierbowski writes:
> > I think it is reasonable to expect that an IKEv2 bis implementation would
> > use an IF statement to control sending the new Notify types.
>
> No they should just use new notifies, as all old complient
> implementations will work with those new error messages also.
They will work when an unrecognized notify type is received but they
may not work as well as if they had received a recognized notify
type such as NO_PROPOSAL_CHOSEN.  

>
> There is no reason to send old error notifications.
A recognized (old) notify type like NO_PROPOSAL_CHOSEN may be used as a hint
to do something special like try again later, a notion the RFC 4718 authors
exploited because they didn't have the luxury of introducing new notify types.  
So, sending a new notify type to a peer that does not recognize it could
be viewed as preventing the peer from making the most informed decision.

>
> > If the minor number was changed an implementation could check the
> > minor version and send the new notify types when the minor version
> > was 1 and send the notify types recommended in RFC 4718 if the minor
> > number was 0.
>
> There is no point of supporting old RFC4718 error notifications after
> you implement IKEv2bis as new error notifications are backward
> compatible with old ones.
I think there is a point to supporting the old notifies.  If you have a
deployed implementation then you have to consider patching it to at least
recognize the new notification types.  If you have an undeployed
implementation in development you still might have to interoperate with
unpatched peers.  On the other hand, if ikev2bis increments the minor
version number then you may code the ikev2bis implementation to not send
the new notify types to down-level peers rather than patching already
deployed implementations.

I also think that calling the new error notifications "backwards compatible"
is misleading.  If you send a new notification to a peer that does not
recognize it then the behavior may be different, possibly worse, than if
you had sent an old, recognized notification.

> Also RFC4718 used text like "thus failing
> the request with something non-fatal such as NO_PROPOSAL_CHOSEN seems
> like a reasonable approach." which clearly indicates that other error
> notifications are also possible, thus whether other end sends
> NO_PROPOSAL_CHOSEN or CHILD_SA_NOT_FOUND error notification, as
> recipient will process them both in a same way, and expect that
> exchange failed.
The quoted RFC 4718 text suggested using a "non-fatal" notify type.
However, a new notify type if it is unrecognized by the peer constitutes
a fatal notify type.  The recipient will probably not process
NO_PROPOSAL_CHOSEN and an unrecognized error-type notify the same way.

>
> > That is what my implementation plans to do if the minor version
> > number is bumped.
>
> I do not think I will ever implement RFC4718 error notifications (we
> have not implemented it yet, and now when we have IKEv2bis almost
> ready, I do not think we ever will), thus for me it does not really
> matter, but I think it would be much easier to just change those error
> notifications you already have in the code to use CHILD_SA_NOT_FOUND
> and TEMPORARY_FAILURE instead of NO_ADDITIONAL_SAS and
> NO_PROPOSAL_CHOSEN without adding any extra logic based on the minor
> version number.
>
> > I'm not sure I agree with Tero that an implementation getting an unknown
> > TEMPORARY_FAILURE notify would always take the same action that it would if
> > it received NO_PROPOSAL_CHOSEN as suggested by RFC 4718.
>
> Then it is not complient to RFC4306, as RFC4306 clearly says that if
> you get uknown error notification then you "MUST assume that the
> corresponding request has failed entirely".
Certainly an RFC 4306 compliant implementation would fail a "request"
entirely if it got an unknown error notification in the response.  
However, an RFC 4306 compliant implementation might also retry the request
later with a different message ID after receiving NO_PROPOSAL_CHOSEN whereas
it almost certainly would not do such a thing after receiving an unknown
error notification.  

>
> RFC4718 does not (and cannot) modify the meaning of NO_PROPOSAL_CHOSEN
> error notification it just gives you examples what kind error
> notifications could be used in which case, but I do not think it gives
> you instructions what to do when you receive such error notifications.
>
> This was one of the things needed to be added to the IKEv2bis, and
> that was the reason we needed to have separate error notifications as
> we wanted to be sure that it is easy to decide what to do when you get
> error notification back (i.e. in addition to assuming that exchange
> failed).
> --
> kivinen@iki.fi
I think this thread has been heading in the direction that
it is not necessary to increment the minor version based on the
incorrect assertion that old implementations will work just as
well when they receive the new notify types as they did before.  
Old implementations will continue to work but they may not work
*as well* when the new notify types are introduced unless the old
implementations are patched.  Some old implementations may even
work worse if they receive the new notifications rather than those
originally suggested in RFC 4718 section 5.11.10.

I think there is a tangible benefit to be gained from incrementing
the minor version number.  Specifically, to enable an implementation
to avoid sending the new notify types to a peer that won't recognize
them.  I understand the potential risk of incrementing the minor version
but I think we ought to weigh that against the potential benefits.

Keith Welter --=_alternative 000BC5A7882576A2_=-- From ynir@checkpoint.com Mon Jan 4 23:55:28 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBACB3A67C0 for ; Mon, 4 Jan 2010 23:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rv-aQ7Q9Qz1U for ; Mon, 4 Jan 2010 23:55:28 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 979403A67ED for ; Mon, 4 Jan 2010 23:55:27 -0800 (PST) X-CheckPoint: {4B42EEB4-10000-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id C209D2AC004; Tue, 5 Jan 2010 09:55:24 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id A69B02AC002 for ; Tue, 5 Jan 2010 09:55:24 +0200 (IST) X-CheckPoint: {4B42EEB3-10000-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o057tOT7009246 for ; Tue, 5 Jan 2010 09:55:24 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 5 Jan 2010 09:55:37 +0200 From: Yoav Nir To: Yaron Sheffer Date: Tue, 5 Jan 2010 09:55:18 +0200 Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AcqN3HfLtL4H8tA3Tj6kNoC82LqJUw== Message-ID: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 07:55:28 -0000 On Jan 5, 2010, at 12:27 AM, Yaron Sheffer wrote: > Hi, >=20 > We have had a few "discusses" during the IESG review of the WESP draft. T= o help resolve them, we would like to reopen the following two questions to= WG discussion. Well reasoned answers are certainly appreciated. But plain = "yes" or "no" would also be useful in judging the group's consensus. >=20 > - The current draft (http://tools.ietf.org/html/draft-ietf-ipsecme-traffi= c-visibility-11) defines the ESP trailer's ICV calculation to include the W= ESP header. This has been done to counter certain attacks, but it means tha= t WESP is no longer a simple wrapper around ESP - ESP itself is modified. D= o you support this design decision? >=20 > - The current draft allows WESP to be applied to encrypted ESP flows, in = addition to the originally specified ESP-null. This was intended so that en= crypted flows can benefit from the future extensibility offered by WESP. Bu= t arguably, it positions WESP as an alternative to ESP. Do you support this= design decision? >=20 > Thanks, > Yaron Yes to both. Regardless of what the original work item specified, WESP as it is now is a= n alternative to ESP. In the long run it makes no sense to have them both, = so one will get obsoleted (just as AH is getting there). I see no benefit in crippling WESP to either keep the old ESP unchanged or = to keep some functionality (like encryption) as ESP-only. From kivinen@iki.fi Tue Jan 5 04:24:27 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AD0E3A68BF for ; Tue, 5 Jan 2010 04:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Si80SwoyYtE7 for ; Tue, 5 Jan 2010 04:24:26 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 831953A690A for ; Tue, 5 Jan 2010 04:24:24 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o05COHvT005476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jan 2010 14:24:17 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o05COGdG004463; Tue, 5 Jan 2010 14:24:16 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19267.12144.328153.130681@fireball.kivinen.iki.fi> Date: Tue, 5 Jan 2010 14:24:16 +0200 From: Tero Kivinen To: Keith Welter In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 71 min X-Total-Time: 70 min Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec Digest, Vol 68, Issue 49 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 12:24:27 -0000 Keith Welter writes: > A recognized (old) notify type like NO_PROPOSAL_CHOSEN may be used > as a hint to do something special like try again later, a notion the > RFC 4718 authors exploited because they didn't have the luxury of > introducing new notify types. So, sending a new notify type to a > peer that does not recognize it could be viewed as preventing the > peer from making the most informed decision. The RFC4718 didn't give any specific instructions what to do when implementation receives those notify types. Also when telling which error to send it uses terms like: "... thus failing the request with something non-fatal such as NO_PROPOSAL_CHOSEN seems like a reasonable approach." "In both cases, NO_PROPOSAL_CHOSEN is probably fine." "... replying with NO_PROPOSAL_CHOSEN is probably reasonable:" "Our proposal is as follows: if a host receives a request to rekey the IKE_SA when it has CHILD_SAs in "half-open" state (currently being created or rekeyed), it should reply with NO_PROPOSAL_CHOSEN. If a host receives a request to create or rekey a CHILD_SA after it has started rekeying the IKE_SA, it should reply with NO_ADDITIONAL_SAS." "Our recommendation is that if a host receives a request to rekey the IKE_SA when it has CHILD_SAs in "half-closed" state (currently being closed), it should reply with NO_PROPOSAL_CHOSEN." "At this point, host B should probably reply with NO_PROPOSAL_CHOSEN, and host A should reply as usual, close the IKE_SA, and stop retransmitting req1." All these uses terms where NO_PROPOSAL_CHOSEN is given out more like and example than specific error. The summary section does not use "probably / such as / our proposal / our recommendation" anymore, it summarizes what has been said in other sections before. As the RFC4718 didn't give any instructions what to do when you receive any of those error notifications, I assumed it expected the normal non-fatal (to IKE SA) error notification processing, i.e. it really does not matter what non-fatal error notification you use, as it should cause the exchange to fail which is the only meaning for sending that error notification. That was the reason I wanted to have new notification, so we can actually define some other processing to happen when those are received. I.e. we can say "When a peer receives a TEMPORARY_FAILURE notification, it MUST NOT immediately retry the operation...". That kind of behavior cannot be specified for NO_PROPOSAL_CHOSEN and that kind of behavior is NOT specified for it. On the other hand as only behavior which is defined for NO_PROPOSAL_CHOSEN is the generic non-fatal error notification behavior, meaning the exchange failed, but nothing else, that means any new error notification will get same behavior from complient implementations. If implementation do add some extra handling for the NO_PROPOSAL_CHOSEN error notifications, that is their own decision and it is not required or specified in the standard. > > > If the minor number was changed an implementation could check the > > > minor version and send the new notify types when the minor version > > > was 1 and send the notify types recommended in RFC 4718 if the minor > > > number was 0. > > > > There is no point of supporting old RFC4718 error notifications after > > you implement IKEv2bis as new error notifications are backward > > compatible with old ones. > I think there is a point to supporting the old notifies. If you have a > deployed implementation then you have to consider patching it to at least > recognize the new notification types. This is something you can do, i.e. if you already support old NO_PROPOSAL_CHOSEN notifications and recognize them based on the current state to be caused by exchange collisions you can (and should) still do that. On the other hand new implementations does not need to do that. For them it should be enough to do special processing for TEMPORARY_FAILURE only, for all other non-fatal error notifications they can do default processing (which will still take care of the RFC4718 way of doing things, as the default processing is to make that exchange fail). > If you have an undeployed implementation in development you still > might have to interoperate with unpatched peers. Regadless what error notification you use, you WILL interoperate with unpatched peers (unless they did something against RFC4306). Note, that there are implementations out there which do not implement RFC4718 exchange collisions at all, which means you still need to make sure you handle those cases too if you really want optimal processing with all implementations out there.. > On the other hand, if ikev2bis increments the minor version number > then you may code the ikev2bis implementation to not send the new > notify types to down-level peers rather than patching already > deployed implementations. There is no need for that, as someone might have already disagreed with RFC4718 and selected some other error notifications, as RFC4718 uses text like "...something non-fatal such as..." or "is probably fine", so you shouldn't really be looking at the specific error (NO_PROPOSAL_CHOSEN) but the fact that you got any non-fatal (to IKE SA) error back when you were at state where there might be collisions. > I also think that calling the new error notifications "backwards > compatible" is misleading. If you send a new notification to a peer > that does not recognize it then the behavior may be different, > possibly worse, than if you had sent an old, recognized > notification. Not really, as RFC4306 or RFC4718 didn't give you any instructions what to do when you receive such error notifications, and those error notifications given in RFC4718 were mostly given out as examples, thus your code should work similarly regardless what error notification you get. As none of the RFC gaven any specific instructions what to do when you receive those error messages that means the new error notifications are backward compatible. Some implementations might have special behavior not specified in the RFCs which might need to be changed, but document modifications we are proposing would still be backward compatible. The reason RFC4718 selected NO_PROPOSAL_CHOSEN was not to add some special processing for it, but because it happened to be non-fatal error code which didn't really have any special meaning for it. Most of the other non-fatal error codes had some special handling attached to it (UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_IKE_SPI, INVALID_MAJOR_VERSION, INVALID_MESSAGE_ID, INVALID_SPI, INVALID_KE_PAYLOAD, SINGLE_PAIR_REQUIRED, NO_ADDITIONAL_SAS, INTERNAL_ADDRESS_FAILURE, FAILED_CP_REQUIRED, INVALID_SELECTORS). The other option could have been TS_UNACCEPTABLE, but NO_PROPOSAL_CHOSEN was selected. There was no way of adding new meaning to the error notification, which is why RFC4718 didn't specify any special handling when you receive the error notification, it just assumed the default processing is ok. > The quoted RFC 4718 text suggested using a "non-fatal" notify type. > However, a new notify type if it is unrecognized by the peer > constitutes a fatal notify type. The recipient will probably not > process NO_PROPOSAL_CHOSEN and an unrecognized error-type notify the > same way. New error notifications are non-fatal just as NO_PROPOSAL_CHOSEN. Only fatal notification types are those which cause IKEv2 SA to be teared down, i.e. AUTHENTICATION_FAILED and INVALID_SYNTAX error notifications are considered fatal. All other error notifications are non-fatal, and only cause the current exchange to be considered as failed. RFC4306 (or RFC4718) didn't specify which error notifications are fatal and which are not, but we already added that text to the IKEv2bis. > Certainly an RFC 4306 compliant implementation would fail a > "request" entirely if it got an unknown error notification in the > response. However, an RFC 4306 compliant implementation might also > retry the request later with a different message ID after receiving > NO_PROPOSAL_CHOSEN whereas it almost certainly would not do such a > thing after receiving an unknown error notification. For TEMPORARY_FAILURE it should try again, for NO_PROPOSAL_CHOSEN that might not be case. If you really think that you get NO_PROPOSAL_CHOSEN only when you have mismatching policy, that means that you should only try again when your configuration has changed, or when the other ends configuration has changed. As configuration changes are not something that happens very often, it would be completely fine to retry after much longer timeout after NO_PROPOSAL_CHOSEN (for example 5 minutes). As most of the implementations do not really care about that, I think most will simply fail the exchange and they will retry when the next packet arrives that will trigger new Child SA to be created for the same policy rule. There is nothing in the documents which says you should not try again (or text which says how often you should retry). > I think this thread has been heading in the direction that > it is not necessary to increment the minor version based on the > incorrect assertion that old implementations will work just as > well when they receive the new notify types as they did before. Yes. Old implementations should work regardless which error notify they get. > Old implementations will continue to work but they may not work > *as well* when the new notify types are introduced unless the old > implementations are patched. Some old implementations may even > work worse if they receive the new notifications rather than those > originally suggested in RFC 4718 section 5.11.10. That might be case. And old implementations might have bugs processing unknown error notifications, but on the other hand old implementations might also have bugs in the processing of new minor version number. > I think there is a tangible benefit to be gained from incrementing > the minor version number. Specifically, to enable an implementation > to avoid sending the new notify types to a peer that won't recognize > them. I understand the potential risk of incrementing the minor version > but I think we ought to weigh that against the potential benefits. All of these exchange collision cases are quite rare. There are really only two of those which are bit more common and one of them is important, i.e. simultaneous IKE SA rekey, and simultaneous Child SA rekey. For both of them there is already text which says how to handle them. Also for simultaneous Child SA rekey even if it is not handled properly only thing that happens is that we have one extra Child SA, but traffic continues to flow and everything works. Only one where it is important to handle it properly is the simultaneous IKE SA rekey, as it is important to know that both ends agree on where the child SAs are moved. As I said these exchange collisions are not something you see very often (if ever) and I do not think the optimal behavior in all of those cases between RFC4718 and IKEv2 bis versions is needed that much that people would need to care about that. RFC4718 and IKEv2bis versions will interoperate and work together, there might be some extra packets going on in case the RFC4718 version do not understand new error notifications coming from the IKEv2bis version and does not delay retrying at all but would delay retrying if it would receive NO_PROPOSAL_CHOSEN. There might also be broken versions which do not retry at all if they receive any other error notification than NO_PROPOSAL_CHOSEN, but I would consider those versions broken. -- kivinen@iki.fi From smoonen@us.ibm.com Tue Jan 5 04:28:58 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D98B33A68BF; Tue, 5 Jan 2010 04:28:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DN8J2ax1WcAX; Tue, 5 Jan 2010 04:28:57 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by core3.amsl.com (Postfix) with ESMTP id 501103A67F3; Tue, 5 Jan 2010 04:28:57 -0800 (PST) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e35.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id o05CFTpo007065; Tue, 5 Jan 2010 05:15:29 -0700 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o05CSgYp101112; Tue, 5 Jan 2010 05:28:43 -0700 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o05CSgB8022447; Tue, 5 Jan 2010 05:28:42 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av05.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o05CSgAN022444; Tue, 5 Jan 2010 05:28:42 -0700 In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> To: Yoav Nir MIME-Version: 1.0 X-KeepSent: EDA9AA9A:7C867E5E-852576A2:0041C4F8; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/05/2010 07:28:25 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/05/2010 07:28:25 AM, Serialize complete at 01/05/2010 07:28:25 AM, S/MIME Sign failed at 01/05/2010 07:28:25 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 01/05/2010 05:28:41, Serialize complete at 01/05/2010 05:28:41 Message-ID: Date: Tue, 5 Jan 2010 07:28:41 -0500 Content-Type: multipart/alternative; boundary="=_alternative 0044852A852576A2_=" Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 12:28:58 -0000 This is a multipart message in MIME format. --=_alternative 0044852A852576A2_= Content-Type: text/plain; charset="US-ASCII" > > Do you support [the decision to include the WESP header in the ICV > > calculation]? > > . . . > > Do you support [the decision to allow the use of WESP for encrypted > > ESP flows]? > > Yes to both. > > Regardless of what the original work item specified, WESP as it is now > is an alternative to ESP. In the long run it makes no sense to have > them both, so one will get obsoleted (just as AH is getting there). > > I see no benefit in crippling WESP to either keep the old ESP > unchanged or to keep some functionality (like encryption) as ESP-only. No to both, considering the initial scope of what this was trying to do. I don't think we have warrant for inventing a complete replacement to ESP and I haven't yet seen any hypothetical proposals for the use of WESP that convince me there is a strong case for scuttling and replacing ESP. However, if the ayes have it, then I think two things are advisable. First, it would be wise to rewind the clock a bit and think about designing a cleaner WESP. WESP would look different if it had started out as a complete replacement for ESP. (For example, we've missed the opportunity to move the encrypted protocol byte up to the front.) Second, because there is a deep divide over whether a full-featured WESP has value or will be embraced, it may be wise to change this from a standards-track document to an individual draft or to experimental. Alternatively, we could really rewind the clock and try to establish real warrant and consensus for a complete replacement to ESP. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Yoav Nir To: Yaron Sheffer Cc: "ipsec@ietf.org" Date: 01/05/2010 02:56 AM Subject: Re: [IPsec] Traffic visibility - consensus call On Jan 5, 2010, at 12:27 AM, Yaron Sheffer wrote: > Hi, > > We have had a few "discusses" during the IESG review of the WESP draft. To help resolve them, we would like to reopen the following two questions to WG discussion. Well reasoned answers are certainly appreciated. But plain "yes" or "no" would also be useful in judging the group's consensus. > > - The current draft ( http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11) defines the ESP trailer's ICV calculation to include the WESP header. This has been done to counter certain attacks, but it means that WESP is no longer a simple wrapper around ESP - ESP itself is modified. Do you support this design decision? > > - The current draft allows WESP to be applied to encrypted ESP flows, in addition to the originally specified ESP-null. This was intended so that encrypted flows can benefit from the future extensibility offered by WESP. But arguably, it positions WESP as an alternative to ESP. Do you support this design decision? > > Thanks, > Yaron Yes to both. Regardless of what the original work item specified, WESP as it is now is an alternative to ESP. In the long run it makes no sense to have them both, so one will get obsoleted (just as AH is getting there). I see no benefit in crippling WESP to either keep the old ESP unchanged or to keep some functionality (like encryption) as ESP-only. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 0044852A852576A2_= Content-Type: text/html; charset="US-ASCII"
> > Do you support [the decision to include the WESP header in the ICV
> > calculation]?
> > . . .
> > Do you support [the decision to allow the use of WESP for encrypted
> > ESP flows]?
>
> Yes to both.
>
> Regardless of what the original work item specified, WESP as it is now
> is an alternative to ESP. In the long run it makes no sense to have
> them both, so one will get obsoleted (just as AH is getting there).
>
> I see no benefit in crippling WESP to either keep the old ESP
> unchanged or to keep some functionality (like encryption) as ESP-only.

No to both, considering the initial scope of what this was trying to do.  I don't think we have warrant for inventing a complete replacement to ESP and I haven't yet seen any hypothetical proposals for the use of WESP that convince me there is a strong case for scuttling and replacing ESP.

However, if the ayes have it, then I think two things are advisable.  First, it would be wise to rewind the clock a bit and think about designing a cleaner WESP.  WESP would look different if it had started out as a complete replacement for ESP.  (For example, we've missed the opportunity to move the encrypted protocol byte up to the front.)  Second, because there is a deep divide over whether a full-featured WESP has value or will be embraced, it may be wise to change this from a standards-track document to an individual draft or to experimental.  Alternatively, we could really rewind the clock and try to establish real warrant and consensus for a complete replacement to ESP.


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen


From: Yoav Nir <ynir@checkpoint.com>
To: Yaron Sheffer <yaronf@checkpoint.com>
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Date: 01/05/2010 02:56 AM
Subject: Re: [IPsec] Traffic visibility - consensus call





On Jan 5, 2010, at 12:27 AM, Yaron Sheffer wrote:

> Hi,
>
> We have had a few "discusses" during the IESG review of the WESP draft. To help resolve them, we would like to reopen the following two questions to WG discussion. Well reasoned answers are certainly appreciated. But plain "yes" or "no" would also be useful in judging the group's consensus.
>
> - The current draft (http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11) defines the ESP trailer's ICV calculation to include the WESP header. This has been done to counter certain attacks, but it means that WESP is no longer a simple wrapper around ESP - ESP itself is modified. Do you support this design decision?
>
> - The current draft allows WESP to be applied to encrypted ESP flows, in addition to the originally specified ESP-null. This was intended so that encrypted flows can benefit from the future extensibility offered by WESP. But arguably, it positions WESP as an alternative to ESP. Do you support this design decision?
>
> Thanks,
>     Yaron

Yes to both.

Regardless of what the original work item specified, WESP as it is now is an alternative to ESP. In the long run it makes no sense to have them both, so one will get obsoleted (just as AH is getting there).

I see no benefit in crippling WESP to either keep the old ESP unchanged or to keep some functionality (like encryption) as ESP-only.


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--=_alternative 0044852A852576A2_=-- From kivinen@iki.fi Tue Jan 5 04:53:02 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00ED33A6858 for ; Tue, 5 Jan 2010 04:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwFyAJWYc71g for ; Tue, 5 Jan 2010 04:53:01 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id BF6AC3A67EA for ; Tue, 5 Jan 2010 04:53:00 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o05CqtBd001070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jan 2010 14:52:55 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o05CqtiQ003805; Tue, 5 Jan 2010 14:52:55 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19267.13863.82855.205850@fireball.kivinen.iki.fi> Date: Tue, 5 Jan 2010 14:52:55 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 17 min X-Total-Time: 27 min Cc: "ipsec@ietf.org" Subject: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 12:53:02 -0000 Yaron Sheffer writes: > - The current draft > (http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11) > defines the ESP trailer's ICV calculation to include the WESP > header. This has been done to counter certain attacks, but it > means that WESP is no longer a simple wrapper around ESP - ESP > itself is modified. Do you support this design decision? No. > - The current draft allows WESP to be applied to encrypted ESP > flows, in addition to the originally specified ESP-null. This was > intended so that encrypted flows can benefit from the future > extensibility offered by WESP. But arguably, it positions WESP as > an alternative to ESP. Do you support this design decision? No. If we really want to make WESP as specified in the charter, it would be much better to make it so it can be added incrementally to the ESP processing, i.e. just like UDP encapsulation for NAT-traversal can be do. This would mean that the WESP processing could be applied after the normal ESP processing, and WESP would simply add extra header to the beginning, and nothing else. The current draft already makes sure all the fields in the WESP header are verified by the IPsec recipient thus there is really no need to add ICV to cover them (if extensions are added then ICV needs cover them, which makes it impossible to implement WESP as incremental change to ESP). On the other hand if WESP is going be ESPv4, then it would be better to modify the ESP directly, i.e make the required modifications to the ESP header itself. Now WESP has bad attributes from both. It cannot be implemented as extra step after normal ESP processing, but it does not benefit from the fact that it could be modifying ESP header. I myself has always not cared that much of WESP, as I always planned NOT to implement it ever, but just refer people who want it to my heuristics draft, and say that there is no need for WESP. Now if people really start to talk WESP as a new ESPv4, and talking about obsoleting old ESP so that only WESP would stay, then the situation is quite different. If that would have been clear from the beginning I myself would have concentrated much more on the WESP work. I assume there are other people who feel the same. Thats why I think it is inappropriate to even consider WESP as something that would be replacing ESP ever. If that is wanted, then much more discussion is needed. -- kivinen@iki.fi From danmcd@sun.com Tue Jan 5 07:28:15 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E687828C0FF for ; Tue, 5 Jan 2010 07:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C57rd0Cqk7+a for ; Tue, 5 Jan 2010 07:28:14 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id A176428C0F4 for ; Tue, 5 Jan 2010 07:28:11 -0800 (PST) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o05FS9Ng028270 for ; Tue, 5 Jan 2010 15:28:09 GMT Received: from kebe.East.Sun.COM (kebe.East.Sun.COM [129.148.174.48]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.4) with ESMTP id o05FS87x028104 for ; Tue, 5 Jan 2010 10:28:08 -0500 (EST) Received: from kebe.East.Sun.COM (localhost [127.0.0.1]) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id o05FRmNq019025 for ; Tue, 5 Jan 2010 10:27:48 -0500 (EST) Received: (from danmcd@localhost) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3/Submit) id o05FRmM1019024 for ipsec@ietf.org; Tue, 5 Jan 2010 10:27:48 -0500 (EST) X-Authentication-Warning: kebe.East.Sun.COM: danmcd set sender to danmcd@sun.com using -f Date: Tue, 5 Jan 2010 10:27:47 -0500 From: Dan McDonald To: ipsec@ietf.org Message-ID: <20100105152747.GA18999@kebe.East.Sun.COM> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <19267.13863.82855.205850@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19267.13863.82855.205850@fireball.kivinen.iki.fi> Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 15:28:15 -0000 On Tue, Jan 05, 2010 at 02:52:55PM +0200, Tero Kivinen wrote: > If we really want to make WESP as specified in the charter, it would > be much better to make it so it can be added incrementally to the ESP > processing, i.e. just like UDP encapsulation for NAT-traversal can be > do. This would mean that the WESP processing could be applied after > the normal ESP processing, and WESP would simply add extra header to > the beginning, and nothing else. The current draft already makes sure > all the fields in the WESP header are verified by the IPsec recipient > thus there is really no need to add ICV to cover them (if extensions > are added then ICV needs cover them, which makes it impossible to > implement WESP as incremental change to ESP). Yes -- this would allow WESP to be an attribute one adds to an ESP SA. Not unlike NAT-Traversal, it could be negotiated by IKE. Dan From kent@bbn.com Tue Jan 5 10:06:11 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3D7E28C18C for ; Tue, 5 Jan 2010 10:06:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihRoZUWAN6Ey for ; Tue, 5 Jan 2010 10:06:11 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 8994A28C149 for ; Tue, 5 Jan 2010 10:06:10 -0800 (PST) Received: from dhcp89-089-161.bbn.com ([128.89.89.161]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NSDnD-0006pZ-CY; Tue, 05 Jan 2010 13:06:08 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> Date: Tue, 5 Jan 2010 13:06:05 -0500 To: Yaron Sheffer From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 18:06:12 -0000 At 12:27 AM +0200 1/5/10, Yaron Sheffer wrote: >Hi, > >We have had a few "discusses" during the IESG review of the WESP >draft. To help resolve them, we would like to reopen the following >two questions to WG discussion. Well reasoned answers are certainly >appreciated. But plain "yes" or "no" would also be useful in judging >the group's consensus. > >- The current draft >(http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11) >defines the ESP trailer's ICV calculation to include the WESP >header. This has been done to counter certain attacks, but it means >that WESP is no longer a simple wrapper around ESP - ESP itself is >modified. Do you support this design decision? My previous message describing why I think the current design is seriously flawed provided the rationale for my NO response to this question. WESP as a modular, separate, nested protocol would be preferable. >- The current draft allows WESP to be applied to encrypted ESP >flows, in addition to the originally specified ESP-null. This was >intended so that encrypted flows can benefit from the future >extensibility offered by WESP. But arguably, it positions WESP as an >alternative to ESP. Do you support this design decision? I am concerned about the wording of the penultimate sentence above. Several folks argued against applying WESP to encrypted traffic and they cited various reasons for why this might be inappropriate. You did not choose to cite those reasons, which I think may bias responses. I think the two major issues cited re the extension of WESP to encrypted traffic are: - it is formally outside the charter - no good WESP extensions have been proposed for encrypted traffic Even if WESP is approved for use with encrypted traffic, that does not mean that it will supplant ESP. ESP still has a smaller header than WESP, so for environments where there is no intent to accommodate middlebox snooping, ESP is still preferable. So, NO to this question as well. Steve From ken.grewal@intel.com Tue Jan 5 10:16:08 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4029828C15C for ; Tue, 5 Jan 2010 10:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afOEGnpMi9sa for ; Tue, 5 Jan 2010 10:16:07 -0800 (PST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by core3.amsl.com (Postfix) with ESMTP id 2497D28C192 for ; Tue, 5 Jan 2010 10:16:07 -0800 (PST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 05 Jan 2010 10:15:36 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.47,507,1257148800"; d="scan'208";a="761523011" Received: from rrsmsx604.amr.corp.intel.com ([10.31.0.170]) by fmsmga001.fm.intel.com with ESMTP; 05 Jan 2010 10:15:57 -0800 Received: from rrsmsx601.amr.corp.intel.com (10.31.0.151) by rrsmsx604.amr.corp.intel.com (10.31.0.170) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 5 Jan 2010 11:16:05 -0700 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Tue, 5 Jan 2010 11:16:05 -0700 From: "Grewal, Ken" To: Yaron Sheffer , "ipsec@ietf.org" Date: Tue, 5 Jan 2010 11:14:43 -0700 Thread-Topic: Traffic visibility - consensus call Thread-Index: AQHKjYZTQaGsaxOJ1EKbzfglwJmR2ZGF/XelgAFFDXA= Message-ID: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 18:16:08 -0000 Yes to both, based on arguments already discussed numerous times in the WG = via presentations, 12 iterations of the draft and multiple WG last calls + = AD reviews! The main motivation for extending the ICV was to counter some of the issues= originally raised by Steve Kent - malicious entities modifying portions of= the WESP header to bypass legitimate parsing of the packet by Trusted Inte= rmediary (TI) devices such as IDS/IPS/etc. This can be addressed by the rec= ipient explicitly validating the WESP header before accepting the packet or= implicitly by including the WESP header as part of the ICV check.=20 The motivation for allowing WESP to be used for encrypted data was brought = up as a consistency argument and also allows for future extensibility in a = uniform manner. I agree that this was not part of the original charter, as = shown in the earlier revisions of the WESP drafts.=20 BUT, this was discussed numerous times within the WG (including an open tic= ket on scope) and it was agreed that this would be a useful bit to include = in the flags, hence introduced in the latter revisions of the draft. Note t= hat this does not mandate using WESP for encrypted traffic, but allows it a= s optional and can be dictated as part of the session setup based on local = policy. Another benefit may be that in running mixed mode environments (enc= rypted + ESP_NULL traffic), it allows for an explicit distinction from the = packet that certain traffic is encrypted and other traffic is not. Otherwis= e, one would use ESP and WESP in these mixed mode environments and to be ab= solutely sure if ESP traffic is encrypted or not, would need to fall back t= o heuristics, which somewhat defeats the object of having this spec. =20 I am certainly not a fan of heuristics, as it is complex, non-deterministic= , will require updates for new algorithms added into ESP, as well as other = arguments already cited numerous times, so would like to see a consistent d= eterministic way to identify the traffic. =20 Thanks,=20 - Ken =20 >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >Of Yaron Sheffer >Sent: Monday, January 04, 2010 2:27 PM >To: ipsec@ietf.org >Subject: [IPsec] Traffic visibility - consensus call > >Hi, > >We have had a few "discusses" during the IESG review of the WESP draft. >To help resolve them, we would like to reopen the following two >questions to WG discussion. Well reasoned answers are certainly >appreciated. But plain "yes" or "no" would also be useful in judging the >group's consensus. > >- The current draft (http://tools.ietf.org/html/draft-ietf-ipsecme- >traffic-visibility-11) defines the ESP trailer's ICV calculation to >include the WESP header. This has been done to counter certain attacks, >but it means that WESP is no longer a simple wrapper around ESP - ESP >itself is modified. Do you support this design decision? > >- The current draft allows WESP to be applied to encrypted ESP flows, in >addition to the originally specified ESP-null. This was intended so that >encrypted flows can benefit from the future extensibility offered by >WESP. But arguably, it positions WESP as an alternative to ESP. Do you >support this design decision? > >Thanks, > Yaron >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec From g_e_montenegro@yahoo.com Tue Jan 5 11:08:38 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61CCF3A692A for ; Tue, 5 Jan 2010 11:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3Bn20MbG1cl for ; Tue, 5 Jan 2010 11:08:37 -0800 (PST) Received: from web82602.mail.mud.yahoo.com (web82602.mail.mud.yahoo.com [68.142.201.119]) by core3.amsl.com (Postfix) with SMTP id 343A33A6767 for ; Tue, 5 Jan 2010 11:08:37 -0800 (PST) Received: (qmail 1728 invoked by uid 60001); 5 Jan 2010 19:08:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1262718514; bh=yXCoDafFq3Vb6U4DYLw3gwwtlQ5HHM/D6uhM1bPyxfk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=T8Iz/vS2++5bQ3dn9iTRyO9Lcels+iq/lUc8wAiMyE0i/PKNSINuyeloYxXhqVNxJ4vhtXAiSiPPltHQS/70/+dU/iQrRdNgJGw41MX8OZNNZGjzRe4KD+ZujbEzsdyTj5p2YvuuVaZ7czeDdwm4VB31X5sR5R1ROxQ3XlWCCw0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=49NQKuO8s0Agviwer4d+pYfXOR16NDxSdxfHJTcVSPFiguDJBgoTZQ0U6Zph+wwPug7gW8SsvLrW8fCGaBRWynDCyNvcvPYhGaIwP9OPvIfDJWSu/PMcZXz/Jftqm8tg70EMlyoweofTpiqp9SRv2peTRcLVuUWQtFctSvsAv9A=; Message-ID: <378834.93787.qm@web82602.mail.mud.yahoo.com> X-YMail-OSG: QJZG068VM1kAc12zQCSYBNndxdKMG8WpjQLzjH5yUlbvMWIO.mjOe1MiiDsadCKuMJxESDAxBV.RGHsOgkVWZA.lFadpNd8mu5vHBOc67XH.pDc_b33TL7Qhf6IMQZHqnN3rc0NbwT0PI_I0K4_2yZ0kFBMfNm2kTg3JlsIYdhnnn6wLqyxkY_1UTkjtuEZ479w7_Kho8sLDeBj9qfwOVNPGoJhXsJwZnRZA.zvUMnKA5nxuxCKoBfW1EvZTs1haeRvlZy8uY1kPxYFw4TsX4IxRh0qYxbb3hRvB4yTy5QRf5eTrwgl6xPg0oWSgUn4loeb6etNUZCCxECICXZ17ap38pjJT3Cl_S8BdOjNtUQl1sGY- Received: from [131.107.0.75] by web82602.mail.mud.yahoo.com via HTTP; Tue, 05 Jan 2010 11:08:34 PST X-Mailer: YahooMailRC/240.3 YahooMailWebService/0.8.100.260964 References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> Date: Tue, 5 Jan 2010 11:08:34 -0800 (PST) From: gabriel montenegro To: "Grewal, Ken" , Yaron Sheffer , "ipsec@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 19:08:38 -0000 Yes to both questions.=0A=A0=0ABut I'd also like to question the process be= ing followed. We've discussed these points numerous times=0Ain f2f meetings= , on the mailing list, at virtual interims, etc. So I'm surprised to see th= e already=0Aestablished consensus being questioned all over again. Some of = the arguments claim lack of=0Aattention, whereas they have been intense and= prolific discussions on WESP, and thankfully so =0A(e.g., including but no= t limited to spawning of Tero's heuristics draft and =0Athe motivation for = the modified ICV coverage to address Steve's comment). =0A=A0=0ABut even if= folks had not paid attention, that is no excuse for derailing the process.= =0A=A0=0AI disagree that WESP encryption is out of scope. It certainly is.= =0A=A0=0AThere is a need per the charter for a mechanism to=0A"easily and r= eliably" determine the type of traffic. Within an organization, it would be= much easier to use=0AWESP encryption as an alternative to ESP. If one sees= ESP packets, then one would have to run heuristics=0Awith all the pertaini= ng issues as explained in Manav's recent message, and higher cost associate= d=0A(particularly, in stateless high aggregation points). WESP with encrypt= ion support would allow an =0Aorganization to simplify rules and inspection= devices. Sure, the WESP header adds more bytes, but the=0Atradeoff is that= there is no need for costly heuristics throughout the network. Without WES= P encryption,=0Athe charter item does not have a complete solution.=0A=A0= =0AJust to be clear: I'm not saying that WESP is a general replacement for = ESP. As Steve Kent points out,=0Awhere there are no trusted intermediary in= spection devices (i.e., outside of medium to large organizations)=0Athere i= s no need for end-nodes to collaborate with the inspecting infrastructure, = hence no need for =0AWESP. ESP is fine. Perhaps this is the disconnect that= is happening: traditionally, the focus of the IPsec=0AWG has been on such = external applications (VPN), whereas WESP and future potential=0Aextensibil= ity is more valuable within organizations. Such value may not be as obvious= to VPN folks.=0A=A0=0AGabriel=0A=0A=0A----- Original Message ----=0A> From= : "Grewal, Ken" =0A> To: Yaron Sheffer ; "ipsec@ietf.org" =0A> Sent: Tue, January 5, 2010= 10:14:43 AM=0A> Subject: Re: [IPsec] Traffic visibility - consensus call= =0A> =0A> Yes to both, based on arguments already discussed numerous times = in the WG via =0A> presentations, 12 iterations of the draft and multiple W= G last calls + AD =0A> reviews!=0A> =0A> The main motivation for extending = the ICV was to counter some of the issues =0A> originally raised by Steve K= ent - malicious entities modifying portions of the =0A> WESP header to bypa= ss legitimate parsing of the packet by Trusted Intermediary =0A> (TI) devic= es such as IDS/IPS/etc. This can be addressed by the recipient =0A> explici= tly validating the WESP header before accepting the packet or implicitly = =0A> by including the WESP header as part of the ICV check. =0A> =0A> The m= otivation for allowing WESP to be used for encrypted data was brought up as= =0A> a consistency argument and also allows for future extensibility in a = uniform =0A> manner. I agree that this was not part of the original charter= , as shown in the =0A> earlier revisions of the WESP drafts. =0A> BUT, this= was discussed numerous times within the WG (including an open ticket =0A> = on scope) and it was agreed that this would be a useful bit to include in t= he =0A> flags, hence introduced in the latter revisions of the draft. Note = that this =0A> does not mandate using WESP for encrypted traffic, but allow= s it as optional and =0A> can be dictated as part of the session setup base= d on local policy. Another =0A> benefit may be that in running mixed mode e= nvironments (encrypted + ESP_NULL =0A> traffic), it allows for an explicit = distinction from the packet that certain =0A> traffic is encrypted and othe= r traffic is not. Otherwise, one would use ESP and =0A> WESP in these mixed= mode environments and to be absolutely sure if ESP traffic =0A> is encrypt= ed or not, would need to fall back to heuristics, which somewhat =0A> defea= ts the object of having this spec.=A0 =0A> =0A> I am certainly not a fan of= heuristics, as it is complex, non-deterministic, =0A> will require updates= for new algorithms added into ESP, as well as other =0A> arguments already= cited numerous times, so would like to see a consistent =0A> deterministic= way to identify the traffic.=A0 =0A> =0A> Thanks, =0A> - Ken=0A> =0A> =0A>= >-----Original Message-----=0A> >From: ipsec-bounces@ietf.org [mailto:ipse= c-bounces@ietf.org] On Behalf=0A> >Of Yaron Sheffer=0A> >Sent: Monday, Janu= ary 04, 2010 2:27 PM=0A> >To: ipsec@ietf.org=0A> >Subject: [IPsec] Traffic = visibility - consensus call=0A> >=0A> >Hi,=0A> >=0A> >We have had a few "di= scusses" during the IESG review of the WESP draft.=0A> >To help resolve the= m, we would like to reopen the following two=0A> >questions to WG discussio= n. Well reasoned answers are certainly=0A> >appreciated. But plain "yes" or= "no" would also be useful in judging the=0A> >group's consensus.=0A> >=0A>= >- The current draft (http://tools.ietf.org/html/draft-ietf-ipsecme-=0A> >= traffic-visibility-11) defines the ESP trailer's ICV calculation to=0A> >in= clude the WESP header. This has been done to counter certain attacks,=0A> >= but it means that WESP is no longer a simple wrapper around ESP - ESP=0A> >= itself is modified. Do you support this design decision?=0A> >=0A> >- The c= urrent draft allows WESP to be applied to encrypted ESP flows, in=0A> >addi= tion to the originally specified ESP-null. This was intended so that=0A> >e= ncrypted flows can benefit from the future extensibility offered by=0A> >WE= SP. But arguably, it positions WESP as an alternative to ESP. Do you=0A> >s= upport this design decision?=0A> >=0A> >Thanks,=0A> >=A0 =A0 Yaron=0A> >___= ____________________________________________=0A> >IPsec mailing list=0A> >I= Psec@ietf.org=0A> >https://www.ietf.org/mailman/listinfo/ipsec=0A> ________= _______________________________________=0A> IPsec mailing list=0A> IPsec@ie= tf.org=0A> https://www.ietf.org/mailman/listinfo/ipsec=0A From paul.hoffman@vpnc.org Tue Jan 5 11:14:43 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4971628C161 for ; Tue, 5 Jan 2010 11:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.173 X-Spam-Level: X-Spam-Status: No, score=-6.173 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYxMcroRySxt for ; Tue, 5 Jan 2010 11:14:42 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 8DCF828C0F3 for ; Tue, 5 Jan 2010 11:14:42 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o05JEcaI083903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jan 2010 12:14:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <378834.93787.qm@web82602.mail.mud.yahoo.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> Date: Tue, 5 Jan 2010 11:14:36 -0800 To: gabriel montenegro , "ipsec@ietf.org" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 19:14:43 -0000 At 11:08 AM -0800 1/5/10, gabriel montenegro wrote: >But I'd also like to question the process being followed. And I would like to answer. In short: the IESG is responsible for the output of the IETF. This is one such output. The IESG chartered the WG for a particular item, and there is a question about whether what we produced matches that charter, and if it doesn't, is it still OK. >We've discussed these points numerous times >in f2f meetings, on the mailing list, at virtual interims, etc. So I'm surprised to see the already >established consensus being questioned all over again. The IESG was not part of those discussions; they are reviewing the work that this WG sent to them. >But even if folks had not paid attention, that is no excuse for derailing the process. A consensus call is not "derailing the process": it is just the opposite. --Paul Hoffman, Director --VPN Consortium From g_e_montenegro@yahoo.com Tue Jan 5 11:25:37 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8695E3A68BB for ; Tue, 5 Jan 2010 11:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FHKZTBuInKP for ; Tue, 5 Jan 2010 11:25:36 -0800 (PST) Received: from web82601.mail.mud.yahoo.com (web82601.mail.mud.yahoo.com [68.142.201.118]) by core3.amsl.com (Postfix) with SMTP id 70C873A6778 for ; Tue, 5 Jan 2010 11:25:36 -0800 (PST) Received: (qmail 4647 invoked by uid 60001); 5 Jan 2010 19:25:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1262719532; bh=G5ej6OJ6eGwQTZLt3r6823v3dRJO14841azbyGD9rkQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=fyv9T5kOLIyvK8ZnXih51NwehwsD1qlNcFR2//pD2ad2CDZiwifxaY6X1PsX3EWluSpYBoFG6Juvfu7RdChnH3VUJjdv0XJPKXs0AN9KtWzo+FopjYrImbLcZNHYV2FfzNB0k7d22A9abbmEOMy07H7tafAEu7g7XIzuBlItirg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=QjwT4fljkz0fMuN40PYGr3GC8HsPbjvKcO4TWI1wnuAwVdc6rebIyp5joaXNduLTlqgQ8MaSlxXOSqEJoJo52Cvjd+qnM/YI1UiA51wiXFaqLp13Awrkgczxgv1eS5q5lHHrAVgfat1JS0z/gXxgJNxtuNaFDHCplrhotf7ykkM=; Message-ID: <97635.97572.qm@web82601.mail.mud.yahoo.com> X-YMail-OSG: g.RTjTkVM1lHeSGICBdhO0bm7lnxEpD424mZq2hEiX7QzjPDlq5e8tmJdlS3RhVhVspi8vXmJj7blUgApmoFAq3je8OCNmsUvWa0TKrZN55PkfyDakfa8w7vAaC21k7DQWMUNc4Zjw2FSOUzdV1HF3j3shD40ru7unMx66YzN2no7zAMNo569Q.GmdxCZsLTZpYOrAr7RSzHyvx9esdofq0QHfp_3Slr3M8GFIJfPyKNFa8qmhIUFUdVNzsGVL7YCduuaT05eqDGv2m2GKFOrtOFKpUaE.T7My3iJK10iHmnha_QjmQyFU4inwIZedUHeTGB1rwsBTuf Received: from [131.107.0.75] by web82601.mail.mud.yahoo.com via HTTP; Tue, 05 Jan 2010 11:25:31 PST X-Mailer: YahooMailRC/240.3 YahooMailWebService/0.8.100.260964 References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> Date: Tue, 5 Jan 2010 11:25:31 -0800 (PST) From: gabriel montenegro To: Paul Hoffman , "ipsec@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 19:25:37 -0000 I fully agree that a consensus call is an integral part of the IETF process. But what we're seeing here is not one but a plurality of consensus calls. I would have expected the response to the IESG to be: yes, this was the consensus arrived in the WG at time X, here are further details, etc. What we're seeing is: oh, ok, let's do it all over again. ----- Original Message ---- > From: Paul Hoffman > To: gabriel montenegro ; "ipsec@ietf.org" > Sent: Tue, January 5, 2010 11:14:36 AM > Subject: Re: [IPsec] Traffic visibility - consensus call > > At 11:08 AM -0800 1/5/10, gabriel montenegro wrote: > >But I'd also like to question the process being followed. > > And I would like to answer. In short: the IESG is responsible for the output of > the IETF. This is one such output. The IESG chartered the WG for a particular > item, and there is a question about whether what we produced matches that > charter, and if it doesn't, is it still OK. > > >We've discussed these points numerous times > >in f2f meetings, on the mailing list, at virtual interims, etc. So I'm > surprised to see the already > >established consensus being questioned all over again. > > The IESG was not part of those discussions; they are reviewing the work that > this WG sent to them. > > >But even if folks had not paid attention, that is no excuse for derailing the > process. > > A consensus call is not "derailing the process": it is just the opposite. > > --Paul Hoffman, Director > --VPN Consortium From g_e_montenegro@yahoo.com Tue Jan 5 11:39:21 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D6773A694E for ; Tue, 5 Jan 2010 11:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qu0c2KPV4r4Q for ; Tue, 5 Jan 2010 11:39:21 -0800 (PST) Received: from web82602.mail.mud.yahoo.com (web82602.mail.mud.yahoo.com [68.142.201.119]) by core3.amsl.com (Postfix) with SMTP id 276633A6942 for ; Tue, 5 Jan 2010 11:39:21 -0800 (PST) Received: (qmail 16114 invoked by uid 60001); 5 Jan 2010 19:32:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1262719956; bh=S33tRR2IMUHHCNCuAfJu/5kxqs1sWQq//2GhMRJ1gmw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=2ltwSaJT2RMW+P+MZOsFv8Zh5MzvBqHZPTPnFJOHMfqWOf4SOvE7Of3t0eEIOfSkgNxWs0IF/Qhw71voSDDqkic2n3UMMjYZZ5kiMWrdGZj2tcv00dLo5KmJqzEz/FIeENVfTdWYe+RckfOKrtjPmsPnH0BLRrOWhxREibl5FP8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=IUO3kA02sMu8bL0ZhcrNdh558NpUHIvmEDiHBn1XH+ctLz1ZJV482FSYiFLHrx3r512fvGSjr4ELDCFbi3/1BfhTJNIq2m06+X7UEMZ+06V6e9+hFGBHXu2TI2BbwOJraW9LauxzMZVbzpX0WpLnEw2HcWdT/oUfqni/NuzqM78=; Message-ID: <941690.12882.qm@web82602.mail.mud.yahoo.com> X-YMail-OSG: D8YvUhgVM1mE9wBSFODSOEVDRPBzwvbo1QjPYay1W0Ci1ptpKGRjc6jPHY6GRVQ1SZez4ara5RAcfi9o5wOqO.thvghMnx5PMHEVFyryNOqLlrOk_JbOkoJEiTmXj0ZqJilDDdBc9YlMAxd3ZdGMZo.9BQWL81GQSTma2IAuM5yZgSSa4WbVjGhPrZ9Bt7ZPM.45B0HHVixUQPv0otL0utEfDXsoqCEfrsJ.zByigE2BRQ3w058zpVk15h6lSSJyMS0VyhMJKSJCurl_DNCU.gsL9eT2P4rEK5vxvCgaHPsDUlpPglVjhHW2CCpHwF7BD5HSYRDPFvw_MINO8NbpSd4SKWh5xIN1plD9bQm4uSMLo489t7np Received: from [131.107.0.75] by web82602.mail.mud.yahoo.com via HTTP; Tue, 05 Jan 2010 11:32:36 PST X-Mailer: YahooMailRC/240.3 YahooMailWebService/0.8.100.260964 References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F0B9@il-ex01.ad.checkpoint.com> <7C362EEF9C7896468B36C9B79200D8350AB332DBC6@INBANSXCHMBSA1.in.alcatel-lucent.com> <20091229145338.EF067F2403E@odin.smetech.net> Date: Tue, 5 Jan 2010 11:32:36 -0800 (PST) From: gabriel montenegro To: Russ Housley , "Bhatia, Manav" In-Reply-To: <20091229145338.EF067F2403E@odin.smetech.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, iesg@ietf.org Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 19:39:21 -0000 Hi Russ,=0A=0AI'd like to comment on your assumption below that:=0A=0A> ...= the ICV protection =0A> imposes a requirement that the end system check the= WESP information that it =0A> does not need, and then discard the packet i= f the attacker altered it to the =0A> potential detriment of the middlebox"= =0A=0AThe underlying assumption seems to be that the end nodes do not need = to carry out=0Aany consistency checks. This contradicts the operating assum= ption we've been operating=0Aunder, as expressed by Steve Kent last May 12:= =0A=0Ahttp://www.ietf.org/mail-archive/web/ipsec/current/msg04359.html:=0A= =0AIf we elect to keep the next header field, to help middle boxes quickly = locate header fields of interest to them, then we MUST require the recipien= t of each message to do a (well-defined) consistency check on the packet, f= or the reasons I cited in SF. =0A=0Aand as discussed in San Francisco minut= es at:=0Ahttp://tools.ietf.org/wg/ipsecme/minutes?item=3Dminutes74.html=0A= =0A=0AOne may argue whether that consistency check is best served by extend= ing the ICV to include the=0AWESP header fields (per the current WG consens= us as expressed in the existing draft), or whether=0Athat is best done by t= he end nodes checking the fields explicitly. =0A=0AGabriel=0A=0A=0A----- Or= iginal Message ----=0A> From: Russ Housley =0A> To: "= Bhatia, Manav" =0A> Cc: ipsec@ietf.org; ie= sg@ietf.org=0A> Sent: Tue, December 29, 2009 6:32:54 AM=0A> Subject: Re: [I= Psec] DISCUSS: draft-ietf-ipsecme-traffic-visibility=0A> =0A> Manav:=0A> = =0A> I am unconvinced.=A0 If a malicious attacker is willing to alter packe= ts to fool =0A> middleboxes, this ICV does not help the middlebox and it ha= rms the end system.=A0 =0A> The middlebox cannot validate the ICV, and the = end system does not need the WESP =0A> header information.=A0 The end syste= m does not need the pointer data in the WESP =0A> header to process the pac= ket correctly; it already knows the size of the IV and =0A> other values as= sociated with the algorithms in use.=A0 Thus, the ICV protection =0A> impos= es a requirement that the end system check the WESP information that it =0A= > does not need, and then discard the packet if the attacker altered it to = the =0A> potential detriment of the middlebox.=0A> =0A> Russ=0A> =0A> At 09= :36 PM 12/28/2009, Bhatia, Manav (Manav) wrote:=0A> > Yes, this was discuss= ed in the WG =0A> (http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/104) a= nd the idea was this:=0A> > =0A> > We could have some malicious entity that= could modify the offsets to ensure =0A> that the intermediaries don't pars= e a portion of the payload (which could =0A> contain malicious content) or = inspect it differently than what it would have =0A> done otherwise. A way t= o protect against such attacks is to let the end node =0A> validate the WES= P header by including this as a part of the ESP ICV. If the =0A> computed I= CV does not match, the packet is dropped (usual IPSec processing).=0A> > = =0A> > This does not completely eliminate the vulnerability, but it does ra= ise the =0A> bar, because now the malicious routers would have to also posi= tion themselves =0A> both before and after the middle boxes in order to hav= e a chance to revert the =0A> packet back to its original form before the e= nd node verifies integrity over the =0A> packet.=0A> > =0A> > We have also = discussed this in the Security Considerations section of the =0A> draft.=0A= > > =0A> > We did informally speak to HW guys who are interested in impleme= nting WESP, =0A> and they confirmed that increasing the integrity protectio= n of ESP to now cover =0A> the WESP header is trivial.=0A> > =0A> > Cheers,= Manav=0A> > =0A> > > -----Original Message-----=0A> > > From: ipsec-bounce= s@ietf.org [mailto:ipsec-bounces@ietf.org]=0A> > > On Behalf Of Jack Kohn= =0A> > > Sent: Tuesday, December 29, 2009 6.17 AM=0A> > > To: Stephen Kent= =0A> > > Cc: ipsec@ietf.org; Russ Housley; iesg@ietf.org; Dan McDonald=0A> = > > Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility=0A>= > >=0A> > > Are you suggesting that ESP ICV should not cover the WESP fiel= ds?=0A> > >=0A> > > I think, and my memory could be failing me, that this w= as discussed in=0A> > > the WG before this got added to the draft.=0A> > >= =0A> > > Jack=0A> > >=0A> > > On Tue, Dec 29, 2009 at 2:15 AM, Stephen Kent= wrote:=0A> > > > Yaron,=0A> > > >=0A> > > > I hate to admit it, but I lost= track of the details of WESP=0A> > > as it progressed=0A> > > > through WG= discussions and briefings at IETF meetings. When=0A> > > I read the I-D=0A= > > > > in detail, I was very surprised to see that it was no longer a=0A> = > > > neatly-layered wrapper, as originally proposed.=A0 The fact=0A> > > t= hat it now calls=0A> > > > for the ESP ICV to be computed in a new fashion = means that=0A> > > it really is=0A> > > > replacing ESP, when used to mark = ESP-NULL packets.=0A> > > >=0A> > > > From a protocol design perspective, t= he current version=0A> > > makes no sense to=0A> > > > me. Why keep the ESP= header when ESP processing is now changed in a=0A> > > > significant way.= =A0 The WESP header cannot be processed=0A> > > (completely) by=0A> > > > i= tself, because of the dependence on the ESP ICV. So it=0A> > > makes little= or no=0A> > > > sense to retain the ESP header in this context. I see no= =0A> > > strong backward=0A> > > > compatibility motivation for this format= , given that ESP=0A> > > processing must=0A> > > > change to accommodate WE= SP (as defined).=0A> > > >=0A> > > > The issue of using WESP for marking en= crypted traffic is a=0A> > > separate topic. I=0A> > > > believe the ration= ale you cited was to enable WESP=0A> > > extensions, but I may=0A> > > > ha= ve missed other arguments put forth for this. Since most=0A> > > of the WES= P=0A> > > > extension proposals discussed so far have proven to be=0A> > > = questionable, I am=0A> > > > not enthusiastic about that rationale.=A0 Othe= rs have noted=0A> > > that using WESP=0A> > > > with encrypted traffic is n= ot consistent with the scope of=0A> > > the WG charter=0A> > > > item that = authorized work on WESP.=A0 Unless Pasi approves a=0A> > > WESP extension W= G=0A> > > > item as part of re-chartering, I think it is inappropriate=0A> = > > to have a flag to=0A> > > > mark a WESP payload as encrypted.=0A> > > >= =0A> > > > Steve=0A> > > > _______________________________________________= =0A> > > > IPsec mailing list=0A> > > > IPsec@ietf.org=0A> > > > https://ww= w.ietf.org/mailman/listinfo/ipsec=0A> > > >=0A> > > _______________________= ________________________=0A> > > IPsec mailing list=0A> > > IPsec@ietf.org= =0A> > > https://www.ietf.org/mailman/listinfo/ipsec=0A> > >=0A> > ________= _______________________________________=0A> > IPsec mailing list=0A> > IPse= c@ietf.org=0A> > https://www.ietf.org/mailman/listinfo/ipsec=0A> =0A> _____= __________________________________________=0A> IPsec mailing list=0A> IPsec= @ietf.org=0A> https://www.ietf.org/mailman/listinfo/ipsec=0A From paul.hoffman@vpnc.org Tue Jan 5 11:41:13 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14CCD28C1B9 for ; Tue, 5 Jan 2010 11:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.109 X-Spam-Level: X-Spam-Status: No, score=-6.109 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tU52n73KLooG for ; Tue, 5 Jan 2010 11:41:12 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 49F8D3A6942 for ; Tue, 5 Jan 2010 11:41:12 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o05Jf8lp085496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jan 2010 12:41:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <97635.97572.qm@web82601.mail.mud.yahoo.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <97635.97572.qm@web82601.mail.mud.yahoo.com> Date: Tue, 5 Jan 2010 11:41:07 -0800 To: gabriel montenegro , "ipsec@ietf.org" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 19:41:13 -0000 At 11:25 AM -0800 1/5/10, gabriel montenegro wrote: >I fully agree that a consensus call is an integral part of the IETF process. > >But what we're seeing here is not one but a plurality of consensus calls. The two questions that Yaron asked are related to the questions from the IESG. >I would have expected the response to the IESG to be: yes, this was the consensus arrived >in the WG at time X, here are further details, etc. The IESG fully understands that there was rough consensus; that's not what they are asking. They want to know if there was a strong consensus, and did we see that we were straying from the charter. >What we're seeing is: oh, ok, let's do it all over again. That is one possibility; another is "OK, that's fine". But it is the IESG that gets to make that determination, not the WG. --Paul Hoffman, Director --VPN Consortium From briansw@microsoft.com Tue Jan 5 11:50:05 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD8E63A693F for ; Tue, 5 Jan 2010 11:50:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrApnA5M7z9N for ; Tue, 5 Jan 2010 11:50:01 -0800 (PST) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 3BAF23A68FE for ; Tue, 5 Jan 2010 11:50:01 -0800 (PST) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 5 Jan 2010 11:49:59 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.0.639.20; Tue, 5 Jan 2010 11:49:59 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.138]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Tue, 5 Jan 2010 11:49:35 -0800 From: Brian Swander To: Yaron Sheffer , "ipsec@ietf.org" Thread-Topic: Traffic visibility - consensus call Thread-Index: AQHKjYZTQaGsaxOJ1EKbzfglwJmR2ZGF/XelgAFl4TA= Date: Tue, 5 Jan 2010 19:49:33 +0000 Message-ID: <5E38DBF64E732C4C98512C53E1B14DDC299B8912@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 19:50:05 -0000 Yes to both. To elaborate on what Ken said, here's an explicit scenario that requires th= e encrypted bit for WESP, fully within the current charter of enabling ESP-= NULL inspection. Transport policies for within an organization that want to enable intermedi= ary inspection of ESP-NULL non-heurisitically. Organization has a mix of v= ersion of systems. Sample policy: When talking to/from non-WESP capable machines: must do ESP-NULL only When both peers are WESP capable: do WESP/ESP-NULL most places. However, w= here policy requires encryption, do WESP/ESP. Only with the WESP encrypt bit can intermediaries distinguish what is going= on here, and still enable the uplevel systems to do full encryption where = needed. I.e. if they see ESP, it must be ESP-NULL. If they see WESP, then= they must leverage the encrypt bit to see what to do. Hence we need to keep the encrypted bit to satisfy the current WESP charter= item. bs -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= aron Sheffer Sent: Monday, January 04, 2010 2:27 PM To: ipsec@ietf.org Subject: [IPsec] Traffic visibility - consensus call Hi, We have had a few "discusses" during the IESG review of the WESP draft. To = help resolve them, we would like to reopen the following two questions to W= G discussion. Well reasoned answers are certainly appreciated. But plain "y= es" or "no" would also be useful in judging the group's consensus. - The current draft (http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-= visibility-11) defines the ESP trailer's ICV calculation to include the WES= P header. This has been done to counter certain attacks, but it means that = WESP is no longer a simple wrapper around ESP - ESP itself is modified. Do = you support this design decision? - The current draft allows WESP to be applied to encrypted ESP flows, in ad= dition to the originally specified ESP-null. This was intended so that encr= ypted flows can benefit from the future extensibility offered by WESP. But = arguably, it positions WESP as an alternative to ESP. Do you support this d= esign decision? Thanks, Yaron _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From M.Vondemkamp@F5.com Tue Jan 5 12:50:05 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24A693A6890 for ; Tue, 5 Jan 2010 12:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Feqeoyukmpkr for ; Tue, 5 Jan 2010 12:50:04 -0800 (PST) Received: from mail.f5.com (mail.f5.com [65.197.145.96]) by core3.amsl.com (Postfix) with ESMTP id 3F2EF3A684A for ; Tue, 5 Jan 2010 12:50:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=M.Vondemkamp@f5.com; q=dns/txt; s=seattle; t=1262724603; x=1294260603; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Mark=20Vondemkamp=20 |Subject:=20RE:=20=20[IPsec]=20Traffic=20visibility=20- =20consensus=20call|Date:=20Tue,=205=20Jan=202010=2012:47 :50=20-0800|Message-ID:=20|To:=20"ipsec@ietf. org"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20|References:=20; bh=uEP1uB9C5pY7Y/5ow9fn9090H4IwTxnn+p97tU1JEa8=; b=cjOubQIJO6+K6RR86zgZR1NNHDQvfo1Cg5QFPXE5FDRAA6LBksKQUI3Y S5PxVhNWzIUpTTrHWtK4LYNXNCfutfiNSiOCDVanaDC1DZrDTew1Auges bVkQ0rP0ww+l8iDXT8S/PzGNGiY2pb16TOCumSxoVmEShl8lhvPlJrVSx Q=; X-IronPort-AV: E=Sophos;i="4.49,224,1262563200"; d="scan'208";a="9190751" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.240]) by mail.f5.com with ESMTP/TLS/RC4-MD5; 05 Jan 2010 20:50:02 +0000 Received: from exch11.olympus.f5net.com ([192.168.16.104]) by e2k7ca1.olympus.f5net.com ([192.168.16.101]) with mapi; Tue, 5 Jan 2010 12:50:02 -0800 From: Mark Vondemkamp To: "ipsec@ietf.org" Date: Tue, 5 Jan 2010 12:47:50 -0800 Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AcqOAg4THpc884NsR2eEap19gd6FZAAQvGDg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 20:50:05 -0000 Yes and Yes. We see a lot of value in taking advantage of the extensibility of the proto= col as it stands in the WESP today. Allowing WESP to not be simply a wrappe= r, and enabling encryption support are both fundamental for the future exte= nsibilities. So we express our support of the these design decisions. Mark -----Original Message----- Date: Tue, 5 Jan 2010 00:27:26 +0200 From: Yaron Sheffer Subject: [IPsec] Traffic visibility - consensus call To: "ipsec@ietf.org" Hi, We have had a few "discusses" during the IESG review of the WESP draft. To = help resolve them, we would like to reopen the following two questions to W= G discussion. Well reasoned answers are certainly appreciated. But plain "y= es" or "no" would also be useful in judging the group's consensus. - The current draft (http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-= visibility-11) defines the ESP trailer's ICV calculation to include the WES= P header. This has been done to counter certain attacks, but it means that = WESP is no longer a simple wrapper around ESP - ESP itself is modified. Do = you support this design decision? - The current draft allows WESP to be applied to encrypted ESP flows, in ad= dition to the originally specified ESP-null. This was intended so that encr= ypted flows can benefit from the future extensibility offered by WESP. But = arguably, it positions WESP as an alternative to ESP. Do you support this d= esign decision? Thanks, Yaron From housley@vigilsec.com Tue Jan 5 13:11:22 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C81573A67F2 for ; Tue, 5 Jan 2010 13:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CepnwrroouGt for ; Tue, 5 Jan 2010 13:11:20 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 802C13A6767 for ; Tue, 5 Jan 2010 13:11:20 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id BA1269A4726; Tue, 5 Jan 2010 16:11:19 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id MNVoaR8gZ35J; Tue, 5 Jan 2010 16:11:18 -0500 (EST) Received: from [192.168.2.112] (pool-173-66-67-45.washdc.fios.verizon.net [173.66.67.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 2BA879A471B; Tue, 5 Jan 2010 16:11:19 -0500 (EST) Message-ID: <4B43AAF7.8030302@vigilsec.com> Date: Tue, 05 Jan 2010 16:11:19 -0500 From: Russ Housley User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: gabriel montenegro References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> In-Reply-To: <378834.93787.qm@web82602.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 21:11:22 -0000 Gabriel: This is being discussed to resolve the concerns that I raised in IESG Evaluation. When this work was chartered, I expected as simple wrapper. The charter says: > - A standards-track mechanism that allows an intermediary device, such > as a firewall or intrusion detection system, to easily and reliably > determine whether an ESP packet is encrypted with the NULL cipher; and > if it is, determine the location of the actual payload data inside the > packet. The starting points for this work item are > draft-grewal-ipsec-traffic-visibility and draft-hoffman-esp-null-protocol. I think the chartering discussion would have been very different had the charter said that the proposed WG would develop an alternative to ESP. Russ On 1/5/2010 2:08 PM, gabriel montenegro wrote: > But I'd also like to question the process being followed. We've discussed these points numerous times in f2f meetings, on the mailing list, at virtual interims, etc. So I'm surprised to see the already established consensus being questioned all over again. From housley@vigilsec.com Tue Jan 5 13:21:22 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E84ED3A684A; Tue, 5 Jan 2010 13:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9Y0UiyF1oXX; Tue, 5 Jan 2010 13:21:21 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 655663A68A7; Tue, 5 Jan 2010 13:21:21 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id C10689A4726; Tue, 5 Jan 2010 16:21:26 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id CG6F3Jjuz+jR; Tue, 5 Jan 2010 16:21:19 -0500 (EST) Received: from [192.168.2.112] (pool-173-66-67-45.washdc.fios.verizon.net [173.66.67.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 7F2799A471B; Tue, 5 Jan 2010 16:21:25 -0500 (EST) Message-ID: <4B43AD4F.3090109@vigilsec.com> Date: Tue, 05 Jan 2010 16:21:19 -0500 From: Russ Housley User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: gabriel montenegro References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F0B9@il-ex01.ad.checkpoint.com> <7C362EEF9C7896468B36C9B79200D8350AB332DBC6@INBANSXCHMBSA1.in.alcatel-lucent.com> <20091229145338.EF067F2403E@odin.smetech.net> <941690.12882.qm@web82602.mail.mud.yahoo.com> In-Reply-To: <941690.12882.qm@web82602.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, iesg@ietf.org Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 21:21:23 -0000 Gabriel: My point is that the end system does not need the information in the WESP header to properly handle the packet for the supported application. The additional information is being exposed to allow middle boxes to make various checks. The end system can ensure that the exposed information was correct so that middle boxes were not spoofed. An extended ICV is not necessary to perform this type of check if the information is limited to the payload offset and such. An ICV is only needed if WESP carries information that cannot be easily checked by a process that knows the crypto algorithms that are in use. I'm challenging the need for such information. Russ On 1/5/2010 2:32 PM, gabriel montenegro wrote: > Hi Russ, > > I'd like to comment on your assumption below that: > > >> ...the ICV protection >> imposes a requirement that the end system check the WESP information that it >> does not need, and then discard the packet if the attacker altered it to the >> potential detriment of the middlebox" >> > The underlying assumption seems to be that the end nodes do not need to carry out > any consistency checks. This contradicts the operating assumption we've been operating > under, as expressed by Steve Kent last May 12: > > http://www.ietf.org/mail-archive/web/ipsec/current/msg04359.html: > > If we elect to keep the next header field, to help middle boxes quickly locate header fields of interest to them, then we MUST require the recipient of each message to do a (well-defined) consistency check on the packet, for the reasons I cited in SF. > > and as discussed in San Francisco minutes at: > http://tools.ietf.org/wg/ipsecme/minutes?item=minutes74.html > > > One may argue whether that consistency check is best served by extending the ICV to include the > WESP header fields (per the current WG consensus as expressed in the existing draft), or whether > that is best done by the end nodes checking the fields explicitly. > > Gabriel > > > ----- Original Message ---- > >> From: Russ Housley >> To: "Bhatia, Manav" >> Cc: ipsec@ietf.org; iesg@ietf.org >> Sent: Tue, December 29, 2009 6:32:54 AM >> Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility >> >> Manav: >> >> I am unconvinced. If a malicious attacker is willing to alter packets to fool >> middleboxes, this ICV does not help the middlebox and it harms the end system. >> The middlebox cannot validate the ICV, and the end system does not need the WESP >> header information. The end system does not need the pointer data in the WESP >> header to process the packet correctly; it already knows the size of the IV and >> other values associated with the algorithms in use. Thus, the ICV protection >> imposes a requirement that the end system check the WESP information that it >> does not need, and then discard the packet if the attacker altered it to the >> potential detriment of the middlebox. >> >> Russ >> >> At 09:36 PM 12/28/2009, Bhatia, Manav (Manav) wrote: >> >>> Yes, this was discussed in the WG >>> >> (http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/104) and the idea was this: >> >>> We could have some malicious entity that could modify the offsets to ensure >>> >> that the intermediaries don't parse a portion of the payload (which could >> contain malicious content) or inspect it differently than what it would have >> done otherwise. A way to protect against such attacks is to let the end node >> validate the WESP header by including this as a part of the ESP ICV. If the >> computed ICV does not match, the packet is dropped (usual IPSec processing). >> >>> This does not completely eliminate the vulnerability, but it does raise the >>> >> bar, because now the malicious routers would have to also position themselves >> both before and after the middle boxes in order to have a chance to revert the >> packet back to its original form before the end node verifies integrity over the >> packet. >> >>> We have also discussed this in the Security Considerations section of the >>> >> draft. >> >>> We did informally speak to HW guys who are interested in implementing WESP, >>> >> and they confirmed that increasing the integrity protection of ESP to now cover >> the WESP header is trivial. >> >>> Cheers, Manav >>> >>> >>>> -----Original Message----- >>>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] >>>> On Behalf Of Jack Kohn >>>> Sent: Tuesday, December 29, 2009 6.17 AM >>>> To: Stephen Kent >>>> Cc: ipsec@ietf.org; Russ Housley; iesg@ietf.org; Dan McDonald >>>> Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility >>>> >>>> Are you suggesting that ESP ICV should not cover the WESP fields? >>>> >>>> I think, and my memory could be failing me, that this was discussed in >>>> the WG before this got added to the draft. >>>> >>>> Jack >>>> >>>> On Tue, Dec 29, 2009 at 2:15 AM, Stephen Kent wrote: >>>> >>>>> Yaron, >>>>> >>>>> I hate to admit it, but I lost track of the details of WESP >>>>> >>>> as it progressed >>>> >>>>> through WG discussions and briefings at IETF meetings. When >>>>> >>>> I read the I-D >>>> >>>>> in detail, I was very surprised to see that it was no longer a >>>>> neatly-layered wrapper, as originally proposed. The fact >>>>> >>>> that it now calls >>>> >>>>> for the ESP ICV to be computed in a new fashion means that >>>>> >>>> it really is >>>> >>>>> replacing ESP, when used to mark ESP-NULL packets. >>>>> >>>>> From a protocol design perspective, the current version >>>>> >>>> makes no sense to >>>> >>>>> me. Why keep the ESP header when ESP processing is now changed in a >>>>> significant way. The WESP header cannot be processed >>>>> >>>> (completely) by >>>> >>>>> itself, because of the dependence on the ESP ICV. So it >>>>> >>>> makes little or no >>>> >>>>> sense to retain the ESP header in this context. I see no >>>>> >>>> strong backward >>>> >>>>> compatibility motivation for this format, given that ESP >>>>> >>>> processing must >>>> >>>>> change to accommodate WESP (as defined). >>>>> >>>>> The issue of using WESP for marking encrypted traffic is a >>>>> >>>> separate topic. I >>>> >>>>> believe the rationale you cited was to enable WESP >>>>> >>>> extensions, but I may >>>> >>>>> have missed other arguments put forth for this. Since most >>>>> >>>> of the WESP >>>> >>>>> extension proposals discussed so far have proven to be >>>>> >>>> questionable, I am >>>> >>>>> not enthusiastic about that rationale. Others have noted >>>>> >>>> that using WESP >>>> >>>>> with encrypted traffic is not consistent with the scope of >>>>> >>>> the WG charter >>>> >>>>> item that authorized work on WESP. Unless Pasi approves a >>>>> >>>> WESP extension WG >>>> >>>>> item as part of re-chartering, I think it is inappropriate >>>>> >>>> to have a flag to >>>> >>>>> mark a WESP payload as encrypted. >>>>> >>>>> Steve >>>>> > > From g_e_montenegro@yahoo.com Tue Jan 5 13:32:24 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 987EF3A6938 for ; Tue, 5 Jan 2010 13:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlhZqi86P73D for ; Tue, 5 Jan 2010 13:32:23 -0800 (PST) Received: from web82604.mail.mud.yahoo.com (web82604.mail.mud.yahoo.com [68.142.201.121]) by core3.amsl.com (Postfix) with SMTP id 0C5EA28C0D9 for ; Tue, 5 Jan 2010 13:32:22 -0800 (PST) Received: (qmail 67858 invoked by uid 60001); 5 Jan 2010 21:32:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1262727138; bh=MyUkNmjGpawQn4x84/VP9J6OXwTcjwOt9eM1S74i5pc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=6QQt2HODTIt+TiYT68jRrVvbybX4f2mrEVPcxHAE4V+rfdxh0ck6efS1LGC5CBA6npEgWJM0SBmkosDP22pnr8hRNFUnJxYGejOI6q+UtpqGKWfnU35sqaQFmcDcg8G4PHnJsY4bTB2dptAvT0zbhsRNn1A9reqmgda4Z/POFeQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kEIkk1hAeXloc8J3NN65E6uuzsEuhBxAbimQDgxxNsvewzolSy2RY3eAxP0CtwlAHr6hRTJwrEIr1zuOyWazjc98nMcnYF9CbXxFrcnz/pn1l/jcuj9lejSVK6uk1pYYXL7yitzpPv11Vff3l0fTvmrtUK4LXAOubsKYqKo7v1k=; Message-ID: <734514.64270.qm@web82604.mail.mud.yahoo.com> X-YMail-OSG: WTTlctwVM1levOlIhQ1buj0.jhC71LPf8SOeuuKAK..bmflJVoEJqfiw_yBWCnXM7Z1aBy9TZFpuU4PYeTHmYRujvCrttrMSuQejYEiO47Tmaq38F6NFVJHVVQlr_pdxBEJDtS.sBS8cMOE9yjfRXWfG0WvHr.j5EafAc8AJdV5F2.5serInYnfqtYph1oqCHsKMwvpUngrt5urifa8dT2l4zSLbAyvSa0TTUWxF5NQ81femaWJjFXFGcUlL3Jtcs.4bwZ4zAo9ZcgUYrvqIliAwkUcKMfUqbsRk5a3KGMdxROX1HsWSMMpxGa0ySGwEvOHZ9LYUBLUn0Q61GMT7XG.R_kpveAGRzCqGG5s- Received: from [131.107.0.75] by web82604.mail.mud.yahoo.com via HTTP; Tue, 05 Jan 2010 13:32:18 PST X-Mailer: YahooMailRC/240.3 YahooMailWebService/0.8.100.260964 References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> Date: Tue, 5 Jan 2010 13:32:18 -0800 (PST) From: gabriel montenegro To: Russ Housley In-Reply-To: <4B43AAF7.8030302@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 21:32:24 -0000 Hi Russ,=0A=0ASome of us believe that allowing WESP to carry encrypted pack= ets=A0is within the charter=0A(there's some recent messages today to this e= ffect). Unfortunately, there's been wording along the lines=0Athat the work= ing group realized it was going off-charter, but no such conclusion has bee= n=0Aarrived at (and some of us don't share it). =0A=0AWithout this capabili= ty, there is not a complete solution for the charter item=A0as one might st= ill have to use =0Aheuristics which has some limitations and cost (e.g., pe= r Manav's recent message).=0A=0AAdditionally, allowing WESP to carry encryp= ted packets does not (at least in my mind)=0Amake it a general alternative= =A0for ESP. WESP has certain applicabilities, and when=0Acooperating with i= ntermediaries is not an issue (e.g., outside of organizational deployments)= =0Aone could use encrypted ESP packets instead.=0A=0Athanks,=0A=0AGabriel= =0A=0A=0A=0A----- Original Message ----=0A> From: Russ Housley =0A> To: gabriel montenegro =0A> Cc: "i= psec@ietf.org" =0A> Sent: Tue, January 5, 2010 1:11:19 PM= =0A> Subject: Re: [IPsec] Traffic visibility - consensus call=0A> =0A> Gabr= iel:=0A> =0A> This is being discussed to resolve the concerns that I raised= in IESG =0A> Evaluation.=0A> =0A> When this work was chartered, I expected= as simple wrapper.=A0 The charter says:=0A> =0A> > - A standards-track mec= hanism that allows an intermediary device, such=0A> > as a firewall or intr= usion detection system, to easily and reliably=0A> > determine whether an E= SP packet is encrypted with the NULL cipher; and=0A> > if it is, determine = the location of the actual payload data inside the=0A> > packet. The starti= ng points for this work item are=0A> > draft-grewal-ipsec-traffic-visibilit= y and draft-hoffman-esp-null-protocol.=0A> =0A> I think the chartering disc= ussion would have been very different had the charter =0A> said that the pr= oposed WG would develop an alternative to ESP.=0A> =0A> Russ=0A> =0A> On 1/= 5/2010 2:08 PM, gabriel montenegro wrote:=0A> > But I'd also like to questi= on the process being followed. We've discussed =0A> these points numerous t= imes in f2f meetings, on the mailing list, at virtual =0A> interims, etc. S= o I'm surprised to see the already established consensus being =0A> questio= ned all over again.=0A> =0A> ______________________________________________= _=0A> IPsec mailing list=0A> IPsec@ietf.org=0A> https://www.ietf.org/mailma= n/listinfo/ipsec=0A From briansw@microsoft.com Tue Jan 5 14:10:39 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C61D73A6868 for ; Tue, 5 Jan 2010 14:10:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnxHhjhC3TAo for ; Tue, 5 Jan 2010 14:10:37 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id EE73F3A659C for ; Tue, 5 Jan 2010 14:10:36 -0800 (PST) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 5 Jan 2010 14:11:15 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.0.639.21; Tue, 5 Jan 2010 14:10:30 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.138]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Tue, 5 Jan 2010 14:10:30 -0800 From: Brian Swander To: gabriel montenegro , Russ Housley Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AQHKjjsDFMfT79gUNESgtZlfXT4hYpGIAOaAgAAF3AD//4Pq4A== Date: Tue, 5 Jan 2010 22:10:28 +0000 Message-ID: <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> In-Reply-To: <734514.64270.qm@web82604.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 22:10:39 -0000 I'll resend my message from earlier today that gives a concrete scenario fo= r why the WESP encryption bit is in charter. =20 To satisfy the existing charter item, we need a deployable solution, which = entails working with legacy systems that don't support this functionality y= et. =20 Here's an explicit scenario that requires the encrypted bit for WESP, fully= within the current charter of enabling ESP-NULL inspection. Transport policies for within an organization that want to enable intermedi= ary inspection of ESP-NULL non-heurisitically. Organization has a mix of v= ersion of systems. Sample policy: When talking to/from non-WESP capable machines: must do ESP-NULL only=20 When both peers are WESP capable: do WESP/ESP-NULL most places. However, w= here policy requires encryption, do WESP/ESP. Only with the WESP encrypt bit can intermediaries distinguish what is going= on here, and still enable the uplevel systems to do full encryption where = needed. I.e. if they see ESP, it must be ESP-NULL. If they see WESP, then= they must leverage the encrypt bit to see what to do. Hence we need to keep the encrypted bit to satisfy the current WESP charter= item. bs -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of g= abriel montenegro Sent: Tuesday, January 05, 2010 1:32 PM To: Russ Housley Cc: ipsec@ietf.org Subject: Re: [IPsec] Traffic visibility - consensus call Hi Russ, Some of us believe that allowing WESP to carry encrypted packets=A0is withi= n the charter (there's some recent messages today to this effect). Unfortunately, there's= been wording along the lines that the working group realized it was going off-charter, but no such concl= usion has been arrived at (and some of us don't share it).=20 Without this capability, there is not a complete solution for the charter i= tem=A0as one might still have to use=20 heuristics which has some limitations and cost (e.g., per Manav's recent me= ssage). Additionally, allowing WESP to carry encrypted packets does not (at least i= n my mind) make it a general alternative=A0for ESP. WESP has certain applicabilities, = and when cooperating with intermediaries is not an issue (e.g., outside of organizat= ional deployments)=20 one could use encrypted ESP packets instead. thanks, Gabriel ----- Original Message ---- > From: Russ Housley > To: gabriel montenegro > Cc: "ipsec@ietf.org" > Sent: Tue, January 5, 2010 1:11:19 PM > Subject: Re: [IPsec] Traffic visibility - consensus call >=20 > Gabriel: >=20 > This is being discussed to resolve the concerns that I raised in IESG=20 > Evaluation. >=20 > When this work was chartered, I expected as simple wrapper.=A0 The charte= r says: >=20 > > - A standards-track mechanism that allows an intermediary device, such > > as a firewall or intrusion detection system, to easily and reliably > > determine whether an ESP packet is encrypted with the NULL cipher; and > > if it is, determine the location of the actual payload data inside the > > packet. The starting points for this work item are > > draft-grewal-ipsec-traffic-visibility and draft-hoffman-esp-null-protoc= ol. >=20 > I think the chartering discussion would have been very different had the = charter=20 > said that the proposed WG would develop an alternative to ESP. >=20 > Russ >=20 > On 1/5/2010 2:08 PM, gabriel montenegro wrote: > > But I'd also like to question the process being followed. We've discuss= ed=20 > these points numerous times in f2f meetings, on the mailing list, at virt= ual=20 > interims, etc. So I'm surprised to see the already established consensus = being=20 > questioned all over again. >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From housley@vigilsec.com Tue Jan 5 14:52:26 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 847323A6883 for ; Tue, 5 Jan 2010 14:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOGa3-4zq64n for ; Tue, 5 Jan 2010 14:52:25 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id C304A3A659C for ; Tue, 5 Jan 2010 14:52:25 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 51D6F9A4726; Tue, 5 Jan 2010 17:52:40 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id d0LxFowcsFXU; Tue, 5 Jan 2010 17:52:24 -0500 (EST) Received: from [192.168.2.112] (pool-173-66-67-45.washdc.fios.verizon.net [173.66.67.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id A5BB19A471B; Tue, 5 Jan 2010 17:52:39 -0500 (EST) Message-ID: <4B43C2A8.6010302@vigilsec.com> Date: Tue, 05 Jan 2010 17:52:24 -0500 From: Russ Housley User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: gabriel montenegro References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> In-Reply-To: <734514.64270.qm@web82604.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 22:52:26 -0000 Gabriel: > Some of us believe that allowing WESP to carry encrypted packets is within the charter > (there's some recent messages today to this effect). Unfortunately, there's been wording along the lines > that the working group realized it was going off-charter, but no such conclusion has been > arrived at (and some of us don't share it). I see the discussion, but so far, I am not convinced by it. I'm still listening ... > Additionally, allowing WESP to carry encrypted packets does not (at least in my mind) > make it a general alternative for ESP. WESP has certain applicabilities, and when > cooperating with intermediaries is not an issue (e.g., outside of organizational deployments) > one could use encrypted ESP packets instead. It is a replacement (as opposed to a wrapper) if the portions of the packet that are covered by the ICV are different. Russ From kohn.jack@gmail.com Tue Jan 5 15:32:22 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6ECB3A65A6 for ; Tue, 5 Jan 2010 15:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwlbgZLOqrUb for ; Tue, 5 Jan 2010 15:32:22 -0800 (PST) Received: from mail-yw0-f196.google.com (mail-yw0-f196.google.com [209.85.211.196]) by core3.amsl.com (Postfix) with ESMTP id D126E3A657C for ; Tue, 5 Jan 2010 15:32:21 -0800 (PST) Received: by ywh34 with SMTP id 34so10148166ywh.31 for ; Tue, 05 Jan 2010 15:32:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JANQOnh03CEdYVKKKoU2vaZbsdzFfG2ST9KehMjAtQY=; b=e3PYv0pIXJBmEVCMB3jn67SKYVxYpL7icb6fszWgM7taKCzuaFGWGmMW9UORvt4uU0 /VgqrPoleu+lN+vc0qpM9u2JTPp1vw6fTgpRl/d6970wQe+CnzUel0OUUqEAxs+wTn3e k+GJ604XkYOLrU3iD/06Ib+y71vMLUcQPVre8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qFwNTvdlpcV7BvzC7nZTNOvkJ8kFFUfXRqtZB7b4HK51/Y1tmD7Rmw88U+Wxb91LIR /C3ezW9D2vncVPmeiFBIKKVQITBjX1rUp/BAFNqDj3qkpHgzlfApDMeYs40+XMGs2+ml hBybLVUpCaRwKeosdr7loZSllvTukGIfP8eLU= MIME-Version: 1.0 Received: by 10.90.40.18 with SMTP id n18mr9358832agn.93.1262734337231; Tue, 05 Jan 2010 15:32:17 -0800 (PST) In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> Date: Wed, 6 Jan 2010 05:02:17 +0530 Message-ID: From: Jack Kohn To: Yaron Sheffer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 23:32:22 -0000 Yaron, On Tue, Jan 5, 2010 at 3:57 AM, Yaron Sheffer wrote= : > Hi, > > We have had a few "discusses" during the IESG review of the WESP draft. T= o help resolve them, we would like to reopen the following two questions to= WG discussion. Well reasoned answers are certainly appreciated. But plain = "yes" or "no" would also be useful in judging the group's consensus. > > - The current draft (http://tools.ietf.org/html/draft-ietf-ipsecme-traffi= c-visibility-11) defines the ESP trailer's ICV calculation to include > the= WESP header. This has been done to counter certain attacks, but it means t= hat WESP is no longer a simple wrapper around > ESP - ESP itself is modifie= d. Do you support this design decision? I had brought this up on the mailing list some time back that WESP now is not a mere "wrapper" over the ESP and is almost like a new protocol, which it anyways was designed to be. I dont see an issue with that. I dont hold a very strong opinion on whether we should include the WESP protocol header inside the ESP calculation or not and am also fine with the end nodes just doing a sanity check to ensure that things look alright when they receive the WESP protocol packets. > > - The current draft allows WESP to be applied to encrypted ESP flows, in = addition to the originally specified ESP-null. This was intended so that en= crypted flows can benefit from the future extensibility offered by WESP. And i strongly agree with this. It would be severely limiting to see WESP being only used for ESP-NULL cases. I see absolutely no harm in using WESP for encrypted traffic too. I agree with others on the list that by having WESP do encryption we provide the middle boxes with an easy/deterministic way to discriminate between integrity protected and encrypted packets, which is what we were chartered to do. I am not a big fan of flow based devices as these get really too hot to handle in scaled up networks and heuristics seems like a juvenile attempt at solving the problem. There have been various mails in the past about the issues in that scheme and i dont intend to rehash them here, so i'll this here. > But arguably, it positions WESP as an alternative to ESP. > It does not. ESP still has its own place and i dont see how having WESP ship ESP encrypted packets makes it a substitute of ESP. WESP will be required in the environments wherever we require deep inspection while ESP will continue where its not. > Do you support this design decision? Yes, i do. Jack > > Thanks, > =A0 =A0 Yaron > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From jtardo@broadcom.com Tue Jan 5 15:33:16 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A6003A6942 for ; Tue, 5 Jan 2010 15:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osSM+Zcjd72A for ; Tue, 5 Jan 2010 15:33:15 -0800 (PST) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id 500E23A693F for ; Tue, 5 Jan 2010 15:33:15 -0800 (PST) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 05 Jan 2010 15:33:03 -0800 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Tue, 5 Jan 2010 15:33:00 -0800 From: "Joseph Tardo" To: "ipsec@ietf.org" Date: Tue, 5 Jan 2010 15:32:59 -0800 Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AcqOOoqsoKTEDLJaT4aoIkszaT/YAwAA6D/Q Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD68163BE940B@SJEXCHCCR02.corp.ad.broadcom.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> In-Reply-To: <378834.93787.qm@web82602.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 675D13A538O61068999-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Jorge Coronel Mendoza , gabriel montenegro , "Grewal, Ken" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 23:33:16 -0000 Gabriel Montenegro wrote: > Just to be clear: I'm not saying that WESP is a general replacement for E= SP.=20 > As Steve Kent points out, where there are no trusted intermediary inspect= ion=20 > devices (i.e., outside of medium to large organizations) there is no need > for end-nodes to collaborate with the inspecting infrastructure, hence n= o > need for WESP. ESP is fine. Perhaps this is the disconnect that is happen= ing:=20 > traditionally, the focus of the IPsec WG has been on such external applic= ations > (VPN), whereas WESP and future potential extensibility is more valuable w= ithin=20 > organizations. Such value may not be as obvious to VPN folks. =A0 This sounds like an argument for being able to strip off the internal netwo= rk WESP header at a perimeter intermediate system. That same perimeter box = can apply Tero's heuristics and then add the header for so the intermediate= systems don't need to. Voila, instant upgrade value for the VPN folks. Which, of course, would not be possible with the ICV over the WESP header. On the other hand, I don't really buy the 'slippery slope' arguments. I hav= e read the charter for this work item over a couple of times and WESP with = encryption still looks consistent to me. So, here's my opinion: - YES on allowing use of WESP when using ESP with encryption - NO on including the WESP header in the ICV calculation, the endpoints hav= e to deal with attacks in any case. By the way, WESP extension drafts that propose arbitrary new mutable fields= for use with ESP just reinforce that NO.=20 Thanks, --Joe= From kohn.jack@gmail.com Tue Jan 5 15:44:24 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DE553A68C3 for ; Tue, 5 Jan 2010 15:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvTCjZWfsKfH for ; Tue, 5 Jan 2010 15:44:23 -0800 (PST) Received: from mail-yx0-f174.google.com (mail-yx0-f174.google.com [209.85.210.174]) by core3.amsl.com (Postfix) with ESMTP id A7C4A3A657C for ; Tue, 5 Jan 2010 15:44:23 -0800 (PST) Received: by yxe4 with SMTP id 4so15147583yxe.32 for ; Tue, 05 Jan 2010 15:44:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8J5jvR4myR5TvLXTvxWKVbL5fIdPfLwC/G6OrMgaN0I=; b=fVPsdZ2Wj3UCDKa/JlVqnHYVUFT6D3nKHxUUsltrXGW3BLWmJY8RlAGnuG3lcYuBYe b9Ghc5FbMXrdYVABiRBP6yHntmYDE1O98hfr0njFJ+3IKKN2A+we0OtXk/7ByGyFCVwc 8nue5f2MbqjG83CQevq1eQXPwrJeQAMVBzXMc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hmOaxulIwDDo7/fatPQiNu2QV9qyC2IODrXdU8OO3tz+FPFpjdb5WypKBxhZwPbdmk uHj46ZPkK74Y9S343tttevIt7vuYbihyT0w5yjSclz4kkWgwDlm9E2vJHBugwQvFJ37Q u+B3jhSTWJ0QihuyaE+fP7Gfvve+l/aBbfX7M= MIME-Version: 1.0 Received: by 10.91.63.29 with SMTP id q29mr6808732agk.72.1262735058625; Tue, 05 Jan 2010 15:44:18 -0800 (PST) In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> Date: Wed, 6 Jan 2010 05:14:18 +0530 Message-ID: From: Jack Kohn To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 23:44:24 -0000 > Even if WESP is approved for use with encrypted traffic, that does not me= an > that it will supplant ESP. =A0ESP still has a smaller header than WESP, s= o for > environments where there is no intent to accommodate middlebox snooping, = ESP > is still preferable. I agree with Steve here that extending WESP to support encryption does not mean that it will be replacing ESP. The latter would still get used, as i noted in my earlier email, in environments where there is no need for deep packet inspection. Jack From kohn.jack@gmail.com Tue Jan 5 15:55:12 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1D6D3A65A6 for ; Tue, 5 Jan 2010 15:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4jHG-ejyVXt for ; Tue, 5 Jan 2010 15:55:11 -0800 (PST) Received: from mail-yw0-f196.google.com (mail-yw0-f196.google.com [209.85.211.196]) by core3.amsl.com (Postfix) with ESMTP id 62FCE3A657C for ; Tue, 5 Jan 2010 15:55:10 -0800 (PST) Received: by ywh34 with SMTP id 34so10166146ywh.31 for ; Tue, 05 Jan 2010 15:55:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=buXp/xFRO0szTsd6Pe7IE1RrNZHLvik58uqHqZ07B9w=; b=iW5aA13VS4EhuhA8BcleNrU5yHWTH8voIeq6LY568cPMbO6dqGeStxIx2qZwa8BxZ4 /eY2ocLaIg5hW66kdXq20jKkMlPQL7LpROVQGCCp1PQylDm083HU1XkYTre0Dgg804vO 4wYNC6ab5nNrxDQgl5iPuYqCk3da0KlB4j2eg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=No6cgC+g0EcIEDexVoKtUNMdPY8knBF5NtTMrG01xjFq97YuZszLcrM9JhUCB588Xx tt5emr1SQ6vux5Abx8lnKdqLDP5f+eUGX1YgfgRF4rCB//3ZpBJxbH7+pnhNF5S8oW0e JNZx+5RGwp5wPfW59h1Azv9UUqCVhyTZXQ7uA= MIME-Version: 1.0 Received: by 10.91.26.9 with SMTP id d9mr13043562agj.16.1262735706157; Tue, 05 Jan 2010 15:55:06 -0800 (PST) In-Reply-To: <378834.93787.qm@web82602.mail.mud.yahoo.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> Date: Wed, 6 Jan 2010 05:25:06 +0530 Message-ID: From: Jack Kohn To: gabriel montenegro Content-Type: text/plain; charset=ISO-8859-1 Cc: "ipsec@ietf.org" , "Grewal, Ken" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 23:55:12 -0000 > There is a need per the charter for a mechanism to > "easily and reliably" determine the type of traffic. Within an organization, it would be much easier to use > WESP encryption as an alternative to ESP. If one sees ESP packets, then one would have to run heuristics > with all the pertaining issues as explained in Manav's recent message, and higher cost associated > (particularly, in stateless high aggregation points). WESP with encryption support would allow an > organization to simplify rules and inspection devices. Sure, the WESP header adds more bytes, but the > tradeoff is that there is no need for costly heuristics throughout the network. Without WESP encryption, > the charter item does not have a complete solution. I agree. I, like others, and unlike the authors of heuristics, would never like to see heuristics implemented in a network, because it is not going to work. Period. It requires too much from the devices to do, and its simply not practical (refer to past mails in the WG list). One can clearly gauge the interest in heuristics vis-a-vis WESP by the amount of mails and the review comments that have been sent/exchanged. WESP provides a simple, clean, deterministic way to disambiguate between encrypted and unencrypted traffic and i would like to see it this way. > > Just to be clear: I'm not saying that WESP is a general replacement for ESP. As Steve Kent points out, > where there are no trusted intermediary inspection devices (i.e., outside of medium to large organizations) > there is no need for end-nodes to collaborate with the inspecting infrastructure, hence no need for > WESP. ESP is fine. I agree and would like to stress that WESP is not a replacement for ESP. I repeat for the benefit of others that extending WESP to carry encrypted packets does not mean that it is replacing ESP. Jack From kohn.jack@gmail.com Tue Jan 5 16:01:32 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 868B43A6958 for ; Tue, 5 Jan 2010 16:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76XkJqymZYOD for ; Tue, 5 Jan 2010 16:01:31 -0800 (PST) Received: from mail-yx0-f174.google.com (mail-yx0-f174.google.com [209.85.210.174]) by core3.amsl.com (Postfix) with ESMTP id BB2EE3A65A6 for ; Tue, 5 Jan 2010 16:01:31 -0800 (PST) Received: by yxe4 with SMTP id 4so15160981yxe.32 for ; Tue, 05 Jan 2010 16:01:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=2vdj/PR2+sNKEziwzUt/sPtdFAmUbAGXt0l9UfPtqL0=; b=Ydsi7qsVJ0IYxkPQIOs4ySR1kt5WraTM4FYq26d5HPfYR+3EBlD6qfnf/RAPGdJ2t0 bk/wOPBxRCFdL6vSDaII4HlYU/kAk5iJ4c0saxZsryJpXmNuuG6X7iG3+rUqukQgh2pA 4esrT2nS1m8HBA4lC4BJl7+x4eeWWHKITkSpw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LUWSrMShxgUQJ2Y3xT01NoaDQPc5/Ww+xxllzw1oswpq3/Zx5nkJkCvSDq0Kf4VuyI ExSWAPE8BFmAU4HQUaozU5Q8HuD0e7HJF3bb0+ivMVI1Ms3lAvE9YndraZiQ6zusW7qN tWAKbgMptPykn5cdpof0xVqMFHRd8KtgrxX40= MIME-Version: 1.0 Received: by 10.90.8.13 with SMTP id 13mr8497006agh.89.1262736081114; Tue, 05 Jan 2010 16:01:21 -0800 (PST) In-Reply-To: <4B43C2A8.6010302@vigilsec.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <4B43C2A8.6010302@vigilsec.com> Date: Wed, 6 Jan 2010 05:31:20 +0530 Message-ID: From: Jack Kohn To: Russ Housley Content-Type: text/plain; charset=ISO-8859-1 Cc: "ipsec@ietf.org" , gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 00:01:32 -0000 Russ, > > It is a replacement (as opposed to a wrapper) if the portions of the packet > that are covered by the ICV are different. Would it help if WESP is renamed to something else? Since we're discussing the fundamental principles of the protocol, i see no reason why we cant change the name, if that helps. I think its the "Wrapped" in the WESP thats causing most heart burn, lets change that to something else .. something thats appeases everyone. Jack From manav.bhatia@alcatel-lucent.com Tue Jan 5 17:56:54 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFFF23A67E1 for ; Tue, 5 Jan 2010 17:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Q1qmYnJURi4 for ; Tue, 5 Jan 2010 17:56:53 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by core3.amsl.com (Postfix) with ESMTP id 1A7063A657C for ; Tue, 5 Jan 2010 17:56:52 -0800 (PST) Received: from horh1.usa.alcatel.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id o061uokG006983; Tue, 5 Jan 2010 19:56:50 -0600 (CST) Received: from mail.apac.alcatel-lucent.com (aprelay03.apac.alcatel-lucent.com [202.65.2.133]) by horh1.usa.alcatel.com (8.13.8/emsr) with ESMTP id o061umvB007094; Tue, 5 Jan 2010 19:56:49 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by mail.apac.alcatel-lucent.com (8.13.7/8.13.7/Alcanet1.0) with ESMTP id o06273CM027276; Wed, 6 Jan 2010 10:07:03 +0800 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 6 Jan 2010 07:26:46 +0530 From: "Bhatia, Manav (Manav)" To: Russ Housley , gabriel montenegro Date: Wed, 6 Jan 2010 07:26:43 +0530 Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AcqOS6cAX0GumPDsRfmRZZ6tSIZRugAIxz7w Message-ID: <7C362EEF9C7896468B36C9B79200D8350AB33FDDD8@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> In-Reply-To: <4B43AAF7.8030302@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 172.22.12.28 X-Scanned-By: MIMEDefang 2.64 on 202.65.2.133 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 01:56:54 -0000 Hi Russ, =20 > > - A standards-track mechanism that allows an intermediary=20 > device, such > > as a firewall or intrusion detection system, to easily and reliably > > determine whether an ESP packet is encrypted with the NULL=20 > cipher; and > > if it is, determine the location of the actual payload=20 > data inside the > > packet. The starting points for this work item are > > draft-grewal-ipsec-traffic-visibility and=20 > draft-hoffman-esp-null-protocol. >=20 > I think the chartering discussion would have been very=20 > different had the=20 > charter said that the proposed WG would develop an alternative to ESP. I don't think WESP is in any sense an alternative to ESP and I believe we d= id stick to the charter, which was to provide a *deterministic* way to disa= mbiguate different ESP packets. I understand that the word "deterministic" is missing from the charter text= , but it was obvious to everyone working in IPSec that WESP was to be a *de= terministic* solution. Now, assume that we limit WESP for only ESP-NULL. If this is done, how can = a middle box deterministically know that the ESP packet that it sees is an = encrypted ESP packet or an ESP packet carrying ESP-NULL payload. The middle= boxes will now be forced to apply heuristics just to be sure that the packe= t is indeed an encrypted ESP packet. This would defeat the purpose of havin= g WESP in the network. So, when including the encryption bit in the WESP header we never thought t= hat it was out of the charter (as others have also noted in the mailing lis= t) as it was really being used to provide a deterministic answer to whether= the packet was encrypted or not. We really don't have a complete solution if we don't include the encryption= bit in the WESP header. Cheers, Manav From g_e_montenegro@yahoo.com Tue Jan 5 18:15:26 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C8D73A67BD for ; Tue, 5 Jan 2010 18:15:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mMMwpEnCvAJ for ; Tue, 5 Jan 2010 18:15:25 -0800 (PST) Received: from web82608.mail.mud.yahoo.com (web82608.mail.mud.yahoo.com [68.142.201.125]) by core3.amsl.com (Postfix) with SMTP id 676993A67B6 for ; Tue, 5 Jan 2010 18:15:25 -0800 (PST) Received: (qmail 91638 invoked by uid 60001); 6 Jan 2010 02:15:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1262744120; bh=6puiEvRWFR1iBbIVghqDnt7uYhPiS429RlCTRH0rmiw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=IKEiXJQKHu+OhTfG8zDLvRh8RBKmo3UrnJCJ/fmQ8Xvb4n2Ydt8QUzIdNdoUv9yBMVCyclIF+/ATZQVa3hRBWc7QhiVeFkdOLXtioJ6zr4Aojn7CehW1FAGFKIwBRN7UNDIpHizDwUcR36WoINFMcuiMQCNHjCu9orKB+ILmVU4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=4X5eBaEiXI9NlqHjh3NQyb8Pv9iyVcuBDJXt/Jsjw20Scy4EXB7NAnaUEbuDtWdQGFh0mjiBBOX9RC3vlZrcptvFBSFzQJYU+MOsdFxojJ9Gpj5SWgVbnetWGc5GE0EcWwIEega1VNdvIe53Tj9k3s0ts/MbuqofizMYOx9FQxg=; Message-ID: <390631.89326.qm@web82608.mail.mud.yahoo.com> X-YMail-OSG: D5swXjEVM1kKjQ7l.KCD.2ZrW7bNm_yOEkAEs1tDYyHhPDhJov27GH2TISjfIKmjXnP3YxjGle76I5Y2ZXc3YTJdOHUAVQy.baL4aHQDHFg02o5v16a7KQR3ww1pIoG_qmf0wRklNkPhv6FP5HMkFMWGCGiG6nyfHcI9ggZSgR.kQL4zvbXRAmWAuzokQ_zh6IJvLjA8R1gUoPukZaKQxyKXPQ09PX9xIG3UYC9lCq56T_b266.BxFF.xqFnpUY0E4yLn1mPNa6ZP4yK8MIjW87_7ZoqWu5S1CVasRrioPhcCIafsnj0E3coCjPvZ04Bk6fUDK9xvX052A-- Received: from [131.107.0.75] by web82608.mail.mud.yahoo.com via HTTP; Tue, 05 Jan 2010 18:15:20 PST X-Mailer: YahooMailRC/240.3 YahooMailWebService/0.8.100.260964 References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <4B43C2A8.6010302@vigilsec.com> Date: Tue, 5 Jan 2010 18:15:20 -0800 (PST) From: gabriel montenegro To: Russ Housley In-Reply-To: <4B43C2A8.6010302@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 02:15:26 -0000 Russ,=0A=0AI think we agree here: the end nodes need to validate the WESP h= eader info.=0A=0AAs I noted before, one could do this by modifying the ICV = or by explicitly checking those =0AWESP fields at the end nodes. I think th= ere has been enough feedback to the effect that=0Amodifying the ICV is over= kill and has some down sides. =0A=0ASo, ok, I think in the=A0next rev of th= e draft=A0we should=A0go back to *not* modifying the ICV (i.e., not =0Aincl= uding the WESP header fields in the ICV). This would leave WESP as a wrappe= r (as it started).=0A=0AThe other threads and messages are hopefully addres= sing your other concerns.=0A=0Athanks,=0A=0AGabriel=0A=0A=0A----- Original = Message ----=0A> From: Russ Housley =0A> To: gabriel = montenegro =0A> Cc: "ipsec@ietf.org" =0A> Sent: Tue, January 5, 2010 2:52:24 PM=0A> Subject: Re: [IPsec] Tra= ffic visibility - consensus call=0A> =0A> Gabriel:=0A> =0A> > Some of us be= lieve that allowing WESP to carry encrypted packets is within the =0A> char= ter=0A> > (there's some recent messages today to this effect). Unfortunatel= y, there's =0A> been wording along the lines=0A> > that the working group r= ealized it was going off-charter, but no such =0A> conclusion has been=0A> = > arrived at (and some of us don't share it).=0A> =0A> I see the discussion= , but so far, I am not convinced by it.=A0 I'm still listening =0A> ...=0A>= =0A> > Additionally, allowing WESP to carry encrypted packets does not (at= least in =0A> my mind)=0A> > make it a general alternative for ESP. WESP h= as certain applicabilities, and =0A> when=0A> > cooperating with intermedia= ries is not an issue (e.g., outside of =0A> organizational deployments)=0A>= > one could use encrypted ESP packets instead.=0A> =0A> It is a replacemen= t (as opposed to a wrapper) if the portions of the packet that =0A> are cov= ered by the ICV are different.=0A> =0A> Russ=0A> __________________________= _____________________=0A> IPsec mailing list=0A> IPsec@ietf.org=0A> https:/= /www.ietf.org/mailman/listinfo/ipsec=0A From caozhenpku@gmail.com Tue Jan 5 18:19:40 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D45D63A67BD for ; Tue, 5 Jan 2010 18:19:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2WEz1ust-cV for ; Tue, 5 Jan 2010 18:19:39 -0800 (PST) Received: from mail-px0-f186.google.com (mail-px0-f186.google.com [209.85.216.186]) by core3.amsl.com (Postfix) with ESMTP id 3BB7D3A67A3 for ; Tue, 5 Jan 2010 18:19:39 -0800 (PST) Received: by pxi16 with SMTP id 16so2906226pxi.29 for ; Tue, 05 Jan 2010 18:19:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=DZ8zo4U8vgIPV17bY1HFXz3EDIwrHd+rGW1bHLaZH8Y=; b=EEISgZMDMJEeQDdhPpuBgj19w30j8mVGJ9GlMk7jehicVcChyydVGv5aWznSLJX7Sa aue2ex/y6Vbx71+tdelerYkcYgZbf+lACgOwczvAuU1Xl/3a2eJtIjs5iXisSA27I0h5 g8/s844WuhcoCEofT9/vdzCeFjr00n32Olo0s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=If33zkOeBDNjpqzcF0vU/OGVyadUZFJpGEPeiHHPdKwENSnwywT8Dw04UhtNca+3Q5 mz2+MNfjMzgXt6pFIjjG3xN/sw0IQaEc7fxX7tz4zfGdD8dwF26+mrP4nDYIVEJ2S/eN GxptSuskrDvD+9s13aCJ8yYr6NMRQcApa62/c= MIME-Version: 1.0 Received: by 10.142.59.13 with SMTP id h13mr295845wfa.3.1262744375669; Tue, 05 Jan 2010 18:19:35 -0800 (PST) In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> Date: Wed, 6 Jan 2010 10:19:35 +0800 Message-ID: From: Zhen Cao To: Yaron Sheffer Content-Type: multipart/alternative; boundary=00504502c138f434ed047c7595e8 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 02:19:41 -0000 --00504502c138f434ed047c7595e8 Content-Type: text/plain; charset=ISO-8859-1 Yes to both. Zhen China Mobile On Tue, Jan 5, 2010 at 6:27 AM, Yaron Sheffer wrote: > Hi, > > We have had a few "discusses" during the IESG review of the WESP draft. To > help resolve them, we would like to reopen the following two questions to WG > discussion. Well reasoned answers are certainly appreciated. But plain "yes" > or "no" would also be useful in judging the group's consensus. > > - The current draft ( > http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11) > defines the ESP trailer's ICV calculation to include the WESP header. This > has been done to counter certain attacks, but it means that WESP is no > longer a simple wrapper around ESP - ESP itself is modified. Do you support > this design decision? > Yes, we need to protect the message integrity while offering traffic visibility. > > - The current draft allows WESP to be applied to encrypted ESP flows, in > addition to the originally specified ESP-null. This was intended so that > encrypted flows can benefit from the future extensibility offered by WESP. > But arguably, it positions WESP as an alternative to ESP. Do you support > this design decision? > Yes, future extensibility is a feature that will benefit traffic control for operators and other entities. > Thanks, > Yaron > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --00504502c138f434ed047c7595e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes to both.=A0

Zhen=A0
China Mobile

On Tue, Jan 5, 2010 at 6:27 AM, Yaron Sheffer <yaronf@checkpoin= t.com> wrote:
Hi,

We have had a few "discusses" during the IESG review of the WESP = draft. To help resolve them, we would like to reopen the following two ques= tions to WG discussion. Well reasoned answers are certainly appreciated. Bu= t plain "yes" or "no" would also be useful in judging t= he group's consensus.

- The current draft (http://tools.ietf.org/html/draf= t-ietf-ipsecme-traffic-visibility-11) defines the ESP trailer's ICV= calculation to include the WESP header. This has been done to counter cert= ain attacks, but it means that WESP is no longer a simple wrapper around ES= P - ESP itself is modified. Do you support this design decision?

Yes, we need to protect the message integr= ity while offering traffic visibility.=A0
=A0

- The current draft allows WESP to be applied to encrypted ESP flows, in ad= dition to the originally specified ESP-null. This was intended so that encr= ypted flows can benefit from the future extensibility offered by WESP. But = arguably, it positions WESP as an alternative to ESP. Do you support this d= esign decision?

Yes, future extensibility is a feature tha= t will benefit traffic control for operators and other entities.=A0


Thanks,
=A0 =A0 Yaron
_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec

--00504502c138f434ed047c7595e8-- From manav.bhatia@alcatel-lucent.com Tue Jan 5 19:47:40 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6C333A677D; Tue, 5 Jan 2010 19:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ue7zdhX6Ria4; Tue, 5 Jan 2010 19:47:40 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by core3.amsl.com (Postfix) with ESMTP id 034F03A683E; Tue, 5 Jan 2010 19:47:39 -0800 (PST) Received: from horh1.usa.alcatel.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id o063lca8027038; Tue, 5 Jan 2010 21:47:38 -0600 (CST) Received: from mail.apac.alcatel-lucent.com (aprelay03.apac.alcatel-lucent.com [202.65.2.133]) by horh1.usa.alcatel.com (8.13.8/emsr) with ESMTP id o063laCM016055; Tue, 5 Jan 2010 21:47:37 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by mail.apac.alcatel-lucent.com (8.13.7/8.13.7/Alcanet1.0) with ESMTP id o063vp9H011338; Wed, 6 Jan 2010 11:57:51 +0800 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Wed, 6 Jan 2010 09:17:34 +0530 From: "Bhatia, Manav (Manav)" To: Russ Housley , gabriel montenegro Date: Wed, 6 Jan 2010 09:16:58 +0530 Thread-Topic: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility Thread-Index: AcqOTQw/Vl5HQKqESc2J8SCvKbN1dwANb1uQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350AB33FDE01@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F0B9@il-ex01.ad.checkpoint.com> <7C362EEF9C7896468B36C9B79200D8350AB332DBC6@INBANSXCHMBSA1.in.alcatel-lucent.com> <20091229145338.EF067F2403E@odin.smetech.net> <941690.12882.qm@web82602.mail.mud.yahoo.com> <4B43AD4F.3090109@vigilsec.com> In-Reply-To: <4B43AD4F.3090109@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 172.22.12.27 X-Scanned-By: MIMEDefang 2.64 on 202.65.2.133 Cc: "ipsec@ietf.org" , "iesg@ietf.org" Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 03:47:40 -0000 Hi Russ, =20 > My point is that the end system does not need the information in the=20 > WESP header to properly handle the packet for the supported=20 > application. The additional information is being exposed to allow=20 > middle boxes to make various checks. The end system can=20 > ensure that the=20 > exposed information was correct so that middle boxes were not=20 > spoofed.=20 > An extended ICV is not necessary to perform this type of check if the=20 > information is limited to the payload offset and such. An=20 > ICV is only=20 > needed if WESP carries information that cannot be easily checked by a=20 > process that knows the crypto algorithms that are in use. I'm=20 > challenging the need for such information. One use case could be when you want to prioritize processing certain ESP-NU= LL packets (most routing applications for instance mandate the use of ESP-N= ULL as routing is not concerned with confidentiality) over the other. The H= W computes the ICV, determines everything is correct and hands over the pac= ket to the IPSec engine. The IPSec engine, briefly inspects the WESP header= (and it knows its correct because it passed the preliminary ICV validation= check) and looks at the right offsets and depending upon the kind of packe= t it is, places it in the appropriate queue. With WESP the HW knows the exa= ct offsets it has to look at to figure out the information it needs and can= be done in the fast path.=20 OTOH, if we don't include the WESP header in the ICV, then the IPSec engine= has to process each packet completely, verify that the WESP header is inde= ed correct and matches with whats carried inside the packet, before it can = do any further processing. This can take up some time, which may be an issu= e for applications that need faster processing (a protocol like BFD for ins= tance). I currently don't see applications that may need this kind of expedited pro= cessing, but the WESP design should not preclude development of such applic= ations/features. However, if folks feel very strongly about not including WESP fields in the= ICV, then I would take a back seat and grudgingly concede to it .. Cheers, Manav From paul.hoffman@vpnc.org Tue Jan 5 20:07:58 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91FA03A683E; Tue, 5 Jan 2010 20:07:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.078 X-Spam-Level: X-Spam-Status: No, score=-6.078 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSnorOtp8VJt; Tue, 5 Jan 2010 20:07:57 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id BA63E3A63EB; Tue, 5 Jan 2010 20:07:57 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0647q1e010608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jan 2010 21:07:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350AB33FDE01@INBANSXCHMBSA1.in.alcatel-luce nt.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F0B9@il-ex01.ad.checkpoint.com> <7C362EEF9C7896468B36C9B79200D8350AB332DBC6@INBANSXCHMBSA1.in.alcatel-luce nt.com> <20091229145338.EF067F2403E@odin.smetech.net> <941690.12882.qm@web82602.mail.mud.yahoo.com> <4B43AD4F.3090109@vigilsec.com> <7C362EEF9C7896468B36C9B79200D8350AB33FDE01@INBANSXCHMBSA1.in.alcatel-luce nt.com> Date: Tue, 5 Jan 2010 20:07:51 -0800 To: "Bhatia, Manav (Manav)" , Russ Housley , gabriel montenegro From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "ipsec@ietf.org" , "iesg@ietf.org" Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 04:07:58 -0000 Kind-of wearing my co-chair hat: At 9:16 AM +0530 1/6/10, Bhatia, Manav (Manav) wrote: >I currently don't see applications that may need this kind of expedited processing, but the WESP design should not preclude development of such applications/features. We have heard a number of statements like this. Please note that WESP was designed for one purpose (making ESP-NULL easier to find) and then the WG realized that we could make it extensible. The latter may be nice, but it should not drive our work unless there is a use case that has stronger-than-rough WG consensus. Nothing precludes us from having both WESP and adding an extensibility mechanism later when there are agreed-on needs. --Paul Hoffman, Director --VPN Consortium From vnktshsriram@gmail.com Tue Jan 5 20:15:54 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AA083A677D for ; Tue, 5 Jan 2010 20:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyUHl49D5T5W for ; Tue, 5 Jan 2010 20:15:53 -0800 (PST) Received: from mail-vw0-f193.google.com (mail-vw0-f193.google.com [209.85.212.193]) by core3.amsl.com (Postfix) with ESMTP id 4B5D63A63EB for ; Tue, 5 Jan 2010 20:15:53 -0800 (PST) Received: by vws31 with SMTP id 31so5605946vws.29 for ; Tue, 05 Jan 2010 20:15:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=EtFvrZzrNh5i/X0Imy1mYBim22OlFcTFhFuKUCaSVN4=; b=UEs+h+OyKgeZWSSqrP6o7sAKqPxma5y7eKD9z98wLrvC26XC3ss6OyzdAcs+bS+vdY Ct34ndxnbJMQxQRfCY/wntTgENo+18gmBLPpnONaDP3sbYPfI+kzytGjv600VE4Zt2Wy /lY2Vr6dKJoAp0po0V5EBi7FdkeJZohEYcGVo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=WHSK4INpnccwRRn9rK7SNW3jCh2niLAYSwiEPYEAwQ1rIROAQGrtrcy5HwfHRUj2gv weAr12g8gU+sn7CAf86Pt56uYIzaMgQHFxJzgehShDItrFzP3gH1SBW+RVNQge3CI3zw SQTtkXIo0p7GZQO6/J/FNagSbPdc3aQ44S4MI= MIME-Version: 1.0 Received: by 10.220.127.1 with SMTP id e1mr864255vcs.49.1262751349352; Tue, 05 Jan 2010 20:15:49 -0800 (PST) In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <4B43C2A8.6010302@vigilsec.com> Date: Wed, 6 Jan 2010 09:45:49 +0530 Message-ID: From: Venkatesh Sriram To: "ipsec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 04:15:54 -0000 > Would it help if WESP is renamed to something else? Since we're > discussing the fundamental principles of the protocol, i see no reason > why we cant change the name, if that helps. I think its the "Wrapped" > in the WESP thats causing most heart burn, lets change that to > something else .. something thats appeases everyone. I agree. How about VESP - "Visible ESP" ? Its phonetically the same as WESP. :) I agree that WESP should not be clipped to only support ESP-NULL; it should be able to carry encrypted packets as well. Without this the middle boxes would never know whether the ESP packet thats passing is encrypted or not. One way could be to deprecate the use of ESP-NULL in ESP, which would mean that if someone sees an ESP packet then it MUST be an encrypted packet. This is as i understand impossible, so the only option left is to let WESP also carry encrypted packets. Sriram From smoonen@us.ibm.com Wed Jan 6 05:38:14 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CAF73A67FE; Wed, 6 Jan 2010 05:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMHiWzh7F7nS; Wed, 6 Jan 2010 05:38:12 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by core3.amsl.com (Postfix) with ESMTP id 9316B3A6838; Wed, 6 Jan 2010 05:38:12 -0800 (PST) Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e34.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id o06DWKGI003010; Wed, 6 Jan 2010 06:32:20 -0700 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o06DbsjH148688; Wed, 6 Jan 2010 06:37:54 -0700 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o06DbsX2012155; Wed, 6 Jan 2010 06:37:54 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av05.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o06Dbs2O012149; Wed, 6 Jan 2010 06:37:54 -0700 In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <4B43C2A8.6010302@vigilsec.com> To: Venkatesh Sriram MIME-Version: 1.0 X-KeepSent: DB2E7C79:DFE38544-852576A3:004102B7; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/06/2010 08:34:39 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/06/2010 08:34:39 AM, Serialize complete at 01/06/2010 08:34:39 AM, S/MIME Sign failed at 01/06/2010 08:34:39 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 01/06/2010 06:37:54, Serialize complete at 01/06/2010 06:37:54 Message-ID: Date: Wed, 6 Jan 2010 08:37:54 -0500 Content-Type: multipart/alternative; boundary="=_alternative 004A956C852576A3_=" Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 13:38:14 -0000 This is a multipart message in MIME format. --=_alternative 004A956C852576A3_= Content-Type: text/plain; charset="US-ASCII" Venkatesh said: > I agree that WESP should not be clipped to only support ESP-NULL; it > should be able to carry encrypted packets as well. Without this the > middle boxes would never know whether the ESP packet thats passing is > encrypted or not. Earlier, Manav said: > Now, assume that we limit WESP for only ESP-NULL. If this is done, how > can a middle box deterministically know that the ESP packet that it > sees is an encrypted ESP packet or an ESP packet carrying ESP-NULL > payload. I don't follow the argument. Because 1) a middle box can't trust that an ESP packet is not ESP-NULL, therefore 2) we are going to allow WESP to carry encrypted ESP? That is either begging the question or else it is simply an invalid argument. Allowing platform A to use WESP to carry encrypted ESP has nothing to do with how likely it is that platform B will use WESP to carry its ESP-NULL packets. The middle box's problem is not solved by this. That needs to be addressed by other means (convince people to use WESP for ESP-NULL, or mandate it). I am not saying that there is no possible case to be made for WESP to carry encrypted packets, just that this argument does not support that. The hidden assumption here still seems to be that WESP either is or ought to become ESPv4. The reality is that with WESP as the alternative, ESP is not going away and ESP-NULL is probably also not going away. I personally cannot envision being able to justify implementing WESP even for ESP-NULL on my own platform. The middle boxes are dependent on end nodes if they want widespread WESP adoption. I must say that the middle-box folks have been doing a lot less sweet talking and receptive listening than I would have expected given this arrangement. :) That leads me to predict a very doubtful future for WESP even if we were to reach perfect consensus on its technical make-up. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Venkatesh Sriram To: "ipsec@ietf.org" Date: 01/05/2010 11:16 PM Subject: Re: [IPsec] Traffic visibility - consensus call > Would it help if WESP is renamed to something else? Since we're > discussing the fundamental principles of the protocol, i see no reason > why we cant change the name, if that helps. I think its the "Wrapped" > in the WESP thats causing most heart burn, lets change that to > something else .. something thats appeases everyone. I agree. How about VESP - "Visible ESP" ? Its phonetically the same as WESP. :) I agree that WESP should not be clipped to only support ESP-NULL; it should be able to carry encrypted packets as well. Without this the middle boxes would never know whether the ESP packet thats passing is encrypted or not. One way could be to deprecate the use of ESP-NULL in ESP, which would mean that if someone sees an ESP packet then it MUST be an encrypted packet. This is as i understand impossible, so the only option left is to let WESP also carry encrypted packets. Sriram _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 004A956C852576A3_= Content-Type: text/html; charset="US-ASCII"
Venkatesh said:
> I agree that WESP should not be clipped to only support ESP-NULL; it
> should be able to carry encrypted packets as well. Without this the
> middle boxes would never know whether the ESP packet thats passing is
> encrypted or not.

Earlier, Manav said:
> Now, assume that we limit WESP for only ESP-NULL. If this is done, how
> can a middle box deterministically know that the ESP packet that it
> sees is an encrypted ESP packet or an ESP packet carrying ESP-NULL
> payload.

I don't follow the argument.  Because 1) a middle box can't trust that an ESP packet is not ESP-NULL, therefore 2) we are going to allow WESP to carry encrypted ESP?  That is either begging the question or else it is simply an invalid argument.  Allowing platform A to use WESP to carry encrypted ESP has nothing to do with how likely it is that platform B will use WESP to carry its ESP-NULL packets.  The middle box's problem is not solved by this.  That needs to be addressed by other means (convince people to use WESP for ESP-NULL, or mandate it).  I am not saying that there is no possible case to be made for WESP to carry encrypted packets, just that this argument does not support that.

The hidden assumption here still seems to be that WESP either is or ought to become ESPv4.  The reality is that with WESP as the alternative, ESP is not going away and ESP-NULL is probably also not going away.  I personally cannot envision being able to justify implementing WESP even for ESP-NULL on my own platform.

The middle boxes are dependent on end nodes if they want widespread WESP adoption.  I must say that the middle-box folks have been doing a lot less sweet talking and receptive listening than I would have expected given this arrangement. :)  That leads me to predict a very doubtful future for WESP even if we were to reach perfect consensus on its technical make-up.


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen


From: Venkatesh Sriram <vnktshsriram@gmail.com>
To: "ipsec@ietf.org" <ipsec@ietf.org>
Date: 01/05/2010 11:16 PM
Subject: Re: [IPsec] Traffic visibility - consensus call




> Would it help if WESP is renamed to something else? Since we're
> discussing the fundamental principles of the protocol, i see no reason
> why we cant change the name, if that helps. I think its the "Wrapped"
> in the WESP thats causing most heart burn, lets change that to
> something else .. something thats appeases everyone.

I agree. How about VESP - "Visible ESP" ? Its phonetically the same as WESP. :)

I agree that WESP should not be clipped to only support ESP-NULL; it
should be able to carry encrypted packets as well. Without this the
middle boxes would never know whether the ESP packet thats passing is
encrypted or not. One way could be to deprecate the use of ESP-NULL in
ESP, which would mean that if someone sees an ESP packet then it MUST
be an encrypted packet.

This is as i understand impossible, so the only option left is to let
WESP also carry encrypted packets.

Sriram
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--=_alternative 004A956C852576A3_=-- From kent@bbn.com Wed Jan 6 07:00:54 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 906073A6849 for ; Wed, 6 Jan 2010 07:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNldAwZOYU28 for ; Wed, 6 Jan 2010 07:00:53 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 81E593A659B for ; Wed, 6 Jan 2010 07:00:53 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.5]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NSXNR-0001V5-CA; Wed, 06 Jan 2010 10:00:50 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> Date: Wed, 6 Jan 2010 09:28:30 -0500 To: "Grewal, Ken" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 15:00:54 -0000 At 11:14 AM -0700 1/5/10, Grewal, Ken wrote: >Yes to both, based on arguments already discussed numerous times in >the WG via presentations, 12 iterations of the draft and multiple WG >last calls + AD reviews! > >The main motivation for extending the ICV was to counter some of the >issues originally raised by Steve Kent - malicious entities >modifying portions of the WESP header to bypass legitimate parsing >of the packet by Trusted Intermediary (TI) devices such as >IDS/IPS/etc. This can be addressed by the recipient explicitly >validating the WESP header before accepting the packet or implicitly >by including the WESP header as part of the ICV check. My recollection is that I identified a vulnerability that arose because of the potential for a mismatch between what a TI checked and what the receiver acted upon, irrespective of how that mismatch arose. I think I suggested that this vulnerability might be remedied by requiring the receiver to verify that the WESP header info was consistent with what the receiver was acting upon, as part of WESP processing. The current I-D calls for this check to be performed by the recipient. Above you state that: "This can be addressed by the recipient explicitly validating the WESP header before accepting the packet or implicitly by including the WESP header as part of the ICV check." I disagree with the "or" in this sentence, for two reasons. First, the I-D calls for the receiver to perform the consistency check, so it's not an "or." Second, it would not suffice to perform JUST the ICV check you described, since that would not address the possibility that the sender created the misleading WESP header. >The motivation for allowing WESP to be used for encrypted data was >brought up as a consistency argument and also allows for future >extensibility in a uniform manner. I agree that this was not part of >the original charter, as shown in the earlier revisions of the WESP >drafts. It appears that we agree that it was out of scope (although others do not), and that the principle motivation cited was to allow for extensions. The phrase :in a uniform manner" is, I believe, shorthand for extensions that apply to encrypted traffic, right? >BUT, this was discussed numerous times within the WG (including an >open ticket on scope) and it was agreed that this would be a useful >bit to include in the flags, hence introduced in the latter >revisions of the draft. I have already admitted that I lost track of this aspect of the discussion, among all of the ticket items that the WG has processed. (BTW, I congratulate Paul and Yaron for doing a very good job of managing such a large number of issues in a detailed fashion. The fact that I, and maybe a few other folks, lost track of the details on one of the many items being worked is not a reflection on the management style that have employed.) When I re-read the I-D during IETF last call, I was surprised to learn that ESP processing had been changed, so cause the ICV to cover non-ESP fields. This seems to be unnecessary and it is a bad design, in my opinion. >Note that this does not mandate using WESP for encrypted traffic, >but allows it as optional and can be dictated as part of the session >setup based on local policy. Another benefit may be that in running >mixed mode environments (encrypted + ESP_NULL traffic), it allows >for an explicit distinction from the packet that certain traffic is >encrypted and other traffic is not. Otherwise, one would use ESP and >WESP in these mixed mode environments and to be absolutely sure if >ESP traffic is encrypted or not, would need to fall back to >heuristics, which somewhat defeats the object of having this spec. If local policy can be used to dictate whether WESP is or is not used for encrypted traffic, then that policy also can dictate that ESP is used only for encrypted traffic. Even in an environment where some but not all hosts support WESP, I don't see the need for this flag. A host that is WESP capable need not use WESP for encrypted traffic; it can use ESP. if so, then ITs see three classes of traffic: - encrypted using ESP - integrity-protected using WESP - integrity-protected using ESP The third class of traffic poses a problem for the ITs, but adding the encrypted flag to WESP does not seem to address that problem. Steve From kent@bbn.com Wed Jan 6 07:00:57 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02F403A689C; Wed, 6 Jan 2010 07:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KvmBMJw1zcq; Wed, 6 Jan 2010 07:00:56 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 11F3A3A6888; Wed, 6 Jan 2010 07:00:56 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.5]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NSXNU-0001V5-9n; Wed, 06 Jan 2010 10:00:52 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <941690.12882.qm@web82602.mail.mud.yahoo.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F0B9@il-ex01.ad.checkpoint.com> <7C362EEF9C7896468B36C9B79200D8350AB332DBC6@INBANSXCHMBSA1.in.alcatel-luce nt.com> <20091229145338.EF067F2403E@odin.smetech.net> <941690.12882.qm@web82602.mail.mud.yahoo.com> Date: Wed, 6 Jan 2010 09:39:33 -0500 To: gabriel montenegro From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: ipsec@ietf.org, "Bhatia, Manav" , Russ Housley , iesg@ietf.org Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 15:00:57 -0000 Gabriel, >... >One may argue whether that consistency check is best served by >extending the ICV to include the >WESP header fields (per the current WG consensus as expressed in the >existing draft), or whether >that is best done by the end nodes checking the fields explicitly. > My reply to Ken addresses the issue you raise about the need for consistency checks. I don't think there is a misunderstanding here. The I-D calls for such checks and I agree that they are the right thing to do. What is at issue, in part, is whether the ESP ICV should have been extended to cover the WESP header. My view, and that of several other folks, is that it should not have been done, for the reasons I cited previously. This aspect of the current I-D could be fixed by having WESP have NO ICV, of by having WESP include its own ICV, which would call for nested processing by hosts. As I explained in my reply to Ken, extending the ESP ICV does not achieve the same effect, so this is not an "either or" situation. On a broader note, as Paul and Russ noted, the IESG gets to decide whether a WG-approved I-D will be published as an RFC (modulo appeals to the IAB, etc.). The IETF last allows anyone, even members of the WG that approved an I-D, to raise questions that the IESG will consider as part of the approval process. I've had over 15 years of experience as a WG chair (opening for Paul to make a snide comment :-)) and I have had WG members raise questions during IETF LC, after WG consensus has been achieved. This is how our process works. Also, even in the face of WG consensus, an AD may request changes to a document. This is not uncommon. when this has happened in the PKIX context, the Wg chairs and document authors have discussed the requested changes with the AD and we have almost always made the changes. Sometimes this has required another WGLC. Steve From kent@bbn.com Wed Jan 6 07:16:25 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CB1A28C0FE for ; Wed, 6 Jan 2010 07:16:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbsYtQcTXNLB for ; Wed, 6 Jan 2010 07:16:24 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 986F128C113 for ; Wed, 6 Jan 2010 07:16:24 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.5]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NSXX5-0001gA-Ci; Wed, 06 Jan 2010 10:10:48 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> Date: Wed, 6 Jan 2010 10:06:37 -0500 To: Brian Swander From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" , Russ Housley , gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 15:16:25 -0000 At 10:10 PM +0000 1/5/10, Brian Swander wrote: >I'll resend my message from earlier today that gives a concrete >scenario for why the WESP encryption bit is in charter. > >To satisfy the existing charter item, we need a deployable solution, >which entails working with legacy systems that don't support this >functionality yet. > >Here's an explicit scenario that requires the encrypted bit for >WESP, fully within the current charter of enabling ESP-NULL >inspection. > >Transport policies for within an organization that want to enable >intermediary inspection of ESP-NULL non-heurisitically. >Organization has a mix of version of systems. > >Sample policy: >When talking to/from non-WESP capable machines: must do ESP-NULL only >When both peers are WESP capable: do WESP/ESP-NULL most places. >However, where policy requires encryption, do WESP/ESP. This is where I have a problem with the analysis. If the policy were that WESP-capable hosts did ESP when then needed to send encrypted traffic, the flag inn question would not be needed, right? I don't think we can justify the inclusion of this flag based on the scenario you described above, because that scenario adopts a particular local policy that it not required. Steve From yaronf@checkpoint.com Wed Jan 6 07:19:29 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B0953A6896; Wed, 6 Jan 2010 07:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8Q9jy6bOYHd; Wed, 6 Jan 2010 07:19:28 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 0413E3A687D; Wed, 6 Jan 2010 07:19:27 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o06FJOT7017445; Wed, 6 Jan 2010 17:19:24 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 6 Jan 2010 17:19:37 +0200 From: Yaron Sheffer To: Scott C Moonen , Venkatesh Sriram Date: Wed, 6 Jan 2010 17:19:20 +0200 Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AcqO1Yrrn7Ay/aLmTuKxqLSvth3gcQACmATg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C506D@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <4B43C2A8.6010302@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , "ipsec-bounces@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 15:19:29 -0000 I would like to reframe the migration discussion. Manav, Scott and everyone= else, please correct me if I got it wrong. Suppose we have a middlebox that can do useful things if it knows that the = flow is unencrypted, and only basic things if it is encrypted. A load balan= cer is a good example. We are slowly migrating all endpoints in an enterprise to be WESP-capable. = During the migration period, the middlebox sees 3 or 4 types of traffic: 1. WESP from the new nodes. 2. Depending on your view of whether we have the bit in question: encrypted= ESP from WESP-capable ("new") nodes. 3. Encrypted ESP from WESP-incapable ("old") nodes. 4. And ESP-null from old nodes. Taking Manav's perspective, the middlebox can always use heuristics to dist= inguish encrypted ESP from ESP-null. As the number of WESP-capable nodes gr= ows, it will see less and less ESP, so will spend ever less CPU power on he= uristics. According to Scott, the middlebox should have a big red switch with two set= tings: initially most nodes are WESP-incapable, so it should use heuristics= to analyze ESP packets. When the time comes when "almost" all endpoint are= WESP-capable, we turn the switch and now we assume all ESP is encrypted, w= ith no per-flow analysis. Unless we do so, we will be wasting CPU on heuris= tics forever. Are these the alternatives we are facing? And if so, what is the preferred = migration scenario? Thanks, Yaron From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of S= cott C Moonen Sent: Wednesday, January 06, 2010 15:38 To: Venkatesh Sriram Cc: ipsec@ietf.org; ipsec-bounces@ietf.org Subject: Re: [IPsec] Traffic visibility - consensus call Venkatesh said:=20 > I agree that WESP should not be clipped to only support ESP-NULL; it > should be able to carry encrypted packets as well. Without this the > middle boxes would never know whether the ESP packet thats passing is > encrypted or not.=20 Earlier, Manav said:=20 > Now, assume that we limit WESP for only ESP-NULL. If this is done, how=20 > can a middle box deterministically know that the ESP packet that it=20 > sees is an encrypted ESP packet or an ESP packet carrying ESP-NULL=20 > payload.=20 I don't follow the argument. =A0Because 1) a middle box can't trust that an= ESP packet is not ESP-NULL, therefore 2) we are going to allow WESP to car= ry encrypted ESP? =A0That is either begging the question or else it is simp= ly an invalid argument. =A0Allowing platform A to use WESP to carry encrypt= ed ESP has nothing to do with how likely it is that platform B will use WES= P to carry its ESP-NULL packets. =A0The middle box's problem is not solved = by this. =A0That needs to be addressed by other means (convince people to u= se WESP for ESP-NULL, or mandate it). =A0I am not saying that there is no p= ossible case to be made for WESP to carry encrypted packets, just that this= argument does not support that.=20 The hidden assumption here still seems to be that WESP either is or ought t= o become ESPv4. =A0The reality is that with WESP as the alternative, ESP is= not going away and ESP-NULL is probably also not going away. =A0I personal= ly cannot envision being able to justify implementing WESP even for ESP-NUL= L on my own platform.=20 The middle boxes are dependent on end nodes if they want widespread WESP ad= option. =A0I must say that the middle-box folks have been doing a lot less = sweet talking and receptive listening than I would have expected given this= arrangement. :) =A0That leads me to predict a very doubtful future for WES= P even if we were to reach perfect consensus on its technical make-up.=20 Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen=20 From:=20 Venkatesh Sriram =20 To:=20 "ipsec@ietf.org" =20 Date:=20 01/05/2010 11:16 PM=20 Subject:=20 Re: [IPsec] Traffic visibility - consensus call ________________________________________ > Would it help if WESP is renamed to something else? Since we're > discussing the fundamental principles of the protocol, i see no reason > why we cant change the name, if that helps. I think its the "Wrapped" > in the WESP thats causing most heart burn, lets change that to > something else .. something thats appeases everyone. I agree. How about VESP - "Visible ESP" ? Its phonetically the same as WESP= . :) I agree that WESP should not be clipped to only support ESP-NULL; it should be able to carry encrypted packets as well. Without this the middle boxes would never know whether the ESP packet thats passing is encrypted or not. One way could be to deprecate the use of ESP-NULL in ESP, which would mean that if someone sees an ESP packet then it MUST be an encrypted packet. This is as i understand impossible, so the only option left is to let WESP also carry encrypted packets. Sriram _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From dgrebovich@avaya.com Tue Jan 5 13:23:10 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 782003A6934 for ; Tue, 5 Jan 2010 13:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPVQApq7SgqW for ; Tue, 5 Jan 2010 13:23:09 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 1561E3A691B for ; Tue, 5 Jan 2010 13:23:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,224,1262581200"; d="scan'208";a="198108841" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 05 Jan 2010 16:23:07 -0500 Received: from unknown (HELO zcars04f.nortel.com) ([47.129.242.57]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Jan 2010 16:23:07 -0500 Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o05LMkK07398 for ; Tue, 5 Jan 2010 21:22:46 GMT Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o05LMhc07409 for ; Tue, 5 Jan 2010 21:22:44 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Jan 2010 16:22:23 -0500 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40A9B7634@zrtphxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AcqOAg4THpc884NsR2eEap19gd6FZAAQvGDgAAFbd6A= References: From: "Dragan Grebovich" To: X-Mailman-Approved-At: Wed, 06 Jan 2010 08:02:29 -0800 Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 21:26:22 -0000 Yes and Yes. I supported WESP from the beginning, because it allows intermediate systems to perform DPI on ESP-NULL packets. I was not in favor of heuristics - not because it is a bad solution (on the contrary) - but because many products we have/make today could not be upgraded to support it. Manav gave an excellent summary the other day. I also view that the extensibility of the protocol as it stands in the WESP today allows a smooth evolution path for fixing an obvious problem and allowing support of new services. I would not deprecate ESP for a long time because there is a wide customer base that cannot be ripped out. I would work within the present charter, if possible. If it takes a new charter to codify ESPv4, I am fine with that too, and let's use WESP as a base. =20 There is always going to be equipment mix of multiple vintages and capabilities. Systems capable of supporting (extensible) WESP should be able to take advantage of that. Some systems may not be able to support encrypted WESP and would work with ESP-NULL only. Legacy systems (non-WESP capable) must be able to perform as they do today (ignoring WESP packets and forwarding them uninspected). =20 Dragan -----Original Message----- Date: Tue, 5 Jan 2010 00:27:26 +0200 From: Yaron Sheffer Subject: [IPsec] Traffic visibility - consensus call To: "ipsec@ietf.org" Hi, We have had a few "discusses" during the IESG review of the WESP draft. To help resolve them, we would like to reopen the following two questions to WG discussion. Well reasoned answers are certainly appreciated. But plain "yes" or "no" would also be useful in judging the group's consensus. - The current draft (http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11) defines the ESP trailer's ICV calculation to include the WESP header. This has been done to counter certain attacks, but it means that WESP is no longer a simple wrapper around ESP - ESP itself is modified. Do you support this design decision? - The current draft allows WESP to be applied to encrypted ESP flows, in addition to the originally specified ESP-null. This was intended so that encrypted flows can benefit from the future extensibility offered by WESP. But arguably, it positions WESP as an alternative to ESP. Do you support this design decision? Thanks, Yaron _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From housley@vigilsec.com Wed Jan 6 08:36:40 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EDAC28C135 for ; Wed, 6 Jan 2010 08:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCmEks9JTS8a for ; Wed, 6 Jan 2010 08:36:39 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 717DF28C132 for ; Wed, 6 Jan 2010 08:36:39 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 12BFD9A472E; Wed, 6 Jan 2010 11:36:47 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id bjhxqSmc1qMN; Wed, 6 Jan 2010 11:36:36 -0500 (EST) Received: from [192.168.2.112] (pool-173-66-67-45.washdc.fios.verizon.net [173.66.67.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 909579A4732; Wed, 6 Jan 2010 11:36:45 -0500 (EST) Message-ID: <4B44BC14.3000906@vigilsec.com> Date: Wed, 06 Jan 2010 11:36:36 -0500 From: Russ Housley User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: Jack Kohn References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <4B43C2A8.6010302@vigilsec.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 16:36:40 -0000 Jack: The name sets incorrect expectations, but that is not on my list of concerns. Russ On 1/5/2010 7:01 PM, Jack Kohn wrote: > Russ, > >> >> It is a replacement (as opposed to a wrapper) if the portions of the packet >> that are covered by the ICV are different. > > Would it help if WESP is renamed to something else? Since we're > discussing the fundamental principles of the protocol, i see no reason > why we cant change the name, if that helps. I think its the "Wrapped" > in the WESP thats causing most heart burn, lets change that to > something else .. something thats appeases everyone. > > Jack > From kent@bbn.com Wed Jan 6 09:00:14 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC38E3A6908 for ; Wed, 6 Jan 2010 09:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6jT8PHODvJA for ; Wed, 6 Jan 2010 09:00:13 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 0460728C0E4 for ; Wed, 6 Jan 2010 09:00:13 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.5]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NSZEw-0004Nx-CX; Wed, 06 Jan 2010 12:00:11 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <4B43C2A8.6010302@vigilsec.com> Date: Wed, 6 Jan 2010 11:43:46 -0500 To: Venkatesh Sriram From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 17:00:14 -0000 At 9:45 AM +0530 1/6/10, Venkatesh Sriram wrote: > > Would it help if WESP is renamed to something else? Since we're >> discussing the fundamental principles of the protocol, i see no reason >> why we cant change the name, if that helps. I think its the "Wrapped" >> in the WESP thats causing most heart burn, lets change that to >> something else .. something thats appeases everyone. > >I agree. How about VESP - "Visible ESP" ? Its phonetically the same >as WESP. :) > >I agree that WESP should not be clipped to only support ESP-NULL; WESP was not initially proposed as a protocol that would encapsulate encrypted traffic, so the term "clipped" is approproprioate only relative to what WESP has mutated to become :-). >it >should be able to carry encrypted packets as well. Without this the >middle boxes would never know whether the ESP packet thats passing is >encrypted or not. One way could be to deprecate the use of ESP-NULL in >ESP, which would mean that if someone sees an ESP packet then it MUST >be an encrypted packet. This is a local policy decision that avoid the need to have a flag in the WESP header to indicate encrypted content. It need not be a standards track action, as you suggest above. >This is as i understand impossible, so the only option left is to let >WESP also carry encrypted packets. It certainly is not impossible as a local policy. Steve From kent@bbn.com Wed Jan 6 09:31:25 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 553FC28C0D0; Wed, 6 Jan 2010 09:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDwx8KarsSpO; Wed, 6 Jan 2010 09:31:24 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 0FB1E28C102; Wed, 6 Jan 2010 09:31:24 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.5]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NSZj6-0005OD-Bk; Wed, 06 Jan 2010 12:31:20 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C506D@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <4B43C2A8.6010302@vigilsec.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C506D@il-ex01.ad.checkpoint.com> Date: Wed, 6 Jan 2010 12:10:19 -0500 To: Yaron Sheffer From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" , Venkatesh Sriram , "ipsec-bounces@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 17:31:25 -0000 At 5:19 PM +0200 1/6/10, Yaron Sheffer wrote: >I would like to reframe the migration discussion. Manav, Scott and >everyone else, please correct me if I got it wrong. > >Suppose we have a middlebox that can do useful things if it knows >that the flow is unencrypted, and only basic things if it is >encrypted. A load balancer is a good example. > >We are slowly migrating all endpoints in an enterprise to be >WESP-capable. During the migration period, the middlebox sees 3 or 4 >types of traffic: > >1. WESP from the new nodes. >2. Depending on your view of whether we have the bit in question: >encrypted ESP from WESP-capable ("new") nodes. >3. Encrypted ESP from WESP-incapable ("old") nodes. >4. And ESP-null from old nodes. > >Taking Manav's perspective, the middlebox can always use heuristics >to distinguish encrypted ESP from ESP-null. As the number of >WESP-capable nodes grows, it will see less and less ESP, so will >spend ever less CPU power on heuristics. It's not clear why nodes sending encrypted traffic would need to use WESP (vs. native ESP), even if there is a WESP flag that indicates an encrypted payload. Thus I don't agree with the conclusion that over time there would be less ESP over all. If you said there would be less use of ESP-NULL (w/o a WES header), I would agree. To suggest otherwise is to pre-suppose that replacing ESP with WESP in general is a goal, and I certainly don't think the WG has indicated that (nor is it in scope at this time). Steve From briansw@microsoft.com Wed Jan 6 09:35:49 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E069728C0E8; Wed, 6 Jan 2010 09:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAQrX+jtJgh6; Wed, 6 Jan 2010 09:35:48 -0800 (PST) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 3C9FC28C0E4; Wed, 6 Jan 2010 09:35:48 -0800 (PST) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 6 Jan 2010 09:35:48 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.0.639.20; Wed, 6 Jan 2010 09:35:47 -0800 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.27]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Wed, 6 Jan 2010 09:35:46 -0800 From: Brian Swander To: Scott C Moonen , Venkatesh Sriram Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AQHKjjsDFMfT79gUNESgtZlfXT4hYpGIAOaAgAAF3ACAABZiAIAAE0IAgABHGoCAAJ0MAP//u+LA Date: Wed, 6 Jan 2010 17:35:46 +0000 Message-ID: <47FF8C26716A4E45993305F326EFE4A2017D2A@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <4B43C2A8.6010302@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_47FF8C26716A4E45993305F326EFE4A2017D2ATK5EX14MBXW603win_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" , "ipsec-bounces@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 17:35:50 -0000 --_000_47FF8C26716A4E45993305F326EFE4A2017D2ATK5EX14MBXW603win_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Take a look at the policy sketch I sent our yesterday for how to roll this = out in a mixed mode environment. That should clarify all your questions. bs From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of S= cott C Moonen Sent: Wednesday, January 06, 2010 5:38 AM To: Venkatesh Sriram Cc: ipsec@ietf.org; ipsec-bounces@ietf.org Subject: Re: [IPsec] Traffic visibility - consensus call Venkatesh said: > I agree that WESP should not be clipped to only support ESP-NULL; it > should be able to carry encrypted packets as well. Without this the > middle boxes would never know whether the ESP packet thats passing is > encrypted or not. Earlier, Manav said: > Now, assume that we limit WESP for only ESP-NULL. If this is done, how > can a middle box deterministically know that the ESP packet that it > sees is an encrypted ESP packet or an ESP packet carrying ESP-NULL > payload. I don't follow the argument. Because 1) a middle box can't trust that an E= SP packet is not ESP-NULL, therefore 2) we are going to allow WESP to carry= encrypted ESP? That is either begging the question or else it is simply a= n invalid argument. Allowing platform A to use WESP to carry encrypted ESP= has nothing to do with how likely it is that platform B will use WESP to c= arry its ESP-NULL packets. The middle box's problem is not solved by this.= That needs to be addressed by other means (convince people to use WESP fo= r ESP-NULL, or mandate it). I am not saying that there is no possible case= to be made for WESP to carry encrypted packets, just that this argument do= es not support that. The hidden assumption here still seems to be that WESP either is or ought t= o become ESPv4. The reality is that with WESP as the alternative, ESP is n= ot going away and ESP-NULL is probably also not going away. I personally c= annot envision being able to justify implementing WESP even for ESP-NULL on= my own platform. The middle boxes are dependent on end nodes if they want widespread WESP ad= option. I must say that the middle-box folks have been doing a lot less sw= eet talking and receptive listening than I would have expected given this a= rrangement. :) That leads me to predict a very doubtful future for WESP ev= en if we were to reach perfect consensus on its technical make-up. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Venkatesh Sriram To: "ipsec@ietf.org" Date: 01/05/2010 11:16 PM Subject: Re: [IPsec] Traffic visibility - consensus call ________________________________ > Would it help if WESP is renamed to something else? Since we're > discussing the fundamental principles of the protocol, i see no reason > why we cant change the name, if that helps. I think its the "Wrapped" > in the WESP thats causing most heart burn, lets change that to > something else .. something thats appeases everyone. I agree. How about VESP - "Visible ESP" ? Its phonetically the same as WESP= . :) I agree that WESP should not be clipped to only support ESP-NULL; it should be able to carry encrypted packets as well. Without this the middle boxes would never know whether the ESP packet thats passing is encrypted or not. One way could be to deprecate the use of ESP-NULL in ESP, which would mean that if someone sees an ESP packet then it MUST be an encrypted packet. This is as i understand impossible, so the only option left is to let WESP also carry encrypted packets. Sriram _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_47FF8C26716A4E45993305F326EFE4A2017D2ATK5EX14MBXW603win_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Take a look at the policy sketch I sent our yesterday for ho= w to roll this out in a mixed mode environment.   That should clarify = all your questions.

 

bs

 

 

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Scott C Moonen
Sent: Wednesday, January 06, 2010 5:38 AM
To: Venkatesh Sriram
Cc: ipsec@ietf.org; ipsec-bounces@ietf.org
Subject: Re: [IPsec] Traffic visibility - consensus call<= /span>

 


Venkatesh= said:
> I agree that WESP should not be c= lipped to only support ESP-NULL; it
> should be able to carry encrypted packets as well. Without this th= e
> middle boxes would never know whether the ESP packet thats passing= is
> encrypted or not.

Earlier, = Manav said:
> Now, assume that we limit WESP fo= r only ESP-NULL. If this is done, how
> can a middle box deterministicall= y know that the ESP packet that it
> sees is an encrypted ESP packet o= r an ESP packet carrying ESP-NULL
> payload.

I don't f= ollow the argument.  Because 1) a middle box can't trust that an ESP packet = is not ESP-NULL, therefore 2) we are going to allow WESP to carry encrypted ES= P?  That is either begging the question or else it is simply an invalid argument.  Allowing platform A to use WESP to carry encrypted ESP has nothing to do with how likely it is that platform B will use WESP to carry = its ESP-NULL packets.  The middle box's problem is not solved by this.  That needs to be addressed by other means (convince people to use WES= P for ESP-NULL, or mandate it).  I am not saying that there is no possib= le case to be made for WESP to carry encrypted packets, just that this argumen= t does not support that.

The hidde= n assumption here still seems to be that WESP either is or ought to become ES= Pv4.  The reality is that with WESP as the alternative, ESP is not going aw= ay and ESP-NULL is probably also not going away.  I personally cannot envision being able to justify implementing WESP even for ESP-NULL on my ow= n platform.

The middl= e boxes are dependent on end nodes if they want widespread WESP adoption.  I m= ust say that the middle-box folks have been doing a lot less sweet talking and receptive listening than I would have expected given this arrangement. :)  That leads me to predict a very doubtful future for WESP even if we w= ere to reach perfect consensus on its technical make-up.


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen=

From:

Venkatesh Sriram <vnktshsriram@gmail.com>

To:

"ipsec@ietf.org" <ipsec@ietf.org>

Date:

01/05/2010 11:16 PM

Subject:

Re: [IPsec] Traffic visibility - consensus call

 




> Would it help if WESP is renamed = to something else? Since we're
> discussing the fundamental principles of the protocol, i see no re= ason
> why we cant change the name, if that helps. I think its the "Wrapped"
> in the WESP thats causing most heart burn, lets change that to
> something else .. something thats appeases everyone.

I agree. How about VESP - "Visible ESP" ? Its phonetically th= e same as WESP. :)

I agree that WESP should not be clipped to only support ESP-NULL; it
should be able to carry encrypted packets as well. Without this the
middle boxes would never know whether the ESP packet thats passing is
encrypted or not. One way could be to deprecate the use of ESP-NULL in<= /tt>
ESP, which would mean that if someone sees an ESP packet then it MUST
be an encrypted packet.

This is as i understand impossible, so the only option left is to let
WESP also carry encrypted packets.

Sriram
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--_000_47FF8C26716A4E45993305F326EFE4A2017D2ATK5EX14MBXW603win_-- From briansw@microsoft.com Wed Jan 6 09:42:44 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F19B3A6920 for ; Wed, 6 Jan 2010 09:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdEkbnmMDdOi for ; Wed, 6 Jan 2010 09:42:43 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 983943A6452 for ; Wed, 6 Jan 2010 09:42:43 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 6 Jan 2010 09:43:21 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.0.639.20; Wed, 6 Jan 2010 09:42:34 -0800 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.27]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Wed, 6 Jan 2010 09:42:25 -0800 From: Brian Swander To: Stephen Kent Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AQHKjjsDFMfT79gUNESgtZlfXT4hYpGIAOaAgAAF3ACAAKG5LIAAKXdw Date: Wed, 6 Jan 2010 17:42:23 +0000 Message-ID: <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Russ Housley , gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 17:42:44 -0000 The uplevel machines can't use ESP to send the encrypted traffic in this sc= enario. Remember, that we need to look at the holistic scenario of how to = deploy this in an environment where we have legacy machines that don't do W= ESP. And we need to satisfy the goal of deterministic intermediary visibil= ity. Hence, the best method I see is what I describe below. The non-WESP machin= es MUST do ESP-NULL to allow visibility. That means uplevel machines canno= t use ESP to send encrypted, since otherwise intermediaries would see both = ESP-NULL, and ESP, and be forced back to heuristics. Intermediaries would= be configured (in this scenario) to assume that ESP always means ESP-NULL. bs -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Wednesday, January 06, 2010 7:07 AM To: Brian Swander Cc: gabriel montenegro; Russ Housley; ipsec@ietf.org Subject: Re: [IPsec] Traffic visibility - consensus call At 10:10 PM +0000 1/5/10, Brian Swander wrote: >I'll resend my message from earlier today that gives a concrete=20 >scenario for why the WESP encryption bit is in charter. =20 > >To satisfy the existing charter item, we need a deployable solution,=20 >which entails working with legacy systems that don't support this=20 >functionality yet.=20 > >Here's an explicit scenario that requires the encrypted bit for=20 >WESP, fully within the current charter of enabling ESP-NULL=20 >inspection. > >Transport policies for within an organization that want to enable=20 >intermediary inspection of ESP-NULL non-heurisitically.=20 >Organization has a mix of version of systems. > >Sample policy: >When talking to/from non-WESP capable machines: must do ESP-NULL only >When both peers are WESP capable: do WESP/ESP-NULL most places.=20 >However, where policy requires encryption, do WESP/ESP. This is where I have a problem with the analysis. If the policy were=20 that WESP-capable hosts did ESP when then needed to send encrypted=20 traffic, the flag inn question would not be needed, right? I don't think we can justify the inclusion of this flag based on the=20 scenario you described above, because that scenario adopts a=20 particular local policy that it not required. Steve From paul.hoffman@vpnc.org Wed Jan 6 09:49:39 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E094C28C112 for ; Wed, 6 Jan 2010 09:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.071 X-Spam-Level: X-Spam-Status: No, score=-6.071 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0cF8W03Q8rb for ; Wed, 6 Jan 2010 09:49:39 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 0F66228C0E1 for ; Wed, 6 Jan 2010 09:49:39 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o06HnZge059013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jan 2010 10:49:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> Date: Wed, 6 Jan 2010 09:49:33 -0800 To: Brian Swander , gabriel montenegro , Russ Housley From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 17:49:40 -0000 Not wearing any hat: At 10:10 PM +0000 1/5/10, Brian Swander wrote: >I'll resend my message from earlier today that gives a concrete scenario for why the WESP encryption bit is in charter. > >To satisfy the existing charter item, we need a deployable solution, which entails working with legacy systems that don't support this functionality yet. > >Here's an explicit scenario that requires the encrypted bit for WESP, fully within the current charter of enabling ESP-NULL inspection. > >Transport policies for within an organization that want to enable intermediary inspection of ESP-NULL non-heurisitically. Organization has a mix of version of systems. > >Sample policy: >When talking to/from non-WESP capable machines: must do ESP-NULL only >When both peers are WESP capable: do WESP/ESP-NULL most places. However, where policy requires encryption, do WESP/ESP. > >Only with the WESP encrypt bit can intermediaries distinguish what is going on here, and still enable the uplevel systems to do full encryption where needed. I.e. if they see ESP, it must be ESP-NULL. If they see WESP, then they must leverage the encrypt bit to see what to do. > >Hence we need to keep the encrypted bit to satisfy the current WESP charter item. That policy makes sense if you assume that WESP covers encrypted ESP. If WESP only covers unencrypted ESP, the policy would be: When talking to/from non-WESP capable machines: must do ESP-NULL only. When both peers are WESP capable: do WESP/ESP-NULL. This is exactly what was envisioned when the WG chartered the work item. That is, the presence of WESP does not affect policy about encryption. --Paul Hoffman, Director --VPN Consortium From briansw@microsoft.com Wed Jan 6 09:56:50 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EE4428C0F6 for ; Wed, 6 Jan 2010 09:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7G1hdda4SFv for ; Wed, 6 Jan 2010 09:56:49 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 386073A67E3 for ; Wed, 6 Jan 2010 09:56:49 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 6 Jan 2010 09:57:27 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.0.639.21; Wed, 6 Jan 2010 09:56:48 -0800 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.27]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Wed, 6 Jan 2010 09:56:48 -0800 From: Brian Swander To: Paul Hoffman , gabriel montenegro , Russ Housley Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AQHKjviaFMfT79gUNESgtZlfXT4hYpGI1BzQ Date: Wed, 6 Jan 2010 17:56:47 +0000 Message-ID: <47FF8C26716A4E45993305F326EFE4A201891B@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 17:56:50 -0000 But that doesn't give us any path to actually do encryption (in environment= s with legacy systems) - hence the proposal is untenable.=20 I'd argue it therefore doesn't satisfy the charter item. The charter item= is a deployable mechanism that lets intermediaries inspect ESP-NULL when p= resent. This charter item surely shouldn't mandate that we can now no long= er use encrypted ESP at all. Clearly we need a solution that also lets us use encrypted traffic where ne= eded, but not break inspection of integrity only traffic. How do we meet t= hat with your proposal below? We must make sure that we have a solution that is deployable and useful in = the real world. bs -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of P= aul Hoffman Sent: Wednesday, January 06, 2010 9:50 AM To: Brian Swander; gabriel montenegro; Russ Housley Cc: ipsec@ietf.org Subject: Re: [IPsec] Traffic visibility - consensus call Not wearing any hat: At 10:10 PM +0000 1/5/10, Brian Swander wrote: >I'll resend my message from earlier today that gives a concrete scenario f= or why the WESP encryption bit is in charter. =20 > >To satisfy the existing charter item, we need a deployable solution, which= entails working with legacy systems that don't support this functionality = yet.=20 > >Here's an explicit scenario that requires the encrypted bit for WESP, full= y within the current charter of enabling ESP-NULL inspection. > >Transport policies for within an organization that want to enable intermed= iary inspection of ESP-NULL non-heurisitically. Organization has a mix of = version of systems. > >Sample policy: >When talking to/from non-WESP capable machines: must do ESP-NULL only >When both peers are WESP capable: do WESP/ESP-NULL most places. However, = where policy requires encryption, do WESP/ESP. > >Only with the WESP encrypt bit can intermediaries distinguish what is goin= g on here, and still enable the uplevel systems to do full encryption where= needed. I.e. if they see ESP, it must be ESP-NULL. If they see WESP, the= n they must leverage the encrypt bit to see what to do. > >Hence we need to keep the encrypted bit to satisfy the current WESP charte= r item. That policy makes sense if you assume that WESP covers encrypted ESP. If WE= SP only covers unencrypted ESP, the policy would be: When talking to/from non-WESP capable machines: must do ESP-NULL only. When both peers are WESP capable: do WESP/ESP-NULL. This is exactly what was envisioned when the WG chartered the work item. Th= at is, the presence of WESP does not affect policy about encryption. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From kohn.jack@gmail.com Wed Jan 6 10:00:35 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C605D3A68E4; Wed, 6 Jan 2010 10:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xB1JNVszb1wI; Wed, 6 Jan 2010 10:00:35 -0800 (PST) Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by core3.amsl.com (Postfix) with ESMTP id C37BB3A6452; Wed, 6 Jan 2010 10:00:34 -0800 (PST) Received: by gxk9 with SMTP id 9so39270198gxk.8 for ; Wed, 06 Jan 2010 10:00:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6tekr2sA4a/gbxrdW8mJ61IHGqKLAXlwbNrKgD5CSTM=; b=bsnVfaqWvlF2lkjrVkIJuVxC4iCZ+lXTOEjp5/SnhkFfdMIbFW9YohmTbMp7p8fnAk cTqZj3VwMvVU3zqvMyQWs3JF/GR6VkUXIsbJmk1GTi7IxU6v31mTl9L1Oty79xq2AxyZ eyfgGpQk2VO+18aK3oEh0HIR6gt9Z0uW7Yyd4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cr0rZytt4XyAACM9W7H9ei1a6bDlyhgdNF3HSLYJrYQmk4Gt4IU74iVg4e/Je+udJy Gf9joTPWER8BL8ELdLNeSQplCuRo3UgPoN6f5J1LYQTRywe1B2wWHkv+Q0K8Nax/GU6n xAF5+9dNxxNNz19EAZplxx1o77f2w4fdmaI5E= MIME-Version: 1.0 Received: by 10.91.50.31 with SMTP id c31mr13961706agk.90.1262800826464; Wed, 06 Jan 2010 10:00:26 -0800 (PST) In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C506D@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <4B43C2A8.6010302@vigilsec.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C506D@il-ex01.ad.checkpoint.com> Date: Wed, 6 Jan 2010 23:30:26 +0530 Message-ID: From: Jack Kohn To: Yaron Sheffer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipsec@ietf.org" , Venkatesh Sriram , "ipsec-bounces@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 18:00:35 -0000 On Wed, Jan 6, 2010 at 8:49 PM, Yaron Sheffer wrote= : > I would like to reframe the migration discussion. Manav, Scott and everyo= ne else, please correct me if I got it wrong. > > Suppose we have a middlebox that can do useful things if it knows that th= e flow is unencrypted, and only basic things if it is encrypted. A load bal= ancer is a good example. > > We are slowly migrating all endpoints in an enterprise to be WESP-capable= . During the migration period, the middlebox sees 3 or 4 types of traffic: > > 1. WESP from the new nodes. > 2. Depending on your view of whether we have the bit in question: encrypt= ed ESP from WESP-capable ("new") nodes. > 3. Encrypted ESP from WESP-incapable ("old") nodes. > 4. And ESP-null from old nodes. > > Taking Manav's perspective, the middlebox can always use heuristics to di= stinguish encrypted ESP from ESP-null. As the number of WESP-capable nodes = grows, it will see less and less ESP, so will spend ever less CPU power on = heuristics. > > According to Scott, the middlebox should have a big red switch with two s= ettings: initially most nodes are > WESP-incapable, so it should use heuristics to analyze ESP packets. When = the time comes when "almost" > all endpoint are WESP-capable, we turn the switch and now we assume all E= SP is encrypted, > with no per-flow analysis. Unless we do so, we will be wasting CPU on heu= ristics forever. > > Are these the alternatives we are facing? And if so, what is the preferre= d migration scenario? I think it will always be the first one, where we see less and less of ESP so that boxes have to spend minimal CPU on heuristics. I am also fine with the other model if we can come out with another standard-track RFC along with the WESP which says that we MUST not use ESP-NULL with ESP, so that we dont see unencrypted ESP pkts in the wild. Can we do this? If not, then lets go ahead with the first model, as proposed by Manav. Jack > > Thanks, > =A0 =A0 =A0 =A0Yaron > From kohn.jack@gmail.com Wed Jan 6 10:14:25 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 239073A6930 for ; Wed, 6 Jan 2010 10:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGpguZrvXihZ for ; Wed, 6 Jan 2010 10:14:15 -0800 (PST) Received: from mail-yw0-f196.google.com (mail-yw0-f196.google.com [209.85.211.196]) by core3.amsl.com (Postfix) with ESMTP id 8995C3A6905 for ; Wed, 6 Jan 2010 10:14:12 -0800 (PST) Received: by ywh34 with SMTP id 34so10949847ywh.31 for ; Wed, 06 Jan 2010 10:14:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ryRPN8Q2SLoqlc+BI/FgQLEvfEiYUJer9BhuHTwXFn0=; b=sTzQuqg/rQY4v4+IeuHna9YMkEHvcs1A0Rqx9wewzCInP0nq2SBD7uDPCZvaHtP+RE U7co77AclOOz3eanYVeL9PBmixN+9w+0u4slcCFOkjMBZ/i0rdgBXOr2RsmfXEeCquX1 qo5F3oLMCsnm3OZewwrBVz6cbhptfzw2yqIkM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=vwEbcmf+8LIHA4bZH5IdoOZI/L2kZQ80mmij2HxecNoGYlZnE+DnID8UYyAADFcEmt ea4JhapQsk/3LDAopAM+DZzpM17QRXyJL9wCvY1Xsjg6bKgBjz8jNA/VegfxTwhiGE7l H2mn7sG7YPFDAudj4IoNWtoGZ3V5qUBFb28sk= MIME-Version: 1.0 Received: by 10.90.20.38 with SMTP id 38mr217481agt.77.1262801645996; Wed, 06 Jan 2010 10:14:05 -0800 (PST) In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA40A9B7634@zrtphxm2.corp.nortel.com> References: <34B3EAA5B3066A42914D28C5ECF5FEA40A9B7634@zrtphxm2.corp.nortel.com> Date: Wed, 6 Jan 2010 23:44:05 +0530 Message-ID: From: Jack Kohn To: Dragan Grebovich Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 18:14:25 -0000 On Wed, Jan 6, 2010 at 2:52 AM, Dragan Grebovich wro= te: > Yes and Yes. > > I supported WESP from the beginning, because it allows intermediate > systems to perform DPI on ESP-NULL packets. =A0I was not in favor of > heuristics - not because it is a bad solution (on the contrary) - but > because many products we have/make today could not be upgraded to > support it. =A0Manav gave an excellent summary the other day. The more that i think about this, the more convinced i get, that we (IPSecME WG) do not have a solution, any solution for traffic visibility, if we do not let WESP carry encrypted traffic, because heuristics is for most boxes unimplementable (i.e. if at all it can work) and all models proposed so far rely on all boxes doing some bit of heuristics along with WESP for proper identification of encrypted and unencrypted packets. > I also view that the extensibility of the protocol as it stands in the > WESP today allows a smooth evolution path for fixing an obvious problem > and allowing support of new services. =A0I would not deprecate ESP for a > long time because there is a wide customer base that cannot be ripped > out. =A0I would work within the present charter, if possible. =A0If it ta= kes > a new charter to codify ESPv4, I am fine with that too, and let's use > WESP as a base. Either this, or we come out with a short draft that deprecates ESP-NULL usage with ESP. > > There is always going to be equipment mix of multiple vintages and > capabilities. =A0Systems capable of supporting =A0(extensible) WESP shoul= d > be able to take advantage of that. =A0Some systems may not be able to > support encrypted WESP and would work with ESP-NULL only. =A0Legacy > systems (non-WESP capable) must be able to perform as they do today > (ignoring WESP packets and forwarding them uninspected). I agree. Jack > > Dragan > From paul.hoffman@vpnc.org Wed Jan 6 10:23:28 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 315133A694E for ; Wed, 6 Jan 2010 10:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.067 X-Spam-Level: X-Spam-Status: No, score=-6.067 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZdiDaJLeNQd for ; Wed, 6 Jan 2010 10:23:27 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 500193A6859 for ; Wed, 6 Jan 2010 10:23:27 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o06INO8L061262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jan 2010 11:23:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <47FF8C26716A4E45993305F326EFE4A201891B@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A201891B@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> Date: Wed, 6 Jan 2010 10:21:05 -0800 To: Brian Swander , gabriel montenegro , Russ Housley From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 18:23:28 -0000 No hat. At 5:56 PM +0000 1/6/10, Brian Swander wrote: >But that doesn't give us any path to actually do encryption (in environments with legacy systems) - hence the proposal is untenable. That doesn't make sense: it is *exactly* the same path as we have today. WESP-as-envisioned gives us one extra capability; WESP-as-it-is-today gives us two. The "path to actually do encryption (in environments with legacy systems)" is to use ESP exactly as it is being done today by dozens of vendors, including you. >I'd argue it therefore doesn't satisfy the charter item. The charter item is a deployable mechanism that lets intermediaries inspect ESP-NULL when present. This charter item surely shouldn't mandate that we can now no longer use encrypted ESP at all. Please don't reduce this to absurd straw men. The charter item is quite clear: A standards-track mechanism that allows an intermediary device, such as a firewall or intrusion detection system, to easily and reliably determine whether an ESP packet is encrypted with the NULL cipher; and if it is, determine the location of the actual payload data inside the packet. WESP-over-ESP-NULL-only fulfills that charter item. WESP-as-it-is-today does it as well, but adds additional features and extensibility. The question in this thread is whether to back down to WESP-over-ESP-NULL-only. >Clearly we need a solution that also lets us use encrypted traffic where needed, but not break inspection of integrity only traffic. How do we meet that with your proposal below? As it is done today, and adding in WESP-over-ESP-NULL-only. >We must make sure that we have a solution that is deployable and useful in the real world. Really, you think so? :-) --Paul Hoffman, Director --VPN Consortium From kent@bbn.com Wed Jan 6 10:37:14 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99A3E28C0ED for ; Wed, 6 Jan 2010 10:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xyi6yuTRS0MK for ; Wed, 6 Jan 2010 10:37:13 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 5DDBC28C0F4 for ; Wed, 6 Jan 2010 10:37:13 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.5]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NSakl-0006oM-CE; Wed, 06 Jan 2010 13:37:08 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> Date: Wed, 6 Jan 2010 13:37:05 -0500 To: Brian Swander From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-949319469==_ma============" Cc: "ipsec@ietf.org" , Russ Housley , gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 18:37:14 -0000 --============_-949319469==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 5:42 PM +0000 1/6/10, Brian Swander wrote: >The uplevel machines can't use ESP to send the encrypted traffic in >this scenario. Remember, that we need to look at the holistic >scenario of how to deploy this in an environment where we have >legacy machines that don't do WESP. And we need to satisfy the goal >of deterministic intermediary visibility. > >Hence, the best method I see is what I describe below. The non-WESP >machines MUST do ESP-NULL to allow visibility. That means uplevel >machines cannot use ESP to send encrypted, since otherwise >intermediaries would see both ESP-NULL, and ESP, and be forced back >to heuristics. Intermediaries would be configured (in this >scenario) to assume that ESP always means ESP-NULL. > >bs Sorry, Brian, I still don't understand the scenario. Let's see if a detailed analysis can help. In a mixed environment, there are two classes of machines: WESP-capable and not. That yields 3 types of connections, and 6 types of flows. Let's label end systems (nodes) as W (for WESP-capable) and N (for not WESP-capable), and label traffic as I (integrity protected, but not encrypted) and E (for encrypted). Finally, label the protocols as W (WESP), W* (WESP with the encrypted content flag set), EE (ESP-encrypted) and EN (ESP-NULL). The following table shows the flows and protocols that could result in 2 scenarios: Scenario 1 is WESP as originally proposed and Scenario 2 is with super-WESP. Case Nodes Flow S 1 S 2 1 N-N I EN EN 2 N-N E EE EE 3 W-W I W W 4 W-W E EE W* 5 W-N I EN EN 6 W-N E EE EE The only place W* can be used is in case 4 (in Scenario 2), where both nodes are WESP-capable and the traffic is encrypted. But, in both scenarios, an intermediate device will encounter ESP traffic that may or may not be encrypted, in cases 1, 2, 5, and 6. So, it appears to me that the intermediate device needs to use heuristics until there are NO non-WESP nodes. At that time, we are dealing only with cases 3 & 4. But, in either scenario, these two cases present an intermediate device with unambiguous info for deciding whether a packet can be inspected. This analysis suggests that there is no need for the flag when all nodes are WESP-capable, and no benefit when there are a mix of WESP-capable and legacy nodes. Steve --============_-949319469==_ma============ Content-Type: text/html; charset="us-ascii" RE: [IPsec] Traffic visibility - consensus call
At 5:42 PM +0000 1/6/10, Brian Swander wrote:
The uplevel machines can't use ESP to send the encrypted traffic in this scenario.  Remember, that we need to look at the holistic scenario of how to deploy this in an environment where we have legacy machines that don't do WESP.  And we need to satisfy the goal of deterministic intermediary visibility.

Hence, the best method I see is what I describe below.  The non-WESP machines MUST do ESP-NULL to allow visibility.  That means uplevel machines cannot use ESP to send encrypted, since otherwise intermediaries would see both ESP-NULL, and ESP, and be forced back to heuristics.   Intermediaries would be configured (in this scenario) to assume that ESP always means ESP-NULL.

bs

Sorry, Brian, I still don't understand the scenario.  Let's see if a detailed analysis can help.

In a mixed environment, there are two classes of machines: WESP-capable and not.  That yields 3 types of connections, and 6 types of flows.  Let's label end systems (nodes) as W (for WESP-capable) and N (for not WESP-capable), and label traffic as I (integrity protected, but not encrypted) and E (for encrypted). Finally, label the protocols as W (WESP), W* (WESP with the encrypted content flag set), EE (ESP-encrypted) and EN (ESP-NULL).  The following table shows the flows and protocols that could result in 2 scenarios: Scenario 1 is WESP as originally proposed and Scenario 2 is with super-WESP.

Case    Nodes   Flow    S 1     S 2
1       N-N     I       EN      EN
2     N-N     E       EE      EE
3     W-W     I       W       W
4      W-W     E       EE      W*
5     W-N     I       EN      EN
6       W-N     E       EE      EE

The only place W* can be used is in case 4 (in Scenario 2), where both nodes are WESP-capable and the traffic is encrypted. But, in both scenarios, an intermediate device will encounter ESP traffic that may or may not be encrypted, in cases 1, 2, 5, and 6. So, it appears to me that the intermediate device needs to use heuristics until there are NO non-WESP nodes. At that time, we are dealing only with cases 3 & 4. But, in either scenario, these two cases present an intermediate device with unambiguous info for deciding whether a packet can be inspected.

This analysis suggests that there is no need for the flag when all nodes are WESP-capable, and no benefit when there are a mix of WESP-capable and legacy nodes.

Steve
--============_-949319469==_ma============-- From danmcd@sun.com Wed Jan 6 10:45:15 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79B3F28C107 for ; Wed, 6 Jan 2010 10:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSURfHgFPs+k for ; Wed, 6 Jan 2010 10:45:14 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 9AA8328C108 for ; Wed, 6 Jan 2010 10:45:14 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o06Ij8jT009313 for ; Wed, 6 Jan 2010 18:45:08 GMT Received: from kebe.East.Sun.COM (kebe.East.Sun.COM [129.148.174.48]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.4) with ESMTP id o06Ij81B016975 for ; Wed, 6 Jan 2010 13:45:08 -0500 (EST) Received: from kebe.East.Sun.COM (localhost [127.0.0.1]) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id o06Iijdv023663 for ; Wed, 6 Jan 2010 13:44:45 -0500 (EST) Received: (from danmcd@localhost) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3/Submit) id o06IijUE023662 for ipsec@ietf.org; Wed, 6 Jan 2010 13:44:45 -0500 (EST) X-Authentication-Warning: kebe.East.Sun.COM: danmcd set sender to danmcd@sun.com using -f Date: Wed, 6 Jan 2010 13:44:45 -0500 From: Dan McDonald To: "ipsec@ietf.org" Message-ID: <20100106184445.GA23645@kebe.East.Sun.COM> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [IPsec] What problem are we REALLY trying to solve? (was Traffic visibility) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 18:45:15 -0000 > Transport policies for within an organization that want to enable > intermediary inspection of ESP-NULL non-heurisitically. Organization has a > mix of version of systems. At this point I need more details. Specifically, why does an organization need to inspect ESP-NULL packets? I can think of two good reasons off the top of my head: * To appropriately schedule or forward a packet according to latency, or any other number of diffserv properties. - Deep-packet inspection for content or other beyond-the-headers processing. I've marked the first item with *, and the second with -. Items marked with * merely requires flow classification. In IPv6 we have a flow id already, and there are rumblings of a hop-by-hop IPv4 option to do the same thing here: http://tools.ietf.org/html/draft-dreibholz-ipv4-flowlabel-11 (Heck, it's even 20 bits!) Items marked with - require that the payload be in the clear, or (by some miracle) the inspecting entity has the cryptographic keys. Items marked with * can use flow labels. Yes it's a host software change, but quite frankly so is WESP. WESP doesn't do anything in this case an alternate mechanism cannot do. Items marked with - will benefit greatly from WESP IF (and only if) you believe heuristics to be untenable, but encrypted WESP support won't help here at all. Furthemore, a working flow label deployment and flow labelling policy could make what were heuristics into completely deterministic processing. There's vague talk about deployability and future directions. Please show me some concrete examples supporting WESP with encrypted packet support. I suspect such examples will most likely either require the whole packet text (i.e. marked with -) or just enough data to identify a flow (i.e. marked with *). Thanks, Dan From dharkins@lounge.org Wed Jan 6 10:48:33 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5354D3A6881 for ; Wed, 6 Jan 2010 10:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XT8TjbMFpneM for ; Wed, 6 Jan 2010 10:48:32 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 8694D3A6805 for ; Wed, 6 Jan 2010 10:48:32 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id EE290A88812E; Wed, 6 Jan 2010 10:48:30 -0800 (PST) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 6 Jan 2010 10:48:31 -0800 (PST) Message-ID: <2658cf557a0791e0140b0c82d27f4d5c.squirrel@www.trepanning.net> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.co m> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> Date: Wed, 6 Jan 2010 10:48:31 -0800 (PST) From: "Dan Harkins" To: "Yaron Sheffer" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 18:48:33 -0000 Hi, No and no. I'm a little alarmed at the assumption by some that ESP would be deprecated (albeit "not for a long time"). AH does not really solve the problem supposedly solved by WESP because it doesn't work through a NAT. So if we're going to have a new protocol that needs to be implemented by end points why not just make a NAT-friendly version of AH and forget the whole idea of "wrapping" ESP packets. That would be architecturally cleaner, in my opinion. If you want to provide traffic visibility then negotiate for the traffic that is being protected, if you don't then negotiate ESP. And if ESP-NULL poses a problem for you then prohibit it by policy. Dan. On Mon, January 4, 2010 2:27 pm, Yaron Sheffer wrote: > Hi, > > We have had a few "discusses" during the IESG review of the WESP draft. To > help resolve them, we would like to reopen the following two questions to > WG discussion. Well reasoned answers are certainly appreciated. But plain > "yes" or "no" would also be useful in judging the group's consensus. > > - The current draft > (http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11) > defines the ESP trailer's ICV calculation to include the WESP header. This > has been done to counter certain attacks, but it means that WESP is no > longer a simple wrapper around ESP - ESP itself is modified. Do you > support this design decision? > > - The current draft allows WESP to be applied to encrypted ESP flows, in > addition to the originally specified ESP-null. This was intended so that > encrypted flows can benefit from the future extensibility offered by WESP. > But arguably, it positions WESP as an alternative to ESP. Do you support > this design decision? > > Thanks, > Yaron > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From yaronf@checkpoint.com Wed Jan 6 10:56:51 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 338553A687D; Wed, 6 Jan 2010 10:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMisI97g6V-c; Wed, 6 Jan 2010 10:56:50 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id F07373A688E; Wed, 6 Jan 2010 10:56:49 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o06IuhT7019405; Wed, 6 Jan 2010 20:56:43 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 6 Jan 2010 20:56:56 +0200 From: Yaron Sheffer To: Stephen Kent Date: Wed, 6 Jan 2010 20:56:38 +0200 Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AcqO9hwbPhq1HywnT9GKAGypQaeNkQAC0dtA Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C509F@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <4B43C2A8.6010302@vigilsec.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C506D@il-ex01.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Venkatesh Sriram , "ipsec-bounces@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 18:56:51 -0000 Hi Steve, Please reread my text. I was (in that paragraph) taking Manav's side, i.e. = assuming there's value in deterministic distinction between encrypted and u= nencrypted ESP, and hence, gradually moving the endpoints to WESP so that m= iddleboxes have an easier time. As we know, this opinion is not shared by everyone. Thanks, Yaron -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Wednesday, January 06, 2010 19:10 To: Yaron Sheffer Cc: Scott C Moonen; Venkatesh Sriram; ipsec@ietf.org; ipsec-bounces@ietf.or= g Subject: Re: [IPsec] Traffic visibility - consensus call At 5:19 PM +0200 1/6/10, Yaron Sheffer wrote: >I would like to reframe the migration discussion. Manav, Scott and=20 >everyone else, please correct me if I got it wrong. > >Suppose we have a middlebox that can do useful things if it knows=20 >that the flow is unencrypted, and only basic things if it is=20 >encrypted. A load balancer is a good example. > >We are slowly migrating all endpoints in an enterprise to be=20 >WESP-capable. During the migration period, the middlebox sees 3 or 4=20 >types of traffic: > >1. WESP from the new nodes. >2. Depending on your view of whether we have the bit in question:=20 >encrypted ESP from WESP-capable ("new") nodes. >3. Encrypted ESP from WESP-incapable ("old") nodes. >4. And ESP-null from old nodes. > >Taking Manav's perspective, the middlebox can always use heuristics=20 >to distinguish encrypted ESP from ESP-null. As the number of=20 >WESP-capable nodes grows, it will see less and less ESP, so will=20 >spend ever less CPU power on heuristics. It's not clear why nodes sending encrypted traffic would need to use=20 WESP (vs. native ESP), even if there is a WESP flag that indicates an=20 encrypted payload. Thus I don't agree with the conclusion that over=20 time there would be less ESP over all. If you said there would be=20 less use of ESP-NULL (w/o a WES header), I would agree. To suggest=20 otherwise is to pre-suppose that replacing ESP with WESP in general=20 is a goal, and I certainly don't think the WG has indicated that (nor=20 is it in scope at this time). Steve Scanned by Check Point Total Security Gateway. From smoonen@us.ibm.com Wed Jan 6 11:00:31 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43CE33A687D; Wed, 6 Jan 2010 11:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtJFFYsWPgnW; Wed, 6 Jan 2010 11:00:29 -0800 (PST) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by core3.amsl.com (Postfix) with ESMTP id A0A1B3A685B; Wed, 6 Jan 2010 11:00:29 -0800 (PST) Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e39.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id o06IrLdh027868; Wed, 6 Jan 2010 11:53:21 -0700 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o06J0EQX041598; Wed, 6 Jan 2010 12:00:14 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o06J0DQg030351; Wed, 6 Jan 2010 12:00:13 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o06J0DpM030331; Wed, 6 Jan 2010 12:00:13 -0700 In-Reply-To: <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> To: Brian Swander MIME-Version: 1.0 X-KeepSent: CE1FA5F5:11BCE49A-852576A3:0061E97E; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/06/2010 01:45:07 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/06/2010 01:45:07 PM, Serialize complete at 01/06/2010 01:45:07 PM, S/MIME Sign failed at 01/06/2010 01:45:07 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 01/06/2010 12:00:13, Serialize complete at 01/06/2010 12:00:13 Message-ID: Date: Wed, 6 Jan 2010 14:00:12 -0500 Content-Type: multipart/alternative; boundary="=_alternative 006701F7852576A3_=" Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org, Russ Housley , gabriel montenegro , Stephen Kent Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 19:00:31 -0000 This is a multipart message in MIME format. --=_alternative 006701F7852576A3_= Content-Type: text/plain; charset="US-ASCII" Brian, the middle box could never "assume that ESP always means ESP-NULL" because the down-level nodes (as well as any up-level node talking to them) will use ESP for encrypted traffic as well. Moreover, this is a soft sort of begging the question because it is assuming that WESP will be widely adopted in order to argue for it to be even more widely used. I remain unconvinced of that assumption, and I am definitely unconvinced that there is zero cost to happily assuming the up-level nodes can always and freely use WESP for encrypted traffic. All this does nothing to encourage those down-level nodes to get with the WESP program, and I think that is your real challenge. Again, I'm not saying that there is no conceivable value to encrypted WESP, just that if this is your concern then encrypted WESP is not the answer. Finally, if WESP really is going to be that widely used, then we really need to scrap it and talk about whether there is warrant to do a real ESPv4 instead of backdooring it like this. WESP is not a suitable ESPv4. And if WESP is going to be that quickly and widely adopted then there should be no trouble getting consensus to do ESPv4. ;) Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Brian Swander To: Stephen Kent Cc: "ipsec@ietf.org" , Russ Housley , gabriel montenegro Date: 01/06/2010 12:42 PM Subject: Re: [IPsec] Traffic visibility - consensus call The uplevel machines can't use ESP to send the encrypted traffic in this scenario. Remember, that we need to look at the holistic scenario of how to deploy this in an environment where we have legacy machines that don't do WESP. And we need to satisfy the goal of deterministic intermediary visibility. Hence, the best method I see is what I describe below. The non-WESP machines MUST do ESP-NULL to allow visibility. That means uplevel machines cannot use ESP to send encrypted, since otherwise intermediaries would see both ESP-NULL, and ESP, and be forced back to heuristics. Intermediaries would be configured (in this scenario) to assume that ESP always means ESP-NULL. bs -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Wednesday, January 06, 2010 7:07 AM To: Brian Swander Cc: gabriel montenegro; Russ Housley; ipsec@ietf.org Subject: Re: [IPsec] Traffic visibility - consensus call At 10:10 PM +0000 1/5/10, Brian Swander wrote: >I'll resend my message from earlier today that gives a concrete >scenario for why the WESP encryption bit is in charter. > >To satisfy the existing charter item, we need a deployable solution, >which entails working with legacy systems that don't support this >functionality yet. > >Here's an explicit scenario that requires the encrypted bit for >WESP, fully within the current charter of enabling ESP-NULL >inspection. > >Transport policies for within an organization that want to enable >intermediary inspection of ESP-NULL non-heurisitically. >Organization has a mix of version of systems. > >Sample policy: >When talking to/from non-WESP capable machines: must do ESP-NULL only >When both peers are WESP capable: do WESP/ESP-NULL most places. >However, where policy requires encryption, do WESP/ESP. This is where I have a problem with the analysis. If the policy were that WESP-capable hosts did ESP when then needed to send encrypted traffic, the flag inn question would not be needed, right? I don't think we can justify the inclusion of this flag based on the scenario you described above, because that scenario adopts a particular local policy that it not required. Steve _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 006701F7852576A3_= Content-Type: text/html; charset="US-ASCII"
Brian, the middle box could never "assume that ESP always means ESP-NULL" because the down-level nodes (as well as any up-level node talking to them) will use ESP for encrypted traffic as well.

Moreover, this is a soft sort of begging the question because it is assuming that WESP will be widely adopted in order to argue for it to be even more widely used.  I remain unconvinced of that assumption, and I am definitely unconvinced that there is zero cost to happily assuming the up-level nodes can always and freely use WESP for encrypted traffic.  All this does nothing to encourage those down-level nodes to get with the WESP program, and I think that is your real challenge.  Again, I'm not saying that there is no conceivable value to encrypted WESP, just that if this is your concern then encrypted WESP is not the answer.

Finally, if WESP really is going to be that widely used, then we really need to scrap it and talk about whether there is warrant to do a real ESPv4 instead of backdooring it like this.  WESP is not a suitable ESPv4.  And if WESP is going to be that quickly and widely adopted then there should be no trouble getting consensus to do ESPv4.  ;)


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen


From: Brian Swander <briansw@microsoft.com>
To: Stephen Kent <kent@bbn.com>
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, Russ Housley <housley@vigilsec.com>, gabriel montenegro <g_e_montenegro@yahoo.com>
Date: 01/06/2010 12:42 PM
Subject: Re: [IPsec] Traffic visibility - consensus call




The uplevel machines can't use ESP to send the encrypted traffic in this scenario.  Remember, that we need to look at the holistic scenario of how to deploy this in an environment where we have legacy machines that don't do WESP.  And we need to satisfy the goal of deterministic intermediary visibility.

Hence, the best method I see is what I describe below.  The non-WESP machines MUST do ESP-NULL to allow visibility.  That means uplevel machines cannot use ESP to send encrypted, since otherwise intermediaries would see both ESP-NULL, and ESP, and be forced back to heuristics.   Intermediaries would be configured (in this scenario) to assume that ESP always means ESP-NULL.

bs



-----Original Message-----
From: Stephen Kent [mailto:kent@bbn.com]
Sent: Wednesday, January 06, 2010 7:07 AM
To: Brian Swander
Cc: gabriel montenegro; Russ Housley; ipsec@ietf.org
Subject: Re: [IPsec] Traffic visibility - consensus call

At 10:10 PM +0000 1/5/10, Brian Swander wrote:
>I'll resend my message from earlier today that gives a concrete
>scenario for why the WESP encryption bit is in charter.  
>
>To satisfy the existing charter item, we need a deployable solution,
>which entails working with legacy systems that don't support this
>functionality yet.
>
>Here's an explicit scenario that requires the encrypted bit for
>WESP, fully within the current charter of enabling ESP-NULL
>inspection.
>
>Transport policies for within an organization that want to enable
>intermediary inspection of ESP-NULL non-heurisitically.
>Organization has a mix of version of systems.
>
>Sample policy:
>When talking to/from non-WESP capable machines:  must do ESP-NULL only
>When both peers are WESP capable: do WESP/ESP-NULL most places.
>However, where policy requires encryption, do WESP/ESP.

This is where I have a problem with the analysis. If the policy were
that WESP-capable hosts did ESP when then needed to send encrypted
traffic, the flag inn question would not be needed, right?

I don't think we can justify the inclusion of this flag based on the
scenario you described above, because that scenario adopts a
particular local policy that it not required.

Steve

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--=_alternative 006701F7852576A3_=-- From briansw@microsoft.com Wed Jan 6 11:07:39 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D36F73A6814 for ; Wed, 6 Jan 2010 11:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knsBpRL7Sy9p for ; Wed, 6 Jan 2010 11:07:32 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 9F6F73A687E for ; Wed, 6 Jan 2010 11:07:32 -0800 (PST) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 6 Jan 2010 11:08:10 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.0.639.20; Wed, 6 Jan 2010 11:06:43 -0800 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.27]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Wed, 6 Jan 2010 11:06:44 -0800 From: Brian Swander To: Stephen Kent Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AQHKjv8+FMfT79gUNESgtZlfXT4hYpGI5nLQ Date: Wed, 6 Jan 2010 19:06:42 +0000 Message-ID: <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_47FF8C26716A4E45993305F326EFE4A2018A04TK5EX14MBXW603win_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Russ Housley , gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 19:07:39 -0000 --_000_47FF8C26716A4E45993305F326EFE4A2018A04TK5EX14MBXW603win_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Remember, the goal isn't necessarily to provide the full cross product of a= ll possible permutations, which is what you've done. The goal is to satisf= y the customer scenarios. Only if the customer really needs all the cross= product permutations, do they come into play. My argument is that a very good deployment strategy that will meet many cus= tomer scenarios is precisely to prune your matrix to make things determinis= tic to the intermediaries. In terms of your chart, that means that the only allowed combinations (of t= his scenario) are: Case Nodes Flow S 1 S 2 1 N-N I EN EN 3 W-W I W W 4 W-W E EE W* 5 W-N I EN EN Hence any (legitimate) ESP traffic that the intermediary sees must be ESP-N= ULL, and the encypt flag is critical, as it is the mechanism to enable encr= yption between uplevel machines. The main point of WESP is to remove heuristics from intermediary processing= . Hence we need to focus on the scenarios that actually allow us to do t= hat, and enable as many of them as possible. bs From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of S= tephen Kent Sent: Wednesday, January 06, 2010 10:37 AM To: Brian Swander Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call At 5:42 PM +0000 1/6/10, Brian Swander wrote: The uplevel machines can't use ESP to send the encrypted traffic in this sc= enario. Remember, that we need to look at the holistic scenario of how to = deploy this in an environment where we have legacy machines that don't do W= ESP. And we need to satisfy the goal of deterministic intermediary visibil= ity. Hence, the best method I see is what I describe below. The non-WESP machin= es MUST do ESP-NULL to allow visibility. That means uplevel machines canno= t use ESP to send encrypted, since otherwise intermediaries would see both = ESP-NULL, and ESP, and be forced back to heuristics. Intermediaries would= be configured (in this scenario) to assume that ESP always means ESP-NULL. bs Sorry, Brian, I still don't understand the scenario. Let's see if a detail= ed analysis can help. In a mixed environment, there are two classes of machines: WESP-capable and= not. That yields 3 types of connections, and 6 types of flows. Let's lab= el end systems (nodes) as W (for WESP-capable) and N (for not WESP-capable)= , and label traffic as I (integrity protected, but not encrypted) and E (fo= r encrypted). Finally, label the protocols as W (WESP), W* (WESP with the e= ncrypted content flag set), EE (ESP-encrypted) and EN (ESP-NULL). The foll= owing table shows the flows and protocols that could result in 2 scenarios:= Scenario 1 is WESP as originally proposed and Scenario 2 is with super-WES= P. Case Nodes Flow S 1 S 2 1 N-N I EN EN 2 N-N E EE EE 3 W-W I W W 4 W-W E EE W* 5 W-N I EN EN 6 W-N E EE EE The only place W* can be used is in case 4 (in Scenario 2), where both node= s are WESP-capable and the traffic is encrypted. But, in both scenarios, an= intermediate device will encounter ESP traffic that may or may not be encr= ypted, in cases 1, 2, 5, and 6. So, it appears to me that the intermediate = device needs to use heuristics until there are NO non-WESP nodes. At that t= ime, we are dealing only with cases 3 & 4. But, in either scenario, these t= wo cases present an intermediate device with unambiguous info for deciding = whether a packet can be inspected. This analysis suggests that there is no need for the flag when all nodes ar= e WESP-capable, and no benefit when there are a mix of WESP-capable and leg= acy nodes. Steve --_000_47FF8C26716A4E45993305F326EFE4A2018A04TK5EX14MBXW603win_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [IPsec] Traffic visibility - consensus call

Remember, the goal isn’t necessarily to provide the fu= ll cross product of all possible permutations, which is what you’ve done. = ; The goal is to satisfy the customer scenarios.   Only if the customer really = needs all the cross product permutations, do they come into play.

 

My argument is that a very good deployment strategy that wil= l meet many customer scenarios is precisely to prune your matrix to make things deterministic to the intermediaries.    

 

In terms of your chart, that means that the only allowed com= binations (of this scenario) are:

 

Case    Nodes   Flow =    S 1     S 2

1       N-N  &= nbsp;  I       EN      EN 3     W-W     I   &n= bsp;   W       W
4      W-W     E  &n= bsp;    EE      W*
5     W-N     I   &n= bsp;   EN      EN

 

Hence any (legitimate) ESP traffic that the intermediary see= s must be ESP-NULL, and the encypt flag is critical, as it is the mechanism to ena= ble encryption between uplevel machines.

 

The main point of WESP is to remove heuristics from intermed= iary processing.    Hence we need to focus on the scenarios that = actually allow us to do that, and enable as many of them as possible.

 

bs

 

 

 

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Stephen Kent
Sent: Wednesday, January 06, 2010 10:37 AM
To: Brian Swander
Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro
Subject: Re: [IPsec] Traffic visibility - consensus call<= /span>

 

At 5:42 PM +0000 1/6/10, Brian Swander wrote:

The uplevel machines can't use ESP to send the encrypt= ed traffic in this scenario.  Remember, that we need to look at the holis= tic scenario of how to deploy this in an environment where we have legacy machi= nes that don't do WESP.  And we need to satisfy the goal of deterministic intermediary visibility.

Hence, the best method I see is what I describe below.  The non-WESP machines MUST do ESP-NULL to allow visibility.  That means uplevel machines cannot use ESP to send encrypted, since otherwise intermediaries w= ould see both ESP-NULL, and ESP, and be forced back to heuristics.   Intermediaries would be configured (in this scenario) to assume that ESP al= ways means ESP-NULL.


bs

 

Sorry, Brian, I still don't understand the scenario.&n= bsp; Let's see if a detailed analysis can help.

 

In a mixed environment, there are two classes of machi= nes: WESP-capable and not.  That yields 3 types of connections, and 6 types= of flows.  Let's label end systems (nodes) as W (for WESP-capable) and N = (for not WESP-capable), and label traffic as I (integrity protected, but not encrypted) and E (for encrypted). Finally, label the protocols as W (WESP),= W* (WESP with the encrypted content flag set), EE (ESP-encrypted) and EN (ESP-NULL).  The following table shows the flows and protocols that co= uld result in 2 scenarios: Scenario 1 is WESP as originally proposed and Scenar= io 2 is with super-WESP.

 

Case    Nodes   Flow =    S 1     S 2

1       N-N  &= nbsp;  I       EN      EN 2     N-N     E   &n= bsp;   EE      EE
3     W-W     I   &n= bsp;   W       W
4      W-W     E  &n= bsp;    EE      W*
5     W-N     I   &n= bsp;   EN      EN

6       W-N  &= nbsp;  E       EE      EE

 

The only place W* can be used is in case 4 (in Scenari= o 2), where both nodes are WESP-capable and the traffic is encrypted. But, in bot= h scenarios, an intermediate device will encounter ESP traffic that may or ma= y not be encrypted, in cases 1, 2, 5, and 6. So, it appears to me that the intermediate device needs to use heuristics until there are NO non-WESP nod= es. At that time, we are dealing only with cases 3 & 4. But, in either scen= ario, these two cases present an intermediate device with unambiguous info for deciding whether a packet can be inspected.

 

This analysis suggests that there is no need for the f= lag when all nodes are WESP-capable, and no benefit when there are a mix of WESP-capable and legacy nodes.

 

Steve

--_000_47FF8C26716A4E45993305F326EFE4A2018A04TK5EX14MBXW603win_-- From briansw@microsoft.com Wed Jan 6 11:08:18 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EE2C28C0D8; Wed, 6 Jan 2010 11:08:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e70HHGsdRaYe; Wed, 6 Jan 2010 11:08:13 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 3D1EA28C0E7; Wed, 6 Jan 2010 11:08:13 -0800 (PST) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 6 Jan 2010 11:08:51 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.0.639.20; Wed, 6 Jan 2010 11:08:01 -0800 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.27]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Wed, 6 Jan 2010 11:08:02 -0800 From: Brian Swander To: Scott C Moonen Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AQHKjjsDFMfT79gUNESgtZlfXT4hYpGIAOaAgAAF3ACAAKG5LIAAKXdwgACcpgD//3vuUA== Date: Wed, 6 Jan 2010 19:08:00 +0000 Message-ID: <47FF8C26716A4E45993305F326EFE4A2018A14@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_47FF8C26716A4E45993305F326EFE4A2018A14TK5EX14MBXW603win_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" , "ipsec-bounces@ietf.org" , Russ Housley , gabriel montenegro , Stephen Kent Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 19:08:18 -0000 --_000_47FF8C26716A4E45993305F326EFE4A2018A14TK5EX14MBXW603win_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See my response to Stephen Kent, and let me know if that doesn't clarify ad= equately. bs From: Scott C Moonen [mailto:smoonen@us.ibm.com] Sent: Wednesday, January 06, 2010 11:00 AM To: Brian Swander Cc: gabriel montenegro; Russ Housley; ipsec@ietf.org; ipsec-bounces@ietf.or= g; Stephen Kent Subject: Re: [IPsec] Traffic visibility - consensus call Brian, the middle box could never "assume that ESP always means ESP-NULL" b= ecause the down-level nodes (as well as any up-level node talking to them) = will use ESP for encrypted traffic as well. Moreover, this is a soft sort of begging the question because it is assumin= g that WESP will be widely adopted in order to argue for it to be even more= widely used. I remain unconvinced of that assumption, and I am definitely= unconvinced that there is zero cost to happily assuming the up-level nodes= can always and freely use WESP for encrypted traffic. All this does nothi= ng to encourage those down-level nodes to get with the WESP program, and I = think that is your real challenge. Again, I'm not saying that there is no = conceivable value to encrypted WESP, just that if this is your concern then= encrypted WESP is not the answer. Finally, if WESP really is going to be that widely used, then we really nee= d to scrap it and talk about whether there is warrant to do a real ESPv4 in= stead of backdooring it like this. WESP is not a suitable ESPv4. And if W= ESP is going to be that quickly and widely adopted then there should be no = trouble getting consensus to do ESPv4. ;) Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Brian Swander To: Stephen Kent Cc: "ipsec@ietf.org" , Russ Housley , gab= riel montenegro Date: 01/06/2010 12:42 PM Subject: Re: [IPsec] Traffic visibility - consensus call ________________________________ The uplevel machines can't use ESP to send the encrypted traffic in this sc= enario. Remember, that we need to look at the holistic scenario of how to = deploy this in an environment where we have legacy machines that don't do W= ESP. And we need to satisfy the goal of deterministic intermediary visibil= ity. Hence, the best method I see is what I describe below. The non-WESP machin= es MUST do ESP-NULL to allow visibility. That means uplevel machines canno= t use ESP to send encrypted, since otherwise intermediaries would see both = ESP-NULL, and ESP, and be forced back to heuristics. Intermediaries would= be configured (in this scenario) to assume that ESP always means ESP-NULL. bs -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Wednesday, January 06, 2010 7:07 AM To: Brian Swander Cc: gabriel montenegro; Russ Housley; ipsec@ietf.org Subject: Re: [IPsec] Traffic visibility - consensus call At 10:10 PM +0000 1/5/10, Brian Swander wrote: >I'll resend my message from earlier today that gives a concrete >scenario for why the WESP encryption bit is in charter. > >To satisfy the existing charter item, we need a deployable solution, >which entails working with legacy systems that don't support this >functionality yet. > >Here's an explicit scenario that requires the encrypted bit for >WESP, fully within the current charter of enabling ESP-NULL >inspection. > >Transport policies for within an organization that want to enable >intermediary inspection of ESP-NULL non-heurisitically. >Organization has a mix of version of systems. > >Sample policy: >When talking to/from non-WESP capable machines: must do ESP-NULL only >When both peers are WESP capable: do WESP/ESP-NULL most places. >However, where policy requires encryption, do WESP/ESP. This is where I have a problem with the analysis. If the policy were that WESP-capable hosts did ESP when then needed to send encrypted traffic, the flag inn question would not be needed, right? I don't think we can justify the inclusion of this flag based on the scenario you described above, because that scenario adopts a particular local policy that it not required. Steve _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_47FF8C26716A4E45993305F326EFE4A2018A14TK5EX14MBXW603win_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

See my response to Stephen Kent, and let me know if that doe= sn’t clarify adequately.

 

bs

 

 

From: Scott C Moone= n [mailto:smoonen@us.ibm.com]
Sent: Wednesday, January 06, 2010 11:00 AM
To: Brian Swander
Cc: gabriel montenegro; Russ Housley; ipsec@ietf.org; ipsec-bounces@ietf.org; Stephen Kent
Subject: Re: [IPsec] Traffic visibility - consensus call<= /span>

 


Brian, th= e middle box could never "assume that ESP always means ESP-NULL" because the down-level nodes (as well as any up-level node talking to them) will use ESP for encrypted traffic as well.

Moreover,= this is a soft sort of begging the question because it is assuming that WESP wil= l be widely adopted in order to argue for it to be even more widely used.  = I remain unconvinced of that assumption, and I am definitely unconvinced that there is zero cost to happily assuming the up-level nodes can always and fr= eely use WESP for encrypted traffic.  All this does nothing to encourage th= ose down-level nodes to get with the WESP program, and I think that is your rea= l challenge.  Again, I'm not saying that there is no conceivable value t= o encrypted WESP, just that if this is your concern then encrypted WESP is no= t the answer.

Finally, = if WESP really is going to be that widely used, then we really need to scrap i= t and talk about whether there is warrant to do a real ESPv4 instead of backdooring it like this.  WESP is not a suitable ESPv4.  And if = WESP is going to be that quickly and widely adopted then there should be no trou= ble getting consensus to do ESPv4.  ;)


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen=

From:

Brian Swander <briansw@microsoft.com>

To:

Stephen Kent <kent@bbn.com>

Cc:

"ipsec@ietf.org" <ipsec@ietf.org>, Russ Housley <housley@vigilsec.com>, gabrie= l montenegro <g_e_montenegro@yahoo.com>

Date:

01/06/2010 12:42 PM

Subject:

Re: [IPsec] Traffic visibility - consensus call

 




The uplevel machines can't use ESP to = send the encrypted traffic in this scenario.  Remember, that we need to loo= k at the holistic scenario of how to deploy this in an environment where we have legacy machines that don't do WESP.  And we need to satisfy the goal o= f deterministic intermediary visibility.

Hence, the best method I see is what I describe below.  The non-WE= SP machines MUST do ESP-NULL to allow visibility.  That means uplevel machines cannot use ESP to send encrypted, since otherwise intermediaries w= ould see both ESP-NULL, and ESP, and be forced back to heuristics.   Intermediaries would be configured (in this scenario) to assume that ESP al= ways means ESP-NULL.

bs



-----Original Message-----
From: Stephen Kent [mailto:kent@bbn.com]
Sent: Wednesday, January 06, 2010 7:07 AM
To: Brian Swander
Cc: gabriel montenegro; Russ Housley; ipsec@ietf.org
Subject: Re: [IPsec] Traffic visibility - consensus call

At 10:10 PM +0000 1/5/10, Brian Swander wrote:
>I'll resend my message from earlier today that gives a concrete
>scenario for why the WESP encryption bit is in charter.  =
>
>To satisfy the existing charter item, we need a deployable solution= ,
>which entails working with legacy systems that don't support this <= /tt>
>functionality yet.
>
>Here's an explicit scenario that requires the encrypted bit for
>WESP, fully within the current charter of enabling ESP-NULL >inspection.
>
>Transport policies for within an organization that want to enable <= /tt>
>intermediary inspection of ESP-NULL non-heurisitically.
>Organization has a mix of version of systems.
>
>Sample policy:
>When talking to/from non-WESP capable machines:  must do ESP-N= ULL only
>When both peers are WESP capable: do WESP/ESP-NULL most places.
>However, where policy requires encryption, do WESP/ESP.

This is where I have a problem with the analysis. If the policy were
that WESP-capable hosts did ESP when then needed to send encrypted
traffic, the flag inn question would not be needed, right?

I don't think we can justify the inclusion of this flag based on the
scenario you described above, because that scenario adopts a
particular local policy that it not required.

Steve

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--_000_47FF8C26716A4E45993305F326EFE4A2018A14TK5EX14MBXW603win_-- From yaronf@checkpoint.com Wed Jan 6 11:21:54 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C97728C14A for ; Wed, 6 Jan 2010 11:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YeLSk7SzcCa for ; Wed, 6 Jan 2010 11:21:46 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 04F863A685B for ; Wed, 6 Jan 2010 11:21:45 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o06JLST7022084; Wed, 6 Jan 2010 21:21:28 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 6 Jan 2010 21:21:41 +0200 From: Yaron Sheffer To: Brian Swander , Stephen Kent Date: Wed, 6 Jan 2010 21:21:22 +0200 Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AQHKjv8+FMfT79gUNESgtZlfXT4hYpGI5nLQgAADIEA= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C50A3@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C50A3ilex01adche_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Russ Housley , gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 19:21:54 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C50A3ilex01adche_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Brian, [no hat on] I think your reasoning about the different scenarios actually demonstrates = that "super-WESP" is useful. But I have to strongly disagree with the state= ment below. Yes we should support all possible permutations. There's no rea= son why WESP should suddenly cause traffic that used to require encryption = to not require it any more. So I would put it differently: the WESP encrypt flag is what enables interm= ediaries to be implemented *efficiently* in a mixed environment, with old a= nd new endpoints, encrypted and integrity-protected traffic. Thanks, Yaron From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of B= rian Swander Sent: Wednesday, January 06, 2010 21:07 To: Stephen Kent Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call Remember, the goal isn't necessarily to provide the full cross product of a= ll possible permutations, which is what you've done. The goal is to satisf= y the customer scenarios. Only if the customer really needs all the cross= product permutations, do they come into play. My argument is that a very good deployment strategy that will meet many cus= tomer scenarios is precisely to prune your matrix to make things determinis= tic to the intermediaries. In terms of your chart, that means that the only allowed combinations (of t= his scenario) are: Case Nodes Flow S 1 S 2 1 N-N I EN EN 3 W-W I W W 4 W-W E EE W* 5 W-N I EN EN Hence any (legitimate) ESP traffic that the intermediary sees must be ESP-N= ULL, and the encypt flag is critical, as it is the mechanism to enable encr= yption between uplevel machines. The main point of WESP is to remove heuristics from intermediary processing= . Hence we need to focus on the scenarios that actually allow us to do t= hat, and enable as many of them as possible. bs From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of S= tephen Kent Sent: Wednesday, January 06, 2010 10:37 AM To: Brian Swander Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call At 5:42 PM +0000 1/6/10, Brian Swander wrote: The uplevel machines can't use ESP to send the encrypted traffic in this sc= enario. Remember, that we need to look at the holistic scenario of how to = deploy this in an environment where we have legacy machines that don't do W= ESP. And we need to satisfy the goal of deterministic intermediary visibil= ity. Hence, the best method I see is what I describe below. The non-WESP machin= es MUST do ESP-NULL to allow visibility. That means uplevel machines canno= t use ESP to send encrypted, since otherwise intermediaries would see both = ESP-NULL, and ESP, and be forced back to heuristics. Intermediaries would= be configured (in this scenario) to assume that ESP always means ESP-NULL. bs Sorry, Brian, I still don't understand the scenario. Let's see if a detail= ed analysis can help. In a mixed environment, there are two classes of machines: WESP-capable and= not. That yields 3 types of connections, and 6 types of flows. Let's lab= el end systems (nodes) as W (for WESP-capable) and N (for not WESP-capable)= , and label traffic as I (integrity protected, but not encrypted) and E (fo= r encrypted). Finally, label the protocols as W (WESP), W* (WESP with the e= ncrypted content flag set), EE (ESP-encrypted) and EN (ESP-NULL). The foll= owing table shows the flows and protocols that could result in 2 scenarios:= Scenario 1 is WESP as originally proposed and Scenario 2 is with super-WES= P. Case Nodes Flow S 1 S 2 1 N-N I EN EN 2 N-N E EE EE 3 W-W I W W 4 W-W E EE W* 5 W-N I EN EN 6 W-N E EE EE The only place W* can be used is in case 4 (in Scenario 2), where both node= s are WESP-capable and the traffic is encrypted. But, in both scenarios, an= intermediate device will encounter ESP traffic that may or may not be encr= ypted, in cases 1, 2, 5, and 6. So, it appears to me that the intermediate = device needs to use heuristics until there are NO non-WESP nodes. At that t= ime, we are dealing only with cases 3 & 4. But, in either scenario, these t= wo cases present an intermediate device with unambiguous info for deciding = whether a packet can be inspected. This analysis suggests that there is no need for the flag when all nodes ar= e WESP-capable, and no benefit when there are a mix of WESP-capable and leg= acy nodes. Steve Scanned by Check Point Total Security Gateway. --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C50A3ilex01adche_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [IPsec] Traffic visibility - consensus call

Hi Brian,

 

[no hat on]

 

I think your reasoning about the different scenarios actuall= y demonstrates that “super-WESP” is useful. But I have to strongl= y disagree with the statement below. Yes we should support all possible permu= tations. There’s no reason why WESP should suddenly cause traffic that used to require encryption to not require it any more.

 

So I would put it differently: the WESP encrypt flag is what enables intermediaries to be implemented *efficiently* in a mixed environment, with old and new endpoints, encrypted and integrity-protected traffic.

 

Thanks,

          =       Yaron

 

From: ipsec-bounces= @ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Brian Swander
Sent: Wednesday, January 06, 2010 21:07
To: Stephen Kent
Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro
Subject: Re: [IPsec] Traffic visibility - consensus call<= /span>

 

Remember, the goal isn’t necessarily to provide the fu= ll cross product of all possible permutations, which is what you’ve done.  The goal is to satisfy the customer scenarios.   Only= if the customer really needs all the cross product permutations, do they come = into play.

 

My argument is that a very good deployment strategy that wil= l meet many customer scenarios is precisely to prune your matrix to make thin= gs deterministic to the intermediaries.    

 

In terms of your chart, that means that the only allowed combinations (of this scenario) are:

 

Case    Nodes   Flow    S 1     S 2

1       N-N     I       EN      EN
3     W-W     I       W      = W
4      W-W     E       EE      W* 5     W-N     I       EN      EN

 

Hence any (legitimate) ESP traffic that the intermediary see= s must be ESP-NULL, and the encypt flag is critical, as it is the mechanism t= o enable encryption between uplevel machines.

 

The main point of WESP is to remove heuristics from intermed= iary processing.    Hence we need to focus on the scenarios that actually allow us to do that, and enable as many of them as possible.<= /o:p>

 

bs

 

 

 

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Stephen Kent
Sent: Wednesday, January 06, 2010 10:37 AM
To: Brian Swander
Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro
Subject: Re: [IPsec] Traffic visibility - consensus call<= /span>

 

At 5:42 PM +0000 1/6/10, Brian Swander wrote:

The uplevel machines can't use ESP to send the encrypt= ed traffic in this scenario.  Remember, that we need to look at the holis= tic scenario of how to deploy this in an environment where we have legacy machi= nes that don't do WESP.  And we need to satisfy the goal of deterministic intermediary visibility.

Hence, the best method I see is what I describe below.  The non-WESP machines MUST do ESP-NULL to allow visibility.  That means uplevel machines cannot use ESP to send encrypted, since otherwise intermediaries w= ould see both ESP-NULL, and ESP, and be forced back to heuristics.   Intermediaries would be configured (in this scenario) to assume that ESP al= ways means ESP-NULL.


bs

 

Sorry, Brian, I still don't understand the scenario.&n= bsp; Let's see if a detailed analysis can help.

 

In a mixed environment, there are two classes of machi= nes: WESP-capable and not.  That yields 3 types of connections, and 6 types= of flows.  Let's label end systems (nodes) as W (for WESP-capable) and N = (for not WESP-capable), and label traffic as I (integrity protected, but not encrypted) and E (for encrypted). Finally, label the protocols as W (WESP),= W* (WESP with the encrypted content flag set), EE (ESP-encrypted) and EN (ESP-NULL).  The following table shows the flows and protocols that co= uld result in 2 scenarios: Scenario 1 is WESP as originally proposed and Scenar= io 2 is with super-WESP.

 

Case    Nodes   Flow    S 1     S 2

1       N-N     I       EN      EN
2     N-N     E       EE      EE 3     W-W     I       W      = W
4      W-W     E       EE      W* 5     W-N     I       EN      EN

6       W-N     E       EE      EE

 

The only place W* can be used is in case 4 (in Scenari= o 2), where both nodes are WESP-capable and the traffic is encrypted. But, in bot= h scenarios, an intermediate device will encounter ESP traffic that may or ma= y not be encrypted, in cases 1, 2, 5, and 6. So, it appears to me that the intermediate device needs to use heuristics until there are NO non-WESP nod= es. At that time, we are dealing only with cases 3 & 4. But, in either scenario, these two cases present an intermediate device with unambiguous i= nfo for deciding whether a packet can be inspected.

 

This analysis suggests that there is no need for the f= lag when all nodes are WESP-capable, and no benefit when there are a mix of WESP-capable and legacy nodes.

 

Steve



Scanned by Check Point Total Security Gateway.

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C50A3ilex01adche_-- From kent@bbn.com Wed Jan 6 11:28:01 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33DB628C114; Wed, 6 Jan 2010 11:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFR4KuVsqPbN; Wed, 6 Jan 2010 11:28:00 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 61C743A68FD; Wed, 6 Jan 2010 11:28:00 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.5]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NSbXy-0007ty-AP; Wed, 06 Jan 2010 14:27:58 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C509F@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <4B43C2A8.6010302@vigilsec.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C506D@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C509F@il-ex01.ad.checkpoint.com> Date: Wed, 6 Jan 2010 14:27:55 -0500 To: Yaron Sheffer From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" , Venkatesh Sriram , "ipsec-bounces@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 19:28:01 -0000 At 8:56 PM +0200 1/6/10, Yaron Sheffer wrote: >Hi Steve, > >Please reread my text. I was (in that paragraph) taking Manav's >side, i.e. assuming there's value in deterministic distinction >between encrypted and unencrypted ESP, and hence, gradually moving >the endpoints to WESP so that middleboxes have an easier time. > >As we know, this opinion is not shared by everyone. > >Thanks, > Yaron Yaron, Sorry. I missed that element of the context that you were assuming. Nonetheless, the analysis I just sent in response to Brian's message suggests that determinism is not possible if we consider the general case of WESP-capable and legacy devices and a mix of encrypted and integrity-only flows. That motivated my response. That analysis is not an opinion :-). But, in fairness, I had not yet generated the analysis when I sent my message, so ... Steve From briansw@microsoft.com Wed Jan 6 11:28:22 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0263F28C114 for ; Wed, 6 Jan 2010 11:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsZiy-DYhiYq for ; Wed, 6 Jan 2010 11:28:21 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 1A2C928C13F for ; Wed, 6 Jan 2010 11:28:21 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 6 Jan 2010 11:28:59 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.0.639.21; Wed, 6 Jan 2010 11:28:19 -0800 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.27]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Wed, 6 Jan 2010 11:28:19 -0800 From: Brian Swander To: Paul Hoffman , gabriel montenegro , Russ Housley Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AQHKjviaFMfT79gUNESgtZlfXT4hYpGI3SzZgAAQDxA= Date: Wed, 6 Jan 2010 19:28:18 +0000 Message-ID: <47FF8C26716A4E45993305F326EFE4A2018A45@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A201891B@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 19:28:22 -0000 I'd like to understand your policies for deploying your proposal below that= meets the charter item. Here are the customer scenario requirements: Legacy systems that don't support WESP (lots of them) Requirements to do encryption between some machines. Willing to upgrade po= ckets of machines to accomplish this. Routing infrastructure that doesn't do heuristics Requires intermediaries that can do full ESP-NULL parsing. bs -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org]=20 Sent: Wednesday, January 06, 2010 10:21 AM To: Brian Swander; gabriel montenegro; Russ Housley Cc: ipsec@ietf.org Subject: RE: [IPsec] Traffic visibility - consensus call No hat. At 5:56 PM +0000 1/6/10, Brian Swander wrote: >But that doesn't give us any path to actually do encryption (in environmen= ts with legacy systems) - hence the proposal is untenable. That doesn't make sense: it is *exactly* the same path as we have today. WE= SP-as-envisioned gives us one extra capability; WESP-as-it-is-today gives u= s two. The "path to actually do encryption (in environments with legacy sys= tems)" is to use ESP exactly as it is being done today by dozens of vendors= , including you. >I'd argue it therefore doesn't satisfy the charter item. The charter ite= m is a deployable mechanism that lets intermediaries inspect ESP-NULL when = present. This charter item surely shouldn't mandate that we can now no lon= ger use encrypted ESP at all. Please don't reduce this to absurd straw men. The charter item is quite cle= ar: A standards-track mechanism that allows an intermediary device, such as a firewall or intrusion detection system, to easily and reliably determine whether an ESP packet is encrypted with the NULL cipher; and if it is, determine the location of the actual payload data inside the packet. WESP-over-ESP-NULL-only fulfills that charter item. WESP-as-it-is-today doe= s it as well, but adds additional features and extensibility. The question = in this thread is whether to back down to WESP-over-ESP-NULL-only. >Clearly we need a solution that also lets us use encrypted traffic where n= eeded, but not break inspection of integrity only traffic. How do we meet = that with your proposal below? As it is done today, and adding in WESP-over-ESP-NULL-only. >We must make sure that we have a solution that is deployable and useful in= the real world. Really, you think so? :-) --Paul Hoffman, Director --VPN Consortium From briansw@microsoft.com Wed Jan 6 11:34:05 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AD7C3A68FD for ; Wed, 6 Jan 2010 11:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7kUgprTW76K for ; Wed, 6 Jan 2010 11:33:56 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id B1C8B3A685B for ; Wed, 6 Jan 2010 11:33:56 -0800 (PST) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 6 Jan 2010 11:34:35 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.0.639.20; Wed, 6 Jan 2010 11:33:55 -0800 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.27]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Wed, 6 Jan 2010 11:33:56 -0800 From: Brian Swander To: Yaron Sheffer , Stephen Kent Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AQHKjv8+FMfT79gUNESgtZlfXT4hYpGI5nLQgAADIECAAAWGUA== Date: Wed, 6 Jan 2010 19:33:53 +0000 Message-ID: <47FF8C26716A4E45993305F326EFE4A2018A7E@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C50A3@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C50A3@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_47FF8C26716A4E45993305F326EFE4A2018A7ETK5EX14MBXW603win_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Russ Housley , gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 19:34:05 -0000 --_000_47FF8C26716A4E45993305F326EFE4A2018A7ETK5EX14MBXW603win_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I never meant to imply WESP would reduce encryption requirements. If the = customer traffic has to be encrypted, then it will be or the scenario isn't= satisfied. In the below, to meet that customer requirement, the custome= r would need to upgrade the machines that require encryption to the latest = version (in this proposal). However, all the other machines can remain unt= ouched. Yes we need to support all possible permutations in the product. I was tal= king about a specific scenario. If intermediaries have good heuristic sup= port, etc, then more permutations open up. But we can't assume intermedia= ries must implement heuristics. bs From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= aron Sheffer Sent: Wednesday, January 06, 2010 11:21 AM To: Brian Swander; Stephen Kent Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call Hi Brian, [no hat on] I think your reasoning about the different scenarios actually demonstrates = that "super-WESP" is useful. But I have to strongly disagree with the state= ment below. Yes we should support all possible permutations. There's no rea= son why WESP should suddenly cause traffic that used to require encryption = to not require it any more. So I would put it differently: the WESP encrypt flag is what enables interm= ediaries to be implemented *efficiently* in a mixed environment, with old a= nd new endpoints, encrypted and integrity-protected traffic. Thanks, Yaron From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of B= rian Swander Sent: Wednesday, January 06, 2010 21:07 To: Stephen Kent Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call Remember, the goal isn't necessarily to provide the full cross product of a= ll possible permutations, which is what you've done. The goal is to satisf= y the customer scenarios. Only if the customer really needs all the cross= product permutations, do they come into play. My argument is that a very good deployment strategy that will meet many cus= tomer scenarios is precisely to prune your matrix to make things determinis= tic to the intermediaries. In terms of your chart, that means that the only allowed combinations (of t= his scenario) are: Case Nodes Flow S 1 S 2 1 N-N I EN EN 3 W-W I W W 4 W-W E EE W* 5 W-N I EN EN Hence any (legitimate) ESP traffic that the intermediary sees must be ESP-N= ULL, and the encypt flag is critical, as it is the mechanism to enable encr= yption between uplevel machines. The main point of WESP is to remove heuristics from intermediary processing= . Hence we need to focus on the scenarios that actually allow us to do t= hat, and enable as many of them as possible. bs From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of S= tephen Kent Sent: Wednesday, January 06, 2010 10:37 AM To: Brian Swander Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call At 5:42 PM +0000 1/6/10, Brian Swander wrote: The uplevel machines can't use ESP to send the encrypted traffic in this sc= enario. Remember, that we need to look at the holistic scenario of how to = deploy this in an environment where we have legacy machines that don't do W= ESP. And we need to satisfy the goal of deterministic intermediary visibil= ity. Hence, the best method I see is what I describe below. The non-WESP machin= es MUST do ESP-NULL to allow visibility. That means uplevel machines canno= t use ESP to send encrypted, since otherwise intermediaries would see both = ESP-NULL, and ESP, and be forced back to heuristics. Intermediaries would= be configured (in this scenario) to assume that ESP always means ESP-NULL. bs Sorry, Brian, I still don't understand the scenario. Let's see if a detail= ed analysis can help. In a mixed environment, there are two classes of machines: WESP-capable and= not. That yields 3 types of connections, and 6 types of flows. Let's lab= el end systems (nodes) as W (for WESP-capable) and N (for not WESP-capable)= , and label traffic as I (integrity protected, but not encrypted) and E (fo= r encrypted). Finally, label the protocols as W (WESP), W* (WESP with the e= ncrypted content flag set), EE (ESP-encrypted) and EN (ESP-NULL). The foll= owing table shows the flows and protocols that could result in 2 scenarios:= Scenario 1 is WESP as originally proposed and Scenario 2 is with super-WES= P. Case Nodes Flow S 1 S 2 1 N-N I EN EN 2 N-N E EE EE 3 W-W I W W 4 W-W E EE W* 5 W-N I EN EN 6 W-N E EE EE The only place W* can be used is in case 4 (in Scenario 2), where both node= s are WESP-capable and the traffic is encrypted. But, in both scenarios, an= intermediate device will encounter ESP traffic that may or may not be encr= ypted, in cases 1, 2, 5, and 6. So, it appears to me that the intermediate = device needs to use heuristics until there are NO non-WESP nodes. At that t= ime, we are dealing only with cases 3 & 4. But, in either scenario, these t= wo cases present an intermediate device with unambiguous info for deciding = whether a packet can be inspected. This analysis suggests that there is no need for the flag when all nodes ar= e WESP-capable, and no benefit when there are a mix of WESP-capable and leg= acy nodes. Steve Scanned by Check Point Total Security Gateway. --_000_47FF8C26716A4E45993305F326EFE4A2018A7ETK5EX14MBXW603win_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [IPsec] Traffic visibility - consensus call

I never meant to imply WESP would reduce encryption requirements.   If the customer traffic has to be encrypted, then= it will be or the scenario isn’t satisfied.    In the below, to meet= that customer requirement, the customer would need to upgrade the machines that require encryption to the latest version (in this proposal).  However, all the= other machines can remain untouched.

 

Yes we need to support all possible permutations in the product.  I was talking about a specific scenario.   If inte= rmediaries have good heuristic support, etc, then more permutations open up.   Bu= t we can’t assume intermediaries must implement heuristics.

 

bs

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Yaron Sheffer
Sent: Wednesday, January 06, 2010 11:21 AM
To: Brian Swander; Stephen Kent
Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro
Subject: Re: [IPsec] Traffic visibility - consensus call<= /span>

 

Hi Brian,

 

[no hat on]

 

I think your reasoning about the different scenarios actuall= y demonstrates that “super-WESP” is useful. But I have to strongl= y disagree with the statement below. Yes we should support all possible permutations. There= ’s no reason why WESP should suddenly cause traffic that used to require encryption to not require it any more.

 

So I would put it differently: the WESP encrypt flag is what enables intermediaries to be implemented *efficiently* in a mixed environment, with old and new endpoints, encrypted and integrity-protected traffic.

 

Thanks,

          =       Yaron

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Brian Swander
Sent: Wednesday, January 06, 2010 21:07
To: Stephen Kent
Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro
Subject: Re: [IPsec] Traffic visibility - consensus call<= /span>

 

Remember, the goal isn’t necessarily to provide the fu= ll cross product of all possible permutations, which is what you’ve done. = ; The goal is to satisfy the customer scenarios.   Only if the customer real= ly needs all the cross product permutations, do they come into play.

 

My argument is that a very good deployment strategy that wil= l meet many customer scenarios is precisely to prune your matrix to make thin= gs deterministic to the intermediaries.    

 

In terms of your chart, that means that the only allowed combinations (of this scenario) are:

 

Case    Nodes   Flow    S 1     S 2

1       N-N     I       EN      EN
3     W-W     I       W      = W
4      W-W     E       EE      W* 5     W-N     I       EN      EN

 

Hence any (legitimate) ESP traffic that the intermediary see= s must be ESP-NULL, and the encypt flag is critical, as it is the mechanism t= o enable encryption between uplevel machines.

 

The main point of WESP is to remove heuristics from intermed= iary processing.    Hence we need to focus on the scenarios that actually allow us to do that, and enable as many of them as possible.<= /o:p>

 

bs

 

 

 

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Stephen Kent
Sent: Wednesday, January 06, 2010 10:37 AM
To: Brian Swander
Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro
Subject: Re: [IPsec] Traffic visibility - consensus call<= /span>

 

At 5:42 PM +0000 1/6/10, Brian Swander wrote:

The uplevel machines can't use ESP to send the encrypt= ed traffic in this scenario.  Remember, that we need to look at the holis= tic scenario of how to deploy this in an environment where we have legacy machi= nes that don't do WESP.  And we need to satisfy the goal of deterministic intermediary visibility.

Hence, the best method I see is what I describe below.  The non-WESP machines MUST do ESP-NULL to allow visibility.  That means uplevel machines cannot use ESP to send encrypted, since otherwise intermediaries w= ould see both ESP-NULL, and ESP, and be forced back to heuristics.   Intermediaries would be configured (in this scenario) to assume that ESP al= ways means ESP-NULL.


bs

 

Sorry, Brian, I still don't understand the scenario.&n= bsp; Let's see if a detailed analysis can help.

 

In a mixed environment, there are two classes of machi= nes: WESP-capable and not.  That yields 3 types of connections, and 6 types= of flows.  Let's label end systems (nodes) as W (for WESP-capable) and N = (for not WESP-capable), and label traffic as I (integrity protected, but not encrypted) and E (for encrypted). Finally, label the protocols as W (WESP),= W* (WESP with the encrypted content flag set), EE (ESP-encrypted) and EN (ESP-NULL).  The following table shows the flows and protocols that co= uld result in 2 scenarios: Scenario 1 is WESP as originally proposed and Scenar= io 2 is with super-WESP.

 

Case    Nodes   Flow    S 1     S 2

1       N-N     I       EN      EN
2     N-N     E       EE      EE 3     W-W     I       W      = W
4      W-W     E       EE      W* 5     W-N     I       EN      EN

6       W-N     E       EE      EE

 

The only place W* can be used is in case 4 (in Scenari= o 2), where both nodes are WESP-capable and the traffic is encrypted. But, in bot= h scenarios, an intermediate device will encounter ESP traffic that may or ma= y not be encrypted, in cases 1, 2, 5, and 6. So, it appears to me that the intermediate device needs to use heuristics until there are NO non-WESP nod= es. At that time, we are dealing only with cases 3 & 4. But, in either scenario, these two cases present an intermediate device with unambiguous i= nfo for deciding whether a packet can be inspected.

 

This analysis suggests that there is no need for the f= lag when all nodes are WESP-capable, and no benefit when there are a mix of WESP-capable and legacy nodes.

 

Steve



Scanned by Check Point Total Security Gateway.

--_000_47FF8C26716A4E45993305F326EFE4A2018A7ETK5EX14MBXW603win_-- From yaronf@checkpoint.com Wed Jan 6 11:34:38 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D12A3A6814 for ; Wed, 6 Jan 2010 11:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biaWuQyDjVZ2 for ; Wed, 6 Jan 2010 11:34:34 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 14E6C3A6927 for ; Wed, 6 Jan 2010 11:34:28 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o06JYNT7023250; Wed, 6 Jan 2010 21:34:23 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 6 Jan 2010 21:34:36 +0200 From: Yaron Sheffer To: Stephen Kent , Brian Swander Date: Wed, 6 Jan 2010 21:34:19 +0200 Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AcqO/1BG4gnK1NklT1SIe9NbJSr8QAABnnJQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C50A5@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C50A5ilex01adche_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Russ Housley , gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 19:34:38 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C50A5ilex01adche_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Steve, [No hat.] Thanks for the analysis, I hope this'll help the discussion to converge. You are taking an either-or approach in the last paragraph below. But assum= ing that WESP is useful (bear with me...), there will be a gradual deployme= nt within any given network. I agree that heuristics will still be needed, = until the last endpoint is WESP-enabled (i.e., forever). But if we adopt W*= , during the migration less and less heuristic processing will be needed. M= uch of this discussion is about performance, so quantitative arguments are = also useful. Thanks, Yaron From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of S= tephen Kent Sent: Wednesday, January 06, 2010 20:37 To: Brian Swander Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call At 5:42 PM +0000 1/6/10, Brian Swander wrote: The uplevel machines can't use ESP to send the encrypted traffic in this sc= enario. Remember, that we need to look at the holistic scenario of how to = deploy this in an environment where we have legacy machines that don't do W= ESP. And we need to satisfy the goal of deterministic intermediary visibil= ity. Hence, the best method I see is what I describe below. The non-WESP machin= es MUST do ESP-NULL to allow visibility. That means uplevel machines canno= t use ESP to send encrypted, since otherwise intermediaries would see both = ESP-NULL, and ESP, and be forced back to heuristics. Intermediaries would= be configured (in this scenario) to assume that ESP always means ESP-NULL. bs Sorry, Brian, I still don't understand the scenario. Let's see if a detail= ed analysis can help. In a mixed environment, there are two classes of machines: WESP-capable and= not. That yields 3 types of connections, and 6 types of flows. Let's lab= el end systems (nodes) as W (for WESP-capable) and N (for not WESP-capable)= , and label traffic as I (integrity protected, but not encrypted) and E (fo= r encrypted). Finally, label the protocols as W (WESP), W* (WESP with the e= ncrypted content flag set), EE (ESP-encrypted) and EN (ESP-NULL). The foll= owing table shows the flows and protocols that could result in 2 scenarios:= Scenario 1 is WESP as originally proposed and Scenario 2 is with super-WES= P. Case Nodes Flow S 1 S 2 1 N-N I EN EN 2 N-N E EE EE 3 W-W I W W 4 W-W E EE W* 5 W-N I EN EN 6 W-N E EE EE The only place W* can be used is in case 4 (in Scenario 2), where both node= s are WESP-capable and the traffic is encrypted. But, in both scenarios, an= intermediate device will encounter ESP traffic that may or may not be encr= ypted, in cases 1, 2, 5, and 6. So, it appears to me that the intermediate = device needs to use heuristics until there are NO non-WESP nodes. At that t= ime, we are dealing only with cases 3 & 4. But, in either scenario, these t= wo cases present an intermediate device with unambiguous info for deciding = whether a packet can be inspected. This analysis suggests that there is no need for the flag when all nodes ar= e WESP-capable, and no benefit when there are a mix of WESP-capable and leg= acy nodes. Steve --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C50A5ilex01adche_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [IPsec] Traffic visibility - consensus call

Hi Steve,

 

[No hat.]

 

Thanks for the analysis, I hope this’ll help the discu= ssion to converge.

 

You are taking an either-or approach in the last paragraph below. But assuming that WESP is useful (bear with me…), there will b= e a gradual deployment within any given network. I agree that heuristics will s= till be needed, until the last endpoint is WESP-enabled (i.e., forever). But if = we adopt W*, during the migration less and less heuristic processing will be needed.= Much of this discussion is about performance, so quantitative arguments are also= useful.

 

Thanks,

          =       Yaron

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Stephen Kent
Sent: Wednesday, January 06, 2010 20:37
To: Brian Swander
Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro
Subject: Re: [IPsec] Traffic visibility - consensus call<= /span>

 

At 5:42 PM +0000 1/6/10, Brian Swander wrote:

The uplevel machines can't use ESP to send the encrypt= ed traffic in this scenario.  Remember, that we need to look at the holis= tic scenario of how to deploy this in an environment where we have legacy machi= nes that don't do WESP.  And we need to satisfy the goal of deterministic intermediary visibility.

Hence, the best method I see is what I describe below.  The non-WESP machines MUST do ESP-NULL to allow visibility.  That means uplevel machines cannot use ESP to send encrypted, since otherwise intermediaries w= ould see both ESP-NULL, and ESP, and be forced back to heuristics.   Intermediaries would be configured (in this scenario) to assume that ESP al= ways means ESP-NULL.


bs

 

Sorry, Brian, I still don't understand the scenario.&n= bsp; Let's see if a detailed analysis can help.

 

In a mixed environment, there are two classes of machi= nes: WESP-capable and not.  That yields 3 types of connections, and 6 types= of flows.  Let's label end systems (nodes) as W (for WESP-capable) and N = (for not WESP-capable), and label traffic as I (integrity protected, but not encrypted) and E (for encrypted). Finally, label the protocols as W (WESP),= W* (WESP with the encrypted content flag set), EE (ESP-encrypted) and EN (ESP-NULL).  The following table shows the flows and protocols that co= uld result in 2 scenarios: Scenario 1 is WESP as originally proposed and Scenar= io 2 is with super-WESP.

 

Case    Nodes   Flow =    S 1     S 2

1       N-N  &= nbsp;  I       EN      EN 2     N-N     E   &n= bsp;   EE      EE
3     W-W     I   &n= bsp;   W       W
4      W-W     E  &n= bsp;    EE      W*
5     W-N     I   &n= bsp;   EN      EN

6       W-N  &= nbsp;  E       EE      EE

 

The only place W* can be used is in case 4 (in Scenari= o 2), where both nodes are WESP-capable and the traffic is encrypted. But, in bot= h scenarios, an intermediate device will encounter ESP traffic that may or ma= y not be encrypted, in cases 1, 2, 5, and 6. So, it appears to me that the intermediate device needs to use heuristics until there are NO non-WESP nod= es. At that time, we are dealing only with cases 3 & 4. But, in either scenario, these two cases present an intermediate device with unambiguous i= nfo for deciding whether a packet can be inspected.

 

This analysis suggests that there is no need for the f= lag when all nodes are WESP-capable, and no benefit when there are a mix of WESP-capable and legacy nodes.

 

Steve

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C50A5ilex01adche_-- From kent@bbn.com Wed Jan 6 11:45:21 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0134228C0F3 for ; Wed, 6 Jan 2010 11:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4G0+GL1bdnqd for ; Wed, 6 Jan 2010 11:45:20 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id D1A8C28C108 for ; Wed, 6 Jan 2010 11:45:19 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.5]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NSboj-0008Ml-Bg; Wed, 06 Jan 2010 14:45:17 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> Date: Wed, 6 Jan 2010 14:45:14 -0500 To: Brian Swander From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-949315379==_ma============" Cc: "ipsec@ietf.org" , Russ Housley , gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 19:45:21 -0000 --============_-949315379==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 7:06 PM +0000 1/6/10, Brian Swander wrote: >Remember, the goal isn't necessarily to provide the full cross >product of all possible permutations, which is what you've done. >The goal is to satisfy the customer scenarios. Only if the >customer really needs all the cross product permutations, do they >come into play. I don't recall the WG having agreed upon a subset of cases that were deemed to be the only ones of interest. But, I admit to having missed some details of WESP as it evolved too, so maybe I missed this too. Can you refresh my memory on this point? > My argument is that a very good deployment strategy that will meet >many customer scenarios is precisely to prune your matrix to make >things deterministic to the intermediaries. This seems a lot like saying that we can convince customers that they need only a subset of the possible cases because these are the ones that we can address well! > In terms of your chart, that means that the only allowed >combinations (of this scenario) are: > >Case Nodes Flow S 1 S 2 >1 N-N I EN EN >3 W-W I W W >4 W-W E EE W* >5 W-N I EN EN I don't understand how one arrives at this subset. Why are legacy nodes prohibited form sending encrypted traffic in this context? Is the idea that this limitation will motivate deployment of WESP-enabled nodes? I don't think the rationale here has been clearly articulated. > Hence any (legitimate) ESP traffic that the intermediary sees must >be ESP-NULL, and the encypt flag is critical, as it is the mechanism >to enable encryption between uplevel machines. This seems to relate to my questions above. >The main point of WESP is to remove heuristics from intermediary >processing. Hence we need to focus on the scenarios that actually >allow us to do that, and enable as many of them as possible. I don't think it is reasonable to consider only those cases where the encrypted content flag will make things better, unless we have a very good, and agreed-upon, rationale for discarding the other cases. Steve --============_-949315379==_ma============ Content-Type: text/html; charset="us-ascii" RE: [IPsec] Traffic visibility - consensus call
At 7:06 PM +0000 1/6/10, Brian Swander wrote:
Remember, the goal isn't necessarily to provide the full cross product of all possible permutations, which is what you've done.  The goal is to satisfy the customer scenarios.   Only if the customer really needs all the cross product permutations, do they come into play.

I don't recall the WG having agreed upon a subset of cases that were deemed to be the only ones of interest. But, I admit to having missed some details of WESP as it evolved too, so maybe I missed this too. Can you refresh my memory on this point?

 My argument is that a very good deployment strategy that will meet many customer scenarios is precisely to prune your matrix to make things deterministic to the intermediaries.  

This seems a lot like saying that we can convince customers that they need only a subset of the possible cases because these are the ones that we can address well!

 In terms of your chart, that means that the only allowed combinations (of this scenario) are:
 
Case    Nodes   Flow    S 1     S 2
1       N-N     I       EN      EN
3     W-W     I       W       W
4      W-W     E       EE      W*
5     W-N     I       EN      EN

I don't understand how one arrives at this subset. Why are legacy nodes prohibited form sending encrypted traffic in this context? Is the idea that this limitation will motivate deployment of WESP-enabled nodes? I don't think the rationale here has been clearly articulated.

 Hence any (legitimate) ESP traffic that the intermediary sees must be ESP-NULL, and the encypt flag is critical, as it is the mechanism to enable encryption between uplevel machines.

This seems to relate to my questions above.

The main point of WESP is to remove heuristics from intermediary processing.   Hence we need to focus on the scenarios that actually allow us to do that, and enable as many of them as possible.
 
I don't think it is reasonable to consider only those cases where the encrypted content flag will make things better, unless we have a very good, and agreed-upon, rationale for discarding the other cases.

Steve
--============_-949315379==_ma============-- From ken.grewal@intel.com Wed Jan 6 11:49:50 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C8D928C131 for ; Wed, 6 Jan 2010 11:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOovfGbh4fvU for ; Wed, 6 Jan 2010 11:49:48 -0800 (PST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by core3.amsl.com (Postfix) with ESMTP id 5000A3A67AB for ; Wed, 6 Jan 2010 11:49:48 -0800 (PST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 06 Jan 2010 11:49:13 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.49,230,1262592000"; d="scan'208";a="761913520" Received: from rrsmsx604.amr.corp.intel.com ([10.31.0.170]) by fmsmga001.fm.intel.com with ESMTP; 06 Jan 2010 11:49:38 -0800 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx604.amr.corp.intel.com ([10.31.0.170]) with mapi; Wed, 6 Jan 2010 12:49:36 -0700 From: "Grewal, Ken" To: Stephen Kent Date: Wed, 6 Jan 2010 12:48:20 -0700 Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AcqO4Qq8U0jp5ABRSveZpSy2lL7dmgAJq99Q Message-ID: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 19:49:50 -0000 Steve,=20 The either-or on using an ICV or explicitly checking the WESP header on the= recipient was based on the assumption that the threat does not come from t= he sender and only from some other malicious entity after the packet has be= en sent.=20 This was the reason for simplifying the header check by using the ICV, inst= ead of explicitly checking every field.=20 If the sender is malicious, then an encrypted (covert) channel is all that = is needed to bypass any intermediate checking and furthermore, any explicit= checking of each WESP field on the recipient does not help, as the payload= can contain whatever is intended by the malicious sender! We did debate this a number of times and extending the integrity appears as= early as May of last year in version 3 of the draft (at version 12 now), s= o it should not have been a surprise at last call.=20 In either case, as Gabriel indicates in a separate email, if it makes sense= to go back to not integrity protecting the WESP header, I am fine with tha= t. This was the original position and aligns with your other email on WESP = acting as a wrapper to ESP, and should also address other comments indicati= ng that the name Wrapped ESP is a misnomer!=20 Thanks,=20 - Ken =20 >-----Original Message----- >From: Stephen Kent [mailto:kent@bbn.com] >Sent: Wednesday, January 06, 2010 6:28 AM >To: Grewal, Ken >Cc: Yaron Sheffer; ipsec@ietf.org >Subject: Re: [IPsec] Traffic visibility - consensus call > >At 11:14 AM -0700 1/5/10, Grewal, Ken wrote: >>Yes to both, based on arguments already discussed numerous times in >>the WG via presentations, 12 iterations of the draft and multiple WG >>last calls + AD reviews! >> >>The main motivation for extending the ICV was to counter some of the >>issues originally raised by Steve Kent - malicious entities >>modifying portions of the WESP header to bypass legitimate parsing >>of the packet by Trusted Intermediary (TI) devices such as >>IDS/IPS/etc. This can be addressed by the recipient explicitly >>validating the WESP header before accepting the packet or implicitly >>by including the WESP header as part of the ICV check. > >My recollection is that I identified a vulnerability that arose >because of the potential for a mismatch between what a TI checked and >what the receiver acted upon, irrespective of how that mismatch >arose. I think I suggested that this vulnerability might be remedied >by requiring the receiver to verify that the WESP header info was >consistent with what the receiver was acting upon, as part of WESP >processing. The current I-D calls for this check to be performed by >the recipient. Above you state that: > >"This can be addressed by the recipient explicitly validating the >WESP header before accepting the packet or implicitly by including >the WESP header as part of the ICV check." > >I disagree with the "or" in this sentence, for two reasons. First, >the I-D calls for the receiver to perform the consistency check, so >it's not an "or." Second, >it would not suffice to perform JUST the ICV check you described, >since that would not address the possibility that the sender created >the misleading WESP header. > >>The motivation for allowing WESP to be used for encrypted data was >>brought up as a consistency argument and also allows for future >>extensibility in a uniform manner. I agree that this was not part of >>the original charter, as shown in the earlier revisions of the WESP >>drafts. > >It appears that we agree that it was out of scope (although others do >not), and that the principle motivation cited was to allow for >extensions. The phrase :in a uniform manner" is, I believe, shorthand >for extensions that apply to encrypted traffic, right? > >>BUT, this was discussed numerous times within the WG (including an >>open ticket on scope) and it was agreed that this would be a useful >>bit to include in the flags, hence introduced in the latter >>revisions of the draft. > >I have already admitted that I lost track of this aspect of the >discussion, among all of the ticket items that the WG has processed. >(BTW, I congratulate Paul and Yaron for doing a very good job of >managing such a large number of issues in a detailed fashion. The >fact that I, and maybe a few other folks, lost track of the details >on one of the many items being worked is not a reflection on the >management style that have employed.) > >When I re-read the I-D during IETF last call, I was surprised to >learn that ESP processing had been changed, so cause the ICV to >cover non-ESP fields. This seems to be unnecessary and it is a bad >design, in my opinion. > >>Note that this does not mandate using WESP for encrypted traffic, >>but allows it as optional and can be dictated as part of the session >>setup based on local policy. Another benefit may be that in running >>mixed mode environments (encrypted + ESP_NULL traffic), it allows >>for an explicit distinction from the packet that certain traffic is >>encrypted and other traffic is not. Otherwise, one would use ESP and >>WESP in these mixed mode environments and to be absolutely sure if >>ESP traffic is encrypted or not, would need to fall back to >>heuristics, which somewhat defeats the object of having this spec. > >If local policy can be used to dictate whether WESP is or is not used >for encrypted traffic, then that policy also can dictate that ESP is >used only for encrypted traffic. Even in an environment where some >but not all hosts support WESP, I don't see the need for this flag. A >host that is WESP capable need not use WESP for encrypted traffic; it >can use ESP. if so, then ITs see three classes of traffic: > - encrypted using ESP > - integrity-protected using WESP > - integrity-protected using ESP > >The third class of traffic poses a problem for the ITs, but adding >the encrypted flag to WESP does not seem to address that problem. > >Steve From yaronf@checkpoint.com Wed Jan 6 11:54:46 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 660EC3A691E for ; Wed, 6 Jan 2010 11:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Kx4cpGEDDFD for ; Wed, 6 Jan 2010 11:54:37 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 8000228C144 for ; Wed, 6 Jan 2010 11:54:36 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o06JsTT7024930; Wed, 6 Jan 2010 21:54:29 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 6 Jan 2010 21:54:43 +0200 From: Yaron Sheffer To: Brian Swander , Stephen Kent Date: Wed, 6 Jan 2010 21:54:27 +0200 Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AQHKjv8+FMfT79gUNESgtZlfXT4hYpGI5nLQgAADIECAAAWGUIAABY4A Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C50A9@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C50A3@il-ex01.ad.checkpoint.com> <47FF8C26716A4E45993305F326EFE4A2018A7E@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <47FF8C26716A4E45993305F326EFE4A2018A7E@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C50A9ilex01adche_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Russ Housley , gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 19:54:46 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C50A9ilex01adche_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Brian, [No hat] If your intermediary is something like a load balancer, and you don't care = that some portion of your traffic is not balanced well, then fine - you don= 't need heuristics. But if the intermediary is a security device, then I would only buy one tha= t implemented heuristics, even if only on the "slow path". An intermediary = shouldn't rely on the entire network being tuned to its needs. Thanks, Yaron From: Brian Swander [mailto:briansw@microsoft.com] Sent: Wednesday, January 06, 2010 21:34 To: Yaron Sheffer; Stephen Kent Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro Subject: RE: [IPsec] Traffic visibility - consensus call I never meant to imply WESP would reduce encryption requirements. If the = customer traffic has to be encrypted, then it will be or the scenario isn't= satisfied. In the below, to meet that customer requirement, the custome= r would need to upgrade the machines that require encryption to the latest = version (in this proposal). However, all the other machines can remain unt= ouched. Yes we need to support all possible permutations in the product. I was tal= king about a specific scenario. If intermediaries have good heuristic sup= port, etc, then more permutations open up. But we can't assume intermedia= ries must implement heuristics. bs From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= aron Sheffer Sent: Wednesday, January 06, 2010 11:21 AM To: Brian Swander; Stephen Kent Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call Hi Brian, [no hat on] I think your reasoning about the different scenarios actually demonstrates = that "super-WESP" is useful. But I have to strongly disagree with the state= ment below. Yes we should support all possible permutations. There's no rea= son why WESP should suddenly cause traffic that used to require encryption = to not require it any more. So I would put it differently: the WESP encrypt flag is what enables interm= ediaries to be implemented *efficiently* in a mixed environment, with old a= nd new endpoints, encrypted and integrity-protected traffic. Thanks, Yaron From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of B= rian Swander Sent: Wednesday, January 06, 2010 21:07 To: Stephen Kent Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call Remember, the goal isn't necessarily to provide the full cross product of a= ll possible permutations, which is what you've done. The goal is to satisf= y the customer scenarios. Only if the customer really needs all the cross= product permutations, do they come into play. My argument is that a very good deployment strategy that will meet many cus= tomer scenarios is precisely to prune your matrix to make things determinis= tic to the intermediaries. In terms of your chart, that means that the only allowed combinations (of t= his scenario) are: Case Nodes Flow S 1 S 2 1 N-N I EN EN 3 W-W I W W 4 W-W E EE W* 5 W-N I EN EN Hence any (legitimate) ESP traffic that the intermediary sees must be ESP-N= ULL, and the encypt flag is critical, as it is the mechanism to enable encr= yption between uplevel machines. The main point of WESP is to remove heuristics from intermediary processing= . Hence we need to focus on the scenarios that actually allow us to do t= hat, and enable as many of them as possible. bs From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of S= tephen Kent Sent: Wednesday, January 06, 2010 10:37 AM To: Brian Swander Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call At 5:42 PM +0000 1/6/10, Brian Swander wrote: The uplevel machines can't use ESP to send the encrypted traffic in this sc= enario. Remember, that we need to look at the holistic scenario of how to = deploy this in an environment where we have legacy machines that don't do W= ESP. And we need to satisfy the goal of deterministic intermediary visibil= ity. Hence, the best method I see is what I describe below. The non-WESP machin= es MUST do ESP-NULL to allow visibility. That means uplevel machines canno= t use ESP to send encrypted, since otherwise intermediaries would see both = ESP-NULL, and ESP, and be forced back to heuristics. Intermediaries would= be configured (in this scenario) to assume that ESP always means ESP-NULL. bs Sorry, Brian, I still don't understand the scenario. Let's see if a detail= ed analysis can help. In a mixed environment, there are two classes of machines: WESP-capable and= not. That yields 3 types of connections, and 6 types of flows. Let's lab= el end systems (nodes) as W (for WESP-capable) and N (for not WESP-capable)= , and label traffic as I (integrity protected, but not encrypted) and E (fo= r encrypted). Finally, label the protocols as W (WESP), W* (WESP with the e= ncrypted content flag set), EE (ESP-encrypted) and EN (ESP-NULL). The foll= owing table shows the flows and protocols that could result in 2 scenarios:= Scenario 1 is WESP as originally proposed and Scenario 2 is with super-WES= P. Case Nodes Flow S 1 S 2 1 N-N I EN EN 2 N-N E EE EE 3 W-W I W W 4 W-W E EE W* 5 W-N I EN EN 6 W-N E EE EE The only place W* can be used is in case 4 (in Scenario 2), where both node= s are WESP-capable and the traffic is encrypted. But, in both scenarios, an= intermediate device will encounter ESP traffic that may or may not be encr= ypted, in cases 1, 2, 5, and 6. So, it appears to me that the intermediate = device needs to use heuristics until there are NO non-WESP nodes. At that t= ime, we are dealing only with cases 3 & 4. But, in either scenario, these t= wo cases present an intermediate device with unambiguous info for deciding = whether a packet can be inspected. This analysis suggests that there is no need for the flag when all nodes ar= e WESP-capable, and no benefit when there are a mix of WESP-capable and leg= acy nodes. Steve Scanned by Check Point Total Security Gateway. Scanned by Check Point Total Security Gateway. --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C50A9ilex01adche_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [IPsec] Traffic visibility - consensus call

Hi Brian,

 

[No hat]

 

If your intermediary is something like a load balancer, and = you don’t care that some portion of your traffic is not balanced well, th= en fine – you don’t need heuristics.

 

But if the intermediary is a security device, then I would o= nly buy one that implemented heuristics, even if only on the “slow path&#= 8221;. An intermediary shouldn’t rely on the entire network being tuned to its = needs.

 

Thanks,

          =       Yaron

 

From: Brian Swander [mailto:briansw@microsoft.com]
Sent: Wednesday, January 06, 2010 21:34
To: Yaron Sheffer; Stephen Kent
Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro
Subject: RE: [IPsec] Traffic visibility - consensus call<= /span>

 

I never meant to imply WESP would reduce encryption requirements.   If the customer traffic has to be encrypted, then= it will be or the scenario isn’t satisfied.    In the bel= ow, to meet that customer requirement, the customer would need to upgrade the mach= ines that require encryption to the latest version (in this proposal).  However, all the other machines can remain untouched.

 

Yes we need to support all possible permutations in the product.  I was talking about a specific scenario.   If intermediaries have good heuristic support, etc, then more permutations ope= n up.   But we can’t assume intermediaries must implement heu= ristics.

 

bs

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Yaron Sheffer
Sent: Wednesday, January 06, 2010 11:21 AM
To: Brian Swander; Stephen Kent
Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro
Subject: Re: [IPsec] Traffic visibility - consensus call<= /span>

 

Hi Brian,

 

[no hat on]

 

I think your reasoning about the different scenarios actuall= y demonstrates that “super-WESP” is useful. But I have to strongl= y disagree with the statement below. Yes we should support all possible permutations. There= ’s no reason why WESP should suddenly cause traffic that used to require encryption to not require it any more.

 

So I would put it differently: the WESP encrypt flag is what enables intermediaries to be implemented *efficiently* in a mixed environment, with old and new endpoints, encrypted and integrity-protected traffic.

 

Thanks,

          =       Yaron

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Brian Swander
Sent: Wednesday, January 06, 2010 21:07
To: Stephen Kent
Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro
Subject: Re: [IPsec] Traffic visibility - consensus call<= /span>

 

Remember, the goal isn’t necessarily to provide the fu= ll cross product of all possible permutations, which is what you’ve done. = ; The goal is to satisfy the customer scenarios.   Only if the customer real= ly needs all the cross product permutations, do they come into play.

 

My argument is that a very good deployment strategy that wil= l meet many customer scenarios is precisely to prune your matrix to make thin= gs deterministic to the intermediaries.    

 

In terms of your chart, that means that the only allowed combinations (of this scenario) are:

 

Case    Nodes   Flow    S 1     S 2

1       N-N     I       EN      EN
3     W-W     I       W      = W
4      W-W     E       EE      W* 5     W-N     I       EN      EN

 

Hence any (legitimate) ESP traffic that the intermediary see= s must be ESP-NULL, and the encypt flag is critical, as it is the mechanism t= o enable encryption between uplevel machines.

 

The main point of WESP is to remove heuristics from intermed= iary processing.    Hence we need to focus on the scenarios that actually allow us to do that, and enable as many of them as possible.<= /o:p>

 

bs

 

 

 

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Stephen Kent
Sent: Wednesday, January 06, 2010 10:37 AM
To: Brian Swander
Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro
Subject: Re: [IPsec] Traffic visibility - consensus call<= /span>

 

At 5:42 PM +0000 1/6/10, Brian Swander wrote:

The uplevel machines can't use ESP to send the encrypt= ed traffic in this scenario.  Remember, that we need to look at the holis= tic scenario of how to deploy this in an environment where we have legacy machi= nes that don't do WESP.  And we need to satisfy the goal of deterministic intermediary visibility.

Hence, the best method I see is what I describe below.  The non-WESP machines MUST do ESP-NULL to allow visibility.  That means uplevel machines cannot use ESP to send encrypted, since otherwise intermediaries w= ould see both ESP-NULL, and ESP, and be forced back to heuristics.   I= ntermediaries would be configured (in this scenario) to assume that ESP always means ESP-NULL.


bs

 

Sorry, Brian, I still don't understand the scenario.&n= bsp; Let's see if a detailed analysis can help.

 

In a mixed environment, there are two classes of machi= nes: WESP-capable and not.  That yields 3 types of connections, and 6 types of flows.&nb= sp; Let's label end systems (nodes) as W (for WESP-capable) and N (for not WESP-capable), and label traffic as I (integrity protected, but not encrypt= ed) and E (for encrypted). Finally, label the protocols as W (WESP), W* (WESP w= ith the encrypted content flag set), EE (ESP-encrypted) and EN (ESP-NULL). = ; The following table shows the flows and protocols that could result in 2 scenarios: Scenario 1 is WESP as originally proposed and Scenario 2 is with super-WESP.

 

Case    Nodes   Flow    S 1     S 2

1       N-N     I       EN      EN
2     N-N     E       EE      EE 3     W-W     I       W      = W
4      W-W     E       EE      W* 5     W-N     I       EN      EN

6       W-N     E       EE      EE

 

The only place W* can be used is in case 4 (in Scenari= o 2), where both nodes are WESP-capable and the traffic is encrypted. But, in bot= h scenarios, an intermediate device will encounter ESP traffic that may or ma= y not be encrypted, in cases 1, 2, 5, and 6. So, it appears to me that the intermediate device needs to use heuristics until there are NO non-WESP nod= es. At that time, we are dealing only with cases 3 & 4. But, in either scenario, these two cases present an intermediate device with unambiguous i= nfo for deciding whether a packet can be inspected.

 

This analysis suggests that there is no need for the f= lag when all nodes are WESP-capable, and no benefit when there are a mix of WESP-capable and legacy nodes.

 

Steve



Scanned by Check Point Total Security Gateway.



Scanned by Check Point Total Security Gateway.

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C50A9ilex01adche_-- From briansw@microsoft.com Wed Jan 6 11:56:42 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01F6928C153 for ; Wed, 6 Jan 2010 11:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64RfhbkfG+rF for ; Wed, 6 Jan 2010 11:56:41 -0800 (PST) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id DBD8828C144 for ; Wed, 6 Jan 2010 11:56:40 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 6 Jan 2010 11:56:40 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.0.639.20; Wed, 6 Jan 2010 11:55:47 -0800 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.27]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Wed, 6 Jan 2010 11:55:47 -0800 From: Brian Swander To: Stephen Kent Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AQHKjwjDFMfT79gUNESgtZlfXT4hYpGI9iDw Date: Wed, 6 Jan 2010 19:55:45 +0000 Message-ID: <47FF8C26716A4E45993305F326EFE4A2018D15@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_47FF8C26716A4E45993305F326EFE4A2018D15TK5EX14MBXW603win_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Russ Housley , gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 19:56:42 -0000 --_000_47FF8C26716A4E45993305F326EFE4A2018D15TK5EX14MBXW603win_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I trust my clarification (to Yaron) addressed these questions. Let me know= if there are any outstanding. bs From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of S= tephen Kent Sent: Wednesday, January 06, 2010 11:45 AM To: Brian Swander Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call At 7:06 PM +0000 1/6/10, Brian Swander wrote: Remember, the goal isn't necessarily to provide the full cross product of a= ll possible permutations, which is what you've done. The goal is to satisf= y the customer scenarios. Only if the customer really needs all the cross= product permutations, do they come into play. I don't recall the WG having agreed upon a subset of cases that were deemed= to be the only ones of interest. But, I admit to having missed some detail= s of WESP as it evolved too, so maybe I missed this too. Can you refresh my= memory on this point? My argument is that a very good deployment strategy that will meet many cu= stomer scenarios is precisely to prune your matrix to make things determini= stic to the intermediaries. This seems a lot like saying that we can convince customers that they need = only a subset of the possible cases because these are the ones that we can = address well! In terms of your chart, that means that the only allowed combinations (of = this scenario) are: Case Nodes Flow S 1 S 2 1 N-N I EN EN 3 W-W I W W 4 W-W E EE W* 5 W-N I EN EN I don't understand how one arrives at this subset. Why are legacy nodes pro= hibited form sending encrypted traffic in this context? Is the idea that th= is limitation will motivate deployment of WESP-enabled nodes? I don't think= the rationale here has been clearly articulated. Hence any (legitimate) ESP traffic that the intermediary sees must be ESP-= NULL, and the encypt flag is critical, as it is the mechanism to enable enc= ryption between uplevel machines. This seems to relate to my questions above. The main point of WESP is to remove heuristics from intermediary processing= . Hence we need to focus on the scenarios that actually allow us to do th= at, and enable as many of them as possible. I don't think it is reasonable to consider only those cases where the encry= pted content flag will make things better, unless we have a very good, and = agreed-upon, rationale for discarding the other cases. Steve --_000_47FF8C26716A4E45993305F326EFE4A2018D15TK5EX14MBXW603win_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [IPsec] Traffic visibility - consensus call

I trust my clarification (to Yaron) addressed these question= s.  Let me know if there are any outstanding.

 

bs

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Stephen Kent
Sent: Wednesday, January 06, 2010 11:45 AM
To: Brian Swander
Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro
Subject: Re: [IPsec] Traffic visibility - consensus call<= /span>

 

At 7:06 PM +0000 1/6/10, Brian Swander wrote:

Remember, the goal isn't necessarily to provide the fu= ll cross product of all possible permutations, which is what you've done. = ; The goal is to satisfy the customer scenarios.   Only if the cust= omer really needs all the cross product permutations, do they come into play.

 

I don't recall the WG having agreed upon a subset of c= ases that were deemed to be the only ones of interest. But, I admit to having mi= ssed some details of WESP as it evolved too, so maybe I missed this too. Can you refresh my memory on this point?

 

 My argument is that a very good deployment strat= egy that will meet many customer scenarios is precisely to prune your matrix to make things deterministic to the intermediaries.  

 

This seems a lot like saying that we can convince cust= omers that they need only a subset of the possible cases because these are the on= es that we can address well!

 

 In terms of your chart, that means that the only allowed combinations (of this scenario) are:

 

Case    Nodes   Flow    S 1     S 2

1       N-N     I       EN      EN
3     W-W     I       W      = W
4      W-W     E       EE      W* 5     W-N     I       EN      EN

 

I don't understand how one arrives at this subset. Why= are legacy nodes prohibited form sending encrypted traffic in this context? Is = the idea that this limitation will motivate deployment of WESP-enabled nodes? I don't think the rationale here has been clearly articulated.

 

 Hence any (legitimate) ESP traffic that the intermediary sees must be ESP-NULL, and the encypt flag is critical, as it = is the mechanism to enable encryption between uplevel machines.

 

This seems to relate to my questions above.=

 

The main point of WESP is to remove heuristics from intermediary processing.   Hence we need to focus on the scenario= s that actually allow us to do that, and enable as many of them as possible.<= o:p>

 

I don't think it is reasonable to consider only those = cases where the encrypted content flag will make things better, unless we have a very g= ood, and agreed-upon, rationale for discarding the other cases.

 

Steve

--_000_47FF8C26716A4E45993305F326EFE4A2018D15TK5EX14MBXW603win_-- From briansw@microsoft.com Wed Jan 6 12:03:04 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CE8C28C0F0 for ; Wed, 6 Jan 2010 12:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Co3wfmRaA2CB for ; Wed, 6 Jan 2010 12:02:54 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 23FD228C108 for ; Wed, 6 Jan 2010 12:02:54 -0800 (PST) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 6 Jan 2010 12:03:32 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.0.639.20; Wed, 6 Jan 2010 12:02:52 -0800 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.27]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Wed, 6 Jan 2010 12:02:54 -0800 From: Brian Swander To: Yaron Sheffer , Stephen Kent Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AQHKjv8+FMfT79gUNESgtZlfXT4hYpGI5nLQgAADIECAAAWGUIAABY4AgAACYtA= Date: Wed, 6 Jan 2010 20:02:52 +0000 Message-ID: <47FF8C26716A4E45993305F326EFE4A2018D59@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C50A3@il-ex01.ad.checkpoint.com> <47FF8C26716A4E45993305F326EFE4A2018A7E@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C50A9@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C50A9@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_47FF8C26716A4E45993305F326EFE4A2018D59TK5EX14MBXW603win_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Russ Housley , gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 20:03:04 -0000 --_000_47FF8C26716A4E45993305F326EFE4A2018D59TK5EX14MBXW603win_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That's a cost/benefit business decision for the intermediary. Some inter= mediaries may welcome the option to not support heuristics at all. They'll= need to do the market research, etc on the various scenarios. But it is my goal to understand exactly what scenarios require heuristics, = and enable as many as possible that don't require them. We've had overwhe= lming support on the list here from intermediary vendors saying heuristics = are hard/bad etc. (Note, I'm not maligning heuristics. If they are prese= nt in the infrastructure, then ideally the scenarios can leverage them, too= ). bs From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= aron Sheffer Sent: Wednesday, January 06, 2010 11:54 AM To: Brian Swander; Stephen Kent Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call Hi Brian, [No hat] If your intermediary is something like a load balancer, and you don't care = that some portion of your traffic is not balanced well, then fine - you don= 't need heuristics. But if the intermediary is a security device, then I would only buy one tha= t implemented heuristics, even if only on the "slow path". An intermediary = shouldn't rely on the entire network being tuned to its needs. Thanks, Yaron From: Brian Swander [mailto:briansw@microsoft.com] Sent: Wednesday, January 06, 2010 21:34 To: Yaron Sheffer; Stephen Kent Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro Subject: RE: [IPsec] Traffic visibility - consensus call I never meant to imply WESP would reduce encryption requirements. If the = customer traffic has to be encrypted, then it will be or the scenario isn't= satisfied. In the below, to meet that customer requirement, the custome= r would need to upgrade the machines that require encryption to the latest = version (in this proposal). However, all the other machines can remain unt= ouched. Yes we need to support all possible permutations in the product. I was tal= king about a specific scenario. If intermediaries have good heuristic sup= port, etc, then more permutations open up. But we can't assume intermedia= ries must implement heuristics. bs From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= aron Sheffer Sent: Wednesday, January 06, 2010 11:21 AM To: Brian Swander; Stephen Kent Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call Hi Brian, [no hat on] I think your reasoning about the different scenarios actually demonstrates = that "super-WESP" is useful. But I have to strongly disagree with the state= ment below. Yes we should support all possible permutations. There's no rea= son why WESP should suddenly cause traffic that used to require encryption = to not require it any more. So I would put it differently: the WESP encrypt flag is what enables interm= ediaries to be implemented *efficiently* in a mixed environment, with old a= nd new endpoints, encrypted and integrity-protected traffic. Thanks, Yaron From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of B= rian Swander Sent: Wednesday, January 06, 2010 21:07 To: Stephen Kent Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call Remember, the goal isn't necessarily to provide the full cross product of a= ll possible permutations, which is what you've done. The goal is to satisf= y the customer scenarios. Only if the customer really needs all the cross= product permutations, do they come into play. My argument is that a very good deployment strategy that will meet many cus= tomer scenarios is precisely to prune your matrix to make things determinis= tic to the intermediaries. In terms of your chart, that means that the only allowed combinations (of t= his scenario) are: Case Nodes Flow S 1 S 2 1 N-N I EN EN 3 W-W I W W 4 W-W E EE W* 5 W-N I EN EN Hence any (legitimate) ESP traffic that the intermediary sees must be ESP-N= ULL, and the encypt flag is critical, as it is the mechanism to enable encr= yption between uplevel machines. The main point of WESP is to remove heuristics from intermediary processing= . Hence we need to focus on the scenarios that actually allow us to do t= hat, and enable as many of them as possible. bs From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of S= tephen Kent Sent: Wednesday, January 06, 2010 10:37 AM To: Brian Swander Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call At 5:42 PM +0000 1/6/10, Brian Swander wrote: The uplevel machines can't use ESP to send the encrypted traffic in this sc= enario. Remember, that we need to look at the holistic scenario of how to = deploy this in an environment where we have legacy machines that don't do W= ESP. And we need to satisfy the goal of deterministic intermediary visibil= ity. Hence, the best method I see is what I describe below. The non-WESP machin= es MUST do ESP-NULL to allow visibility. That means uplevel machines canno= t use ESP to send encrypted, since otherwise intermediaries would see both = ESP-NULL, and ESP, and be forced back to heuristics. Intermediaries would= be configured (in this scenario) to assume that ESP always means ESP-NULL. bs Sorry, Brian, I still don't understand the scenario. Let's see if a detail= ed analysis can help. In a mixed environment, there are two classes of machines: WESP-capable and= not. That yields 3 types of connections, and 6 types of flows. Let's lab= el end systems (nodes) as W (for WESP-capable) and N (for not WESP-capable)= , and label traffic as I (integrity protected, but not encrypted) and E (fo= r encrypted). Finally, label the protocols as W (WESP), W* (WESP with the e= ncrypted content flag set), EE (ESP-encrypted) and EN (ESP-NULL). The foll= owing table shows the flows and protocols that could result in 2 scenarios:= Scenario 1 is WESP as originally proposed and Scenario 2 is with super-WES= P. Case Nodes Flow S 1 S 2 1 N-N I EN EN 2 N-N E EE EE 3 W-W I W W 4 W-W E EE W* 5 W-N I EN EN 6 W-N E EE EE The only place W* can be used is in case 4 (in Scenario 2), where both node= s are WESP-capable and the traffic is encrypted. But, in both scenarios, an= intermediate device will encounter ESP traffic that may or may not be encr= ypted, in cases 1, 2, 5, and 6. So, it appears to me that the intermediate = device needs to use heuristics until there are NO non-WESP nodes. At that t= ime, we are dealing only with cases 3 & 4. But, in either scenario, these t= wo cases present an intermediate device with unambiguous info for deciding = whether a packet can be inspected. This analysis suggests that there is no need for the flag when all nodes ar= e WESP-capable, and no benefit when there are a mix of WESP-capable and leg= acy nodes. Steve Scanned by Check Point Total Security Gateway. Scanned by Check Point Total Security Gateway. --_000_47FF8C26716A4E45993305F326EFE4A2018D59TK5EX14MBXW603win_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [IPsec] Traffic visibility - consensus call

That’s a cost/benefit business decision for the intermediary.    Some intermediaries may welcome the option = to not support heuristics at all.  They’ll need to do the market research, etc on the various scenarios.  

 

But it is my goal to understand exactly what scenarios requi= re heuristics, and enable as many as possible that don’t require them.&n= bsp;  We’ve had overwhelming support on the list here from intermedia= ry vendors saying heuristics are hard/bad etc.   (Note, I’m no= t maligning heuristics.  If they are present in the infrastructure, then ideally the scenarios can leverage them, too).

 

 

bs

 

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Yaron Sheffer
Sent: Wednesday, January 06, 2010 11:54 AM
To: Brian Swander; Stephen Kent
Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro
Subject: Re: [IPsec] Traffic visibility - consensus call<= /span>

 

Hi Brian,

 

[No hat]

 

If your intermediary is something like a load balancer, and = you don’t care that some portion of your traffic is not balanced well, th= en fine – you don’t need heuristics.

 

But if the intermediary is a security device, then I would o= nly buy one that implemented heuristics, even if only on the “slow path”. An intermediary shouldn’t rely on the entire network bei= ng tuned to its needs.

 

Thanks,

          =       Yaron

 

From: Brian Swander [mailto:briansw@microsoft.com]
Sent: Wednesday, January 06, 2010 21:34
To: Yaron Sheffer; Stephen Kent
Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro
Subject: RE: [IPsec] Traffic visibility - consensus call<= /span>

 

I never meant to imply WESP would reduce encryption requirements.   If the customer traffic has to be encrypted, then= it will be or the scenario isn’t satisfied.    In the bel= ow, to meet that customer requirement, the customer would need to upgrade the m= achines that require encryption to the latest version (in this proposal).  However, all the other machines can remain untouched.

 

Yes we need to support all possible permutations in the product.  I was talking about a specific scenario.   If intermediaries have good heuristic support, etc, then more permutations ope= n up.   But we can’t assume intermediaries must implement heuristics.

 

bs

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Yaron Sheffer
Sent: Wednesday, January 06, 2010 11:21 AM
To: Brian Swander; Stephen Kent
Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro
Subject: Re: [IPsec] Traffic visibility - consensus call<= /span>

 

Hi Brian,

 

[no hat on]

 

I think your reasoning about the different scenarios actuall= y demonstrates that “super-WESP” is useful. But I have to strongl= y disagree with the statement below. Yes we should support all possible permutations. There’s no reason why WESP should suddenly cause traffi= c that used to require encryption to not require it any more.

 

So I would put it differently: the WESP encrypt flag is what enables intermediaries to be implemented *efficiently* in a mixed environment, with old and new endpoints, encrypted and integrity-protected traffic.

 

Thanks,

          =       Yaron

 

From: ipsec-bounces= @ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Brian Swander
Sent: Wednesday, January 06, 2010 21:07
To: Stephen Kent
Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro
Subject: Re: [IPsec] Traffic visibility - consensus call<= /span>

 

Remember, the goal isn’t necessarily to provide the fu= ll cross product of all possible permutations, which is what you’ve done.  The goal is to satisfy the customer scenarios.   Only= if the customer really needs all the cross product permutations, do they come = into play.

 

My argument is that a very good deployment strategy that wil= l meet many customer scenarios is precisely to prune your matrix to make thin= gs deterministic to the intermediaries.    

 

In terms of your chart, that means that the only allowed com= binations (of this scenario) are:

 

Case    Nodes   Flow    S 1     S 2

1       N-N     I       EN      EN
3     W-W     I       W      = W
4      W-W     E       EE      W* 5     W-N     I       EN      EN

 

Hence any (legitimate) ESP traffic that the intermediary see= s must be ESP-NULL, and the encypt flag is critical, as it is the mechanism t= o enable encryption between uplevel machines.

 

The main point of WESP is to remove heuristics from intermed= iary processing.    Hence we need to focus on the scenarios that = actually allow us to do that, and enable as many of them as possible.

 

bs

 

 

 

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Stephen Kent
Sent: Wednesday, January 06, 2010 10:37 AM
To: Brian Swander
Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro
Subject: Re: [IPsec] Traffic visibility - consensus call<= /span>

 

At 5:42 PM +0000 1/6/10, Brian Swander wrote:

The uplevel machines can't use ESP to send the encrypt= ed traffic in this scenario.  Remember, that we need to look at the holis= tic scenario of how to deploy this in an environment where we have legacy machi= nes that don't do WESP.  And we need to satisfy the goal of deterministic intermediary visibility.

Hence, the best method I see is what I describe below.  The non-WESP machines MUST do ESP-NULL to allow visibility.  That means uplevel machines cannot use ESP to send encrypted, since otherwise intermediaries w= ould see both ESP-NULL, and ESP, and be forced back to heuristics.   Intermediaries would be configured (in this scenario) to assume that ESP al= ways means ESP-NULL.


bs

 

Sorry, Brian, I still don't understand the scenario.&n= bsp; Let's see if a detailed analysis can help.

 

In a mixed environment, there are two classes of machi= nes: WESP-capable and not.  That yields 3 types of connections, and 6 types= of flows.  Let's label end systems (nodes) as W (for WESP-capable) and N = (for not WESP-capable), and label traffic as I (integrity protected, but not encrypted) and E (for encrypted). Finally, label the protocols as W (WESP),= W* (WESP with the encrypted content flag set), EE (ESP-encrypted) and EN (ESP-NULL).  The following table shows the flows and protocols that co= uld result in 2 scenarios: Scenario 1 is WESP as originally proposed and Scenar= io 2 is with super-WESP.

 

Case    Nodes   Flow    S 1     S 2

1       N-N     I       EN      EN
2     N-N     E       EE      EE 3     W-W     I       W      = W
4      W-W     E       EE      W* 5     W-N     I       EN      EN

6       W-N     E       EE      EE

 

The only place W* can be used is in case 4 (in Scenari= o 2), where both nodes are WESP-capable and the traffic is encrypted. But, in bot= h scenarios, an intermediate device will encounter ESP traffic that may or ma= y not be encrypted, in cases 1, 2, 5, and 6. So, it appears to me that the intermediate device needs to use heuristics until there are NO non-WESP nod= es. At that time, we are dealing only with cases 3 & 4. But, in either scen= ario, these two cases present an intermediate device with unambiguous info for deciding whether a packet can be inspected.

 

This analysis suggests that there is no need for the f= lag when all nodes are WESP-capable, and no benefit when there are a mix of WES= P-capable and legacy nodes.

 

Steve



Scanned by Check Point Total Security Gateway.



Scanned by Check Point Total Security Gateway.

--_000_47FF8C26716A4E45993305F326EFE4A2018D59TK5EX14MBXW603win_-- From kent@bbn.com Wed Jan 6 12:19:12 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1C923A68F7 for ; Wed, 6 Jan 2010 12:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t81t4Ir5qaTp for ; Wed, 6 Jan 2010 12:19:11 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 725F03A6778 for ; Wed, 6 Jan 2010 12:19:11 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.5]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NScLU-0000lB-Ah; Wed, 06 Jan 2010 15:19:08 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C50A5@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C50A5@il-ex01.ad.checkpoint.com> Date: Wed, 6 Jan 2010 15:19:04 -0500 To: Yaron Sheffer From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-949313348==_ma============" Cc: "ipsec@ietf.org" , Russ Housley , gabriel montenegro , Brian Swander Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 20:19:12 -0000 --============_-949313348==_ma============ Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable At 9:34 PM +0200 1/6/10, Yaron Sheffer wrote: >Hi Steve, > >[No hat.] > >Thanks for the analysis, I hope this'll help the discussion to converge. > >You are taking an either-or approach in the last=20 >paragraph below. But assuming that WESP is=20 >useful (bear with me=8A), there will be a gradual=20 >deployment within any given network. I agree=20 >that heuristics will still be needed, until the=20 >last endpoint is WESP-enabled (i.e., forever).=20 >But if we adopt W*, during the migration less=20 >and less heuristic processing will be needed.=20 >Much of this discussion is about performance, so=20 >quantitative arguments are also useful. > >Thanks, > Yaron > Yaron, So, is the argument that use of W* would reduce=20 the quantity of traffic that requires heuristic=20 processing at some stages in the deployment=20 process, because as the number of WESP-capable=20 nodes increases, cases 3 & 4 predominate? if this=20 is the argument, why did it take this long to get=20 a clear articulation of the argument (and why was=20 I the one who had to do the analysis to support=20 it :-))? That argument makes sense, but only in the=20 context of other assumptions about deployment=20 (which have yet to be articulated). =46or example, if an enterprise deploys an=20 intermediate system that can perform packet=20 inspection on IPsec traffic before most of the=20 nodes are WESP-capable, then that system will=20 have to use heuristics to deal with the vast=20 majority of traffic initially. Such a system=20 could continue to use those heuristics until=20 WESP-deployment is complete. So that scenario=20 does not motivate use of W*. However, if the traffic load grows a lot during=20 deployment, it might exceed the capacity of the=20 intermediate system before WESP deployment was=20 complete. In that case use of W* would help, if=20 encrypted traffic were a lot more common than=20 integrity-protected traffic. Or, one might argue that use of W* would allow=20 deployment of an intermediate system that uses=20 WESP, but still incorporates heuristic support,=20 at an earlier stage in WESP-deployment, though=20 not initially. Of course the (earlier) point at=20 which such deployment could take place is very=20 context-specific. These could be reasonable arguments, but I've not=20 seen them articulated clearly. Nor have I seen=20 any rough estimates of ratios of traffic types=20 and the processing burden of heuristics to=20 provide some quantitative basis for arguments of=20 this sort. So, I think the WG needs to do more=20 homework on this if we're going to make such=20 arguments. Steve --============_-949313348==_ma============ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [IPsec] Traffic visibility - consensus call
At 9:34 PM +0200 1/6/10, Yaron Sheffer wrote:
Hi Steve,
 
[No hat.]
 
Thanks for the analysis, I hope this'll help the discussion to converge.
 
You are taking an either-or approach in the last paragraph below. But assuming that WESP is useful (bear with me=8A), there will be a gradual deployment within any given network. I agree that heuristics will still be needed, until the last endpoint is WESP-enabled (i.e., forever). But if we adopt W*, during the migration less and less heuristic processing will be needed. Much of this discussion is about performance, so quantitative arguments are also useful.
 
Thanks,
                Yaron
 

Yaron,

So, is the argument that use of W* would reduce the quantity of traffic that requires heuristic processing at some stages in the deployment process, because as the number of WESP-capable nodes increases, cases 3 & 4 predominate? if this is the argument, why did it take this long to get a clear articulation of the argument (and why was I the one who had to do the analysis to support it :-))?

That argument makes sense, but only in the context of other assumptions about deployment (which have yet to be articulated).

For example, if an enterprise deploys an intermediate system that can perform packet inspection on IPsec traffic before most of the nodes are WESP-capable, then that system will have to use heuristics to deal with the vast majority of traffic initially. Such a system could continue to use those heuristics until WESP-deployment is complete. So that scenario does not motivate use of W*.

However, if the traffic load grows a lot during deployment, it might exceed the capacity of the intermediate system before WESP deployment was complete. In that case use of W* would help, if encrypted traffic were a lot more common than integrity-protected traffic.

Or, one might argue that use of W* would allow deployment of an intermediate system that uses WESP, but still incorporates heuristic support, at an earlier stage in WESP-deployment, though not initially. Of course the (earlier) point at which such deployment could take place is very context-specific.

These could be reasonable arguments, but I've not seen them articulated clearly. Nor have I seen any rough estimates of ratios of traffic types and the processing burden of heuristics to provide some quantitative basis for arguments of this sort.  So, I think the WG needs to do more homework on this if we're going to make such arguments.

Steve

--============_-949313348==_ma============-- From kent@bbn.com Wed Jan 6 13:06:01 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B53E3A6890 for ; Wed, 6 Jan 2010 13:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6uOQVYkO7sa for ; Wed, 6 Jan 2010 13:06:00 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 329E13A685B for ; Wed, 6 Jan 2010 13:06:00 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.5]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NSd4m-0001px-9u; Wed, 06 Jan 2010 16:05:56 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> Date: Wed, 6 Jan 2010 15:40:07 -0500 To: "Grewal, Ken" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 21:06:01 -0000 At 12:48 PM -0700 1/6/10, Grewal, Ken wrote: >Steve, >The either-or on using an ICV or explicitly checking the WESP header >on the recipient was based on the assumption that the threat does >not come from the sender and only from some other malicious entity >after the packet has been sent. >This was the reason for simplifying the header check by using the >ICV, instead of explicitly checking every field. You cited my comments about a vulnerability as the rationale for pursuing this design. I noted that my comments did not specify the source of the mismatch between header data that IPsec acts upon (for access control) vs. what WESP caused an intermediate system to examine. You chose to focus on one possible source of manipulation, i.e., a MITM attack. That's fine, but it does not necessitate changing the ESP ICV computation, i.e., checking by the recipient suffices. Also, the I-D calls for consistency checking, so I was (justifiably) confused by the either-or statement you made. >If the sender is malicious, then an encrypted (covert) channel is >all that is needed to bypass any intermediate checking and >furthermore, any explicit checking of each WESP field on the >recipient does not help, as the payload can contain whatever is >intended by the malicious sender! I see we have a miscommunication about the nature of the vulnerability that I cited. It is what I noted above, i.e., "a mismatch between header data that IPsec acts upon (for access control) vs. what WESP caused an intermediate system to examine." This is an old security concern, dating from the mid/late 1970s, when it was discovered that one could make a call to an OS with one set of parameters, and then change the parameters after an access control check was performed but before the OS acted upon the call. The fix for this sort of attavck was to copy the parameters into OS-controlled address space, out of user-space. An encrypted covert channel was not what motivated my comments, because IPsec makes its access control decisions based on the 5-tuples from the IP and transport layer headers. >We did debate this a number of times and extending the integrity >appears as early as May of last year in version 3 of the draft (at >version 12 now), so it should not have been a surprise at last call. I have already apologized for not closely tracking the changes to WESP. However, during IETF last call everyone is free to raise questions of this sort, so we ought not devote too much time and energy to this aspect of the discussion. >In either case, as Gabriel indicates in a separate email, if it >makes sense to go back to not integrity protecting the WESP header, >I am fine with that. This was the original position and aligns with >your other email on WESP acting as a wrapper to ESP, and should also >address other comments indicating that the name Wrapped ESP is a >misnomer! That works for me too, but I would feel better if we were all in agreement about the nature of the vulnerability that I cited, which motivated this in the first place. Steve From kent@bbn.com Wed Jan 6 13:31:25 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A65F3A68CF for ; Wed, 6 Jan 2010 13:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znGLXlEISkiL for ; Wed, 6 Jan 2010 13:31:24 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 49F583A685B for ; Wed, 6 Jan 2010 13:31:24 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.5]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NSd4o-0001px-Ct for ipsec@ietf.org; Wed, 06 Jan 2010 16:05:59 -0500 Mime-Version: 1.0 Message-Id: Date: Wed, 6 Jan 2010 16:05:52 -0500 To: ipsec@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [IPsec] this discussion X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 21:31:25 -0000 Folks, The flurry of messages that have been exchanged today and yesterday have often struck me as incorporating rather vague arguments. I find myself having to do a lot of work to fill in the blanks for not well-articulated comments, construct detailed analyses, and postulate rationales for the arguments made by others. I think everyone ought to spend more time composing messages that are clear and persuasive, so as to not unduly consume the time of others. Steve From kent@bbn.com Wed Jan 6 13:31:25 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9A583A6915 for ; Wed, 6 Jan 2010 13:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0cdSmujAySe for ; Wed, 6 Jan 2010 13:31:25 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 173F23A685B for ; Wed, 6 Jan 2010 13:31:25 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.5]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NSd4o-0001px-BC; Wed, 06 Jan 2010 16:05:58 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <47FF8C26716A4E45993305F326EFE4A2018D15@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018D15@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> Date: Wed, 6 Jan 2010 16:01:21 -0500 To: Brian Swander From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" , Russ Housley , gabriel montenegro , Stephen Kent Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 21:31:26 -0000 At 7:55 PM +0000 1/6/10, Brian Swander wrote: >I trust my clarification (to Yaron) addressed these questions. Let >me know if there are any outstanding. > I understood the first two lines about lots of legacy systems, only a few of which need to perform encryption." The next two lines were too terse for me: "Routing infrastructure that doesn't do heuristics Requires intermediaries that can do full ESP-NULL parsing" if the intermediaries are part of the routing infrastructure, why use different terms in these two lines? Also within an enterprise context, one might well be able to configure the intermediaries with the addresses of the few machines that perform encryption, and which therefore are allowed to communicate with one another w/o benefit of packet inspection. So I would not say that your response addresses my questions in the lager context. Steve From Paul_Koning@Dell.com Wed Jan 6 13:44:08 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 134AA3A687B for ; Wed, 6 Jan 2010 13:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIYb+A4BeOQA for ; Wed, 6 Jan 2010 13:44:07 -0800 (PST) Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com [143.166.224.254]) by core3.amsl.com (Postfix) with ESMTP id 1633C3A682B for ; Wed, 6 Jan 2010 13:44:06 -0800 (PST) X-Loopcount0: from 12.110.134.31 X-IronPort-AV: E=Sophos;i="4.49,231,1262584800"; d="scan'208";a="429059467" Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkps320.us.dell.com with SMTP; 06 Jan 2010 15:44:05 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Jan 2010 16:43:06 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Traffic visibility - consensus call thread-index: AcqPF6PxvYYNmV7GQIGw93hGwMEvNQAAIiEQ References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com><7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com><378834.93787.qm@web82602.mail.mud.yahoo.com><4B43AAF7.8030302@vigilsec.com><734514.64270.qm@web82604.mail.mud.yahoo.com><5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018D15@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> From: "Paul Koning" To: "Stephen Kent" Cc: ipsec@ietf.org Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 21:44:08 -0000 I've been watching a long stream of messages about WESP flying by and I must admit to being rather confused. What follows is based on my best understanding of what's going on, so please apply grains of salt as needed.=20 It's likely that I'm in the same corner as Tero.=20 It sounds to me like WESP was chartered to do something very specific, having to do with ESP-NULL and intermediate systems looking at traffic. And now we have discussions about ESP-nonNULL with WESP, and maybe WESP as an alternative to ESP, or a replacement to ESP. How is this possible? It's nice to talk about the benefits of greater generality and all that, but it isn't proper to have a WG chartered to do a narrow thing and then end up doing something much bigger. =20 Why not? Answer: the purpose of a charter is (a) to tell the WG what it should be doing, (b) to tell observers whether the work of the WG is something they need to track -- or do NOT need to track. If a WG goes well outside its charter, that's not fair to those who would have participated if the charter had said this, but ended up not participating because the charter told them they did not need to. From what I understand from Tero's comments, that situation applies to him, and I think it applies to me as well. It may well be a good idea to expand or modify or generalize or replace ESP, but if such a project is to be done, it should be done by a WG chartered for that purpose, so that all interested parties are on notice that this work is about to happen. Meanwhile, as to the consensus call: if this is out of charter as it appears to be, then, independent of its technical merit, my vote is NO. paul koning From sommerfeld@sun.com Wed Jan 6 14:08:43 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7E963A685D for ; Wed, 6 Jan 2010 14:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMH20bb6UAah for ; Wed, 6 Jan 2010 14:08:42 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id C9F8F3A685B for ; Wed, 6 Jan 2010 14:08:42 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o06M8bf4015900; Wed, 6 Jan 2010 22:08:37 GMT Received: from thunk-west.local (dhcp-umpk17-109-232.SFBay.Sun.COM [129.146.109.232]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o06M8bjt014762; Wed, 6 Jan 2010 14:08:37 -0800 (PST) Received: from thunk-west.local (thunk-west [127.0.0.1]) by thunk-west.local (8.14.3+Sun/8.14.3) with ESMTP id o06M8baj017441; Wed, 6 Jan 2010 14:08:37 -0800 (PST) Received: (from sommerfeld@localhost) by thunk-west.local (8.14.3+Sun/8.14.3/Submit) id o06M8a1j017440; Wed, 6 Jan 2010 14:08:36 -0800 (PST) X-Authentication-Warning: thunk-west.local: sommerfeld set sender to sommerfeld@sun.com using -f From: Bill Sommerfeld To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset="ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 06 Jan 2010 14:08:36 -0800 Message-ID: <1262815716.17434.1.camel@thunk-west> Mime-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 22:08:43 -0000 On Tue, 2010-01-05 at 00:27 +0200, Yaron Sheffer wrote: > - The current draft > (http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11) > defines the ESP trailer's ICV calculation to include the WESP header. > This has been done to counter certain attacks, but it means that WESP > is no longer a simple wrapper around ESP - ESP itself is modified. Do > you support this design decision? no. > - The current draft allows WESP to be applied to encrypted ESP flows, > in addition to the originally specified ESP-null. This was intended so > that encrypted flows can benefit from the future extensibility offered > by WESP. But arguably, it positions WESP as an alternative to ESP. Do > you support this design decision? no. From briansw@microsoft.com Wed Jan 6 14:18:04 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6B9A28C0E7 for ; Wed, 6 Jan 2010 14:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MuPLM+g-pOrE for ; Wed, 6 Jan 2010 14:18:03 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id F2D473A68D6 for ; Wed, 6 Jan 2010 14:18:02 -0800 (PST) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 6 Jan 2010 14:18:41 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.0.639.20; Wed, 6 Jan 2010 14:17:39 -0800 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.27]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Wed, 6 Jan 2010 14:17:40 -0800 From: Brian Swander To: Stephen Kent Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AQHKjwjDFMfT79gUNESgtZlfXT4hYpGJDETfgAAP7CA= Date: Wed, 6 Jan 2010 22:17:34 +0000 Message-ID: <47FF8C26716A4E45993305F326EFE4A20191D9@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018D15@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Russ Housley , gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 22:18:04 -0000 I trust that this is a question on the sample set of requirements for the s= cenario I sent to Paul. I use infrastructure and intermediaries terms interchangeably. The scenario I had in mind is: No heuristic support from any network infrastructure. Only limited number of legacy clients that require encryption, hence they a= re capable of upgrading. Vast majority of legacy are ok with ESP-NULL. Potentially many uplevel clients that require encryption. As on the previ= ous thread, we want to enable as many capabilities in the cross product mat= rix as possible. Hence it is extremely desirable for uplevel to do encrypt= ion or integrity without forcing extra infrastructure config. I.e. I'd as= sume that managing ip addresses on all uplevel machines that want to do enc= ryption is prohibitive. bs -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Wednesday, January 06, 2010 1:01 PM To: Brian Swander Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro; Stephen Kent Subject: RE: [IPsec] Traffic visibility - consensus call At 7:55 PM +0000 1/6/10, Brian Swander wrote: >I trust my clarification (to Yaron) addressed these questions. Let=20 >me know if there are any outstanding. > I understood the first two lines about lots of legacy systems, only a=20 few of which need to perform encryption." The next two lines were too=20 terse for me: "Routing infrastructure that doesn't do heuristics Requires intermediaries that can do full ESP-NULL parsing" if the intermediaries are part of the routing infrastructure, why use=20 different terms in these two lines? Also within an enterprise context, one might well be able to=20 configure the intermediaries with the addresses of the few machines=20 that perform encryption, and which therefore are allowed to=20 communicate with one another w/o benefit of packet inspection. So I would not say that your response addresses my questions in the=20 lager context. Steve From ken.grewal@intel.com Wed Jan 6 14:43:40 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FEFB3A6889 for ; Wed, 6 Jan 2010 14:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaP-0pE7D10l for ; Wed, 6 Jan 2010 14:43:29 -0800 (PST) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by core3.amsl.com (Postfix) with ESMTP id 009FA3A68CD for ; Wed, 6 Jan 2010 14:43:28 -0800 (PST) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 06 Jan 2010 14:43:27 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.47,316,1257148800"; d="scan'208";a="229980269" Received: from rrsmsx604.amr.corp.intel.com ([10.31.0.170]) by azsmga001.ch.intel.com with ESMTP; 06 Jan 2010 14:43:27 -0800 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx604.amr.corp.intel.com ([10.31.0.170]) with mapi; Wed, 6 Jan 2010 15:43:27 -0700 From: "Grewal, Ken" To: Paul Koning , Stephen Kent Date: Wed, 6 Jan 2010 15:42:09 -0700 Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AcqPF6PxvYYNmV7GQIGw93hGwMEvNQAAIiEQAACqaYA= Message-ID: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com><7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com><378834.93787.qm@web82602.mail.mud.yahoo.com><4B43AAF7.8030302@vigilsec.com><734514.64270.qm@web82604.mail.mud.yahoo.com><5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018D15@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 22:43:40 -0000 Paul,=20 My 2 cents... Some people have jumped to conclusions that because we want to differentiat= e between encrypted and non-encrypted traffic by explicitly signaling in th= e packet, that WESP is now a replacement for ESP. THIS IS NOT THE CASE AND IT WAS NEVER THE INTENT!=20 One item that may have led to this conclusion was the expanded ICV over WES= P, but this was introduced as a mitigation for certain threats highlighted = in the WG. Subsequent discussions have determined that it would be better t= o mitigate these treats in an alternative manner, so we can fall back to WE= SP being a wrapper for ESP, without the expanded ICV. Wrapped ESP provides = a wrapper for ESP! The other item for discussion is whether WESP needs to explicitly different= iate between the payload being encrypted or NULL - I think this is a valid = point to discuss.=20 Numerous threads have talked about policy based deployments, mixed mode env= ironments, migration paths, using/not using heuristics, etc... The bottom line is that in order for a network appliance (Trusted Intermedi= ary) to offer critical network services (IDS/IPS/DPI/Access Control) in IPs= ec environments, it needs to know if a given IPsec packet is encrypted or n= ot in a deterministic manner and this is within scope.=20 WESP is offering this determination on a per packet basis.=20 I think we all agree that the traffic patterns will not fall into one singl= e category (NULL OR Encrypted) within an Enterprise environment. i.e. There= will be some traffic that is encrypted and some using NULL encryption.=20 Some argue that we should use WESP for NULL traffic, mandating ESP for encr= ypted traffic...AND ensure that ESP is NEVER used for NULL encryption withi= n a given domain / environment. How does an intermediate device know that t= his policy is being enforced? What if ESP is still being used for ESP-NULL = and encrypted traffic? If this is the case, we are back to where we were/ar= e today - no way to tell if ESP payload is encrypted or not.=20 Having the encrypted flag within WESP allows clear and explicit distinction= that certain traffic is encrypted whereas other traffic is not. This prese= rves the network based services we rely on and also allows other access con= trol policies to be enforced. E.g. I want to ensure that my finance data fl= owing in the network is encrypted and NOT using ESP-NULL. If I rely on ESP = for encrypted data and it can still use NULL encryption, I cannot enforce s= uch a policy from an access control tool. =20 Bottom line is that having this 'encryption' flag in WESP provides the capa= bility to deterministically provide and preserve critical network services = in IPsec environments, as well as apply access control policies. Without it= , we are back to half-baked solutions. As others have quoted the charter, here it is again... "A standards-track mechanism that allows an intermediary device, such as a firewall or intrusion detection system, to easily and reliably determine whether an ESP packet is encrypted with the NULL cipher; and if it is, determine the location of the actual payload data inside the packet." If we say that WESP is ONLY used to carry ESP-NULL (and ESP is used to carr= y encrypted traffic, but based on the ESP spec and legacy, it may also carr= y ESP-NULL), then we have not completed what we set out to do, as we have f= ailed to *reliably* determine if the ESP traffic is encrypted or not! Again, WESP does not replace ESP. It offers what it set out to do - an easy= and reliable way to tell if an IPsec packet has a NULL payload or if it is= encrypted. Thanks,=20 - Ken =20 >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >Of Paul Koning >Sent: Wednesday, January 06, 2010 1:43 PM >To: Stephen Kent >Cc: ipsec@ietf.org >Subject: Re: [IPsec] Traffic visibility - consensus call > >I've been watching a long stream of messages about WESP flying by and I >must admit to being rather confused. What follows is based on my best >understanding of what's going on, so please apply grains of salt as >needed. > >It's likely that I'm in the same corner as Tero. > >It sounds to me like WESP was chartered to do something very specific, >having to do with ESP-NULL and intermediate systems looking at traffic. >And now we have discussions about ESP-nonNULL with WESP, and maybe WESP >as an alternative to ESP, or a replacement to ESP. > >How is this possible? It's nice to talk about the benefits of greater >generality and all that, but it isn't proper to have a WG chartered to >do a narrow thing and then end up doing something much bigger. > >Why not? > >Answer: the purpose of a charter is (a) to tell the WG what it should be >doing, (b) to tell observers whether the work of the WG is something >they need to track -- or do NOT need to track. > >If a WG goes well outside its charter, that's not fair to those who >would have participated if the charter had said this, but ended up not >participating because the charter told them they did not need to. From >what I understand from Tero's comments, that situation applies to him, >and I think it applies to me as well. > >It may well be a good idea to expand or modify or generalize or replace >ESP, but if such a project is to be done, it should be done by a WG >chartered for that purpose, so that all interested parties are on notice >that this work is about to happen. > >Meanwhile, as to the consensus call: if this is out of charter as it >appears to be, then, independent of its technical merit, my vote is NO. > > paul koning >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec From mauricio.sanchez@hp.com Wed Jan 6 16:04:02 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58E4C3A683F for ; Wed, 6 Jan 2010 16:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fg17rT7AIJdH for ; Wed, 6 Jan 2010 16:04:01 -0800 (PST) Received: from g4t0017.houston.hp.com (g4t0017.houston.hp.com [15.201.24.20]) by core3.amsl.com (Postfix) with ESMTP id 5F5FA3A659C for ; Wed, 6 Jan 2010 16:04:01 -0800 (PST) Received: from G6W0641.americas.hpqcorp.net (g6w0641.atlanta.hp.com [16.230.34.77]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0017.houston.hp.com (Postfix) with ESMTPS id 8B1983868D for ; Thu, 7 Jan 2010 00:03:59 +0000 (UTC) Received: from G5W0325.americas.hpqcorp.net (16.228.8.67) by G6W0641.americas.hpqcorp.net (16.230.34.77) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 7 Jan 2010 00:03:20 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G5W0325.americas.hpqcorp.net ([16.228.8.67]) with mapi; Thu, 7 Jan 2010 00:03:20 +0000 From: "Sanchez, Mauricio (ProCurve)" To: "ipsec@ietf.org" Date: Thu, 7 Jan 2010 00:03:18 +0000 Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AcqOAg6CNa7TzR2bQzOucpln3vnudwBKeuCA Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C51B3D6A20C@GVW0671EXC.americas.hpqcorp.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 00:04:02 -0000 Responding to Yaron's request for group input on two questions pertaining t= o WESP draft On question #1 (ICV calculation): I don't agree with design decision to inc= lude WESP header in ESP trailer's ICV. I see it as unnecessary contaminati= on of ESP protocol. =20 On question #2 (Allowing WESP as alternative to ESP): I support this desig= n choice. On the whole I feel that the functionality described for WESP, ev= en when perceived as an alternative to ESP, is a step in the right directi= on for supporting several key use cases for us. =20 Cheers, MS --------------------------------------------=20 Mauricio Sanchez Chief Security Architect HP ProCurve Networking Hewlett-Packard 8000 Foothills Blvd. M/S 5541 Roseville, CA 95747 tel: 916.785.1910 fax: 916.785.1749 mauricio.sanchez@hp.com =20 -------------------------------------------- ---------------------------------------------------------------------- Message: 1 Date: Tue, 5 Jan 2010 00:27:26 +0200 From: Yaron Sheffer Subject: [IPsec] Traffic visibility - consensus call To: "ipsec@ietf.org" Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> =09 Content-Type: text/plain; charset=3D"us-ascii" Hi, We have had a few "discusses" during the IESG review of the WESP draft. To = help resolve them, we would like to reopen the following two questions to W= G discussion. Well reasoned answers are certainly appreciated. But plain "y= es" or "no" would also be useful in judging the group's consensus. - The current draft (http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-= visibility-11) defines the ESP trailer's ICV calculation to include the WES= P header. This has been done to counter certain attacks, but it means that = WESP is no longer a simple wrapper around ESP - ESP itself is modified. Do = you support this design decision? - The current draft allows WESP to be applied to encrypted ESP flows, in ad= dition to the originally specified ESP-null. This was intended so that encr= ypted flows can benefit from the future extensibility offered by WESP. But = arguably, it positions WESP as an alternative to ESP. Do you support this d= esign decision? Thanks, Yaron ------------------------------ From dharkins@lounge.org Wed Jan 6 16:04:22 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04FE23A6861 for ; Wed, 6 Jan 2010 16:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHpvz02NljoL for ; Wed, 6 Jan 2010 16:04:21 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 1B4E53A692A for ; Wed, 6 Jan 2010 16:04:21 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id B21BA1022404A; Wed, 6 Jan 2010 16:04:19 -0800 (PST) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 6 Jan 2010 16:04:19 -0800 (PST) Message-ID: In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com><7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com><378834.93787.qm@web82602.mail.mud.yahoo.com><4B43AAF7.8030302@vigilsec.com><734514.64270.qm@web82604.mail.mud.yahoo.com><5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018D15@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Date: Wed, 6 Jan 2010 16:04:19 -0800 (PST) From: "Dan Harkins" To: "Grewal, Ken" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "ipsec@ietf.org" , Paul Koning , Stephen Kent Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 00:04:22 -0000 Hi Ken, No one responded to my suggestion so I'll suggest it again below. On Wed, January 6, 2010 2:42 pm, Grewal, Ken wrote: [snip] > The bottom line is that in order for a network appliance (Trusted > Intermediary) to offer critical network services (IDS/IPS/DPI/Access > Control) in IPsec environments, it needs to know if a given IPsec packet > is encrypted or not in a deterministic manner and this is within scope. > WESP is offering this determination on a per packet basis. That is a clear definition of the problem: a TI must be able to determine whether a given IPsec packet is encrypted or not. [snip] > Some argue that we should use WESP for NULL traffic, mandating ESP for > encrypted traffic...AND ensure that ESP is NEVER used for NULL encryption > within a given domain / environment. How does an intermediate device know > that this policy is being enforced? What if ESP is still being used for > ESP-NULL and encrypted traffic? If this is the case, we are back to where > we were/are today - no way to tell if ESP payload is encrypted or not. The intermediate device knows this because it is under the same policy domain as the endpoints that have agreed to do WESP. If he's not in the same policy domain then he has no assurance that the endpoints will do WESP anyway. Maybe they'll do ESP and maybe even use the NULL cipher, so this box in the cloud is out-of-luck again and WESP doesn't help. Unless, of course, WESP is really a trojan horse to deprecate ESP and force everyone to use WESP always but you have said that's not the case. So now my suggestion again. If you're going to specify a new protocol and require endpoints to implement it then why not just make a new IPsec protocol that is a NAT-friendly way of doing per-packet integrity protection? Don't try to "wrap" ESP packets. That way the middlebox knows that when it sees this new protocol that it is not encrypted and when it sees ESP it knows it is encrypted (it knows that ESP is not using NULL encryption because policy has disallowed that). We could even think about deprecating ESP-NULL in favor of this new protocol. This would be an architecturally cleaner way of solving the problem you clearly described above. IKE can negotiate the new protocol, in transport- or tunnel-mode, negotiate an algorithm to use to provide integrity protection, and establish an authenticated and shared key to use with the algorithm. So what's the problem with this suggestion? regards, Dan. From latten@austin.ibm.com Wed Jan 6 16:31:06 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E86B3A683D for ; Wed, 6 Jan 2010 16:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcbixIogxgas for ; Wed, 6 Jan 2010 16:31:04 -0800 (PST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by core3.amsl.com (Postfix) with ESMTP id 6F53D3A659C for ; Wed, 6 Jan 2010 16:31:04 -0800 (PST) Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e4.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o070LVuX020304 for ; Wed, 6 Jan 2010 19:21:31 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o070V2s01769720 for ; Wed, 6 Jan 2010 19:31:02 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o070V1Rq023540 for ; Wed, 6 Jan 2010 22:31:01 -0200 Received: from austin.ibm.com (netmail2.austin.ibm.com [9.41.248.176]) by d01av03.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o070V1RL023523; Wed, 6 Jan 2010 22:31:01 -0200 Received: from [9.41.41.43] (faith.austin.ibm.com [9.41.41.43]) by austin.ibm.com (8.13.8/8.12.10) with ESMTP id o070V0YD034050; Wed, 6 Jan 2010 18:31:01 -0600 From: Joy Latten To: "Grewal, Ken" In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018D15@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain Date: Wed, 06 Jan 2010 18:16:01 -0600 Message-Id: <1262823361.2717.569.camel@faith.austin.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: latten@austin.ibm.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 00:31:06 -0000 On Wed, 2010-01-06 at 15:42 -0700, Grewal, Ken wrote: > Paul, > > > > My 2 cents... > > Some people have jumped to conclusions that because we want to differentiate between encrypted and non-encrypted traffic by explicitly signaling in the packet, that WESP is now a replacement for ESP. > > THIS IS NOT THE CASE AND IT WAS NEVER THE INTENT! > > One item that may have led to this conclusion was the expanded ICV over WESP, but this was introduced as a mitigation for certain threats highlighted in the WG. Subsequent discussions have determined that it would be better to mitigate these treats in an alternative manner, so we can fall back to WESP being a wrapper for ESP, without the expanded ICV. Wrapped ESP provides a wrapper for ESP! > > The other item for discussion is whether WESP needs to explicitly differentiate between the payload being encrypted or NULL - I think this is a valid point to discuss. > > Numerous threads have talked about policy based deployments, mixed mode environments, migration paths, using/not using heuristics, etc... > > The bottom line is that in order for a network appliance (Trusted Intermediary) to offer critical network services (IDS/IPS/DPI/Access Control) in IPsec environments, it needs to know if a given IPsec packet is encrypted or not in a deterministic manner and this is within scope. > WESP is offering this determination on a per packet basis. > > I think we all agree that the traffic patterns will not fall into one single category (NULL OR Encrypted) within an Enterprise environment. i.e. There will be some traffic that is encrypted and some using NULL encryption. > > Some argue that we should use WESP for NULL traffic, mandating ESP for encrypted traffic...AND ensure that ESP is NEVER used for NULL encryption within a given domain / environment. How does an intermediate device know that this policy is being enforced? What if ESP is still being used for ESP-NULL and encrypted traffic? If this is the case, we are back to where we were/are today - no way to tell if ESP payload is encrypted or not. > > Having the encrypted flag within WESP allows clear and explicit distinction that certain traffic is encrypted whereas other traffic is not. This preserves the network based services we rely on and also allows other access control policies to be enforced. E.g. I want to ensure that my finance data flowing in the network is encrypted and NOT using ESP-NULL. If I rely on ESP for encrypted data and it can still use NULL encryption, I cannot enforce such a policy from an access control tool. > Ok. Thanks, for the clarity. I had read the latest draft and had been following the thread but wasn't clear on the justification of needing the encryption flag in WESP. So for my own understanding... the use of the "USE_WESP_MODE" for IKEv2 as indicated in the draft guarantees that WESP-capable nodes only use ESP for encryption and WESP for ESP-NULL. My thinking is, the SA created will somehow indicate this "USE-WESP-MODE" and thus guarantee that the packets on the SA enforce this policy, right? However, this is on the end node, not the intermediate device. And it is the intermediate device we want to give the guarantee to... especially in a mixed-environment... And the WESP header, with an encryption flag indicating encrypted or not, supplies this guarantee to the device. Am I understanding this correctly or missing something or not even in the ballpark? If I have understood correctly, then in reference to Yaron's email, I vote: >>- The current draft >>(http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11) >>defines the ESP trailer's ICV calculation to include the WESP header. >>This has been done to counter certain attacks, but it means that WESP >>is no longer a simple wrapper around ESP - ESP itself is modified. Do >>you support this design decision? No. Go back to WESP as a wrapper for ESP. >>- The current draft allows WESP to be applied to encrypted ESP flows, >>in addition to the originally specified ESP-null. This was intended so >>that encrypted flows can benefit from the future extensibility offered >>by WESP. But arguably, it positions WESP as an alternative to ESP. Do >>you support this design decision? Yes. regards, Joy > Bottom line is that having this 'encryption' flag in WESP provides the capability to deterministically provide and preserve critical network services in IPsec environments, as well as apply access control policies. Without it, we are back to half-baked solutions. > > As others have quoted the charter, here it is again... > > "A standards-track mechanism that allows an intermediary device, such > as a firewall or intrusion detection system, to easily and reliably > determine whether an ESP packet is encrypted with the NULL cipher; and > if it is, determine the location of the actual payload data inside the > packet." > > If we say that WESP is ONLY used to carry ESP-NULL (and ESP is used to carry encrypted traffic, but based on the ESP spec and legacy, it may also carry ESP-NULL), then we have not completed what we set out to do, as we have failed to *reliably* determine if the ESP traffic is encrypted or not! > > Again, WESP does not replace ESP. It offers what it set out to do - an easy and reliable way to tell if an IPsec packet has a NULL payload or if it is encrypted. > > Thanks, > - Ken > > > >-----Original Message----- > >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > >Of Paul Koning > >Sent: Wednesday, January 06, 2010 1:43 PM > >To: Stephen Kent > >Cc: ipsec@ietf.org > >Subject: Re: [IPsec] Traffic visibility - consensus call > > > >I've been watching a long stream of messages about WESP flying by and I > >must admit to being rather confused. What follows is based on my best > >understanding of what's going on, so please apply grains of salt as > >needed. > > > >It's likely that I'm in the same corner as Tero. > > > >It sounds to me like WESP was chartered to do something very specific, > >having to do with ESP-NULL and intermediate systems looking at traffic. > >And now we have discussions about ESP-nonNULL with WESP, and maybe WESP > >as an alternative to ESP, or a replacement to ESP. > > > >How is this possible? It's nice to talk about the benefits of greater > >generality and all that, but it isn't proper to have a WG chartered to > >do a narrow thing and then end up doing something much bigger. > > > >Why not? > > > >Answer: the purpose of a charter is (a) to tell the WG what it should be > >doing, (b) to tell observers whether the work of the WG is something > >they need to track -- or do NOT need to track. > > > >If a WG goes well outside its charter, that's not fair to those who > >would have participated if the charter had said this, but ended up not > >participating because the charter told them they did not need to. From > >what I understand from Tero's comments, that situation applies to him, > >and I think it applies to me as well. > > > >It may well be a good idea to expand or modify or generalize or replace > >ESP, but if such a project is to be done, it should be done by a WG > >chartered for that purpose, so that all interested parties are on notice > >that this work is about to happen. > > > >Meanwhile, as to the consensus call: if this is out of charter as it > >appears to be, then, independent of its technical merit, my vote is NO. > > > > paul koning > >_______________________________________________ > >IPsec mailing list > >IPsec@ietf.org > >https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From kohn.jack@gmail.com Wed Jan 6 16:42:11 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C118F3A6944 for ; Wed, 6 Jan 2010 16:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDYZajspVO8r for ; Wed, 6 Jan 2010 16:42:10 -0800 (PST) Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by core3.amsl.com (Postfix) with ESMTP id C619C3A683D for ; Wed, 6 Jan 2010 16:42:10 -0800 (PST) Received: by gxk9 with SMTP id 9so39640427gxk.8 for ; Wed, 06 Jan 2010 16:42:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kC5z0U7mF5qzpw9AgGbLa1E6dxDxXCrml5ALTUMke/o=; b=wVnRRJdm1mDHAWTT93UWYFuOrr3yOy/INAFW7uPt2ZtZw5C+yAa31/b7Htllv3v2Nl HI2sRgtXMiosQtj8nga5eIe9GI+Uv4dY+eFKgVmisKaxe2iSjMadEY3Zh0+A6I91NQ8d Jjl8auCIOIadpBJUh1zpaJ+RHic8ue0N5BGVU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=M1c7PC84GZF1HeWN+MSLs6y9rY4PNuRjwOLb+I1umYSxUzN6NjP2OUs+arGIAdt7xH woTTXP89s3oC0ldkBTB0D9J6403s/hWq8Hf0RUFbp34xQgSJBLjAoWChWbyk+7tXC0C+ mKyyZ2vnhRSGAcqbLzReQsWmx2qatRCrJqSDg= MIME-Version: 1.0 Received: by 10.91.18.32 with SMTP id v32mr1133305agi.81.1262824925712; Wed, 06 Jan 2010 16:42:05 -0800 (PST) In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018D15@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Date: Thu, 7 Jan 2010 06:12:05 +0530 Message-ID: From: Jack Kohn To: Dan Harkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipsec@ietf.org" , Paul Koning , "Grewal, Ken" , Stephen Kent Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 00:42:11 -0000 >> Some argue that we should use WESP for NULL traffic, mandating ESP for >> encrypted traffic...AND ensure that ESP is NEVER used for NULL encryptio= n >> within a given domain / environment. How does an intermediate device kno= w >> that this policy is being enforced? What if ESP is still being used for >> ESP-NULL and encrypted traffic? If this is the case, we are back to wher= e >> we were/are today - no way to tell if ESP payload is encrypted or not. Thats the whole idea of using WESP with encryption. During the initial phase there will be less number of nodes supporting WESP, and the majority would be using ESP-NULL. However, as time passes, more and more nodes would move to WESP, because load balancers/firewalls/inspection devices will work properly only with WESP traffic. This would provide the end nodes with a motivation to upgrade to WESP. I dont think heuristics have a place here. Manav had sent an excellent detailed mail on the issues with heuristics and why its not as easy to implement as the authors and its proponents claim. Given that heuristics cannot be done, what alternative are we left with for middle boxes to deterministically differentiate between the two classes of traffic? The vision, and its not shared by everyone, is that after some time we will have lot of end nodes moving to WESP, as its only then that their packets can get prioritized, load balanced, etc. All other unrecognized traffic by the middle boxes will not follow the optimized path. > =A0So now my suggestion again. If you're going to specify a new protocol > and require endpoints to implement it then why not just make a new > IPsec protocol that is a NAT-friendly way of doing per-packet integrity > protection? Don't try to "wrap" ESP packets. That way the middlebox knows > that when it sees this new protocol that it is not encrypted and when it > sees ESP it knows it is encrypted (it knows that ESP is not using NULL > encryption because policy has disallowed that). We could even think about > deprecating ESP-NULL in favor of this new protocol. This would be an > architecturally cleaner way of solving the problem you clearly described > above. IKE can negotiate the new protocol, in transport- or tunnel-mode, > negotiate an algorithm to use to provide integrity protection, and > establish an authenticated and shared key to use with the algorithm. So > what's the problem with this suggestion? How different is your new protocol from WESP? Would it work if we were to call this new protocol XXXX instead of WESP. The idea behind this design is that it requires only an incremental implementation effort as its only a wrapper over an existing widely deployed implementation. Once we do away with WESP inside ESP ICV computation its really just a wrapper over ESP. Jack From ken.grewal@intel.com Wed Jan 6 16:43:29 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1E5A3A6944 for ; Wed, 6 Jan 2010 16:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPhVs-0ytn-V for ; Wed, 6 Jan 2010 16:43:28 -0800 (PST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by core3.amsl.com (Postfix) with ESMTP id BF26F3A693B for ; Wed, 6 Jan 2010 16:43:28 -0800 (PST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 06 Jan 2010 16:43:04 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.49,232,1262592000"; d="scan'208";a="481921573" Received: from rrsmsx603.amr.corp.intel.com ([10.31.0.57]) by orsmga002.jf.intel.com with ESMTP; 06 Jan 2010 16:42:54 -0800 Received: from rrsmsx601.amr.corp.intel.com (10.31.0.151) by rrsmsx603.amr.corp.intel.com (10.31.0.57) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 6 Jan 2010 17:43:15 -0700 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Wed, 6 Jan 2010 17:43:15 -0700 From: "Grewal, Ken" To: Dan Harkins Date: Wed, 6 Jan 2010 17:41:57 -0700 Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AcqPLP4YIThQEKfpS1uQeTJJ9DO7QwABGaAw Message-ID: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com><7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com><378834.93787.qm@web82602.mail.mud.yahoo.com><4B43AAF7.8030302@vigilsec.com><734514.64270.qm@web82604.mail.mud.yahoo.com><5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018D15@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Paul Koning , Stephen Kent Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 00:43:29 -0000 Hi Dan,=20 I think the main motivation for using ESP and providing a wrapper was so we= do not have to reinvent the wheel / redo all the work that has been done a= lready. Starting off from scratch on a new protocol would have meant a larger workl= oad and this item was meant to be a simple wrapper to provide the desired f= unctionality.=20 I do recall that someone else had brought up modifying AH earlier also, but= as ESP already provided everything we needed, including NAT-T support, and= we had two existing I-Ds as a starting point, we selected this route.=20 Thanks,=20 - Ken =20 >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >Of Dan Harkins >Sent: Wednesday, January 06, 2010 4:04 PM >To: Grewal, Ken >Cc: ipsec@ietf.org; Paul Koning; Stephen Kent >Subject: Re: [IPsec] Traffic visibility - consensus call > > > Hi Ken, > > No one responded to my suggestion so I'll suggest it again below. > >On Wed, January 6, 2010 2:42 pm, Grewal, Ken wrote: >[snip] >> The bottom line is that in order for a network appliance (Trusted >> Intermediary) to offer critical network services (IDS/IPS/DPI/Access >> Control) in IPsec environments, it needs to know if a given IPsec >packet >> is encrypted or not in a deterministic manner and this is within >scope. >> WESP is offering this determination on a per packet basis. > > That is a clear definition of the problem: a TI must be able to >determine whether a given IPsec packet is encrypted or not. > >[snip] >> Some argue that we should use WESP for NULL traffic, mandating ESP for >> encrypted traffic...AND ensure that ESP is NEVER used for NULL >encryption >> within a given domain / environment. How does an intermediate device >know >> that this policy is being enforced? What if ESP is still being used >for >> ESP-NULL and encrypted traffic? If this is the case, we are back to >where >> we were/are today - no way to tell if ESP payload is encrypted or not. > > The intermediate device knows this because it is under the same >policy domain as the endpoints that have agreed to do WESP. If he's not >in the same policy domain then he has no assurance that the endpoints >will do WESP anyway. Maybe they'll do ESP and maybe even use the NULL >cipher, so this box in the cloud is out-of-luck again and WESP doesn't >help. Unless, of course, WESP is really a trojan horse to deprecate ESP >and force everyone to use WESP always but you have said that's not the >case. > > So now my suggestion again. If you're going to specify a new protocol >and require endpoints to implement it then why not just make a new >IPsec protocol that is a NAT-friendly way of doing per-packet integrity >protection? Don't try to "wrap" ESP packets. That way the middlebox >knows >that when it sees this new protocol that it is not encrypted and when it >sees ESP it knows it is encrypted (it knows that ESP is not using NULL >encryption because policy has disallowed that). We could even think >about >deprecating ESP-NULL in favor of this new protocol. This would be an >architecturally cleaner way of solving the problem you clearly described >above. IKE can negotiate the new protocol, in transport- or tunnel-mode, >negotiate an algorithm to use to provide integrity protection, and >establish an authenticated and shared key to use with the algorithm. So >what's the problem with this suggestion? > > regards, > > Dan. > > >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec From ken.grewal@intel.com Wed Jan 6 16:50:17 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B52E83A6944 for ; Wed, 6 Jan 2010 16:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kam7SDnFx8uj for ; Wed, 6 Jan 2010 16:50:16 -0800 (PST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by core3.amsl.com (Postfix) with ESMTP id 8F0103A683D for ; Wed, 6 Jan 2010 16:50:14 -0800 (PST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 06 Jan 2010 16:49:46 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.49,231,1262592000"; d="scan'208";a="761996615" Received: from rrsmsx604.amr.corp.intel.com ([10.31.0.170]) by fmsmga001.fm.intel.com with ESMTP; 06 Jan 2010 16:50:02 -0800 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx604.amr.corp.intel.com ([10.31.0.170]) with mapi; Wed, 6 Jan 2010 17:50:11 -0700 From: "Grewal, Ken" To: "latten@austin.ibm.com" Date: Wed, 6 Jan 2010 17:48:54 -0700 Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AcqPMLOdumA0+G9ERquclh6el+Kh4AAAkzvQ Message-ID: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018D15@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <1262823361.2717.569.camel@faith.austin.ibm.com> In-Reply-To: <1262823361.2717.569.camel@faith.austin.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 00:50:17 -0000 Joy,=20 Yes, your understanding is correct - WESP with the encryption flag allows i= ntermediaries to determine if the payload is encrypted or NULL-encrypted an= d act accordingly.=20 Thanks,=20 - Ken =20 >-----Original Message----- >From: Joy Latten [mailto:latten@austin.ibm.com] >Sent: Wednesday, January 06, 2010 4:16 PM >To: Grewal, Ken >Cc: ipsec@ietf.org >Subject: Re: [IPsec] Traffic visibility - consensus call > >On Wed, 2010-01-06 at 15:42 -0700, Grewal, Ken wrote: >> Paul, >> >> messages on this topic! :-)> >> >> My 2 cents... >> >> Some people have jumped to conclusions that because we want to >differentiate between encrypted and non-encrypted traffic by explicitly >signaling in the packet, that WESP is now a replacement for ESP. >> >> THIS IS NOT THE CASE AND IT WAS NEVER THE INTENT! >> >> One item that may have led to this conclusion was the expanded ICV >over WESP, but this was introduced as a mitigation for certain threats >highlighted in the WG. Subsequent discussions have determined that it >would be better to mitigate these treats in an alternative manner, so we >can fall back to WESP being a wrapper for ESP, without the expanded ICV. >Wrapped ESP provides a wrapper for ESP! >> >> The other item for discussion is whether WESP needs to explicitly >differentiate between the payload being encrypted or NULL - I think this >is a valid point to discuss. >> >> Numerous threads have talked about policy based deployments, mixed >mode environments, migration paths, using/not using heuristics, etc... >> >> The bottom line is that in order for a network appliance (Trusted >Intermediary) to offer critical network services (IDS/IPS/DPI/Access >Control) in IPsec environments, it needs to know if a given IPsec packet >is encrypted or not in a deterministic manner and this is within scope. >> WESP is offering this determination on a per packet basis. >> >> I think we all agree that the traffic patterns will not fall into one >single category (NULL OR Encrypted) within an Enterprise environment. >i.e. There will be some traffic that is encrypted and some using NULL >encryption. >> >> Some argue that we should use WESP for NULL traffic, mandating ESP for >encrypted traffic...AND ensure that ESP is NEVER used for NULL >encryption within a given domain / environment. How does an intermediate >device know that this policy is being enforced? What if ESP is still >being used for ESP-NULL and encrypted traffic? If this is the case, we >are back to where we were/are today - no way to tell if ESP payload is >encrypted or not. >> >> Having the encrypted flag within WESP allows clear and explicit >distinction that certain traffic is encrypted whereas other traffic is >not. This preserves the network based services we rely on and also >allows other access control policies to be enforced. E.g. I want to >ensure that my finance data flowing in the network is encrypted and NOT >using ESP-NULL. If I rely on ESP for encrypted data and it can still use >NULL encryption, I cannot enforce such a policy from an access control >tool. >> >Ok. Thanks, for the clarity. I had read the latest draft and had been >following the thread but wasn't clear on the justification of needing >the encryption flag in WESP. > >So for my own understanding... the use of the "USE_WESP_MODE" for IKEv2 >as indicated in the draft guarantees that WESP-capable nodes only use >ESP for encryption and WESP for ESP-NULL. My thinking is, the SA created >will somehow indicate this "USE-WESP-MODE" and thus guarantee that the >packets on the SA enforce this policy, right? However, this is on the >end node, not the intermediate device. And it is the intermediate device >we want to give the guarantee to... especially in a mixed-environment... >And the WESP header, with an encryption flag indicating encrypted or >not, supplies this guarantee to the device. Am I understanding this >correctly or missing something or not even in the ballpark? > >If I have understood correctly, then in reference to Yaron's email, I >vote: > >>>- The current draft >>>(http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11) >>>defines the ESP trailer's ICV calculation to include the WESP header. >>>This has been done to counter certain attacks, but it means that WESP >>>is no longer a simple wrapper around ESP - ESP itself is modified. Do >>>you support this design decision? > >No. Go back to WESP as a wrapper for ESP. > >>>- The current draft allows WESP to be applied to encrypted ESP flows, >>>in addition to the originally specified ESP-null. This was intended so >>>that encrypted flows can benefit from the future extensibility offered >>>by WESP. But arguably, it positions WESP as an alternative to ESP. Do >>>you support this design decision? > >Yes. > >regards, >Joy > > >> Bottom line is that having this 'encryption' flag in WESP provides the >capability to deterministically provide and preserve critical network >services in IPsec environments, as well as apply access control >policies. Without it, we are back to half-baked solutions. >> >> As others have quoted the charter, here it is again... >> >> "A standards-track mechanism that allows an intermediary device, such >> as a firewall or intrusion detection system, to easily and reliably >> determine whether an ESP packet is encrypted with the NULL cipher; and >> if it is, determine the location of the actual payload data inside the >> packet." >> >> If we say that WESP is ONLY used to carry ESP-NULL (and ESP is used to >carry encrypted traffic, but based on the ESP spec and legacy, it may >also carry ESP-NULL), then we have not completed what we set out to do, >as we have failed to *reliably* determine if the ESP traffic is >encrypted or not! >> >> Again, WESP does not replace ESP. It offers what it set out to do - an >easy and reliable way to tell if an IPsec packet has a NULL payload or >if it is encrypted. >> >> Thanks, >> - Ken >> >> >> >-----Original Message----- >> >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >Behalf >> >Of Paul Koning >> >Sent: Wednesday, January 06, 2010 1:43 PM >> >To: Stephen Kent >> >Cc: ipsec@ietf.org >> >Subject: Re: [IPsec] Traffic visibility - consensus call >> > >> >I've been watching a long stream of messages about WESP flying by and >I >> >must admit to being rather confused. What follows is based on my >best >> >understanding of what's going on, so please apply grains of salt as >> >needed. >> > >> >It's likely that I'm in the same corner as Tero. >> > >> >It sounds to me like WESP was chartered to do something very >specific, >> >having to do with ESP-NULL and intermediate systems looking at >traffic. >> >And now we have discussions about ESP-nonNULL with WESP, and maybe >WESP >> >as an alternative to ESP, or a replacement to ESP. >> > >> >How is this possible? It's nice to talk about the benefits of >greater >> >generality and all that, but it isn't proper to have a WG chartered >to >> >do a narrow thing and then end up doing something much bigger. >> > >> >Why not? >> > >> >Answer: the purpose of a charter is (a) to tell the WG what it should >be >> >doing, (b) to tell observers whether the work of the WG is something >> >they need to track -- or do NOT need to track. >> > >> >If a WG goes well outside its charter, that's not fair to those who >> >would have participated if the charter had said this, but ended up >not >> >participating because the charter told them they did not need to. >From >> >what I understand from Tero's comments, that situation applies to >him, >> >and I think it applies to me as well. >> > >> >It may well be a good idea to expand or modify or generalize or >replace >> >ESP, but if such a project is to be done, it should be done by a WG >> >chartered for that purpose, so that all interested parties are on >notice >> >that this work is about to happen. >> > >> >Meanwhile, as to the consensus call: if this is out of charter as it >> >appears to be, then, independent of its technical merit, my vote is >NO. >> > >> > paul koning >> >_______________________________________________ >> >IPsec mailing list >> >IPsec@ietf.org >> >https://www.ietf.org/mailman/listinfo/ipsec >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec From paul.hoffman@vpnc.org Wed Jan 6 17:06:57 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EA7A3A6967 for ; Wed, 6 Jan 2010 17:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.064 X-Spam-Level: X-Spam-Status: No, score=-6.064 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7py8wzVSJZlq for ; Wed, 6 Jan 2010 17:06:56 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id AC9CB3A696C for ; Wed, 6 Jan 2010 17:06:56 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0716iSq083691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jan 2010 18:06:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 6 Jan 2010 17:06:43 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: Tero Kivinen Subject: [IPsec] New IKEv2 parameter listing at IANA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 01:06:57 -0000 Greetings again. All IKEv2 developers: please review , which has a few of the registries updated and reformatted. If you see anything wrong, please contact Yaron and Tero and I. Thanks! --Paul Hoffman, Director --VPN Consortium From dharkins@lounge.org Wed Jan 6 17:16:15 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB7283A6972 for ; Wed, 6 Jan 2010 17:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zai82fTrqqxs for ; Wed, 6 Jan 2010 17:16:14 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id C4DA33A6971 for ; Wed, 6 Jan 2010 17:16:14 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 2E4181022404A; Wed, 6 Jan 2010 17:16:13 -0800 (PST) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 6 Jan 2010 17:16:13 -0800 (PST) Message-ID: <990dc8709d807e083bc24d3a45352384.squirrel@www.trepanning.net> In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018D15@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Date: Wed, 6 Jan 2010 17:16:13 -0800 (PST) From: "Dan Harkins" To: "Jack Kohn" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 01:16:15 -0000 Hi Jack, My suggestion in not just a semantic one. The protocol would be different because it would not wrap an existing, ESP-encapsulated packet. There would be no "additional attributes", no "next header" duplication, no processing overhead to check whether data is the same in two places, and none of the issues currently being discussed here, like the encrypted data bit. It would be just like AH but NAT-friendly. It would be simple to implement and more clean architecturally. You could probably even cut-and-paste large portions of AH to make a draft too. I am somewhat sympathetic to your point about the implementation effort but hacks always _appear_ easier than doing it right (which is why they're done in the first place) and this seems alot like a hack. Heck, if implementation simplicity is a concern you could probably cut-and-paste large portions of your AH implementation to do this type of a protocol and in that sense it might actually even be easier than an ESP wrapper. Dan. On Wed, January 6, 2010 4:42 pm, Jack Kohn wrote: >>> Some argue that we should use WESP for NULL traffic, mandating ESP for >>> encrypted traffic...AND ensure that ESP is NEVER used for NULL >>> encryption >>> within a given domain / environment. How does an intermediate device >>> know >>> that this policy is being enforced? What if ESP is still being used for >>> ESP-NULL and encrypted traffic? If this is the case, we are back to >>> where >>> we were/are today - no way to tell if ESP payload is encrypted or not. > > Thats the whole idea of using WESP with encryption. During the initial > phase there will be less number of nodes supporting WESP, and the > majority would be using ESP-NULL. However, as time passes, more and > more nodes would move to WESP, because load > balancers/firewalls/inspection devices will work properly only with > WESP traffic. This would provide the end nodes with a motivation to > upgrade to WESP. I dont think heuristics have a place here. Manav had > sent an excellent detailed mail on the issues with heuristics and why > its not as easy to implement as the authors and its proponents claim. > > Given that heuristics cannot be done, what alternative are we left > with for middle boxes to deterministically differentiate between the > two classes of traffic? > > The vision, and its not shared by everyone, is that after some time we > will have lot of end nodes moving to WESP, as its only then that their > packets can get prioritized, load balanced, etc. All other > unrecognized traffic by the middle boxes will not follow the optimized > path. > >>  So now my suggestion again. If you're going to specify a new protocol >> and require endpoints to implement it then why not just make a new >> IPsec protocol that is a NAT-friendly way of doing per-packet integrity >> protection? Don't try to "wrap" ESP packets. That way the middlebox >> knows >> that when it sees this new protocol that it is not encrypted and when it >> sees ESP it knows it is encrypted (it knows that ESP is not using NULL >> encryption because policy has disallowed that). We could even think >> about >> deprecating ESP-NULL in favor of this new protocol. This would be an >> architecturally cleaner way of solving the problem you clearly described >> above. IKE can negotiate the new protocol, in transport- or tunnel-mode, >> negotiate an algorithm to use to provide integrity protection, and >> establish an authenticated and shared key to use with the algorithm. So >> what's the problem with this suggestion? > > How different is your new protocol from WESP? Would it work if we were > to call this new protocol XXXX instead of WESP. > > The idea behind this design is that it requires only an incremental > implementation effort as its only a wrapper over an existing widely > deployed implementation. Once we do away with WESP inside ESP ICV > computation its really just a wrapper over ESP. > > Jack > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From charliek@microsoft.com Wed Jan 6 23:14:27 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B430B3A6983 for ; Wed, 6 Jan 2010 23:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rFGEfWY6FVF for ; Wed, 6 Jan 2010 23:14:23 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id C41563A6821 for ; Wed, 6 Jan 2010 23:14:20 -0800 (PST) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 6 Jan 2010 23:14:59 -0800 Received: from TK5EX14MBXC119.redmond.corp.microsoft.com ([169.254.10.191]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi; Wed, 6 Jan 2010 23:14:21 -0800 From: Charlie Kaufman To: Yaron Sheffer , "ipsec@ietf.org" Thread-Topic: Traffic visibility - consensus call Thread-Index: AQHKjYZTQaGsaxOJ1EKbzfglwJmR2ZGF/XelgAOt8dA= Date: Thu, 7 Jan 2010 07:14:16 +0000 Message-ID: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 07:14:27 -0000 Oh sigh!! What is it about IPsec that makes people go down this same path e= very time: 1) Someone proposes an utterly simple and useful piece of functionality (in= this case, some way to indicate where the encapsulated data begins in the = case where ESP is carrying unencrypted data. 2) The proposal is a little more complex than we might have hoped because w= e have to deal with forward migration (in this case, we can't add a new fie= ld to the ESP header - it was not extensible in this way - so we have to in= vent some new alternate header or a wrapper for the existing one). 3) Hoards of people propose minor improvements in the form of extensibility= "infection sites" where future stuff can be added in a way that (if we're = lucky) won't cause as much migration pain in the future if some similar ext= ension is needed in the future. (In this case, we might want more informati= on than the offset to the beginning of the plaintext data. Let's add a vari= able length header extension whose content is specified later. Oh, and the = decision to put the "next protocol" field at the end of the ESP format inst= ead of the front in order to maintain someone's idea of alignment turns out= to be trouble, so let's put a copy at the front. Oh, and some of those fie= lds we might want to specify someday might be security sensitive so let's c= hange the integrity check to cover them. Oh, and we might want those extra = fields we might want to specify someday to be added even for encrypted pack= ets, so let's make the functionality that got this whole ball rolling optio= nal!) 4) The resulting protocol is complex and misunderstood, and as a result it = is incorrectly implemented by enough high profile vendors that any future e= xtensibility based on the unused options will break them and in practice ha= ve to be done in some new and more horrible way. We're on step 3, debating whether to push on with something ugly or spend a= nother year trying to make the thing simpler. Can anyone think of an exampl= e of where taking another year to make things simpler actually worked? And = for those who think simplifying this will only slow it down by a few weeks,= post the prediction to the list and I'll forward this note to you in a yea= r and ask how things are going. Responding to Yaron's questions: [Yaron:] - The current draft (http://tools.ietf.org/html/draft-ietf-ipsecme= -traffic-visibility-11) defines the ESP trailer's ICV calculation to includ= e the WESP header. This has been done to counter certain attacks, but it me= ans that WESP is no longer a simple wrapper around ESP - ESP itself is modi= fied. Do you support this design decision? [CWK: ] If and only if it causes the process to complete faster. If we're g= oing to have the option to add new options later, it makes sense to be able= to integrity protect them. But it might make this a little harder to imple= ment for some vendors. Neither of these arguments is important; I'd vote fo= r whatever makes the debate end sooner. [Yaron: ] - The current draft allows WESP to be applied to encrypted ESP fl= ows, in addition to the originally specified ESP-null. This was intended so= that encrypted flows can benefit from the future extensibility offered by = WESP. But arguably, it positions WESP as an alternative to ESP. Do you supp= ort this design decision? [CWK: ] If and only if it causes the process to complete faster. If we're g= oing to have the option to add new options later, it makes sense to be able= to apply those options to encrypted flows. But it makes the check in a mid= dle-box for whether there is plaintext data in the packet more complex and = implementations more complex (neither by very much). Neither of these argum= ents is important; I'd vote for whatever makes the debate end sooner. [CWK:] Unfortunately, I don't know what will make the debate end sooner. If= history is any guide, neither decision will and we're just doomed. [CWK:] PROVE ME WRONG!! PLEASE!! --Charlie From ynir@checkpoint.com Wed Jan 6 23:26:59 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47BD128C0F6 for ; Wed, 6 Jan 2010 23:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uup8aoSAawL4 for ; Wed, 6 Jan 2010 23:26:58 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 4F17F28C0E9 for ; Wed, 6 Jan 2010 23:26:58 -0800 (PST) X-CheckPoint: {4B458AF0-10005-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 31C6629C004; Thu, 7 Jan 2010 09:26:56 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 1426729C002; Thu, 7 Jan 2010 09:26:56 +0200 (IST) X-CheckPoint: {4B458AF0-10000-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o077QtT7025158; Thu, 7 Jan 2010 09:26:55 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 7 Jan 2010 09:27:09 +0200 From: Yoav Nir To: Charlie Kaufman Date: Thu, 7 Jan 2010 09:26:50 +0200 Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AcqPatJy20o2WynnS2+XrdHbWnVodg== Message-ID: <9FB9969A-3C81-456F-92AE-AE33AFA49B58@checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 07:26:59 -0000 On Jan 7, 2010, at 9:14 AM, Charlie Kaufman wrote: > Oh sigh!! What is it about IPsec that makes people go down this same path= every time: IPsec? So I guess you haven't been following the TLS mailing list these past coupl= e of months. I don't think anyone's described a practical attack on WESP without extendi= ng the ICV protected data, but I'm afraid that if we don't extend it, somed= ay somebody will, and then we'll really have a situation like they have, re= trofitting "new ICV" into "old WESP", using "extensions" that many did not = implement correctly. From charliek@microsoft.com Wed Jan 6 23:30:49 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B9FE3A6954 for ; Wed, 6 Jan 2010 23:30:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGQSGIOgAP5D for ; Wed, 6 Jan 2010 23:30:48 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 47B443A67F4 for ; Wed, 6 Jan 2010 23:30:48 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 6 Jan 2010 23:31:26 -0800 Received: from TK5EX14MBXC119.redmond.corp.microsoft.com ([169.254.10.191]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi; Wed, 6 Jan 2010 23:30:46 -0800 From: Charlie Kaufman To: Paul Hoffman , Tero Kivinen , "Yaron Sheffer" Thread-Topic: [IPsec] Clarifying what happens with INITIAL_CONTACT Thread-Index: AQHKh2qtLkzTtwsLPku0K5F2hjUSZpF7HAGAgAACNgCAAUd0AIAFQvqAgAgcdoA= Date: Thu, 7 Jan 2010 07:30:45 +0000 Message-ID: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C46D7@il-ex01.ad.checkpoint.com> <19257.58134.758647.17743@fireball.kivinen.iki.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] Clarifying what happens with INITIAL_CONTACT X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 07:30:49 -0000 There was a lot of debate in the original IPsec working group about INITIAL= _CONTACT. We should be careful not to add any MUSTs that would make noticin= g it mandatory, since that would complicate minimal implementations. It wou= ld be reasonable to say that if an IKE SA is deleted in response to an INIT= IAL_CONTACT notification, the node deleting is SHOULD NOT send a DELETE pay= load or any other notification on the obsolete SA. The real use of INITIAL_CONTACT involves semantics not specified in IKEv2 (= and I never really understood the semantics in the architecture document). = The problem is that if there are two SAs that specify duplicate traffic sel= ectors (or even overlapping), how is the destination supposed to know which= one to use when sending outbound traffic? INITIAL_CONTACT addresses the pr= oblem in practice but not in theory, because it closes SAs with the same au= thenticated identity, not with the same traffic selectors (which could be i= ndependent). It's a can of worms that I don't think we should reopen unless= there is some real problem we're trying to solve. --Charlie -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of P= aul Hoffman Sent: Friday, January 01, 2010 11:29 AM To: Tero Kivinen; Yaron Sheffer Cc: IPsecme WG Subject: Re: [IPsec] Clarifying what happens with INITIAL_CONTACT At 1:08 PM +0200 12/29/09, Tero Kivinen wrote: >Paul Hoffman writes: >> At 5:28 PM +0200 12/28/09, Yaron Sheffer wrote: >> > You are adding two MUSTs, which we SHOULD NOT do unless we have=20 >> > very good reasons, such as interop problems, security issues, or=20 >> > major functionality problems (like memory leaks). I'm not sure any=20 >> > of these apply, so I suggest that you change the wording to be=20 >> > non-normative. >> >> Whoops, all good points. I got carried away. How about: >> >> When an initiator receives an INITIAL_CONTACT notification in=20 >> response to its IKE_AUTH request, it silently deletes any IKE SAs and=20 >> associated Child SAs for that responder without sending any=20 >> notifications to the responder. If a responder receives an=20 >> INITIAL_CONTACT notification in an IKE_AUTH request, it silently=20 >> deletes any IKE SAs and associated Child SAs for that initiator=20 >> without sending any notifications to the initiator. > >I would actually keep the keyword we have in the RFC4306, i.e. "MAY". >It says "... recipient MAY use this information to delete any other=20 >IKE_SAs ...". I am not sure what you say above and the MAY are really=20 >same. For me the text above says you need to do it, even when it does=20 >not have word "MUST" in it, as it only gives you exactly one option. > >As implementations are not required to understand (or send)=20 >INITIAL_CONTACT notifications writing text like you have is bit=20 >dangerous, as some people might still read that recipient of=20 >INITIAL_CONTACT needs to silently delete any IKE SAs when it receives=20 >INITIAL_CONTACT. Hrm. Another good point. Ignore this proposed change. FWIW, what I was real= ly trying to get at in the addition was that, if you delete SAs when you ge= t an INITIAL_CONTACT, you should do it silently, not by sending Delete noti= fications. But I don't see how to do that without adding normative-like lan= guage; if others can see how to say that, by all means let me know. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From yaronf@checkpoint.com Thu Jan 7 04:15:46 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 375093A67E2 for ; Thu, 7 Jan 2010 04:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82fBBew43nAG for ; Thu, 7 Jan 2010 04:15:44 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 5602C3A676A for ; Thu, 7 Jan 2010 04:15:43 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o07C7xT8003058; Thu, 7 Jan 2010 14:07:59 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 7 Jan 2010 14:08:12 +0200 From: Yaron Sheffer To: "latten@austin.ibm.com" , "Grewal, Ken" Date: Thu, 7 Jan 2010 14:08:08 +0200 Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AcqPML75TOxKvXW/QT+x8kaItYSe/QAYSwqQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C5160@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018D15@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <1262823361.2717.569.camel@faith.austin.ibm.com> In-Reply-To: <1262823361.2717.569.camel@faith.austin.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 12:15:46 -0000 Hi Joy, Sorry but this is not the case. Quoting your text below: "The use of the "U= SE_WESP_MODE" for IKEv2 as indicated in the draft guarantees that WESP-capa= ble nodes only use ESP for encryption and WESP for ESP-NULL." This is incorrect: proponents of the encryption flag would have the WESP-ca= pable devices use WESP for *both* encrypted and ESP-null traffic. And as you say, intermediaries would then be able to distinguish both kinds= of traffic using the encryption flag in the WEPS header. Thanks, Yaron -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of J= oy Latten Sent: Thursday, January 07, 2010 2:16 To: Grewal, Ken Cc: ipsec@ietf.org Subject: Re: [IPsec] Traffic visibility - consensus call On Wed, 2010-01-06 at 15:42 -0700, Grewal, Ken wrote: > Paul,=20 >=20 > >=20 > My 2 cents... >=20 > Some people have jumped to conclusions that because we want to differenti= ate between encrypted and non-encrypted traffic by explicitly signaling in = the packet, that WESP is now a replacement for ESP. >=20 > THIS IS NOT THE CASE AND IT WAS NEVER THE INTENT!=20 >=20 > One item that may have led to this conclusion was the expanded ICV over W= ESP, but this was introduced as a mitigation for certain threats highlighte= d in the WG. Subsequent discussions have determined that it would be better= to mitigate these treats in an alternative manner, so we can fall back to = WESP being a wrapper for ESP, without the expanded ICV. Wrapped ESP provide= s a wrapper for ESP! >=20 > The other item for discussion is whether WESP needs to explicitly differe= ntiate between the payload being encrypted or NULL - I think this is a vali= d point to discuss.=20 >=20 > Numerous threads have talked about policy based deployments, mixed mode e= nvironments, migration paths, using/not using heuristics, etc... >=20 > The bottom line is that in order for a network appliance (Trusted Interme= diary) to offer critical network services (IDS/IPS/DPI/Access Control) in I= Psec environments, it needs to know if a given IPsec packet is encrypted or= not in a deterministic manner and this is within scope.=20 > WESP is offering this determination on a per packet basis.=20 >=20 > I think we all agree that the traffic patterns will not fall into one sin= gle category (NULL OR Encrypted) within an Enterprise environment. i.e. The= re will be some traffic that is encrypted and some using NULL encryption.=20 >=20 > Some argue that we should use WESP for NULL traffic, mandating ESP for en= crypted traffic...AND ensure that ESP is NEVER used for NULL encryption wit= hin a given domain / environment. How does an intermediate device know that= this policy is being enforced? What if ESP is still being used for ESP-NUL= L and encrypted traffic? If this is the case, we are back to where we were/= are today - no way to tell if ESP payload is encrypted or not.=20 >=20 > Having the encrypted flag within WESP allows clear and explicit distincti= on that certain traffic is encrypted whereas other traffic is not. This pre= serves the network based services we rely on and also allows other access c= ontrol policies to be enforced. E.g. I want to ensure that my finance data = flowing in the network is encrypted and NOT using ESP-NULL. If I rely on ES= P for encrypted data and it can still use NULL encryption, I cannot enforce= such a policy from an access control tool. =20 >=20 Ok. Thanks, for the clarity. I had read the latest draft and had been following the thread but wasn't clear on the justification of needing the encryption flag in WESP. So for my own understanding... the use of the "USE_WESP_MODE" for IKEv2 as indicated in the draft guarantees that WESP-capable nodes only use ESP for encryption and WESP for ESP-NULL. My thinking is, the SA created will somehow indicate this "USE-WESP-MODE" and thus guarantee that the packets on the SA enforce this policy, right? However, this is on the end node, not the intermediate device. And it is the intermediate device we want to give the guarantee to... especially in a mixed-environment... And the WESP header, with an encryption flag indicating encrypted or not, supplies this guarantee to the device. Am I understanding this correctly or missing something or not even in the ballpark? If I have understood correctly, then in reference to Yaron's email, I vote: >>- The current draft >>(http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11) >>defines the ESP trailer's ICV calculation to include the WESP header. >>This has been done to counter certain attacks, but it means that WESP >>is no longer a simple wrapper around ESP - ESP itself is modified. Do >>you support this design decision? No. Go back to WESP as a wrapper for ESP. >>- The current draft allows WESP to be applied to encrypted ESP flows, >>in addition to the originally specified ESP-null. This was intended so >>that encrypted flows can benefit from the future extensibility offered >>by WESP. But arguably, it positions WESP as an alternative to ESP. Do >>you support this design decision? Yes. regards, Joy =20 > Bottom line is that having this 'encryption' flag in WESP provides the ca= pability to deterministically provide and preserve critical network service= s in IPsec environments, as well as apply access control policies. Without = it, we are back to half-baked solutions. >=20 > As others have quoted the charter, here it is again... >=20 > "A standards-track mechanism that allows an intermediary device, such > as a firewall or intrusion detection system, to easily and reliably > determine whether an ESP packet is encrypted with the NULL cipher; and > if it is, determine the location of the actual payload data inside the > packet." >=20 > If we say that WESP is ONLY used to carry ESP-NULL (and ESP is used to ca= rry encrypted traffic, but based on the ESP spec and legacy, it may also ca= rry ESP-NULL), then we have not completed what we set out to do, as we have= failed to *reliably* determine if the ESP traffic is encrypted or not! >=20 > Again, WESP does not replace ESP. It offers what it set out to do - an ea= sy and reliable way to tell if an IPsec packet has a NULL payload or if it = is encrypted. >=20 > Thanks,=20 > - Ken > =20 >=20 > >-----Original Message----- > >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > >Of Paul Koning > >Sent: Wednesday, January 06, 2010 1:43 PM > >To: Stephen Kent > >Cc: ipsec@ietf.org > >Subject: Re: [IPsec] Traffic visibility - consensus call > > > >I've been watching a long stream of messages about WESP flying by and I > >must admit to being rather confused. What follows is based on my best > >understanding of what's going on, so please apply grains of salt as > >needed. > > > >It's likely that I'm in the same corner as Tero. > > > >It sounds to me like WESP was chartered to do something very specific, > >having to do with ESP-NULL and intermediate systems looking at traffic. > >And now we have discussions about ESP-nonNULL with WESP, and maybe WESP > >as an alternative to ESP, or a replacement to ESP. > > > >How is this possible? It's nice to talk about the benefits of greater > >generality and all that, but it isn't proper to have a WG chartered to > >do a narrow thing and then end up doing something much bigger. > > > >Why not? > > > >Answer: the purpose of a charter is (a) to tell the WG what it should be > >doing, (b) to tell observers whether the work of the WG is something > >they need to track -- or do NOT need to track. > > > >If a WG goes well outside its charter, that's not fair to those who > >would have participated if the charter had said this, but ended up not > >participating because the charter told them they did not need to. From > >what I understand from Tero's comments, that situation applies to him, > >and I think it applies to me as well. > > > >It may well be a good idea to expand or modify or generalize or replace > >ESP, but if such a project is to be done, it should be done by a WG > >chartered for that purpose, so that all interested parties are on notice > >that this work is about to happen. > > > >Meanwhile, as to the consensus call: if this is out of charter as it > >appears to be, then, independent of its technical merit, my vote is NO. > > > > paul koning > >_______________________________________________ > >IPsec mailing list > >IPsec@ietf.org > >https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. From yaronf@checkpoint.com Thu Jan 7 04:19:40 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E67428C0DD for ; Thu, 7 Jan 2010 04:19:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkjTb2-8eOai for ; Thu, 7 Jan 2010 04:19:38 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 0FBEC28C110 for ; Thu, 7 Jan 2010 04:19:37 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o07CJUT7004357; Thu, 7 Jan 2010 14:19:30 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 7 Jan 2010 14:19:43 +0200 From: Yaron Sheffer To: Dan Harkins , "Grewal, Ken" Date: Thu, 7 Jan 2010 14:19:42 +0200 Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AcqPLQTAwLIgbN73S4SDpCURfr0NvQAZal9A Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C516D@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com><7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com><378834.93787.qm@web82602.mail.mud.yahoo.com><4B43AAF7.8030302@vigilsec.com><734514.64270.qm@web82604.mail.mud.yahoo.com><5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018D15@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Paul Koning , Stephen Kent Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 12:19:40 -0000 Hi Dan, There are multiple good ways to indicate ESP-null traffic. We just chose on= e option. But (assuming you strongly dislike heuristics, which some of us do) the big= question is how to indicate *encrypted* ESP. Deprecating ESP-null is a non= -starter: it is "changing ESP" just like changing the header format, and ev= en more so, because it is a practically invisible change. Thanks, Yaron -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of D= an Harkins Sent: Thursday, January 07, 2010 2:04 To: Grewal, Ken Cc: ipsec@ietf.org; Paul Koning; Stephen Kent Subject: Re: [IPsec] Traffic visibility - consensus call Hi Ken, No one responded to my suggestion so I'll suggest it again below. On Wed, January 6, 2010 2:42 pm, Grewal, Ken wrote: [snip] > The bottom line is that in order for a network appliance (Trusted > Intermediary) to offer critical network services (IDS/IPS/DPI/Access > Control) in IPsec environments, it needs to know if a given IPsec packet > is encrypted or not in a deterministic manner and this is within scope. > WESP is offering this determination on a per packet basis. That is a clear definition of the problem: a TI must be able to determine whether a given IPsec packet is encrypted or not. [snip] > Some argue that we should use WESP for NULL traffic, mandating ESP for > encrypted traffic...AND ensure that ESP is NEVER used for NULL encryption > within a given domain / environment. How does an intermediate device know > that this policy is being enforced? What if ESP is still being used for > ESP-NULL and encrypted traffic? If this is the case, we are back to where > we were/are today - no way to tell if ESP payload is encrypted or not. The intermediate device knows this because it is under the same policy domain as the endpoints that have agreed to do WESP. If he's not in the same policy domain then he has no assurance that the endpoints will do WESP anyway. Maybe they'll do ESP and maybe even use the NULL cipher, so this box in the cloud is out-of-luck again and WESP doesn't help. Unless, of course, WESP is really a trojan horse to deprecate ESP and force everyone to use WESP always but you have said that's not the case. So now my suggestion again. If you're going to specify a new protocol and require endpoints to implement it then why not just make a new IPsec protocol that is a NAT-friendly way of doing per-packet integrity protection? Don't try to "wrap" ESP packets. That way the middlebox knows that when it sees this new protocol that it is not encrypted and when it sees ESP it knows it is encrypted (it knows that ESP is not using NULL encryption because policy has disallowed that). We could even think about deprecating ESP-NULL in favor of this new protocol. This would be an architecturally cleaner way of solving the problem you clearly described above. IKE can negotiate the new protocol, in transport- or tunnel-mode, negotiate an algorithm to use to provide integrity protection, and establish an authenticated and shared key to use with the algorithm. So what's the problem with this suggestion? regards, Dan. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. From mglt.ietf@gmail.com Thu Jan 7 08:00:14 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E04B93A689A for ; Thu, 7 Jan 2010 08:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iww1biJNmEF for ; Thu, 7 Jan 2010 08:00:13 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 1F54D3A685E for ; Thu, 7 Jan 2010 08:00:12 -0800 (PST) Received: by bwz23 with SMTP id 23so11910311bwz.29 for ; Thu, 07 Jan 2010 08:00:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=au86+ZSO8IVp3R9zOD/DB/qsoXh5len4iw0BVAlhPmU=; b=Va6kkcR3mSdheOmxC8ADeqMwqWPq2+Hkze4LK77Y6Mwu8FhWuRpCcAS7S7RgyDfuoy ArYg2YVIZvPybiG+ZfTTOpaER9+CDrRptesF9EKUEQRVE8v16OzaQL2VeVwi52lXJdAM keQVd6O9lcvP5JYnMeNE+uvjQCseZ12kZvW0w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tIN7t7m6cfaUucu8YGvY/fH6o6pugiDFRSGSDojT4ibrEINpK0dC6vm8iFmCDY0Adx HYd3+ALHvhzOEiP0sVqw0Fo1DOePBCPPAHXFc8NxcCbz46K7rIoV6MArdrdQcey2UE92 TnAJmjmpKSK81uxPGodvTcEHmbMop+Lgy6KwE= MIME-Version: 1.0 Received: by 10.102.237.12 with SMTP id k12mr1768080muh.15.1262880001432; Thu, 07 Jan 2010 08:00:01 -0800 (PST) In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> Date: Thu, 7 Jan 2010 17:00:01 +0100 Message-ID: <51eafbcb1001070800j54130182p6c0ed35189ab65e5@mail.gmail.com> From: Daniel Migault To: Yaron Sheffer Content-Type: multipart/alternative; boundary=0016363ba708e11d7e047c9529d4 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 16:00:15 -0000 --0016363ba708e11d7e047c9529d4 Content-Type: text/plain; charset=ISO-8859-1 Hi, On Mon, Jan 4, 2010 at 11:27 PM, Yaron Sheffer wrote: > Hi, > > We have had a few "discusses" during the IESG review of the WESP draft. To > help resolve them, we would like to reopen the following two questions to WG > discussion. Well reasoned answers are certainly appreciated. But plain "yes" > or "no" would also be useful in judging the group's consensus. > > - The current draft ( > http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11) > defines the ESP trailer's ICV calculation to include the WESP header. This > has been done to counter certain attacks, but it means that WESP is no > longer a simple wrapper around ESP - ESP itself is modified. Do you support > this design decision? > Motivations for including the WESP header in the ICV calculation were to counter WESP header modifications. An alternative is to explicitly check WESP header fields. On my opinion both are fine. Checking WESP's header values makes WESP to be a Wrapper that do not change ESP. If this design issue makes implementation easier, that's even better. I may not understand all discussions on transition from ESP to WESP, and still consider WESP and ESP as two distinct protocols designed for different purposes. So my answer is YES I support this design decision. > > - The current draft allows WESP to be applied to encrypted ESP flows, in > addition to the originally specified ESP-null. This was intended so that > encrypted flows can benefit from the future extensibility offered by WESP. > But arguably, it positions WESP as an alternative to ESP. Do you support > this design decision? > As mentioned above WESP and ESP have been designed for two different purposes. ESP has been designed for end-to-end communications, WESP is based on ESP but has been designed to provide traffic visibility to middle boxes. One scenario considers bypassing ESP_NULL traffic and discarding -or having different policies -- for encrypted and/or unspecified traffic. This means that targeted traffic is ESP_NULL. Traffic management may also target NON_NULL_ESP traffic. If a node has multiple interfaces it can choose to forward NON_NULL_ESP traffic on a non-protected network, and has different policies for the rest of the traffic. We (Orange) do request, for traffic management purpose, that flows can explicitly specify whether they are encrypted or not-encrypted. The WESP header seems to me the proper place for that specification. We are not considering WESP as ESPv4, but we think that WESP (resp. ESP) will be used because WESP (resp. ESP) traffic will have better QoS then ESP. This will mainly depend on security and traffic management policies. So here again my answer is YES I support this design decision. Regards, Daniel > > Thanks, > Yaron > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --0016363ba708e11d7e047c9529d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

On Mon, Jan 4, 2010 at 11:27 PM, Yaro= n Sheffer <ya= ronf@checkpoint.com> wrote:
Hi,

We have had a few "discusses" during the IESG review of the WESP = draft. To help resolve them, we would like to reopen the following two ques= tions to WG discussion. Well reasoned answers are certainly appreciated. Bu= t plain "yes" or "no" would also be useful in judging t= he group's consensus.

- The current draft (http://tools.ietf.org/html/draf= t-ietf-ipsecme-traffic-visibility-11) defines the ESP trailer's ICV= calculation to include the WESP header. This has been done to counter cert= ain attacks, but it means that WESP is no longer a simple wrapper around ES= P - ESP itself is modified. Do you support this design decision?

Motivations for including the WESP header in the ICV = calculation were to counter WESP header modifications. An alternative is to= explicitly check WESP header fields. On my opinion both are fine. Checking= WESP's header values makes WESP to be a Wrapper that do not change ESP= . If this design issue makes implementation easier, that's even better.= I may not understand all discussions on transition from ESP to WESP, and s= till consider WESP and ESP as two distinct protocols designed for different= purposes.=A0 So my answer is YES I support this design decision.

- The current draft allows WESP to be applied to encrypted ESP flows, in ad= dition to the originally specified ESP-null. This was intended so that encr= ypted flows can benefit from the future extensibility offered by WESP. But = arguably, it positions WESP as an alternative to ESP. Do you support this d= esign decision?

As mentioned above WESP and ESP have been designed fo= r two different purposes. ESP has been designed for end-to-end communicatio= ns, WESP is based on ESP but has been designed to provide traffic visibilit= y to middle boxes. One scenario considers bypassing ESP_NULL traffic and di= scarding -or having different policies -- for encrypted and/or unspecified = traffic. This means that targeted traffic is ESP_NULL. Traffic management m= ay also target NON_NULL_ESP traffic. If a node has multiple interfaces it c= an choose to forward NON_NULL_ESP traffic on a non-protected network, and = has different policies for the rest of the traffic.
We (Orange) do request, for traffic management purpose, that flows can expl= icitly specify whether they are encrypted or not-encrypted. The WESP header= seems to me the proper place for that specification.
We are not consid= ering WESP as ESPv4, but we think that WESP (resp. ESP) will be used becaus= e WESP (resp. ESP) traffic will have better QoS then ESP. This will mainly = depend on security and traffic management policies.
So here again my answer is YES I support this design decision.

Regar= ds,
Daniel
=A0

Thanks,
=A0 =A0 Yaron
__________________________________= _____________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec



--
Daniel Miga= ult
Orange Labs -- Security
+33 6 70 72 69 58
--0016363ba708e11d7e047c9529d4-- From kent@bbn.com Thu Jan 7 08:10:18 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B378C3A6809 for ; Thu, 7 Jan 2010 08:10:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-nf-xNKs73P for ; Thu, 7 Jan 2010 08:10:17 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 687AE3A67FB for ; Thu, 7 Jan 2010 08:10:17 -0800 (PST) Received: from dhcp89-089-161.bbn.com ([128.89.89.161]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NSuwB-0001LJ-A8; Thu, 07 Jan 2010 11:10:15 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <47FF8C26716A4E45993305F326EFE4A20191D9@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018D15@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20191D9@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> Date: Thu, 7 Jan 2010 11:10:12 -0500 To: Brian Swander From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" , Russ Housley , gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 16:10:18 -0000 At 10:17 PM +0000 1/6/10, Brian Swander wrote: >I trust that this is a question on the sample set of requirements >for the scenario I sent to Paul. > >I use infrastructure and intermediaries terms interchangeably. > >The scenario I had in mind is: > >No heuristic support from any network infrastructure. > >Only limited number of legacy clients that require encryption, hence >they are capable of upgrading. >Vast majority of legacy are ok with ESP-NULL. > >Potentially many uplevel clients that require encryption. As on >the previous thread, we want to enable as many capabilities in the >cross product matrix as possible. Hence it is extremely desirable >for uplevel to do encryption or integrity without forcing extra >infrastructure config. > > I.e. I'd assume that managing ip addresses on all uplevel machines >that want to do encryption is prohibitive. Color me confused. It appears that the high level policy is: - pairs of "uplevel" (WESP-capable) machines are allowed to send data via encrypted SAs, and thus bypass the packet inspection that the intermediate systems would otherwise perform - if either machine in a communicating pair is not "uplevel" then any SAs between them must be subject to inspection by the intermediate systems, and hence they are restricted to using ESP-NULL (or no IPsec at all). What confuses me is how the intermediate systems will know which policy applies to any given traffic flow? If the intermediate systems have a list of IP addresses of the hosts that fall into the category of "allowed to encrypt traffic" that would work, but that approach relies on doing what you said would be prohibitive to manage. Even if one needs only to configure one of the addresses or authorized pairs, that is the same as what would be needed in my proposal, and thus is also viewed as too hard to manage. But what other means of informing the intermediate systems how to decide to treat these two different classes of traffic do you envision? I hope that you're not suggesting that the answer is to rely on each node to behave properly and to use only the type of SA for which it is authorized. If we had sufficient confidence in these nodes to do that, we probably wouldn't need intermediate systems to perform packet inspection, right? Steve From ken.grewal@intel.com Thu Jan 7 09:11:31 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 322033A68B7 for ; Thu, 7 Jan 2010 09:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXPoM1q8fZjw for ; Thu, 7 Jan 2010 09:11:29 -0800 (PST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by core3.amsl.com (Postfix) with ESMTP id 59F9B3A67FA for ; Thu, 7 Jan 2010 09:11:29 -0800 (PST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 07 Jan 2010 09:10:45 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.49,236,1262592000"; d="scan'208";a="482158617" Received: from rrsmsx603.amr.corp.intel.com ([10.31.0.57]) by orsmga002.jf.intel.com with ESMTP; 07 Jan 2010 09:10:46 -0800 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx603.amr.corp.intel.com ([10.31.0.57]) with mapi; Thu, 7 Jan 2010 10:10:50 -0700 From: "Grewal, Ken" To: Yaron Sheffer , "latten@austin.ibm.com" Date: Thu, 7 Jan 2010 10:09:34 -0700 Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AcqPML75TOxKvXW/QT+x8kaItYSe/QAYSwqQAAqG3MA= Message-ID: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018D15@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <1262823361.2717.569.camel@faith.austin.ibm.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C5160@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C5160@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 17:11:31 -0000 Thanks for the clarification Yaron. My answer was incomplete, as I had just picked up on the last statement. Thanks,=20 - Ken =20 >-----Original Message----- >From: Yaron Sheffer [mailto:yaronf@checkpoint.com] >Sent: Thursday, January 07, 2010 4:08 AM >To: latten@austin.ibm.com; Grewal, Ken >Cc: ipsec@ietf.org >Subject: RE: [IPsec] Traffic visibility - consensus call > >Hi Joy, > >Sorry but this is not the case. Quoting your text below: "The use of the >"USE_WESP_MODE" for IKEv2 as indicated in the draft guarantees that >WESP-capable nodes only use ESP for encryption and WESP for ESP-NULL." > >This is incorrect: proponents of the encryption flag would have the >WESP-capable devices use WESP for *both* encrypted and ESP-null traffic. > >And as you say, intermediaries would then be able to distinguish both >kinds of traffic using the encryption flag in the WEPS header. > >Thanks, > Yaron > >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >Of Joy Latten >Sent: Thursday, January 07, 2010 2:16 >To: Grewal, Ken >Cc: ipsec@ietf.org >Subject: Re: [IPsec] Traffic visibility - consensus call > >On Wed, 2010-01-06 at 15:42 -0700, Grewal, Ken wrote: >> Paul, >> >> messages on this topic! :-)> >> >> My 2 cents... >> >> Some people have jumped to conclusions that because we want to >differentiate between encrypted and non-encrypted traffic by explicitly >signaling in the packet, that WESP is now a replacement for ESP. >> >> THIS IS NOT THE CASE AND IT WAS NEVER THE INTENT! >> >> One item that may have led to this conclusion was the expanded ICV >over WESP, but this was introduced as a mitigation for certain threats >highlighted in the WG. Subsequent discussions have determined that it >would be better to mitigate these treats in an alternative manner, so we >can fall back to WESP being a wrapper for ESP, without the expanded ICV. >Wrapped ESP provides a wrapper for ESP! >> >> The other item for discussion is whether WESP needs to explicitly >differentiate between the payload being encrypted or NULL - I think this >is a valid point to discuss. >> >> Numerous threads have talked about policy based deployments, mixed >mode environments, migration paths, using/not using heuristics, etc... >> >> The bottom line is that in order for a network appliance (Trusted >Intermediary) to offer critical network services (IDS/IPS/DPI/Access >Control) in IPsec environments, it needs to know if a given IPsec packet >is encrypted or not in a deterministic manner and this is within scope. >> WESP is offering this determination on a per packet basis. >> >> I think we all agree that the traffic patterns will not fall into one >single category (NULL OR Encrypted) within an Enterprise environment. >i.e. There will be some traffic that is encrypted and some using NULL >encryption. >> >> Some argue that we should use WESP for NULL traffic, mandating ESP for >encrypted traffic...AND ensure that ESP is NEVER used for NULL >encryption within a given domain / environment. How does an intermediate >device know that this policy is being enforced? What if ESP is still >being used for ESP-NULL and encrypted traffic? If this is the case, we >are back to where we were/are today - no way to tell if ESP payload is >encrypted or not. >> >> Having the encrypted flag within WESP allows clear and explicit >distinction that certain traffic is encrypted whereas other traffic is >not. This preserves the network based services we rely on and also >allows other access control policies to be enforced. E.g. I want to >ensure that my finance data flowing in the network is encrypted and NOT >using ESP-NULL. If I rely on ESP for encrypted data and it can still use >NULL encryption, I cannot enforce such a policy from an access control >tool. >> >Ok. Thanks, for the clarity. I had read the latest draft and had been >following the thread but wasn't clear on the justification of needing >the encryption flag in WESP. > >So for my own understanding... the use of the "USE_WESP_MODE" for IKEv2 >as indicated in the draft guarantees that WESP-capable nodes only use >ESP for encryption and WESP for ESP-NULL. My thinking is, the SA created >will somehow indicate this "USE-WESP-MODE" and thus guarantee that the >packets on the SA enforce this policy, right? However, this is on the >end node, not the intermediate device. And it is the intermediate device >we want to give the guarantee to... especially in a mixed-environment... >And the WESP header, with an encryption flag indicating encrypted or >not, supplies this guarantee to the device. Am I understanding this >correctly or missing something or not even in the ballpark? > >If I have understood correctly, then in reference to Yaron's email, I >vote: > >>>- The current draft >>>(http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11) >>>defines the ESP trailer's ICV calculation to include the WESP header. >>>This has been done to counter certain attacks, but it means that WESP >>>is no longer a simple wrapper around ESP - ESP itself is modified. Do >>>you support this design decision? > >No. Go back to WESP as a wrapper for ESP. > >>>- The current draft allows WESP to be applied to encrypted ESP flows, >>>in addition to the originally specified ESP-null. This was intended so >>>that encrypted flows can benefit from the future extensibility offered >>>by WESP. But arguably, it positions WESP as an alternative to ESP. Do >>>you support this design decision? > >Yes. > >regards, >Joy > > >> Bottom line is that having this 'encryption' flag in WESP provides the >capability to deterministically provide and preserve critical network >services in IPsec environments, as well as apply access control >policies. Without it, we are back to half-baked solutions. >> >> As others have quoted the charter, here it is again... >> >> "A standards-track mechanism that allows an intermediary device, such >> as a firewall or intrusion detection system, to easily and reliably >> determine whether an ESP packet is encrypted with the NULL cipher; and >> if it is, determine the location of the actual payload data inside the >> packet." >> >> If we say that WESP is ONLY used to carry ESP-NULL (and ESP is used to >carry encrypted traffic, but based on the ESP spec and legacy, it may >also carry ESP-NULL), then we have not completed what we set out to do, >as we have failed to *reliably* determine if the ESP traffic is >encrypted or not! >> >> Again, WESP does not replace ESP. It offers what it set out to do - an >easy and reliable way to tell if an IPsec packet has a NULL payload or >if it is encrypted. >> >> Thanks, >> - Ken >> >> >> >-----Original Message----- >> >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >Behalf >> >Of Paul Koning >> >Sent: Wednesday, January 06, 2010 1:43 PM >> >To: Stephen Kent >> >Cc: ipsec@ietf.org >> >Subject: Re: [IPsec] Traffic visibility - consensus call >> > >> >I've been watching a long stream of messages about WESP flying by and >I >> >must admit to being rather confused. What follows is based on my >best >> >understanding of what's going on, so please apply grains of salt as >> >needed. >> > >> >It's likely that I'm in the same corner as Tero. >> > >> >It sounds to me like WESP was chartered to do something very >specific, >> >having to do with ESP-NULL and intermediate systems looking at >traffic. >> >And now we have discussions about ESP-nonNULL with WESP, and maybe >WESP >> >as an alternative to ESP, or a replacement to ESP. >> > >> >How is this possible? It's nice to talk about the benefits of >greater >> >generality and all that, but it isn't proper to have a WG chartered >to >> >do a narrow thing and then end up doing something much bigger. >> > >> >Why not? >> > >> >Answer: the purpose of a charter is (a) to tell the WG what it should >be >> >doing, (b) to tell observers whether the work of the WG is something >> >they need to track -- or do NOT need to track. >> > >> >If a WG goes well outside its charter, that's not fair to those who >> >would have participated if the charter had said this, but ended up >not >> >participating because the charter told them they did not need to. >From >> >what I understand from Tero's comments, that situation applies to >him, >> >and I think it applies to me as well. >> > >> >It may well be a good idea to expand or modify or generalize or >replace >> >ESP, but if such a project is to be done, it should be done by a WG >> >chartered for that purpose, so that all interested parties are on >notice >> >that this work is about to happen. >> > >> >Meanwhile, as to the consensus call: if this is out of charter as it >> >appears to be, then, independent of its technical merit, my vote is >NO. >> > >> > paul koning >> >_______________________________________________ >> >IPsec mailing list >> >IPsec@ietf.org >> >https://www.ietf.org/mailman/listinfo/ipsec >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec > >Scanned by Check Point Total Security Gateway. From briansw@microsoft.com Thu Jan 7 09:14:28 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FDD23A68D7 for ; Thu, 7 Jan 2010 09:14:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4y+qdSZJq9P for ; Thu, 7 Jan 2010 09:14:26 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id B7A0B3A68D9 for ; Thu, 7 Jan 2010 09:14:17 -0800 (PST) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 7 Jan 2010 09:14:54 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.0.639.20; Thu, 7 Jan 2010 09:13:52 -0800 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.27]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Thu, 7 Jan 2010 09:13:52 -0800 From: Brian Swander To: Stephen Kent Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AQHKjwjDFMfT79gUNESgtZlfXT4hYpGJDETfgAE9ml2AAA7M8A== Date: Thu, 7 Jan 2010 17:13:51 +0000 Message-ID: <47FF8C26716A4E45993305F326EFE4A201982B@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018D15@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20191D9@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Russ Housley , gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 17:14:28 -0000 In this scenario, the sum of functionality is greater than the parts - end = hosts and intermediaries working together can achieve better overall securi= ty than either working in isolation and in complete distrust of the other. It'll be up to the individual customer on where to dial the knobs, and we s= hould enable the options and make them as deployable as possible. I.e. if = customers really want to manage full IP address policies for who can do enc= rypted ESP, than that option should be available. If they want good inter= mediary audit trails with a simpler intermediary config, that option needs = to be available. If they want best effort load balancing/WAN optimization,= that option needs to be available. This is no longer an either-or adversarial situation between end systems an= d intermediaries, and the intermediaries in play are not relegated to secur= ity intermediaries - although clearly security intermediaries are important= here, too. bs -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Thursday, January 07, 2010 8:10 AM To: Brian Swander Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call At 10:17 PM +0000 1/6/10, Brian Swander wrote: >I trust that this is a question on the sample set of requirements=20 >for the scenario I sent to Paul. > >I use infrastructure and intermediaries terms interchangeably. > >The scenario I had in mind is: > >No heuristic support from any network infrastructure. > >Only limited number of legacy clients that require encryption, hence=20 >they are capable of upgrading. >Vast majority of legacy are ok with ESP-NULL. > >Potentially many uplevel clients that require encryption. As on=20 >the previous thread, we want to enable as many capabilities in the=20 >cross product matrix as possible. Hence it is extremely desirable=20 >for uplevel to do encryption or integrity without forcing extra=20 >infrastructure config. > > I.e. I'd assume that managing ip addresses on all uplevel machines=20 >that want to do encryption is prohibitive. Color me confused. It appears that the high level policy is: - pairs of "uplevel" (WESP-capable) machines are allowed to=20 send data via encrypted SAs, and thus bypass the packet inspection=20 that the intermediate systems would otherwise perform - if either machine in a communicating pair is not "uplevel"=20 then any SAs between them must be subject to inspection by the=20 intermediate systems, and hence they are restricted to using ESP-NULL=20 (or no IPsec at all). What confuses me is how the intermediate systems will know which=20 policy applies to any given traffic flow? If the intermediate systems=20 have a list of IP addresses of the hosts that fall into the category=20 of "allowed to encrypt traffic" that would work, but that approach=20 relies on doing what you said would be prohibitive to manage. Even if=20 one needs only to configure one of the addresses or authorized pairs,=20 that is the same as what would be needed in my proposal, and thus is=20 also viewed as too hard to manage. But what other means of informing=20 the intermediate systems how to decide to treat these two different=20 classes of traffic do you envision? I hope that you're not suggesting that the answer is to rely on each=20 node to behave properly and to use only the type of SA for which it=20 is authorized. If we had sufficient confidence in these nodes to do=20 that, we probably wouldn't need intermediate systems to perform=20 packet inspection, right? Steve From briansw@microsoft.com Thu Jan 7 09:17:41 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 649DD28C0CF for ; Thu, 7 Jan 2010 09:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YR1qSCHkwHOD for ; Thu, 7 Jan 2010 09:17:40 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 2D5C028B23E for ; Thu, 7 Jan 2010 09:17:40 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 7 Jan 2010 09:18:18 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.0.639.20; Thu, 7 Jan 2010 09:17:38 -0800 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.27]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Thu, 7 Jan 2010 09:17:39 -0800 From: Brian Swander To: Stephen Kent Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AQHKjwjDFMfT79gUNESgtZlfXT4hYpGJDETfgAE9ml2AAA7M8IAAAyEg Date: Thu, 7 Jan 2010 17:17:38 +0000 Message-ID: <47FF8C26716A4E45993305F326EFE4A2019843@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018D15@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20191D9@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Russ Housley , gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 17:17:41 -0000 Slight rewording of the first sentence for more clarity: In this scenario, the sum of functionality is greater than the parts - end = hosts and intermediaries working together can better satisfy the customer's= holistic deployment requirements (security, load balancing, auditing, etc)= than either working in isolation and in complete distrust of the other. -----Original Message----- From: Brian Swander=20 Sent: Thursday, January 07, 2010 9:14 AM To: 'Stephen Kent' Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro Subject: RE: [IPsec] Traffic visibility - consensus call In this scenario, the sum of functionality is greater than the parts - end = hosts and intermediaries working together can achieve better overall securi= ty than either working in isolation and in complete distrust of the other. It'll be up to the individual customer on where to dial the knobs, and we s= hould enable the options and make them as deployable as possible. I.e. if = customers really want to manage full IP address policies for who can do enc= rypted ESP, than that option should be available. If they want good inter= mediary audit trails with a simpler intermediary config, that option needs = to be available. If they want best effort load balancing/WAN optimization,= that option needs to be available. This is no longer an either-or adversarial situation between end systems an= d intermediaries, and the intermediaries in play are not relegated to secur= ity intermediaries - although clearly security intermediaries are important= here, too. bs -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Thursday, January 07, 2010 8:10 AM To: Brian Swander Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call At 10:17 PM +0000 1/6/10, Brian Swander wrote: >I trust that this is a question on the sample set of requirements=20 >for the scenario I sent to Paul. > >I use infrastructure and intermediaries terms interchangeably. > >The scenario I had in mind is: > >No heuristic support from any network infrastructure. > >Only limited number of legacy clients that require encryption, hence=20 >they are capable of upgrading. >Vast majority of legacy are ok with ESP-NULL. > >Potentially many uplevel clients that require encryption. As on=20 >the previous thread, we want to enable as many capabilities in the=20 >cross product matrix as possible. Hence it is extremely desirable=20 >for uplevel to do encryption or integrity without forcing extra=20 >infrastructure config. > > I.e. I'd assume that managing ip addresses on all uplevel machines=20 >that want to do encryption is prohibitive. Color me confused. It appears that the high level policy is: - pairs of "uplevel" (WESP-capable) machines are allowed to=20 send data via encrypted SAs, and thus bypass the packet inspection=20 that the intermediate systems would otherwise perform - if either machine in a communicating pair is not "uplevel"=20 then any SAs between them must be subject to inspection by the=20 intermediate systems, and hence they are restricted to using ESP-NULL=20 (or no IPsec at all). What confuses me is how the intermediate systems will know which=20 policy applies to any given traffic flow? If the intermediate systems=20 have a list of IP addresses of the hosts that fall into the category=20 of "allowed to encrypt traffic" that would work, but that approach=20 relies on doing what you said would be prohibitive to manage. Even if=20 one needs only to configure one of the addresses or authorized pairs,=20 that is the same as what would be needed in my proposal, and thus is=20 also viewed as too hard to manage. But what other means of informing=20 the intermediate systems how to decide to treat these two different=20 classes of traffic do you envision? I hope that you're not suggesting that the answer is to rely on each=20 node to behave properly and to use only the type of SA for which it=20 is authorized. If we had sufficient confidence in these nodes to do=20 that, we probably wouldn't need intermediate systems to perform=20 packet inspection, right? Steve From dharkins@lounge.org Thu Jan 7 09:56:59 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E33263A68C0 for ; Thu, 7 Jan 2010 09:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkMCUGcp81ZY for ; Thu, 7 Jan 2010 09:56:58 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id D1EED3A68A6 for ; Thu, 7 Jan 2010 09:56:58 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 2CB59A88812E; Thu, 7 Jan 2010 09:56:57 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 7 Jan 2010 09:56:57 -0800 (PST) Message-ID: <55d9618ca48e1b5733c23f7554834395.squirrel@www.trepanning.net> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C516D@il-ex01.ad.checkpoint.co m> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com><7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com><378834.93787.qm@web82602.mail.mud.yahoo.com><4B43AAF7.8030302@vigilsec.com><734514.64270.qm@web82604.mail.mud.yahoo.com><5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018D15@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C516D@il-ex01.ad.checkpoint.com> Date: Thu, 7 Jan 2010 09:56:57 -0800 (PST) From: "Dan Harkins" To: "Yaron Sheffer" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 17:57:00 -0000 Hi Yaron, Yes, one way was chosen but it has morphed into something much more than simply indicating ESP-null traffic. What I'm suggesting is that if the goal is simply a good way to indicate ESP-null traffic then doing just that is possible with a NAT-friendly version of AH. It's much cleaner than WESP. How do I indicate encrypted ESP? Well, as I mentioned, it is the only traffic using ESP in the network for which traffic visibility is required. The middleboxes looking into these packets must be in the same policy domain as the end systems that are producing the protected traffic. That being the case you just disallow ESP-null _by policy_ on that network. Then any traffic on the network that is ESP is encrypted and the protected-but-inspectable traffic is the NAT-friendly version of AH. Voila! We can now distinguish between encrypted and non-encrypted traffic and we can inspect traffic that is merely integrity protected. Dan. P.S. ESP is a protocol which has the ability to use or not use any number of ciphers. I don't think deprecating a cipher (even the NULL cipher) is a "change" to ESP. It doesn't change the protocol the way changing a header format or redefining ICV calculations changes the protocol. But I'm not proposing deprecating ESP-null and that really has nothing to do with the topic of a NAT-friendly version of AH as a solution to the problem that WESP claims it is solving. On Thu, January 7, 2010 4:19 am, Yaron Sheffer wrote: > Hi Dan, > > There are multiple good ways to indicate ESP-null traffic. We just chose > one option. > > But (assuming you strongly dislike heuristics, which some of us do) the > big question is how to indicate *encrypted* ESP. Deprecating ESP-null is a > non-starter: it is "changing ESP" just like changing the header format, > and even more so, because it is a practically invisible change. > > Thanks, > Yaron > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Dan Harkins > Sent: Thursday, January 07, 2010 2:04 > To: Grewal, Ken > Cc: ipsec@ietf.org; Paul Koning; Stephen Kent > Subject: Re: [IPsec] Traffic visibility - consensus call > > > Hi Ken, > > No one responded to my suggestion so I'll suggest it again below. > > On Wed, January 6, 2010 2:42 pm, Grewal, Ken wrote: > [snip] >> The bottom line is that in order for a network appliance (Trusted >> Intermediary) to offer critical network services (IDS/IPS/DPI/Access >> Control) in IPsec environments, it needs to know if a given IPsec packet >> is encrypted or not in a deterministic manner and this is within scope. >> WESP is offering this determination on a per packet basis. > > That is a clear definition of the problem: a TI must be able to > determine whether a given IPsec packet is encrypted or not. > > [snip] >> Some argue that we should use WESP for NULL traffic, mandating ESP for >> encrypted traffic...AND ensure that ESP is NEVER used for NULL >> encryption >> within a given domain / environment. How does an intermediate device >> know >> that this policy is being enforced? What if ESP is still being used for >> ESP-NULL and encrypted traffic? If this is the case, we are back to >> where >> we were/are today - no way to tell if ESP payload is encrypted or not. > > The intermediate device knows this because it is under the same > policy domain as the endpoints that have agreed to do WESP. If he's not > in the same policy domain then he has no assurance that the endpoints > will do WESP anyway. Maybe they'll do ESP and maybe even use the NULL > cipher, so this box in the cloud is out-of-luck again and WESP doesn't > help. Unless, of course, WESP is really a trojan horse to deprecate ESP > and force everyone to use WESP always but you have said that's not the > case. > > So now my suggestion again. If you're going to specify a new protocol > and require endpoints to implement it then why not just make a new > IPsec protocol that is a NAT-friendly way of doing per-packet integrity > protection? Don't try to "wrap" ESP packets. That way the middlebox knows > that when it sees this new protocol that it is not encrypted and when it > sees ESP it knows it is encrypted (it knows that ESP is not using NULL > encryption because policy has disallowed that). We could even think about > deprecating ESP-NULL in favor of this new protocol. This would be an > architecturally cleaner way of solving the problem you clearly described > above. IKE can negotiate the new protocol, in transport- or tunnel-mode, > negotiate an algorithm to use to provide integrity protection, and > establish an authenticated and shared key to use with the algorithm. So > what's the problem with this suggestion? > > regards, > > Dan. > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. > From kent@bbn.com Thu Jan 7 11:09:11 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 609E73A68CE for ; Thu, 7 Jan 2010 11:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bodjZBXzRZJv for ; Thu, 7 Jan 2010 11:09:10 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 7D49428C1B8 for ; Thu, 7 Jan 2010 11:09:06 -0800 (PST) Received: from dhcp89-089-161.bbn.com ([128.89.89.161]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NSxjE-0005hy-AR; Thu, 07 Jan 2010 14:09:04 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <47FF8C26716A4E45993305F326EFE4A201982B@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018D15@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20191D9@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A201982B@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> Date: Thu, 7 Jan 2010 14:09:01 -0500 To: Brian Swander From: Stephen Kent Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Cc: "ipsec@ietf.org" , Russ Housley Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 19:09:11 -0000 At 5:13 PM +0000 1/7/10, Brian Swander wrote: >In this scenario, the sum of functionality is=20 >greater than the parts - end hosts and=20 >intermediaries working together can achieve=20 >better overall security than either working in=20 >isolation and in complete distrust of the other. > >It'll be up to the individual customer on where=20 >to dial the knobs, and we should enable the=20 >options and make them as deployable as possible.=20 >I.e. if customers really want to manage full IP=20 >address policies for who can do encrypted ESP,=20 >than that option should be available. If they=20 >want good intermediary audit trails with a=20 >simpler intermediary config, that option needs=20 >to be available. If they want best effort load=20 >balancing/WAN optimization, that option needs to=20 >be available. > >This is no longer an either-or adversarial=20 >situation between end systems and=20 >intermediaries, and the intermediaries in play=20 >are not relegated to security intermediaries -=20 >although clearly security intermediaries are=20 >important here, too. > >bs Brian, I was really hoping for a simple answer to the=20 questions I posed in my message. Instead IO got a=20 message with words like "holistic" and phrases=20 like "the sum of functionality is greater than=20 the parts=8A" which is a bit too new age for me :. I'm guessing that hints to the answer I was=20 looking for are lurking in your second paragraph: >It'll be up to the individual customer on where=20 >to dial the knobs, and we should enable the=20 >options and make them as deployable as possible.=20 >I.e. if customers really want to manage full IP=20 >address policies for who can do encrypted ESP,=20 >than that option should be available. If they=20 >want good intermediary audit trails with a=20 >simpler intermediary config, that option needs=20 >to be available. If they want best effort load=20 >balancing/WAN optimization, that option needs to=20 >be available. In interpret this to mean that yes, you realize=20 that an intermediate system that wants to enforce=20 the sort of policies you previously described=20 would, in fact, have to be configured with IP=20 address info (or its moral equivalent) in order=20 to enforce such policies. In this case your=20 argument against my suggested approach to dealing=20 with incremental deployment of WESP disappears=20 (which may be why you chose to not make this=20 statement directly :)). You seem to offer an alternative, i.e., to give=20 customers the ability to have intermediaries=20 inspect or not inspect traffic based solely on=20 what the traffic labels indicate. This amounts=20 trusting the hosts to label traffic properly,=20 which is the alternative answer I postulated and=20 criticized. Again, you chose not to answer this=20 directly, but instead alluded (in your last=20 paragraph) to the need to think of end systems=20 and intermediaries as no longer operating in an=20 adversarial environment. Historically, the=20 principle motivations for security intermediaries=20 include countering (security relevant)=20 misconfiguration of hosts, an inability to manage=20 the (security relevant) configurations of hosts,=20 dealing with compromise of hosts, etc. These are=20 all instances where the intermediaries do not=20 trust the end systems. Please elaborate on why=20 you believe that these are now outmoded reasons=20 for how security intermediaries should relate to=20 hosts. You describe allowing intermediaries to generate=20 audit trails (presumably capturing some info=20 about the encrypted traffic that they were unable=20 to inspect, but you didn't say specifically) as=20 an alternative to policy enforcement. There may=20 be some merit to this in some contexts, but I=20 think the WG needs to have a clear picture of=20 what is being proposed and the associated=20 rationale. I searched the IPSECME archives and=20 found only one set of messages inn 2009 that=20 include the word "audit" in the context of this=20 discussion. These messages were a thread=20 involving Ken and Tero, and appeared in the=20 2/4-11 timeframe. The messages focused on the=20 performance and cost issues associated with=20 implementing stateful vs. stateless=20 intermediaries, as part of the larger debate on=20 heuristics vs. explicit packet labeling. This=20 thread did not raise the issue you did above,=20 i.e., that a major motivation for WESP is to=20 enable users to "audit" encrypted traffic flows=20 as an alternative to using access control info to=20 permit/deny such flows. I don't think the WG should make major design=20 decisions without a clear picture of the various=20 use cases that are being cited, but which lack=20 detailed descriptions and thoroughly-articulated=20 assumptions. I think the WG needs such=20 descriptions and associated analysis to guide its=20 decisions. Steve From kent@bbn.com Thu Jan 7 11:09:12 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F30753A68CE for ; Thu, 7 Jan 2010 11:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FP6lrKuolIlE for ; Thu, 7 Jan 2010 11:09:11 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 5942F3A684F for ; Thu, 7 Jan 2010 11:09:07 -0800 (PST) Received: from dhcp89-089-161.bbn.com ([128.89.89.161]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NSxjE-0005hy-C6 for ipsec@ietf.org; Thu, 07 Jan 2010 14:09:04 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com><7 F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com><378834 .93787.qm@web82602.mail.mud.yahoo.com><4B43AAF7.8030302@vigilsec.com><7345 14.64270.qm@web82604.mail.mud.yahoo.com><5E38DBF64E732C4C98512C53E1B14DDC2 99B8B20@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188 CE@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018A 04@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018D 15@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Date: Thu, 7 Jan 2010 13:43:39 -0500 To: ipsec@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [IPsec] Traffic visibility - what are the assumptions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 19:09:12 -0000 Folks, In discussing how intermediaries can perform packet inspection in the context of mixed deployments (WESP-capabale and legacy hosts) there seems to be a lack of detail re assumptions. This came to light in my questions to Brian this morning. So, just to clarify the discussion, I'd like to hear from folks what information about hosts they presume an intermediary has available, and how that affects how the intermediary operates. It probably will help if we distinguish among different types of intermediaries, e.g., firewall-like devices, IDS-style devices, load balancing devices, etc. My goal is to ensure that we all are using the same set of underlying assumptions when we discuss how things operate, and thus why different approaches to labelling packets are more or less desirable. Thanks, Steve From briansw@microsoft.com Thu Jan 7 12:06:39 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D8C028C101 for ; Thu, 7 Jan 2010 12:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u97h8DPO02zK for ; Thu, 7 Jan 2010 12:06:38 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 426A83A6923 for ; Thu, 7 Jan 2010 12:06:38 -0800 (PST) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 7 Jan 2010 12:07:16 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.0.639.20; Thu, 7 Jan 2010 12:06:24 -0800 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.27]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Thu, 7 Jan 2010 12:06:23 -0800 From: Brian Swander To: Stephen Kent Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AQHKjwjDFMfT79gUNESgtZlfXT4hYpGJDETfgAE9ml2AADJuaYAADcCA Date: Thu, 7 Jan 2010 20:06:20 +0000 Message-ID: <47FF8C26716A4E45993305F326EFE4A20199F1@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018D15@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20191D9@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A201982B@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Russ Housley Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 20:06:39 -0000 I'm going by what my real customers are asking for.=20 Our real customers are asking for exactly what I'm describing below. I di= dn't ask them why their stance to intermediaries has changed, if it even ha= s. That is academic. The key question here is what do real customers want= to deploy, and how can we enable them to do it. bs -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Thursday, January 07, 2010 11:09 AM To: Brian Swander Cc: ipsec@ietf.org; Russ Housley Subject: RE: [IPsec] Traffic visibility - consensus call At 5:13 PM +0000 1/7/10, Brian Swander wrote: >In this scenario, the sum of functionality is=20 >greater than the parts - end hosts and=20 >intermediaries working together can achieve=20 >better overall security than either working in=20 >isolation and in complete distrust of the other. > >It'll be up to the individual customer on where=20 >to dial the knobs, and we should enable the=20 >options and make them as deployable as possible.=20 >I.e. if customers really want to manage full IP=20 >address policies for who can do encrypted ESP,=20 >than that option should be available. If they=20 >want good intermediary audit trails with a=20 >simpler intermediary config, that option needs=20 >to be available. If they want best effort load=20 >balancing/WAN optimization, that option needs to=20 >be available. > >This is no longer an either-or adversarial=20 >situation between end systems and=20 >intermediaries, and the intermediaries in play=20 >are not relegated to security intermediaries -=20 >although clearly security intermediaries are=20 >important here, too. > >bs Brian, I was really hoping for a simple answer to the=20 questions I posed in my message. Instead IO got a=20 message with words like "holistic" and phrases=20 like "the sum of functionality is greater than=20 the parts=A9" which is a bit too new age for me :. I'm guessing that hints to the answer I was=20 looking for are lurking in your second paragraph: >It'll be up to the individual customer on where=20 >to dial the knobs, and we should enable the=20 >options and make them as deployable as possible.=20 >I.e. if customers really want to manage full IP=20 >address policies for who can do encrypted ESP,=20 >than that option should be available. If they=20 >want good intermediary audit trails with a=20 >simpler intermediary config, that option needs=20 >to be available. If they want best effort load=20 >balancing/WAN optimization, that option needs to=20 >be available. In interpret this to mean that yes, you realize=20 that an intermediate system that wants to enforce=20 the sort of policies you previously described=20 would, in fact, have to be configured with IP=20 address info (or its moral equivalent) in order=20 to enforce such policies. In this case your=20 argument against my suggested approach to dealing=20 with incremental deployment of WESP disappears=20 (which may be why you chose to not make this=20 statement directly :)). You seem to offer an alternative, i.e., to give=20 customers the ability to have intermediaries=20 inspect or not inspect traffic based solely on=20 what the traffic labels indicate. This amounts=20 trusting the hosts to label traffic properly,=20 which is the alternative answer I postulated and=20 criticized. Again, you chose not to answer this=20 directly, but instead alluded (in your last=20 paragraph) to the need to think of end systems=20 and intermediaries as no longer operating in an=20 adversarial environment. Historically, the=20 principle motivations for security intermediaries=20 include countering (security relevant)=20 misconfiguration of hosts, an inability to manage=20 the (security relevant) configurations of hosts,=20 dealing with compromise of hosts, etc. These are=20 all instances where the intermediaries do not=20 trust the end systems. Please elaborate on why=20 you believe that these are now outmoded reasons=20 for how security intermediaries should relate to=20 hosts. You describe allowing intermediaries to generate=20 audit trails (presumably capturing some info=20 about the encrypted traffic that they were unable=20 to inspect, but you didn't say specifically) as=20 an alternative to policy enforcement. There may=20 be some merit to this in some contexts, but I=20 think the WG needs to have a clear picture of=20 what is being proposed and the associated=20 rationale. I searched the IPSECME archives and=20 found only one set of messages inn 2009 that=20 include the word "audit" in the context of this=20 discussion. These messages were a thread=20 involving Ken and Tero, and appeared in the=20 2/4-11 timeframe. The messages focused on the=20 performance and cost issues associated with=20 implementing stateful vs. stateless=20 intermediaries, as part of the larger debate on=20 heuristics vs. explicit packet labeling. This=20 thread did not raise the issue you did above,=20 i.e., that a major motivation for WESP is to=20 enable users to "audit" encrypted traffic flows=20 as an alternative to using access control info to=20 permit/deny such flows. I don't think the WG should make major design=20 decisions without a clear picture of the various=20 use cases that are being cited, but which lack=20 detailed descriptions and thoroughly-articulated=20 assumptions. I think the WG needs such=20 descriptions and associated analysis to guide its=20 decisions.=20 Steve From yaronf@checkpoint.com Thu Jan 7 13:24:42 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0593E3A67A8 for ; Thu, 7 Jan 2010 13:24:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMJWMmHf+4r7 for ; Thu, 7 Jan 2010 13:24:40 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 814083A68B4 for ; Thu, 7 Jan 2010 13:24:40 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o07LObT7015074; Thu, 7 Jan 2010 23:24:37 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 7 Jan 2010 23:24:50 +0200 From: Yaron Sheffer To: Dan Harkins Date: Thu, 7 Jan 2010 23:24:44 +0200 Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AcqPwtitjIll+yJTS8SKZtvHleIKxQAG9ahA Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C51F1@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com><7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com><378834.93787.qm@web82602.mail.mud.yahoo.com><4B43AAF7.8030302@vigilsec.com><734514.64270.qm@web82604.mail.mud.yahoo.com><5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018D15@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C516D@il-ex01.ad.checkpoint.com> <55d9618ca48e1b5733c23f7554834395.squirrel@www.trepanning.net> In-Reply-To: <55d9618ca48e1b5733c23f7554834395.squirrel@www.trepanning.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 21:24:42 -0000 Hi Dan, [No hat. This is getting cold!] When I hear that "the network enforces a policy" I immediately think of the= exceptions: unmanaged machines (in the enterprise sense of the word), mach= ines with weird operating systems (that's "non Windows" to some of our part= icipants), outdated versions, machines that failed to be provisioned etc. So it is difficult to assume that *all* ESP is encrypted in any given netwo= rk. This may be OK, if you're willing to accept false positives (e.g. in a = load balancer). Or it may not be OK, if you have security decisions that de= pend on this distinction. And this is why a smooth migration is so important. Over time you get a lar= ger and larger portion of the network to play by the rules. Thanks, Yaron -----Original Message----- From: Dan Harkins [mailto:dharkins@lounge.org]=20 Sent: Thursday, January 07, 2010 19:57 To: Yaron Sheffer Cc: ipsec@ietf.org Subject: RE: [IPsec] Traffic visibility - consensus call Hi Yaron, Yes, one way was chosen but it has morphed into something much more than simply indicating ESP-null traffic. What I'm suggesting is that if the goal is simply a good way to indicate ESP-null traffic then doing just that is possible with a NAT-friendly version of AH. It's much cleaner than WESP. How do I indicate encrypted ESP? Well, as I mentioned, it is the only traffic using ESP in the network for which traffic visibility is required. The middleboxes looking into these packets must be in the same policy domain as the end systems that are producing the protected traffic. That being the case you just disallow ESP-null _by policy_ on that network. Then any traffic on the network that is ESP is encrypted and the protected-but-inspectable traffic is the NAT-friendly version of AH. Voila! We can now distinguish between encrypted and non-encrypted traffic and we can inspect traffic that is merely integrity protected. Dan. P.S. ESP is a protocol which has the ability to use or not use any number of ciphers. I don't think deprecating a cipher (even the NULL cipher) is a "change" to ESP. It doesn't change the protocol the way changing a header format or redefining ICV calculations changes the protocol. But I'm not proposing deprecating ESP-null and that really has nothing to do with the topic of a NAT-friendly version of AH as a solution to the problem that WESP claims it is solving. On Thu, January 7, 2010 4:19 am, Yaron Sheffer wrote: > Hi Dan, > > There are multiple good ways to indicate ESP-null traffic. We just chose > one option. > > But (assuming you strongly dislike heuristics, which some of us do) the > big question is how to indicate *encrypted* ESP. Deprecating ESP-null is = a > non-starter: it is "changing ESP" just like changing the header format, > and even more so, because it is a practically invisible change. > > Thanks, > Yaron > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Dan Harkins > Sent: Thursday, January 07, 2010 2:04 > To: Grewal, Ken > Cc: ipsec@ietf.org; Paul Koning; Stephen Kent > Subject: Re: [IPsec] Traffic visibility - consensus call > > > Hi Ken, > > No one responded to my suggestion so I'll suggest it again below. > > On Wed, January 6, 2010 2:42 pm, Grewal, Ken wrote: > [snip] >> The bottom line is that in order for a network appliance (Trusted >> Intermediary) to offer critical network services (IDS/IPS/DPI/Access >> Control) in IPsec environments, it needs to know if a given IPsec packet >> is encrypted or not in a deterministic manner and this is within scope. >> WESP is offering this determination on a per packet basis. > > That is a clear definition of the problem: a TI must be able to > determine whether a given IPsec packet is encrypted or not. > > [snip] >> Some argue that we should use WESP for NULL traffic, mandating ESP for >> encrypted traffic...AND ensure that ESP is NEVER used for NULL >> encryption >> within a given domain / environment. How does an intermediate device >> know >> that this policy is being enforced? What if ESP is still being used for >> ESP-NULL and encrypted traffic? If this is the case, we are back to >> where >> we were/are today - no way to tell if ESP payload is encrypted or not. > > The intermediate device knows this because it is under the same > policy domain as the endpoints that have agreed to do WESP. If he's not > in the same policy domain then he has no assurance that the endpoints > will do WESP anyway. Maybe they'll do ESP and maybe even use the NULL > cipher, so this box in the cloud is out-of-luck again and WESP doesn't > help. Unless, of course, WESP is really a trojan horse to deprecate ESP > and force everyone to use WESP always but you have said that's not the > case. > > So now my suggestion again. If you're going to specify a new protocol > and require endpoints to implement it then why not just make a new > IPsec protocol that is a NAT-friendly way of doing per-packet integrity > protection? Don't try to "wrap" ESP packets. That way the middlebox knows > that when it sees this new protocol that it is not encrypted and when it > sees ESP it knows it is encrypted (it knows that ESP is not using NULL > encryption because policy has disallowed that). We could even think about > deprecating ESP-NULL in favor of this new protocol. This would be an > architecturally cleaner way of solving the problem you clearly described > above. IKE can negotiate the new protocol, in transport- or tunnel-mode, > negotiate an algorithm to use to provide integrity protection, and > establish an authenticated and shared key to use with the algorithm. So > what's the problem with this suggestion? > > regards, > > Dan. > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. > Scanned by Check Point Total Security Gateway. From dharkins@lounge.org Thu Jan 7 13:51:03 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C5BF3A68C8 for ; Thu, 7 Jan 2010 13:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEOfzs-7c9-n for ; Thu, 7 Jan 2010 13:51:02 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 1C17F3A68C9 for ; Thu, 7 Jan 2010 13:51:02 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 8442DA88812E; Thu, 7 Jan 2010 13:51:00 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 7 Jan 2010 13:51:00 -0800 (PST) Message-ID: <702b230802fbbb0b7886245783e6538e.squirrel@www.trepanning.net> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C51F1@il-ex01.ad.checkpoint.co m> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com><7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com><378834.93787.qm@web82602.mail.mud.yahoo.com><4B43AAF7.8030302@vigilsec.com><734514.64270.qm@web82604.mail.mud.yahoo.com><5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C516D@il-ex01.ad.checkpoint.com> <55d9618ca48e1b5733c23f7554834395.squirrel@www.trepanning.net> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C51F1@il-ex01.ad.checkpoint.com> Date: Thu, 7 Jan 2010 13:51:00 -0800 (PST) From: "Dan Harkins" To: "Yaron Sheffer" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "ipsec@ietf.org" , Dan Harkins Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 21:51:03 -0000 Hi Yaron, [wearing a baseball cap from the "Working Man's Triathlon"!] These same "unmanaged machines" will cause problems for this new mutated form of WESP (wrapping both encrypted and unencrypted ESP). There is no way to assure that they will use WESP. Maybe they'll use ESP-null without WESP and then these middleboxes relying on WESP wrapped ESP to do their job are out-of-luck. So yes, these machines do pose a problem, but WESP doesn't fix that problem. Over time a larger and larger portion of the network will "play by the rules", as you say, but those rules could be: 1) use WESP to wrap all your ESP traffic, both encrypted and not encrypted; or 2) use ESP for encrypted traffic and for your unencrypted traffic. Aside from architectural cleanliness, another benefit of a NAT-friendly AH would be that the temptation for extensions and the consequential creep of new "requirements" (what WESP seems to be suffering from right now) would go away. We had a problem and the solution has morphed and succumed to temptation. That's the sign of a bad solution. Dan. On Thu, January 7, 2010 1:24 pm, Yaron Sheffer wrote: > Hi Dan, > > [No hat. This is getting cold!] > > When I hear that "the network enforces a policy" I immediately think of > the exceptions: unmanaged machines (in the enterprise sense of the word), > machines with weird operating systems (that's "non Windows" to some of our > participants), outdated versions, machines that failed to be provisioned > etc. > > So it is difficult to assume that *all* ESP is encrypted in any given > network. This may be OK, if you're willing to accept false positives (e.g. > in a load balancer). Or it may not be OK, if you have security decisions > that depend on this distinction. > > And this is why a smooth migration is so important. Over time you get a > larger and larger portion of the network to play by the rules. > > Thanks, > Yaron > > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: Thursday, January 07, 2010 19:57 > To: Yaron Sheffer > Cc: ipsec@ietf.org > Subject: RE: [IPsec] Traffic visibility - consensus call > > > Hi Yaron, > > Yes, one way was chosen but it has morphed into something much more > than simply indicating ESP-null traffic. What I'm suggesting is that if > the goal is simply a good way to indicate ESP-null traffic then doing > just that is possible with a NAT-friendly version of AH. It's much > cleaner than WESP. > > How do I indicate encrypted ESP? Well, as I mentioned, it is the only > traffic using ESP in the network for which traffic visibility is required. > The middleboxes looking into these packets must be in the same policy > domain as the end systems that are producing the protected traffic. That > being the case you just disallow ESP-null _by policy_ on that network. > Then any traffic on the network that is ESP is encrypted and the > protected-but-inspectable traffic is the NAT-friendly version of AH. > Voila! We can now distinguish between encrypted and non-encrypted traffic > and we can inspect traffic that is merely integrity protected. > > Dan. > > P.S. ESP is a protocol which has the ability to use or not use any number > of ciphers. I don't think deprecating a cipher (even the NULL cipher) is > a "change" to ESP. It doesn't change the protocol the way changing a > header format or redefining ICV calculations changes the protocol. But > I'm not proposing deprecating ESP-null and that really has nothing to do > with the topic of a NAT-friendly version of AH as a solution to the > problem that WESP claims it is solving. > > On Thu, January 7, 2010 4:19 am, Yaron Sheffer wrote: >> Hi Dan, >> >> There are multiple good ways to indicate ESP-null traffic. We just chose >> one option. >> >> But (assuming you strongly dislike heuristics, which some of us do) the >> big question is how to indicate *encrypted* ESP. Deprecating ESP-null is >> a >> non-starter: it is "changing ESP" just like changing the header format, >> and even more so, because it is a practically invisible change. >> >> Thanks, >> Yaron >> >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >> Of >> Dan Harkins >> Sent: Thursday, January 07, 2010 2:04 >> To: Grewal, Ken >> Cc: ipsec@ietf.org; Paul Koning; Stephen Kent >> Subject: Re: [IPsec] Traffic visibility - consensus call >> >> >> Hi Ken, >> >> No one responded to my suggestion so I'll suggest it again below. >> >> On Wed, January 6, 2010 2:42 pm, Grewal, Ken wrote: >> [snip] >>> The bottom line is that in order for a network appliance (Trusted >>> Intermediary) to offer critical network services (IDS/IPS/DPI/Access >>> Control) in IPsec environments, it needs to know if a given IPsec >>> packet >>> is encrypted or not in a deterministic manner and this is within scope. >>> WESP is offering this determination on a per packet basis. >> >> That is a clear definition of the problem: a TI must be able to >> determine whether a given IPsec packet is encrypted or not. >> >> [snip] >>> Some argue that we should use WESP for NULL traffic, mandating ESP for >>> encrypted traffic...AND ensure that ESP is NEVER used for NULL >>> encryption >>> within a given domain / environment. How does an intermediate device >>> know >>> that this policy is being enforced? What if ESP is still being used for >>> ESP-NULL and encrypted traffic? If this is the case, we are back to >>> where >>> we were/are today - no way to tell if ESP payload is encrypted or not. >> >> The intermediate device knows this because it is under the same >> policy domain as the endpoints that have agreed to do WESP. If he's not >> in the same policy domain then he has no assurance that the endpoints >> will do WESP anyway. Maybe they'll do ESP and maybe even use the NULL >> cipher, so this box in the cloud is out-of-luck again and WESP doesn't >> help. Unless, of course, WESP is really a trojan horse to deprecate ESP >> and force everyone to use WESP always but you have said that's not the >> case. >> >> So now my suggestion again. If you're going to specify a new protocol >> and require endpoints to implement it then why not just make a new >> IPsec protocol that is a NAT-friendly way of doing per-packet integrity >> protection? Don't try to "wrap" ESP packets. That way the middlebox >> knows >> that when it sees this new protocol that it is not encrypted and when it >> sees ESP it knows it is encrypted (it knows that ESP is not using NULL >> encryption because policy has disallowed that). We could even think >> about >> deprecating ESP-NULL in favor of this new protocol. This would be an >> architecturally cleaner way of solving the problem you clearly described >> above. IKE can negotiate the new protocol, in transport- or tunnel-mode, >> negotiate an algorithm to use to provide integrity protection, and >> establish an authenticated and shared key to use with the algorithm. So >> what's the problem with this suggestion? >> >> regards, >> >> Dan. >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> Scanned by Check Point Total Security Gateway. >> > > > > Scanned by Check Point Total Security Gateway. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From kent@bbn.com Thu Jan 7 15:41:16 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94C023A68BB for ; Thu, 7 Jan 2010 15:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5seJuVYxvhl for ; Thu, 7 Jan 2010 15:41:15 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id B914A3A68B4 for ; Thu, 7 Jan 2010 15:41:15 -0800 (PST) Received: from dhcp89-089-161.bbn.com ([128.89.89.161]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NT1yb-0002va-B1; Thu, 07 Jan 2010 18:41:13 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <47FF8C26716A4E45993305F326EFE4A20199F1@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018D15@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20191D9@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A201982B@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20199F1@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> Date: Thu, 7 Jan 2010 18:41:11 -0500 To: Brian Swander From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" , Russ Housley Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 23:41:16 -0000 At 8:06 PM +0000 1/7/10, Brian Swander wrote: >I'm going by what my real customers are asking for. > >Our real customers are asking for exactly what I'm describing below. >I didn't ask them why their stance to intermediaries has changed, if >it even has. That is academic. The key question here is what do >real customers want to deploy, and how can we enable them to do it. > >bs Brian, I don't know how IPSECME will choose to proceed, but in the WG I chair folks expect WG participants to provide technically defensible rationales for designs that they advocate. Relaying what customers purportedly have requested doesn't cut it. Also, the IETF does not assume that "the customer is always right" when making protocol design decisions. If we did, and if we made such decisions in 1990, we'd be using ATM, CLNP, X.400, and other protocols that many big clients said were what they wanted in that time frame :-). Steve From kohn.jack@gmail.com Thu Jan 7 15:54:30 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 663573A6864 for ; Thu, 7 Jan 2010 15:54:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnzbDOLMX+uN for ; Thu, 7 Jan 2010 15:54:29 -0800 (PST) Received: from mail-yw0-f196.google.com (mail-yw0-f196.google.com [209.85.211.196]) by core3.amsl.com (Postfix) with ESMTP id F1ABB3A6767 for ; Thu, 7 Jan 2010 15:54:28 -0800 (PST) Received: by ywh34 with SMTP id 34so12397012ywh.31 for ; Thu, 07 Jan 2010 15:54:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fUCtjuHDv25nTc8fbtudV/pbTlEGIwiuKm1ZAa4IwTc=; b=LZBUDyPFY7wWq1e+8EcT0eS5o2T8ezH5S7OG7r9C9e2LxK4h95Qc4QEcLMWxB3SRij EVqHATQFW9LMyIKCUuBE3z8v1rJAgRUzHxEVjWfqm0kr80cgCIRSTWUpMt9mAtey477S AL9W7kGC9z6hVhuvAVZqEN7P/aEeLmmdyRoDY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NCYZCUkLAqQJPQR8O6h0ddm322I/EMVgHlHLtbq+0A0s7eypxZWgY7EkF2lpVbK6dm 9pPrvp8Fbvy68GxrrnrfVeIX2mC3BzFEk3v18+FWrc9Umo+PlggjSK7U3CdWnvUyl2qs oEbjzz+2/6QUbdthvn6iiAQ4WODfWJWpBTdfs= MIME-Version: 1.0 Received: by 10.90.166.12 with SMTP id o12mr3590475age.110.1262908462108; Thu, 07 Jan 2010 15:54:22 -0800 (PST) In-Reply-To: <702b230802fbbb0b7886245783e6538e.squirrel@www.trepanning.net> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C516D@il-ex01.ad.checkpoint.com> <55d9618ca48e1b5733c23f7554834395.squirrel@www.trepanning.net> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C51F1@il-ex01.ad.checkpoint.com> <702b230802fbbb0b7886245783e6538e.squirrel@www.trepanning.net> Date: Fri, 8 Jan 2010 05:24:21 +0530 Message-ID: From: Jack Kohn To: Dan Harkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 23:54:30 -0000 Dan, As Yaron has already stated, there are multiple ways of detecting ESP-NULL packets and the WG chose one out of those. I remember an initial proposal (by Manav or Paul? not sure) where the author was using a reserved SPI value in the ESP to indicate all ESP-NULL packets. This was shot down by the WG citing extensibility reasons, and i agreed with them. I agreed, that if we do that then we will be able to differentiate between ESP-NULL and other ESP packets, but that'll be the end of the road, and there can be no further extensions done. Then WESP came along, which was patently extensible and people happily lapped it up. Now, folks are getting cold feet, saying that its too extensible and probably we shouldnt be having such a loose protocol thats so easily extensible. Lets leave it at marking ESP-NULL only and lets not have this do anything else. Similarly, as Charlie says, you might be proposing AH-lite, but by the time it reaches IESG it would have morphed into something much more complex than the AH-lite that you have in your mind right now! :) YMMV but I dont see WESP as a hack at all, and i think its a very good solution to a problem that we're all trying very hard to fix. Jack On Fri, Jan 8, 2010 at 3:21 AM, Dan Harkins wrote: > > =A0Hi Yaron, > > =A0[wearing a baseball cap from the "Working Man's Triathlon"!] > > =A0These same "unmanaged machines" will cause problems for this new > mutated form of WESP (wrapping both encrypted and unencrypted ESP). > There is no way to assure that they will use WESP. Maybe they'll > use ESP-null without WESP and then these middleboxes relying on > WESP wrapped ESP to do their job are out-of-luck. So yes, these > machines do pose a problem, but WESP doesn't fix that problem. > > =A0Over time a larger and larger portion of the network will "play by > the rules", as you say, but those rules could be: 1) use WESP to wrap > all your ESP traffic, both encrypted and not encrypted; or 2) use > ESP for encrypted traffic and for your > unencrypted traffic. > > =A0Aside from architectural cleanliness, another benefit of a NAT-friendl= y > AH would be that the temptation for extensions and the consequential > creep of new "requirements" (what WESP seems to be suffering from right > now) would go away. We had a problem and the solution has morphed and > succumed to temptation. That's the sign of a bad solution. > > =A0Dan. > > On Thu, January 7, 2010 1:24 pm, Yaron Sheffer wrote: >> Hi Dan, >> >> [No hat. This is getting cold!] >> >> When I hear that "the network enforces a policy" I immediately think of >> the exceptions: unmanaged machines (in the enterprise sense of the word)= , >> machines with weird operating systems (that's "non Windows" to some of o= ur >> participants), outdated versions, machines that failed to be provisioned >> etc. >> >> So it is difficult to assume that *all* ESP is encrypted in any given >> network. This may be OK, if you're willing to accept false positives (e.= g. >> in a load balancer). Or it may not be OK, if you have security decisions >> that depend on this distinction. >> >> And this is why a smooth migration is so important. Over time you get a >> larger and larger portion of the network to play by the rules. >> >> Thanks, >> =A0 =A0 =A0 Yaron >> >> -----Original Message----- >> From: Dan Harkins [mailto:dharkins@lounge.org] >> Sent: Thursday, January 07, 2010 19:57 >> To: Yaron Sheffer >> Cc: ipsec@ietf.org >> Subject: RE: [IPsec] Traffic visibility - consensus call >> >> >> =A0 Hi Yaron, >> >> =A0 Yes, one way was chosen but it has morphed into something much more >> than simply indicating ESP-null traffic. What I'm suggesting is that if >> the goal is simply a good way to indicate ESP-null traffic then doing >> just that is possible with a NAT-friendly version of AH. It's much >> cleaner than WESP. >> >> =A0 How do I indicate encrypted ESP? Well, as I mentioned, it is the onl= y >> traffic using ESP in the network for which traffic visibility is require= d. >> The middleboxes looking into these packets must be in the same policy >> domain as the end systems that are producing the protected traffic. That >> being the case you just disallow ESP-null _by policy_ on that network. >> Then any traffic on the network that is ESP is encrypted and the >> protected-but-inspectable traffic is the NAT-friendly version of AH. >> Voila! We can now distinguish between encrypted and non-encrypted traffi= c >> and we can inspect traffic that is merely integrity protected. >> >> =A0 Dan. >> >> P.S. ESP is a protocol which has the ability to use or not use any numbe= r >> of ciphers. I don't think deprecating a cipher (even the NULL cipher) is >> a "change" to ESP. It doesn't change the protocol the way changing a >> header format or redefining ICV calculations changes the protocol. But >> I'm not proposing deprecating ESP-null and that really has nothing to do >> with the topic of a NAT-friendly version of AH as a solution to the >> problem that WESP claims it is solving. >> >> On Thu, January 7, 2010 4:19 am, Yaron Sheffer wrote: >>> Hi Dan, >>> >>> There are multiple good ways to indicate ESP-null traffic. We just chos= e >>> one option. >>> >>> But (assuming you strongly dislike heuristics, which some of us do) the >>> big question is how to indicate *encrypted* ESP. Deprecating ESP-null i= s >>> a >>> non-starter: it is "changing ESP" just like changing the header format, >>> and even more so, because it is a practically invisible change. >>> >>> Thanks, >>> =A0 =A0 =A0Yaron >>> >>> -----Original Message----- >>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >>> Of >>> Dan Harkins >>> Sent: Thursday, January 07, 2010 2:04 >>> To: Grewal, Ken >>> Cc: ipsec@ietf.org; Paul Koning; Stephen Kent >>> Subject: Re: [IPsec] Traffic visibility - consensus call >>> >>> >>> =A0 Hi Ken, >>> >>> =A0 No one responded to my suggestion so I'll suggest it again below. >>> >>> On Wed, January 6, 2010 2:42 pm, Grewal, Ken wrote: >>> [snip] >>>> The bottom line is that in order for a network appliance (Trusted >>>> Intermediary) to offer critical network services (IDS/IPS/DPI/Access >>>> Control) in IPsec environments, it needs to know if a given IPsec >>>> packet >>>> is encrypted or not in a deterministic manner and this is within scope= . >>>> WESP is offering this determination on a per packet basis. >>> >>> =A0 That is a clear definition of the problem: a TI must be able to >>> determine whether a given IPsec packet is encrypted or not. >>> >>> [snip] >>>> Some argue that we should use WESP for NULL traffic, mandating ESP for >>>> encrypted traffic...AND ensure that ESP is NEVER used for NULL >>>> encryption >>>> within a given domain / environment. How does an intermediate device >>>> know >>>> that this policy is being enforced? What if ESP is still being used fo= r >>>> ESP-NULL and encrypted traffic? If this is the case, we are back to >>>> where >>>> we were/are today - no way to tell if ESP payload is encrypted or not. >>> >>> =A0 The intermediate device knows this because it is under the same >>> policy domain as the endpoints that have agreed to do WESP. If he's not >>> in the same policy domain then he has no assurance that the endpoints >>> will do WESP anyway. Maybe they'll do ESP and maybe even use the NULL >>> cipher, so this box in the cloud is out-of-luck again and WESP doesn't >>> help. Unless, of course, WESP is really a trojan horse to deprecate ESP >>> and force everyone to use WESP always but you have said that's not the >>> case. >>> >>> =A0 So now my suggestion again. If you're going to specify a new protoc= ol >>> and require endpoints to implement it then why not just make a new >>> IPsec protocol that is a NAT-friendly way of doing per-packet integrity >>> protection? Don't try to "wrap" ESP packets. That way the middlebox >>> knows >>> that when it sees this new protocol that it is not encrypted and when i= t >>> sees ESP it knows it is encrypted (it knows that ESP is not using NULL >>> encryption because policy has disallowed that). We could even think >>> about >>> deprecating ESP-NULL in favor of this new protocol. This would be an >>> architecturally cleaner way of solving the problem you clearly describe= d >>> above. IKE can negotiate the new protocol, in transport- or tunnel-mode= , >>> negotiate an algorithm to use to provide integrity protection, and >>> establish an authenticated and shared key to use with the algorithm. So >>> what's the problem with this suggestion? >>> >>> =A0 regards, >>> >>> =A0 Dan. >>> >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>> Scanned by Check Point Total Security Gateway. >>> >> >> >> >> Scanned by Check Point Total Security Gateway. >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From briansw@microsoft.com Thu Jan 7 15:59:36 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BDBB3A67E3 for ; Thu, 7 Jan 2010 15:59:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkAniTTU9XlB for ; Thu, 7 Jan 2010 15:59:35 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 870703A6767 for ; Thu, 7 Jan 2010 15:59:35 -0800 (PST) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 7 Jan 2010 16:00:14 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.0.639.20; Thu, 7 Jan 2010 15:59:33 -0800 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.27]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Thu, 7 Jan 2010 15:59:31 -0800 From: Brian Swander To: Stephen Kent Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AQHKjwjDFMfT79gUNESgtZlfXT4hYpGJDETfgAE9ml2AADJuaYAATReigAAAp/A= Date: Thu, 7 Jan 2010 23:59:30 +0000 Message-ID: <47FF8C26716A4E45993305F326EFE4A2019C7C@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018D15@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20191D9@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A201982B@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20199F1@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Russ Housley Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 23:59:36 -0000 Take 3 simple ones. =20 1. Intermediaries can audit traffic flowing thru them. Netflows work for = all integrity protected traffic as if it were cleartext. 2. Intermediaries can effectively perform QOS markings on packets. Integr= ity-only packets get more accurate markings (as if they were cleartext). =20 3. Intermediaries can enforce stateless router ACLs on all integrity traff= ic. This is used in conjunction with end system audits, and intermediary a= udits, etc. This only increases the security of the overall system. The = alternative is that the stateless router ACLs just permits all ESP (null or= otherwise). All of these allow rolling out transport IPSec without compromising the fun= ctionality of the given intermediaries. All are in scope for WESP. =20 I'm curious what the goal of this line of enquiry is. I.e. how can we ever= be done with this thread? What sort of justification is needed to progress here?=20 bs -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Thursday, January 07, 2010 3:41 PM To: Brian Swander Cc: ipsec@ietf.org; Russ Housley Subject: Re: [IPsec] Traffic visibility - consensus call At 8:06 PM +0000 1/7/10, Brian Swander wrote: >I'm going by what my real customers are asking for. > >Our real customers are asking for exactly what I'm describing below.=20 >I didn't ask them why their stance to intermediaries has changed, if=20 >it even has. That is academic. The key question here is what do=20 >real customers want to deploy, and how can we enable them to do it. > >bs Brian, I don't know how IPSECME will choose to proceed, but in the WG I=20 chair folks expect WG participants to provide technically defensible=20 rationales for designs that they advocate. Relaying what customers=20 purportedly have requested doesn't cut it. Also, the IETF does not assume that "the customer is always right"=20 when making protocol design decisions. If we did, and if we made such=20 decisions in 1990, we'd be using ATM, CLNP, X.400, and other=20 protocols that many big clients said were what they wanted in that=20 time frame :-). Steve From kohn.jack@gmail.com Thu Jan 7 16:06:30 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CE5F3A6826 for ; Thu, 7 Jan 2010 16:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGesu5qeMZq3 for ; Thu, 7 Jan 2010 16:06:29 -0800 (PST) Received: from mail-yw0-f196.google.com (mail-yw0-f196.google.com [209.85.211.196]) by core3.amsl.com (Postfix) with ESMTP id 3F4023A672F for ; Thu, 7 Jan 2010 16:06:29 -0800 (PST) Received: by ywh34 with SMTP id 34so12405989ywh.31 for ; Thu, 07 Jan 2010 16:06:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=8k4r+t1xFy+0/Q1rR6x5drp6Kqe2ALgXSFg2Fp/IXTI=; b=JHjpxSKZtDrgoD36lMRTxJ1WDz7NAPKDNqkjUk/kQlc52bkpYWtoXP1lj7LcevPDS0 Mv2ZOgaEvrxVOgtjyGs33Hzb3x1PeQODe40pBxBeIpd7kU1MLnhRn4M++3Fs26CGbybr lzqV88zdPKjh6KD3IMZMIsy2QeGpBE4EHu1i0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=O8/v42M6rm+fmMCiyuK+rULkP5ovpcVm1l1/czsq3JNdpyux9Vzp9WPtVHtDojWMFd LYKCfP8N91Mqvv/erOrASHbWdJrwu9qYHBWFDEtHuDttffPyma4m7J8nqZSaHrD00cAt sceSs1L7Sb/zxVRtV/ttBfcoqjpRgFgn1ufcI= MIME-Version: 1.0 Received: by 10.90.24.26 with SMTP id 26mr2757595agx.37.1262909184797; Thu, 07 Jan 2010 16:06:24 -0800 (PST) Date: Fri, 8 Jan 2010 05:36:24 +0530 Message-ID: From: Jack Kohn To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [IPsec] Traffic Visibility Future X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 00:06:30 -0000 Folks, Some questions. o In a steady state, where we are using WESP only for ESP-NULL, what should a middle box do when it sees ESP traffic, besides hyperventilating and throwing up? Should it run heuristics (dang! no) or should it simply assume that the packet is encrypted and do whatever the local policy dictates it to do for all encrypted packets? I would guess that it'll be the latter as most middle boxes will NOT run heuristics. Then going forward, should we recommend obsoleting the use of NULL cipher with ESP, as thats the easiest way to get folks off using ESP-NULL. o Are we going to approach the other WGs to starting using WESP wherever they propose to use ESP-NULL? Is that the plan? Jack From dharkins@lounge.org Thu Jan 7 16:21:22 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CB523A691A for ; Thu, 7 Jan 2010 16:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwfWMX626gyi for ; Thu, 7 Jan 2010 16:21:21 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 2E5573A6880 for ; Thu, 7 Jan 2010 16:21:21 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 5977FA88812E; Thu, 7 Jan 2010 16:21:19 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 7 Jan 2010 16:21:19 -0800 (PST) Message-ID: In-Reply-To: References: Date: Thu, 7 Jan 2010 16:21:19 -0800 (PST) From: "Dan Harkins" To: "Jack Kohn" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: ipsec@ietf.org Subject: Re: [IPsec] Traffic Visibility Future X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 00:21:22 -0000 Hi Jack, On Thu, January 7, 2010 4:06 pm, Jack Kohn wrote: > Folks, > > Some questions. > > o In a steady state, where we are using WESP only for ESP-NULL, what > should a middle box do when it sees ESP traffic, besides > hyperventilating and throwing up? Should it run heuristics (dang! no) > or should it simply assume that the packet is encrypted and do > whatever the local policy dictates it to do for all encrypted packets? > I would guess that it'll be the latter as most middle boxes will NOT > run heuristics. Then going forward, should we recommend obsoleting the > use of NULL cipher with ESP, as thats the easiest way to get folks off > using ESP-NULL. No. > o Are we going to approach the other WGs to starting using WESP > wherever they propose to use ESP-NULL? Is that the plan? I sure hope not! Dan. From Nicolas.Williams@sun.com Thu Jan 7 16:25:20 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66A9E3A6901 for ; Thu, 7 Jan 2010 16:25:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlWrFhWYyIoX for ; Thu, 7 Jan 2010 16:25:19 -0800 (PST) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id 4E6523A672F for ; Thu, 7 Jan 2010 16:25:19 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o080PBDP008069 for ; Fri, 8 Jan 2010 00:25:13 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id o080PBwk022427 for ; Thu, 7 Jan 2010 17:25:11 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id o080ABrW023322; Thu, 7 Jan 2010 18:10:11 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id o080ABIU023321; Thu, 7 Jan 2010 18:10:11 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 7 Jan 2010 18:10:10 -0600 From: Nicolas Williams To: Yaron Sheffer Message-ID: <20100108001009.GK1516@Sun.COM> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> User-Agent: Mutt/1.5.7i Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 00:25:20 -0000 On Tue, Jan 05, 2010 at 12:27:26AM +0200, Yaron Sheffer wrote: > We have had a few "discusses" during the IESG review of the WESP > draft. To help resolve them, we would like to reopen the following two > questions to WG discussion. Well reasoned answers are certainly > appreciated. But plain "yes" or "no" would also be useful in judging > the group's consensus. > > - The current draft > (http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11) > defines the ESP trailer's ICV calculation to include the WESP header. > This has been done to counter certain attacks, but it means that WESP > is no longer a simple wrapper around ESP - ESP itself is modified. Do > you support this design decision? No. > - The current draft allows WESP to be applied to encrypted ESP flows, > in addition to the originally specified ESP-null. This was intended so > that encrypted flows can benefit from the future extensibility offered > by WESP. But arguably, it positions WESP as an alternative to ESP. Do > you support this design decision? I don't fully understand why we actually need this, but I think the above is instantly objectionable, while this may be less so. (Just thinking in terms of what changes would be required to existing IPsec implementations.) Nico -- From shore@arsc.edu Thu Jan 7 16:25:29 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDAFC28C0EB for ; Thu, 7 Jan 2010 16:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQFxnXv2G6RU for ; Thu, 7 Jan 2010 16:25:29 -0800 (PST) Received: from arsc.edu (mail1.arsc.edu [IPv6:2001:480:150:75::229]) by core3.amsl.com (Postfix) with ESMTP id 76BFA28C0E6 for ; Thu, 7 Jan 2010 16:25:28 -0800 (PST) Received: from viking-e0.arsc.edu (viking-e0.arsc.edu [IPv6:2001:480:150:860:223:32ff:feda:4a52]) by arsc.edu (20090828.ARSC) with ESMTP id o080PNQA025303; Thu, 7 Jan 2010 15:25:23 -0900 (AKST) Message-Id: From: Melinda Shore To: Jack Kohn In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 7 Jan 2010 15:25:36 -0900 References: X-Mailer: Apple Mail (2.936) X-CanIt-Geo: No geolocation information available for 2001:480:150:860:223:32ff:feda:4a52 X-CanItPRO-Stream: default X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on IPv6:2001:480:150:75::167 Cc: ipsec@ietf.org Subject: Re: [IPsec] Traffic Visibility Future X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 00:25:29 -0000 On Jan 7, 2010, at 3:06 PM, Jack Kohn wrote: > o In a steady state, where we are using WESP only for ESP-NULL, what > should a middle box do when it sees ESP traffic, besides > hyperventilating and throwing up? How would that information be used here? Do you want to specify middlebox behavior? In my experience in some environments network administrators would like to prevent encrypted traffic on the wire because they want to inspect packet contents. I'm trying to think of requirements for doing that other than providing the ability to flag the packet as encrypted or not (let's assume that the presence or absence of other encryption protocols is out-of-scope, since it is out-of-scope) and can't see anything obvious. Melinda From kohn.jack@gmail.com Thu Jan 7 16:39:32 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDB893A690D for ; Thu, 7 Jan 2010 16:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2dlCraUlSio for ; Thu, 7 Jan 2010 16:39:32 -0800 (PST) Received: from mail-yw0-f196.google.com (mail-yw0-f196.google.com [209.85.211.196]) by core3.amsl.com (Postfix) with ESMTP id E3A8C3A672F for ; Thu, 7 Jan 2010 16:39:31 -0800 (PST) Received: by ywh34 with SMTP id 34so12430036ywh.31 for ; Thu, 07 Jan 2010 16:39:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Jh0AkAvBbhY2I9JdsSMkiOgVwVMN5lBnpI/j9M8SK9I=; b=Nl61M28ff7OXkwSXuZIY93zQQ6TIEa1Fy4xQfJy+EqfV+O5vV0CuGzO7wi+HqhYOlV wsgwM8Nogs8TXPfm171NfjDEFD1aFxtYii5JfqGJhojQWZPntGNP0lkyOM4Tw25h5XfA cN53GKcWtpf9rYzkqEYdWlpfoILaue4KqVK8A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=eEershS1atZZrZz5jFGAVAeoBbxLl78QfKCWUOp9cZ8pVw/M+DyQeBxPxXImRHu405 AsKTKJjwsVRKL5CAExH25FCR74Z7OAwT/TXwT/y90C5WpOxCqyFhTVRmvI8766CyVa+7 u9XOi+fdKA4JVsYKI0csLVMEifOKPfhlCBg08= MIME-Version: 1.0 Received: by 10.91.63.29 with SMTP id q29mr9817679agk.72.1262911166382; Thu, 07 Jan 2010 16:39:26 -0800 (PST) In-Reply-To: References: Date: Fri, 8 Jan 2010 06:09:26 +0530 Message-ID: From: Jack Kohn To: Dan Harkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org Subject: Re: [IPsec] Traffic Visibility Future X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 00:39:33 -0000 On Fri, Jan 8, 2010 at 5:51 AM, Dan Harkins wrote: > > =A0Hi Jack, > > On Thu, January 7, 2010 4:06 pm, Jack Kohn wrote: >> Folks, >> >> Some questions. >> >> o In a steady state, where we are using WESP only for ESP-NULL, what >> should a middle box do when it sees =A0ESP traffic, besides >> hyperventilating and throwing up? Should it run heuristics (dang! no) >> or should it simply assume that the packet is encrypted and do >> whatever the local policy dictates it to do for all encrypted packets? >> I would guess that it'll be the latter as most middle boxes will NOT >> run heuristics. Then going forward, should we recommend obsoleting the >> use of NULL cipher with ESP, as thats the easiest way to get folks off >> using ESP-NULL. > > =A0No. Interesting. Then how to do you propose to get people started off with using WESP or the AH-lite? > >> o Are we going to approach the other WGs to starting using WESP >> wherever they propose to use ESP-NULL? Is that the plan? > > =A0I sure hope not! Curious. Why not? > > =A0Dan. > > > > From kohn.jack@gmail.com Thu Jan 7 16:45:12 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCDCB3A6914 for ; Thu, 7 Jan 2010 16:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N76QEGfVQz40 for ; Thu, 7 Jan 2010 16:45:12 -0800 (PST) Received: from mail-yw0-f196.google.com (mail-yw0-f196.google.com [209.85.211.196]) by core3.amsl.com (Postfix) with ESMTP id 0DCF83A690D for ; Thu, 7 Jan 2010 16:45:11 -0800 (PST) Received: by ywh34 with SMTP id 34so12434081ywh.31 for ; Thu, 07 Jan 2010 16:45:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=v+LjSGhr7w46vtszi4fftz/7Rbfz2lGg7JKFQYICwTo=; b=DIZNklaHYlaoCDdXFpGiLC6CyWVtLHM9AuTRHkFSHq0gYVVIGjEAA+Wk+s04fLKnyU LhZXVw2Igh7+Mj948rNvRkmb77ciGkWKGho9IK8QdsoyF7U5sTLqkptOkm8IOhyuhne4 BVGFqA+ZnWkN+frcOJPA2vaPHOA5nDRjk3f2A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rBbS6hsYRdbhYe3rCSx+hCgtoakl20HqGUaw43vBgKaLarFIPAy+f+blOn6RyEnB8n O9Ybvb1rzWK9WZ8Z/VJvF2oPpx0r9dAFuk+R14A4/7fe8NkDcd5zyxdOrLCWkje9OWgy 5/7A9o6kongOGUmCYnDGwqHZQfhSiWt4Vcih0= MIME-Version: 1.0 Received: by 10.91.196.4 with SMTP id y4mr7389968agp.107.1262911507760; Thu, 07 Jan 2010 16:45:07 -0800 (PST) In-Reply-To: References: Date: Fri, 8 Jan 2010 06:15:07 +0530 Message-ID: From: Jack Kohn To: Melinda Shore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org Subject: Re: [IPsec] Traffic Visibility Future X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 00:45:13 -0000 On Fri, Jan 8, 2010 at 5:55 AM, Melinda Shore wrote: > On Jan 7, 2010, at 3:06 PM, Jack Kohn wrote: >> >> o In a steady state, where we are using WESP only for ESP-NULL, what >> should a middle box do when it sees =A0ESP traffic, besides >> hyperventilating and throwing up? > > How would that information be used here? =A0Do you want > to specify middlebox behavior? No, i dont plan anything this ambitious. I am just trying to understand what a WESP powered middle box thats interested in deep inspecting packets, should do when it sees a native ESP packet. Should it make an attempt to parse it based on heuristics (which i completely resent) or should it treat the packet as encrypted and do whatever the local policy dictates? > > In my experience in some environments network > administrators would like to prevent encrypted traffic > on the wire because they want to inspect packet contents. Ok, so in such cases, WESP capable middle boxes would probably drop all ESP (including ESP-NULL) traffic. > I'm trying to think of requirements for doing that other .. doing what? I am sorry i could not follow your following statements. Jack > than providing the ability to flag the packet as > encrypted or not (let's assume that the presence or > absence of other encryption protocols is out-of-scope, > since it is out-of-scope) and can't see anything > obvious. > > Melinda > > From shore@arsc.edu Thu Jan 7 16:50:57 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5620E3A68F7 for ; Thu, 7 Jan 2010 16:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TepsXpQBbhQV for ; Thu, 7 Jan 2010 16:50:56 -0800 (PST) Received: from arsc.edu (mail1.arsc.edu [IPv6:2001:480:150:75::229]) by core3.amsl.com (Postfix) with ESMTP id 0E1013A65A6 for ; Thu, 7 Jan 2010 16:50:55 -0800 (PST) Received: from viking-e0.arsc.edu (viking-e0.arsc.edu [IPv6:2001:480:150:860:223:32ff:feda:4a52]) by arsc.edu (20090828.ARSC) with ESMTP id o080ooIX026353; Thu, 7 Jan 2010 15:50:50 -0900 (AKST) Message-Id: From: Melinda Shore To: Jack Kohn In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 7 Jan 2010 15:51:04 -0900 References: X-Mailer: Apple Mail (2.936) X-CanIt-Geo: No geolocation information available for 2001:480:150:860:223:32ff:feda:4a52 X-CanItPRO-Stream: default X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on IPv6:2001:480:150:75::167 Cc: ipsec@ietf.org Subject: Re: [IPsec] Traffic Visibility Future X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 00:50:57 -0000 On Jan 7, 2010, at 3:45 PM, Jack Kohn wrote: > I am just trying to understand what a WESP powered middle box thats > interested in deep inspecting packets, should do when it sees a native > ESP packet. Should it make an attempt to parse it based on heuristics > (which i completely resent) or should it treat the packet as encrypted > and do whatever the local policy dictates? It seems to me that any discussion of what the middlebox "should" do is not just out-of-scope, it's very very very very very out-of-scope. >> .. doing what? I am sorry i could not follow your following >> statements. Sorry - writing while groggy. Basically, if there are additional requirements for being able to detect encrypted packets that would require some action on the part of ipsecme, I can't think of them off the top of my head. Melinda From rfc-editor@rfc-editor.org Thu Jan 7 16:55:05 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4B8A3A690D; Thu, 7 Jan 2010 16:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.262 X-Spam-Level: X-Spam-Status: No, score=-17.262 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZ1q5sM+sPOt; Thu, 7 Jan 2010 16:55:04 -0800 (PST) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id E0DF53A6914; Thu, 7 Jan 2010 16:55:04 -0800 (PST) Received: by bosco.isi.edu (Postfix, from userid 70) id 883AF39B48D; Thu, 7 Jan 2010 16:52:40 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100108005240.883AF39B48D@bosco.isi.edu> Date: Thu, 7 Jan 2010 16:52:40 -0800 (PST) Cc: ipsec@ietf.org, rfc-editor@rfc-editor.org Subject: [IPsec] RFC 5723 on Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 00:55:06 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5723 Title: Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption Author: Y. Sheffer, H. Tschofenig Status: Standards Track Date: January 2010 Mailbox: yaronf@checkpoint.com, Hannes.Tschofenig@gmx.net Pages: 26 Characters: 59201 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipsecme-ikev2-resumption-09.txt URL: http://www.rfc-editor.org/rfc/rfc5723.txt The Internet Key Exchange version 2 (IKEv2) protocol has a certain computational and communication overhead with respect to the number of round trips required and the cryptographic operations involved. In remote access situations, the Extensible Authentication Protocol (EAP) is used for authentication, which adds several more round trips and consequently latency. To re-establish security associations (SAs) upon a failure recovery condition is time consuming especially when an IPsec peer (such as a VPN gateway) needs to re-establish a large number of SAs with various endpoints. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA re-establishment. In order to avoid the need to re-run the key exchange protocol from scratch, it would be useful to provide an efficient way to resume an IKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously established IKE SA. A client can reconnect to a gateway from which it was disconnected. The proposed approach encodes partial IKE state into an opaque ticket, which can be stored on the client or in a centralized store, and is later made available to the IKEv2 responder for re-authentication. We use the term ticket to refer to the opaque data that is created by the IKEv2 responder. This document does not specify the format of the ticket but examples are provided. [STANDARDS TRACK] This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From dharkins@lounge.org Thu Jan 7 16:59:41 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C84963A691C for ; Thu, 7 Jan 2010 16:59:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaFGJpjOnnAP for ; Thu, 7 Jan 2010 16:59:41 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 1F92C3A6826 for ; Thu, 7 Jan 2010 16:59:41 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 3FB4CA88812E; Thu, 7 Jan 2010 16:59:39 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 7 Jan 2010 16:59:39 -0800 (PST) Message-ID: <494c1d29f6d5637948814a7fc0280865.squirrel@www.trepanning.net> In-Reply-To: References: Date: Thu, 7 Jan 2010 16:59:39 -0800 (PST) From: "Dan Harkins" To: "Jack Kohn" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: ipsec@ietf.org, Dan Harkins Subject: Re: [IPsec] Traffic Visibility Future X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 00:59:41 -0000 On Thu, January 7, 2010 4:39 pm, Jack Kohn wrote: > On Fri, Jan 8, 2010 at 5:51 AM, Dan Harkins wrote: >> >>  Hi Jack, >> >> On Thu, January 7, 2010 4:06 pm, Jack Kohn wrote: >>> Folks, >>> >>> Some questions. >>> >>> o In a steady state, where we are using WESP only for ESP-NULL, what >>> should a middle box do when it sees  ESP traffic, besides >>> hyperventilating and throwing up? Should it run heuristics (dang! no) >>> or should it simply assume that the packet is encrypted and do >>> whatever the local policy dictates it to do for all encrypted packets? >>> I would guess that it'll be the latter as most middle boxes will NOT >>> run heuristics. Then going forward, should we recommend obsoleting the >>> use of NULL cipher with ESP, as thats the easiest way to get folks off >>> using ESP-NULL. >> >>  No. > > Interesting. Then how to do you propose to get people started off with > using WESP or the AH-lite? As I have been saying, if you have the problem that WESP claims to be solving you prohibit ESP-null by local policy. >>> o Are we going to approach the other WGs to starting using WESP >>> wherever they propose to use ESP-NULL? Is that the plan? >> >>  I sure hope not! > > Curious. Why not? Because it's unnecessary bloat that another group may not have any use for. ESP-null could be used, for instance, to protect packets in an EGP routing protocol. There is no need for WESP in such an environment. We should not try to get people to use a protocol simply because the IT department in some enterprise somewhere likes it. Dan. From Nicolas.Williams@sun.com Thu Jan 7 17:26:00 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9D173A691B for ; Thu, 7 Jan 2010 17:26:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVRYDVS8pr4K for ; Thu, 7 Jan 2010 17:26:00 -0800 (PST) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id E99B03A67E3 for ; Thu, 7 Jan 2010 17:25:59 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o081PkXG017965 for ; Fri, 8 Jan 2010 01:25:46 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id o081PjCr051061 for ; Thu, 7 Jan 2010 18:25:45 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id o0813F2i023498; Thu, 7 Jan 2010 19:03:15 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id o0813E6e023497; Thu, 7 Jan 2010 19:03:14 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 7 Jan 2010 19:03:14 -0600 From: Nicolas Williams To: Melinda Shore Message-ID: <20100108010314.GN1516@Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: ipsec@ietf.org, Jack Kohn Subject: Re: [IPsec] Traffic Visibility Future X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 01:26:00 -0000 On Thu, Jan 07, 2010 at 03:51:04PM -0900, Melinda Shore wrote: > On Jan 7, 2010, at 3:45 PM, Jack Kohn wrote: > >I am just trying to understand what a WESP powered middle box thats > >interested in deep inspecting packets, should do when it sees a native > >ESP packet. Should it make an attempt to parse it based on heuristics > >(which i completely resent) or should it treat the packet as encrypted > >and do whatever the local policy dictates? > > It seems to me that any discussion of what the middlebox > "should" do is not just out-of-scope, it's very very very > very very out-of-scope. Yes, but it's useful to know what they could possibly do. If a middlebox wants to drop all encrypted IPsec traffic then it needs to know if it's encrypted. Knowing WESP -> ESP-null, ESP -> unknown, is sufficient. Anyone who might want to configure middle boxes to drop ESP-!null is not really going to be helped by having a WESP "encrypted bit" -- either way they'll have to have a flag day when they impose this policy. Nico -- From jtardo@broadcom.com Thu Jan 7 17:47:46 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46E5D3A683D for ; Thu, 7 Jan 2010 17:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muLyQs7G8tVP for ; Thu, 7 Jan 2010 17:47:45 -0800 (PST) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id 367DA3A67AA for ; Thu, 7 Jan 2010 17:47:45 -0800 (PST) Received: from [10.16.192.232] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 07 Jan 2010 17:47:33 -0800 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Thu, 7 Jan 2010 17:47:33 -0800 From: "Joseph Tardo" To: "Stephen Kent" , "Brian Swander" Date: Thu, 7 Jan 2010 17:47:32 -0800 Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AQHKjwjDFMfT79gUNESgtZlfXT4hYpGJDETfgAE9ml2AADJuaYAATReigAAAp/CAABr9cA== Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD68163BE9674@SJEXCHCCR02.corp.ad.broadcom.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018D15@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20191D9@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A201982B@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20199F1@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2019C7C@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <47FF8C26716A4E45993305F326EFE4A2019C7C@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 6758513F3J865511201-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 01:47:46 -0000 Steve, Let me add 2 more simple ones, mirroring based on L4 dest port and policy b= ased routing. An important point here is that not all intermediate nodes that need to exa= mine packets are necessarily "trusted" intermediaries (in the security appl= iance sense), many (such as Netflow probes) have perfectly legitimate purpo= ses that ESP-NULL would break. For these, and I'm not the first to say this= , heuristics will never work. WESP is a simple enough approach to include i= n many of these kind of devices. I agree with Brian and Charlie here, what do we need to close this off? Thanks, --Joe -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of B= rian Swander Sent: Thursday, January 07, 2010 3:59 PM To: Stephen Kent Cc: ipsec@ietf.org; Russ Housley Subject: Re: [IPsec] Traffic visibility - consensus call Take 3 simple ones. =20 1. Intermediaries can audit traffic flowing thru them. Netflows work for = all integrity protected traffic as if it were cleartext. 2. Intermediaries can effectively perform QOS markings on packets. Integr= ity-only packets get more accurate markings (as if they were cleartext). =20 3. Intermediaries can enforce stateless router ACLs on all integrity traff= ic. This is used in conjunction with end system audits, and intermediary a= udits, etc. This only increases the security of the overall system. The = alternative is that the stateless router ACLs just permits all ESP (null or= otherwise). All of these allow rolling out transport IPSec without compromising the fun= ctionality of the given intermediaries. All are in scope for WESP. =20 I'm curious what the goal of this line of enquiry is. I.e. how can we ever= be done with this thread? What sort of justification is needed to progress here?=20 bs -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Thursday, January 07, 2010 3:41 PM To: Brian Swander Cc: ipsec@ietf.org; Russ Housley Subject: Re: [IPsec] Traffic visibility - consensus call At 8:06 PM +0000 1/7/10, Brian Swander wrote: >I'm going by what my real customers are asking for. > >Our real customers are asking for exactly what I'm describing below.=20 >I didn't ask them why their stance to intermediaries has changed, if=20 >it even has. That is academic. The key question here is what do=20 >real customers want to deploy, and how can we enable them to do it. > >bs Brian, I don't know how IPSECME will choose to proceed, but in the WG I=20 chair folks expect WG participants to provide technically defensible=20 rationales for designs that they advocate. Relaying what customers=20 purportedly have requested doesn't cut it. Also, the IETF does not assume that "the customer is always right"=20 when making protocol design decisions. If we did, and if we made such=20 decisions in 1990, we'd be using ATM, CLNP, X.400, and other=20 protocols that many big clients said were what they wanted in that=20 time frame :-). Steve _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From kohn.jack@gmail.com Thu Jan 7 18:09:52 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C13163A6910 for ; Thu, 7 Jan 2010 18:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkdPCG53Dl9s for ; Thu, 7 Jan 2010 18:09:52 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id E64753A6889 for ; Thu, 7 Jan 2010 18:09:51 -0800 (PST) Received: by gxk28 with SMTP id 28so12260468gxk.9 for ; Thu, 07 Jan 2010 18:09:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=95aoCR41cD7OEMzzbIcoO8xqe3r1EjnTo+9YwQj2dRY=; b=NFxav8dMysSp5/PnwTf5hMQzn3XJh+vbyUTykGkQdr51RSwJjtfkiNugHN6qVhjeD5 wON3RnUF/POEmRHKvcukuidUziLxaHa3pKm5sGozDgiajOZQUQlWJiJV3rLvpLn7tO0Z UlwLfzeD+ecAMCzzJhEJk+pW7Bk6CyG6RtH74= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dFzRVRadTqukFZQqrr/Qva71Qj/umvBp3kTyMh515/oC6pNCN0Ch2/9/UWitsvyNp6 Kc3MNuFzsopaWqGsuIjQV6Hpp/a/2qS0yPn1yatvlp9pAA1wqeixn5GA87e0ACSN9fYh w3FjN1uvMBUDJT/GZO1tGwSHf3t9nyxes3HWA= MIME-Version: 1.0 Received: by 10.91.18.32 with SMTP id v32mr2646181agi.81.1262916587103; Thu, 07 Jan 2010 18:09:47 -0800 (PST) In-Reply-To: <20100108010314.GN1516@Sun.COM> References: <20100108010314.GN1516@Sun.COM> Date: Fri, 8 Jan 2010 07:39:47 +0530 Message-ID: From: Jack Kohn To: Nicolas Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, Melinda Shore Subject: Re: [IPsec] Traffic Visibility Future X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 02:09:52 -0000 > > Yes, but it's useful to know what they could possibly do. =A0If a > middlebox wants to drop all encrypted IPsec traffic then it needs to > know if it's encrypted. =A0Knowing WESP -> ESP-null, ESP -> unknown, is > sufficient. Yup, and this is what i was alluding to. All middle boxes may not want to drop all encrypted traffic, which is why i said that such boxes must do what their local policy dictates. If the local policy dictates, marking all encrypted packets as low priority, then it must mark all ESP traffic as low prio, as it has no way of knowing whether the incoming traffic is ESP or ESP-NULL. This is what i had meant in my original mail. > > Anyone who might want to configure middle boxes to drop ESP-!null is not > really going to be helped by having a WESP "encrypted bit" -- either way > they'll have to have a flag day when they impose this policy. Yes, if the intent is to drop all encrypted packets. However, it can help, if the intent is to do separate processing for null and encrypted packets. In case of vanilla ESP, we will also have some false negatives, which may not be desired. Jack From manav.bhatia@alcatel-lucent.com Thu Jan 7 18:15:43 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2052F3A6889 for ; Thu, 7 Jan 2010 18:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhOkBL5SJRNi for ; Thu, 7 Jan 2010 18:15:42 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by core3.amsl.com (Postfix) with ESMTP id 34B3B3A67E3 for ; Thu, 7 Jan 2010 18:15:42 -0800 (PST) Received: from horh1.usa.alcatel.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id o082Fd0x008637; Thu, 7 Jan 2010 20:15:39 -0600 (CST) Received: from mail.apac.alcatel-lucent.com (h202-65-2-130.alcatel.com [202.65.2.130]) by horh1.usa.alcatel.com (8.13.8/emsr) with ESMTP id o082FbtF023492; Thu, 7 Jan 2010 20:15:38 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by mail.apac.alcatel-lucent.com (8.13.7/8.13.7/Alcanet1.0) with ESMTP id o082ABFX025139; Fri, 8 Jan 2010 10:10:12 +0800 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Fri, 8 Jan 2010 07:45:35 +0530 From: "Bhatia, Manav (Manav)" To: Dan Harkins , Jack Kohn Date: Fri, 8 Jan 2010 07:45:32 +0530 Thread-Topic: [IPsec] Traffic Visibility Future Thread-Index: AcqP/fcvFloLnbPvR/+ESScPKT2yxQACk/SA Message-ID: <7C362EEF9C7896468B36C9B79200D8350AB34BB308@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <494c1d29f6d5637948814a7fc0280865.squirrel@www.trepanning.net> In-Reply-To: <494c1d29f6d5637948814a7fc0280865.squirrel@www.trepanning.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 172.22.12.28 X-Scanned-By: MIMEDefang 2.64 on 202.65.2.130 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic Visibility Future X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 02:15:43 -0000 Dan, [clipped] =20 > Because it's unnecessary bloat that another group may not have any > use for. ESP-null could be used, for instance, to protect=20 > packets in an > EGP routing protocol. There is no need for WESP in such an=20 > environment. EGP routing protocols, by definition and design, will traverse multiple aut= onomous systems, and there could very well be a policy on the edge of one s= uch AS that could deny entry to any traffic that it doesn't recognize.=20 Using WESP will clearly help in such cases. Cheers, Manav= From dharkins@lounge.org Thu Jan 7 21:11:56 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D605828C0F8 for ; Thu, 7 Jan 2010 21:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01CaZHfJISJ0 for ; Thu, 7 Jan 2010 21:11:55 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 28BBE3A67DD for ; Thu, 7 Jan 2010 21:11:53 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 633FD1022404A; Thu, 7 Jan 2010 21:11:51 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 7 Jan 2010 21:11:51 -0800 (PST) Message-ID: <23a2ecaa6e7a978bcaf8cd216572e9b1.squirrel@www.trepanning.net> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350AB34BB308@INBANSXCHMBSA1.in.alcatel- lucent.com> References: <494c1d29f6d5637948814a7fc0280865.squirrel@www.trepanning.net> <7C362EEF9C7896468B36C9B79200D8350AB34BB308@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Thu, 7 Jan 2010 21:11:51 -0800 (PST) From: "Dan Harkins" To: "Bhatia, Manav (Manav)" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "ipsec@ietf.org" , Dan Harkins , Jack Kohn Subject: Re: [IPsec] Traffic Visibility Future X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 05:11:57 -0000 I would be very much interested in a real-world example instead of hypotheticals. What service provider is asking for WESP? Dan. On Thu, January 7, 2010 6:15 pm, Bhatia, Manav (Manav) wrote: > Dan, > > [clipped] > >> Because it's unnecessary bloat that another group may not have any >> use for. ESP-null could be used, for instance, to protect >> packets in an >> EGP routing protocol. There is no need for WESP in such an >> environment. > > EGP routing protocols, by definition and design, will traverse multiple > autonomous systems, and there could very well be a policy on the edge of > one such AS that could deny entry to any traffic that it doesn't > recognize. > > Using WESP will clearly help in such cases. > > Cheers, Manav > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From Nicolas.Williams@sun.com Thu Jan 7 22:12:36 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65F493A693D for ; Thu, 7 Jan 2010 22:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLhYzkLVASRr for ; Thu, 7 Jan 2010 22:12:32 -0800 (PST) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id B68303A692C for ; Thu, 7 Jan 2010 22:12:31 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o086CT0S002068 for ; Fri, 8 Jan 2010 06:12:30 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id o086CTKR036659 for ; Thu, 7 Jan 2010 23:12:29 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id o085nxqh023647; Thu, 7 Jan 2010 23:49:59 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id o085nxvS023646; Thu, 7 Jan 2010 23:49:59 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 7 Jan 2010 23:49:59 -0600 From: Nicolas Williams To: Jack Kohn Message-ID: <20100108054958.GP1516@Sun.COM> References: <20100108010314.GN1516@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.7i Cc: ipsec@ietf.org, Melinda Shore Subject: Re: [IPsec] Traffic Visibility Future X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 06:12:37 -0000 On Fri, Jan 08, 2010 at 07:39:47AM +0530, Jack Kohn wrote: > > Yes, but it's useful to know what they could possibly do.  If a > > middlebox wants to drop all encrypted IPsec traffic then it needs to > > know if it's encrypted.  Knowing WESP -> ESP-null, ESP -> unknown, is > > sufficient. > > Yup, and this is what i was alluding to. All middle boxes may not want > to drop all encrypted traffic, which is why i said that such boxes > must do what their local policy dictates. > > If the local policy dictates, marking all encrypted packets as low > priority, then it must mark all ESP traffic as low prio, as it has no > way of knowing whether the incoming traffic is ESP or ESP-NULL. > > This is what i had meant in my original mail. That's what I thought. > > Anyone who might want to configure middle boxes to drop ESP-!null is not > > really going to be helped by having a WESP "encrypted bit" -- either way > > they'll have to have a flag day when they impose this policy. > > Yes, if the intent is to drop all encrypted packets. > > However, it can help, if the intent is to do separate processing for > null and encrypted packets. In case of vanilla ESP, we will also have > some false negatives, which may not be desired. Yeah, but if the action to be taken is anything other than "drop" then the false positives do little harm. Also, anything QoS related should really happen outside ESP anyways. What are we left with? Auditing/ logging based on deep inspection? But then you're back to the question of just how paranoid one can get. If you trust the end-points then you might as well trust them to use WESP and ESP-!null as appropriate, else you can't win. This is why I don't see the need for WESP to wrap ESP-!null. Nico -- From manav.bhatia@alcatel-lucent.com Fri Jan 8 03:35:34 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE4483A6876 for ; Fri, 8 Jan 2010 03:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhRQDFszYvZ9 for ; Fri, 8 Jan 2010 03:35:34 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id F2E9D3A6863 for ; Fri, 8 Jan 2010 03:35:33 -0800 (PST) Received: from horh1.usa.alcatel.com (h172-22-218-55.lucent.com [172.22.218.55]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o08BZQ7r027770; Fri, 8 Jan 2010 05:35:29 -0600 (CST) Received: from mail.apac.alcatel-lucent.com (aprelay03.apac.alcatel-lucent.com [202.65.2.133]) by horh1.usa.alcatel.com (8.13.8/emsr) with ESMTP id o08BZNMH010511; Fri, 8 Jan 2010 05:35:24 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by mail.apac.alcatel-lucent.com (8.13.7/8.13.7/Alcanet1.0) with ESMTP id o08BjtQN026847; Fri, 8 Jan 2010 19:45:58 +0800 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Fri, 8 Jan 2010 17:05:21 +0530 From: "Bhatia, Manav (Manav)" To: Dan Harkins Date: Fri, 8 Jan 2010 17:05:19 +0530 Thread-Topic: [IPsec] Traffic Visibility Future Thread-Index: AcqQITkZyWmQEkYzT7WLenqo9BlTtAANSorQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350AB34BB53C@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <494c1d29f6d5637948814a7fc0280865.squirrel@www.trepanning.net> <7C362EEF9C7896468B36C9B79200D8350AB34BB308@INBANSXCHMBSA1.in.alcatel-lucent.com> <23a2ecaa6e7a978bcaf8cd216572e9b1.squirrel@www.trepanning.net> In-Reply-To: <23a2ecaa6e7a978bcaf8cd216572e9b1.squirrel@www.trepanning.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 202.65.2.133 Cc: "ipsec@ietf.org" , Jack Kohn Subject: Re: [IPsec] Traffic Visibility Future X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 11:35:34 -0000 I never said that there are service providers clamouring for WESP.=20 You brought up a point about EGP routing protocols, and I just replied to t= hat. Cheers, Manav=20 > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org]=20 > Sent: Friday, January 08, 2010 10.42 AM > To: Bhatia, Manav (Manav) > Cc: Dan Harkins; Jack Kohn; ipsec@ietf.org > Subject: Re: [IPsec] Traffic Visibility Future >=20 >=20 > I would be very much interested in a real-world example instead > of hypotheticals. What service provider is asking for WESP? >=20 > Dan. >=20 > On Thu, January 7, 2010 6:15 pm, Bhatia, Manav (Manav) wrote: > > Dan, > > > > [clipped] > > > >> Because it's unnecessary bloat that another group may=20 > not have any > >> use for. ESP-null could be used, for instance, to protect > >> packets in an > >> EGP routing protocol. There is no need for WESP in such an > >> environment. > > > > EGP routing protocols, by definition and design, will=20 > traverse multiple > > autonomous systems, and there could very well be a policy=20 > on the edge of > > one such AS that could deny entry to any traffic that it doesn't > > recognize. > > > > Using WESP will clearly help in such cases. > > > > Cheers, Manav > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > >=20 >=20 > = From kivinen@iki.fi Fri Jan 8 03:58:30 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4670C3A67EB for ; Fri, 8 Jan 2010 03:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29KUgTVZaxDr for ; Fri, 8 Jan 2010 03:58:29 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 0D5213A6898 for ; Fri, 8 Jan 2010 03:58:28 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o08BwHXV004242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Jan 2010 13:58:17 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o08BwGpd003936; Fri, 8 Jan 2010 13:58:16 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19271.7640.62846.565938@fireball.kivinen.iki.fi> Date: Fri, 8 Jan 2010 13:58:16 +0200 From: Tero Kivinen To: Brian Swander In-Reply-To: <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 17 min X-Total-Time: 16 min Cc: "ipsec@ietf.org" , Russ Housley , Stephen Kent , gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 11:58:30 -0000 [I finally managed to catch up all the tons of emails to the ipsec-list, so now I can finally reply to few of them.] Brian Swander writes: > In terms of your chart, that means that the only allowed > combinations (of this scenario) are: > > Case Nodes Flow S 1 S 2 > 1 N-N I EN EN > 3 W-W I W W > 4 W-W E EE W* > 5 W-N I EN EN > > Hence any (legitimate) ESP traffic that the intermediary sees must > be ESP-NULL, and the encypt flag is critical, as it is the mechanism > to enable encryption between uplevel machines. > > The main point of WESP is to remove heuristics from intermediary > processing. Hence we need to focus on the scenarios that actually > allow us to do that, and enable as many of them as possible. Note, that every time you have ESP-NULL traffic without WESP, you need heuristics. I.e. the cases 1 and 5 still need heuristics regardless whether you like that fact or not. If you try to inspect plain ESP-NULL traffic you need heuristics to find out the algorithm parameters for those ESP-NULL connections, i.e. what is the ICV length and whether there is IV (and its length). If you allow ESP traffic at all on the network you need to deal with it, meaning you either use heuristics to inspect it or you simply allow it go through or drop it (regradless whether it is encrypted ESP or ESP-NULL). If your use of ESP/WESP is such that it is beneficial for the users to use WESP instead of ESP-NULL then they will move to it (i.e. if WESP provides better QoS properties than ESP-NULL, then it will get used). If it is critical for security that all traffic is inspected then you cannot allow encrypted ESP at all (regardless whether it is marked in WESP or not). If it is "nice to have feature" (for example network statistics) to be able to see inside ESP-NULL packets (regardless whether they use WESP or ESP-NULL) then you either use heuristics for ESP-NULL packets, or just notice that the amount of ESP-NULL traffic is so small that it is no longer needed for network statistcs use (i.e. when WESP is widespread enough in your network, you can stop trying to inspect ESP packets to account that last 0.00001% of traffic still using ESP-NULL instead of WESP). I cannot really see any scenario above where it would really be needed to put encrypted packets inside WESP. -- kivinen@iki.fi From kivinen@iki.fi Fri Jan 8 05:24:30 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 729F33A68FD for ; Fri, 8 Jan 2010 05:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsXEdUymYkcf for ; Fri, 8 Jan 2010 05:24:29 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id EA4DA3A6886 for ; Fri, 8 Jan 2010 05:24:28 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o08DOBNJ004695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Jan 2010 15:24:11 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o08DO9ap003171; Fri, 8 Jan 2010 15:24:09 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19271.12793.257408.246220@fireball.kivinen.iki.fi> Date: Fri, 8 Jan 2010 15:24:09 +0200 From: Tero Kivinen To: "Grewal, Ken" In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018D15@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 15 min X-Total-Time: 85 min Cc: "ipsec@ietf.org" , Paul Koning , Stephen Kent Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 13:24:30 -0000 Grewal, Ken writes: > Some people have jumped to conclusions that because we want to > differentiate between encrypted and non-encrypted traffic by > explicitly signaling in the packet, that WESP is now a replacement > for ESP. > > THIS IS NOT THE CASE AND IT WAS NEVER THE INTENT! That is true, it was never intented for that, but some of the comments in the list (and in the last IETF meeting) started discussions which started to lead that way. This includes most of the WESP extension discussion. That discussion was the thing that woke me up, and then I started to notice that the WESP is very far from where it started. Even when most of the intermediate steps were justifiable, that does not mean the end result will be ok. > One item that may have led to this conclusion was the expanded ICV > over WESP, but this was introduced as a mitigation for certain > threats highlighted in the WG. Subsequent discussions have > determined that it would be better to mitigate these treats in an > alternative manner, so we can fall back to WESP being a wrapper for > ESP, without the expanded ICV. Wrapped ESP provides a wrapper for > ESP! The current draft still requires both checks, i.e. both ICV to cover the WESP header, AND checking all fields in the WESP header against other sources. I think the checking and ICV expansion happeneded about in the same time, and one of the reasons the checking of the fields is needed REGARDLESS whether ICV covers WESP header or not, is to protect against attacks where the end node puts wrong values to the WESP header to fool intermediate devices. ICV cannot protect against that. ICV will only protect against the attacks happening in transit, but checking all fields protects both for attacks happening in transit, and attacks done by the end node. > Some argue that we should use WESP for NULL traffic, mandating ESP > for encrypted traffic...AND ensure that ESP is NEVER used for NULL > encryption within a given domain / environment. How does an > intermediate device know that this policy is being enforced? It cannot, but on the other hand how can intermediate device know that the traffic which must be sent using ESP-NULL is not encrypted? Only way to do either of those, is to mandate them by policy, which do require co-operation from end point(s). > Having the encrypted flag within WESP allows clear and explicit > distinction that certain traffic is encrypted whereas other traffic > is not. This preserves the network based services we rely on and > also allows other access control policies to be enforced. E.g. I > want to ensure that my finance data flowing in the network is > encrypted and NOT using ESP-NULL. If I rely on ESP for encrypted > data and it can still use NULL encryption, I cannot enforce such a > policy from an access control tool. If you mandate that ESP is only for encrypted data, then you make policy which says that ESP is only for encrypted data, and thats it. If you cannot rely your end nodes to select correct policy between WESP-NULL and encrypted ESP, how can you rely them selecting correct policy for WESP-NULL vs encrypted-WESP traffic? I.e. your node can still use WESP-NULL for financial data or it can use encrypted WESP for traffic which should have been been using NULL cipher. > "A standards-track mechanism that allows an intermediary device, such > as a firewall or intrusion detection system, to easily and reliably > determine whether an ESP packet is encrypted with the NULL cipher; and > if it is, determine the location of the actual payload data inside the > packet." > > If we say that WESP is ONLY used to carry ESP-NULL (and ESP is used > to carry encrypted traffic, but based on the ESP spec and legacy, it > may also carry ESP-NULL), then we have not completed what we set out > to do, as we have failed to *reliably* determine if the ESP traffic > is encrypted or not! You can still use heuristics in that case, if you cannot update all your hosts which use NULL cipher to use WESP. Heuristics can also provide *reliable* way to determine whether traffic is encrypted ESP or not. That is why we have both heuristics and WESP. Heuristics are meant to be used in the mean time when not all traffic cannot be made to use WESP-NULL. After the whole network supports WESP-NULL you can forbid ESP-NULL by policy and drop heuristics. -- kivinen@iki.fi From Nicolas.Williams@sun.com Fri Jan 8 08:10:34 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09EAA28C0ED for ; Fri, 8 Jan 2010 08:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9cCMKX9l6Ri for ; Fri, 8 Jan 2010 08:10:32 -0800 (PST) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 7248428C106 for ; Fri, 8 Jan 2010 08:10:31 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o08GATgs024136 for ; Fri, 8 Jan 2010 16:10:29 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id o08GATJB046540 for ; Fri, 8 Jan 2010 09:10:29 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id o08FtSgx023896; Fri, 8 Jan 2010 09:55:28 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id o08FtSJm023895; Fri, 8 Jan 2010 09:55:28 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 8 Jan 2010 09:55:28 -0600 From: Nicolas Williams To: Yaron Sheffer Message-ID: <20100108155527.GQ1402@Sun.COM> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <20100108001009.GK1516@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100108001009.GK1516@Sun.COM> User-Agent: Mutt/1.5.7i Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 16:10:34 -0000 On Thu, Jan 07, 2010 at 06:10:10PM -0600, Nicolas Williams wrote: > On Tue, Jan 05, 2010 at 12:27:26AM +0200, Yaron Sheffer wrote: > > - The current draft > > (http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11) > > defines the ESP trailer's ICV calculation to include the WESP header. > > This has been done to counter certain attacks, but it means that WESP > > is no longer a simple wrapper around ESP - ESP itself is modified. Do > > you support this design decision? > > No. > > > - The current draft allows WESP to be applied to encrypted ESP flows, > > in addition to the originally specified ESP-null. This was intended so > > that encrypted flows can benefit from the future extensibility offered > > by WESP. But arguably, it positions WESP as an alternative to ESP. Do > > you support this design decision? > > I don't fully understand why we actually need this, but I think the > above is instantly objectionable, while this may be less so. (Just > thinking in terms of what changes would be required to existing IPsec > implementations.) I believe I understand the issues now, and I believe this extension is not needed, therefore: No. Nico -- From briansw@microsoft.com Fri Jan 8 09:06:36 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5417E3A6810 for ; Fri, 8 Jan 2010 09:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wki6Vu6MjCcs for ; Fri, 8 Jan 2010 09:06:35 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 52F473A677C for ; Fri, 8 Jan 2010 09:06:35 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 8 Jan 2010 09:07:14 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.0.639.20; Fri, 8 Jan 2010 09:06:33 -0800 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.27]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Fri, 8 Jan 2010 09:06:32 -0800 From: Brian Swander To: Tero Kivinen Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AQHKjv8+FMfT79gUNESgtZlfXT4hYpGI5nLQgAM1ZAD//87lMA== Date: Fri, 8 Jan 2010 17:06:31 +0000 Message-ID: <47FF8C26716A4E45993305F326EFE4A201A160@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com> <734514.64270.qm@web82604.mail.mud.yahoo.com> <5E38DBF64E732C4C98512C53E1B14DDC299B8B20@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A20188CE@TK5EX14MBXW603.wingroup.windeploy. ntdev.microsoft.com> <47FF8C26716A4E45993305F326EFE4A2018A04@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <19271.7640.62846.565938@fireball.kivinen.iki.fi> In-Reply-To: <19271.7640.62846.565938@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Russ Housley , Stephen Kent , gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 17:06:36 -0000 In the absolutely most generic case, yes. And heuristics absolutely have t= heir place. However, my proposal clearly allows for eliminating all heuris= tics with policy constraints.=20 As you well know, you can eliminate the heuristics you describe by choosing= the same algorithm so intermediaries don't need to guess ICV lengths. Hence in this scenario, all ESP traffic would be ESP-NULL of a known algori= thm. This is possible since you just choose an algo that all the legacy cl= ients also support. =20 So my scenario gives a very real deployment that can eliminate the need for= heuristics entirely during migration. So carrying encrypted traffic in WE= SP is very valuable (and in charter). bs -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of T= ero Kivinen Sent: Friday, January 08, 2010 3:58 AM To: Brian Swander Cc: ipsec@ietf.org; Russ Housley; Stephen Kent; gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call [I finally managed to catch up all the tons of emails to the ipsec-list, so now I can finally reply to few of them.] Brian Swander writes: > In terms of your chart, that means that the only allowed > combinations (of this scenario) are:=20 >=20 > Case Nodes Flow S 1 S 2 > 1 N-N I EN EN > 3 W-W I W W > 4 W-W E EE W* > 5 W-N I EN EN >=20 > Hence any (legitimate) ESP traffic that the intermediary sees must > be ESP-NULL, and the encypt flag is critical, as it is the mechanism > to enable encryption between uplevel machines.=20 >=20 > The main point of WESP is to remove heuristics from intermediary > processing. Hence we need to focus on the scenarios that actually > allow us to do that, and enable as many of them as possible.=20 Note, that every time you have ESP-NULL traffic without WESP, you need heuristics. I.e. the cases 1 and 5 still need heuristics regardless whether you like that fact or not. If you try to inspect plain ESP-NULL traffic you need heuristics to find out the algorithm parameters for those ESP-NULL connections, i.e. what is the ICV length and whether there is IV (and its length). If you allow ESP traffic at all on the network you need to deal with it, meaning you either use heuristics to inspect it or you simply allow it go through or drop it (regradless whether it is encrypted ESP or ESP-NULL). If your use of ESP/WESP is such that it is beneficial for the users to use WESP instead of ESP-NULL then they will move to it (i.e. if WESP provides better QoS properties than ESP-NULL, then it will get used). If it is critical for security that all traffic is inspected then you cannot allow encrypted ESP at all (regardless whether it is marked in WESP or not).=20 If it is "nice to have feature" (for example network statistics) to be able to see inside ESP-NULL packets (regardless whether they use WESP or ESP-NULL) then you either use heuristics for ESP-NULL packets, or just notice that the amount of ESP-NULL traffic is so small that it is no longer needed for network statistcs use (i.e. when WESP is widespread enough in your network, you can stop trying to inspect ESP packets to account that last 0.00001% of traffic still using ESP-NULL instead of WESP). I cannot really see any scenario above where it would really be needed to put encrypted packets inside WESP.=20 --=20 kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From jtardo@broadcom.com Fri Jan 8 11:14:26 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EC0F3A67F8 for ; Fri, 8 Jan 2010 11:14:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mY5i6UZw4Aoo for ; Fri, 8 Jan 2010 11:14:22 -0800 (PST) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id F251E3A67FB for ; Fri, 8 Jan 2010 11:14:21 -0800 (PST) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 08 Jan 2010 11:14:09 -0800 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Fri, 8 Jan 2010 11:14:09 -0800 From: "Joseph Tardo" To: "Nicolas Williams" , "Jack Kohn" Date: Fri, 8 Jan 2010 11:14:06 -0800 Thread-Topic: [IPsec] Traffic Visibility Future Thread-Index: AcqQKZ7Xc0z1Kgs5SOi/7PGjeXQ5MwAa+kWQ Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD68163BE9739@SJEXCHCCR02.corp.ad.broadcom.com> References: <20100108010314.GN1516@Sun.COM> <20100108054958.GP1516@Sun.COM> In-Reply-To: <20100108054958.GP1516@Sun.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67595B8B38O65808368-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "ipsec@ietf.org" , Melinda Shore Subject: Re: [IPsec] Traffic Visibility Future X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 19:14:26 -0000 -----Original Message----- Also, anything QoS related should really happen outside ESP anyways. =20 Nico -- In an ideal world maybe. Sometimes the netwwork needs to mark traffic at th= e edge switch but doesn't 'trust' the endpoint to do it. So typically it wo= uld be done with policy rules. Thanks, --Joe =20 From danmcd@sun.com Fri Jan 8 11:18:45 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B198C3A6886 for ; Fri, 8 Jan 2010 11:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3b8jcRGzXFK for ; Fri, 8 Jan 2010 11:18:44 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 8E3F23A6856 for ; Fri, 8 Jan 2010 11:18:44 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o08JIfsb025779 for ; Fri, 8 Jan 2010 19:18:41 GMT Received: from kebe.East.Sun.COM (kebe.East.Sun.COM [129.148.174.48]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o08JIfLv006885; Fri, 8 Jan 2010 14:18:41 -0500 (EST) Received: from kebe.East.Sun.COM (localhost [127.0.0.1]) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id o08JIew2001224; Fri, 8 Jan 2010 14:18:40 -0500 (EST) Received: (from danmcd@localhost) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3/Submit) id o08JIdi6001223; Fri, 8 Jan 2010 14:18:39 -0500 (EST) X-Authentication-Warning: kebe.East.Sun.COM: danmcd set sender to danmcd@sun.com using -f Date: Fri, 8 Jan 2010 14:18:39 -0500 From: Dan McDonald To: ipsec@ietf.org Message-ID: <20100108191839.GN23285@kebe.East.Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [IPsec] No UDP encapsulation with IKEv2 over port 4500? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 19:18:45 -0000 I read this sentence in IKEv2bis... If NAT-T is supported (that is, if NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT), all devices MUST be able to receive and process both UDP encapsulated and non-UDP encapsulated packets at any time. ... and thought of my own implementation. The background reading is here: http://blogs.sun.com/danmcd/entry/detangling_ipsec_nat_traversal_and Today, my implementation marks a port (a socket option to be precise) as a NAT-Traversal port. Traffic to this port that has the zero-SPI gets the zero-SPI stripped and the datagram passed to UDP like any other UDP datagram. If the SPI is non-zero, the UDP portion is stripped, and the packet is passed to ESP for lookup. If there's no SA, the packet is dropped like any other ESP packet with a bad SPI. The text above suggests that if I'm to build IKEv2 properly, I need to not drop these bad-SPI ESP-in-UDP packets (local-port == 4500), but instead pass them up as a UDP datagram without any strippage. Am I understanding this correctly? Or does the text need some more rewhacking? I'm not sure what problem 4500-with-no-encapsulation solves. If you use port 4500, you're most likely going to be doing ESP-in-UDP anyway, and will need the zero-SPI for IKE traffic anyway. And what if you hit that N-in-2^32 chance (where N is the number of inbound SAs) where the high 32-bits of the IKE SPI value is the same as some IPsec SA? Dan From Nicolas.Williams@sun.com Fri Jan 8 11:50:10 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF1513A6856 for ; Fri, 8 Jan 2010 11:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWvluwEo0PrL for ; Fri, 8 Jan 2010 11:50:10 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id EE6503A683D for ; Fri, 8 Jan 2010 11:50:09 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o08Jo7MQ011313 for ; Fri, 8 Jan 2010 19:50:07 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id o08Jo7dw057206 for ; Fri, 8 Jan 2010 12:50:07 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id o08JK7wa001244; Fri, 8 Jan 2010 13:20:07 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id o08JK6Xf001243; Fri, 8 Jan 2010 13:20:06 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 8 Jan 2010 13:20:06 -0600 From: Nicolas Williams To: Joseph Tardo Message-ID: <20100108192006.GA1061@Sun.COM> References: <20100108010314.GN1516@Sun.COM> <20100108054958.GP1516@Sun.COM> <2C2F1EBA8050E74EA81502D5740B4BD68163BE9739@SJEXCHCCR02.corp.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD68163BE9739@SJEXCHCCR02.corp.ad.broadcom.com> User-Agent: Mutt/1.5.7i Cc: "ipsec@ietf.org" , Melinda Shore , Jack Kohn Subject: Re: [IPsec] Traffic Visibility Future X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 19:50:11 -0000 On Fri, Jan 08, 2010 at 11:14:06AM -0800, Joseph Tardo wrote: > -----Original Message----- > > Also, anything QoS related should really happen outside ESP anyways. > > > In an ideal world maybe. Sometimes the netwwork needs to mark traffic > at the edge switch but doesn't 'trust' the endpoint to do it. So > typically it would be done with policy rules. We're talking about making changes to the end nodes anyways, so why not make them handle QoS correctly? From smoonen@us.ibm.com Fri Jan 8 13:53:42 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0475F3A68EB; Fri, 8 Jan 2010 13:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.931 X-Spam-Level: X-Spam-Status: No, score=-3.931 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1YIE5ji1JYP; Fri, 8 Jan 2010 13:53:40 -0800 (PST) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by core3.amsl.com (Postfix) with ESMTP id 22C8E3A68E8; Fri, 8 Jan 2010 13:53:40 -0800 (PST) Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e37.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id o08LqBVt025545; Fri, 8 Jan 2010 14:52:11 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o08LrR6G087308; Fri, 8 Jan 2010 14:53:27 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o08LrRpW011061; Fri, 8 Jan 2010 14:53:27 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av03.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o08LrRp6011058; Fri, 8 Jan 2010 14:53:27 -0700 In-Reply-To: <20100108191839.GN23285@kebe.East.Sun.COM> References: <20100108191839.GN23285@kebe.East.Sun.COM> To: Dan McDonald MIME-Version: 1.0 X-KeepSent: 3FE25A29:0D215DFC-852576A5:0077AE74; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/08/2010 04:50:21 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/08/2010 04:50:21 PM, Serialize complete at 01/08/2010 04:50:21 PM, S/MIME Sign failed at 01/08/2010 04:50:21 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 01/08/2010 14:53:26, Serialize complete at 01/08/2010 14:53:26 Message-ID: Date: Fri, 8 Jan 2010 16:53:25 -0500 Content-Type: multipart/alternative; boundary="=_alternative 0077F772852576A5_=" Cc: ipsec@ietf.org, ipsec-bounces@ietf.org Subject: Re: [IPsec] No UDP encapsulation with IKEv2 over port 4500? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 21:53:42 -0000 This is a multipart message in MIME format. --=_alternative 0077F772852576A5_= Content-Type: text/plain; charset="US-ASCII" Dan, I think the intent of that text was to read "non-UDP encapsulated" as "non-UDP encapsulated [ESP]". I.e., it is not saying you should support both UDP-encapsulation and vanilla UDP on port 4500; it is saying that you should support UDP encapsulation for an ESP tunnel even if a NAT was not detected for that tunnel. So it might be good to reword it to clarify, Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Dan McDonald To: ipsec@ietf.org Date: 01/08/2010 02:20 PM Subject: [IPsec] No UDP encapsulation with IKEv2 over port 4500? I read this sentence in IKEv2bis... If NAT-T is supported (that is, if NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT), all devices MUST be able to receive and process both UDP encapsulated and non-UDP encapsulated packets at any time. ... and thought of my own implementation. The background reading is here: http://blogs.sun.com/danmcd/entry/detangling_ipsec_nat_traversal_and Today, my implementation marks a port (a socket option to be precise) as a NAT-Traversal port. Traffic to this port that has the zero-SPI gets the zero-SPI stripped and the datagram passed to UDP like any other UDP datagram. If the SPI is non-zero, the UDP portion is stripped, and the packet is passed to ESP for lookup. If there's no SA, the packet is dropped like any other ESP packet with a bad SPI. The text above suggests that if I'm to build IKEv2 properly, I need to not drop these bad-SPI ESP-in-UDP packets (local-port == 4500), but instead pass them up as a UDP datagram without any strippage. Am I understanding this correctly? Or does the text need some more rewhacking? I'm not sure what problem 4500-with-no-encapsulation solves. If you use port 4500, you're most likely going to be doing ESP-in-UDP anyway, and will need the zero-SPI for IKE traffic anyway. And what if you hit that N-in-2^32 chance (where N is the number of inbound SAs) where the high 32-bits of the IKE SPI value is the same as some IPsec SA? Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 0077F772852576A5_= Content-Type: text/html; charset="US-ASCII"
Dan, I think the intent of that text was to read "non-UDP encapsulated" as "non-UDP encapsulated [ESP]".  I.e., it is not saying you should support both UDP-encapsulation and vanilla UDP on port 4500; it is saying that you should support UDP encapsulation for an ESP tunnel even if a NAT was not detected for that tunnel.

So it might be good to reword it to clarify,


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen


From: Dan McDonald <danmcd@sun.com>
To: ipsec@ietf.org
Date: 01/08/2010 02:20 PM
Subject: [IPsec] No UDP encapsulation with IKEv2 over port 4500?




I read this sentence in IKEv2bis...

  If NAT-T is supported (that is, if NAT_DETECTION_*_IP payloads were
  exchanged during IKE_SA_INIT), all devices MUST be able to receive and
  process both UDP encapsulated and non-UDP encapsulated packets at any
  time.

... and thought of my own implementation.  The background reading is here:

                http://blogs.sun.com/danmcd/entry/detangling_ipsec_nat_traversal_and

Today, my implementation marks a port (a socket option to be precise) as a
NAT-Traversal port.  Traffic to this port that has the zero-SPI gets the
zero-SPI stripped and the datagram passed to UDP like any other UDP datagram.

If the SPI is non-zero, the UDP portion is stripped, and the packet is passed
to ESP for lookup.  If there's no SA, the packet is dropped like any other
ESP packet with a bad SPI.

The text above suggests that if I'm to build IKEv2 properly, I need to not
drop these bad-SPI ESP-in-UDP packets (local-port == 4500), but instead pass
them up as a UDP datagram without any strippage.

Am I understanding this correctly?  Or does the text need some more
rewhacking?  I'm not sure what problem 4500-with-no-encapsulation solves.  If
you use port 4500, you're most likely going to be doing ESP-in-UDP anyway,
and will need the zero-SPI for IKE traffic anyway.  And what if you hit that
N-in-2^32 chance (where N is the number of inbound SAs) where the high
32-bits of the IKE SPI value is the same as some IPsec SA?

Dan
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--=_alternative 0077F772852576A5_=-- From manav.bhatia@alcatel-lucent.com Fri Jan 8 16:08:52 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D76603A67A2 for ; Fri, 8 Jan 2010 16:08:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dt6yonyPwtHh for ; Fri, 8 Jan 2010 16:08:52 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 20E6A3A6407 for ; Fri, 8 Jan 2010 16:08:51 -0800 (PST) Received: from horh1.usa.alcatel.com (h172-22-218-55.lucent.com [172.22.218.55]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id o0908Pfe025371; Fri, 8 Jan 2010 18:08:25 -0600 (CST) Received: from mail.apac.alcatel-lucent.com (aprelay03.apac.alcatel-lucent.com [202.65.2.133]) by horh1.usa.alcatel.com (8.13.8/emsr) with ESMTP id o0908KR2013468; Fri, 8 Jan 2010 18:08:21 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by mail.apac.alcatel-lucent.com (8.13.7/8.13.7/Alcanet1.0) with ESMTP id o090Iv25031324; Sat, 9 Jan 2010 08:18:58 +0800 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Sat, 9 Jan 2010 05:38:17 +0530 From: "Bhatia, Manav (Manav)" To: Nicolas Williams , Joseph Tardo Date: Sat, 9 Jan 2010 05:38:15 +0530 Thread-Topic: [IPsec] Traffic Visibility Future Thread-Index: AcqQm8v0wk4dl1tKRzqgWK19NmcIbQAI5evw Message-ID: <7C362EEF9C7896468B36C9B79200D8350AB34BB645@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <20100108010314.GN1516@Sun.COM> <20100108054958.GP1516@Sun.COM> <2C2F1EBA8050E74EA81502D5740B4BD68163BE9739@SJEXCHCCR02.corp.ad.broadcom.com> <20100108192006.GA1061@Sun.COM> In-Reply-To: <20100108192006.GA1061@Sun.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 202.65.2.133 Cc: "ipsec@ietf.org" , Melinda Shore , Jack, Kohn Subject: Re: [IPsec] Traffic Visibility Future X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2010 00:08:52 -0000 > >=20 > > In an ideal world maybe. Sometimes the netwwork needs to=20 > mark traffic > > at the edge switch but doesn't 'trust' the endpoint to do it. So > > typically it would be done with policy rules. >=20 > We're talking about making changes to the end nodes anyways,=20 > so why not > make them handle QoS correctly? QoS remarking is done by the service provider based on various factors (the= SLA negotiated with the customer), and it cannot simply trust what it rece= ives from the customer (the end nodes in this case). Cheers, Manav= From danmcd@sun.com Fri Jan 8 19:22:05 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB9453A6932 for ; Fri, 8 Jan 2010 19:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVzbaNBdO7kg for ; Fri, 8 Jan 2010 19:22:05 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id E81243A687E for ; Fri, 8 Jan 2010 19:22:04 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o093M0Rg019704 for ; Sat, 9 Jan 2010 03:22:02 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KVY00300MDQ1H00@mail-amer.sun.com> for ipsec@ietf.org; Fri, 08 Jan 2010 20:22:00 -0700 (MST) Received: from @ ([unknown] [71.174.113.16]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KVY00NYXMOK2M10@mail-amer.sun.com> for ipsec@ietf.org; Fri, 08 Jan 2010 20:22:00 -0700 (MST) Date: Fri, 08 Jan 2010 22:21:56 -0500 From: Dan McDonald In-reply-to: Sender: Dan.McDonald@sun.com To: ipsec@ietf.org Message-id: <20100109032156.GA20320@mactavish> Organization: Sun Microsystems, Inc. - Solaris Networking & Security References: <20100108191839.GN23285@kebe.East.Sun.COM> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [IPsec] No UDP encapsulation with IKEv2 over port 4500? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2010 03:22:05 -0000 On Fri, Jan 08, 2010 at 04:53:25PM -0500, Scott C Moonen wrote: > Dan, I think the intent of that text was to read "non-UDP encapsulated" as > "non-UDP encapsulated [ESP]". I.e., it is not saying you should support > both UDP-encapsulation and vanilla UDP on port 4500; it is saying that you > should support UDP encapsulation for an ESP tunnel even if a NAT was not > detected for that tunnel. ESP isn't a tunnelling protocol... ;) You meant an ESP SA, right? OTOH, what is an ESP clarification doing in IKEv2? > So it might be good to reword it to clarify, Yes, it definitely would be! Anyone else who's an actual document editor agree with Scott and me? Dan From smoonen@us.ibm.com Fri Jan 8 20:02:15 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 399A43A696D; Fri, 8 Jan 2010 20:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.598 X-Spam-Level: X-Spam-Status: No, score=-5.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHSQz8qValVz; Fri, 8 Jan 2010 20:02:14 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by core3.amsl.com (Postfix) with ESMTP id 27BB63A695B; Fri, 8 Jan 2010 20:02:13 -0800 (PST) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e34.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id o093uDJX001555; Fri, 8 Jan 2010 20:56:13 -0700 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o09421vv092130; Fri, 8 Jan 2010 21:02:01 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o09421xr010878; Fri, 8 Jan 2010 21:02:01 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o0942146010872; Fri, 8 Jan 2010 21:02:01 -0700 In-Reply-To: <20100109032156.GA20320@mactavish> References: <20100108191839.GN23285@kebe.East.Sun.COM> <20100109032156.GA20320@mactavish> To: Dan McDonald MIME-Version: 1.0 X-KeepSent: F0E188AF:19A7CFE0-852576A6:00152B67; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/08/2010 11:01:41 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/08/2010 11:01:41 PM, Serialize complete at 01/08/2010 11:01:41 PM, S/MIME Sign failed at 01/08/2010 11:01:41 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 01/08/2010 21:02:00, Serialize complete at 01/08/2010 21:02:00 Message-ID: Date: Fri, 8 Jan 2010 23:02:00 -0500 Content-Type: multipart/alternative; boundary="=_alternative 001620B0852576A6_=" Cc: ipsec@ietf.org, ipsec-bounces@ietf.org Subject: Re: [IPsec] No UDP encapsulation with IKEv2 over port 4500? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2010 04:02:15 -0000 This is a multipart message in MIME format. --=_alternative 001620B0852576A6_= Content-Type: text/plain; charset="US-ASCII" > ESP isn't a tunnelling protocol... ;) You meant an ESP SA, right? Er, yes. :) > OTOH, what is an ESP clarification doing in IKEv2? IIRC, there was a request at one point to allow for ESP and UDP-encap ESP to be completely interchangeable for any given packet at the discretion of the sender. Several folks, including myself, objected to the broadness of that; I vaguely recall you might have even had something to say about this in reference to IPv6. I think this text represented a compromise -- you could only send UDP-encap if you had evidence that the peer supported NAT traversal (and therefore UDP encapsulation) for this SA. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Dan McDonald To: ipsec@ietf.org Date: 01/08/2010 10:22 PM Subject: Re: [IPsec] No UDP encapsulation with IKEv2 over port 4500? On Fri, Jan 08, 2010 at 04:53:25PM -0500, Scott C Moonen wrote: > Dan, I think the intent of that text was to read "non-UDP encapsulated" as > "non-UDP encapsulated [ESP]". I.e., it is not saying you should support > both UDP-encapsulation and vanilla UDP on port 4500; it is saying that you > should support UDP encapsulation for an ESP tunnel even if a NAT was not > detected for that tunnel. ESP isn't a tunnelling protocol... ;) You meant an ESP SA, right? OTOH, what is an ESP clarification doing in IKEv2? > So it might be good to reword it to clarify, Yes, it definitely would be! Anyone else who's an actual document editor agree with Scott and me? Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 001620B0852576A6_= Content-Type: text/html; charset="US-ASCII"
> ESP isn't a tunnelling protocol... ;)  You meant an ESP SA, right?
Er, yes. :)

> OTOH, what is an ESP clarification doing in IKEv2?

IIRC, there was a request at one point to allow for ESP and UDP-encap ESP to be completely interchangeable for any given packet at the discretion of the sender.  Several folks, including myself, objected to the broadness of that; I vaguely recall you might have even had something to say about this in reference to IPv6.  I think this text represented a compromise -- you could only send UDP-encap if you had evidence that the peer supported NAT traversal (and therefore UDP encapsulation) for this SA.


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen


From: Dan McDonald <danmcd@sun.com>
To: ipsec@ietf.org
Date: 01/08/2010 10:22 PM
Subject: Re: [IPsec] No UDP encapsulation with IKEv2 over port 4500?




On Fri, Jan 08, 2010 at 04:53:25PM -0500, Scott C Moonen wrote:
> Dan, I think the intent of that text was to read "non-UDP encapsulated" as
> "non-UDP encapsulated [ESP]".  I.e., it is not saying you should support
> both UDP-encapsulation and vanilla UDP on port 4500; it is saying that you
> should support UDP encapsulation for an ESP tunnel even if a NAT was not
> detected for that tunnel.

ESP isn't a tunnelling protocol... ;)  You meant an ESP SA, right?

OTOH, what is an ESP clarification doing in IKEv2?

> So it might be good to reword it to clarify,

Yes, it definitely would be!  Anyone else who's an actual document editor
agree with Scott and me?

Dan
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--=_alternative 001620B0852576A6_=-- From smb@cs.columbia.edu Sun Jan 10 12:11:18 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CFB428C102 for ; Sun, 10 Jan 2010 12:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMPY+N7UTw32 for ; Sun, 10 Jan 2010 12:11:15 -0800 (PST) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by core3.amsl.com (Postfix) with ESMTP id 0E4E128C10E for ; Sun, 10 Jan 2010 12:11:14 -0800 (PST) Received: from [192.168.2.69] ([69.38.252.83]) (user=smb2132 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o0AKAaXI006915 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sun, 10 Jan 2010 15:11:11 -0500 (EST) From: Steven Bellovin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 10 Jan 2010 15:11:11 -0500 Message-Id: <2B8448F5-4BE4-4A6B-A836-1FE95446774C@cs.columbia.edu> To: ipsec@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Subject: [IPsec] Volunteers wanted for IPsec configuration experiment X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2010 20:11:18 -0000 We've devised a new IPsec configuration mechanism, and we're performing = a controlled experiment comparing it to today's mechanisms. = Accordingly, we're looking for volunteers to participate in our study. = (It's been submitted to and approved by the university's Institutional = Review Board (IRB).) So -- we're looking for volunteers who are generally familiar with how = IPsec works, but haven't actually configured it anywhere. (The former = does, I think, describe most subscribers to this list...) The study = will take place during the second half of January; we expect it to take = 2-3 hours. There will be modest compensation to participants. =20 I'm being deliberately vague on details of our scheme, for fear of = biasing the results. We will make details available as soon as = possible, and we plan to release our code under an open source license. If you're interested, please contact me. (Note: I checked with the ADs = and WG chairs before posting this message to the IPsec list.) --Steve Bellovin, http://www.cs.columbia.edu/~smb From paul.hoffman@vpnc.org Sun Jan 10 16:25:50 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FCBD3A68B5 for ; Sun, 10 Jan 2010 16:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.926 X-Spam-Level: X-Spam-Status: No, score=-5.926 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnMt-kBRbCvo for ; Sun, 10 Jan 2010 16:25:49 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 950D23A6452 for ; Sun, 10 Jan 2010 16:25:49 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0B0PjQM084613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 10 Jan 2010 17:25:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sun, 10 Jan 2010 16:25:44 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Issue #128: Can implementations not reply fully to Deletes? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 00:25:50 -0000 At 10:55 AM -0800 12/15/09, Paul Hoffman wrote: >Section 1.4.1 says: Normally, the reply in the INFORMATIONAL exchange will contain delete payloads for the paired SAs going in the other direction. There is one exception. If by chance both ends of a set of SAs independently decide to close them, each may send a delete payload and the two requests may cross in the network. > >But, Section 4 (conformance requirements), says: Every implementation MUST be capable of responding to an INFORMATIONAL exchange, but a minimal implementation MAY respond to any INFORMATIONAL message with an empty INFORMATIONAL reply. > >What should we do? Changing the conformance requirement is pretty serious, but not telling the other side that you understand the Delete is also serious. >From the discussion so far, I am inclined to leave the text as-is. Tero is correct that a really minimal implementation might make the other side not understand that it is minimal, but it is still conformant. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Sun Jan 10 16:49:30 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 170AB3A680E for ; Sun, 10 Jan 2010 16:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.938 X-Spam-Level: X-Spam-Status: No, score=-5.938 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DK1awb05f9aj for ; Sun, 10 Jan 2010 16:49:29 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 578383A6405 for ; Sun, 10 Jan 2010 16:49:29 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0B0nPVW086133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 10 Jan 2010 17:49:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sun, 10 Jan 2010 16:49:23 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Issue #130: Do we need to bump the minor version number? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 00:49:30 -0000 At 2:21 PM -0800 12/16/09, Paul Hoffman wrote: >Section 1.7 (Differences Between RFC 4306 and This Document) states: > > The protocol described in this document retains the same major > version number (2) and minor version number (0) as was used in RFC > 4306. That is, the version number is *not* changed from RFC 4306. > >Section 2.5 (Version Numbers and Forward Compatibility) states > > The minor > version number indicates new capabilities, and MUST be ignored by a > node with a smaller minor version number, but used for informational > purposes by the node with the larger minor version number. For > example, it might indicate the ability to process a newly defined > notification message. The node with the larger minor version number > would simply note that its correspondent would not be able to > understand that message and therefore would not send it. > >New notifies have been added to the bis draft. Is a bump in the minor >number warranted? Is there a down side to bumping the minor number? I take the discussion as deciding not to bump the minor version number. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Sun Jan 10 17:13:50 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8514A3A6959 for ; Sun, 10 Jan 2010 17:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgBSkd3Cv+qU for ; Sun, 10 Jan 2010 17:13:36 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 2F1B73A697B for ; Sun, 10 Jan 2010 17:13:36 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0B1DWiV087279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 10 Jan 2010 18:13:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sun, 10 Jan 2010 17:13:30 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Issue #131: Returning TEMPORARY_FAILURE: MUST or SHOULD? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 01:13:50 -0000 At 2:29 PM -0800 12/16/09, Paul Hoffman wrote: >Section 2.8.2 Simultaneous IKE SA Rekeying states: > > If only one peer detects a simultaneous rekey, redundant SAs > are not created. In this case, when the peer that did not notice the > simultaneous rekey gets the request to rekey the IKE SA that it has > already successfully rekeyed, it MUST return TEMPORARY_FAILURE > because it is an IKE SA that it is currently trying to close (whether > or not it has already sent the delete notification for the SA). > >Section 2.25.2 (Collisions While Rekeying or Closing IKE SAs) states: > > If a peer receives a request to close an IKE SA that it is > currently trying to close, it SHOULD reply as usual, and forget about > its own close request. > >Based on the text in Section 2.25.2 it seems that perhaps the MUST in >Section 2.8.2 is really a SHOULD. Or, based on the text in 2.8.2, the >SHOULD in 2.25.2 should be a MUST. This got no response; does anyone have an opinion? --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Sun Jan 10 17:16:14 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0788F3A6959 for ; Sun, 10 Jan 2010 17:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.956 X-Spam-Level: X-Spam-Status: No, score=-5.956 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDRKL0O7Xylr for ; Sun, 10 Jan 2010 17:16:13 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 2CB703A6897 for ; Sun, 10 Jan 2010 17:16:13 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0B1G0gd087409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Jan 2010 18:16:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0C@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0C@il-ex01.ad.checkpoint.com> Date: Sun, 10 Jan 2010 17:15:54 -0800 To: Yaron Sheffer , "ipsec@ietf.org" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, IKEv2-bis!) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 01:16:14 -0000 At 11:04 AM +0200 12/10/09, Yaron Sheffer wrote: >This is to begin a 4 week working group last call for draft-ietf-ipsecme-ikev2bis-06. The target status for this document is Proposed Standard, obsoleting RFC 4306 and RFC 4718. > >Please send your comments to the ipsec list by Jan. 5, 2010, as follow-ups to this message. We hae overshot that by a bit, and there are still three open issues. Please send in any last-minute WG LC comments in the next day or two, if you would. --Paul Hoffman, Director --VPN Consortium From huangmin@huaweisymantec.com Sun Jan 10 22:38:03 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C173E3A69B9 for ; Sun, 10 Jan 2010 22:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHymZBBqKzxJ for ; Sun, 10 Jan 2010 22:38:02 -0800 (PST) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id A655A3A68AB for ; Sun, 10 Jan 2010 22:38:02 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KW2003TGL31EK60@hstga02-in.huaweisymantec.com> for ipsec@ietf.org; Mon, 11 Jan 2010 14:37:49 +0800 (CST) Received: from h00104745 ([10.27.154.97]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KW2000F2L30QA10@hstml01-in.huaweisymantec.com> for ipsec@ietf.org; Mon, 11 Jan 2010 14:37:48 +0800 (CST) From: Min Huang To: Yaron Sheffer Date: Mon, 11 Jan 2010 14:37:48 +0800 Message-id: <002b01ca9288$97867760$619a1b0a@china.huawei.com> X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: AcqSiJcY0j/cHXB+QFCBKHYFTxwJMw== Cc: ipsec@ietf.org Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 06:38:03 -0000 YES to both. The WESP header provides a kind of rapid *deterministic* detection method for ESP_NULL packet. The heuristics method is too complex and it calls for more computing resource and computing time. I doubt the middle box whether will support the heuristics method for ESP_NULL detection. Although including the WESP header into ESP ICV calculation seems modifying ESP, it is necessary to check the WESP header integrity for counter certain attacks. The explicit WESP integrity calculation is OK for me, too. I support WESP for encrypted ESP flow. WESP has the capacity to provide more functions by future extensibility than just traffic visibility for ESP_NULL. Nowadays ESP is used much more widely for encrypted flow than ESP_NULL flow. It is meaningful for middle detection machines to have the ability to detecting encrypted traffic. And then WESP could provide this kind of traffic visibility for both encrypted flow and unencrypted flow in future. regards, Min -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org ] On Behalf Of Yaron Sheffer Sent: Tuesday, January 05, 2010 6:27 AM To: ipsec@ietf.org Subject: [IPsec] Traffic visibility - consensus call Hi, We have had a few "discusses" during the IESG review of the WESP draft. To help resolve them, we would like to reopen the following two questions to WG discussion. Well reasoned answers are certainly appreciated. But plain "yes" or "no" would also be useful in judging the group's consensus. - The current draft (http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11) defines the ESP trailer's ICV calculation to include the WESP header. This has been done to counter certain attacks, but it means that WESP is no longer a simple wrapper around ESP - ESP itself is modified. Do you support this design decision? - The current draft allows WESP to be applied to encrypted ESP flows, in addition to the originally specified ESP-null. This was intended so that encrypted flows can benefit from the future extensibility offered by WESP. But arguably, it positions WESP as an alternative to ESP. Do you support this design decision? Thanks, Yaron _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From Pasi.Eronen@nokia.com Mon Jan 11 00:29:08 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F3753A69E4 for ; Mon, 11 Jan 2010 00:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.742 X-Spam-Level: X-Spam-Status: No, score=-6.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldWFN1Z6Xe3L for ; Mon, 11 Jan 2010 00:29:07 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 19A4E3A69E1 for ; Mon, 11 Jan 2010 00:29:06 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0B8STNT019326; Mon, 11 Jan 2010 10:28:58 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Jan 2010 10:28:53 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Jan 2010 10:28:44 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Mon, 11 Jan 2010 09:28:40 +0100 From: To: Date: Mon, 11 Jan 2010 09:28:38 +0100 Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AcqO4Qq8U0jp5ABRSveZpSy2lL7dmgAJq99QAOP3ciA= Message-ID: <808FD6E27AD4884E94820BC333B2DB775840F4BC84@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jan 2010 08:28:44.0736 (UTC) FILETIME=[16B89400:01CA9298] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 08:29:08 -0000 Ken Grewal wrote: > The either-or on using an ICV or explicitly checking the WESP header > on the recipient was based on the assumption that the threat does > not come from the sender and only from some other malicious entity > after the packet has been sent. > > This was the reason for simplifying the header check by using the > ICV, instead of explicitly checking every field. Note that the current draft *does* explicitly check ever field. Are you proposing removing those checks? =20 Best regards, Pasi (not wearing any hats) From manav.bhatia@alcatel-lucent.com Mon Jan 11 01:03:28 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A5CF3A6903 for ; Mon, 11 Jan 2010 01:03:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlikyLtWnYYU for ; Mon, 11 Jan 2010 01:03:27 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 383203A68EB for ; Mon, 11 Jan 2010 01:03:26 -0800 (PST) Received: from horh1.usa.alcatel.com (h172-22-218-55.lucent.com [172.22.218.55]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id o0B93N0B008133; Mon, 11 Jan 2010 03:03:23 -0600 (CST) Received: from mail.apac.alcatel-lucent.com (h202-65-2-130.alcatel.com [202.65.2.130]) by horh1.usa.alcatel.com (8.13.8/emsr) with ESMTP id o0B93LAi019276; Mon, 11 Jan 2010 03:03:22 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by mail.apac.alcatel-lucent.com (8.13.7/8.13.7/Alcanet1.0) with ESMTP id o0B8v4Ur000609; Mon, 11 Jan 2010 16:57:42 +0800 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Mon, 11 Jan 2010 14:32:57 +0530 From: "Bhatia, Manav (Manav)" To: "Pasi.Eronen@nokia.com" , "ken.grewal@intel.com" Date: Mon, 11 Jan 2010 14:32:55 +0530 Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AcqO4Qq8U0jp5ABRSveZpSy2lL7dmgAJq99QAOP3ciAAAL2D8A== Message-ID: <7C362EEF9C7896468B36C9B79200D8350AB34BB8CB@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB775840F4BC84@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB775840F4BC84@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 202.65.2.130 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 09:03:28 -0000 I believe Ken is alluding to removing the WESP header from the ICV calculat= ion, and relying on explicitly checking the WESP header at the endnodes. Cheers, Manav > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]=20 > On Behalf Of Pasi.Eronen@nokia.com > Sent: Monday, January 11, 2010 1.59 PM > To: ken.grewal@intel.com > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Traffic visibility - consensus call >=20 > Ken Grewal wrote: >=20 > > The either-or on using an ICV or explicitly checking the WESP header > > on the recipient was based on the assumption that the threat does > > not come from the sender and only from some other malicious entity > > after the packet has been sent. > > > > This was the reason for simplifying the header check by using the > > ICV, instead of explicitly checking every field. >=20 > Note that the current draft *does* explicitly check ever field. > Are you proposing removing those checks? > =20 > Best regards, > Pasi > (not wearing any hats) > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > = From dharkins@lounge.org Mon Jan 11 01:23:51 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D8843A6974 for ; Mon, 11 Jan 2010 01:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLy132V5JLIK for ; Mon, 11 Jan 2010 01:23:50 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id BF6883A6927 for ; Mon, 11 Jan 2010 01:23:50 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 63C311022404A; Mon, 11 Jan 2010 01:23:48 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 11 Jan 2010 01:23:48 -0800 (PST) Message-ID: <15b20fc87c91ef1152f2ba42ada44f84.squirrel@www.trepanning.net> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350AB34BB8CB@INBANSXCHMBSA1.in.alcatel- lucent.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB775840F4BC84@NOK-EUMSG-01.mgdnok.nokia.com> <7C362EEF9C7896468B36C9B79200D8350AB34BB8CB@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Mon, 11 Jan 2010 01:23:48 -0800 (PST) From: "Dan Harkins" To: "Bhatia, Manav (Manav)" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "ipsec@ietf.org" , "Pasi.Eronen@nokia.com" , "ken.grewal@intel.com" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 09:23:51 -0000 Manav, So let's say the normal (removed WESP header) ICV calculations by ESP are correct but something doesn't match between the (now unprotected) WESP header and the rest of the packet. Why should the recipient care? WESP is for middleboxes. The end node has an assurance that the _meaningful_ portion of the frame was sent by the claimed sender and was not modified in transit. Any decisions made by a middlebox that might've involved an improperly modified WESP header are over and done with. He doesn't care if the packet was properly handled by middleboxes or not, he got it and it's correct. You trust the end nodes to negotiate WESP and encapsulate their ESP packets in WESP but you don't trust the content they put into those packets. Is that the trust model you're operating on? The more I think of this problem the more worthless WESP becomes. Dan. On Mon, January 11, 2010 1:02 am, Bhatia, Manav (Manav) wrote: > I believe Ken is alluding to removing the WESP header from the ICV > calculation, and relying on explicitly checking the WESP header at the > endnodes. > > Cheers, Manav > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] >> On Behalf Of Pasi.Eronen@nokia.com >> Sent: Monday, January 11, 2010 1.59 PM >> To: ken.grewal@intel.com >> Cc: ipsec@ietf.org >> Subject: Re: [IPsec] Traffic visibility - consensus call >> >> Ken Grewal wrote: >> >> > The either-or on using an ICV or explicitly checking the WESP header >> > on the recipient was based on the assumption that the threat does >> > not come from the sender and only from some other malicious entity >> > after the packet has been sent. >> > >> > This was the reason for simplifying the header check by using the >> > ICV, instead of explicitly checking every field. >> >> Note that the current draft *does* explicitly check ever field. >> Are you proposing removing those checks? >> >> Best regards, >> Pasi >> (not wearing any hats) >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From manav.bhatia@alcatel-lucent.com Mon Jan 11 01:32:32 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D7393A68B7 for ; Mon, 11 Jan 2010 01:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaWo-xHyFVda for ; Mon, 11 Jan 2010 01:32:31 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by core3.amsl.com (Postfix) with ESMTP id 6AEA63A65A6 for ; Mon, 11 Jan 2010 01:32:30 -0800 (PST) Received: from horh1.usa.alcatel.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id o0B9WSfU019213; Mon, 11 Jan 2010 03:32:28 -0600 (CST) Received: from mail.apac.alcatel-lucent.com (aprelay03.apac.alcatel-lucent.com [202.65.2.133]) by horh1.usa.alcatel.com (8.13.8/emsr) with ESMTP id o0B9WQGr006363; Mon, 11 Jan 2010 03:32:27 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by mail.apac.alcatel-lucent.com (8.13.7/8.13.7/Alcanet1.0) with ESMTP id o0B9hDsA019901; Mon, 11 Jan 2010 17:43:24 +0800 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Mon, 11 Jan 2010 15:02:04 +0530 From: "Bhatia, Manav (Manav)" To: Dan Harkins Date: Mon, 11 Jan 2010 15:02:03 +0530 Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AcqSn8xSEVEiuszlTUut50h0b+EfPQAAL5Aw Message-ID: <7C362EEF9C7896468B36C9B79200D8350AB34BB8FB@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB775840F4BC84@NOK-EUMSG-01.mgdnok.nokia.com> <7C362EEF9C7896468B36C9B79200D8350AB34BB8CB@INBANSXCHMBSA1.in.alcatel-lucent.com> <15b20fc87c91ef1152f2ba42ada44f84.squirrel@www.trepanning.net> In-Reply-To: <15b20fc87c91ef1152f2ba42ada44f84.squirrel@www.trepanning.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 172.22.12.27 X-Scanned-By: MIMEDefang 2.64 on 202.65.2.133 Cc: "ipsec@ietf.org" , "Pasi.Eronen@nokia.com" , "ken.grewal@intel.com" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 09:32:32 -0000 Dan, >=20 > You trust the end nodes to negotiate WESP and encapsulate their ESP > packets in WESP but you don't trust the content they put into those > packets. Is that the trust model you're operating on? No. We trust the end nodes to put the right information in the WESP header. But= , we don't trust the intermediaries, that could have mangled the packet so = that it goes through the firewall/deep inspection device. If that happens, then the packet should not be consumed, which would make t= he attack by a malicious middle box worthless. Hope this helps. Manav >=20 > The more I think of this problem the more worthless WESP becomes. >=20 > Dan. >=20 > On Mon, January 11, 2010 1:02 am, Bhatia, Manav (Manav) wrote: > > I believe Ken is alluding to removing the WESP header from the ICV > > calculation, and relying on explicitly checking the WESP=20 > header at the > > endnodes. > > > > Cheers, Manav > > > >> -----Original Message----- > >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > >> On Behalf Of Pasi.Eronen@nokia.com > >> Sent: Monday, January 11, 2010 1.59 PM > >> To: ken.grewal@intel.com > >> Cc: ipsec@ietf.org > >> Subject: Re: [IPsec] Traffic visibility - consensus call > >> > >> Ken Grewal wrote: > >> > >> > The either-or on using an ICV or explicitly checking the=20 > WESP header > >> > on the recipient was based on the assumption that the threat does > >> > not come from the sender and only from some other=20 > malicious entity > >> > after the packet has been sent. > >> > > >> > This was the reason for simplifying the header check by using the > >> > ICV, instead of explicitly checking every field. > >> > >> Note that the current draft *does* explicitly check ever field. > >> Are you proposing removing those checks? > >> > >> Best regards, > >> Pasi > >> (not wearing any hats) > >> _______________________________________________ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > >> > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > >=20 >=20 > = From dharkins@lounge.org Mon Jan 11 02:00:23 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A95E93A69C2 for ; Mon, 11 Jan 2010 02:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAInbQARb2jc for ; Mon, 11 Jan 2010 02:00:23 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id EBDE93A69BD for ; Mon, 11 Jan 2010 02:00:22 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 5500F1022404A; Mon, 11 Jan 2010 02:00:20 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 11 Jan 2010 02:00:20 -0800 (PST) Message-ID: In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350AB34BB8FB@INBANSXCHMBSA1.in.alcatel- lucent.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB775840F4BC84@NOK-EUMSG-01.mgdnok.nokia.com> <7C362EEF9C7896468B36C9B79200D8350AB34BB8CB@INBANSXCHMBSA1.in.alcatel-lucent.com> <15b20fc87c91ef1152f2ba42ada44f84.squirrel@www.trepanning.net> <7C362EEF9C7896468B36C9B79200D8350AB34BB8FB@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Mon, 11 Jan 2010 02:00:20 -0800 (PST) From: "Dan Harkins" To: "Bhatia, Manav (Manav)" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "ipsec@ietf.org" , "Pasi.Eronen@nokia.com" , Dan Harkins , "ken.grewal@intel.com" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 10:00:23 -0000 Manav, On Mon, January 11, 2010 1:32 am, Bhatia, Manav (Manav) wrote: > Dan, > >> >> You trust the end nodes to negotiate WESP and encapsulate their ESP >> packets in WESP but you don't trust the content they put into those >> packets. Is that the trust model you're operating on? > > No. > > We trust the end nodes to put the right information in the WESP header. > But, we don't trust the intermediaries, that could have mangled the packet > so that it goes through the firewall/deep inspection device. The fact that you require deep inspection of a packet sent by an end node means you don't trust the end node to put good bits into the packet. Yet you trust the end node to negotiate WESP and properly encapsulate ESP with WESP and do the checking of the (now unprotected) WESP header and normal ESP header. That's weird. If (the WESP header of) a packet was modified such that it avoided deep packet inspection but still passes a source and (non-WESP header) data integrity check why would you want to drop that packet? End-to-end protection (via ESP) means that you don't have to trust the intermediaries. And you don't. Great. So what exactly is the threat? Dan. From smoonen@us.ibm.com Mon Jan 11 04:54:52 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FBDE3A67C1; Mon, 11 Jan 2010 04:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.798 X-Spam-Level: X-Spam-Status: No, score=-3.798 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMA6QoWeZvcs; Mon, 11 Jan 2010 04:54:51 -0800 (PST) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by core3.amsl.com (Postfix) with ESMTP id 2D4D03A67AF; Mon, 11 Jan 2010 04:54:51 -0800 (PST) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e37.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id o0BCrKv8015672; Mon, 11 Jan 2010 05:53:20 -0700 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o0BCsdxL113198; Mon, 11 Jan 2010 05:54:39 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o0BCsc0i015168; Mon, 11 Jan 2010 05:54:38 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av01.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o0BCscSd015156; Mon, 11 Jan 2010 05:54:38 -0700 In-Reply-To: References: To: Paul Hoffman MIME-Version: 1.0 X-KeepSent: B3BF0EE0:EDB8F348-852576A8:0045392A; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/11/2010 07:37:22 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/11/2010 07:37:22 AM, Serialize complete at 01/11/2010 07:37:22 AM, S/MIME Sign failed at 01/11/2010 07:37:23 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 01/11/2010 05:54:37, Serialize complete at 01/11/2010 05:54:37 Message-ID: Date: Mon, 11 Jan 2010 07:54:37 -0500 Content-Type: multipart/alternative; boundary="=_alternative 004556CF852576A8_=" Cc: IPsecme WG , ipsec-bounces@ietf.org Subject: Re: [IPsec] Issue #128: Can implementations not reply fully to Deletes? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 12:54:52 -0000 This is a multipart message in MIME format. --=_alternative 004556CF852576A8_= Content-Type: text/plain; charset="US-ASCII" [Worm-can-opener hat] I'm ok with that. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Paul Hoffman To: IPsecme WG Date: 01/10/2010 07:26 PM Subject: Re: [IPsec] Issue #128: Can implementations not reply fully to Deletes? At 10:55 AM -0800 12/15/09, Paul Hoffman wrote: >Section 1.4.1 says: Normally, the reply in the INFORMATIONAL exchange will contain delete payloads for the paired SAs going in the other direction. There is one exception. If by chance both ends of a set of SAs independently decide to close them, each may send a delete payload and the two requests may cross in the network. > >But, Section 4 (conformance requirements), says: Every implementation MUST be capable of responding to an INFORMATIONAL exchange, but a minimal implementation MAY respond to any INFORMATIONAL message with an empty INFORMATIONAL reply. > >What should we do? Changing the conformance requirement is pretty serious, but not telling the other side that you understand the Delete is also serious. >From the discussion so far, I am inclined to leave the text as-is. Tero is correct that a really minimal implementation might make the other side not understand that it is minimal, but it is still conformant. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 004556CF852576A8_= Content-Type: text/html; charset="US-ASCII"
[Worm-can-opener hat] I'm ok with that.


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen


From: Paul Hoffman <paul.hoffman@vpnc.org>
To: IPsecme WG <ipsec@ietf.org>
Date: 01/10/2010 07:26 PM
Subject: Re: [IPsec] Issue #128: Can implementations not reply fully to Deletes?




At 10:55 AM -0800 12/15/09, Paul Hoffman wrote:
>Section 1.4.1 says: Normally, the reply in the INFORMATIONAL exchange will contain delete payloads for the paired SAs going in the other direction. There is one exception. If by chance both ends of a set of SAs independently decide to close them, each may send a delete payload and the two requests may cross in the network.
>
>But, Section 4 (conformance requirements), says: Every implementation MUST be capable of responding to an INFORMATIONAL exchange, but a minimal implementation MAY respond to any INFORMATIONAL message with an empty INFORMATIONAL reply.
>
>What should we do? Changing the conformance requirement is pretty serious, but not telling the other side that you understand the Delete is also serious.

>From the discussion so far, I am inclined to leave the text as-is. Tero is correct that a really minimal implementation might make the other side not understand that it is minimal, but it is still conformant.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--=_alternative 004556CF852576A8_=-- From ken.grewal@intel.com Mon Jan 11 08:16:31 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF3713A688D for ; Mon, 11 Jan 2010 08:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqOSpMQWqVPM for ; Mon, 11 Jan 2010 08:16:30 -0800 (PST) Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by core3.amsl.com (Postfix) with ESMTP id CFABB28C115 for ; Mon, 11 Jan 2010 08:16:30 -0800 (PST) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 11 Jan 2010 08:16:28 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.47,316,1257148800"; d="scan'208";a="231432424" Received: from rrsmsx604.amr.corp.intel.com ([10.31.0.170]) by azsmga001.ch.intel.com with ESMTP; 11 Jan 2010 08:16:28 -0800 Received: from rrsmsx601.amr.corp.intel.com (10.31.0.151) by rrsmsx604.amr.corp.intel.com (10.31.0.170) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 11 Jan 2010 09:16:28 -0700 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Mon, 11 Jan 2010 09:16:27 -0700 From: "Grewal, Ken" To: "Pasi.Eronen@nokia.com" Date: Mon, 11 Jan 2010 09:15:13 -0700 Thread-Topic: [IPsec] Traffic visibility - consensus call Thread-Index: AcqO4Qq8U0jp5ABRSveZpSy2lL7dmgAJq99QAOP3ciAAEDxGEA== Message-ID: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB775840F4BC84@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB775840F4BC84@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 16:16:31 -0000 Hi Pasi,=20 The text for explicitly checking the fields was added in and this was follo= wed by adding the ICV check for simplification, without removing the aforem= entioned text, hence we ended up with both 'checks'! Based on subsequent discussions, the WG appears to be in favor of removing = the extended ICV and keeping the explicit checks, so we will incorporate th= e appropriate modifications for this and other items raised when the next r= ev of the document is generated.=20 Thanks,=20 - Ken =20 >-----Original Message----- >From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] >Sent: Monday, January 11, 2010 12:29 AM >To: Grewal, Ken >Cc: ipsec@ietf.org >Subject: RE: [IPsec] Traffic visibility - consensus call > >Ken Grewal wrote: > >> The either-or on using an ICV or explicitly checking the WESP header >> on the recipient was based on the assumption that the threat does >> not come from the sender and only from some other malicious entity >> after the packet has been sent. >> >> This was the reason for simplifying the header check by using the >> ICV, instead of explicitly checking every field. > >Note that the current draft *does* explicitly check ever field. >Are you proposing removing those checks? > >Best regards, >Pasi >(not wearing any hats) From smoonen@us.ibm.com Mon Jan 11 10:11:05 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B97E83A6880 for ; Mon, 11 Jan 2010 10:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=-2.083, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9W6mufNW8hh for ; Mon, 11 Jan 2010 10:11:04 -0800 (PST) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by core3.amsl.com (Postfix) with ESMTP id 541AE3A68F2 for ; Mon, 11 Jan 2010 10:11:04 -0800 (PST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e37.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id o0BI9djK006092 for ; Mon, 11 Jan 2010 11:09:39 -0700 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o0BIAvNo160170 for ; Mon, 11 Jan 2010 11:10:57 -0700 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o0BICof2021775 for ; Mon, 11 Jan 2010 11:12:50 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av06.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o0BICoBs021769 for ; Mon, 11 Jan 2010 11:12:50 -0700 MIME-Version: 1.0 X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/11/2010 01:10:27 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/11/2010 01:10:27 PM, Serialize complete at 01/11/2010 01:10:27 PM, S/MIME Sign failed at 01/11/2010 01:10:27 PM: The cryptographic key was not found, S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/11/2010 01:10:40 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/11/2010 01:10:40 PM, Serialize complete at 01/11/2010 01:10:40 PM, S/MIME Sign failed at 01/11/2010 01:10:40 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 01/11/2010 11:10:47, Serialize complete at 01/11/2010 11:10:47 To: ipsec@ietf.org X-KeepSent: C4D65BD8:72119D70-852576A8:00630DE0; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen Message-ID: Date: Mon, 11 Jan 2010 13:10:47 -0500 Content-Type: multipart/alternative; boundary="=_alternative 0063DA86852576A8_=" Subject: [IPsec] ikev2bis clarification on port floating X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 18:11:05 -0000 This is a multipart message in MIME format. --=_alternative 0063DA86852576A8_= Content-Type: text/plain; charset="US-ASCII" ikev2bis says: An initiator can float to port 4500, regardless whether or not there is NAT, even at the beginning of IKE. When either side is using port 4500, sending with UDP encapsulation is not required, but understanding received packets with UDP encapsulation is required. UDP encapsulation MUST NOT be done on port 500. If NAT-T is supported (that is, if NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT), all devices MUST be able to receive and process both UDP encapsulated and non-UDP encapsulated packets at any time. Either side can decide whether or not to use UDP encapsulation irrespective of the choice made by the other side. However, if a NAT is detected, both devices MUST send UDP encapsulated packets. Dan has suggested that we clarify the part about UDP encapsulation. However, I have an additional question about the port floating aspect. Do we intend to say that an initiator may float to 4500, period, or is it only allowed to do so if NAT_DETECTION_* payloads are exchanged? Can the initiator have any confidence that the responder is even listening on port 4500 unless the responder sends a NAT-detection payload? Also, we have not defined floating, so it is not clear what is really intended here. By "float" do we mean that the initiator may send the IKE_SA_INIT request to/from port 4500? Or are you only allowed to float on the IKE_AUTH request? Presumably there is at least some justification for floating the IKE_SA_INIT request if you have an existing SA that you are reauthenticating. But in the absence of a NAT_DETECTION_* payload or an existing SA, I'm not sure that floating should be allowed, since the MUST for listening on port 4500 appears only within the conditional context of NAT traversal support. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen --=_alternative 0063DA86852576A8_= Content-Type: text/html; charset="US-ASCII"
ikev2bis says:

   An initiator can float to port 4500, regardless whether or not there
   is NAT, even at the beginning of IKE.  When either side is using port
   4500, sending with UDP encapsulation is not required, but
   understanding received packets with UDP encapsulation is required.
   UDP encapsulation MUST NOT be done on port 500.  If NAT-T is
   supported (that is, if NAT_DETECTION_*_IP payloads were exchanged
   during IKE_SA_INIT), all devices MUST be able to receive and process
   both UDP encapsulated and non-UDP encapsulated packets at any time.
   Either side can decide whether or not to use UDP encapsulation
   irrespective of the choice made by the other side.  However, if a NAT
   is detected, both devices MUST send UDP encapsulated packets.

Dan has suggested that we clarify the part about UDP encapsulation.  However, I have an additional question about the port floating aspect.  Do we intend to say that an initiator may float to 4500, period, or is it only allowed to do so if NAT_DETECTION_* payloads are exchanged?  Can the initiator have any confidence that the responder is even listening on port 4500 unless the responder sends a NAT-detection payload?  Also, we have not defined floating, so it is not clear what is really intended here.  By "float" do we mean that the initiator may send the IKE_SA_INIT request to/from port 4500?  Or are you only allowed to float on the IKE_AUTH request?

Presumably there is at least some justification for floating the IKE_SA_INIT request if you have an existing SA that you are reauthenticating.  But in the absence of a NAT_DETECTION_* payload or an existing SA, I'm not sure that floating should be allowed, since the MUST for listening on port 4500 appears only within the conditional context of NAT traversal support.


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen --=_alternative 0063DA86852576A8_=-- From smoonen@us.ibm.com Mon Jan 11 11:41:04 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5634E3A6936 for ; Mon, 11 Jan 2010 11:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.217 X-Spam-Level: X-Spam-Status: No, score=-4.217 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e93YHlF+1zq1 for ; Mon, 11 Jan 2010 11:40:59 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by core3.amsl.com (Postfix) with ESMTP id 9E1223A692D for ; Mon, 11 Jan 2010 11:40:59 -0800 (PST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id o0BJZ4p8016477 for ; Mon, 11 Jan 2010 12:35:04 -0700 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o0BJekv4094360 for ; Mon, 11 Jan 2010 12:40:47 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o0BJebeN003801 for ; Mon, 11 Jan 2010 12:40:37 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av01.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o0BJeaDh003793 for ; Mon, 11 Jan 2010 12:40:36 -0700 In-Reply-To: References: To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: 76269D1A:B03F8DE3-852576A8:006A8CC3; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/11/2010 02:38:52 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/11/2010 02:38:52 PM, Serialize complete at 01/11/2010 02:38:52 PM, S/MIME Sign failed at 01/11/2010 02:38:52 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 01/11/2010 12:40:36, Serialize complete at 01/11/2010 12:40:36 Message-ID: Date: Mon, 11 Jan 2010 14:40:35 -0500 Content-Type: multipart/alternative; boundary="=_alternative 006BEDE1852576A8_=" Subject: Re: [IPsec] ikev2bis clarification on port floating X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 19:41:04 -0000 This is a multipart message in MIME format. --=_alternative 006BEDE1852576A8_= Content-Type: text/plain; charset="US-ASCII" Further question -- is it ok for the IKE negotiation *not* to float and then for the ESP traffic to later arrive UDP-encapped on port 4500? It seems like it would be wise not to send UDP-encapped ESP unless you've already verified that the 4500-4500 port pairing works during an IKE exchange. But the text in section 2.31 doesn't seem to exclude that possibility. Personally, I think we should: 1) Rephrase the "non-UDP encapsulated packets" wording as Dan requested. Possible starting point: "receive and process IPsec packets with or without UDP encapsulation at any time." 2) Disallow floating on IKE_SA_INIT unless you have prior knowledge the peer supports NAT traversal (i.e., an existing SA is being authenticated, which itself exchanged NAT_DETECTION_* payloads even if it may not have detected a NAT). 3) Disallow this elective use of UDP-encap unless you have already floated the IKE SA. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Scott C Moonen/Raleigh/IBM To: ipsec@ietf.org Date: 01/11/2010 01:10 PM Subject: ikev2bis clarification on port floating ikev2bis says: An initiator can float to port 4500, regardless whether or not there is NAT, even at the beginning of IKE. When either side is using port 4500, sending with UDP encapsulation is not required, but understanding received packets with UDP encapsulation is required. UDP encapsulation MUST NOT be done on port 500. If NAT-T is supported (that is, if NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT), all devices MUST be able to receive and process both UDP encapsulated and non-UDP encapsulated packets at any time. Either side can decide whether or not to use UDP encapsulation irrespective of the choice made by the other side. However, if a NAT is detected, both devices MUST send UDP encapsulated packets. Dan has suggested that we clarify the part about UDP encapsulation. However, I have an additional question about the port floating aspect. Do we intend to say that an initiator may float to 4500, period, or is it only allowed to do so if NAT_DETECTION_* payloads are exchanged? Can the initiator have any confidence that the responder is even listening on port 4500 unless the responder sends a NAT-detection payload? Also, we have not defined floating, so it is not clear what is really intended here. By "float" do we mean that the initiator may send the IKE_SA_INIT request to/from port 4500? Or are you only allowed to float on the IKE_AUTH request? Presumably there is at least some justification for floating the IKE_SA_INIT request if you have an existing SA that you are reauthenticating. But in the absence of a NAT_DETECTION_* payload or an existing SA, I'm not sure that floating should be allowed, since the MUST for listening on port 4500 appears only within the conditional context of NAT traversal support. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen --=_alternative 006BEDE1852576A8_= Content-Type: text/html; charset="US-ASCII"
Further question -- is it ok for the IKE negotiation *not* to float and then for the ESP traffic to later arrive UDP-encapped on port 4500?  It seems like it would be wise not to send UDP-encapped ESP unless you've already verified that the 4500-4500 port pairing works during an IKE exchange.  But the text in section 2.31 doesn't seem to exclude that possibility.

Personally, I think we should:

1) Rephrase the "non-UDP encapsulated packets" wording as Dan requested.  Possible starting point: "receive and process IPsec packets with or without UDP encapsulation at any time."
2) Disallow floating on IKE_SA_INIT unless you have prior knowledge the peer supports NAT traversal (i.e., an existing SA is being authenticated, which itself exchanged NAT_DETECTION_* payloads even if it may not have detected a NAT).
3) Disallow this elective use of UDP-encap unless you have already floated the IKE SA.


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen


From: Scott C Moonen/Raleigh/IBM
To: ipsec@ietf.org
Date: 01/11/2010 01:10 PM
Subject: ikev2bis clarification on port floating



ikev2bis says:

   An initiator can float to port 4500, regardless whether or not there
   is NAT, even at the beginning of IKE.  When either side is using port
   4500, sending with UDP encapsulation is not required, but
   understanding received packets with UDP encapsulation is required.
   UDP encapsulation MUST NOT be done on port 500.  If NAT-T is
   supported (that is, if NAT_DETECTION_*_IP payloads were exchanged
   during IKE_SA_INIT), all devices MUST be able to receive and process
   both UDP encapsulated and non-UDP encapsulated packets at any time.
   Either side can decide whether or not to use UDP encapsulation
   irrespective of the choice made by the other side.  However, if a NAT
   is detected, both devices MUST send UDP encapsulated packets.

Dan has suggested that we clarify the part about UDP encapsulation.  However, I have an additional question about the port floating aspect.  Do we intend to say that an initiator may float to 4500, period, or is it only allowed to do so if NAT_DETECTION_* payloads are exchanged?  Can the initiator have any confidence that the responder is even listening on port 4500 unless the responder sends a NAT-detection payload?  Also, we have not defined floating, so it is not clear what is really intended here.  By "float" do we mean that the initiator may send the IKE_SA_INIT request to/from port 4500?  Or are you only allowed to float on the IKE_AUTH request?

Presumably there is at least some justification for floating the IKE_SA_INIT request if you have an existing SA that you are reauthenticating.  But in the absence of a NAT_DETECTION_* payload or an existing SA, I'm not sure that floating should be allowed, since the MUST for listening on port 4500 appears only within the conditional context of NAT traversal support.


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

--=_alternative 006BEDE1852576A8_=-- From kivinen@iki.fi Mon Jan 11 23:54:48 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EC053A68DE for ; Mon, 11 Jan 2010 23:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.516 X-Spam-Level: X-Spam-Status: No, score=-1.516 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iLliLJ8NZ2j for ; Mon, 11 Jan 2010 23:54:47 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 8FBB13A6765 for ; Mon, 11 Jan 2010 23:54:46 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0C7sd1K010027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jan 2010 09:54:39 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0C7saS5009747; Tue, 12 Jan 2010 09:54:36 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19276.10940.439692.78671@fireball.kivinen.iki.fi> Date: Tue, 12 Jan 2010 09:54:36 +0200 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 25 min X-Total-Time: 26 min Cc: ipsec@ietf.org Subject: [IPsec] ikev2bis clarification on port floating X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 07:54:48 -0000 Scott C Moonen writes: > ikev2bis says: This whole section is about NAT-T and it has text saying: Support for NAT traversal is optional. In this section only, requirements listed as MUST apply only to implementations supporting NAT traversal. meaning everything said here only applies if and only if implementations support NAT traversal. > An initiator can float to port 4500, regardless whether or not there > is NAT, even at the beginning of IKE. This text is saying same thing than what is said below i.e. as responder MUST listen on port 4500 as well as port 500 and it MUST respond to the IP address and port from which packets arrived (first bullet point), then if initiator knows responder supports NAT-T it can change to the port 4500 regardless whether there is NAT or not even for IKE_SA_INIT packets. The initiator still needs to know (or suspect) that the other end supports NAT-T before doing that. One way of knowing that is that there was previously IKE SA with the responder already and that was dropped for some reason and inititor is recreating it (this is the original reason for allowing this). Another reason might be that initiator sees that its own IP-address is from private address range (for example 10.0.0.22) and responders IP-address is from global address range, and it is expected there is NAT between, or otherwise the communiation will not work, thus other end needs to support NAT-T or otherwise the communication will not work. Anyways this text needs to be modified to remove term "float", as we decided earlier that (during RFC 3947/3948 time) that we DO NOT use term float, but instead use term "change to port 4500" or "use port 4500" or similar. I.e. this text needs to be changed to say: An initiator can use port 4500, regardless whether or not there is NAT, even at the beginning of IKE. > When either side is using port > 4500, sending with UDP encapsulation is not required, but > understanding received packets with UDP encapsulation is required. As we are talking about UDP encapsulation there, it is talking about UDP encapsulated IPsec packets (ESP) not about IKE packets. I.e. this says you needs to understand UDP encapsulated ESP packets even when there is no NAT if port 4500 is used. And on the other hand you can also use normal ESP packets even when you are using port 4500 (i.e. if there is no NAT). > UDP encapsulation MUST NOT be done on port 500. This is saying that with port 500 you cannot use UDP encapsulated IPsec (ESP) packets. > If NAT-T is > supported (that is, if NAT_DETECTION_*_IP payloads were exchanged > during IKE_SA_INIT), all devices MUST be able to receive and process > both UDP encapsulated and non-UDP encapsulated packets at any time. This is saying that regardless whether you changed to port 4500 but if both ends indicated that they support NAT-T by exhchanging NAT_DETECTION_*_IP payloads), you still need to be able to process both UDP encapsulated ESP (at port 4500) and normal IPsec ESP packets. > Either side can decide whether or not to use UDP encapsulation > irrespective of the choice made by the other side. However, if a NAT > is detected, both devices MUST send UDP encapsulated packets. This says both ends can decide themselves whether they use UDP encapsulation or not, but they MUST use it if NAT was detected. > Dan has suggested that we clarify the part about UDP encapsulation. > However, I have an additional question about the port floating aspect. Do > we intend to say that an initiator may float to 4500, period, or is it > only allowed to do so if NAT_DETECTION_* payloads are exchanged? Initiator can try to use port 4500. If responder supports NAT-T it will respond to that and everything works. If responder does not support NAT-T (or it is not allowed) then responder will not answer to packets to port 4500. Because of this the initiator might not want to use it unless it knows that other end supports NAT-T. > Can the initiator have any confidence that the responder is even > listening on port 4500 unless the responder sends a NAT-detection > payload? If it knows from somewhere that other end supports NAT-T (from policy, from previous communications, or because it knows it is behind NAT (i.e. there is no point of trying to communicate if other end does not support NAT)) it can use port 4500. Responder MUST be listening on port 4500 if it suports NAT-T, regardless whether NAT_DETECTION_* payloads have been exchanged. I.e. you need to start listing on port 500 and 4500 at the same time when you start the IKE daemon if you support NAT-T. You cannot postpone opening port 4500 only after NAT_DETECTION_* payload exchanges. > Also, we have not defined floating, so it is not clear what is > really intended here. By "float" do we mean that the initiator may > send the IKE_SA_INIT request to/from port 4500? Or are you only > allowed to float on the IKE_AUTH request? Using term "float" is wrong in the text. It should say "can use port 4500" instead of using term float. And yes, you are allowed to send IKE_SA_INIT to/from port 4500. > Presumably there is at least some justification for floating the > IKE_SA_INIT request if you have an existing SA that you are > reauthenticating. That is one example. Another is that your IKE SA was dropped for some reason, and you are recreating it (for example the GW was rebooted). > But in the absence of a NAT_DETECTION_* payload or an > existing SA, I'm not sure that floating should be allowed, since the MUST > for listening on port 4500 appears only within the conditional context of > NAT traversal support. It is conditional on the context of the implementation SUPPORTING NAT-T, not whether it is in use. I.e. your code will have support for NAT-T even when NAT_DETECTION_* payload are not exchanged so you need to listen port 4500. On the other hand if you disable NAT-T on your policy, then your implementation does not support NAT-T at all in its current policy, and then you do not listen port 4500 (or respond). -- kivinen@iki.fi From kivinen@iki.fi Tue Jan 12 00:32:53 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C31ED3A68F6 for ; Tue, 12 Jan 2010 00:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3ckxhUPlegW for ; Tue, 12 Jan 2010 00:32:52 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 70EEC3A68B4 for ; Tue, 12 Jan 2010 00:32:51 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0C8WjdQ019266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jan 2010 10:32:45 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0C8WjIm009996; Tue, 12 Jan 2010 10:32:45 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19276.13229.412264.229979@fireball.kivinen.iki.fi> Date: Tue, 12 Jan 2010 10:32:45 +0200 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 13 min X-Total-Time: 37 min Cc: ipsec@ietf.org Subject: Re: [IPsec] ikev2bis clarification on port floating X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 08:32:53 -0000 Scott C Moonen writes: > Further question -- is it ok for the IKE negotiation *not* to float and > then for the ESP traffic to later arrive UDP-encapped on port 4500? Yes, provided the NAT_DETECTION_* payloads were exchanged, (i.e. the implementation knows other end supports NAT-T). > It seems like it would be wise not to send UDP-encapped ESP unless > you've already verified that the 4500-4500 port pairing works during > an IKE exchange. But the text in section 2.31 doesn't seem to > exclude that possibility. That was the intention, i.e. even when there was no NAT (regardless whether you use port 500 or 4500), but other end did support NAT-T (i.e. NAT_DETECTION_* payloads were exchanged), then you can use either normal ESP packets, or UDP encapsulated ESP packets on port 4500. This is something that is already required for MOBIKE, as with MOBIKE the host might suddenly notice that you moved to new IP-address which do have NAT, thus you might need to enable NAT-T. On the other hand with MOBIKE you always change to use port 4500 in the beginning to simplify things. The current text does not say when you would be sending such packets, it just says that you MUST be able to receive them. > Personally, I think we should: > > 1) Rephrase the "non-UDP encapsulated packets" wording as Dan requested. > Possible starting point: "receive and process IPsec packets with or > without UDP encapsulation at any time." That change seems to be good. > 2) Disallow floating on IKE_SA_INIT unless you have prior knowledge the > peer supports NAT traversal (i.e., an existing SA is being authenticated, > which itself exchanged NAT_DETECTION_* payloads even if it may not have > detected a NAT). Why do you want to disallow that? You might not have prior knowledge, but you might have good hints that other end needs to support NAT-T or otherwise communications does not work so better start at port 4500 directly. Also some minimal implementations supporting NAT-T could always start at port 4500 as they do not support normal IPsec at all, only UDP encapsulated IPsec and they always act as they were behind NAT. > 3) Disallow this elective use of UDP-encap unless you have already floated > the IKE SA. Again why do that? I think it is easier to just make it so that you can always use normal IPsec or UDP encapsulated IPsec if you support NAT-T regardless whether you have changed ports etc... I.e if you get packet to your IKE NAT port (4500) you check the SPI and if it is there you strip UDP header and pass it to IPsec engine. If there is 4 bytes of zeros in the beginning then you pass it to the UDP stack. No need to check whether there was NAT-T enabled for this specific host etc. -- kivinen@iki.fi From yaronf@checkpoint.com Tue Jan 12 03:37:33 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31D743A6873 for ; Tue, 12 Jan 2010 03:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFU8Uht4FpfJ for ; Tue, 12 Jan 2010 03:37:32 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 171FA3A67BE for ; Tue, 12 Jan 2010 03:37:31 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0CBbST7008996 for ; Tue, 12 Jan 2010 13:37:28 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 12 Jan 2010 13:37:42 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Tue, 12 Jan 2010 13:37:26 +0200 Thread-Topic: Traffic visibility - proposed way forward Thread-Index: AcqSuO8rwfrDHMTFRqqAnab43TA7+gAwLu5Q Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A2166C@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] Traffic visibility - proposed way forward X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 11:37:33 -0000 Hi, Thanks to the IESG feedback, we have had a long and enlightening discussion= on the list. But we have not reached consensus on either of the two questi= ons. As a result, Paul and I are proposing the following resolution, which = appears to be acceptable both to the draft's editors and to the IESG member= s. Unless there are strong objections from multiple WG participants, we wil= l ask the editors to rev the draft in the next few days according to this p= roposal. Motivation: retain deterministic traffic visibility for middleboxes with a = smooth migration path, while ensuring that WESP does not change ESP, and is= not (nor seen as) ESPv4. - Return ICV to its former ESP-only definition. - Maintain the Encrypted bit, as per the latest version of the draft. - Make the padding field have the minimal possible length, possibly 0. Elim= inate the Padding Length field (the first octet). [Essentially roll back to= version -10]. - WESPv1 will not accept extensions. Any extensions will need a WESPv2, inc= luding some integrity protection for the new data. - Clarify the text about Version/HdrLen as proposed in the thread related t= o Jari's discuss - so even if we add extensions later, and bump the version= number, HdrLen/TrailerLen will be in the same place, and middleboxes can s= till find where the actual packet starts/ends Thanks, Yaron From smoonen@us.ibm.com Tue Jan 12 06:22:28 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BD0F3A67D1 for ; Tue, 12 Jan 2010 06:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYG6ulZiTiLG for ; Tue, 12 Jan 2010 06:22:25 -0800 (PST) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by core3.amsl.com (Postfix) with ESMTP id 279FB3A69ED for ; Tue, 12 Jan 2010 06:22:18 -0800 (PST) Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e7.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o0CEFw9H010046 for ; Tue, 12 Jan 2010 09:15:58 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o0CEM2in128062 for ; Tue, 12 Jan 2010 09:22:04 -0500 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o0CELeO5008939 for ; Tue, 12 Jan 2010 07:21:40 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o0CELaIa008528; Tue, 12 Jan 2010 07:21:36 -0700 In-Reply-To: <19276.13229.412264.229979@fireball.kivinen.iki.fi> References: <19276.13229.412264.229979@fireball.kivinen.iki.fi> To: Tero Kivinen MIME-Version: 1.0 X-KeepSent: 86561FCF:C344CDD9-852576A9:004D744B; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/12/2010 09:14:20 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/12/2010 09:14:20 AM, Serialize complete at 01/12/2010 09:14:20 AM, S/MIME Sign failed at 01/12/2010 09:14:20 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 01/12/2010 07:21:36, Serialize complete at 01/12/2010 07:21:36 Message-ID: Date: Tue, 12 Jan 2010 09:21:35 -0500 Content-Type: multipart/alternative; boundary="=_alternative 004E37A8852576A9_=" Cc: ipsec@ietf.org Subject: Re: [IPsec] ikev2bis clarification on port floating X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 14:22:28 -0000 This is a multipart message in MIME format. --=_alternative 004E37A8852576A9_= Content-Type: text/plain; charset="US-ASCII" Tero, > > 2) Disallow floating on IKE_SA_INIT unless . . . > Why do you want to disallow that? . . . > > > 3) Disallow this elective use of UDP-encap unless . . . > Again why do that? I guess I'm thinking more about what is advisable (without out-of-band knowledge or inference) than what is permissible, so that may be out of scope. And I should have said "recommend against" rather than "disallow". Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Tero Kivinen To: Scott C Moonen/Raleigh/IBM@IBMUS Cc: ipsec@ietf.org Date: 01/12/2010 03:36 AM Subject: Re: [IPsec] ikev2bis clarification on port floating Scott C Moonen writes: > Further question -- is it ok for the IKE negotiation *not* to float and > then for the ESP traffic to later arrive UDP-encapped on port 4500? Yes, provided the NAT_DETECTION_* payloads were exchanged, (i.e. the implementation knows other end supports NAT-T). > It seems like it would be wise not to send UDP-encapped ESP unless > you've already verified that the 4500-4500 port pairing works during > an IKE exchange. But the text in section 2.31 doesn't seem to > exclude that possibility. That was the intention, i.e. even when there was no NAT (regardless whether you use port 500 or 4500), but other end did support NAT-T (i.e. NAT_DETECTION_* payloads were exchanged), then you can use either normal ESP packets, or UDP encapsulated ESP packets on port 4500. This is something that is already required for MOBIKE, as with MOBIKE the host might suddenly notice that you moved to new IP-address which do have NAT, thus you might need to enable NAT-T. On the other hand with MOBIKE you always change to use port 4500 in the beginning to simplify things. The current text does not say when you would be sending such packets, it just says that you MUST be able to receive them. > Personally, I think we should: > > 1) Rephrase the "non-UDP encapsulated packets" wording as Dan requested. > Possible starting point: "receive and process IPsec packets with or > without UDP encapsulation at any time." That change seems to be good. > 2) Disallow floating on IKE_SA_INIT unless you have prior knowledge the > peer supports NAT traversal (i.e., an existing SA is being authenticated, > which itself exchanged NAT_DETECTION_* payloads even if it may not have > detected a NAT). Why do you want to disallow that? You might not have prior knowledge, but you might have good hints that other end needs to support NAT-T or otherwise communications does not work so better start at port 4500 directly. Also some minimal implementations supporting NAT-T could always start at port 4500 as they do not support normal IPsec at all, only UDP encapsulated IPsec and they always act as they were behind NAT. > 3) Disallow this elective use of UDP-encap unless you have already floated > the IKE SA. Again why do that? I think it is easier to just make it so that you can always use normal IPsec or UDP encapsulated IPsec if you support NAT-T regardless whether you have changed ports etc... I.e if you get packet to your IKE NAT port (4500) you check the SPI and if it is there you strip UDP header and pass it to IPsec engine. If there is 4 bytes of zeros in the beginning then you pass it to the UDP stack. No need to check whether there was NAT-T enabled for this specific host etc. -- kivinen@iki.fi --=_alternative 004E37A8852576A9_= Content-Type: text/html; charset="US-ASCII"
Tero,

> > 2) Disallow floating on IKE_SA_INIT unless . . .
> Why do you want to disallow that? . . .
>
> > 3) Disallow this elective use of UDP-encap unless . . .
> Again why do that?

I guess I'm thinking more about what is advisable (without out-of-band knowledge or inference) than what is permissible, so that may be out of scope.  And I should have said "recommend against" rather than "disallow".


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen


From: Tero Kivinen <kivinen@iki.fi>
To: Scott C Moonen/Raleigh/IBM@IBMUS
Cc: ipsec@ietf.org
Date: 01/12/2010 03:36 AM
Subject: Re: [IPsec] ikev2bis clarification on port floating




Scott C Moonen writes:
> Further question -- is it ok for the IKE negotiation *not* to float and
> then for the ESP traffic to later arrive UDP-encapped on port 4500?

Yes, provided the NAT_DETECTION_* payloads were exchanged, (i.e. the
implementation knows other end supports NAT-T).

> It seems like it would be wise not to send UDP-encapped ESP unless
> you've already verified that the 4500-4500 port pairing works during
> an IKE exchange. But the text in section 2.31 doesn't seem to
> exclude that possibility.

That was the intention, i.e. even when there was no NAT (regardless
whether you use port 500 or 4500), but other end did support NAT-T
(i.e. NAT_DETECTION_* payloads were exchanged), then you can use
either normal ESP packets, or UDP encapsulated ESP packets on port
4500.

This is something that is already required for MOBIKE, as with MOBIKE
the host might suddenly notice that you moved to new IP-address which
do have NAT, thus you might need to enable NAT-T. On the other hand
with MOBIKE you always change to use port 4500 in the beginning to
simplify things.

The current text does not say when you would be sending such packets,
it just says that you MUST be able to receive them.

> Personally, I think we should:
>
> 1) Rephrase the "non-UDP encapsulated packets" wording as Dan requested.
> Possible starting point: "receive and process IPsec packets with or
> without UDP encapsulation at any time."

That change seems to be good.

> 2) Disallow floating on IKE_SA_INIT unless you have prior knowledge the
> peer supports NAT traversal (i.e., an existing SA is being authenticated,
> which itself exchanged NAT_DETECTION_* payloads even if it may not have
> detected a NAT).

Why do you want to disallow that?

You might not have prior knowledge, but you might have good hints that
other end needs to support NAT-T or otherwise communications does not
work so better start at port 4500 directly.

Also some minimal implementations supporting NAT-T could always start
at port 4500 as they do not support normal IPsec at all, only UDP
encapsulated IPsec and they always act as they were behind NAT.

> 3) Disallow this elective use of UDP-encap unless you have already floated
> the IKE SA.

Again why do that? I think it is easier to just make it so that you
can always use normal IPsec or UDP encapsulated IPsec if you support
NAT-T regardless whether you have changed ports etc...

I.e if you get packet to your IKE NAT port (4500) you check the SPI
and if it is there you strip UDP header and pass it to IPsec engine.
If there is 4 bytes of zeros in the beginning then you pass it to the
UDP stack.

No need to check whether there was NAT-T enabled for this specific
host etc.
--
kivinen@iki.fi

--=_alternative 004E37A8852576A9_=-- From vnktshsriram@gmail.com Tue Jan 12 06:22:46 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 358743A69EB for ; Tue, 12 Jan 2010 06:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IWEjaXJMh+T for ; Tue, 12 Jan 2010 06:22:45 -0800 (PST) Received: from mail-qy0-f188.google.com (mail-qy0-f188.google.com [209.85.221.188]) by core3.amsl.com (Postfix) with ESMTP id 0708D3A69F7 for ; Tue, 12 Jan 2010 06:22:44 -0800 (PST) Received: by qyk26 with SMTP id 26so11459966qyk.5 for ; Tue, 12 Jan 2010 06:22:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7u3gz/2ruDZJq9p+fbyMI1NQvj6+frDb1+cBEJIE52s=; b=VIPUSFFTy304XO1MSMWQsxqBgdlCNXx7C1jAClEGSxm/XaU7lYkBN0qxCIT8eVotJU LHt+gtyyRWRyHKynbEnJxmme3lnaPGpSclhNeKLLIJDmSrWTqjs1h3Cm2OgmPp/ofqrh IGw01yFVWNdtKYmCdNbEtI17lOkVsFGbA2bTA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qpFdiZU/+RX9kZ4DlvLSoC9VMrYl1NSqol7jsnaYEBF5/nKQLgGwKucX/fWaONLyvb 7tON3v9rPdz4RwADS4aRsZs0ZGOoGqDb9APAU1JlvEFyv7S1/ZnepGx48ZFHRCXIUIDz zz3V8vZIKa1S+qLgeFM3oTbkbeZVMBJzT2Mqo= MIME-Version: 1.0 Received: by 10.220.123.170 with SMTP id p42mr567614vcr.105.1263306157178; Tue, 12 Jan 2010 06:22:37 -0800 (PST) In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A2166C@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A2166C@il-ex01.ad.checkpoint.com> Date: Tue, 12 Jan 2010 19:52:37 +0530 Message-ID: From: Venkatesh Sriram To: Yaron Sheffer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Traffic visibility - proposed way forward X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 14:22:46 -0000 Looks Good. Sriram On Tue, Jan 12, 2010 at 5:07 PM, Yaron Sheffer wrot= e: > Hi, > > Thanks to the IESG feedback, we have had a long and enlightening discussi= on on the list. But we have not reached consensus on either of the two ques= tions. As a result, Paul and I are proposing the following resolution, whic= h appears to be acceptable both to the draft's editors and to the IESG memb= ers. Unless there are strong objections from multiple WG participants, we w= ill ask the editors to rev the draft in the next few days according to this= proposal. > > Motivation: retain deterministic traffic visibility for middleboxes with = a smooth migration path, while ensuring that WESP does not change ESP, and = is not (nor seen as) ESPv4. > > - Return ICV to its former ESP-only definition. > - Maintain the Encrypted bit, as per the latest version of the draft. > - Make the padding field have the minimal possible length, possibly 0. El= iminate the Padding Length field (the first octet). [Essentially roll back = to version -10]. > - WESPv1 will not accept extensions. Any extensions will need a WESPv2, i= ncluding some integrity protection for the new data. > - Clarify the text about Version/HdrLen as proposed in the thread related= to Jari's discuss - so even if we add extensions later, and bump the versi= on number, HdrLen/TrailerLen will be in the same place, and middleboxes can= still find where the actual packet starts/ends > > Thanks, > =A0 =A0 =A0 =A0Yaron > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From ynir@checkpoint.com Tue Jan 12 06:38:55 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E67F83A69BB for ; Tue, 12 Jan 2010 06:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fgthzi9HMZ6e for ; Tue, 12 Jan 2010 06:38:54 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id DB1133A69A2 for ; Tue, 12 Jan 2010 06:38:53 -0800 (PST) X-CheckPoint: {4B4C876E-10008-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 2AA1B29C00A; Tue, 12 Jan 2010 16:38:50 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 01A9F29C005; Tue, 12 Jan 2010 16:38:49 +0200 (IST) X-CheckPoint: {4B4C876E-10000-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0CEcnT7005125; Tue, 12 Jan 2010 16:38:49 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 12 Jan 2010 16:39:03 +0200 From: Yoav Nir To: Scott C Moonen Date: Tue, 12 Jan 2010 16:38:41 +0200 Thread-Topic: [IPsec] ikev2bis clarification on port floating Thread-Index: AcqTlPx8DIGBV/hYShiyfe9SflkzDQ== Message-ID: References: <19276.13229.412264.229979@fireball.kivinen.iki.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EF0FF15B6C264524ACF2958BA3AF3481checkpointcom_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Tero Kivinen Subject: Re: [IPsec] ikev2bis clarification on port floating X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 14:38:56 -0000 --_000_EF0FF15B6C264524ACF2958BA3AF3481checkpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Scott When writing remote access VPN clients (running on phones, PCs, tablets, pr= obably not z/OS) it's usually safe to assume that the peer (a gateway) supp= orts NAT-T. This is because on the real Internet, a RAS that does not suppo= rt NAT-T simply doesn't work. NATs are everywhere. So it's possible to write a simplified client, that only does NAT-T (no ESP= and no UDP port 500) and it doesn't even need to bother with the NAT_DETEC= TION payloads. Allowing UDP 4500 even for the IKE_SA_INIT exchange allows such clients, an= d I don't see a reason to forbid them. Yes, they are not interoperable with= perfectly legitimate IKEv2 implementations that do not support NAT-T, but = that doesn't matter, because those minimal implementations are not fit to b= e RAS. On Jan 12, 2010, at 4:21 PM, Scott C Moonen wrote: Tero, > > 2) Disallow floating on IKE_SA_INIT unless . . . > Why do you want to disallow that? . . . > > > 3) Disallow this elective use of UDP-encap unless . . . > Again why do that? I guess I'm thinking more about what is advisable (without out-of-band know= ledge or inference) than what is permissible, so that may be out of scope. = And I should have said "recommend against" rather than "disallow". Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Tero Kivinen > To: Scott C Moonen/Raleigh/IBM@IBMUS Cc: ipsec@ietf.org Date: 01/12/2010 03:36 AM Subject: Re: [IPsec] ikev2bis clarification on port floating ________________________________ Scott C Moonen writes: > Further question -- is it ok for the IKE negotiation *not* to float and > then for the ESP traffic to later arrive UDP-encapped on port 4500? Yes, provided the NAT_DETECTION_* payloads were exchanged, (i.e. the implementation knows other end supports NAT-T). > It seems like it would be wise not to send UDP-encapped ESP unless > you've already verified that the 4500-4500 port pairing works during > an IKE exchange. But the text in section 2.31 doesn't seem to > exclude that possibility. That was the intention, i.e. even when there was no NAT (regardless whether you use port 500 or 4500), but other end did support NAT-T (i.e. NAT_DETECTION_* payloads were exchanged), then you can use either normal ESP packets, or UDP encapsulated ESP packets on port 4500. This is something that is already required for MOBIKE, as with MOBIKE the host might suddenly notice that you moved to new IP-address which do have NAT, thus you might need to enable NAT-T. On the other hand with MOBIKE you always change to use port 4500 in the beginning to simplify things. The current text does not say when you would be sending such packets, it just says that you MUST be able to receive them. > Personally, I think we should: > > 1) Rephrase the "non-UDP encapsulated packets" wording as Dan requested. > Possible starting point: "receive and process IPsec packets with or > without UDP encapsulation at any time." That change seems to be good. > 2) Disallow floating on IKE_SA_INIT unless you have prior knowledge the > peer supports NAT traversal (i.e., an existing SA is being authenticated, > which itself exchanged NAT_DETECTION_* payloads even if it may not have > detected a NAT). Why do you want to disallow that? You might not have prior knowledge, but you might have good hints that other end needs to support NAT-T or otherwise communications does not work so better start at port 4500 directly. Also some minimal implementations supporting NAT-T could always start at port 4500 as they do not support normal IPsec at all, only UDP encapsulated IPsec and they always act as they were behind NAT. > 3) Disallow this elective use of UDP-encap unless you have already floate= d > the IKE SA. Again why do that? I think it is easier to just make it so that you can always use normal IPsec or UDP encapsulated IPsec if you support NAT-T regardless whether you have changed ports etc... I.e if you get packet to your IKE NAT port (4500) you check the SPI and if it is there you strip UDP header and pass it to IPsec engine. If there is 4 bytes of zeros in the beginning then you pass it to the UDP stack. No need to check whether there was NAT-T enabled for this specific host etc. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_EF0FF15B6C264524ACF2958BA3AF3481checkpointcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Scott

When writing remote access VPN clients (running on phones, PCs, tablets, = probably not z/OS) it's usually safe to assume that the peer (a gateway) su= pports NAT-T. This is because on the real Internet, a RAS that does not sup= port NAT-T simply doesn't work. NATs are everywhere.

So it's possible to write a simplified client, that only does NAT-T (no = ESP and no UDP port 500) and it doesn't even need to bother with the NAT_DE= TECTION payloads.

Allowing UDP 4500 even for the I= KE_SA_INIT exchange allows such clients, and I don't see a reason to forbid= them. Yes, they are not interoperable with perfectly legitimate IKEv2 impl= ementations that do not support NAT-T, but that doesn't matter, because tho= se minimal implementations are not fit to be RAS.

=
On Jan 12, 2010, at 4:21 PM, Scott C Moonen wrote:


Tero,

> > 2) Disallow floating on IKE_SA_INIT unle= ss . . .
> Why do you want to disallow that? . . .
>
> > 3) Disallow this elective use of UDP-encap unless . . .
> Again why do that?

I guess I'm thinking more about wh= at is advisable (without out-of-band knowledge or inference) than what is permissible, so that may be out of scope.  And I should have said "recommend against" rather than "disallow".


Scott Moonen (smoonen@us.ibm.com)=
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen


From: Tero Kivinen <kivinen@iki.fi>
To: Scott C Moonen/Raleigh/IBM@IB= MUS
C= c: ipsec@ietf.org
Date: 01/12/2010 03:36 AM
Subject: Re: [IPsec] ikev2bis clarific= ation on port floating




Scott C Moonen writes:
> Further question -- is it ok for the IKE negotiation *not* to float and
> then for the ESP traffic to later arrive UDP-encapped on port 4500?
Yes, provided the NAT_DETECTION_* payloads were exchanged, (i.e. the
implementation knows other end supports NAT-T).

> It seems like it would be wise not to send UDP-encapped ESP unless
> you've already verified that the 4500-4500 port pairing works during > an IKE exchange. But the text in section 2.31 doesn't seem to
> exclude that possibility.

That was the intention, i.e. even when there was no NAT (regardless
whether you use port 500 or 4500), but other end did support NAT-T
(i.e. NAT_DETECTION_* payloads were exchanged), then you can use
either normal ESP packets, or UDP encapsulated ESP packets on port
4500.

This is something that is already required for MOBIKE, as with MOBIKE
the host might suddenly notice that you moved to new IP-address which
do have NAT, thus you might need to enable NAT-T. On the other hand
with MOBIKE you always change to use port 4500 in the beginning to
simplify things.

The current text does not say when you would be sending such packets,
it just says that you MUST be able to receive them.

> Personally, I think we should:
>
> 1) Rephrase the "non-UDP encapsulated packets" wording as Dan requested.
> Possible starting point: "receive and process IPsec packets with or
> without UDP encapsulation at any time."

That change seems to be good.

> 2) Disallow floating on IKE_SA_INIT unless you have prior knowledge the
> peer supports NAT traversal (i.e., an existing SA is being authenticat= ed,
> which itself exchanged NAT_DETECTION_* payloads even if it may not have
> detected a NAT).

Why do you want to disallow that?

You might not have prior knowledge, but you might have good hints that
other end needs to support NAT-T or otherwise communications does not
work so better start at port 4500 directly.

Also some minimal implementations supporting NAT-T could always start
at port 4500 as they do not support normal IPsec at all, only UDP
encapsulated IPsec and they always act as they were behind NAT.

> 3) Disallow this elective use of UDP-encap unless you have already floated
> the IKE SA.

Again why do that? I think it is easier to just make it so that you
can always use normal IPsec or UDP encapsulated IPsec if you support
NAT-T regardless whether you have changed ports etc...

I.e if you get packet to your IKE NAT port (4500) you check the SPI
and if it is there you strip UDP header and pass it to IPsec engine.
If there is 4 bytes of zeros in the beginning then you pass it to the
UDP stack.

No need to check whether there was NAT-T enabled for this specific
host etc.
--
kivinen@iki.fi

_______________________________________________
IPsec mailing listIPsec@ietf.org
https://www.ietf.= org/mailman/listinfo/ipsec

= --_000_EF0FF15B6C264524ACF2958BA3AF3481checkpointcom_-- From smoonen@us.ibm.com Tue Jan 12 07:21:58 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 307F83A680F for ; Tue, 12 Jan 2010 07:21:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.246 X-Spam-Level: X-Spam-Status: No, score=-3.246 tagged_above=-999 required=5 tests=[AWL=-0.648, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaZoH2sdpWFq for ; Tue, 12 Jan 2010 07:21:54 -0800 (PST) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by core3.amsl.com (Postfix) with ESMTP id BE5303A67B7 for ; Tue, 12 Jan 2010 07:21:52 -0800 (PST) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e37.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id o0CFKHeJ005459 for ; Tue, 12 Jan 2010 08:20:17 -0700 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o0CFLNOG048072 for ; Tue, 12 Jan 2010 08:21:29 -0700 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o0CFNQUl010165 for ; Tue, 12 Jan 2010 08:23:26 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av06.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o0CFNQp3010162; Tue, 12 Jan 2010 08:23:26 -0700 In-Reply-To: References: <19276.13229.412264.229979@fireball.kivinen.iki.fi> To: Yoav Nir MIME-Version: 1.0 X-KeepSent: 12E857A5:3D35F709-852576A9:0053FC39; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/12/2010 10:20:55 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/12/2010 10:20:55 AM, Serialize complete at 01/12/2010 10:20:55 AM, S/MIME Sign failed at 01/12/2010 10:20:55 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 01/12/2010 08:21:22, Serialize complete at 01/12/2010 08:21:22 Message-ID: Date: Tue, 12 Jan 2010 10:21:22 -0500 Content-Type: multipart/alternative; boundary="=_alternative 00545014852576A9_=" Cc: "ipsec@ietf.org" , Tero Kivinen Subject: Re: [IPsec] ikev2bis clarification on port floating X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 15:21:58 -0000 This is a multipart message in MIME format. --=_alternative 00545014852576A9_= Content-Type: text/plain; charset="US-ASCII" Yoav, thanks. I withdraw my suggestions #2 and #3 altogether, and (barring objections) we can just stick with the suggested rewording of "both UDP encapsulated and non-UDP encapsulated packets" to "IPsec packets with or without UDP encapsulation". Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Yoav Nir To: Scott C Moonen/Raleigh/IBM@IBMUS Cc: Tero Kivinen , "ipsec@ietf.org" Date: 01/12/2010 09:39 AM Subject: Re: [IPsec] ikev2bis clarification on port floating Hi Scott When writing remote access VPN clients (running on phones, PCs, tablets, probably not z/OS) it's usually safe to assume that the peer (a gateway) supports NAT-T. This is because on the real Internet, a RAS that does not support NAT-T simply doesn't work. NATs are everywhere. So it's possible to write a simplified client, that only does NAT-T (no ESP and no UDP port 500) and it doesn't even need to bother with the NAT_DETECTION payloads. Allowing UDP 4500 even for the IKE_SA_INIT exchange allows such clients, and I don't see a reason to forbid them. Yes, they are not interoperable with perfectly legitimate IKEv2 implementations that do not support NAT-T, but that doesn't matter, because those minimal implementations are not fit to be RAS. On Jan 12, 2010, at 4:21 PM, Scott C Moonen wrote: Tero, > > 2) Disallow floating on IKE_SA_INIT unless . . . > Why do you want to disallow that? . . . > > > 3) Disallow this elective use of UDP-encap unless . . . > Again why do that? I guess I'm thinking more about what is advisable (without out-of-band knowledge or inference) than what is permissible, so that may be out of scope. And I should have said "recommend against" rather than "disallow". Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Tero Kivinen To: Scott C Moonen/Raleigh/IBM@IBMUS Cc: ipsec@ietf.org Date: 01/12/2010 03:36 AM Subject: Re: [IPsec] ikev2bis clarification on port floating Scott C Moonen writes: > Further question -- is it ok for the IKE negotiation *not* to float and > then for the ESP traffic to later arrive UDP-encapped on port 4500? Yes, provided the NAT_DETECTION_* payloads were exchanged, (i.e. the implementation knows other end supports NAT-T). > It seems like it would be wise not to send UDP-encapped ESP unless > you've already verified that the 4500-4500 port pairing works during > an IKE exchange. But the text in section 2.31 doesn't seem to > exclude that possibility. That was the intention, i.e. even when there was no NAT (regardless whether you use port 500 or 4500), but other end did support NAT-T (i.e. NAT_DETECTION_* payloads were exchanged), then you can use either normal ESP packets, or UDP encapsulated ESP packets on port 4500. This is something that is already required for MOBIKE, as with MOBIKE the host might suddenly notice that you moved to new IP-address which do have NAT, thus you might need to enable NAT-T. On the other hand with MOBIKE you always change to use port 4500 in the beginning to simplify things. The current text does not say when you would be sending such packets, it just says that you MUST be able to receive them. > Personally, I think we should: > > 1) Rephrase the "non-UDP encapsulated packets" wording as Dan requested. > Possible starting point: "receive and process IPsec packets with or > without UDP encapsulation at any time." That change seems to be good. > 2) Disallow floating on IKE_SA_INIT unless you have prior knowledge the > peer supports NAT traversal (i.e., an existing SA is being authenticated, > which itself exchanged NAT_DETECTION_* payloads even if it may not have > detected a NAT). Why do you want to disallow that? You might not have prior knowledge, but you might have good hints that other end needs to support NAT-T or otherwise communications does not work so better start at port 4500 directly. Also some minimal implementations supporting NAT-T could always start at port 4500 as they do not support normal IPsec at all, only UDP encapsulated IPsec and they always act as they were behind NAT. > 3) Disallow this elective use of UDP-encap unless you have already floated > the IKE SA. Again why do that? I think it is easier to just make it so that you can always use normal IPsec or UDP encapsulated IPsec if you support NAT-T regardless whether you have changed ports etc... I.e if you get packet to your IKE NAT port (4500) you check the SPI and if it is there you strip UDP header and pass it to IPsec engine. If there is 4 bytes of zeros in the beginning then you pass it to the UDP stack. No need to check whether there was NAT-T enabled for this specific host etc. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 00545014852576A9_= Content-Type: text/html; charset="US-ASCII"
Yoav, thanks.  I withdraw my suggestions #2 and #3 altogether, and (barring objections) we can just stick with the suggested rewording of "both UDP encapsulated and non-UDP encapsulated packets" to "IPsec packets with or without UDP encapsulation".


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen


From: Yoav Nir <ynir@checkpoint.com>
To: Scott C Moonen/Raleigh/IBM@IBMUS
Cc: Tero Kivinen <kivinen@iki.fi>, "ipsec@ietf.org" <ipsec@ietf.org>
Date: 01/12/2010 09:39 AM
Subject: Re: [IPsec] ikev2bis clarification on port floating




Hi Scott

When writing remote access VPN clients (running on phones, PCs, tablets, probably not z/OS) it's usually safe to assume that the peer (a gateway) supports NAT-T. This is because on the real Internet, a RAS that does not support NAT-T simply doesn't work. NATs are everywhere.

So it's possible to write a simplified client, that only does NAT-T (no ESP and no UDP port 500) and it doesn't even need to bother with the NAT_DETECTION payloads.

Allowing UDP 4500 even for the IKE_SA_INIT exchange allows such clients, and I don't see a reason to forbid them. Yes, they are not interoperable with perfectly legitimate IKEv2 implementations that do not support NAT-T, but that doesn't matter, because those minimal implementations are not fit to be RAS.


On Jan 12, 2010, at 4:21 PM, Scott C Moonen wrote:


Tero,

> > 2) Disallow floating on IKE_SA_INIT unless . . .
> Why do you want to disallow that? . . .
>
> > 3) Disallow this elective use of UDP-encap unless . . .
> Again why do that?

I guess I'm thinking more about what is advisable (without out-of-band knowledge or inference) than what is permissible, so that may be out of scope.  And I should have said "recommend against" rather than "disallow".


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

From: Tero Kivinen <kivinen@iki.fi>
To: Scott C Moonen/Raleigh/IBM@IBMUS
Cc: ipsec@ietf.org
Date: 01/12/2010 03:36 AM
Subject: Re: [IPsec] ikev2bis clarification on port floating



Scott C Moonen writes:
> Further question -- is it ok for the IKE negotiation *not* to float and
> then for the ESP traffic to later arrive UDP-encapped on port 4500?

Yes, provided the NAT_DETECTION_* payloads were exchanged, (i.e. the
implementation knows other end supports NAT-T).

> It seems like it would be wise not to send UDP-encapped ESP unless
> you've already verified that the 4500-4500 port pairing works during
> an IKE exchange. But the text in section 2.31 doesn't seem to
> exclude that possibility.

That was the intention, i.e. even when there was no NAT (regardless
whether you use port 500 or 4500), but other end did support NAT-T
(i.e. NAT_DETECTION_* payloads were exchanged), then you can use
either normal ESP packets, or UDP encapsulated ESP packets on port
4500.

This is something that is already required for MOBIKE, as with MOBIKE
the host might suddenly notice that you moved to new IP-address which
do have NAT, thus you might need to enable NAT-T. On the other hand
with MOBIKE you always change to use port 4500 in the beginning to
simplify things.

The current text does not say when you would be sending such packets,
it just says that you MUST be able to receive them.

> Personally, I think we should:
>
> 1) Rephrase the "non-UDP encapsulated packets" wording as Dan requested.
> Possible starting point: "receive and process IPsec packets with or
> without UDP encapsulation at any time."

That change seems to be good.

> 2) Disallow floating on IKE_SA_INIT unless you have prior knowledge the
> peer supports NAT traversal (i.e., an existing SA is being authenticated,
> which itself exchanged NAT_DETECTION_* payloads even if it may not have
> detected a NAT).

Why do you want to disallow that?

You might not have prior knowledge, but you might have good hints that
other end needs to support NAT-T or otherwise communications does not
work so better start at port 4500 directly.

Also some minimal implementations supporting NAT-T could always start
at port 4500 as they do not support normal IPsec at all, only UDP
encapsulated IPsec and they always act as they were behind NAT.

> 3) Disallow this elective use of UDP-encap unless you have already floated
> the IKE SA.

Again why do that? I think it is easier to just make it so that you
can always use normal IPsec or UDP encapsulated IPsec if you support
NAT-T regardless whether you have changed ports etc...

I.e if you get packet to your IKE NAT port (4500) you check the SPI
and if it is there you strip UDP header and pass it to IPsec engine.
If there is 4 bytes of zeros in the beginning then you pass it to the
UDP stack.

No need to check whether there was NAT-T enabled for this specific
host etc.
--
kivinen@iki.fi


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


--=_alternative 00545014852576A9_=-- From smoonen@us.ibm.com Tue Jan 12 12:59:51 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68CA728C0E6 for ; Tue, 12 Jan 2010 12:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.181 X-Spam-Level: X-Spam-Status: No, score=-5.181 tagged_above=-999 required=5 tests=[AWL=1.417, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+RzZLEeX+c5 for ; Tue, 12 Jan 2010 12:59:50 -0800 (PST) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by core3.amsl.com (Postfix) with ESMTP id 32E2A28C0D7 for ; Tue, 12 Jan 2010 12:59:50 -0800 (PST) Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e3.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o0CKnlqG001757 for ; Tue, 12 Jan 2010 15:49:47 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o0CKxeYe103660 for ; Tue, 12 Jan 2010 15:59:40 -0500 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o0CKxdUk003381 for ; Tue, 12 Jan 2010 13:59:39 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o0CKxdOR003365 for ; Tue, 12 Jan 2010 13:59:39 -0700 To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: 1F77D20A:40E80C15-852576A9:00723402; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/12/2010 03:51:48 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/12/2010 03:51:48 PM, Serialize complete at 01/12/2010 03:51:48 PM, S/MIME Sign failed at 01/12/2010 03:51:48 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 01/12/2010 13:59:39, Serialize complete at 01/12/2010 13:59:39 Message-ID: Date: Tue, 12 Jan 2010 15:59:38 -0500 Content-Type: multipart/alternative; boundary="=_alternative 00729B37852576A9_=" Subject: [IPsec] ikev2bis and NAT traversal in transport mode X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 20:59:51 -0000 This is a multipart message in MIME format. --=_alternative 00729B37852576A9_= Content-Type: text/plain; charset="US-ASCII" The draft says: After this address substitution, both the traffic selectors and the IKE UDP source/destination addresses look the same, and the server does SPD lookup based on those new traffic selectors. If an entry is found and it allows transport mode, then that entry is used. If an entry is found but it does not allow transport mode, then the server MAY undo the address substitution and redo the SPD lookup using the original traffic selectors. . . . and then later on it says: For the responder, when transport mode is proposed by client: . . . - If no SPD entry was found, or if found SPD entry does not allow transport mode, undo the traffic selector substitutions. Do PAD and SPD lookup again using the ID and original traffic selectors, but also searching for tunnel mode SPD entry (that is, fall back to tunnel mode). Because of the MAY in the first paragraph, I suggest that we reword the second quote. Perhaps we can simply say "optionally undo". Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen --=_alternative 00729B37852576A9_= Content-Type: text/html; charset="US-ASCII"
The draft says:

   After this address substitution, both the traffic selectors and the
   IKE UDP source/destination addresses look the same, and the server
   does SPD lookup based on those new traffic selectors.  If an entry is
   found and it allows transport mode, then that entry is used.  If an
   entry is found but it does not allow transport mode, then the server
   MAY undo the address substitution and redo the SPD lookup using the
   original traffic selectors. . . .

and then later on it says:

   For the responder, when transport mode is proposed by client:
   . . .
   - If no SPD entry was found, or if found SPD entry does not
     allow transport mode, undo the traffic selector substitutions.
     Do PAD and SPD lookup again using the ID and original traffic
     selectors, but also searching for tunnel mode SPD entry (that
     is, fall back to tunnel mode).

Because of the MAY in the first paragraph, I suggest that we reword the second quote.  Perhaps we can simply say "optionally undo".


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen --=_alternative 00729B37852576A9_=-- From welterk@us.ibm.com Tue Jan 12 14:03:38 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 723E43A68A0 for ; Tue, 12 Jan 2010 14:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clbVoyFTzAgK for ; Tue, 12 Jan 2010 14:03:36 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by core3.amsl.com (Postfix) with ESMTP id B64E43A6884 for ; Tue, 12 Jan 2010 14:03:35 -0800 (PST) Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e34.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id o0CLvVGU025170 for ; Tue, 12 Jan 2010 14:57:31 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o0CM3GBP125762 for ; Tue, 12 Jan 2010 15:03:17 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o0CM3GZg001947 for ; Tue, 12 Jan 2010 15:03:16 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av03.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o0CM3Ftu001937 for ; Tue, 12 Jan 2010 15:03:15 -0700 In-Reply-To: References: To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: 776A461C:F178CC8F-882576A9:00787EA5; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Keith Welter X-MIMETrack: S/MIME Sign by Notes Client on Keith Welter/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/12/2010 02:03:10 PM, Serialize by Notes Client on Keith Welter/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/12/2010 02:03:10 PM, Serialize complete at 01/12/2010 02:03:10 PM, S/MIME Sign failed at 01/12/2010 02:03:10 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 01/12/2010 15:03:15, Serialize complete at 01/12/2010 15:03:15 Message-ID: Date: Tue, 12 Jan 2010 14:03:14 -0800 Content-Type: multipart/alternative; boundary="=_alternative 007923C1882576A9_=" Subject: Re: [IPsec] Issue #131: Returning TEMPORARY_FAILURE: MUST or SHOULD? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 22:03:38 -0000 This is a multipart message in MIME format. --=_alternative 007923C1882576A9_= Content-Type: text/plain; charset="US-ASCII" The "MUST return TEMPORARY_FAILURE" wording was not in the text proposed by the issue #22 design team. The original wording was "will return TEMPORARY_FAILURE". Had the team carefully considered a SHOULD versus MUST in this case I suspect we would have picked "SHOULD". Anyway, my vote is for "SHOULD return TEMPORARY_FAILURE" in section 2.8.2 > Message: 5 > Date: Sun, 10 Jan 2010 17:13:30 -0800 > From: Paul Hoffman > Subject: Re: [IPsec] Issue #131: Returning TEMPORARY_FAILURE: MUST or > SHOULD? > To: IPsecme WG > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > At 2:29 PM -0800 12/16/09, Paul Hoffman wrote: > >Section 2.8.2 Simultaneous IKE SA Rekeying states: > > > > If only one peer detects a simultaneous rekey, redundant SAs > > are not created. In this case, when the peer that did not notice the > > simultaneous rekey gets the request to rekey the IKE SA that it has > > already successfully rekeyed, it MUST return TEMPORARY_FAILURE > > because it is an IKE SA that it is currently trying to close (whether > > or not it has already sent the delete notification for the SA). > > > >Section 2.25.2 (Collisions While Rekeying or Closing IKE SAs) states: > > > > If a peer receives a request to close an IKE SA that it is > > currently trying to close, it SHOULD reply as usual, and forget about > > its own close request. > > > >Based on the text in Section 2.25.2 it seems that perhaps the MUST in > >Section 2.8.2 is really a SHOULD. Or, based on the text in 2.8.2, the > >SHOULD in 2.25.2 should be a MUST. > > This got no response; does anyone have an opinion? > > --Paul Hoffman, Director > --VPN Consortium > > > ------------------------------ > > Message: 6 > Date: Sun, 10 Jan 2010 17:15:54 -0800 > From: Paul Hoffman > Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 > (yes, IKEv2-bis!) > To: Yaron Sheffer , "ipsec@ietf.org" > > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > At 11:04 AM +0200 12/10/09, Yaron Sheffer wrote: > >This is to begin a 4 week working group last call for draft-ietf-ipsecme- > ikev2bis-06. The target status for this document is Proposed Standard, obsoleting > RFC 4306 and RFC 4718. > > > >Please send your comments to the ipsec list by Jan. 5, 2010, as follow-ups to this message. > > We hae overshot that by a bit, and there are still three open issues. Please send > in any last-minute WG LC comments in the next day or two, if you would. > > --Paul Hoffman, Director > --VPN Consortium > > > ------------------------------ > > Message: 7 > Date: Mon, 11 Jan 2010 14:37:48 +0800 > From: Min Huang > Subject: Re: [IPsec] Traffic visibility - consensus call > To: Yaron Sheffer > Cc: ipsec@ietf.org > Message-ID: <002b01ca9288$97867760$619a1b0a@china.huawei.com> > Content-Type: text/plain; charset=us-ascii > > YES to both. > > The WESP header provides a kind of rapid *deterministic* detection method > for ESP_NULL packet. The heuristics method is too complex and it calls for > more computing resource and computing time. I doubt the middle box whether > will support the heuristics method for ESP_NULL detection. Although > including the WESP header into ESP ICV calculation seems modifying ESP, it > is necessary to check the WESP header integrity for counter certain attacks. > The explicit WESP integrity calculation is OK for me, too. > > I support WESP for encrypted ESP flow. WESP has the capacity to provide > more functions by future extensibility than just traffic visibility for > ESP_NULL. Nowadays ESP is used much more widely for encrypted flow than > ESP_NULL flow. It is meaningful for middle detection machines to have the > ability to detecting encrypted traffic. And then WESP could provide this > kind of traffic visibility for both encrypted flow and unencrypted flow in > future. > > regards, > Min > > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org > ] On Behalf Of > Yaron Sheffer > Sent: Tuesday, January 05, 2010 6:27 AM > To: ipsec@ietf.org > Subject: [IPsec] Traffic visibility - consensus call > > Hi, > > We have had a few "discusses" during the IESG review of the WESP draft. To > help resolve them, we would like to reopen the following two questions to WG > discussion. Well reasoned answers are certainly appreciated. But plain "yes" > or "no" would also be useful in judging the group's consensus. > > - The current draft > (http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11) > > defines the ESP trailer's ICV calculation to include the WESP header. This > has been done to counter certain attacks, but it means that WESP is no > longer a simple wrapper around ESP - ESP itself is modified. Do you support > this design decision? > > - The current draft allows WESP to be applied to encrypted ESP flows, in > addition to the originally specified ESP-null. This was intended so that > encrypted flows can benefit from the future extensibility offered by WESP. > But arguably, it positions WESP as an alternative to ESP. Do you support > this design decision? > > Thanks, > Yaron > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > ------------------------------ > > Message: 8 > Date: Mon, 11 Jan 2010 09:28:38 +0100 > From: > Subject: Re: [IPsec] Traffic visibility - consensus call > To: > Cc: ipsec@ietf.org > Message-ID: > <808FD6E27AD4884E94820BC333B2DB775840F4BC84@NOK-EUMSG-01.mgdnok.nokia.com> > > Content-Type: text/plain; charset="us-ascii" > > Ken Grewal wrote: > > > The either-or on using an ICV or explicitly checking the WESP header > > on the recipient was based on the assumption that the threat does > > not come from the sender and only from some other malicious entity > > after the packet has been sent. > > > > This was the reason for simplifying the header check by using the > > ICV, instead of explicitly checking every field. > > Note that the current draft *does* explicitly check ever field. > Are you proposing removing those checks? > > Best regards, > Pasi > (not wearing any hats) > > > ------------------------------ > > Message: 9 > Date: Mon, 11 Jan 2010 14:32:55 +0530 > From: "Bhatia, Manav (Manav)" > Subject: Re: [IPsec] Traffic visibility - consensus call > To: "Pasi.Eronen@nokia.com" , > "ken.grewal@intel.com" > Cc: "ipsec@ietf.org" > Message-ID: > <7C362EEF9C7896468B36C9B79200D8350AB34BB8CB@INBANSXCHMBSA1.in.alcatel-lucent.com> > > Content-Type: text/plain; charset="us-ascii" > > I believe Ken is alluding to removing the WESP header from the ICV calculation, and > relying on explicitly checking the WESP header at the endnodes. > > Cheers, Manav > > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > > On Behalf Of Pasi.Eronen@nokia.com > > Sent: Monday, January 11, 2010 1.59 PM > > To: ken.grewal@intel.com > > Cc: ipsec@ietf.org > > Subject: Re: [IPsec] Traffic visibility - consensus call > > > > Ken Grewal wrote: > > > > > The either-or on using an ICV or explicitly checking the WESP header > > > on the recipient was based on the assumption that the threat does > > > not come from the sender and only from some other malicious entity > > > after the packet has been sent. > > > > > > This was the reason for simplifying the header check by using the > > > ICV, instead of explicitly checking every field. > > > > Note that the current draft *does* explicitly check ever field. > > Are you proposing removing those checks? > > > > Best regards, > > Pasi > > (not wearing any hats) > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > ------------------------------ > > Message: 10 > Date: Mon, 11 Jan 2010 01:23:48 -0800 (PST) > From: "Dan Harkins" > Subject: Re: [IPsec] Traffic visibility - consensus call > To: "Bhatia, Manav (Manav)" > Cc: "ipsec@ietf.org" , "Pasi.Eronen@nokia.com" > , "ken.grewal@intel.com" > Message-ID: > <15b20fc87c91ef1152f2ba42ada44f84.squirrel@www.trepanning.net> > Content-Type: text/plain;charset=iso-8859-1 > > > Manav, > > So let's say the normal (removed WESP header) ICV calculations by > ESP are correct but something doesn't match between the (now unprotected) > WESP header and the rest of the packet. Why should the recipient care? > WESP is for middleboxes. The end node has an assurance that the > _meaningful_ portion of the frame was sent by the claimed sender and > was not modified in transit. Any decisions made by a middlebox that > might've involved an improperly modified WESP header are over and done > with. He doesn't care if the packet was properly handled by middleboxes > or not, he got it and it's correct. > > You trust the end nodes to negotiate WESP and encapsulate their ESP > packets in WESP but you don't trust the content they put into those > packets. Is that the trust model you're operating on? > > The more I think of this problem the more worthless WESP becomes. > > Dan. > > On Mon, January 11, 2010 1:02 am, Bhatia, Manav (Manav) wrote: > > I believe Ken is alluding to removing the WESP header from the ICV > > calculation, and relying on explicitly checking the WESP header at the > > endnodes. > > > > Cheers, Manav > > > >> -----Original Message----- > >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > >> On Behalf Of Pasi.Eronen@nokia.com > >> Sent: Monday, January 11, 2010 1.59 PM > >> To: ken.grewal@intel.com > >> Cc: ipsec@ietf.org > >> Subject: Re: [IPsec] Traffic visibility - consensus call > >> > >> Ken Grewal wrote: > >> > >> > The either-or on using an ICV or explicitly checking the WESP header > >> > on the recipient was based on the assumption that the threat does > >> > not come from the sender and only from some other malicious entity > >> > after the packet has been sent. > >> > > >> > This was the reason for simplifying the header check by using the > >> > ICV, instead of explicitly checking every field. > >> > >> Note that the current draft *does* explicitly check ever field. > >> Are you proposing removing those checks? > >> > >> Best regards, > >> Pasi > >> (not wearing any hats) > >> _______________________________________________ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > >> > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > ------------------------------ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > End of IPsec Digest, Vol 69, Issue 31 > ************************************* --=_alternative 007923C1882576A9_= Content-Type: text/html; charset="US-ASCII"
The "MUST return TEMPORARY_FAILURE" wording was not in the text
proposed by the issue #22 design team.  The original wording was
"will return TEMPORARY_FAILURE".  Had the team carefully
considered a SHOULD versus MUST in this case I suspect we would
have picked "SHOULD".  Anyway, my vote is for "SHOULD return
TEMPORARY_FAILURE" in section 2.8.2

> Message: 5
> Date: Sun, 10 Jan 2010 17:13:30 -0800
> From: Paul Hoffman <paul.hoffman@vpnc.org>
> Subject: Re: [IPsec] Issue #131: Returning TEMPORARY_FAILURE: MUST or
>    SHOULD?
> To: IPsecme WG <ipsec@ietf.org>
> Message-ID: <p06240804c7702b9454ff@[10.20.30.158]>
> Content-Type: text/plain; charset="us-ascii"
>
> At 2:29 PM -0800 12/16/09, Paul Hoffman wrote:
> >Section 2.8.2 Simultaneous IKE SA Rekeying states:
> >
> >   If only one peer detects a simultaneous rekey, redundant SAs
> >   are not created.  In this case, when the peer that did not notice the
> >   simultaneous rekey gets the request to rekey the IKE SA that it has
> >   already successfully rekeyed, it MUST return TEMPORARY_FAILURE
> >   because it is an IKE SA that it is currently trying to close (whether
> >   or not it has already sent the delete notification for the SA).
> >
> >Section 2.25.2 (Collisions While Rekeying or Closing IKE SAs) states:
> >
> >   If a peer receives a request to close an IKE SA that it is
> >   currently trying to close, it SHOULD reply as usual, and forget about
> >   its own close request.
> >
> >Based on the text in Section 2.25.2 it seems that perhaps the MUST in
> >Section 2.8.2 is really a SHOULD. Or, based on the text in 2.8.2, the
> >SHOULD in 2.25.2 should be a MUST.
>
> This got no response; does anyone have an opinion?
>
> --Paul Hoffman, Director
> --VPN Consortium
>
>
> ------------------------------
>
> Message: 6
> Date: Sun, 10 Jan 2010 17:15:54 -0800
> From: Paul Hoffman <paul.hoffman@vpnc.org>
> Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06
>    (yes, IKEv2-bis!)
> To: Yaron Sheffer <yaronf@checkpoint.com>, "ipsec@ietf.org"
>    <ipsec@ietf.org>
> Message-ID: <p06240805c7702c147313@[10.20.30.158]>
> Content-Type: text/plain; charset="us-ascii"
>
> At 11:04 AM +0200 12/10/09, Yaron Sheffer wrote:
> >This is to begin a 4 week working group last call for draft-ietf-ipsecme-
> ikev2bis-06. The target status for this document is Proposed Standard, obsoleting
> RFC 4306 and RFC 4718.
> >
> >Please send your comments to the ipsec list by Jan. 5, 2010, as follow-ups to this message.
>
> We hae overshot that by a bit, and there are still three open issues. Please send
> in any last-minute WG LC comments in the next day or two, if you would.
>
> --Paul Hoffman, Director
> --VPN Consortium
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 11 Jan 2010 14:37:48 +0800
> From: Min Huang <huangmin@huaweisymantec.com>
> Subject: Re: [IPsec] Traffic visibility - consensus call
> To: Yaron Sheffer <yaronf@checkpoint.com>
> Cc: ipsec@ietf.org
> Message-ID: <002b01ca9288$97867760$619a1b0a@china.huawei.com>
> Content-Type: text/plain; charset=us-ascii
>
> YES  to both.
>
> The WESP header provides a kind of rapid *deterministic* detection method
> for ESP_NULL packet. The heuristics method is too complex and it calls for
> more computing resource and computing time. I doubt the middle box whether
> will support the heuristics method  for ESP_NULL detection. Although
> including the WESP header into ESP ICV calculation seems modifying ESP, it
> is necessary to check the WESP header integrity for counter certain attacks.
> The explicit  WESP integrity calculation is OK for me, too.
>
> I support WESP for encrypted ESP flow.  WESP has the capacity to provide
> more functions by future extensibility than just traffic visibility for
> ESP_NULL. Nowadays ESP is used much more widely for encrypted flow than
> ESP_NULL flow. It is meaningful for middle detection machines to have the
> ability to detecting encrypted traffic.  And then WESP could provide this
> kind of traffic visibility for both encrypted flow and unencrypted flow in
> future.  
>
> regards,
> Min
>
>
> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org
> <javascript:main.compose('new', 't=ipsec-bounces@ietf.org')> ] On Behalf Of
> Yaron Sheffer
> Sent: Tuesday, January 05, 2010 6:27 AM
> To: ipsec@ietf.org
> Subject: [IPsec] Traffic visibility - consensus call
>
> Hi,
>
> We have had a few "discusses" during the IESG review of the WESP draft. To
> help resolve them, we would like to reopen the following two questions to WG
> discussion. Well reasoned answers are certainly appreciated. But plain "yes"
> or "no" would also be useful in judging the group's consensus.
>
> - The current draft
> (http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11)
> <http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11)>
> defines the ESP trailer's ICV calculation to include the WESP header. This
> has been done to counter certain attacks, but it means that WESP is no
> longer a simple wrapper around ESP - ESP itself is modified. Do you support
> this design decision?
>
> - The current draft allows WESP to be applied to encrypted ESP flows, in
> addition to the originally specified ESP-null. This was intended so that
> encrypted flows can benefit from the future extensibility offered by WESP.
> But arguably, it positions WESP as an alternative to ESP. Do you support
> this design decision?
>
> Thanks,
>      Yaron
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
> <https://www.ietf.org/mailman/listinfo/ipsec>
>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Mon, 11 Jan 2010 09:28:38 +0100
> From: <Pasi.Eronen@nokia.com>
> Subject: Re: [IPsec] Traffic visibility - consensus call
> To: <ken.grewal@intel.com>
> Cc: ipsec@ietf.org
> Message-ID:
>    <808FD6E27AD4884E94820BC333B2DB775840F4BC84@NOK-EUMSG-01.mgdnok.nokia.com>
>    
> Content-Type: text/plain; charset="us-ascii"
>
> Ken Grewal wrote:
>
> > The either-or on using an ICV or explicitly checking the WESP header
> > on the recipient was based on the assumption that the threat does
> > not come from the sender and only from some other malicious entity
> > after the packet has been sent.
> >
> > This was the reason for simplifying the header check by using the
> > ICV, instead of explicitly checking every field.
>
> Note that the current draft *does* explicitly check ever field.
> Are you proposing removing those checks?
>  
> Best regards,
> Pasi
> (not wearing any hats)
>
>
> ------------------------------
>
> Message: 9
> Date: Mon, 11 Jan 2010 14:32:55 +0530
> From: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
> Subject: Re: [IPsec] Traffic visibility - consensus call
> To: "Pasi.Eronen@nokia.com" <Pasi.Eronen@nokia.com>,
>    "ken.grewal@intel.com"   <ken.grewal@intel.com>
> Cc: "ipsec@ietf.org" <ipsec@ietf.org>
> Message-ID:
>    <7C362EEF9C7896468B36C9B79200D8350AB34BB8CB@INBANSXCHMBSA1.in.alcatel-lucent.com>
>    
> Content-Type: text/plain; charset="us-ascii"
>
> I believe Ken is alluding to removing the WESP header from the ICV calculation, and
> relying on explicitly checking the WESP header at the endnodes.
>
> Cheers, Manav
>
> > -----Original Message-----
> > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]
> > On Behalf Of Pasi.Eronen@nokia.com
> > Sent: Monday, January 11, 2010 1.59 PM
> > To: ken.grewal@intel.com
> > Cc: ipsec@ietf.org
> > Subject: Re: [IPsec] Traffic visibility - consensus call
> >
> > Ken Grewal wrote:
> >
> > > The either-or on using an ICV or explicitly checking the WESP header
> > > on the recipient was based on the assumption that the threat does
> > > not come from the sender and only from some other malicious entity
> > > after the packet has been sent.
> > >
> > > This was the reason for simplifying the header check by using the
> > > ICV, instead of explicitly checking every field.
> >
> > Note that the current draft *does* explicitly check ever field.
> > Are you proposing removing those checks?
> >  
> > Best regards,
> > Pasi
> > (not wearing any hats)
> > _______________________________________________
> > IPsec mailing list
> > IPsec@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipsec
> >
>
> ------------------------------
>
> Message: 10
> Date: Mon, 11 Jan 2010 01:23:48 -0800 (PST)
> From: "Dan Harkins" <dharkins@lounge.org>
> Subject: Re: [IPsec] Traffic visibility - consensus call
> To: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
> Cc: "ipsec@ietf.org" <ipsec@ietf.org>,   "Pasi.Eronen@nokia.com"
>    <pasi.eronen@nokia.com>,   "ken.grewal@intel.com" <ken.grewal@intel.com>
> Message-ID:
>    <15b20fc87c91ef1152f2ba42ada44f84.squirrel@www.trepanning.net>
> Content-Type: text/plain;charset=iso-8859-1
>
>
>   Manav,
>
>   So let's say the normal (removed WESP header) ICV calculations by
> ESP are correct but something doesn't match between the (now unprotected)
> WESP header and the rest of the packet. Why should the recipient care?
> WESP is for middleboxes. The end node has an assurance that the
> _meaningful_ portion of the frame was sent by the claimed sender and
> was not modified in transit. Any decisions made by a middlebox that
> might've involved an improperly modified WESP header are over and done
> with. He doesn't care if the packet was properly handled by middleboxes
> or not, he got it and it's correct.
>
>   You trust the end nodes to negotiate WESP and encapsulate their ESP
> packets in WESP but you don't trust the content they put into those
> packets. Is that the trust model you're operating on?
>
>   The more I think of this problem the more worthless WESP becomes.
>
>   Dan.
>
> On Mon, January 11, 2010 1:02 am, Bhatia, Manav (Manav) wrote:
> > I believe Ken is alluding to removing the WESP header from the ICV
> > calculation, and relying on explicitly checking the WESP header at the
> > endnodes.
> >
> > Cheers, Manav
> >
> >> -----Original Message-----
> >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]
> >> On Behalf Of Pasi.Eronen@nokia.com
> >> Sent: Monday, January 11, 2010 1.59 PM
> >> To: ken.grewal@intel.com
> >> Cc: ipsec@ietf.org
> >> Subject: Re: [IPsec] Traffic visibility - consensus call
> >>
> >> Ken Grewal wrote:
> >>
> >> > The either-or on using an ICV or explicitly checking the WESP header
> >> > on the recipient was based on the assumption that the threat does
> >> > not come from the sender and only from some other malicious entity
> >> > after the packet has been sent.
> >> >
> >> > This was the reason for simplifying the header check by using the
> >> > ICV, instead of explicitly checking every field.
> >>
> >> Note that the current draft *does* explicitly check ever field.
> >> Are you proposing removing those checks?
> >>
> >> Best regards,
> >> Pasi
> >> (not wearing any hats)
> >> _______________________________________________
> >> IPsec mailing list
> >> IPsec@ietf.org
> >> https://www.ietf.org/mailman/listinfo/ipsec
> >>
> > _______________________________________________
> > IPsec mailing list
> > IPsec@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipsec
> >
>
>
>
>
> ------------------------------
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
>
> End of IPsec Digest, Vol 69, Issue 31
> *************************************
 --=_alternative 007923C1882576A9_=-- From kivinen@iki.fi Wed Jan 13 01:28:35 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD1DC3A6AA4 for ; Wed, 13 Jan 2010 01:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDaKpAyGMlp3 for ; Wed, 13 Jan 2010 01:28:35 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id CD6013A69F0 for ; Wed, 13 Jan 2010 01:28:34 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0D9STnG028562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jan 2010 11:28:29 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0D9SSCj028596; Wed, 13 Jan 2010 11:28:28 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19277.37436.589199.63256@fireball.kivinen.iki.fi> Date: Wed, 13 Jan 2010 11:28:28 +0200 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: <19276.13229.412264.229979@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 2 min Cc: ipsec@ietf.org Subject: Re: [IPsec] ikev2bis clarification on port floating X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 09:28:35 -0000 Scott C Moonen writes: > Tero, > > > > 2) Disallow floating on IKE_SA_INIT unless . . . > > Why do you want to disallow that? . . . > > > > > 3) Disallow this elective use of UDP-encap unless . . . > > Again why do that? > > I guess I'm thinking more about what is advisable (without out-of-band > knowledge or inference) than what is permissible, so that may be out of > scope. And I should have said "recommend against" rather than "disallow". Ok, that makes much more sense. On the other hand the current text tries to make the recipient part so that we do not need to change that, even if someone later proposes modifications that use out-of-band or similar knowledge and defines how those are used. So it is ok to add text saying that you should not use those features as a initiator, but you still must to be able to receive them as a responder. -- kivinen@iki.fi From kent@bbn.com Wed Jan 13 11:01:38 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A24C28C148 for ; Wed, 13 Jan 2010 11:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZ3anicKOxv0 for ; Wed, 13 Jan 2010 11:01:37 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id C878628C106 for ; Wed, 13 Jan 2010 11:01:37 -0800 (PST) Received: from dhcp89-089-182.bbn.com ([128.89.89.182]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NV8TF-000AkQ-8X; Wed, 13 Jan 2010 14:01:33 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350AB34BB8FB@INBANSXCHMBSA1.in.alcatel-luce nt.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB775840F4BC84@NOK-EUMSG-01.mgdnok.nokia.com> <7C362EEF9C7896468B36C9B79200D8350AB34BB8CB@INBANSXCHMBSA1.in.alcatel-luce nt.com> <15b20fc87c91ef1152f2ba42ada44f84.squirrel@www.trepanning.net> <7C362EEF9C7896468B36C9B79200D8350AB34BB8FB@INBANSXCHMBSA1.in.alcatel-luce nt.com> Date: Wed, 13 Jan 2010 13:53:25 -0500 To: "Bhatia, Manav (Manav)" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" , "Pasi.Eronen@nokia.com" , Dan Harkins , "ken.grewal@intel.com" Subject: Re: [IPsec] Traffic visibility - consensus call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 19:01:38 -0000 At 3:02 PM +0530 1/11/10, Bhatia, Manav (Manav) wrote: >Dan, > >> >> You trust the end nodes to negotiate WESP and encapsulate their ESP >> packets in WESP but you don't trust the content they put into those >> packets. Is that the trust model you're operating on? > >No. > >We trust the end nodes to put the right information in the WESP >header. But, we don't trust the intermediaries, that could have >mangled the packet so that it goes through the firewall/deep >inspection device. > >If that happens, then the packet should not be consumed, which would >make the attack by a malicious middle box worthless. > >Hope this helps. > >Manav I don' know about anyone else, but it didn't clarify the threat model for me :-). In some messages the phrase "trusted intermediaries" is used, which does not seem to fit your text above. If you are alluding to a MITM, say so. Steve From wierbows@us.ibm.com Wed Jan 13 19:21:28 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9A543A68D1 for ; Wed, 13 Jan 2010 19:21:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6Aww3-5CYhx for ; Wed, 13 Jan 2010 19:21:27 -0800 (PST) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by core3.amsl.com (Postfix) with ESMTP id 4A0E53A681E for ; Wed, 13 Jan 2010 19:21:27 -0800 (PST) Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e3.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o0E3BL4e020659 for ; Wed, 13 Jan 2010 22:11:21 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o0E3LGEs132044 for ; Wed, 13 Jan 2010 22:21:16 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o0E3LGEa006908 for ; Wed, 13 Jan 2010 22:21:16 -0500 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av01.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o0E3LFLs006905 for ; Wed, 13 Jan 2010 22:21:15 -0500 X-KeepSent: 604BF75D:B2C4C1F6-852576AB:000EFDBA; type=4; name=$KeepSent To: IPsecme WG X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: David Wierbowski Date: Wed, 13 Jan 2010 22:21:13 -0500 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 01/13/2010 22:21:15 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [IPsec] Config payload text in Section 4 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 03:21:28 -0000 Section 4 of IKEv2bis (and RFC 4306) states: IKEv2 is designed to permit minimal implementations that can interoperate with all compliant implementations. There are a series of optional features that can easily be ignored by a particular implementation if it does not support that feature. Those features include: o Ability to negotiate SAs through a NAT and tunnel the resulting ESP SA over UDP. o Ability to request (and respond to a request for) a temporary IP address on the remote end of a tunnel. A little further down Section 4 also states: Implementations are not required to support requesting temporary IP addresses or responding to such requests. Finally Section 4 also states: A minimal IPv4 responder implementation will ignore the contents of the CP payload except to determine that it includes an INTERNAL_IP4_ADDRESS attribute and will respond with the address and other related attributes regardless of whether the initiator requested them. A minimal IPv4 initiator will generate a CP payload containing only an INTERNAL_IP4_ADDRESS attribute and will parse the response ignoring attributes it does not know how to use. By reading all the text in Section 4 it is seems that "minimal IPv4 responder implementation" means an implementation that minimally supports responding to a config payload request and that "minimal IPv4 initiator" means an implementation that minimally supports requesting a temporary IP address. Unfortunately, the terms "minimal IPv4 responder implementation" and "minimal IPv4 initiator" alone are somewhat ambiguous and can be interpreted as contradiction to the first two statements I cited above. I suggest changing the text in the last two paragraphs I cited to: An implementation that minimally supports responding to a request for a temporary IP address will ignore the contents of the CP payload except to determine that it includes an INTERNAL_IP4_ADDRESS attribute and will respond with the address and other related attributes regardless of whether the initiator requested them. An implementation that minimally supports requesting a temporary IP address will generate a CP payload containing only an INTERNAL_IP4_ADDRESS attribute and will parse the response ignoring attributes it does not know how to use. Dave Wierbowski From yaronf@checkpoint.com Thu Jan 14 00:39:50 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB7593A6958 for ; Thu, 14 Jan 2010 00:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2DSbS2531Dl for ; Thu, 14 Jan 2010 00:39:50 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id A9ADE3A6966 for ; Thu, 14 Jan 2010 00:39:49 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0E8diT7012590 for ; Thu, 14 Jan 2010 10:39:44 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 14 Jan 2010 10:39:57 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Thu, 14 Jan 2010 10:39:54 +0200 Thread-Topic: Traffic visibility - proposed way forward Thread-Index: AcqSuO8rwfrDHMTFRqqAnab43TA7+gAwLu5QAF7Go1A= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A218F3@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] Traffic visibility - proposed way forward X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 08:39:51 -0000 Hi, We posted the proposed resolution 2 days ago, and have heard no objections = on the list. So I'd like to ask the editors of the Traffic Visibility draft= to revise the draft in light of this resolution, and close all other issue= s that were raised by the IESG (there were quite a few: https://datatracker= .ietf.org/idtracker/draft-ietf-ipsecme-traffic-visibility/). Given the numb= er of changes, we will ensure that the WG has a chance to review the draft = before it is returned to the IESG for consideration, and hopefully approval= . Thanks, Yaron -----Original Message----- From: Yaron Sheffer=20 Sent: Tuesday, January 12, 2010 13:37 To: 'ipsec@ietf.org' Subject: Traffic visibility - proposed way forward Hi, Thanks to the IESG feedback, we have had a long and enlightening discussion= on the list. But we have not reached consensus on either of the two questi= ons. As a result, Paul and I are proposing the following resolution, which = appears to be acceptable both to the draft's editors and to the IESG member= s. Unless there are strong objections from multiple WG participants, we wil= l ask the editors to rev the draft in the next few days according to this p= roposal. Motivation: retain deterministic traffic visibility for middleboxes with a = smooth migration path, while ensuring that WESP does not change ESP, and is= not (nor seen as) ESPv4. - Return ICV to its former ESP-only definition. - Maintain the Encrypted bit, as per the latest version of the draft. - Make the padding field have the minimal possible length, possibly 0. Elim= inate the Padding Length field (the first octet). [Essentially roll back to= version -10]. - WESPv1 will not accept extensions. Any extensions will need a WESPv2, inc= luding some integrity protection for the new data. - Clarify the text about Version/HdrLen as proposed in the thread related t= o Jari's discuss - so even if we add extensions later, and bump the version= number, HdrLen/TrailerLen will be in the same place, and middleboxes can s= till find where the actual packet starts/ends Thanks, Yaron From kivinen@iki.fi Thu Jan 14 04:05:33 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B0823A6819 for ; Thu, 14 Jan 2010 04:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iflEgCWKEI6E for ; Thu, 14 Jan 2010 04:05:32 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 701223A672F for ; Thu, 14 Jan 2010 04:05:31 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0EC5Nxc000888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 14 Jan 2010 14:05:23 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0EC5NJK004018; Thu, 14 Jan 2010 14:05:23 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19279.2179.103236.985956@fireball.kivinen.iki.fi> Date: Thu, 14 Jan 2010 14:05:23 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 6 min Subject: [IPsec] Review of section 1 of the draft-ietf-ipsecme-ikev2bis-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 12:05:33 -0000 This is my first part of my review of ikev2bis document. This includes changes based on going through section 1. ---------------------------------------------------------------------- Section 1 defines following terms: IKE SA, Child SA, message, request, response, and exchange. The document uses sometimes "reply" instead of "response", so I think it should be consistent in its use of terms. This means that following uses of "reply" should be changed to "response". - Section 1.4.1 Deleting an SA with INFORMATIONAL Exchanges change "Normally, the reply in the INFORMATIONAL exchange will contain delete payloads for the paired SAs going in the other direction" with "Normally, the response in the INFORMATIONAL exchange will contain delete payloads for the paired SAs going in the other direction" - Section 2.1. Use of Retransmission Timers change "IKE is a reliable protocol, in the sense that the initiator MUST retransmit a request until either it receives a corresponding reply OR it deems the IKE security association to have failed and it discards all state associated with the IKE SA and any Child SAs negotiated using that IKE SA. " with "IKE is a reliable protocol, in the sense that the initiator MUST retransmit a request until either it receives a corresponding response OR it deems the IKE security association to have failed and it discards all state associated with the IKE SA and any Child SAs negotiated using that IKE SA. " - Section 2.6. IKE SA SPIs and Cookies change "An attacker can forge multiple cookie responses to the initiator's IKE_SA_INIT message, and each of those forged cookie replies will trigger two packets: one packet from the initiator to the responder (which will reject those cookies), and one reply from responder to initiator that includes the correct cookie." with "An attacker can forge multiple cookie responses to the initiator's IKE_SA_INIT message, and each of those forged cookie replies will trigger two packets: one packet from the initiator to the responder (which will reject those cookies), and one response from responder to initiator that includes the correct cookie." - Section 2.23.1. Transport Mode NAT Traversal change "When the client receives the server's reply to the Child SA, it will do similar processing." with "When the client receives the server's response to the Child SA, it will do similar processing." and change "If transport mode for the SA was selected (that is, if the server included USE_TRANSPORT_MODE notification in its reply):" with "If transport mode for the SA was selected (that is, if the server included USE_TRANSPORT_MODE notification in its response):" - Section 3.15.1. Configuration Attributes change "INTERNAL_IP4_NETMASK - The internal network's netmask. Only one netmask is allowed in the request and reply messages" with "INTERNAL_IP4_NETMASK - The internal network's netmask. Only one netmask is allowed in the request and response messages" and change "Note that no recommendations are made in this document as to how an implementation actually figures out what information to send in a reply." with "Note that no recommendations are made in this document as to how an implementation actually figures out what information to send in a response." - Section 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET change "A different possible reply would have been this:" with "A different possible response would have been this:" and change "That reply would mean that the client can send all its traffic through the gateway, but the gateway does not mind if the client sends traffic not included by INTERNAL_IP4_SUBNET directly to the destination (without going through the gateway)." with "That response would mean that the client can send all its traffic through the gateway, but the gateway does not mind if the client sends traffic not included by INTERNAL_IP4_SUBNET directly to the destination (without going through the gateway)." and change "then the gateway's reply might be:" with "then the gateway's response might be:" - Section 4. Conformance Requirements change "Every implementation MUST be capable of responding to an INFORMATIONAL exchange, but a minimal implementation MAY respond to any INFORMATIONAL message with an empty INFORMATIONAL reply" with "Every implementation MUST be capable of responding to an INFORMATIONAL exchange, but a minimal implementation MAY respond to any INFORMATIONAL message with an empty INFORMATIONAL response" In other cases the "reply" should be kept as it is now, as it does not refer response message. ---------------------------------------------------------------------- The document also uses both "Child SA" and "IPsec SA" quite often, and I think they are meant to mean same... ---------------------------------------------------------------------- In section 1.2 there is one instance of "IKE_INFORMATINAL exchange", which should be "INFORMATIONAL exchange" instead. ---------------------------------------------------------------------- In section 1.3 at the end there is text talking about the NO_ADDITIONAL_SAS. The current text is in the generic CREATE_CHILD_SA section thus it covers all 3 use cases for CREATE_CHILD_SA (creating new IPsec SAs, rekeying old IPsec SAs and rekeying IKE SA). The text there is written to cover only new IPsec SAs, but I think it should also cover rekeying IKE SA cases (section 4 conformance requirements makes it quite clear you can return NO_ADDITIONAL_SAS to any CREATE_CHILD_SA exchange including IKE SA rekey). This means the text should be changed from The responder sends a NO_ADDITIONAL_SAS notification to indicate that a CREATE_CHILD_SA request is unacceptable because the responder is unwilling to accept any more Child SAs on this IKE SA. Some minimal implementations may only accept a single Child SA setup in the context of an initial IKE exchange and reject any subsequent attempts to add more. To The responder sends a NO_ADDITIONAL_SAS notification to indicate that a CREATE_CHILD_SA request is unacceptable because the responder is unwilling to accept any more Child SAs on this IKE SA. This notify can also be used to reject IKE SA rekey. Some minimal implementations may only accept a single Child SA setup in the context of an initial IKE exchange and reject any subsequent attempts to add more. ---------------------------------------------------------------------- Section 1.3.1 now talks about the USE_TRANSPORT_MODE, ESP_TFC_PADDING_NOT_SUPPORTED and NON_FIRST_FRAMENTS_ALSO notifications, and says they can be included, but the packet figure does not include them. Adding them to the figure would be easy, but the problem is that we currently say that you should follow the order of payloads from the figures (altough we do refer to section 2 not section 1, but this is one of the open issues). So depending what we decided on the payload order and figures, it might be better to add one extra ", [N]" to the figure before SA payload. Also there is one more notify payload which can be included and which affect negotiation, i.e. the IPCOMP_SUPPORTED notification which is covered in the 2.22. Perhaps forward reference should be added to there. Also the section 1.3.1 has text which perhaps should be removed: Failure of an attempt to create a Child SA SHOULD NOT tear down the IKE SA: there is no reason to lose the work done to set up the IKE SA. When an IKE SA is not created, the error message return SHOULD NOT be encrypted because the other party will not be able to authenticate that message. See Section 2.21 for a list of error messages that might occur if creating a Child SA fails. This section 1.3.1 is talking about the CREATE_CHILD_SA not initial IKE_AUTH, thus this section is not needed here. The section 1.2 already has text about the Child SA failing during the initial exchange, so this how paragaraph needs to be removed. ---------------------------------------------------------------------- Section 1.3.3 should make it clear that the first N payload in the figure is the N(REKEY_SA), i.e the diagram should be changed to: Initiator Responder ------------------------------------------------------------------- HDR, SK {N(REKEY_SA), SA, Ni, [KEi], TSi, TSr} --> Also this section should say that other notifications explained in the 1.3.1 can also be included in this exchange, i.e. if transport mode SA was rekeyed then this CREATE_CHILD_SA rekeying that SA needs to include USE_TRANSPORT_MODE notification. Some kind of reference back to the 1.3.1 should be enough. ---------------------------------------------------------------------- Section 1.4 says that INFORMATIONAL exchanges MUST ONLY occur after the initial exchanges and are cryptographically protected with the negotiated keys. This does not match the 1.5 which says we can send INFORMATIONAL exchanges also outside the IKE SA. Perhaps this needs to be changed to: Normally INFORMATIONAL exchanges MUST ONLY occur after the initial exchanges and are cryptographically protected with the negotiated keys (see Section 1.5 for exceptions). ---------------------------------------------------------------------- Section 1.5 needs some reordering and the text in section 1.5 vand 2.21.4 needs to be combined, now we have about the same text in two places. The first paragraph of the 1.5 talks about the INVALID_IKE_SPI even though it does not say it explictly, the second paragraph talks about INVALID_SPI and then in third paragraph it says that "there are two cases when one-way message is sent: INVALID_IKE_SPI and INVALID_SPI", just like this would be new thing, but the previous paragraphs have already talked about this. This is confusing, so I think this section requires bit of reordering and rewording. Also it might be useful to actually move all this text to section 2.21.4 and remove this whole section (remember to update references). Especially the fact that exchange type is copied from the request in the INVALID_IKE_SPI case is missing from the 2.21.4 and should be added there and also the last paragraph about INVALID_SPI text in the 1.5 is something that is not that clearly explained in the 2.21.4 so that also needs to be kept (and/or moved). ---------------------------------------------------------------------- Section 1.6 is way too far from the beginning. We have already used those terms 40 times before this section comes up, so it would be much better that this section would be in the beginning of the document, not at the page 20... Perhaps it should be moved to subsection 1.0.1 and move other defined terms there too. -- kivinen@iki.fi From smoonen@us.ibm.com Thu Jan 14 08:34:53 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 750583A6965; Thu, 14 Jan 2010 08:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.31 X-Spam-Level: X-Spam-Status: No, score=-5.31 tagged_above=-999 required=5 tests=[AWL=1.288, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4-JFi586QT4; Thu, 14 Jan 2010 08:34:50 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by core3.amsl.com (Postfix) with ESMTP id 68DA93A6910; Thu, 14 Jan 2010 08:34:48 -0800 (PST) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e34.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id o0EGSgUi004277; Thu, 14 Jan 2010 09:28:42 -0700 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id o0EGYZE0243972; Thu, 14 Jan 2010 09:34:35 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o0EGYV4T032436; Thu, 14 Jan 2010 09:34:31 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o0EGYVRj032392; Thu, 14 Jan 2010 09:34:31 -0700 In-Reply-To: <19279.2179.103236.985956@fireball.kivinen.iki.fi> References: <19279.2179.103236.985956@fireball.kivinen.iki.fi> To: Tero Kivinen MIME-Version: 1.0 X-KeepSent: CFE85D6B:DBA36B7E-852576AB:0059A0B5; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/14/2010 11:19:08 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/14/2010 11:19:08 AM, Serialize complete at 01/14/2010 11:19:08 AM, S/MIME Sign failed at 01/14/2010 11:19:08 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 01/14/2010 09:34:30, Serialize complete at 01/14/2010 09:34:30 Message-ID: Date: Thu, 14 Jan 2010 11:34:30 -0500 Content-Type: multipart/alternative; boundary="=_alternative 0059A48A852576AB_=" Cc: ipsec@ietf.org, ipsec-bounces@ietf.org Subject: Re: [IPsec] Review of section 1 of the draft-ietf-ipsecme-ikev2bis-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 16:34:53 -0000 This is a multipart message in MIME format. --=_alternative 0059A48A852576AB_= Content-Type: text/plain; charset="US-ASCII" > Section 1.4 says that > > INFORMATIONAL exchanges MUST ONLY occur > after the initial exchanges and are cryptographically protected with > the negotiated keys. > > This does not match the 1.5 which says we can send INFORMATIONAL > exchanges also outside the IKE SA. I think that section 1.5 is pretty careful to distinguish between informational messages (sent outside the IKE SA) and informational exchanges (which occur only within the context of an IKE SA). I'm inclined to keep the Section 1.4 text as it is. If you prefer, though, I'd be ok with clarifying Section 1.4 to say "INFORMATIONAL exchanges (to be distinguished from INFORMATIONAL messages sent outside the context of an IKE SA) . . ." Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Tero Kivinen To: ipsec@ietf.org Date: 01/14/2010 07:06 AM Subject: [IPsec] Review of section 1 of the draft-ietf-ipsecme-ikev2bis-06.txt This is my first part of my review of ikev2bis document. This includes changes based on going through section 1. ---------------------------------------------------------------------- Section 1 defines following terms: IKE SA, Child SA, message, request, response, and exchange. The document uses sometimes "reply" instead of "response", so I think it should be consistent in its use of terms. This means that following uses of "reply" should be changed to "response". - Section 1.4.1 Deleting an SA with INFORMATIONAL Exchanges change "Normally, the reply in the INFORMATIONAL exchange will contain delete payloads for the paired SAs going in the other direction" with "Normally, the response in the INFORMATIONAL exchange will contain delete payloads for the paired SAs going in the other direction" - Section 2.1. Use of Retransmission Timers change "IKE is a reliable protocol, in the sense that the initiator MUST retransmit a request until either it receives a corresponding reply OR it deems the IKE security association to have failed and it discards all state associated with the IKE SA and any Child SAs negotiated using that IKE SA. " with "IKE is a reliable protocol, in the sense that the initiator MUST retransmit a request until either it receives a corresponding response OR it deems the IKE security association to have failed and it discards all state associated with the IKE SA and any Child SAs negotiated using that IKE SA. " - Section 2.6. IKE SA SPIs and Cookies change "An attacker can forge multiple cookie responses to the initiator's IKE_SA_INIT message, and each of those forged cookie replies will trigger two packets: one packet from the initiator to the responder (which will reject those cookies), and one reply from responder to initiator that includes the correct cookie." with "An attacker can forge multiple cookie responses to the initiator's IKE_SA_INIT message, and each of those forged cookie replies will trigger two packets: one packet from the initiator to the responder (which will reject those cookies), and one response from responder to initiator that includes the correct cookie." - Section 2.23.1. Transport Mode NAT Traversal change "When the client receives the server's reply to the Child SA, it will do similar processing." with "When the client receives the server's response to the Child SA, it will do similar processing." and change "If transport mode for the SA was selected (that is, if the server included USE_TRANSPORT_MODE notification in its reply):" with "If transport mode for the SA was selected (that is, if the server included USE_TRANSPORT_MODE notification in its response):" - Section 3.15.1. Configuration Attributes change "INTERNAL_IP4_NETMASK - The internal network's netmask. Only one netmask is allowed in the request and reply messages" with "INTERNAL_IP4_NETMASK - The internal network's netmask. Only one netmask is allowed in the request and response messages" and change "Note that no recommendations are made in this document as to how an implementation actually figures out what information to send in a reply." with "Note that no recommendations are made in this document as to how an implementation actually figures out what information to send in a response." - Section 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET change "A different possible reply would have been this:" with "A different possible response would have been this:" and change "That reply would mean that the client can send all its traffic through the gateway, but the gateway does not mind if the client sends traffic not included by INTERNAL_IP4_SUBNET directly to the destination (without going through the gateway)." with "That response would mean that the client can send all its traffic through the gateway, but the gateway does not mind if the client sends traffic not included by INTERNAL_IP4_SUBNET directly to the destination (without going through the gateway)." and change "then the gateway's reply might be:" with "then the gateway's response might be:" - Section 4. Conformance Requirements change "Every implementation MUST be capable of responding to an INFORMATIONAL exchange, but a minimal implementation MAY respond to any INFORMATIONAL message with an empty INFORMATIONAL reply" with "Every implementation MUST be capable of responding to an INFORMATIONAL exchange, but a minimal implementation MAY respond to any INFORMATIONAL message with an empty INFORMATIONAL response" In other cases the "reply" should be kept as it is now, as it does not refer response message. ---------------------------------------------------------------------- The document also uses both "Child SA" and "IPsec SA" quite often, and I think they are meant to mean same... ---------------------------------------------------------------------- In section 1.2 there is one instance of "IKE_INFORMATINAL exchange", which should be "INFORMATIONAL exchange" instead. ---------------------------------------------------------------------- In section 1.3 at the end there is text talking about the NO_ADDITIONAL_SAS. The current text is in the generic CREATE_CHILD_SA section thus it covers all 3 use cases for CREATE_CHILD_SA (creating new IPsec SAs, rekeying old IPsec SAs and rekeying IKE SA). The text there is written to cover only new IPsec SAs, but I think it should also cover rekeying IKE SA cases (section 4 conformance requirements makes it quite clear you can return NO_ADDITIONAL_SAS to any CREATE_CHILD_SA exchange including IKE SA rekey). This means the text should be changed from The responder sends a NO_ADDITIONAL_SAS notification to indicate that a CREATE_CHILD_SA request is unacceptable because the responder is unwilling to accept any more Child SAs on this IKE SA. Some minimal implementations may only accept a single Child SA setup in the context of an initial IKE exchange and reject any subsequent attempts to add more. To The responder sends a NO_ADDITIONAL_SAS notification to indicate that a CREATE_CHILD_SA request is unacceptable because the responder is unwilling to accept any more Child SAs on this IKE SA. This notify can also be used to reject IKE SA rekey. Some minimal implementations may only accept a single Child SA setup in the context of an initial IKE exchange and reject any subsequent attempts to add more. ---------------------------------------------------------------------- Section 1.3.1 now talks about the USE_TRANSPORT_MODE, ESP_TFC_PADDING_NOT_SUPPORTED and NON_FIRST_FRAMENTS_ALSO notifications, and says they can be included, but the packet figure does not include them. Adding them to the figure would be easy, but the problem is that we currently say that you should follow the order of payloads from the figures (altough we do refer to section 2 not section 1, but this is one of the open issues). So depending what we decided on the payload order and figures, it might be better to add one extra ", [N]" to the figure before SA payload. Also there is one more notify payload which can be included and which affect negotiation, i.e. the IPCOMP_SUPPORTED notification which is covered in the 2.22. Perhaps forward reference should be added to there. Also the section 1.3.1 has text which perhaps should be removed: Failure of an attempt to create a Child SA SHOULD NOT tear down the IKE SA: there is no reason to lose the work done to set up the IKE SA. When an IKE SA is not created, the error message return SHOULD NOT be encrypted because the other party will not be able to authenticate that message. See Section 2.21 for a list of error messages that might occur if creating a Child SA fails. This section 1.3.1 is talking about the CREATE_CHILD_SA not initial IKE_AUTH, thus this section is not needed here. The section 1.2 already has text about the Child SA failing during the initial exchange, so this how paragaraph needs to be removed. ---------------------------------------------------------------------- Section 1.3.3 should make it clear that the first N payload in the figure is the N(REKEY_SA), i.e the diagram should be changed to: Initiator Responder ------------------------------------------------------------------- HDR, SK {N(REKEY_SA), SA, Ni, [KEi], TSi, TSr} --> Also this section should say that other notifications explained in the 1.3.1 can also be included in this exchange, i.e. if transport mode SA was rekeyed then this CREATE_CHILD_SA rekeying that SA needs to include USE_TRANSPORT_MODE notification. Some kind of reference back to the 1.3.1 should be enough. ---------------------------------------------------------------------- Section 1.4 says that INFORMATIONAL exchanges MUST ONLY occur after the initial exchanges and are cryptographically protected with the negotiated keys. This does not match the 1.5 which says we can send INFORMATIONAL exchanges also outside the IKE SA. Perhaps this needs to be changed to: Normally INFORMATIONAL exchanges MUST ONLY occur after the initial exchanges and are cryptographically protected with the negotiated keys (see Section 1.5 for exceptions). ---------------------------------------------------------------------- Section 1.5 needs some reordering and the text in section 1.5 vand 2.21.4 needs to be combined, now we have about the same text in two places. The first paragraph of the 1.5 talks about the INVALID_IKE_SPI even though it does not say it explictly, the second paragraph talks about INVALID_SPI and then in third paragraph it says that "there are two cases when one-way message is sent: INVALID_IKE_SPI and INVALID_SPI", just like this would be new thing, but the previous paragraphs have already talked about this. This is confusing, so I think this section requires bit of reordering and rewording. Also it might be useful to actually move all this text to section 2.21.4 and remove this whole section (remember to update references). Especially the fact that exchange type is copied from the request in the INVALID_IKE_SPI case is missing from the 2.21.4 and should be added there and also the last paragraph about INVALID_SPI text in the 1.5 is something that is not that clearly explained in the 2.21.4 so that also needs to be kept (and/or moved). ---------------------------------------------------------------------- Section 1.6 is way too far from the beginning. We have already used those terms 40 times before this section comes up, so it would be much better that this section would be in the beginning of the document, not at the page 20... Perhaps it should be moved to subsection 1.0.1 and move other defined terms there too. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 0059A48A852576AB_= Content-Type: text/html; charset="US-ASCII"
> Section 1.4 says that
>
>                  INFORMATIONAL exchanges MUST ONLY occur
>    after the initial exchanges and are cryptographically protected with
>    the negotiated keys.
>
> This does not match the 1.5 which says we can send INFORMATIONAL
> exchanges also outside the IKE SA.

I think that section 1.5 is pretty careful to distinguish between informational messages (sent outside the IKE SA) and informational exchanges (which occur only within the context of an IKE SA).  I'm inclined to keep the Section 1.4 text as it is.  If you prefer, though, I'd be ok with clarifying Section 1.4 to say "INFORMATIONAL exchanges (to be distinguished from INFORMATIONAL messages sent outside the context of an IKE SA) . . ."


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen


From: Tero Kivinen <kivinen@iki.fi>
To: ipsec@ietf.org
Date: 01/14/2010 07:06 AM
Subject: [IPsec] Review of section 1 of the        draft-ietf-ipsecme-ikev2bis-06.txt




This is my first part of my review of ikev2bis document. This includes
changes based on going through section 1.

----------------------------------------------------------------------
Section 1 defines following terms: IKE SA, Child SA, message, request,
response, and exchange. The document uses sometimes "reply" instead of
"response", so I think it should be consistent in its use of terms.
This means that following uses of "reply" should be changed to
"response".

- Section 1.4.1 Deleting an SA with INFORMATIONAL Exchanges
 change
 
 "Normally, the reply in the INFORMATIONAL exchange will contain
  delete payloads for the paired SAs going in the other direction"

 with

 "Normally, the response in the INFORMATIONAL exchange will contain
  delete payloads for the paired SAs going in the other direction"

- Section 2.1. Use of Retransmission Timers
 change

 "IKE is a reliable protocol, in the sense that the initiator MUST
  retransmit a request until either it receives a corresponding reply
  OR it deems the IKE security association to have failed and it
  discards all state associated with the IKE SA and any Child SAs
  negotiated using that IKE SA. "

 with
 
 "IKE is a reliable protocol, in the sense that the initiator MUST
  retransmit a request until either it receives a corresponding
  response OR it deems the IKE security association to have failed
  and it discards all state associated with the IKE SA and any Child
  SAs negotiated using that IKE SA. "

- Section 2.6.  IKE SA SPIs and Cookies
 change

 "An attacker can forge multiple cookie responses to the initiator's
  IKE_SA_INIT message, and each of those forged cookie replies will
  trigger two packets: one packet from the initiator to the responder
  (which will reject those cookies), and one reply from responder to
  initiator that includes the correct cookie."

 with

 "An attacker can forge multiple cookie responses to the initiator's
  IKE_SA_INIT message, and each of those forged cookie replies will
  trigger two packets: one packet from the initiator to the responder
  (which will reject those cookies), and one response from responder
  to initiator that includes the correct cookie."

- Section 2.23.1.  Transport Mode NAT Traversal
 change

 "When the client receives the server's reply to the Child SA, it will
  do similar processing."

 with

 "When the client receives the server's response to the Child SA, it
  will do similar processing."

 and change

 "If transport mode for the SA was selected (that is, if the server
  included USE_TRANSPORT_MODE notification in its reply):"

 with

 "If transport mode for the SA was selected (that is, if the server
  included USE_TRANSPORT_MODE notification in its response):"

- Section 3.15.1.  Configuration Attributes
 change

 "INTERNAL_IP4_NETMASK - The internal network's netmask. Only one
  netmask is allowed in the request and reply messages"

 with

 "INTERNAL_IP4_NETMASK - The internal network's netmask.  Only one
  netmask is allowed in the request and response messages"

 and change

 "Note that no recommendations are made in this document as to how an
  implementation actually figures out what information to send in a
  reply."

 with

 "Note that no recommendations are made in this document as to how an
  implementation actually figures out what information to send in a
  response."

- Section 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET
 change

 "A different possible reply would have been this:"

 with

 "A different possible response would have been this:"

 and change

 "That reply would mean that the client can send all its traffic
  through the gateway, but the gateway does not mind if the client
  sends traffic not included by INTERNAL_IP4_SUBNET directly to the
  destination (without going through the gateway)."

 with

 "That response would mean that the client can send all its traffic
  through the gateway, but the gateway does not mind if the client
  sends traffic not included by INTERNAL_IP4_SUBNET directly to the
  destination (without going through the gateway)."

 and change

 "then the gateway's reply might be:"

 with

 "then the gateway's response might be:"

- Section 4.  Conformance Requirements
 change

 "Every implementation MUST be capable of responding to an
  INFORMATIONAL exchange, but a minimal implementation MAY respond to
  any INFORMATIONAL message with an empty INFORMATIONAL reply"

 with

 "Every implementation MUST be capable of responding to an
  INFORMATIONAL exchange, but a minimal implementation MAY respond to
  any INFORMATIONAL message with an empty INFORMATIONAL response"

In other cases the "reply" should be kept as it is now, as it does not
refer response message.

----------------------------------------------------------------------

The document also uses both "Child SA" and "IPsec SA" quite often, and
I think they are meant to mean same...

----------------------------------------------------------------------

In section 1.2 there is one instance of "IKE_INFORMATINAL exchange",
which should be "INFORMATIONAL exchange" instead.

----------------------------------------------------------------------

In section 1.3 at the end there is text talking about the
NO_ADDITIONAL_SAS. The current text is in the generic CREATE_CHILD_SA
section thus it covers all 3 use cases for CREATE_CHILD_SA (creating
new IPsec SAs, rekeying old IPsec SAs and rekeying IKE SA). The text
there is written to cover only new IPsec SAs, but I think it should
also cover rekeying IKE SA cases (section 4 conformance requirements
makes it quite clear you can return NO_ADDITIONAL_SAS to any
CREATE_CHILD_SA exchange including IKE SA rekey).

This means the text should be changed from

  The responder sends a NO_ADDITIONAL_SAS notification to indicate that
  a CREATE_CHILD_SA request is unacceptable because the responder is
  unwilling to accept any more Child SAs on this IKE SA.  Some minimal
  implementations may only accept a single Child SA setup in the
  context of an initial IKE exchange and reject any subsequent attempts
  to add more.

To

  The responder sends a NO_ADDITIONAL_SAS notification to indicate that
  a CREATE_CHILD_SA request is unacceptable because the responder is
  unwilling to accept any more Child SAs on this IKE SA. This notify can
  also be used to reject IKE SA rekey. Some minimal implementations may
  only accept a single Child SA setup in the context of an initial IKE
  exchange and reject any subsequent attempts to add more.

----------------------------------------------------------------------

Section 1.3.1 now talks about the USE_TRANSPORT_MODE,
ESP_TFC_PADDING_NOT_SUPPORTED and NON_FIRST_FRAMENTS_ALSO notifications,
and says they can be included, but the packet figure does not include
them. Adding them to the figure would be easy, but the problem is that we
currently say that you should follow the order of payloads from the
figures (altough we do refer to section 2 not section 1, but this is one
of the open issues).

So depending what we decided on the payload order and figures, it might
be better to add one extra ", [N]" to the figure before SA payload.

Also there is one more notify payload which can be included and which
affect negotiation, i.e. the IPCOMP_SUPPORTED notification which is
covered in the 2.22. Perhaps forward reference should be added to there.

Also the section 1.3.1 has text which perhaps should be removed:

  Failure of an attempt to create a Child SA SHOULD NOT tear down the
  IKE SA: there is no reason to lose the work done to set up the IKE
  SA.  When an IKE SA is not created, the error message return SHOULD
  NOT be encrypted because the other party will not be able to
  authenticate that message.  See Section 2.21 for a list of error
  messages that might occur if creating a Child SA fails.

This section 1.3.1 is talking about the CREATE_CHILD_SA not initial
IKE_AUTH, thus this section is not needed here. The section 1.2 already
has text about the Child SA failing during the initial exchange, so this
how paragaraph needs to be removed.

----------------------------------------------------------------------

Section 1.3.3 should make it clear that the first N payload in the figure
is the N(REKEY_SA), i.e the diagram should be changed to:

  Initiator                         Responder
  -------------------------------------------------------------------
  HDR, SK {N(REKEY_SA), SA, Ni, [KEi],
      TSi, TSr}   -->

Also this section should say that other notifications explained in the
1.3.1 can also be included in this exchange, i.e. if transport mode SA
was rekeyed then this CREATE_CHILD_SA rekeying that SA needs to include
USE_TRANSPORT_MODE notification. Some kind of reference back to the 1.3.1
should be enough.

----------------------------------------------------------------------

Section 1.4 says that

                INFORMATIONAL exchanges MUST ONLY occur
  after the initial exchanges and are cryptographically protected with
  the negotiated keys.

This does not match the 1.5 which says we can send INFORMATIONAL
exchanges also outside the IKE SA.

Perhaps this needs to be changed to:

                Normally INFORMATIONAL exchanges MUST ONLY occur
  after the initial exchanges and are cryptographically protected with
  the negotiated keys (see Section 1.5 for exceptions).

----------------------------------------------------------------------

Section 1.5 needs some reordering and the text in section 1.5 vand 2.21.4
needs to be combined, now we have about the same text in two places.

The first paragraph of the 1.5 talks about the INVALID_IKE_SPI even
though it does not say it explictly, the second paragraph talks about
INVALID_SPI and then in third paragraph it says that "there are two cases
when one-way message is sent: INVALID_IKE_SPI and INVALID_SPI", just like
this would be new thing, but the previous paragraphs have already talked
about this. This is confusing, so I think this section requires bit of
reordering and rewording. Also it might be useful to actually move all
this text to section 2.21.4 and remove this whole section (remember
to update references).

Especially the fact that exchange type is copied from the request in
the INVALID_IKE_SPI case is missing from the 2.21.4 and should be
added there and also the last paragraph about INVALID_SPI text in the
1.5 is something that is not that clearly explained in the 2.21.4 so
that also needs to be kept (and/or moved).

----------------------------------------------------------------------

Section 1.6 is way too far from the beginning. We have already used
those terms 40 times before this section comes up, so it would be much
better that this section would be in the beginning of the document,
not at the page 20... Perhaps it should be moved to subsection 1.0.1
and move other defined terms there too.
--
kivinen@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--=_alternative 0059A48A852576AB_=-- From paul.hoffman@vpnc.org Thu Jan 14 10:13:48 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79D703A6991 for ; Thu, 14 Jan 2010 10:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.94 X-Spam-Level: X-Spam-Status: No, score=-5.94 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4M2mF8dLkcXF for ; Thu, 14 Jan 2010 10:13:47 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 4E01D3A6810 for ; Thu, 14 Jan 2010 10:13:47 -0800 (PST) Received: from [75.101.18.87] (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0EI13sG032382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 14 Jan 2010 11:01:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 14 Jan 2010 10:01:01 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Proposed wording for rechartering the IPsecME WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 18:13:48 -0000 Greetings again. Yaron and Pasi and I have put our heads together on the seven proposed new work items for the WG. Of the seven, we propose that four go ahead as WG work items and three not; see the descriptions below. We will turn in this proposed rechartering within a week, but are quite open to changes to the proposed charter wording for the proposed work items. ===== Quick Crash Discovery (QCD) for IKEv2 Proposed charter text: An IKEv2 standards-track extension that allows an IKE peer to quickly and securely detect that its opposite peer, while currently reachable, has lost its IKEv2/IPsec state. Changes to how the peers recover from this situation are beyond the scope of this work item, as is improving the detection of an unreachable or dead peer. Ideas from draft-nir-ike-qcd-05 and draft-detienne-ikev2-recovery-03 can be used as starting points. ===== EAP-only IKEv2 Proposed charter text: The WG will develop a standards-track IKEv2 extension to allow mutual EAP-based authentication in IKEv2, eliminating the need for the responder to present a certificate. The document will define the conditions that EAP methods need to fulfill in order to use this extension. The document will recommend, but will not require, the use of EAP methods that provide EAP channel binding. The proposed starting point for this work is draft-eronen-ipsec-ikev2-eap-auth-07.txt. ===== Password-based mutual authentication for IKEv2 Proposed charter text: IKEv2 supports mutual authentication with a shared secret, but this mechanism is intended for "strong" shared secrets. User-chosen passwords are typically of low entropy and subject to off-line dictionary attacks when used with this mechanism. Thus, RFC 4306 recommends using EAP with public-key based authentication of the responder instead. This approach would be typically used in enterprise remote access VPN scenarios where the VPN gateway does not usually even have the actual passwords for all users, but instead typically communicates with a back-end RADIUS server. However, user-configured shared secrets are still useful for many other IPsec scenarios, such as authentication between two servers or routers. These scenarios are usually symmetric: both peers know the shared secret, no back-end authentication servers are involved, and either peer can initiate an IKEv2 SA. These features make using EAP (with its strict client-server separation) undesirable. The WG will develop a standards-track extension to IKEv2 to allow mutual authentication based on "weak" (low-entropy) shared secrets. The goal is to avoid off-line dictionary attacks without requiring the use of certificates or EAP. There are many already-developed algorithms that can be used, and the WG would need to pick one that both is believed to be secure and is believed to have acceptable intellectual property features. The WG would also need to develop the protocol to use the chosen algorithm in IKEv2 in a secure fashion. It is noted up front that this work item poses a higher chance of failing to be completed than other WG work items; this is balanced by the very high expected value of the extension if it is standardized and deployed. ===== High Availability/Load Sharing Proposed charter text: IPsec gateways are often deployed in clusters that look like a single gateway to the peer (such as for high availability and load balancing reasons). However, correctly maintaining the appearance to the peer of a single gateway is complicated; one of the main challenges is the strict use of sequence numbers both in IKEv2 and ESP/AH. This work item will define a problem statement and requirements for potential IPsec/IKEv2 mechanism (or multiple mechanisms) to simplify cluster implementations. The result will be an informational document that, once completed, may lead to chartering one or more new work items to specify the actual mechanisms. The scope is restricted to mechanism(s) that are visible to the peer, and thus usually require interoperability between vendors. Mixed-vendor clusters, and protocols between the cluster members, are explicitly out of scope of this work item. The starting point will be draft-nir-ipsecme-ipsecha-00. ===== Childless SAs It is our view that this proposal doesn't make IPsec work better (or even differently) in any user-perceived way. The specification looks almost ready, and does not need any IANA assignments, so we encourage the authors to progress it as an individual submission for standards track instead of a WG work item. ===== WESP Extension Framework / Concrete Extensions The recent discussion of WESPv1 shows that there are a fair number of surprising views on where and how WESP is expected to be used. It is too soon to charter this work. Having a solid set of proposed extensions and a framework for how WESPv2 could be used to handle them would be needed before the WG could decide on taking this work in. ===== Labelled IPsec This one did not have sufficient interest or agreement exactly what should be done. It could come up again later, but more work would need to be done to help the WG understand the work that precedes it and the expected use cases. --Paul Hoffman, Director --VPN Consortium From kivinen@iki.fi Fri Jan 15 00:31:28 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FB573A6941 for ; Fri, 15 Jan 2010 00:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovgzyE5vUzIA for ; Fri, 15 Jan 2010 00:31:27 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 0B0DD3A6939 for ; Fri, 15 Jan 2010 00:31:26 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0F8VIHh009762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Jan 2010 10:31:18 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0F8VH1j008786; Fri, 15 Jan 2010 10:31:17 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19280.10197.22119.999077@fireball.kivinen.iki.fi> Date: Fri, 15 Jan 2010 10:31:17 +0200 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: <19279.2179.103236.985956@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 0 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Review of section 1 of the draft-ietf-ipsecme-ikev2bis-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 08:31:28 -0000 Scott C Moonen writes: > > Section 1.4 says that > > > > INFORMATIONAL exchanges MUST ONLY occur > > after the initial exchanges and are cryptographically protected with > > the negotiated keys. > > > > This does not match the 1.5 which says we can send INFORMATIONAL > > exchanges also outside the IKE SA. > > I think that section 1.5 is pretty careful to distinguish between > informational messages (sent outside the IKE SA) and informational > exchanges (which occur only within the context of an IKE SA). I'm > inclined to keep the Section 1.4 text as it is. If you prefer, though, > I'd be ok with clarifying Section 1.4 to say "INFORMATIONAL exchanges (to > be distinguished from INFORMATIONAL messages sent outside the context of > an IKE SA) . . ." That change looks even better than my proposed one... -- kivinen@iki.fi From kivinen@iki.fi Fri Jan 15 06:29:44 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B7C43A6AA4 for ; Fri, 15 Jan 2010 06:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFvqAbH99QUN for ; Fri, 15 Jan 2010 06:29:42 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id C83453A68B2 for ; Fri, 15 Jan 2010 06:29:41 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0FETWq6009227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 15 Jan 2010 16:29:32 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0FETWH2021476; Fri, 15 Jan 2010 16:29:32 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19280.31692.225087.576574@fireball.kivinen.iki.fi> Date: Fri, 15 Jan 2010 16:29:32 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 2 min Subject: [IPsec] Review of section 2 to 2.23 (not 2.23.1 forward yet). X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 14:29:44 -0000 Here is second set of issues now from the section 2. I didn't get completely through it yet, but I decided to send this now as next time I will be able to get more comments is on Monday. ---------------------------------------------------------------------- In section 2.2 there is duplicate text: The Message ID is reset to zero in the new IKE SA after the IKE SA is rekeyed. Rekeying an IKE SA resets the sequence numbers. Thus, the first pair of IKE_AUTH messages will have ID of 1, the second (when EAP is used) will be 2, and so on. I suggest removing the "Rekeying an IKE SA resets the sequence numbers.", as the first sentence says it better (i.e. explains that the new IKE SA has message id 0, not the old one). Also the last sentense starting with "Thus, the first ..." should be moved before the text I quoted, so that the whole paragraph will be: The Message ID is a 32-bit quantity, which is zero for the IKE_SA_INIT messages (including retries of the message due to responses such as COOKIE and INVALID_KE_PAYLOAD), and incremented for each subsequent exchange. Thus, the first pair of IKE_AUTH messages will have ID of 1, the second (when EAP is used) will be 2, and so on. The Message ID is reset to zero in the new IKE SA after the IKE SA is rekeyed. Also later there is two definations for the "original initiator": Throughout this document, "initiator" refers to the party who initiated the exchange being described, and "original initiator" refers to the party who initiated the whole IKE SA. The "original initiator" always refers to the party who initiated the exchange which resulted in the current IKE SA. In other words, if the "original responder" starts rekeying the IKE SA, that party becomes the "original initiator" of the new IKE SA. I suggest changing that to: Throughout this document, "initiator" refers to the party who initiated the exchange being described. The "original initiator" always refers to the party who initiated the exchange which resulted in the current IKE SA. In other words, if the "original responder" starts rekeying the IKE SA, that party becomes the "original initiator" of the new IKE SA. ---------------------------------------------------------------------- Section 2.5 changes MUST to SHOULD and SHOULD to MUST NOT, and I think this should be noted in the section 1.7, i.e this text was in the original RFC4306: Although new payload types may be added in the future and may appear interleaved with the fields defined in this specification, implementations MUST send the payloads defined in this specification in the order shown in the figures in section 2 and implementations SHOULD reject as invalid a message with those payloads in any other order. and this is the text from the current IKEv2bis draft: Although new payload types may be added in the future and may appear interleaved with the fields defined in this specification, implementations SHOULD send the payloads defined in this specification in the order shown in the figures in Section 2; implementations MUST NOT reject as invalid a message with those payloads in any other order. The change from "MUST send payloads in order" to "SHOULD send", and "SHOULD reject" to "MUST NOT reject" is important enough to be noted in 1.7. ---------------------------------------------------------------------- In section 2.6 there is text explaining why Ni is added to the cookie, but that text is not really about the Ni, but SPIi: Also, incorporating Ni in the hash prevents an attacker from fetching one cookie from the other end, and then initiating many IKE_SA_INIT exchanges all with different initiator SPIs (and perhaps port numbers) so that the responder thinks that there are lots of machines behind one NAT box who are all trying to connect. I.e. adding Ni does not protect against that attack, but adding SPIi will prevent attacker from using one cookie for different initiator SPIs. Adding Ni will prevent attacker from sending multiple packets each having same SPIi and IPi (which would most likely being rejected as retransmissions). Better text would be: Also, incorporating SPIi in the hash prevents an attacker from fetching one cookie from the other end, and then initiating many IKE_SA_INIT exchanges all with different initiator SPIs (and perhaps port numbers) so that the responder thinks that there are lots of machines behind one NAT box who are all trying to connect. I already complained about this earlier (issue #19), but when it was put to the draft I think the text got changed from "incorporating SPIi" to "Incorporating Ni". Also the paragraph: In addition to cookies, there are several cases where the IKE_SA_INIT exchange does not result in the creation of an IKE SA (such as INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). In such a case, sending a zero value for the Responder's SPI is correct. If the responder sends a non-zero responder SPI, the initiator should not reject the response for only that reason. could perhaps clarify that it is talking about the FIRST IKE_SA_INIT exchange that does not result in the creation of an IKE SA, as most of those cases will result creation of IKE SA during next IKE_SA_INIT exchanges. On the other hand section 2.7 has about same text covering cases, so perhaps we should remove this text from section 2.6, and only keep the text at the 2.7: When the IKE_SA_INIT exchange does not result in the creation of an IKE SA due to INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN, or COOKIE (see Section 2.6), the responder's SPI will be zero. However, if the responder sends a non-zero responder SPI, the initiator should not reject the response for only that reason. (There are several cases where we have added similar text to multiple locations (which some are quite close to each other), because we have made those changes incrementally. Now when I am reading the whole text through those repeated texts just cause confusion and makes document longer). ---------------------------------------------------------------------- In section 2.6.1 it has text saying: For instance, if the responder includes the SAi1 and KEi payloads in cookie calculation, it will reject the request by sending a new cookie. which is misleading, as even if SAi1 is included in the cookie, that should not cause cookie to be rejected, as the retry behavior for INVALID_KE_PAYLOAD says that SAi1 is going to be same (section 2.7 says: "The initiator MUST again propose its full set of acceptable cryptographic suites ..."). IT would be better to remove "SAi1 and" from the sentence and only talk about KEi: For instance, if the responder includes the KEi payload in cookie calculation, it will reject the request by sending a new cookie. ---------------------------------------------------------------------- In section 2.8 the sentence: Note that, when rekeying, the new Child SA SHOULD NOT have different traffic selectors and algorithms than the old one. is in wrong place, it is after the paragraph talking about IKE SA rekey, it should be moved to the previous paragraph talking about Child SA rekeying. There is also orphan paragraph: The node that initiated the surviving rekeyed SA should delete the replaced SA after the new one is established. which should be moved to somewhere, I think the text before it got moved to the subsections of 2.8.... so this text should probably be moved to section 2.8.1 after the paragraph about checking cookies i.e. after: This form of rekeying may temporarily result in multiple similar SAs between the same pairs of nodes. When there are two SAs eligible to receive packets, a node MUST accept incoming packets through either SA. If redundant SAs are created though such a collision, the SA created with the lowest of the four nonces used in the two exchanges SHOULD be closed by the endpoint that created it. "Lowest" means an octet-by-octet, lexicographical comparison (instead of, for instance, comparing the nonces as large integers). In other words, start by comparing the first octet; if they're equal, move to the next octet, and so on. If you reach the end of one nonce, that nonce is the lower one. this paragraph. ---------------------------------------------------------------------- Also the text in the 2.8.1 is not consistent with the new error notifications, so the end of the section should be changed to use CHILD_SA_NOT_FOUND instead of NO_PROPOSAL_CHOSEN: To B, it looks like A is trying to rekey an SA that no longer exists; thus, B responds to the request with something non-fatal such as CHILD_SA_NOT_FOUND. <-- send resp1: N(CHILD_SA_NOT_FOUND) recv resp1 <-- When A receives this error, it already knows there was simultaneous rekeying, so it can ignore the error message. ---------------------------------------------------------------------- Section 2.8.2 seems to have quite fatal error: The new IKE SA containing the lowest nonce inherits the Child SAs. This is wrong. The one containing the lowest nonce, is the one that is going to be deleted, not the one that survives. This needs to be changed to: The new IKE SA containing the lowest nonce SHOULD be deleted by the node that created it and the other suriving new IKE SA MUST inherit all the Child SAs. Note, that I used words MUST here as this is one of the few cases where the correct behavior is really needed for interoperability reasons. It is not needed for simultaneous Child SA cases, as traffic continues to flow, even if they do not delete the loosing Child SA (we just have one extra Child SA). In this case it is important for the interoprability that both ends AGREE on which new IKE SA inherited the Child SAs from the old IKE SA. If they disagree then all IKE SAs are messed up and future rekeys, deletes etc will fail. Deleting the loosing IKE SA is not necessarely needed for interoperability so thats why that is SHOULD (just like it is in the child SA case), but moving Child SAs to correct IKE SA is MUST. ---------------------------------------------------------------------- In section 2.9 the paragraph It is possible for the responder's policy to contain multiple smaller ranges, all encompassed by the initiator's traffic selector, and with the responder's policy being that each of those ranges should be sent over a different SA. Continuing the example above, the responder might have a policy of being willing to tunnel those addresses to and from the initiator, but might require that each address pair be on a separately negotiated Child SA. If the initiator generated its request in response to an incoming packet from 192.0.1.43 to 192.0.2.123, there would be no way for the responder to determine which pair of addresses should be included in this tunnel, and it would have to make a guess or reject the request with a status of SINGLE_PAIR_REQUIRED. is bit confusing, as if the initiator generated its request in response to an incoming packet then it should include first traffic selectors based on the data from packet, and then responder should be able to pick up the correct pair of addresses. So I assume this paragraph talks about the case where a) initiator is not following the SHOULD saying it SHOULD include very specific traffic selector, b) the initiator didn't start creating the SA based on packet at all. So the paragraph should be changed to: It is possible for the responder's policy to contain multiple smaller ranges, all encompassed by the initiator's traffic selector, and with the responder's policy being that each of those ranges should be sent over a different SA. Continuing the example above, the responder might have a policy of being willing to tunnel those addresses to and from the initiator, but might require that each address pair be on a separately negotiated Child SA. If the initiator didn't generated its request based on the packet, but for example upon startup, there would not be the very specific first traffic selectors helping responder to select correct range and there would be no way for the responder to determine which pair of addresses should be included in this tunnel, and it would have to make a guess or reject the request with a status of SINGLE_PAIR_REQUIRED. In RFC4306 this paragraph was followed by the explanation of the very specific first traffic selectors, but now that text has moved earlier, thus causing this confusion. ---------------------------------------------------------------------- In section 2.18 we now DO require Diffie-Hellman to be done on the IKE SA rekey. This MUST level requirement is new to IKEv2bis, and needs to be added to the section 1.7. ---------------------------------------------------------------------- In section 2.19 there is FAILED_CP_REQUIRED text twice: The FAILED_CP_REQUIRED notification is sent by responder in the case where CP(CFG_REQUEST) was expected but not received, and so is a conflict with locally configured policy. There is no associated data. The responder MUST NOT send a CFG_REPLY without having first received a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS to perform an unnecessary configuration lookup if the IRAC cannot process the REPLY. In the case where the IRAS's configuration requires that CP be used for a given identity IDi, but IRAC has failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and terminate the IKE exchange with a FAILED_CP_REQUIRED error. The FAILED_CP_REQUIRED is not fatal to the IKE SA; it simply causes the Child SA creation fail. The initiator can fix this by later starting a new configuration payload request. I think the first paragraph should be removed and second one splitted and changed to:: The responder MUST NOT send a CFG_REPLY without having first received a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS to perform an unnecessary configuration lookup if the IRAC cannot process the REPLY. In the case where the IRAS's configuration requires that CP be used for a given identity IDi, but IRAC has failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and terminate the Child SA creation with a FAILED_CP_REQUIRED error. The FAILED_CP_REQUIRED is not fatal to the IKE SA; it simply causes the Child SA creation fail. The initiator can fix this by later starting a new configuration payload request. There is no associated data in the FAILED_CP_REQUIRED error. (Changed "terminate the IKE exchange" to "terminate the Child SA creation" and added text about the associated data). ---------------------------------------------------------------------- In section 2.21.2 we still have NOTE FOR WG DISCUSSION: NOTE FOR WG DISCUSSION: Having other payloads in the message is allowed but there are none suggested. One WG member mentioned the possibility of adding a DELETE payload when the error is sent in a separate INFORMATIONAL exchange. Do we want to allow such additional payloads that have operational semantics? ---------------------------------------------------------------------- In section 2.23 the word "float" needs to be replaced: An initiator can use port 4500, regardless whether or not there is NAT, even at the beginning of IKE. When either side is using port In section 2.23 the paragraph: o The original source and destination IP address required for the transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) are obtained from the Traffic Selectors associated with the exchange. In the case of NAT traversal, the Traffic Selectors MUST contain exactly one IP address, which is then used as the original IP address. Says that In case of NAT traversal there MUST only be exactly one IP address, but that actually only covers the transport mode NAT-Traversal (as said in the beginning of paragraph) so the text should be changed to: o The original source and destination IP address required for the transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) are obtained from the Traffic Selectors associated with the exchange. In the case of transport mode NAT traversal, the Traffic Selectors MUST contain exactly one IP address, which is then used as the original IP address. -- kivinen@iki.fi From rsjenwar@gmail.com Sat Jan 16 04:22:16 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20AEC3A685B for ; Sat, 16 Jan 2010 04:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVDlRdG0uHPW for ; Sat, 16 Jan 2010 04:22:12 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 49E173A67F0 for ; Sat, 16 Jan 2010 04:22:11 -0800 (PST) Received: by ewy6 with SMTP id 6so1796817ewy.29 for ; Sat, 16 Jan 2010 04:22:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=b5/YgGOCQYmJcQFaOUMdJAqzpuavRljdelyu9f1Gspw=; b=FqJDkTjgsuSe9qbq1R+4cpaTAJWA2JzThk4PzTrOuyLdjP36DI12TzIi2OtmiTnu9+ DyWBZ329ZSsOG/LIKLfHrUUQ6CINc1003wy3q5ChvVs5n4dxG9YN4AEx0m54Qcuu7Li1 KIsGToTAdGpsTTN6n6F0OpsoaZvyZjb+JAqUw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=S4opzlzpDmfJ0cH89csaoKfw/GlblQjd45nDlyz3rThpM1XkoQ89i04yCCrytY5Rl8 E0oUQaPNDk+rKoMOBmXNiI2bM/GN3+MiI/DVO6dquYbz+BkihzLcixftmznaDdN+yury L6bjkoMrwLokWQAJdPtOD2i4dP7JM4xzInYkY= MIME-Version: 1.0 Received: by 10.216.86.85 with SMTP id v63mr1280776wee.32.1263644524803; Sat, 16 Jan 2010 04:22:04 -0800 (PST) In-Reply-To: <19280.10197.22119.999077@fireball.kivinen.iki.fi> References: <19279.2179.103236.985956@fireball.kivinen.iki.fi> <19280.10197.22119.999077@fireball.kivinen.iki.fi> Date: Sat, 16 Jan 2010 17:52:04 +0530 Message-ID: <7ccecf671001160422v43244e0bt63e97b5f66482794@mail.gmail.com> From: Raj Singh To: Tero Kivinen Content-Type: multipart/alternative; boundary=0016e6d9a05705f63c047d472baa Cc: ipsec Subject: Re: [IPsec] Review of section 1 of the draft-ietf-ipsecme-ikev2bis-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2010 12:22:16 -0000 --0016e6d9a05705f63c047d472baa Content-Type: text/plain; charset=UTF-8 * * * * Section 1.2. The Initial Exchanges Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH exchanges (known in IKEv1 as Phase 1). These initial exchanges normally consist of four messages, though in some scenarios that number can grow. All communications using IKE consist of request/ response pairs. We'll describe the base exchange first, followed by variations. The first pair of messages (IKE_SA_INIT) negotiate cryptographic algorithms, exchange nonces, and do a Diffie-Hellman exchange [DH ]. It would be better to say Communication using *IKEv2* always begins with IKE_SA_INIT and IKE_AUTH exchanges (known in IKEv1 as Phase 1). These initial exchanges normally consist of four messages, though in some scenarios that number can grow. All communications using IKE consist of request/ response pairs. We'll describe the base exchange first, followed by variations. The first pair of messages (IKE_SA_INIT) negotiate cryptographic algorithms, exchange nonces, and do a Diffie-Hellman exchange [DH ]. Even though IKE has been used before this section where it is meant as IKEv2. So, also we can say like. "IKE and IKEv2 has been used interchangeably". But some place IKE is refer'd as generic protocol. So, mentioning IKE, IKEv1 and IKEv2 need to be done. Thanks & Regards, Raj On Fri, Jan 15, 2010 at 2:01 PM, Tero Kivinen wrote: > Scott C Moonen writes: > > > Section 1.4 says that > > > > > > INFORMATIONAL exchanges MUST ONLY occur > > > after the initial exchanges and are cryptographically protected with > > > the negotiated keys. > > > > > > This does not match the 1.5 which says we can send INFORMATIONAL > > > exchanges also outside the IKE SA. > > > > I think that section 1.5 is pretty careful to distinguish between > > informational messages (sent outside the IKE SA) and informational > > exchanges (which occur only within the context of an IKE SA). I'm > > inclined to keep the Section 1.4 text as it is. If you prefer, though, > > I'd be ok with clarifying Section 1.4 to say "INFORMATIONAL exchanges (to > > be distinguished from INFORMATIONAL messages sent outside the context of > > an IKE SA) . . ." > > That change looks even better than my proposed one... > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --0016e6d9a05705f63c047d472baa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 




Section 1.2.  The Initial Exchanges
   Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH
   exchanges (known in IKEv1 as Phase 1).  These initial exchanges
   normally consist of four messages, though in some scenarios that
   number can grow.  All communications using IKE consist of request/
   response pairs.  We'll describe the base exchange first, followed by
   variations.  The first pair of messages (IKE_SA_INIT) negotiate
   cryptographic algorithms, exchange nonces, and do a Diffie-Hellman
   exchange [DH]=
.

It would be better to say =


   Communication using *IKEv2* always begins with IKE_SA_INIT and IKE_AUTH
   exchanges (known in IKEv1 as Phase 1).  These initial exchanges
   normally consist of four messages, though in some scenarios that
   number can grow.  All communications using IKE consist of request/
   response pairs.  We'll describe the base exchange first, followed by
   variations.  The first pair of messages (IKE_SA_INIT) negotiate
   cryptographic algorithms, exchange nonces, and do a Diffie-Hellman
   exchange [DH]=
.

Even though IKE has been u=
sed before this section where it is meant as IKEv2. So, also we can say lik=
e. "IKE and IKEv2 has been used interchangeably".


But some place IKE is refer'd as=
 generic protocol. So, mentioning IKE, IKEv1 and IKEv2 need to be done.



Thanks & Regards,
Raj  

On Fri, Jan 1=
5, 2010 at 2:01 PM, Tero Kivinen <kivinen@iki.fi> wrote:


Scott C Moonen writes:

> > Section 1.4 says that

> >

> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0INFORMATIO=
NAL exchanges MUST ONLY occur

> > =C2=A0 =C2=A0after the initial exchanges and are cryptographicall=
y protected with

> > =C2=A0 =C2=A0the negotiated keys.

> >

> > This does not match the 1.5 which says we can send INFORMATIONAL<=
br>
> > exchanges also outside the IKE SA.

>

> I think that section 1.5 is pretty careful to distinguish between

> informational messages (sent outside the IKE SA) and informational

> exchanges (which occur only within the context of an IKE SA). =C2=A0I&=
#39;m

> inclined to keep the Section 1.4 text as it is. =C2=A0If you prefer, t=
hough,

> I'd be ok with clarifying Section 1.4 to say "INFORMATIONAL e=
xchanges (to

> be distinguished from INFORMATIONAL messages sent outside the context =
of

> an IKE SA) . . ."




That change looks even better than my proposed one...


--

kivinen@iki.fi

_______________________________________________

IPsec mailing list

IPsec@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/ipsec





--0016e6d9a05705f63c047d472baa--

From paul.hoffman@vpnc.org  Sun Jan 17 08:14:34 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B80E3A6950 for ; Sun, 17 Jan 2010 08:14:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.268
X-Spam-Level: 
X-Spam-Status: No, score=-5.268 tagged_above=-999 required=5 tests=[AWL=-0.711, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LK7vRB7VvuQd for ; Sun, 17 Jan 2010 08:14:33 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id DB0DC3A6958 for ; Sun, 17 Jan 2010 08:14:33 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0HG9nGm085482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 17 Jan 2010 09:09:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
Date: Sun, 17 Jan 2010 08:04:39 -0800
To: IPsecme WG 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: [IPsec] Issue #133: Adding more possible notifications when rekeying Child SAs
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Jan 2010 16:14:34 -0000

1.3.3 section should say that other notifications explained in the 1.3.1 can also be included in this exchange, i.e. if transport mode SA was rekeyed then this CREATE_CHILD_SA rekeying that SA needs to include USE_TRANSPORT_MODE notification. Some kind of reference back to the 1.3.1 should be enough.

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Sun Jan 17 08:14:34 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D29E83A6950 for ; Sun, 17 Jan 2010 08:14:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.054
X-Spam-Level: 
X-Spam-Status: No, score=-5.054 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 580YHzRkW1DH for ; Sun, 17 Jan 2010 08:14:34 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 1CD4D3A6959 for ; Sun, 17 Jan 2010 08:14:34 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0HG9nGo085482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 17 Jan 2010 09:09:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
Date: Sun, 17 Jan 2010 08:05:33 -0800
To: IPsecme WG 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: [IPsec] Issue #134: SAi1 in cookies
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Jan 2010 16:14:34 -0000

In section 2.6.1 it has text saying:

For instance, if
the responder includes the SAi1 and KEi payloads in cookie calculation, it will reject the request by sending a new cookie.

which is misleading, as even if SAi1 is included in the cookie, that should not cause cookie to be rejected, as the retry behavior for INVALID_KE_PAYLOAD says that SAi1 is going to be same (section 2.7 says: "The initiator MUST again propose its full set of acceptable cryptographic suites ..."). IT would be better to remove "SAi1 and" from the sentence and only talk about KEi:

For instance, if
the responder includes the KEi payload in cookie calculation, it will reject the request by sending a new cookie.

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Sun Jan 17 08:14:35 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3127A3A696A for ; Sun, 17 Jan 2010 08:14:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.95
X-Spam-Level: 
X-Spam-Status: No, score=-5.95 tagged_above=-999 required=5 tests=[AWL=0.096,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoRfMxPlxoFo for ; Sun, 17 Jan 2010 08:14:34 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 5B9963A6874 for ; Sun, 17 Jan 2010 08:14:34 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0HG9nGq085482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 17 Jan 2010 09:09:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
Date: Sun, 17 Jan 2010 08:06:42 -0800
To: IPsecme WG 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: [IPsec] Issue #135: Which IKE SA inherits a Child SA?
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Jan 2010 16:14:35 -0000

Section 2.8.2 seems to have quite fatal error:

The new IKE SA containing the lowest nonce inherits the Child
SAs.

This is wrong. The one containing the lowest nonce, is the one that is going to be deleted, not the one that survives. This needs to be changed to:

The new IKE SA containing the lowest nonce SHOULD be deleted by the node that created it and the other suriving new IKE SA MUST inherit all the Child SAs.

Note, that I used words MUST here as this is one of the few cases where the correct behavior is really needed for interoperability reasons. It is not needed for simultaneous Child SA cases, as traffic continues to flow, even if they do not delete the loosing Child SA (we just have one extra Child SA). In this case it is important for the interoprability that both ends AGREE on which new IKE SA inherited the Child SAs from the old IKE SA. If they disagree then all IKE SAs are messed up and future rekeys, deletes etc will fail. Deleting the loosing IKE SA is not necessarely needed for interoperability so thats why that is SHOULD (just like it is in the child SA case), but moving Child SAs to correct IKE SA is MUST.

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Sun Jan 17 08:14:35 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 968CA3A6975 for ; Sun, 17 Jan 2010 08:14:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.954
X-Spam-Level: 
X-Spam-Status: No, score=-5.954 tagged_above=-999 required=5 tests=[AWL=0.092,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5eDsjqwFJcm for ; Sun, 17 Jan 2010 08:14:34 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 9EA753A6958 for ; Sun, 17 Jan 2010 08:14:34 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0HG9nGs085482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 17 Jan 2010 09:09:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
Date: Sun, 17 Jan 2010 08:08:00 -0800
To: IPsecme WG 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: [IPsec] Issue #136: NAT traversal and transport mode
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Jan 2010 16:14:35 -0000

In section 2.23 the word "float" needs to be replaced:

   An initiator can use port 4500, regardless whether or not there
   is NAT, even at the beginning of IKE.  When either side is using port

In section 2.23 the paragraph:

   o  The original source and destination IP address required for the
      transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS])
      are obtained from the Traffic Selectors associated with the
      exchange.  In the case of NAT traversal, the Traffic Selectors
      MUST contain exactly one IP address, which is then used as the
      original IP address.

Says that In case of NAT traversal there MUST only be exactly one IP
address, but that actually only covers the transport mode NAT-Traversal
(as said in the beginning of paragraph) so the text should be changed to:
      
   o  The original source and destination IP address required for the
      transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS])
      are obtained from the Traffic Selectors associated with the
      exchange.  In the case of transport mode NAT traversal, the Traffic
      Selectors MUST contain exactly one IP address, which is then used
      as the original IP address.

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Sun Jan 17 08:14:35 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9EC33A6978 for ; Sun, 17 Jan 2010 08:14:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.957
X-Spam-Level: 
X-Spam-Status: No, score=-5.957 tagged_above=-999 required=5 tests=[AWL=0.089,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C35OudzrgxKD for ; Sun, 17 Jan 2010 08:14:34 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id D63313A6959 for ; Sun, 17 Jan 2010 08:14:34 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0HG9nGk085482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 17 Jan 2010 09:09:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
Date: Sun, 17 Jan 2010 08:09:46 -0800
To: IPsecme WG 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: [IPsec] Issue #132: Should NO_ADDITIONAL_SAS cover rekeying IKE SAs?
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Jan 2010 16:14:35 -0000

In section 1.3 at the end there is text talking about the NO_ADDITIONAL_SAS. The current text is in the generic CREATE_CHILD_SA section thus it covers all 3 use cases for CREATE_CHILD_SA (creating new IPsec SAs, rekeying old IPsec SAs and rekeying IKE SA). The text there is written to cover only new IPsec SAs, but I think it should also cover rekeying IKE SA cases (section 4 conformance requirements makes it quite clear you can return NO_ADDITIONAL_SAS to any CREATE_CHILD_SA exchange including IKE SA rekey).

This means the text should be changed from

The responder sends a NO_ADDITIONAL_SAS notification to indicate that a CREATE_CHILD_SA request is unacceptable because the responder is unwilling to accept any more Child SAs on this IKE SA. Some minimal implementations may only accept a single Child SA setup in the context of an initial IKE exchange and reject any subsequent attempts to add more.

To

The responder sends a NO_ADDITIONAL_SAS notification to indicate that a CREATE_CHILD_SA request is unacceptable because the responder is unwilling to accept any more Child SAs on this IKE SA. This notify can also be used to reject IKE SA rekey. Some minimal implementations may only accept a single Child SA setup in the context of an initial IKE exchange and reject any subsequent attempts to add more.

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Sun Jan 17 08:14:36 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83AD43A69C6 for ; Sun, 17 Jan 2010 08:14:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.96
X-Spam-Level: 
X-Spam-Status: No, score=-5.96 tagged_above=-999 required=5 tests=[AWL=0.086,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHrZRWn286MD for ; Sun, 17 Jan 2010 08:14:35 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 299CC3A6950 for ; Sun, 17 Jan 2010 08:14:35 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0HG9nGi085482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Jan 2010 09:09:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
X-Priority: 4 (Low)
Date: Sun, 17 Jan 2010 08:02:10 -0800
To: IPsecme WG , Tero Kivinen 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [IPsec] Reviews of section 1 and 2 of the draft-ietf-ipsecme-ikev2
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Jan 2010 16:14:36 -0000

Tero:

Thank you for your careful (if not a bit late...) reviews. The author team will incorporate the non-controversial editorial changes into the version going to IETF Last Call. I have also already opened issues in the issue tracker for the ones that look like technical changes or clarifications that might be controversial; I'll start threads for those soon.

There are a few remaining changes you asked for that I don't think should be made; I have listed them here. If anyone (including you, of course) really object to these rejections, please do open individual issues in the tracker instead of just replying to this message. Really: trying to follow ideas in a single thread on this message will be too hard.

----------------------------------------------------------------------

Section 1.3.1 now talks about the USE_TRANSPORT_MODE,
ESP_TFC_PADDING_NOT_SUPPORTED and NON_FIRST_FRAMENTS_ALSO notifications,
and says they can be included, but the packet figure does not include
them. Adding them to the figure would be easy, but the problem is that we
currently say that you should follow the order of payloads from the
figures (altough we do refer to section 2 not section 1, but this is one
of the open issues).

So depending what we decided on the payload order and figures, it might
be better to add one extra ", [N]" to the figure before SA payload.

[[ Response: It is not an open issue. The spec says "implementations MUST NOT reject as invalid a message with those payloads in any other order". Thus, putting the "[N]" in the figure is likely to be more confusing than helpful because [N] can appear in almost *any* of the figures. ]]

----------------------------------------------------------------------

Also the section 1.3.1 has text which perhaps should be removed:

   Failure of an attempt to create a Child SA SHOULD NOT tear down the
   IKE SA: there is no reason to lose the work done to set up the IKE
   SA.  When an IKE SA is not created, the error message return SHOULD
   NOT be encrypted because the other party will not be able to
   authenticate that message.  See Section 2.21 for a list of error
   messages that might occur if creating a Child SA fails.

This section 1.3.1 is talking about the CREATE_CHILD_SA not initial
IKE_AUTH, thus this section is not needed here. The section 1.2 already
has text about the Child SA failing during the initial exchange, so this
how paragaraph needs to be removed.

[[ Response: This text was specifically added by the WG to deal with creating SAs, not with IKE_AUTH. This was Issue #9, which you initiated. ]]

----------------------------------------------------------------------

Section 1.5 needs some reordering and the text in section 1.5 vand 2.21.4
needs to be combined, now we have about the same text in two places.

The first paragraph of the 1.5 talks about the INVALID_IKE_SPI even
though it does not say it explictly, the second paragraph talks about
INVALID_SPI and then in third paragraph it says that "there are two cases
when one-way message is sent: INVALID_IKE_SPI and INVALID_SPI", just like
this would be new thing, but the previous paragraphs have already talked
about this. This is confusing, so I think this section requires bit of
reordering and rewording. Also it might be useful to actually move all
this text to section 2.21.4 and remove this whole section (remember
to update references).

Especially the fact that exchange type is copied from the request in
the INVALID_IKE_SPI case is missing from the 2.21.4 and should be
added there and also the last paragraph about INVALID_SPI text in the
1.5 is something that is not that clearly explained in the 2.21.4 so
that also needs to be kept (and/or moved).

[[ Response: While I agree that there is a lot of duplication in the 1.5 and 2.21.4, I am quite worried about removing anything at this late date. If you have a specific reordering you want, please post it; otherwise, I think we should leave this duplication here. ]]

----------------------------------------------------------------------

XX In section 2.8 the sentence:

	   Note that, when
   rekeying, the new Child SA SHOULD NOT have different traffic
   selectors and algorithms than the old one.

is in wrong place, it is after the paragraph talking about IKE SA rekey,
it should be moved to the previous paragraph talking about Child SA
rekeying.

[[ Response: It looks like the sentence is, in fact, in the right place. The whole paragraph reads: "To rekey a Child SA within an existing IKE SA, create a new, equivalent SA (see Section 2.17 below), and when the new one is established, delete the old one.  Note that, when rekeying, the new Child SA SHOULD NOT have different traffic selectors and algorithms than the old one." That is, indeed, talking about rekeying a Child SA. ]]

----------------------------------------------------------------------

In section 2.19 there is FAILED_CP_REQUIRED text twice:

   The FAILED_CP_REQUIRED notification is sent by responder in the case
   where CP(CFG_REQUEST) was expected but not received, and so is a
   conflict with locally configured policy.  There is no associated
   data.

   The responder MUST NOT send a CFG_REPLY without having first received
   a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS
   to perform an unnecessary configuration lookup if the IRAC cannot
   process the REPLY.  In the case where the IRAS's configuration
   requires that CP be used for a given identity IDi, but IRAC has
   failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and
   terminate the IKE exchange with a FAILED_CP_REQUIRED error.  The
   FAILED_CP_REQUIRED is not fatal to the IKE SA; it simply causes the
   Child SA creation fail.  The initiator can fix this by later starting
   a new configuration payload request.

I think the first paragraph should be removed and second one splitted and
changed to::

   The responder MUST NOT send a CFG_REPLY without having first received
   a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS
   to perform an unnecessary configuration lookup if the IRAC cannot
   process the REPLY.

   In the case where the IRAS's configuration requires that CP be used
   for a given identity IDi, but IRAC has failed to send a
   CP(CFG_REQUEST), IRAS MUST fail the request, and terminate the Child
   SA creation with a FAILED_CP_REQUIRED error. The FAILED_CP_REQUIRED is
   not fatal to the IKE SA; it simply causes the Child SA creation fail.
   The initiator can fix this by later starting a new configuration
   payload request. There is no associated data in the FAILED_CP_REQUIRED
   error.

(Changed "terminate the IKE exchange" to "terminate the Child SA
creation" and added text about the associated data).

[[ Response: The two uses of FAILED_CP_REQUIRED are different and therefore should both be left in. ]]

----------------------------------------------------------------------

Again: thanks for the detailed review! It will hopefully cause others in the WG to do such a review in IETF Last Call.

--Paul Hoffman, Director
--VPN Consortium

From tamura.toshihiko@lab.ntt.co.jp  Mon Jan 18 02:48:32 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE90C3A6920 for ; Mon, 18 Jan 2010 02:48:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.769
X-Spam-Level: *
X-Spam-Status: No, score=1.769 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNWOfOR461yW for ; Mon, 18 Jan 2010 02:48:32 -0800 (PST)
Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by core3.amsl.com (Postfix) with ESMTP id DF5E53A686C for ; Mon, 18 Jan 2010 02:48:31 -0800 (PST)
Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama50.ecl.ntt.co.jp (8.14.3/8.14.3) with ESMTP id o0IAmRVB011833 for ; Mon, 18 Jan 2010 19:48:27 +0900 (JST)
Received: from mfs5.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 8F10C6CDA for ; Mon, 18 Jan 2010 19:48:27 +0900 (JST)
Received: from iml.m.ecl.ntt.co.jp (iml0.m.ecl.ntt.co.jp [129.60.5.150]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 6E4546CD7 for ; Mon, 18 Jan 2010 19:48:27 +0900 (JST)
Received: from [127.0.0.1] (tamura-dell.nslab.ecl.ntt.co.jp [129.60.11.10]) by iml.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id o0IAmR3f017663 for ; Mon, 18 Jan 2010 19:48:27 +0900 (JST)
Date: Mon, 18 Jan 2010 19:48:27 +0900
From: Toshihiko Tamura 
To: ipsec@ietf.org
Message-Id: <20100118192835.0621.DECD93FF@lab.ntt.co.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.48.02 [ja]
Subject: [IPsec] question about 2.8.1 simultaneous child SA rekeying
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2010 10:48:33 -0000

Hi, I want to ask about simultaneous Child SA rekeying 
at section 2.8.1 in IKEv2bis.

I'm sure it is convenient to support this function,
but why is current IKEv2bis draft saying this fucntion
as SHOULD?
-------------------------------
If redundant SAs are created though such a collision, the SA
created with the lowest of the four nonces used in the two exchanges
SHOULD be closed by the endpoint that created it.
-------------------------------
Even if this function is not supported and two new pairs of 
Child SAs are created, there is no problem.
Should this be regraded as optional?
I think " ... the two exchanges MAY be closed by..." is better.

Are there any discussions about it in the past?

---------
Regards, 
Toshihiko Tamura

From ynir@checkpoint.com  Mon Jan 18 03:00:31 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE2173A6920 for ; Mon, 18 Jan 2010 03:00:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnKtpBcaRD0f for ; Mon, 18 Jan 2010 03:00:31 -0800 (PST)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id CA2AA3A689C for ; Mon, 18 Jan 2010 03:00:30 -0800 (PST)
X-CheckPoint: {4B543CFB-10004-14201DC2-FFFF}
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id EE6BC29C004; Mon, 18 Jan 2010 13:00:25 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id D00BC29C002; Mon, 18 Jan 2010 13:00:25 +0200 (IST)
X-CheckPoint: {4B543CFB-10000-14201DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0IB0PT7019201; Mon, 18 Jan 2010 13:00:25 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 18 Jan 2010 13:00:39 +0200
From: Yoav Nir 
To: Toshihiko Tamura 
Date: Mon, 18 Jan 2010 13:00:18 +0200
Thread-Topic: [IPsec] question about 2.8.1 simultaneous child SA rekeying
Thread-Index: AcqYLXgD7LpW22THSfeuZ8upC3rI7Q==
Message-ID: <752778CF-0899-43E9-845B-55E014D2A863@checkpoint.com>
References: <20100118192835.0621.DECD93FF@lab.ntt.co.jp>
In-Reply-To: <20100118192835.0621.DECD93FF@lab.ntt.co.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ipsec@ietf.org" 
Subject: Re: [IPsec] question about 2.8.1 simultaneous child SA rekeying
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2010 11:00:31 -0000

Hi

On Jan 18, 2010, at 12:48 PM, Toshihiko Tamura wrote:

> Hi, I want to ask about simultaneous Child SA rekeying=20
> at section 2.8.1 in IKEv2bis.
>=20
> I'm sure it is convenient to support this function,
> but why is current IKEv2bis draft saying this fucntion
> as SHOULD?
> -------------------------------
> If redundant SAs are created though such a collision, the SA
> created with the lowest of the four nonces used in the two exchanges
> SHOULD be closed by the endpoint that created it.
> -------------------------------
> Even if this function is not supported and two new pairs of=20
> Child SAs are created, there is no problem.
> Should this be regraded as optional?
> I think " ... the two exchanges MAY be closed by..." is better.
>=20
> Are there any discussions about it in the past?

SHOULD means that is is acceptable for an implementation to not do this, pr=
ovided there is a good enough reason. that it makes your SA database manage=
ment more complicated is a perfectly acceptable reason. In fact, the draft =
is full of comments about minimal implementations, and how you need to make=
 allowances for them.

In this case, I think SHOULD is preferable to MAY because it is definitely =
better to delete the redundant SA rather than keep it.

Yoav=

From Pasi.Eronen@nokia.com  Mon Jan 18 07:23:27 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9CE43A68B3 for ; Mon, 18 Jan 2010 07:23:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.652
X-Spam-Level: 
X-Spam-Status: No, score=-6.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjBmi2PCN859 for ; Mon, 18 Jan 2010 07:23:26 -0800 (PST)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id BCD283A689D for ; Mon, 18 Jan 2010 07:23:26 -0800 (PST)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0IFMpSU027230; Mon, 18 Jan 2010 09:23:22 -0600
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 18 Jan 2010 17:23:05 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 18 Jan 2010 17:23:01 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Mon, 18 Jan 2010 16:23:00 +0100
From: 
To: , 
Date: Mon, 18 Jan 2010 16:22:59 +0100
Thread-Topic: [IPsec] Issue #135: Which IKE SA inherits a Child SA?
Thread-Index: AcqXkEAzrsnG3gHpS0mloavRmFy1RgAwdAow
Message-ID: <808FD6E27AD4884E94820BC333B2DB775841046AFB@NOK-EUMSG-01.mgdnok.nokia.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 18 Jan 2010 15:23:01.0112 (UTC) FILETIME=[1F2ACF80:01CA9852]
X-Nokia-AV: Clean
Subject: Re: [IPsec] Issue #135: Which IKE SA inherits a Child SA?
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2010 15:23:27 -0000

I agree. This was also noted in
http://www.rfc-editor.org/errata_search.php?rfc=3D4718

Best regards,
Pasi
(not wearing any hats)

> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
> Of ext Paul Hoffman
> Sent: 17 January, 2010 18:07
> To: IPsecme WG
> Subject: [IPsec] Issue #135: Which IKE SA inherits a Child SA?
>=20
> Section 2.8.2 seems to have quite fatal error:
>=20
> The new IKE SA containing the lowest nonce inherits the Child
> SAs.
>=20
> This is wrong. The one containing the lowest nonce, is the one that is
> going to be deleted, not the one that survives. This needs to be
> changed to:
>=20
> The new IKE SA containing the lowest nonce SHOULD be deleted by the
> node that created it and the other suriving new IKE SA MUST inherit all
> the Child SAs.
>=20
> Note, that I used words MUST here as this is one of the few cases where
> the correct behavior is really needed for interoperability reasons. It
> is not needed for simultaneous Child SA cases, as traffic continues to
> flow, even if they do not delete the loosing Child SA (we just have one
> extra Child SA). In this case it is important for the interoprability
> that both ends AGREE on which new IKE SA inherited the Child SAs from
> the old IKE SA. If they disagree then all IKE SAs are messed up and
> future rekeys, deletes etc will fail. Deleting the loosing IKE SA is
> not necessarely needed for interoperability so thats why that is SHOULD
> (just like it is in the child SA case), but moving Child SAs to correct
> IKE SA is MUST.
>=20
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

From kivinen@iki.fi  Mon Jan 18 08:02:33 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6CA83A6943 for ; Mon, 18 Jan 2010 08:02:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.491
X-Spam-Level: 
X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5qX4ApeqfCW for ; Mon, 18 Jan 2010 08:02:32 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 808E33A68F3 for ; Mon, 18 Jan 2010 08:02:31 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0IG2Nc3019436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 18 Jan 2010 18:02:23 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0IG2LZd027183; Mon, 18 Jan 2010 18:02:21 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19284.34317.682796.84636@fireball.kivinen.iki.fi>
Date: Mon, 18 Jan 2010 18:02:21 +0200
From: Tero Kivinen 
To: ipsec@ietf.org
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 4 min
X-Total-Time: 3 min
Subject: [IPsec] Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1 forward)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2010 16:02:33 -0000

Here is the final part of my comments. 

----------------------------------------------------------------------
In section 2.23.1 there is extra "the":

				 It can have multiple traffic
   selectors if it has, for example, multiple port ranges that it wants
   to negotiate, but all TSi entries must use IP1-IP1 range as the IP
   addresses, and all TSr entries must have the IPN2-IPN2 range as IP
   the addresses.  The first traffic selector of TSi and TSr SHOULD have
   ^^^
     \-- There

Also there is extra "as" in this sentence:

   In this case, the server should first check that as initiator
						    ^^
   requested transport mode and do address substitution on the traffic
   selectors.  

There is also typo:

      (thta is, it replaces IPN2 in TSr with IP2).
       ^^^^

Also the bullet

   - Store the original traffic selector IP addresses as real source
     and destination address in case we need to undo address
     substitution.

needs to be changed to

   - Store the original traffic selector IP addresses as real source
     and destination address and also in case we need them to undo
     address substitution.

The whole section 2.23.1 would require someone to do some langauge
cleanup for it.

----------------------------------------------------------------------

In section 2.25 the CHILD_SA_NOT_FOUND text could be bit expanded to
explain bit more, i.e. change:

   A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives
   a request to rekey a Child SA that does not exist.  A peer that
   receives a CHILD_SA_NOT_FOUND notification SHOULD silently delete the
   Child SA and send a request to create a new Child SA from scratch.

to

   A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives
   a request to rekey a Child SA that does not exist A peer that receives
   a CHILD_SA_NOT_FOUND notification SHOULD silently delete the Child SA
   (if it still exists, as most likely delete notification sent by the
   other hand has already deleted it) and send a request to create a new
   Child SA from scratch if such Child SA does not yet exists.

----------------------------------------------------------------------

In section 3.3.6 there is few odd sentences at the end of second
paragraph:

					An exception is
   the case where one of the proposals offered is for the Diffie-Hellman
   group of NONE.  In this case, the responder MUST ignore the
   initiator's KE payload and omit the KE payload from the response.

Before this it talked about the extensibility and so, and I do not
understand how the Diffie-Hellman negotiation is an exception of that
case.

The next paragraph talks about the Diffie-Hellman negotiation, and I
think this text belongs to there, not in this paragraph, altough the text
needs to be modified when moved to there to match the context.

----------------------------------------------------------------------

In section 3.6 we have text which says:

	   Certificate payloads SHOULD be included in an exchange if
   certificates are available to the sender unless the peer has
   indicated an ability to retrieve this information from elsewhere
   using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload.  

which is bit misleading, as even if HTTP_CERT_LOOKUP_SUPPORTED notify
payload is sent that does not mean peer should leave out all Certificate
payloads, it just means it should use Hash and URL formats instead of
sending full certificates.

Perhaps it should be changed to:

	   Certificate payloads SHOULD be included in an exchange if
   certificates are available to the sender. The Hash and URL formats of
   the Certificate payloads should be used in case the peer has indicated
   an ability to retrieve this information from elsewhere using an
   HTTP_CERT_LOOKUP_SUPPORTED Notify payload.

----------------------------------------------------------------------

Section "3.10.1.  Notify Message Types" should include:


   TEMPORARY_FAILURE		 {TBA1}
       See section 2.25.

   CHILD_SA_NOT_FOUND		 {TBA2}
       See section 2.25.

It is funny that section "E.13. Changes from
draft-ietf-ipsecme-ikev2bis-05 to draft-ietf-ipsecme-ikev2bis-06" claims
that text was added to there, but it isn't there.

Also in the beginning of error code list it would be better to put
pointer to the section "2.21 Error Handling" is it covers text for more
than one of those errors notifications. Also following references could
also be added:

   INVALID_KE_PAYLOAD                       17
       See Section 1.3.

also section 2.7

   AUTHENTICATION_FAILED                    24
       Sent in the response to an IKE_AUTH message when for some reason
       the authentication failed. There is no associated data.

Section 2.21.2.

----------------------------------------------------------------------

In section "3.15.1.  Configuration Attributes" the text before the table
saying:

      The values in the following table are only current as of the
      publication date of RFC 4306.  Other values may have been added
      since then or will be added after the publication of this
      document.  Readers should refer to [IKEV2IANA] for the latest
      values.

Is not true, as the RFC4306 included INTERNAL_ADDRESS_EXPIRY and
INTERNAL_IP6_NBNS which were removed from the table. Perhaps text should
be changed to:


      The values in the following table are only current as of the
      publication date of RFC 4306 (except INTERNAL_ADDRESS_EXPIRY and
      INTERNAL_IP6_NBNS which were removed by this document). Other
      values may have been added since then or will be added after the
      publication of this document. Readers should refer to [IKEV2IANA]
      for the latest values.

The INTERNAL_ADDRESS_EXPIRY removal was listed in the section 1.7 but
INTERNAL_IP6_NBNS wasn't. I am not sure if that is big enough sure to
require note in the section 1.7. 

----------------------------------------------------------------------

In section 6. IANA Considerations it is missing the removal of
INTERNAL_IP6_NBNS and INTERNAL_ADDRESS_EXPIRY attribute types from the
IKEv2 Configuration Payload Attribute Types table.

----------------------------------------------------------------------

In section C.5 it shows KEi and KEr as optional payloads, but they are
not optional for IKE SA rekey, i.e. the exchange should be:

C.5.  CREATE_CHILD_SA Exchange for Rekeying the IKE SA

   request             --> SA, Ni, KEi
                           [V+][N+]

   response            <-- SA, Nr, KEr
                           [V+][N+]

----------------------------------------------------------------------

In section 2.16 we say:

						For
   this reason, these protocols are typically used to authenticate the
   initiator to the responder and MUST be used in conjunction with a
   public key signature based authentication of the responder to the
   initiator.

but in the section 5 we say:

   An implementation using EAP MUST also use strong authentication of
   the server to the client before the EAP authentication begins, even
   if the EAP method offers mutual authentication.

In the appendix E we can se that we first changed both section 2.16 and
section 5 to say "strong authentication", but then we changed the section
2.16 back from "strong authentication" to "public key signature based
authentication", but we didn't change the section 5 back to its original
way.

Should we make them consistent and convert the section 5 back to its
original form? 

----------------------------------------------------------------------
Following things might or might not need to be added to section 1.7
(taken from appendix E):

   In the description of ID_FQDN in Section 3.5, added "All characters
   in the ID_FQDN are ASCII; this follows that for an "internationalized
   domain name" as defined in [IDNA]."
...
   In Section 3.3.2, changed the following algorithms to (UNSPECIFIED)
   because the RFCs listed didn't really specify how to implement them
   in an interoperable fashion:

   Encryption Algorithms
   ENCR_DES_IV64        1           (RFC1827)
   ENCR_3IDEA           8           (RFC2451)
   ENCR_DES_IV32        9
   Pseudo-random Functions
   PRF_HMAC_TIGER              3         (RFC2104)
   Integrity Algorithms
   AUTH_DES_MAC         3
   AUTH_KPDK_MD5        4        (RFC1826)
...
   Added the reference to RFC 2104 back for PRF_HMAC_TIGER in 3.3.2.
   [Issue #33]
...
   Changed the "Initialization Vector" bullet in Section 3.14 to specify
   better what is needed for the IV.  Upgraded the SHOULDs to MUSTs.
   Also added the reference for [MODES].
...
   In section 2.6, upgraded "needs to choose them so as to be unique
   identifiers of an IKE_SA" to a MUST.
...
   Added a reference to email address internationalization to 3.5,
   making the address binary (not ASCII).
...
   In 3.14, updated the discussion of initialization modes to reflect
   that it is only about CBC, and that other specs have to specify their
   own IVs.
...
   In section 1.3.2, changed "The KEi payload SHOULD be included" to be
   "The KEi payload MUST be included".  This also lead to changes in
   section 2.18.  The square brackets around "g^ir (new)" in the
   SKEYSEED calculation are eliminated, and the requirement language in
   the paragraph starting "The main rekeying" is changed from SHOULD to
   MUST.  [Issue #50]
...
   In 2.1, at the end of the paragraph about retransmission timers,
   added "In order to allow saving memory, responders are allowed to
   forget response after a timeout of several minutes.  If the responder
   receives a retransmitted request for which it has already forgotten
   the response, it MUST ignore the request (and not, for example,
   attempt constructing a new response)."  [Issue #14]
...
   Added the following to 2.23: An initiator can float to port 4500,
   regardless whether or not there is NAT, even at the beginning of IKE.
   When either side is using port 4500, sending with UDP encapsulation
   is not required, but understanding received packets with UDP
   encapsulation is required.  UDP encapsulation MUST NOT be done on
   port 500.  If NAT-T is supported (that is, if NAT_DETECTION_*_IP
   payloads were exchanged during IKE_SA_INIT), all devices MUST be able
   to receive and process both UDP encapsulated and non-UDP encapsulated
   packets at any time.  Either side can decide whether or not to use
   UDP encapsulation irrespective of the choice made by the other side.
   However, if a NAT is detected, both devices MUST send UDP
   encapsulated packets.  [Issue #40]
...
   In 2.5, changed "implementations MUST send the payloads defined in
   this specification in the order shown in the figures in Section 2;
   implementations are explicitly allowed to reject as invalid a message
   with those payloads in any other order" to "implementations SHOULD
   send the payloads defined in this specification in the order shown in
   the figures in Section 2; implementations MUST NOT reject as invalid
   a message with those payloads in any other order".  [Issue #16]
   [Issue #45]
...
   Removed INTERNAL_IP6_NBNS from 3.15.1.  [Issue #44]
...
   In 2.8, changed "Note that, when rekeying, the new Child SA MAY have
   different traffic selectors and algorithms than the old one." to
   "Note that, when rekeying, the new Child SA SHOULD NOT have different
   traffic selectors and algorithms than the old one.".  [Issue #12]
...
   Added 2.23.1, which covers how to handle NAT traversal when transport
   mode is requested.  [Issue #28]
...
   Added 2.25 and its subsections.  [Issue #22]
...
   Added to the end of 3.6: "Implementations MUST support the HTTP
   method for hash-and-URL lookup.  The behavior of other URL methods is
   not currently specified, and such methods SHOULD NOT be used in the
   absence of a document specifying them."  [Issue #117]
...
   In 3.7, removed "10" from the list of acceptable types for the
   "Certification Authority" field.  [Issue #120]
...
   In 3.10.1, added

   TEMPORARY_FAILURE
       See section 2.25.

   CHILD_SA_NOT_FOUND
       See section 2.25.
...

I tried to pick ones which might affect existing implementations (i.e.
where we changed something to MUST when it was SHOULD etc, or where we
expanded or added specifications to cases which were not specified
properly previously).

Some of those are already cases where there might be some text in 1.7 or
which have already been pointed out, but I added those still to this more
complete list just to make sure.

BTW what is going to be the relationship between section 1.7 and
Appendix D?
-- 
kivinen@iki.fi

From Pasi.Eronen@nokia.com  Mon Jan 18 08:21:23 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 775E23A68DE for ; Mon, 18 Jan 2010 08:21:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.649
X-Spam-Level: 
X-Spam-Status: No, score=-6.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMTMFDF7K6bq for ; Mon, 18 Jan 2010 08:21:22 -0800 (PST)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 565E63A680A for ; Mon, 18 Jan 2010 08:21:22 -0800 (PST)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0IGL6gV012599 for ; Mon, 18 Jan 2010 10:21:18 -0600
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 18 Jan 2010 18:21:07 +0200
Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 18 Jan 2010 18:21:03 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 18 Jan 2010 18:20:55 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Mon, 18 Jan 2010 17:20:54 +0100
From: 
To: 
Date: Mon, 18 Jan 2010 17:20:52 +0100
Thread-Topic: IKEv2bis editorial nits (Sections 1-2)
Thread-Index: AcqYWjRaPf9wFAzyR42JmfrxnZd7aw==
Message-ID: <808FD6E27AD4884E94820BC333B2DB7758410A9509@NOK-EUMSG-01.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 18 Jan 2010 16:20:55.0055 (UTC) FILETIME=[35CC71F0:01CA985A]
X-Nokia-AV: Clean
Subject: [IPsec] IKEv2bis editorial nits (Sections 1-2)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2010 16:21:23 -0000

- Abstract: "It replaces..." Here "it" seems to refer to "IKE", which
isn't correct; it should refer to "This document". This could be fixed
by e.g. switching the first and second sentence, or changing "it" to
"This document".

- Section 1.2: s/IKE_INFORMATIONAL/INFORMATIONAL/

- Section 1.4, 3rd paragraph: suggest changing "message with no
payloads" and "also contain no payloads" to "empty message" (Section
1.2 says empty message means encrypted payload only, but "no payloads"
sounds a bit different)

- Section 2.21.2: There's a "NOTE FOR WG DISCUSSION" (just FYI so it's
not forgotten there)

- Section 2.23: "port on which this packet was sent": would "port from
which this packet was sent" be clearer?

- Section 2.23, 5th bullet ("The recipient of either..."): the "that
system SHOULD start sending keepalive packets as defined in
[UDPENCAPS]" is a bit redundant; it's repeated two bullets later.

- Section 2.25.1, first paragraph: "..based on the nonces":=20
suggest adding pointer "(see Section 2.8.1)". =20

- Section 2.25.1, 2nd paragraph, 1st sentence: suggest=20
adding pointer "(see Section 1.4.1)"

- Section 2.25.2, "...based on the nonces": suggest adding=20
pointer "(see Section 2.8.2)".

Best regards,
Pasi

From Pasi.Eronen@nokia.com  Mon Jan 18 08:47:50 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1B3C3A67A8 for ; Mon, 18 Jan 2010 08:47:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.647
X-Spam-Level: 
X-Spam-Status: No, score=-6.647 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqsN19kz3+jO for ; Mon, 18 Jan 2010 08:47:49 -0800 (PST)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id A4A593A63EB for ; Mon, 18 Jan 2010 08:47:49 -0800 (PST)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0IGlfJ9003201 for ; Mon, 18 Jan 2010 10:47:45 -0600
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 18 Jan 2010 18:47:37 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 18 Jan 2010 18:47:32 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Mon, 18 Jan 2010 17:47:32 +0100
From: 
To: 
Date: Mon, 18 Jan 2010 17:47:31 +0100
Thread-Topic: IKEv2bis, comments about sections 1-2
Thread-Index: AcqYXe1SfvmJIbIrRL+ClD/e9Qdotg==
Message-ID: <808FD6E27AD4884E94820BC333B2DB7758410A954B@NOK-EUMSG-01.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 18 Jan 2010 16:47:32.0670 (UTC) FILETIME=[EE0D25E0:01CA985D]
X-Nokia-AV: Clean
Subject: [IPsec] IKEv2bis, comments about sections 1-2
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2010 16:47:50 -0000

I'm doing a yet another full review pass over the whole document (not
just diff as I've usually done; to find issues/inconsistencies that
diffs wouldn't necessarily show). So far, I've covered Sections 1=20
and 2.

Substantial comments:

- Section 1.5: I noticed the 1st paragraph nowadays (well, since -00
of the WG draft) allows sending INVALID_IKE_SPI notification inside an
existing IKE_SA. This contradicts a MUST NOT in RFC 4306, and I'm not
sure if it really brings any benefits?

- Section 2.8.1, NO_PROPOSAL_CHOSEN near the end. This is probably
left over from old versions, and should be something else now
to align with Section 2.25? =20

- Section 2.8.2: (already covered by issue #135)

- Section 2.14: "only the first 64 bits of Ni and the first 64 bits of
Nr are used in the calculation". This section has two calculations
involving Ni/Nr, but this sentence should only apply to the former.
Suggested rephrasing: "the calculation" -> "when calculating SKEYSEED
(but all bits are used when calculating SK_*)"

- Section 2.17: See
http://www.ietf.org/mail-archive/web/ipsec/current/msg04673.html
http://www.ietf.org/mail-archive/web/ipsec/current/msg04681.html

- Section 2.23, last bullet: "MUST NOT be used when MOBIKE is used"
This is actually not exactly what Section 3.8 of [MOBIKE] says (it
does allow using this for ESP).  I would suggest just referring to
Section 3.8 of [MOBIKE] for details.

- Section 2.23.1: If the responder doesn't find SPD entry for
transport mode with the modified traffic selectors, and does a lookup
with the original selectors, if it finds an entry for transport mode,
can it use it? (And would that screw up the initiator processing of
the reply? Unfortunately,this question is relevant for RFC 5555...)

- Section 2.25: "A peer that receives a CHILD_SA_NOT_FOUND
notification SHOULD silently delete the Child SA": Is this really
necessary? I think this notification should only occur in cases where
DELETE payload for this Child SA pair has already been sent, and
probably has been processed already by the time the CHILD_SA_NOT_FOUND
notification is received.=20

- Section 2.25.2, "If a peer receives a request to delete a Child SA
when it is currently rekeying the IKE SA, it SHOULD reply as usual,
with a Delete payload." I noticed this is different from what RFC 4718
recommended, but this is probably OK, given the other text...  (but I
still hope this was intentional change :-)

Somewhat substantial:

- Section 1.3.1: delete sentence "When an IKE SA is not created..."
(this section is about CREATE_CHILD_SA, and the IKE_AUTH error
messages are already well described in Section 1.2).

- Section 1.5 doesn't read well, and needs a rewrite. I can
provide text once the substantial issue re: INVALID_IKE_SPI
is decided.

- Section 2.6, paragraph beginning with "In addition to cookies..",
and Section 2.7, last paragraph, are both in very strange places (and
basically say the same thing). Suggest combining both, and adding them
to the end of paragraph "In the first message.." in 2.6:

   "When the exchange does not result in the creation of an IKE SA on
   the responder (due to, for example, COOKIE, INVALID_KE_PAYLOAD, or
   NO_PROPOSAL_CHOSEN), the responder's SPI will be zero also in the
   response message. However, if the responder does send a non-zero
   responder SPI, the initiator should not reject the response for
   only that reason."

- There are two places that have very similar text about
INVALID_KE_PAYLOAD: Section 1.3 (for CREATE_CHILD_SA exchange), and
Section 2.7 (for IKE_SA_INIT exchange).  Especially the latter seems a
bit strange, everything else in that section applies to
CREATE_CHILD_SA exchanges, too, but this paragraph explicitly applies
to IKE_SA_INIT only (although INVALID_KE_PAYLOAD works roughly the
same way in CREATE_CHILD_SA, too). Perhaps the text in 2.7 should be
moved to 1.2?

- Section 2.8, sentence: "Note that, when rekeying..." This is in
wrong place; the rest of this paragraph is about IKE_SA rekeying, so
it should be moved to the previous paragraph.

- Section 2.18, last paragraph: suggest adding "PRF" to the list of
things that come from the new exchange.

- Section 2.23, paragraph starting: "An initiator can float..."  needs
some clarifications. Probably "UDP encapsulation/encapsulated" should
be "UDP encapsulation of ESP/UDP-encapsulated ESP" (since at other
places, the document also talks about IKE packets being UDP
encapsulated).

- Section 2.23.1: I would strongly suggest using the word "original
address" (just like RFC 3947) instead "real address" (since both
addresses are very real).

- Section 2.23.1, "- Store the original traffic selectors.."  (occurs
twice) I would suggest using "received" instead of "original" here.

Best regards,
Pasi=20


From paul.hoffman@vpnc.org  Mon Jan 18 15:16:51 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0012C3A67F6 for ; Mon, 18 Jan 2010 15:16:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.968
X-Spam-Level: 
X-Spam-Status: No, score=-5.968 tagged_above=-999 required=5 tests=[AWL=0.078,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzFLf1KGcJ7r for ; Mon, 18 Jan 2010 15:16:50 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 1D6A03A67D1 for ; Mon, 18 Jan 2010 15:16:49 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0INGiWL005392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jan 2010 16:16:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7758410A9509@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB7758410A9509@NOK-EUMSG-01.mgdnok.nokia.com>
Date: Mon, 18 Jan 2010 15:16:42 -0800
To: , 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [IPsec] IKEv2bis editorial nits (Sections 1-2)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2010 23:16:51 -0000

All of these are fine; done.

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Mon Jan 18 18:22:53 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEA543A67B3 for ; Mon, 18 Jan 2010 18:22:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.971
X-Spam-Level: 
X-Spam-Status: No, score=-5.971 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Akx4hzAPuV+S for ; Mon, 18 Jan 2010 18:22:53 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 23B383A6784 for ; Mon, 18 Jan 2010 18:22:53 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0J2MlLl014115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jan 2010 19:22:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <19284.34317.682796.84636@fireball.kivinen.iki.fi>
References: <19284.34317.682796.84636@fireball.kivinen.iki.fi>
Date: Mon, 18 Jan 2010 18:22:45 -0800
To: Tero Kivinen , ipsec@ietf.org
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [IPsec] Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1 forward)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 02:22:54 -0000

Another big thank you for doing this review. I have incorporated everything other than the following.

----------------------------------------------------------------------
Also the bullet

   - Store the original traffic selector IP addresses as real source
     and destination address in case we need to undo address
     substitution.

needs to be changed to

   - Store the original traffic selector IP addresses as real source
     and destination address and also in case we need them to undo
     address substitution.

[[ Response: That wording doesn't make any sense to me. ]]

----------------------------------------------------------------------

In section 3.6 we have text which says:

	   Certificate payloads SHOULD be included in an exchange if
   certificates are available to the sender unless the peer has
   indicated an ability to retrieve this information from elsewhere
   using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload.  

which is bit misleading, as even if HTTP_CERT_LOOKUP_SUPPORTED notify
payload is sent that does not mean peer should leave out all Certificate
payloads, it just means it should use Hash and URL formats instead of
sending full certificates.

Perhaps it should be changed to:

	   Certificate payloads SHOULD be included in an exchange if
   certificates are available to the sender. The Hash and URL formats of
   the Certificate payloads should be used in case the peer has indicated
   an ability to retrieve this information from elsewhere using an
   HTTP_CERT_LOOKUP_SUPPORTED Notify payload.

[[ Response: The proposed change does not make sense: it sounds like a peer SHOULD send *both* the certificates and the hash-and-URL, which is silly. ]]

----------------------------------------------------------------------

Section "3.10.1.  Notify Message Types" should include:


   TEMPORARY_FAILURE		 {TBA1}
       See section 2.25.

   CHILD_SA_NOT_FOUND		 {TBA2}
       See section 2.25.

[[ Response: Can't do that: the WG decided we have to leave the tables with the values defined in RFC 4306. Those two are, of course, listed in the IANA considerations. ]]

----------------------------------------------------------------------
Following things might or might not need to be added to section 1.7
(taken from appendix E):

[[ Response: I included only some of those. 1.7 is not meant to be exhaustive: it can't be. But I did add a bunch you had suggested that I had missed on my pass. ]]

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Mon Jan 18 18:30:22 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A89143A68C4 for ; Mon, 18 Jan 2010 18:30:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.973
X-Spam-Level: 
X-Spam-Status: No, score=-5.973 tagged_above=-999 required=5 tests=[AWL=0.073,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UsEewLXfJt8 for ; Mon, 18 Jan 2010 18:30:22 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id ED4423A67B0 for ; Mon, 18 Jan 2010 18:30:21 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0J2UGl3014435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 18 Jan 2010 19:30:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <064.4edefd1af047d580f930dab249c8e673@tools.ietf.org>
References: <064.4edefd1af047d580f930dab249c8e673@tools.ietf.org>
Date: Mon, 18 Jan 2010 18:25:35 -0800
To: IPsecme WG 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: [IPsec] Issue #137: Sending INVALID_IKE_SPI notification inside an existing IKE_SA
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 02:30:22 -0000

Section 1.5: I noticed the 1st paragraph nowadays (well, since -00 of the WG draft) allows sending INVALID_IKE_SPI notification inside an existing IKE_SA. This contradicts a MUST NOT in RFC 4306, and I'm not sure if it really brings any benefits?

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Mon Jan 18 18:30:23 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB2CF3A69DC for ; Mon, 18 Jan 2010 18:30:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.975
X-Spam-Level: 
X-Spam-Status: No, score=-5.975 tagged_above=-999 required=5 tests=[AWL=0.071,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWtnFutiqudF for ; Mon, 18 Jan 2010 18:30:22 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id D04D23A67B0 for ; Mon, 18 Jan 2010 18:30:22 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0J2UGl7014435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 18 Jan 2010 19:30:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <064.cff10879f1e3e888fa8930a85464b847@tools.ietf.org>
References: <064.cff10879f1e3e888fa8930a85464b847@tools.ietf.org>
Date: Mon, 18 Jan 2010 18:26:48 -0800
To: IPsecme WG 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: [IPsec] Issue #139: Keying material taken in the order for RoHC
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 02:30:23 -0000

 One of the differences between RFC 4306 and the IKEv2bis draft is in
 Section 2.17, Generating Key Material for Child SAs. Appendix E.2 of the
 IKEv2bis draft indicates the following:

 In Section 2.17, removed "If multiple IPsec protocols are negotiated,
 keying material is taken in the order in which the protocol headers
 will appear in the encapsulated packet" because multiple IPsec
 protocols cannot be negotiated at one time.

 Is it possible to leave the quoted text in the spec? I agree that multiple
 IPsec protocols cannot be negotiated at one time; however, the text is
 useful for ROHCoIPsec implementers, where multiple keys may need to be
 generated for a ROHC-enabled Child SA.

 For example, if a ROHC-enabled Child-SA with ROHC_INTEG [draft-ietf-rohc-
 ikev2-extensions-hcoipsec-09] is instantiated, first the IPsec
 encryption/authentication keying material will be taken, then an
 additional key will be taken for the algorithm used to verify the proper
 decompression of packet headers.

 Also:

 The original text in RFC 4306 was slightly confusing, but I think we
 should leave room for ROHCoIPsec here. Perhaps adding something like
 this after the bulleted list?

    If the Child SA negotiation includes some future IPsec protocol(s)
    in addition to (or instead of) ESP or AH (e.g., ROHC_INTEG), then
    (1) all keys for SAs carrying data from the initiator to the
    responder are taken before SAs going in the reverse direction, and
    (2) keying material for the IPsec protocols are taken in the order
    in which the protocol headers will appear in the encapsulated
    packet.

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Mon Jan 18 18:30:24 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D1FE3A68C4 for ; Mon, 18 Jan 2010 18:30:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.977
X-Spam-Level: 
X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[AWL=0.069,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiM0jeqwWe+j for ; Mon, 18 Jan 2010 18:30:23 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 814593A69CF for ; Mon, 18 Jan 2010 18:30:23 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0J2UGl9014435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 18 Jan 2010 19:30:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <064.c6d473cc5819f99907907c6144324c07@tools.ietf.org>
References: <064.c6d473cc5819f99907907c6144324c07@tools.ietf.org>
Date: Mon, 18 Jan 2010 18:27:13 -0800
To: IPsecme WG 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: [IPsec] Issue #140: No SPD entry for transport mode
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 02:30:24 -0000

 Section 2.23.1: If the responder doesn't find SPD entry for
 transport mode with the modified traffic selectors, and does a lookup
 with the original selectors, if it finds an entry for transport mode,
 can it use it? (And would that screw up the initiator processing of
 the reply? Unfortunately,this question is relevant for RFC 5555...)

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Mon Jan 18 18:44:37 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E5563A69E4 for ; Mon, 18 Jan 2010 18:44:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.979
X-Spam-Level: 
X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[AWL=0.067,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkoEhNlh+g+P for ; Mon, 18 Jan 2010 18:44:36 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 743EF3A6975 for ; Mon, 18 Jan 2010 18:44:36 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0J2UGlF014435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 18 Jan 2010 19:30:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <064.ab2ff0ca09001764d46ce8c6ea30657a@tools.ietf.org>
References: <064.ab2ff0ca09001764d46ce8c6ea30657a@tools.ietf.org>
Date: Mon, 18 Jan 2010 18:28:56 -0800
To: IPsecme WG 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: [IPsec] Issue #143: Rewrite of 1.5
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 02:44:37 -0000

 Section 1.5 doesn't read well, and needs a rewrite. Pasi can
 provide text once the substantial issue re: INVALID_IKE_SPI
 is decided.

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Mon Jan 18 18:44:37 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEAB53A69E4 for ; Mon, 18 Jan 2010 18:44:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.981
X-Spam-Level: 
X-Spam-Status: No, score=-5.981 tagged_above=-999 required=5 tests=[AWL=0.065,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2M3r87FgD0f for ; Mon, 18 Jan 2010 18:44:36 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id AD7143A69CC for ; Mon, 18 Jan 2010 18:44:36 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0J2UGlL014435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 18 Jan 2010 19:30:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <064.d85d00066812bdaceff3ac778480d642@tools.ietf.org>
References: <064.d85d00066812bdaceff3ac778480d642@tools.ietf.org>
Date: Mon, 18 Jan 2010 18:30:05 -0800
To: IPsecme WG 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: [IPsec] Issue #146: Encapsulation wording
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 02:44:38 -0000

 Section 2.23, paragraph starting: "An initiator can float..."  needs
 some clarifications. Probably "UDP encapsulation/encapsulated" should
 be "UDP encapsulation of ESP/UDP-encapsulated ESP" (since at other
 places, the document also talks about IKE packets being UDP
 encapsulated).

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Mon Jan 18 18:44:37 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E45C03A69CC for ; Mon, 18 Jan 2010 18:44:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.982
X-Spam-Level: 
X-Spam-Status: No, score=-5.982 tagged_above=-999 required=5 tests=[AWL=0.064,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1npDvUQlsTn6 for ; Mon, 18 Jan 2010 18:44:37 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id EF33B3A69E3 for ; Mon, 18 Jan 2010 18:44:36 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0J2UGlJ014435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 18 Jan 2010 19:30:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <064.f3ea9d87cfe8949bb9980c9ab970738c@tools.ietf.org>
References: <064.f3ea9d87cfe8949bb9980c9ab970738c@tools.ietf.org>
Date: Mon, 18 Jan 2010 18:29:41 -0800
To: IPsecme WG 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: [IPsec] #145: IKE_SA rekeying wording in 2.8
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 02:44:38 -0000

 Section 2.8, sentence: "Note that, when rekeying..." This is in
 wrong place; the rest of this paragraph is about IKE_SA rekeying, so
 it should be moved to the previous paragraph.

 [[ Tero noted this as well, but Paul disagreed, saying that the placement
 was correct. This needs to be resolved. ]]

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Mon Jan 18 18:44:38 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 354D23A69CC for ; Mon, 18 Jan 2010 18:44:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.984
X-Spam-Level: 
X-Spam-Status: No, score=-5.984 tagged_above=-999 required=5 tests=[AWL=0.062,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63EPdLMCNKID for ; Mon, 18 Jan 2010 18:44:37 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 3CFA43A6975 for ; Mon, 18 Jan 2010 18:44:37 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0J2UGl5014435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 18 Jan 2010 19:30:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <064.0e5659162c4e55745d66c3ac8e8be7f8@tools.ietf.org>
References: <064.0e5659162c4e55745d66c3ac8e8be7f8@tools.ietf.org>
Date: Mon, 18 Jan 2010 18:25:57 -0800
To: IPsecme WG 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: [IPsec] Issue #138: Calculations involving Ni/Nr
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 02:44:38 -0000

 Section 2.14: "only the first 64 bits of Ni and the first 64 bits of
 Nr are used in the calculation". This section has two calculations
 involving Ni/Nr, but this sentence should only apply to the former.
 Suggested rephrasing: "the calculation" -> "when calculating SKEYSEED
 (but all bits are used when calculating SK_*)"

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Mon Jan 18 18:44:38 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83BA43A69CC for ; Mon, 18 Jan 2010 18:44:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.985
X-Spam-Level: 
X-Spam-Status: No, score=-5.985 tagged_above=-999 required=5 tests=[AWL=0.061,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZpL1GNFK4v0 for ; Mon, 18 Jan 2010 18:44:37 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id ABFDC3A69E7 for ; Mon, 18 Jan 2010 18:44:37 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0J2UGlD014435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 18 Jan 2010 19:30:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <064.0d315aaeb2bd619d37eac8c0f0e27e80@tools.ietf.org>
References: <064.0d315aaeb2bd619d37eac8c0f0e27e80@tools.ietf.org>
Date: Mon, 18 Jan 2010 18:28:10 -0800
To: IPsecme WG 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: [IPsec] Issue #142: Difference from RFC 4718 in rekeying IKE SA
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 02:44:38 -0000

 Section 2.25.2, "If a peer receives a request to delete a Child SA
 when it is currently rekeying the IKE SA, it SHOULD reply as usual,
 with a Delete payload." I noticed this is different from what RFC 4718
 recommended, but this is probably OK, given the other text...  (but I
 still hope this was intentional change :-)

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Mon Jan 18 18:44:38 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B17A23A69E4 for ; Mon, 18 Jan 2010 18:44:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.987
X-Spam-Level: 
X-Spam-Status: No, score=-5.987 tagged_above=-999 required=5 tests=[AWL=0.059,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+qU5exZSe+t for ; Mon, 18 Jan 2010 18:44:38 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id ECA9B3A69E8 for ; Mon, 18 Jan 2010 18:44:37 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0J2UGlB014435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 18 Jan 2010 19:30:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <064.e963e5b9c3d1955a5bc2d70dd03d6752@tools.ietf.org>
References: <064.e963e5b9c3d1955a5bc2d70dd03d6752@tools.ietf.org>
Date: Mon, 18 Jan 2010 18:27:34 -0800
To: IPsecme WG 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: [IPsec] Issue #141: Silently deleting the Child SA after a CHILD_SA_NOT_FOUND
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 02:44:38 -0000

 Section 2.25: "A peer that receives a CHILD_SA_NOT_FOUND
 notification SHOULD silently delete the Child SA": Is this really
 necessary? I think this notification should only occur in cases where
 DELETE payload for this Child SA pair has already been sent, and
 probably has been processed already by the time the CHILD_SA_NOT_FOUND
 notification is received.

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Mon Jan 18 18:44:39 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C9AA3A69CC for ; Mon, 18 Jan 2010 18:44:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.988
X-Spam-Level: 
X-Spam-Status: No, score=-5.988 tagged_above=-999 required=5 tests=[AWL=0.058,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhRQBN4dL39Z for ; Mon, 18 Jan 2010 18:44:38 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 3D4183A6975 for ; Mon, 18 Jan 2010 18:44:38 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0J2UGlH014435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 18 Jan 2010 19:30:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <064.e362c0035a6b0b331faec5471cd5bb0d@tools.ietf.org>
References: <064.e362c0035a6b0b331faec5471cd5bb0d@tools.ietf.org>
Date: Mon, 18 Jan 2010 18:29:19 -0800
To: IPsecme WG 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: [IPsec] Issue #144: Placement of INVALID_KE_PAYLOAD text
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 02:44:39 -0000

 There are two places that have very similar text about
 INVALID_KE_PAYLOAD: Section 1.3 (for CREATE_CHILD_SA exchange), and
 Section 2.7 (for IKE_SA_INIT exchange).  Especially the latter seems a
 bit strange, everything else in that section applies to
 CREATE_CHILD_SA exchanges, too, but this paragraph explicitly applies
 to IKE_SA_INIT only (although INVALID_KE_PAYLOAD works roughly the
 same way in CREATE_CHILD_SA, too). Perhaps the text in 2.7 should be
 moved to 1.2?

--Paul Hoffman, Director
--VPN Consortium

From yaronf@checkpoint.com  Mon Jan 18 22:57:43 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ABA03A684E for ; Mon, 18 Jan 2010 22:57:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzcFLfgdordk for ; Mon, 18 Jan 2010 22:57:42 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id D6B9F3A6800 for ; Mon, 18 Jan 2010 22:57:41 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0J6vaT7003246; Tue, 19 Jan 2010 08:57:36 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 19 Jan 2010 08:57:50 +0200
From: Yaron Sheffer 
To: Paul Hoffman , Tero Kivinen , "ipsec@ietf.org" 
Date: Tue, 19 Jan 2010 08:57:49 +0200
Thread-Topic: Notify types, was: RE: [IPsec] Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1 forward)
Thread-Index: AcqYrllyxG2tdyI0RQyTrFJRRFxfPAAIEa6w
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21D66@il-ex01.ad.checkpoint.com>
References: <19284.34317.682796.84636@fireball.kivinen.iki.fi> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [IPsec] Notify types, was: RE: Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1 forward)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 06:57:43 -0000

I agree with Tero, regardless of the discussion we had on where to put the =
tables etc., the document needs to be internally consistent. So we should a=
dd the new notify types that we're defining in *this* document to the notif=
y types table. Luckily there aren't many.

Thanks,
	Yaron

----------------------------------------------------------------------

Section "3.10.1.  Notify Message Types" should include:


   TEMPORARY_FAILURE		 {TBA1}
       See section 2.25.

   CHILD_SA_NOT_FOUND		 {TBA2}
       See section 2.25.

[[ Response: Can't do that: the WG decided we have to leave the tables with=
 the values defined in RFC 4306. Those two are, of course, listed in the IA=
NA considerations. ]]

----------------------------------------------------------------------


From svanru@gmail.com  Mon Jan 18 23:34:17 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C4283A6941 for ; Mon, 18 Jan 2010 23:34:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level: 
X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, XMAILER_MIMEOLE_OL_7533E=0.513]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpnF4gze8Vfe for ; Mon, 18 Jan 2010 23:34:16 -0800 (PST)
Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 675543A68FF for ; Mon, 18 Jan 2010 23:34:16 -0800 (PST)
Received: by ewy6 with SMTP id 6so4355395ewy.29 for ; Mon, 18 Jan 2010 23:34:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:references :subject:date:mime-version:content-type:content-transfer-encoding :x-priority:x-msmail-priority:x-mailer:x-mimeole; bh=jJ/q1TM/y4Aj7awoSR9ADrucTczd79lv/veNenPajC0=; b=QzQNs7X1+ITRrHEFlxIN70S+WLt4veLg/Tx3/DrNlmQQS+Q1hLvzC4leHz/yvMc+XD WSktA8TglN2cI9eF+hkcSysI2is/CWaUZVECUWl6s9Mtj4OK6LFRor8BrEG+ESV87ToZ R8Z/jvBx0w/Kd8+kA/8G04wRlwPwiCyInhZig=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=tuYq+MJ7Ks85AjtRs5Ym7hLCMe1Kzt5KdygitOVjjY8EfEl7EZ03QPRRwhUOt8pP9O hpTNwafKJRSODyph70oNKYkivRCYCujF8/5+MiVs4EZeUS7MJN3clpgJ0+UKcH8BvnrK JwCv1Q1yhObz0YwttjAhLagoMYtRQ45QQKHxI=
Received: by 10.213.37.76 with SMTP id w12mr170577ebd.26.1263886448502; Mon, 18 Jan 2010 23:34:08 -0800 (PST)
Received: from svanpc ([82.138.51.4]) by mx.google.com with ESMTPS id 15sm2191347ewy.4.2010.01.18.23.34.06 (version=SSLv3 cipher=RC4-MD5); Mon, 18 Jan 2010 23:34:06 -0800 (PST)
Message-ID: 
From: "Valery Smyslov" 
To: "Yaron Sheffer" , "Paul Hoffman" , "Tero Kivinen" , 
References: <19284.34317.682796.84636@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21D66@il-ex01.ad.checkpoint.com>
Date: Tue, 19 Jan 2010 10:34:41 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4963.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700
Subject: Re: [IPsec] Notify types, was: RE: Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1 forward)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 07:34:17 -0000

Hi,

I also agree with Tero and Yaron. It's better to have all defined
notifications listed in one table.
In this case the paragraph immediately preceeding the table must be changed
from:

   The values in the following table are only current as of the
   publication date of RFC 4306.  Other values may have been added since
   then or will be added after the publication of this document.
   Readers should refer to [IKEV2IANA] for the latest values.

to something like:

   The values in the following table are only current as of the
   publication date of this document.  Other values may have been added
   since then. Readers should refer to [IKEV2IANA] for the latest values.


By the way, section 6 (IANA Considerations) contains typo:

   [IKEV2] defined many field types and values.  IANA has already
   registered those types and values in [IKEV2IANA], so the are not
                                                                            
      ^^^^
   listed here again.

Regards,
Valery Smyslov.


> I agree with Tero, regardless of the discussion we had on where to put the
tables etc., the document needs to be internally consistent. So we should
add the new notify types that we're defining in *this* document to the
notify types table. Luckily there aren't many.
>
> Thanks,
> Yaron
>
> ----------------------------------------------------------------------
>
> Section "3.10.1.  Notify Message Types" should include:
>
>
>    TEMPORARY_FAILURE {TBA1}
>        See section 2.25.
>
>    CHILD_SA_NOT_FOUND {TBA2}
>        See section 2.25.
>
> [[ Response: Can't do that: the WG decided we have to leave the tables
with the values defined in RFC 4306. Those two are, of course, listed in the
IANA considerations. ]]
>
> ----------------------------------------------------------------------
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec


From ynir@checkpoint.com  Tue Jan 19 00:21:39 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2AEC3A68D1 for ; Tue, 19 Jan 2010 00:21:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tvo-LsAo48XZ for ; Tue, 19 Jan 2010 00:21:38 -0800 (PST)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 1A78D3A67B2 for ; Tue, 19 Jan 2010 00:21:38 -0800 (PST)
X-CheckPoint: {4B556935-10002-14201DC2-FFFF}
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id A164C29C00A; Tue, 19 Jan 2010 10:21:33 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 7592529C002; Tue, 19 Jan 2010 10:21:33 +0200 (IST)
X-CheckPoint: {4B556934-10000-14201DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0J8LXT7012396; Tue, 19 Jan 2010 10:21:33 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 19 Jan 2010 10:21:46 +0200
From: Yoav Nir 
To: "'Valery Smyslov'" , Yaron Sheffer , Paul Hoffman , Tero Kivinen , "ipsec@ietf.org" 
Date: Tue, 19 Jan 2010 10:21:46 +0200
Thread-Topic: [IPsec] Notify types,	was: RE: Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1	forward)
Thread-Index: AcqY2dhSU+Pd/ZLrSFqL+X+3fFuc5QABlYjg
Message-ID: <006FEB08D9C6444AB014105C9AEB133FB36A511137@il-ex01.ad.checkpoint.com>
References: <19284.34317.682796.84636@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21D66@il-ex01.ad.checkpoint.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [IPsec] Notify types, was: RE: Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1	forward)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 08:21:40 -0000

+1

Anybody who starts implementing IKEv2 in a few months using the new RFC sho=
uld not have to care about the history, and which notify type was added at =
which point, except to know that some implementations in the field may not =
support these newer notifications.

-----Original Message-----
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of V=
alery Smyslov
Sent: Tuesday, January 19, 2010 9:35 AM
To: Yaron Sheffer; Paul Hoffman; Tero Kivinen; ipsec@ietf.org
Subject: Re: [IPsec] Notify types, was: RE: Review of rest of draft-ietf-ip=
secme-ikev2 (section 2.23.1 forward)

Hi,

I also agree with Tero and Yaron. It's better to have all defined
notifications listed in one table.
In this case the paragraph immediately preceeding the table must be changed
from:

   The values in the following table are only current as of the
   publication date of RFC 4306.  Other values may have been added since
   then or will be added after the publication of this document.
   Readers should refer to [IKEV2IANA] for the latest values.

to something like:

   The values in the following table are only current as of the
   publication date of this document.  Other values may have been added
   since then. Readers should refer to [IKEV2IANA] for the latest values.


By the way, section 6 (IANA Considerations) contains typo:

   [IKEV2] defined many field types and values.  IANA has already
   registered those types and values in [IKEV2IANA], so the are not
                                                                           =
=20
      ^^^^
   listed here again.

Regards,
Valery Smyslov.


> I agree with Tero, regardless of the discussion we had on where to put th=
e
tables etc., the document needs to be internally consistent. So we should
add the new notify types that we're defining in *this* document to the
notify types table. Luckily there aren't many.
>
> Thanks,
> Yaron
>
> ----------------------------------------------------------------------
>
> Section "3.10.1.  Notify Message Types" should include:
>
>
>    TEMPORARY_FAILURE {TBA1}
>        See section 2.25.
>
>    CHILD_SA_NOT_FOUND {TBA2}
>        See section 2.25.
>
> [[ Response: Can't do that: the WG decided we have to leave the tables
with the values defined in RFC 4306. Those two are, of course, listed in th=
e
IANA considerations. ]]
>
> ----------------------------------------------------------------------
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Scanned by Check Point Total Security Gateway.

From yaronf@checkpoint.com  Tue Jan 19 00:22:07 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6AA23A696C for ; Tue, 19 Jan 2010 00:22:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKVL1ivywngI for ; Tue, 19 Jan 2010 00:22:07 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 952133A67B2 for ; Tue, 19 Jan 2010 00:22:06 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0J8M0T7012450; Tue, 19 Jan 2010 10:22:00 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 19 Jan 2010 10:22:13 +0200
From: Yaron Sheffer 
To: Valery Smyslov , Paul Hoffman , Tero Kivinen , "ipsec@ietf.org" 
Date: Tue, 19 Jan 2010 10:22:09 +0200
Thread-Topic: [IPsec] Notify types, was: RE: Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1 forward)
Thread-Index: AcqY2dNGAdd3ps6vSEGkvydLlQx6fwABmmQw
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21D9E@il-ex01.ad.checkpoint.com>
References: <19284.34317.682796.84636@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21D66@il-ex01.ad.checkpoint.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [IPsec] Notify types, was: RE: Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1 forward)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 08:22:08 -0000

To clarify, I was only referring to the notifications defined in -bis. Not =
in any other documents.

-----Original Message-----
From: Valery Smyslov [mailto:svanru@gmail.com]=20
Sent: Tuesday, January 19, 2010 9:35
To: Yaron Sheffer; Paul Hoffman; Tero Kivinen; ipsec@ietf.org
Subject: Re: [IPsec] Notify types, was: RE: Review of rest of draft-ietf-ip=
secme-ikev2 (section 2.23.1 forward)

Hi,

I also agree with Tero and Yaron. It's better to have all defined
notifications listed in one table.
In this case the paragraph immediately preceeding the table must be changed
from:

   The values in the following table are only current as of the
   publication date of RFC 4306.  Other values may have been added since
   then or will be added after the publication of this document.
   Readers should refer to [IKEV2IANA] for the latest values.

to something like:

   The values in the following table are only current as of the
   publication date of this document.  Other values may have been added
   since then. Readers should refer to [IKEV2IANA] for the latest values.


By the way, section 6 (IANA Considerations) contains typo:

   [IKEV2] defined many field types and values.  IANA has already
   registered those types and values in [IKEV2IANA], so the are not
                                                                           =
=20
      ^^^^
   listed here again.

Regards,
Valery Smyslov.


> I agree with Tero, regardless of the discussion we had on where to put th=
e
tables etc., the document needs to be internally consistent. So we should
add the new notify types that we're defining in *this* document to the
notify types table. Luckily there aren't many.
>
> Thanks,
> Yaron
>
> ----------------------------------------------------------------------
>
> Section "3.10.1.  Notify Message Types" should include:
>
>
>    TEMPORARY_FAILURE {TBA1}
>        See section 2.25.
>
>    CHILD_SA_NOT_FOUND {TBA2}
>        See section 2.25.
>
> [[ Response: Can't do that: the WG decided we have to leave the tables
with the values defined in RFC 4306. Those two are, of course, listed in th=
e
IANA considerations. ]]
>
> ----------------------------------------------------------------------
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec


Scanned by Check Point Total Security Gateway.

From kivinen@iki.fi  Tue Jan 19 01:24:59 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B16F3A63C9 for ; Tue, 19 Jan 2010 01:24:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.501
X-Spam-Level: 
X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNOqGPKfcY+L for ; Tue, 19 Jan 2010 01:24:58 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 6AD943A67A4 for ; Tue, 19 Jan 2010 01:24:58 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0J9Ooh4015551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2010 11:24:50 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0J9OnY6018645; Tue, 19 Jan 2010 11:24:49 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19285.31329.364411.591517@fireball.kivinen.iki.fi>
Date: Tue, 19 Jan 2010 11:24:49 +0200
From: Tero Kivinen 
To: 
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7758410A954B@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB7758410A954B@NOK-EUMSG-01.mgdnok.nokia.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 6 min
X-Total-Time: 6 min
Cc: ipsec@ietf.org
Subject: [IPsec] INVALID_IKE_SPI inside IKE SA (was:  IKEv2bis, comments about sections 1-2)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 09:24:59 -0000

Pasi.Eronen@nokia.com writes:
> - Section 1.5: I noticed the 1st paragraph nowadays (well, since -00
> of the WG draft) allows sending INVALID_IKE_SPI notification inside an
> existing IKE_SA. This contradicts a MUST NOT in RFC 4306, and I'm not
> sure if it really brings any benefits?

There is no way to send INVALID_IKE_SPI inside IKE SA, as the section
3.10 says that the IKE SPI is never sent inside the notification
payload (For a notification concerning the IKE SA, the SPI Size MUST
be zero and the field must be empty.) and the IKE SPI is taken from
the packet. Sending INVALID_IKE_SPI inside IKE SA would mean that the
IKE SA you are sending the packet inside is invalid...

The section 2.21.4 is very clear that INVALID_IKE_SPI MUST NOT be
cryptographically protected, i.e. it is sent outside the IKE SA.

I think the 1st paragraph is quite wrong and the

  If the receiving node has an active IKE SA to the IP address from
  whence the packet came, it MAY send a notification of the wayward
  packet over that IKE SA in an INFORMATIONAL exchange.

part should be removed.
-- 
kivinen@iki.fi

From Pasi.Eronen@nokia.com  Tue Jan 19 02:14:45 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFE5C3A68DB for ; Tue, 19 Jan 2010 02:14:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.642
X-Spam-Level: 
X-Spam-Status: No, score=-6.642 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tfbmjc0SJcPk for ; Tue, 19 Jan 2010 02:14:45 -0800 (PST)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id E6A993A6846 for ; Tue, 19 Jan 2010 02:14:44 -0800 (PST)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0JAE94T009329 for ; Tue, 19 Jan 2010 04:14:40 -0600
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Jan 2010 12:14:13 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Jan 2010 12:14:08 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 19 Jan 2010 11:14:07 +0100
From: 
To: 
Date: Tue, 19 Jan 2010 11:14:06 +0100
Thread-Topic: IKEv2bis, comments about sections 3-
Thread-Index: AcqY8CIzpmIsxUNSSiOUkRNZOi++cQ==
Message-ID: <808FD6E27AD4884E94820BC333B2DB7758410A9BC5@NOK-EUMSG-01.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 19 Jan 2010 10:14:08.0336 (UTC) FILETIME=[232F5D00:01CA98F0]
X-Nokia-AV: Clean
Subject: [IPsec] IKEv2bis, comments about sections 3-
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 10:14:45 -0000

Somewhat substantial:

- Section 3.13.1: the paragraph about Mobility Header is very
confusing; suggested rephrasing:

   Traffic selectors can use IP Protocol ID 135 to match the IPv6
   mobility header [MIPV6].  As specified in [IPSECARCH], the IPv6
   mobility header (MH) message type is placed in the most significant
   eight bits of the 16-bit local port selector.  The direction
   semantics of TSi/TSr port fields are the same as for ICMP.

- Section 3.*: should we omit the UNSPECIFIED values? They don't
really help the reader here...

- Overall: The document uses 192.0.1.0/24 in examples (in addition to
the official 192.0.2.0/24 documentation block). Back in RFC 4306/4718
times, we didn't have much of a choice, but now
draft-iana-ipv4-examples (already approved) provides two additional
blocks. Suggest replacing "192.0.1" -> "198.51.100" .

- Appendix C.5: brackets should be removed from [KEi]/[KEr]

- Section 1.7, suggest mentioning the new notifications explicitly;
  i.e. rephrase the last paragraph

  "Section 2.25 was added to explain how to act when there are timing
  collisions when deleting and/or rekeying SAs, and two new error
  notifications (TEMPORARY_FAILURE and CHILD_SA_NOT_FOUND) were
  defined."

- Section 1.7: suggest adding
  =20
  "This document requires doing a Diffie-Hellman exchange when
  rekeying the IKE_SA.  In theory, RFC 4306 allowed a policy where
  the Diffie-Hellman exchange was optional, this was not useful (or
  appropriate) when rekeying the IKE_SA.

Editorial suggestions:

- Section 3.1: "The bits are defined LSB first, so bit 0 would be the
least significant bit of the Flags octet." This seems to be exactly
the opposite of the bit numbering used in the figure above, which
sounds confusing. Instead of using numbers, we should just show a
diagram?

    0 1 2 3 4 5 6 7=20
   +-+-+-+-+-+-+-+-+
   |X X|R|V|I|X X X|
   +-+-+-+-+-+-+-+-+

- Section 3.1, the text about critical bit should have a pointer to
Section 2.5.

- Section 3.3.6: suggest removing the last paragraph (the
INVALID_KE_PAYLOAD case is already well described in 1.2 and 2.7),=20
and there's no need to repeat it here.

- Section 3.4, 2nd-to-last paragraph: suggest adding pointer to
Sections 1.2 and 2.7.

- Section 3.10.1: there's one "{{ Demoted the SHOULD }}" that
should be removed.

- Section 3.10.1: the list should contain CHILD_SA_NOT_FOUND
and TEMPORARY_FAILURE.

- Section 3.15.1: the table column header should be "Multi-Valued"
(like it is in RFC 4306) instead of "Valued"

- Section 3.5: "MUST not" -> "MUST NOT" (twice)

- Section 1.6: the spelling in the 2nd paragraph isn't exactly
what RFC 2119 has (and this causes idnits to complain).=20

- From idnits: Duplicate reference: RFC4291, mentioned in 'IPV6ADDR',=20
was also mentioned in 'ADDRIPV6'.

- Appendix D: can be removed, since the changes from RFC 4306 are
now in Section 1.7

Best regards,
Pasi

From kivinen@iki.fi  Tue Jan 19 03:12:22 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F5223A6967 for ; Tue, 19 Jan 2010 03:12:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.509
X-Spam-Level: 
X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsjPzZgAujQO for ; Tue, 19 Jan 2010 03:12:21 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id C78583A693C for ; Tue, 19 Jan 2010 03:12:20 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0JBCBXi019513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2010 13:12:12 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0JBCBiO001008; Tue, 19 Jan 2010 13:12:11 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19285.37771.259456.852530@fireball.kivinen.iki.fi>
Date: Tue, 19 Jan 2010 13:12:11 +0200
From: Tero Kivinen 
To: 
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7758410A954B@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB7758410A954B@NOK-EUMSG-01.mgdnok.nokia.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 5 min
X-Total-Time: 5 min
Cc: ipsec@ietf.org
Subject: [IPsec] RFC5555 and Section 2.23.1 (was:  IKEv2bis, comments about sections 1-2)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 11:12:22 -0000

Pasi.Eronen@nokia.com writes:
> - Section 2.23.1: If the responder doesn't find SPD entry for
> transport mode with the modified traffic selectors, and does a lookup
> with the original selectors, if it finds an entry for transport mode,
> can it use it? 

I do not think it can use the transport mode SA using original
selectors. This of course depends which traffic selectors are used
when installing the SA data to SAD. If those original selectors are
used then incoming packets will be dropped because they do not match
the selectors for the SA (RFC4301 section 5.2, step 5).

If modified selectors is used when installing SA then those selectors
were not matched against the SPD, and this can cause spoofing attacks.

> (And would that screw up the initiator processing of
> the reply?

That again depends which traffic selectors are returned. If original
traffic selectors are returned then initiator do not get information
about the original addresses, thus it cannot do incremental checksum
updating. Also depending what kind of checks initiator does, it might
cause initiator to fail the reply processing.

> Unfortunately,this question is relevant for RFC 5555...)

What kind of things does the RFC5555 require?
-- 
kivinen@iki.fi

From kivinen@iki.fi  Tue Jan 19 03:20:30 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E71F53A69F7 for ; Tue, 19 Jan 2010 03:20:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.516
X-Spam-Level: 
X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xM1+kGgqAAkq for ; Tue, 19 Jan 2010 03:20:27 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 95BD93A6988 for ; Tue, 19 Jan 2010 03:20:26 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0JBKLNv020617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2010 13:20:21 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0JBKLDZ017725; Tue, 19 Jan 2010 13:20:21 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19285.38261.379439.873648@fireball.kivinen.iki.fi>
Date: Tue, 19 Jan 2010 13:20:21 +0200
From: Tero Kivinen 
To: 
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7758410A954B@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB7758410A954B@NOK-EUMSG-01.mgdnok.nokia.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 8 min
X-Total-Time: 7 min
Cc: ipsec@ietf.org
Subject: [IPsec] CHILD_SA_NOT_FOUND error (was:  IKEv2bis, comments about sections 1-2)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 11:20:30 -0000

Pasi.Eronen@nokia.com writes:
> - Section 2.25: "A peer that receives a CHILD_SA_NOT_FOUND
> notification SHOULD silently delete the Child SA": Is this really
> necessary? I think this notification should only occur in cases where
> DELETE payload for this Child SA pair has already been sent, and
> probably has been processed already by the time the CHILD_SA_NOT_FOUND
> notification is received.

I agree on that, and I proposed new wording for that:

   A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives
   a request to rekey a Child SA that does not exist A peer that receives
   a CHILD_SA_NOT_FOUND notification SHOULD silently delete the Child SA
   (if it still exists, as most likely delete notification sent by the
   other hand has already deleted it) and send a request to create a new
   Child SA from scratch if such Child SA does not yet exists.

> - Section 2.25.2, "If a peer receives a request to delete a Child SA
> when it is currently rekeying the IKE SA, it SHOULD reply as usual,
> with a Delete payload." I noticed this is different from what RFC 4718
> recommended, but this is probably OK, given the other text...  (but I
> still hope this was intentional change :-)

This was intentional change.

When we discussed this in the design team, nobody see any reason why
it should reply without the delete payload. In all implementation I
know the SPI itself is enough to delete the SA, it does not really
matter whether that Child SA was already moved to the new IKE SA or
whether it was still in the Old IKE SA. This means sending delete to
either one of the SA will cause the Child SA to go and that SPI cannot
refer to any other Child SA.

So most of the implementations will be replying with delete payload as
usual and the Child SA is deleted. Implementations are always allowed
not to return the delete payload immediately if they like, so the old
behavior from RFC4718 is still also allowed, but not preferred.

We tought it would be best to try to limit the amount of cases where
half-closed SAs could be created so we though it is better to close
the Child SA directly without going first to the half-closed state,
and waiting for the other end to send another delete payload (using
new IKE SA?) for the other half.
-- 
kivinen@iki.fi

From Pasi.Eronen@nokia.com  Tue Jan 19 03:24:27 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EC7E3A68DD for ; Tue, 19 Jan 2010 03:24:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.637
X-Spam-Level: 
X-Spam-Status: No, score=-6.637 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmnC8AsHZ-DM for ; Tue, 19 Jan 2010 03:24:26 -0800 (PST)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 70E6A3A68DB for ; Tue, 19 Jan 2010 03:24:26 -0800 (PST)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0JBOCuh006541; Tue, 19 Jan 2010 05:24:19 -0600
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Jan 2010 13:24:17 +0200
Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Jan 2010 13:24:09 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Jan 2010 13:24:04 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 19 Jan 2010 12:24:03 +0100
From: 
To: , , , 
Date: Tue, 19 Jan 2010 12:24:03 +0100
Thread-Topic: [IPsec] Notify types, was: RE: Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1 forward)
Thread-Index: AcqYrllyxG2tdyI0RQyTrFJRRFxfPAAIEa6wAAq6GlA=
Message-ID: <808FD6E27AD4884E94820BC333B2DB7758410A9C91@NOK-EUMSG-01.mgdnok.nokia.com>
References: <19284.34317.682796.84636@fireball.kivinen.iki.fi>  <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21D66@il-ex01.ad.checkpoint.com>
In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21D66@il-ex01.ad.checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 19 Jan 2010 11:24:04.0313 (UTC) FILETIME=[E82EA490:01CA98F9]
X-Nokia-AV: Clean
Subject: Re: [IPsec] Notify types, was: RE: Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1 forward)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 11:24:27 -0000

I think the tables should list the values needed to implement *this*=20
specification; in all cases except here, that's the same as "defined=20
in RFC 4306", but not in this case.

Best regards,
Pasi

> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
> Of ext Yaron Sheffer
> Sent: 19 January, 2010 08:58
> To: Paul Hoffman; Tero Kivinen; ipsec@ietf.org
> Subject: [IPsec] Notify types, was: RE: Review of rest of draft-ietf-
> ipsecme-ikev2 (section 2.23.1 forward)
>=20
> I agree with Tero, regardless of the discussion we had on where to put
> the tables etc., the document needs to be internally consistent. So we
> should add the new notify types that we're defining in *this* document
> to the notify types table. Luckily there aren't many.
>=20
> Thanks,
> 	Yaron
>=20
> ----------------------------------------------------------------------
>=20
> Section "3.10.1.  Notify Message Types" should include:
>=20
>=20
>    TEMPORARY_FAILURE		 {TBA1}
>        See section 2.25.
>=20
>    CHILD_SA_NOT_FOUND		 {TBA2}
>        See section 2.25.
>=20
> [[ Response: Can't do that: the WG decided we have to leave the tables
> with the values defined in RFC 4306. Those two are, of course, listed
> in the IANA considerations. ]]
>=20
> ----------------------------------------------------------------------
>=20
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

From Pasi.Eronen@nokia.com  Tue Jan 19 03:28:03 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C09053A68DB for ; Tue, 19 Jan 2010 03:28:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.636
X-Spam-Level: 
X-Spam-Status: No, score=-6.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAD9loUkxN6L for ; Tue, 19 Jan 2010 03:28:02 -0800 (PST)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id D07E93A68DD for ; Tue, 19 Jan 2010 03:28:02 -0800 (PST)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0JBRaio009298; Tue, 19 Jan 2010 05:27:58 -0600
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Jan 2010 13:27:50 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Jan 2010 13:27:42 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 19 Jan 2010 12:27:41 +0100
From: 
To: 
Date: Tue, 19 Jan 2010 12:27:40 +0100
Thread-Topic: INVALID_IKE_SPI inside IKE SA (was: [IPsec] IKEv2bis, comments about sections 1-2)
Thread-Index: AcqY6Um0cAw6wbmKSpyYjyHqPDBZZAAEOrLg
Message-ID: <808FD6E27AD4884E94820BC333B2DB7758410A9C9E@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB7758410A954B@NOK-EUMSG-01.mgdnok.nokia.com> <19285.31329.364411.591517@fireball.kivinen.iki.fi>
In-Reply-To: <19285.31329.364411.591517@fireball.kivinen.iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 19 Jan 2010 11:27:42.0262 (UTC) FILETIME=[6A170560:01CA98FA]
X-Nokia-AV: Clean
Cc: ipsec@ietf.org
Subject: Re: [IPsec] INVALID_IKE_SPI inside IKE SA (was:  IKEv2bis, comments about sections 1-2)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 11:28:03 -0000

Tero,

I agree with your analysis (I hadn't noticed that this=20
doesn't even work).

Best regards,
Pasi

> -----Original Message-----
> From: ext Tero Kivinen [mailto:kivinen@iki.fi]
> Sent: 19 January, 2010 11:25
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: ipsec@ietf.org
> Subject: INVALID_IKE_SPI inside IKE SA (was: [IPsec] IKEv2bis, comments
> about sections 1-2)
>=20
> Pasi.Eronen@nokia.com writes:
> > - Section 1.5: I noticed the 1st paragraph nowadays (well, since -00
> > of the WG draft) allows sending INVALID_IKE_SPI notification inside
> > an
> > existing IKE_SA. This contradicts a MUST NOT in RFC 4306, and I'm not
> > sure if it really brings any benefits?
>=20
> There is no way to send INVALID_IKE_SPI inside IKE SA, as the section
> 3.10 says that the IKE SPI is never sent inside the notification
> payload (For a notification concerning the IKE SA, the SPI Size MUST
> be zero and the field must be empty.) and the IKE SPI is taken from
> the packet. Sending INVALID_IKE_SPI inside IKE SA would mean that the
> IKE SA you are sending the packet inside is invalid...
>=20
> The section 2.21.4 is very clear that INVALID_IKE_SPI MUST NOT be
> cryptographically protected, i.e. it is sent outside the IKE SA.
>=20
> I think the 1st paragraph is quite wrong and the
>=20
>   If the receiving node has an active IKE SA to the IP address from
>   whence the packet came, it MAY send a notification of the wayward
>   packet over that IKE SA in an INFORMATIONAL exchange.
>=20
> part should be removed.
> --
> kivinen@iki.fi

From Pasi.Eronen@nokia.com  Tue Jan 19 03:42:38 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6F583A68F4 for ; Tue, 19 Jan 2010 03:42:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.635
X-Spam-Level: 
X-Spam-Status: No, score=-6.635 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkpJWYFK2Q-r for ; Tue, 19 Jan 2010 03:42:37 -0800 (PST)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id ECBCD3A6A5E for ; Tue, 19 Jan 2010 03:42:36 -0800 (PST)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0JBgRAc007422; Tue, 19 Jan 2010 13:42:29 +0200
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Jan 2010 13:42:13 +0200
Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Jan 2010 13:42:08 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Jan 2010 13:42:03 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Tue, 19 Jan 2010 12:42:03 +0100
From: 
To: , 
Date: Tue, 19 Jan 2010 12:42:02 +0100
Thread-Topic: [IPsec] Issue #143: Rewrite of 1.5
Thread-Index: AcqYsWIlo0hZrmO/SPiqMW6lE1DOlgASsSLw
Message-ID: <808FD6E27AD4884E94820BC333B2DB7758410A9CE7@NOK-EUMSG-01.mgdnok.nokia.com>
References: <064.ab2ff0ca09001764d46ce8c6ea30657a@tools.ietf.org> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 19 Jan 2010 11:42:03.0994 (UTC) FILETIME=[6BB8E3A0:01CA98FC]
X-Nokia-AV: Clean
Subject: Re: [IPsec] Issue #143: Rewrite of 1.5
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 11:42:39 -0000

Paul Hoffman wrote:

> Section 1.5 doesn't read well, and needs a rewrite. Pasi can
> provide text once the substantial issue re: INVALID_IKE_SPI
> is decided.

That substantial issue is #137; assuming it's resolved the way
Tero proposed (and I agree), I'm proposing the following text:

   There are couple of cases when a node receives a packet it cannot
   process, but may want to notify the sender about this situation:

   o  If an ESP or AH packet arrives with an unrecognized SPI, it
      could be because the receiving node has recently crashed and
      lost state or because of some other system malfunction or
      attack.
=20
   o  If an encrypted IKE request packet arrives on port 500 or 4500
      with an unrecognized SPI, it could be because the receiving node
      has recently crashed and lost state or because of some other
      system malfunction or attack.

   o If an IKE request packet arrives with a higher major version
     number than the implementation supports.

   (Note that the first and third cases apply only to IKE request
   packets, not response packets.)

   In the first case, if the receiving node has an active IKE SA to
   the IP address from whence the packet came, it MAY send an
   INVALID_SPI notification of the wayward packet over that IKE SA in
   an INFORMATIONAL exchange. The Notification Data contains the SPI
   of the invalid packet. The recipient of this notification cannot
   tell whether the SPI is for AH or ESP, but this is not important
   because the SPIs are supposed to be different for the two.

   If no suitable IKE SA exists, the node MAY send an INFORMATIONAL
   message without cryptographic protection to the source IP address.
   In this case, it should only be used by the recipient as a "hint"
   that something might be wrong (because it could easily be forged).
   This message is not part of an INFORMATIONAL exchange, and the
   receiving node MUST NOT respond to it (doing so could cause a
   message loop). The message is constructed as follows: There are no
   IKE SPI values that would be meaningful to the recipient of such a
   notification; using zero values or random values are both
   acceptable.  The Initiator flag is set, the Response bit is set to
   0, and the version flags are set in the normal fashion.

   In the second and third cases, the message is always sent without
   cryptographic protection (outside of an IKE SA), and includes
   either INVALID_IKE_SPI or INVALID_MAJOR_VERSION notification (with
   no notification data).  The message is a response message, and thus
   it is sent to the IP address and port from whence it came with the
   same IKE SPIs and the Message ID is copied.  The Response bit is
   set to 1, and the version flags are set in the normal fashion. The
   responder SHOULD copy the Exchange Type from the request.

Best regards,
Pasi

From Pasi.Eronen@nokia.com  Tue Jan 19 03:45:48 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D8963A6823 for ; Tue, 19 Jan 2010 03:45:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.633
X-Spam-Level: 
X-Spam-Status: No, score=-6.633 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tAiKz0lI9iN for ; Tue, 19 Jan 2010 03:45:47 -0800 (PST)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id C6D0D3A68D9 for ; Tue, 19 Jan 2010 03:45:47 -0800 (PST)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0JBjJbr025410; Tue, 19 Jan 2010 05:45:43 -0600
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Jan 2010 13:45:30 +0200
Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Jan 2010 13:45:30 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Jan 2010 13:45:25 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 19 Jan 2010 12:45:25 +0100
From: 
To: , 
Date: Tue, 19 Jan 2010 12:45:24 +0100
Thread-Topic: [IPsec] Issue #134: SAi1 in cookies
Thread-Index: AcqXkDfu0hgLhCWfSVWPU9qBdyTCtQBbJlfw
Message-ID: <808FD6E27AD4884E94820BC333B2DB7758410A9CF6@NOK-EUMSG-01.mgdnok.nokia.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 19 Jan 2010 11:45:25.0867 (UTC) FILETIME=[E40C43B0:01CA98FC]
X-Nokia-AV: Clean
Subject: Re: [IPsec] Issue #134: SAi1 in cookies
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 11:45:48 -0000

I agree with the proposed change.

Best regards,
Pasi

> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
> Of ext Paul Hoffman
> Sent: 17 January, 2010 18:06
> To: IPsecme WG
> Subject: [IPsec] Issue #134: SAi1 in cookies
>=20
> In section 2.6.1 it has text saying:
>=20
> For instance, if
> the responder includes the SAi1 and KEi payloads in cookie calculation,
> it will reject the request by sending a new cookie.
>=20
> which is misleading, as even if SAi1 is included in the cookie, that
> should not cause cookie to be rejected, as the retry behavior for
> INVALID_KE_PAYLOAD says that SAi1 is going to be same (section 2.7
> says: "The initiator MUST again propose its full set of acceptable
> cryptographic suites ..."). IT would be better to remove "SAi1 and"
> from the sentence and only talk about KEi:
>=20
> For instance, if
> the responder includes the KEi payload in cookie calculation, it will
> reject the request by sending a new cookie.
>=20
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

From kivinen@iki.fi  Tue Jan 19 04:00:34 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 902C83A68D9 for ; Tue, 19 Jan 2010 04:00:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.522
X-Spam-Level: 
X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IQRmHF-HMoC for ; Tue, 19 Jan 2010 04:00:33 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 717AC3A6890 for ; Tue, 19 Jan 2010 04:00:33 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0JC0Ppv019738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2010 14:00:25 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0JC0Oxm027984; Tue, 19 Jan 2010 14:00:24 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19285.40664.791802.892678@fireball.kivinen.iki.fi>
Date: Tue, 19 Jan 2010 14:00:24 +0200
From: Tero Kivinen 
To: Paul Hoffman 
In-Reply-To: 
References: <19284.34317.682796.84636@fireball.kivinen.iki.fi> 
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 8 min
X-Total-Time: 9 min
Cc: ipsec@ietf.org
Subject: [IPsec] NAT-T text (was: Re: Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1 forward))
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 12:00:34 -0000

Paul Hoffman writes:
> Also the bullet
> 
>    - Store the original traffic selector IP addresses as real source
>      and destination address in case we need to undo address
>      substitution.
> 
> needs to be changed to
> 
>    - Store the original traffic selector IP addresses as real source
>      and destination address and also in case we need them to undo
>      address substitution.
> 
> [[ Response: That wording doesn't make any sense to me. ]]

There is two reason why original traffic selector IP addresses are
stored: 1) to use as "real source and destination address" as
specified by RFC3948 for TCP/UDP checksum fixup; 2) when they are
needed to undo address substitution in case we need to fall back to
tunnel mode.

The original text only mentioned the second use, not first use, and my
change tried to include both...

Perhaps you can try to write some wording that makes sense...

BTW, the RFC3948 uses term "peer's real source and destination IP
addresses" (section 3.1.2, option 1). The RFC3947 uses therm "Original
Source and Destination Addresses" (section 5.2).
-- 
kivinen@iki.fi

From kivinen@iki.fi  Tue Jan 19 04:03:34 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 373043A688F for ; Tue, 19 Jan 2010 04:03:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.527
X-Spam-Level: 
X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JY1Ro4akDO+1 for ; Tue, 19 Jan 2010 04:03:33 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 016AD3A6846 for ; Tue, 19 Jan 2010 04:03:32 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0JC3Rid019747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2010 14:03:27 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0JC3Rbw008720; Tue, 19 Jan 2010 14:03:27 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19285.40847.855520.352829@fireball.kivinen.iki.fi>
Date: Tue, 19 Jan 2010 14:03:27 +0200
From: Tero Kivinen 
To: Paul Hoffman 
In-Reply-To: 
References: <19284.34317.682796.84636@fireball.kivinen.iki.fi> 
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 2 min
X-Total-Time: 3 min
Cc: ipsec@ietf.org
Subject: [IPsec] HTTP_CERT_LOOKUP_SUPPORTED (was: Re: Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1 forward))
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 12:03:34 -0000

Paul Hoffman writes:
> In section 3.6 we have text which says:
> 
> 	   Certificate payloads SHOULD be included in an exchange if
>    certificates are available to the sender unless the peer has
>    indicated an ability to retrieve this information from elsewhere
>    using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload.  
> 
> which is bit misleading, as even if HTTP_CERT_LOOKUP_SUPPORTED notify
> payload is sent that does not mean peer should leave out all Certificate
> payloads, it just means it should use Hash and URL formats instead of
> sending full certificates.
> 
> Perhaps it should be changed to:
> 
> 	   Certificate payloads SHOULD be included in an exchange if
>    certificates are available to the sender. The Hash and URL formats of
>    the Certificate payloads should be used in case the peer has indicated
>    an ability to retrieve this information from elsewhere using an
>    HTTP_CERT_LOOKUP_SUPPORTED Notify payload.
> 
> [[ Response: The proposed change does not make sense: it sounds like
> a peer SHOULD send *both* the certificates and the hash-and-URL,
> which is silly. ]]

Peer uses certificate payloads to send both full X.509 certificates
and hash-and url "certificates", so yes, when peer uses hash-and-URL
format it is still sending "certificates" inside the certificate
payloads, even though the actual X.509 certificate is not there.

Would this be better:

	   Certificate payloads SHOULD be included in an exchange if
   certificates are available to the sender. The Hash and URL formats
   of the Certificate payloads should be used instead of full X.509
   certificates in case the peer has indicated an ability to retrieve
   this information from elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED
   Notify payload.

(The section 3.6 already notices that term "certificate" is misleading
as not all data is certificates in this payload). 
-- 
kivinen@iki.fi

From kivinen@iki.fi  Tue Jan 19 04:07:13 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCAB83A6A73 for ; Tue, 19 Jan 2010 04:07:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.531
X-Spam-Level: 
X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFTfz2YwlzQK for ; Tue, 19 Jan 2010 04:07:13 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id B20423A6A6E for ; Tue, 19 Jan 2010 04:07:12 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0JC77F7019681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2010 14:07:07 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0JC767A014051; Tue, 19 Jan 2010 14:07:06 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19285.41066.733827.866040@fireball.kivinen.iki.fi>
Date: Tue, 19 Jan 2010 14:07:06 +0200
From: Tero Kivinen 
To: Paul Hoffman 
In-Reply-To: 
References: <19284.34317.682796.84636@fireball.kivinen.iki.fi> 
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 4 min
X-Total-Time: 3 min
Cc: ipsec@ietf.org
Subject: [IPsec] Notify message types (was: Re: Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1 forward))
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 12:07:14 -0000

Paul Hoffman writes:
> Section "3.10.1.  Notify Message Types" should include:
> 
> 
>    TEMPORARY_FAILURE		 {TBA1}
>        See section 2.25.
> 
>    CHILD_SA_NOT_FOUND		 {TBA2}
>        See section 2.25.
> 
> [[ Response: Can't do that: the WG decided we have to leave the
> tables with the values defined in RFC 4306. Those two are, of
> course, listed in the IANA considerations. ]] 

I do not think we agreed on that. We agreed that we do not add any
values defined on other documents (i.e. AES-GCM etc).

I do not think we agreed that we should not update the table to
include the numbers defined in THIS document.

I think it would be better to have the table in 3.10.1 to be complete
set of notify message types which are used by this document. It does
not need to include notify message types from other documents or new
extensions, but it should include everything which is defined in this
document. 
-- 
kivinen@iki.fi

From kivinen@iki.fi  Tue Jan 19 04:12:46 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E43623A67AD for ; Tue, 19 Jan 2010 04:12:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.535
X-Spam-Level: 
X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDqLspMuUU+v for ; Tue, 19 Jan 2010 04:12:45 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id B6F5C3A68F7 for ; Tue, 19 Jan 2010 04:12:44 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0JCCcsL029005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2010 14:12:38 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0JCCcV1004670; Tue, 19 Jan 2010 14:12:38 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19285.41398.297890.458286@fireball.kivinen.iki.fi>
Date: Tue, 19 Jan 2010 14:12:38 +0200
From: Tero Kivinen 
To: Paul Hoffman 
In-Reply-To: 
References: <19284.34317.682796.84636@fireball.kivinen.iki.fi> 
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 5 min
X-Total-Time: 5 min
Cc: ipsec@ietf.org
Subject: [IPsec] Section 1.7 (Was Re: Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1 forward))
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 12:12:46 -0000

Paul Hoffman writes:
> Following things might or might not need to be added to section 1.7
> (taken from appendix E):
> 
> [[ Response: I included only some of those. 1.7 is not meant to be
> exhaustive: it can't be. But I did add a bunch you had suggested
> that I had missed on my pass. ]] 

Can you send new 1.7 (or at least list which entries you included, and
which you left out) before putting out new version so we can see which
one you included.

Some of those are important some are not, and I included in my list
all that I tough might be important enough to be mentioned (and yes, I
agree not all of them needs to be there, but those were entries I
assumed someone might think needs to be there, so I think it might be
good idea to get comments now, not only after next revision).

BTW, you didn't anwer to my question what is the intended relationship
between "Appendix D. Significant Changes from RFC 4306" and " 1.7.
Differences Between RFC 4306 and This Document"?

Are you going to remove one of them, or is the 1.7 going to list
only significant changes and Appendix D more changes (including not so
significant). 
-- 
kivinen@iki.fi

From kivinen@iki.fi  Tue Jan 19 04:32:04 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03DC53A6A74 for ; Tue, 19 Jan 2010 04:32:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.539
X-Spam-Level: 
X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4f-zE6UpaQM for ; Tue, 19 Jan 2010 04:32:03 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id C065F3A68D9 for ; Tue, 19 Jan 2010 04:32:02 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0JCVtcQ016629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2010 14:31:55 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0JCVt40017670; Tue, 19 Jan 2010 14:31:55 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19285.42555.180251.23550@fireball.kivinen.iki.fi>
Date: Tue, 19 Jan 2010 14:31:55 +0200
From: Tero Kivinen 
To: 
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7758410A9BC5@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB7758410A9BC5@NOK-EUMSG-01.mgdnok.nokia.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 10 min
X-Total-Time: 11 min
Cc: ipsec@ietf.org
Subject: [IPsec] Flags in header (was:  IKEv2bis, comments about sections 3-)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 12:32:04 -0000

Pasi.Eronen@nokia.com writes:
> - Section 3.1: "The bits are defined LSB first, so bit 0 would be the
> least significant bit of the Flags octet." This seems to be exactly
> the opposite of the bit numbering used in the figure above, which
> sounds confusing. Instead of using numbers, we should just show a
> diagram?
> 
>     0 1 2 3 4 5 6 7 
>    +-+-+-+-+-+-+-+-+
>    |X X|R|V|I|X X X|
>    +-+-+-+-+-+-+-+-+

So you are suggesting that we change the bit order to use MSB instead
of LSB as it is now? It might be better to get rid of bit numbers
completely then and put the separate flags to the main figure:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       IKE SA Initiator's SPI                  |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       IKE SA Responder's SPI                  |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Payload | MjVer | MnVer | Exchange Type |X|X|R|V|I|X|X|X|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Message ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Length                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 4:  IKE Header Format

and remove the whole bit numbering mess.

Note, that this bit order thing has been inherited from the RFC2408
which also used MSB bit order when showing figures having 32 bits
words, but used LSB bit order when actually counting bits inside the
octect.

BTW, your format confused me as I am so used to talking about bit 0
when I am talking about the lowest bit of the octect (i.e the one you
get by doing (octect & 1)).

I would actually prefer to keep the text as it is now, even though it
is not consistent with the bit order in 32-bit figures and the bit
order in the text, but at least it clearly defines the bit order.
-- 
kivinen@iki.fi

From kivinen@iki.fi  Tue Jan 19 04:45:05 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D49993A6846 for ; Tue, 19 Jan 2010 04:45:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.542
X-Spam-Level: 
X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-l7AcmAc3Vg for ; Tue, 19 Jan 2010 04:45:02 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id BA0373A6982 for ; Tue, 19 Jan 2010 04:44:57 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0JCiqqc019575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2010 14:44:52 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0JCioDJ018134; Tue, 19 Jan 2010 14:44:50 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19285.43330.296567.83100@fireball.kivinen.iki.fi>
Date: Tue, 19 Jan 2010 14:44:50 +0200
From: Tero Kivinen 
To: 
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7758410A9CE7@NOK-EUMSG-01.mgdnok.nokia.com>
References: <064.ab2ff0ca09001764d46ce8c6ea30657a@tools.ietf.org>  <808FD6E27AD4884E94820BC333B2DB7758410A9CE7@NOK-EUMSG-01.mgdnok.nokia.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 4 min
X-Total-Time: 8 min
Cc: ipsec@ietf.org, paul.hoffman@vpnc.org
Subject: Re: [IPsec] Issue #143: Rewrite of 1.5
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 12:45:05 -0000

Pasi.Eronen@nokia.com writes:
>    There are couple of cases when a node receives a packet it cannot
>    process, but may want to notify the sender about this situation:
> 
>    o  If an ESP or AH packet arrives with an unrecognized SPI, it
>       could be because the receiving node has recently crashed and
>       lost state or because of some other system malfunction or
>       attack.
>  
>    o  If an encrypted IKE request packet arrives on port 500 or 4500
>       with an unrecognized SPI, it could be because the receiving node
>       has recently crashed and lost state or because of some other
>       system malfunction or attack.
> 
>    o If an IKE request packet arrives with a higher major version
>      number than the implementation supports.
> 
>    (Note that the first and third cases apply only to IKE request
>    packets, not response packets.)

The first case applies to ESP or AH packets, so this text should apply
only to the last two cases.

>    In the first case, if the receiving node has an active IKE SA to
>    the IP address from whence the packet came, it MAY send an
>    INVALID_SPI notification of the wayward packet over that IKE SA in
>    an INFORMATIONAL exchange. The Notification Data contains the SPI
>    of the invalid packet. The recipient of this notification cannot
>    tell whether the SPI is for AH or ESP, but this is not important
>    because the SPIs are supposed to be different for the two.
> 
>    If no suitable IKE SA exists, the node MAY send an INFORMATIONAL
>    message without cryptographic protection to the source IP address.
>    In this case, it should only be used by the recipient as a "hint"
>    that something might be wrong (because it could easily be forged).
>    This message is not part of an INFORMATIONAL exchange, and the
>    receiving node MUST NOT respond to it (doing so could cause a
>    message loop). The message is constructed as follows: There are no
>    IKE SPI values that would be meaningful to the recipient of such a
>    notification; using zero values or random values are both
>    acceptable.  The Initiator flag is set, the Response bit is set to
>    0, and the version flags are set in the normal fashion.

This is against the text in the section 3.1 which says:

   o  Initiator's SPI (8 octets) - A value chosen by the initiator to
      identify a unique IKE security association.  This value MUST NOT
      be zero.

Was that intentional, i.e. can both the Initiator's and responder's
SPIs be zero?

>    In the second and third cases, the message is always sent without
>    cryptographic protection (outside of an IKE SA), and includes
>    either INVALID_IKE_SPI or INVALID_MAJOR_VERSION notification (with
>    no notification data).  The message is a response message, and thus
>    it is sent to the IP address and port from whence it came with the
>    same IKE SPIs and the Message ID is copied.  The Response bit is
>    set to 1, and the version flags are set in the normal fashion. The
>    responder SHOULD copy the Exchange Type from the request.

Otherwise the text looked good.
-- 
kivinen@iki.fi

From Pasi.Eronen@nokia.com  Tue Jan 19 05:00:57 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D10A3A67EF for ; Tue, 19 Jan 2010 05:00:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.632
X-Spam-Level: 
X-Spam-Status: No, score=-6.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxCcji7HLPVg for ; Tue, 19 Jan 2010 05:00:56 -0800 (PST)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 2E47E3A6A87 for ; Tue, 19 Jan 2010 05:00:56 -0800 (PST)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0JD0Kll020966; Tue, 19 Jan 2010 15:00:49 +0200
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Jan 2010 15:00:48 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Jan 2010 15:00:43 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 19 Jan 2010 14:00:43 +0100
From: 
To: 
Date: Tue, 19 Jan 2010 14:00:42 +0100
Thread-Topic: [IPsec] Issue #143: Rewrite of 1.5
Thread-Index: AcqZBUKM5fJ1lh9nTse2pW9hhVMStwAAQoKA
Message-ID: <808FD6E27AD4884E94820BC333B2DB7758410A9DE6@NOK-EUMSG-01.mgdnok.nokia.com>
References: <064.ab2ff0ca09001764d46ce8c6ea30657a@tools.ietf.org>  <808FD6E27AD4884E94820BC333B2DB7758410A9CE7@NOK-EUMSG-01.mgdnok.nokia.com> <19285.43330.296567.83100@fireball.kivinen.iki.fi>
In-Reply-To: <19285.43330.296567.83100@fireball.kivinen.iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 19 Jan 2010 13:00:43.0983 (UTC) FILETIME=[690E0DF0:01CA9907]
X-Nokia-AV: Clean
Cc: ipsec@ietf.org, paul.hoffman@vpnc.org
Subject: Re: [IPsec] Issue #143: Rewrite of 1.5
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 13:00:57 -0000

Tero Kivinen wrote:

> Pasi.Eronen@nokia.com writes:
> >    There are couple of cases when a node receives a packet it cannot
> >    process, but may want to notify the sender about this situation:
> >
> >    o  If an ESP or AH packet arrives with an unrecognized SPI, it
> >       could be because the receiving node has recently crashed and
> >       lost state or because of some other system malfunction or
> >       attack.
> >
> >    o  If an encrypted IKE request packet arrives on port 500 or 4500
> >       with an unrecognized SPI, it could be because the receiving
> >       node
> >       has recently crashed and lost state or because of some other
> >       system malfunction or attack.
> >
> >    o If an IKE request packet arrives with a higher major version
> >      number than the implementation supports.
> >
> >    (Note that the first and third cases apply only to IKE request
> >    packets, not response packets.)
>=20
> The first case applies to ESP or AH packets, so this text should apply
> only to the last two cases.

Quite right, this should be "second and third".

> >    In the first case, if the receiving node has an active IKE SA to
> >    the IP address from whence the packet came, it MAY send an
> >    INVALID_SPI notification of the wayward packet over that IKE SA in
> >    an INFORMATIONAL exchange. The Notification Data contains the SPI
> >    of the invalid packet. The recipient of this notification cannot
> >    tell whether the SPI is for AH or ESP, but this is not important
> >    because the SPIs are supposed to be different for the two.
> >
> >    If no suitable IKE SA exists, the node MAY send an INFORMATIONAL
> >    message without cryptographic protection to the source IP address.
> >    In this case, it should only be used by the recipient as a "hint"
> >    that something might be wrong (because it could easily be forged).
> >    This message is not part of an INFORMATIONAL exchange, and the
> >    receiving node MUST NOT respond to it (doing so could cause a
> >    message loop). The message is constructed as follows: There are no
> >    IKE SPI values that would be meaningful to the recipient of such a
> >    notification; using zero values or random values are both
> >    acceptable.  The Initiator flag is set, the Response bit is set to
> >    0, and the version flags are set in the normal fashion.
>=20
> This is against the text in the section 3.1 which says:
>=20
>    o  Initiator's SPI (8 octets) - A value chosen by the initiator to
>       identify a unique IKE security association.  This value MUST NOT
>       be zero.
>=20
> Was that intentional, i.e. can both the Initiator's and responder's
> SPIs be zero?

I didn't change this part; the text has been there since the first
draft (and is also in RFC 4718, section 7.7). Here's what 4718 said:

   In case of INVALID_SPI, however, there are no IKE SPI values that
   would be meaningful to the recipient of such a notification.  Also,
   the message sent is now an INFORMATIONAL request.  A strict
   interpretation of the specification would require the sender to
   invent garbage values for the SPI fields.  However, we think this
   was not the intention, and using zero values is acceptable.

   (References: "INVALID_IKE_SPI" thread, June 2005.)

Since the value will be anyway meaningless to the recipient, I don't
think it matters what it is; so I would propose we leave this as-is.

> >    In the second and third cases, the message is always sent
> >    without cryptographic protection (outside of an IKE SA), and
> >    includes either INVALID_IKE_SPI or INVALID_MAJOR_VERSION
> >    notification (with no notification data).  The message is a
> >    response message, and thus it is sent to the IP address and
> >    port from whence it came with the same IKE SPIs and the Message
> >    ID is copied.  The Response bit is set to 1, and the version
> >    flags are set in the normal fashion. The responder SHOULD copy
> >    the Exchange Type from the request.
>=20
> Otherwise the text looked good.

Thanks for checking this!

Best regards,
Pasi


From Pasi.Eronen@nokia.com  Tue Jan 19 05:04:31 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F133A3A6949 for ; Tue, 19 Jan 2010 05:04:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.631
X-Spam-Level: 
X-Spam-Status: No, score=-6.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+jLGsX6q1CW for ; Tue, 19 Jan 2010 05:04:31 -0800 (PST)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id BC7B03A67EF for ; Tue, 19 Jan 2010 05:04:30 -0800 (PST)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0JD4Fhm000768; Tue, 19 Jan 2010 15:04:24 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Jan 2010 15:03:11 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Jan 2010 15:03:11 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 19 Jan 2010 14:03:10 +0100
From: 
To: 
Date: Tue, 19 Jan 2010 14:03:08 +0100
Thread-Topic: [IPsec] Flags in header (was:  IKEv2bis, comments about sections 3-)
Thread-Index: AcqZA3CNg3uZcvczSO23oaGKJygLGwABAQOw
Message-ID: <808FD6E27AD4884E94820BC333B2DB7758410A9DEA@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB7758410A9BC5@NOK-EUMSG-01.mgdnok.nokia.com> <19285.42555.180251.23550@fireball.kivinen.iki.fi>
In-Reply-To: <19285.42555.180251.23550@fireball.kivinen.iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 19 Jan 2010 13:03:11.0383 (UTC) FILETIME=[C0E98270:01CA9907]
X-Nokia-AV: Clean
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Flags in header (was:  IKEv2bis, comments about sections 3-)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 13:04:32 -0000

Removing the whole bit numbering mess, and showing the flags
in the main figure as you suggest, sounds good to me.

(But since nobody has noticed this before -- AFAIK, at least --
perhaps leaving this as-is would also be acceptable...)

Best regards,
Pasi

> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
> Of ext Tero Kivinen
> Sent: 19 January, 2010 14:32
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: ipsec@ietf.org
> Subject: [IPsec] Flags in header (was: IKEv2bis, comments about
> sections 3-)
>=20
> Pasi.Eronen@nokia.com writes:
> > - Section 3.1: "The bits are defined LSB first, so bit 0 would be the
> > least significant bit of the Flags octet." This seems to be exactly
> > the opposite of the bit numbering used in the figure above, which
> > sounds confusing. Instead of using numbers, we should just show a
> > diagram?
> >
> >     0 1 2 3 4 5 6 7
> >    +-+-+-+-+-+-+-+-+
> >    |X X|R|V|I|X X X|
> >    +-+-+-+-+-+-+-+-+
>=20
> So you are suggesting that we change the bit order to use MSB instead
> of LSB as it is now? It might be better to get rid of bit numbers
> completely then and put the separate flags to the main figure:
>=20
>                         1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                       IKE SA Initiator's SPI                  |
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                       IKE SA Responder's SPI                  |
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  Next Payload | MjVer | MnVer | Exchange Type |X|X|R|V|I|X|X|X|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                          Message ID                           |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                            Length                             |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
>                     Figure 4:  IKE Header Format
>=20
> and remove the whole bit numbering mess.
>=20
> Note, that this bit order thing has been inherited from the RFC2408
> which also used MSB bit order when showing figures having 32 bits
> words, but used LSB bit order when actually counting bits inside the
> octect.
>=20
> BTW, your format confused me as I am so used to talking about bit 0
> when I am talking about the lowest bit of the octect (i.e the one you
> get by doing (octect & 1)).
>=20
> I would actually prefer to keep the text as it is now, even though it
> is not consistent with the bit order in 32-bit figures and the bit
> order in the text, but at least it clearly defines the bit order.
> --
> kivinen@iki.fi
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

From kivinen@iki.fi  Tue Jan 19 05:47:05 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 561FB3A6A8B for ; Tue, 19 Jan 2010 05:47:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.545
X-Spam-Level: 
X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NNa4PGfceK8 for ; Tue, 19 Jan 2010 05:47:04 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 2149F3A6A7B for ; Tue, 19 Jan 2010 05:47:03 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0JDktQs028537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2010 15:46:55 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0JDksIi001351; Tue, 19 Jan 2010 15:46:54 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19285.47054.324974.228538@fireball.kivinen.iki.fi>
Date: Tue, 19 Jan 2010 15:46:54 +0200
From: Tero Kivinen 
To: Paul Hoffman 
In-Reply-To: 
References: 
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 16 min
X-Total-Time: 45 min
Cc: IPsecme WG 
Subject: [IPsec] Payload order section number (Re: Reviews of section 1 and 2 of the draft-ietf-ipsecme-ikev2)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 13:47:05 -0000

Paul Hoffman writes:
> Section 1.3.1 now talks about the USE_TRANSPORT_MODE,
> ESP_TFC_PADDING_NOT_SUPPORTED and NON_FIRST_FRAMENTS_ALSO notifications,
> and says they can be included, but the packet figure does not include
> them. Adding them to the figure would be easy, but the problem is that we
> currently say that you should follow the order of payloads from the
> figures (altough we do refer to section 2 not section 1, but this is one
> of the open issues).
> 
> So depending what we decided on the payload order and figures, it might
> be better to add one extra ", [N]" to the figure before SA payload.
> 
> [[ Response: It is not an open issue. The spec says "implementations
> MUST NOT reject as invalid a message with those payloads in any
> other order". Thus, putting the "[N]" in the figure is likely to be
> more confusing than helpful because [N] can appear in almost *any*
> of the figures. ]]

Yes [N] Can appear in any figure.

On the other hand we are now talking about Notification payloads in
the section 1.3.1 and the figures don't show them at all, which can
cause confusion.

BTW, so we are going to leave the reference to point to only section 2
in the end of section 2.5?

Section 2 used to have only very few figures, i.e. the one in 2.6 (IKE
SA SPIs and Cookies), 2.16 EAP, 2.19 requesting IP-address from remote
network, and 2.20 requesting peer's version.

Now we have some more figures in section 2 covering those exchange
collision etc cases, but all the important base figures are in section
1. I think we had ticket about this, but cannot seem to find it now.

We did have #16 and #45 which covered the order, but they didn't talk
about whether it should refer section 2 or section 1 (or both) for the
figures, so I guess we didn't have ticket about this.
-- 
kivinen@iki.fi

From kivinen@iki.fi  Tue Jan 19 05:52:20 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 369233A6A7B for ; Tue, 19 Jan 2010 05:52:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.547
X-Spam-Level: 
X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNdDh3cECdqF for ; Tue, 19 Jan 2010 05:52:19 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id EBBBA3A6A76 for ; Tue, 19 Jan 2010 05:52:18 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0JDqDeu022211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2010 15:52:13 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0JDqDtE021042; Tue, 19 Jan 2010 15:52:13 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19285.47373.156742.582007@fireball.kivinen.iki.fi>
Date: Tue, 19 Jan 2010 15:52:13 +0200
From: Tero Kivinen 
To: Paul Hoffman 
In-Reply-To: 
References: 
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 5 min
X-Total-Time: 5 min
Cc: IPsecme WG 
Subject: [IPsec] Issue #9, and section 1.3.1 (Re: Reviews of section 1 and 2 of the draft-ietf-ipsecme-ikev2)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 13:52:20 -0000

Paul Hoffman writes:
> Also the section 1.3.1 has text which perhaps should be removed:
> 
>    Failure of an attempt to create a Child SA SHOULD NOT tear down the
>    IKE SA: there is no reason to lose the work done to set up the IKE
>    SA.  When an IKE SA is not created, the error message return SHOULD
>    NOT be encrypted because the other party will not be able to
>    authenticate that message.  See Section 2.21 for a list of error
>    messages that might occur if creating a Child SA fails.
> 
> This section 1.3.1 is talking about the CREATE_CHILD_SA not initial
> IKE_AUTH, thus this section is not needed here. The section 1.2 already
> has text about the Child SA failing during the initial exchange, so this
> how paragaraph needs to be removed.
> 
> [[ Response: This text was specifically added by the WG to deal with
> creating SAs, not with IKE_AUTH. This was Issue #9, which you
> initiated. ]] 

Issue #9 covered only IKE_AUTH case and IKE SA creation in general ,
it didn't talk anything about the Child SA creation case.

Section 1.3.1 only talks about the creating Child SAs using
CREATE_CHILD_SA exchange. It does not cover creating IKE SA (i.e.
IKE_AUTH) at all.

We already have the text we need in the 1.2 we do not need to have
this text here, especially as it is very misleading.

The first sentence is only thing that is really correct about the
paragraph and even that should be obvious.

The rest starting talking about "When an IKE SA is not created" is
completely out of place, as this section does not talk about IKE SA
creation. 
-- 
kivinen@iki.fi

From kivinen@iki.fi  Tue Jan 19 05:57:50 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 417193A685B for ; Tue, 19 Jan 2010 05:57:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level: 
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cY7Ab7k3knW4 for ; Tue, 19 Jan 2010 05:57:49 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 1A3BD3A6846 for ; Tue, 19 Jan 2010 05:57:48 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0JDvh6e001334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2010 15:57:43 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0JDvhQx017611; Tue, 19 Jan 2010 15:57:43 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19285.47703.188331.573852@fireball.kivinen.iki.fi>
Date: Tue, 19 Jan 2010 15:57:43 +0200
From: Tero Kivinen 
To: Paul Hoffman 
In-Reply-To: 
References: 
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 3 min
X-Total-Time: 2 min
Cc: IPsecme WG 
Subject: [IPsec] Section 2.8 (Re: Reviews of section 1 and 2 of the	draft-ietf-ipsecme-ikev2)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 13:57:50 -0000

Paul Hoffman writes:
> XX In section 2.8 the sentence:
> 
> 	   Note that, when
>    rekeying, the new Child SA SHOULD NOT have different traffic
>    selectors and algorithms than the old one.
> 
> is in wrong place, it is after the paragraph talking about IKE SA rekey,
> it should be moved to the previous paragraph talking about Child SA
> rekeying.
> 
> [[ Response: It looks like the sentence is, in fact, in the right
> place. The whole paragraph reads: "To rekey a Child SA within an
> existing IKE SA, create a new, equivalent SA (see Section 2.17
> below), and when the new one is established, delete the old one.
> Note that, when rekeying, the new Child SA SHOULD NOT have different
> traffic selectors and algorithms than the old one." That is, indeed,
> talking about rekeying a Child SA. ]]

That text you quoted is not from the
draft-ietf-ipsecme-ikev2bis-06.txt, so I assume you have already fixed
this bug.

The text from draft-ietf-ipsecme-ikev2bis-06 says:

   To rekey a Child SA within an existing IKE SA, create a new,
   equivalent SA (see Section 2.17 below), and when the new one is
   established, delete the old one.

   To rekey an IKE SA, establish a new equivalent IKE SA (see
   Section 2.18 below) with the peer to whom the old IKE SA is shared
   using a CREATE_CHILD_SA within the existing IKE SA.  An IKE SA so
   created inherits all of the original IKE SA's Child SAs, and the new
   IKE SA is used for all control messages needed to maintain those
   Child SAs.  After the new equivalent IKE SA is created, the initiator
   deletes the old IKE SA, and the Delete payload to delete itself MUST
   be the last request sent over the old IKE SA.  Note that, when
   rekeying, the new Child SA SHOULD NOT have different traffic
   selectors and algorithms than the old one.

and here you can see that the last sentence of the last paragraph is
in wrong place. I assume you have already moved the sentence to the end
of previous paragraph earlier. 
-- 
kivinen@iki.fi

From kivinen@iki.fi  Tue Jan 19 06:01:56 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCAFD3A691B for ; Tue, 19 Jan 2010 06:01:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+966nDd0PKl for ; Tue, 19 Jan 2010 06:01:55 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 5D0463A6846 for ; Tue, 19 Jan 2010 06:01:55 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0JE1oLw014809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2010 16:01:50 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0JE1oZZ023593; Tue, 19 Jan 2010 16:01:50 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19285.47950.159235.173118@fireball.kivinen.iki.fi>
Date: Tue, 19 Jan 2010 16:01:50 +0200
From: Tero Kivinen 
To: Paul Hoffman 
In-Reply-To: 
References: 
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 3 min
X-Total-Time: 3 min
Cc: IPsecme WG 
Subject: [IPsec] FAILED_CP_REQUIRED (Re: Reviews of section 1 and 2 of the	draft-ietf-ipsecme-ikev2)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 14:01:56 -0000

Paul Hoffman writes:
> In section 2.19 there is FAILED_CP_REQUIRED text twice:
> 
>    The FAILED_CP_REQUIRED notification is sent by responder in the case
>    where CP(CFG_REQUEST) was expected but not received, and so is a
>    conflict with locally configured policy.  There is no associated
>    data.
> 
>    The responder MUST NOT send a CFG_REPLY without having first received
>    a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS
>    to perform an unnecessary configuration lookup if the IRAC cannot
>    process the REPLY.  In the case where the IRAS's configuration
>    requires that CP be used for a given identity IDi, but IRAC has
>    failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and
>    terminate the IKE exchange with a FAILED_CP_REQUIRED error.  The
>    FAILED_CP_REQUIRED is not fatal to the IKE SA; it simply causes the
>    Child SA creation fail.  The initiator can fix this by later starting
>    a new configuration payload request.
> 
> I think the first paragraph should be removed and second one splitted and
> changed to::
> 
>    The responder MUST NOT send a CFG_REPLY without having first received
>    a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS
>    to perform an unnecessary configuration lookup if the IRAC cannot
>    process the REPLY.
> 
>    In the case where the IRAS's configuration requires that CP be used
>    for a given identity IDi, but IRAC has failed to send a
>    CP(CFG_REQUEST), IRAS MUST fail the request, and terminate the Child
>    SA creation with a FAILED_CP_REQUIRED error. The FAILED_CP_REQUIRED is
>    not fatal to the IKE SA; it simply causes the Child SA creation fail.
>    The initiator can fix this by later starting a new configuration
>    payload request. There is no associated data in the FAILED_CP_REQUIRED
>    error.
> 
> (Changed "terminate the IKE exchange" to "terminate the Child SA
> creation" and added text about the associated data).
> 
> [[ Response: The two uses of FAILED_CP_REQUIRED are different and
> therefore should both be left in. ]]

I do not think they are different cases. 

The first one uses word "responder" instead of "IRAS" but they are
talking about the exactly same case. I.e. when the client (initiator,
IRAC) do not send CP(CFG_REQUEST) in its packet, but the server
(responder, IRAS) requires it to be sent, and thats why the server
(responder, IRAS) returns FAILED_CP_REQUIRED error notification back
to the client (initiator, IRAC). 

If you think those two cases in the two paragraphs are really
different, can you explain what is the difference between them?
-- 
kivinen@iki.fi

From kivinen@iki.fi  Tue Jan 19 06:07:18 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D03E03A6A76 for ; Tue, 19 Jan 2010 06:07:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.554
X-Spam-Level: 
X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRZpJvV+Islu for ; Tue, 19 Jan 2010 06:07:18 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 9C9103A6A5F for ; Tue, 19 Jan 2010 06:07:17 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0JE7CBA022863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2010 16:07:12 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0JE7BDf028567; Tue, 19 Jan 2010 16:07:11 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19285.48271.313543.281841@fireball.kivinen.iki.fi>
Date: Tue, 19 Jan 2010 16:07:11 +0200
From: Tero Kivinen 
To: 
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7758410A9DE6@NOK-EUMSG-01.mgdnok.nokia.com>
References: <064.ab2ff0ca09001764d46ce8c6ea30657a@tools.ietf.org>  <808FD6E27AD4884E94820BC333B2DB7758410A9CE7@NOK-EUMSG-01.mgdnok.nokia.com> <19285.43330.296567.83100@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7758410A9DE6@NOK-EUMSG-01.mgdnok.nokia.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 5 min
X-Total-Time: 4 min
Cc: ipsec@ietf.org, paul.hoffman@vpnc.org
Subject: Re: [IPsec] Issue #143: Rewrite of 1.5
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 14:07:18 -0000

Pasi.Eronen@nokia.com writes:
> > This is against the text in the section 3.1 which says:
> > 
> >    o  Initiator's SPI (8 octets) - A value chosen by the initiator to
> >       identify a unique IKE security association.  This value MUST NOT
> >       be zero.
> > 
> > Was that intentional, i.e. can both the Initiator's and responder's
> > SPIs be zero?
> 
> I didn't change this part; the text has been there since the first
> draft (and is also in RFC 4718, section 7.7). Here's what 4718 said:
> 
>    In case of INVALID_SPI, however, there are no IKE SPI values that
>    would be meaningful to the recipient of such a notification.  Also,
>    the message sent is now an INFORMATIONAL request.  A strict
>    interpretation of the specification would require the sender to
>    invent garbage values for the SPI fields.  However, we think this
>    was not the intention, and using zero values is acceptable.
> 
>    (References: "INVALID_IKE_SPI" thread, June 2005.)
> 
> Since the value will be anyway meaningless to the recipient, I don't
> think it matters what it is; so I would propose we leave this as-is.

Should we note something that we know this is against MUST in section
3.1, but sending zero initiator SPI is still ok?

The problem I have with this text, is that I know that some day
someone will come to me and ask me to explain why we send zero
initiator SPI when sending these error notifications even when there
is text saying that initiator SPI MUST NOT be zero...

(and yes, I am used to explaining things already saying that "this is
because the document is internally inconsistent" :-)

The text in RFC4718 at least brings this issue out, the text put to
the ikev2bis is silent about the internal inconsistency.
-- 
kivinen@iki.fi

From smoonen@us.ibm.com  Tue Jan 19 06:12:39 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5EBA3A6942; Tue, 19 Jan 2010 06:12:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.418
X-Spam-Level: 
X-Spam-Status: No, score=-5.418 tagged_above=-999 required=5 tests=[AWL=1.180,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nKvQG+PVhme; Tue, 19 Jan 2010 06:12:38 -0800 (PST)
Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by core3.amsl.com (Postfix) with ESMTP id 32B353A67F0; Tue, 19 Jan 2010 06:12:38 -0800 (PST)
Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id o0JE9Crg019250; Tue, 19 Jan 2010 07:09:12 -0700
Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o0JEC7X0088868; Tue, 19 Jan 2010 07:12:07 -0700
Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o0JEC7aO008401; Tue, 19 Jan 2010 07:12:07 -0700
Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av02.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o0JEC6jh008370; Tue, 19 Jan 2010 07:12:06 -0700
In-Reply-To: <19285.41066.733827.866040@fireball.kivinen.iki.fi>
References: <19284.34317.682796.84636@fireball.kivinen.iki.fi>	 <19285.41066.733827.866040@fireball.kivinen.iki.fi>
To: Tero Kivinen 
MIME-Version: 1.0
X-KeepSent: 5D1F4675:6FFE2DAE-852576B0:004DC33E; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009
From: Scott C Moonen 
X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/19/2010 09:09:40 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/19/2010 09:09:40 AM, Serialize complete at 01/19/2010 09:09:40 AM, S/MIME Sign failed at 01/19/2010 09:09:40 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 01/19/2010 07:12:06, Serialize complete at 01/19/2010 07:12:06
Message-ID: 
Date: Tue, 19 Jan 2010 09:12:05 -0500
Content-Type: multipart/alternative; boundary="=_alternative 004DCA0C852576B0_="
Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, Paul Hoffman 
Subject: Re: [IPsec] Notify message types (was: Re: Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1 forward))
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 14:12:39 -0000

This is a multipart message in MIME format.
--=_alternative 004DCA0C852576B0_=
Content-Type: text/plain; charset="US-ASCII"

> I think it would be better to have the table in 3.10.1 to be complete
> set of notify message types which are used by this document. It does
> not need to include notify message types from other documents or new
> extensions, but it should include everything which is defined in this
> document. 

Agree.

Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen



From:
Tero Kivinen 
To:
Paul Hoffman 
Cc:
ipsec@ietf.org
Date:
01/19/2010 07:08 AM
Subject:
[IPsec] Notify message types (was: Re: Review of rest of 
draft-ietf-ipsecme-ikev2 (section 2.23.1 forward))



Paul Hoffman writes:
> Section "3.10.1.  Notify Message Types" should include:
> 
> 
>    TEMPORARY_FAILURE                            {TBA1}
>        See section 2.25.
> 
>    CHILD_SA_NOT_FOUND                           {TBA2}
>        See section 2.25.
> 
> [[ Response: Can't do that: the WG decided we have to leave the
> tables with the values defined in RFC 4306. Those two are, of
> course, listed in the IANA considerations. ]] 

I do not think we agreed on that. We agreed that we do not add any
values defined on other documents (i.e. AES-GCM etc).

I do not think we agreed that we should not update the table to
include the numbers defined in THIS document.

I think it would be better to have the table in 3.10.1 to be complete
set of notify message types which are used by this document. It does
not need to include notify message types from other documents or new
extensions, but it should include everything which is defined in this
document. 
-- 
kivinen@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec



--=_alternative 004DCA0C852576B0_=
Content-Type: text/html; charset="US-ASCII"



> I think it would be better to have the table
in 3.10.1 to be complete

> set of notify message types which are used by this document. It does

> not need to include notify message types from other documents or new

> extensions, but it should include everything which is defined in this

> document. 



Agree.



Scott Moonen (smoonen@us.ibm.com)

z/OS Communications Server TCP/IP Development

http://www.linkedin.com/in/smoonen










From:
Tero Kivinen <kivinen@iki.fi>


To:
Paul Hoffman <paul.hoffman@vpnc.org>


Cc:
ipsec@ietf.org


Date:
01/19/2010 07:08 AM


Subject:
[IPsec] Notify message types (was: Re:
Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1 forward))










Paul Hoffman writes:

> Section "3.10.1.  Notify Message Types" should include:

> 

> 

>    TEMPORARY_FAILURE        
                 
        {TBA1}

>        See section 2.25.

> 

>    CHILD_SA_NOT_FOUND        
                 
        {TBA2}

>        See section 2.25.

> 

> [[ Response: Can't do that: the WG decided we have to leave the

> tables with the values defined in RFC 4306. Those two are, of

> course, listed in the IANA considerations. ]] 



I do not think we agreed on that. We agreed that we do not add any

values defined on other documents (i.e. AES-GCM etc).



I do not think we agreed that we should not update the table to

include the numbers defined in THIS document.



I think it would be better to have the table in 3.10.1 to be complete

set of notify message types which are used by this document. It does

not need to include notify message types from other documents or new

extensions, but it should include everything which is defined in this

document. 

-- 

kivinen@iki.fi

_______________________________________________

IPsec mailing list

IPsec@ietf.org

https://www.ietf.org/mailman/listinfo/ipsec






--=_alternative 004DCA0C852576B0_=--

From Pasi.Eronen@nokia.com  Tue Jan 19 12:54:16 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A6D93A6801 for ; Tue, 19 Jan 2010 12:54:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.628
X-Spam-Level: 
X-Spam-Status: No, score=-6.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDforpgAFUPz for ; Tue, 19 Jan 2010 12:54:15 -0800 (PST)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 10ED23A67F7 for ; Tue, 19 Jan 2010 12:54:14 -0800 (PST)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0JKrx2L025749; Tue, 19 Jan 2010 22:54:08 +0200
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Jan 2010 22:54:03 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Jan 2010 22:53:58 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Tue, 19 Jan 2010 21:53:57 +0100
From: 
To: 
Date: Tue, 19 Jan 2010 21:53:56 +0100
Thread-Topic: [IPsec] Issue #143: Rewrite of 1.5
Thread-Index: AcqZEMMQtmKTyEj7Q42NAYbmRATskAAODDSw
Message-ID: <808FD6E27AD4884E94820BC333B2DB7758410AA187@NOK-EUMSG-01.mgdnok.nokia.com>
References: <064.ab2ff0ca09001764d46ce8c6ea30657a@tools.ietf.org>  <808FD6E27AD4884E94820BC333B2DB7758410A9CE7@NOK-EUMSG-01.mgdnok.nokia.com> <19285.43330.296567.83100@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7758410A9DE6@NOK-EUMSG-01.mgdnok.nokia.com> <19285.48271.313543.281841@fireball.kivinen.iki.fi>
In-Reply-To: <19285.48271.313543.281841@fireball.kivinen.iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 19 Jan 2010 20:53:58.0508 (UTC) FILETIME=[8582BAC0:01CA9949]
X-Nokia-AV: Clean
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Issue #143: Rewrite of 1.5
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 20:54:16 -0000

Tero Kivinen wrote:

> Should we note something that we know this is against MUST in section
> 3.1, but sending zero initiator SPI is still ok?

Yes, we probably should. Proposed rephrasing of that sentence:

   There are no IKE SPI values that would be meaningful to the
   recipient of such a notification; using zero values or random
   values are both acceptable (this is an exception to the usual
   requirement that the initiator's SPI cannot be zero).

> The problem I have with this text, is that I know that some day
> someone will come to me and ask me to explain why we send zero
> initiator SPI when sending these error notifications even when there
> is text saying that initiator SPI MUST NOT be zero...

...or someone will, three years from now, notice this same=20
bug again on the mailing list :-)

Best regards,
Pasi

From paul.hoffman@vpnc.org  Tue Jan 19 14:22:07 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22EA83A69BD for ; Tue, 19 Jan 2010 14:22:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.99
X-Spam-Level: 
X-Spam-Status: No, score=-5.99 tagged_above=-999 required=5 tests=[AWL=0.056,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDQM3oHDbAzm for ; Tue, 19 Jan 2010 14:22:06 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 704513A69BB for ; Tue, 19 Jan 2010 14:22:06 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0JMM0HI092970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2010 15:22:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <19285.47950.159235.173118@fireball.kivinen.iki.fi>
References:  <19285.47950.159235.173118@fireball.kivinen.iki.fi>
Date: Tue, 19 Jan 2010 14:21:56 -0800
To: Tero Kivinen 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Cc: IPsecme WG 
Subject: Re: [IPsec] FAILED_CP_REQUIRED (Re: Reviews of section 1 and 2 of the	draft-ietf-ipsecme-ikev2)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 22:22:07 -0000

At 4:01 PM +0200 1/19/10, Tero Kivinen wrote:
>I do not think they are different cases.

On further staring at this, I agree, and I agree that your rewording is fine. Done.

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Tue Jan 19 14:29:44 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C09523A696B for ; Tue, 19 Jan 2010 14:29:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.991
X-Spam-Level: 
X-Spam-Status: No, score=-5.991 tagged_above=-999 required=5 tests=[AWL=0.055,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ut6UZ+hW3kxL for ; Tue, 19 Jan 2010 14:29:44 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id E22F33A68FB for ; Tue, 19 Jan 2010 14:29:43 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0JMM0HG092970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2010 15:22:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21D66@il-ex01.ad.checkpoint.com>
References: <19284.34317.682796.84636@fireball.kivinen.iki.fi>  <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21D66@il-ex01.ad.checkpoint.com>
Date: Tue, 19 Jan 2010 14:15:52 -0800
To: Yaron Sheffer , Tero Kivinen , "ipsec@ietf.org" 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [IPsec] Notify types, was: RE: Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1 forward)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 22:29:44 -0000

At 8:57 AM +0200 1/19/10, Yaron Sheffer wrote:
>I agree with Tero, regardless of the discussion we had on where to put the tables etc., the document needs to be internally consistent. So we should add the new notify types that we're defining in *this* document to the notify types table. Luckily there aren't many.

Done.

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Tue Jan 19 14:53:09 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E83B23A683D for ; Tue, 19 Jan 2010 14:53:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.992
X-Spam-Level: 
X-Spam-Status: No, score=-5.992 tagged_above=-999 required=5 tests=[AWL=0.054,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wn1aiJAnzcd0 for ; Tue, 19 Jan 2010 14:53:09 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 01B573A680B for ; Tue, 19 Jan 2010 14:53:08 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0JMr318094510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2010 15:53:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <19285.40847.855520.352829@fireball.kivinen.iki.fi>
References: <19284.34317.682796.84636@fireball.kivinen.iki.fi>  <19285.40847.855520.352829@fireball.kivinen.iki.fi>
Date: Tue, 19 Jan 2010 14:35:03 -0800
To: Tero Kivinen 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Cc: ipsec@ietf.org
Subject: Re: [IPsec] HTTP_CERT_LOOKUP_SUPPORTED (was: Re: Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1 forward))
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 22:53:10 -0000

At 2:03 PM +0200 1/19/10, Tero Kivinen wrote:
>Paul Hoffman writes:
>> In section 3.6 we have text which says:
>>
>>	   Certificate payloads SHOULD be included in an exchange if
>>    certificates are available to the sender unless the peer has
>>    indicated an ability to retrieve this information from elsewhere
>>    using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. 
>>
>> which is bit misleading, as even if HTTP_CERT_LOOKUP_SUPPORTED notify
>> payload is sent that does not mean peer should leave out all Certificate
>> payloads, it just means it should use Hash and URL formats instead of
>> sending full certificates.
>>
>> Perhaps it should be changed to:
>>
>>	   Certificate payloads SHOULD be included in an exchange if
>>    certificates are available to the sender. The Hash and URL formats of
>>    the Certificate payloads should be used in case the peer has indicated
>>    an ability to retrieve this information from elsewhere using an
>>    HTTP_CERT_LOOKUP_SUPPORTED Notify payload.
>>
>> [[ Response: The proposed change does not make sense: it sounds like
>> a peer SHOULD send *both* the certificates and the hash-and-URL,
>> which is silly. ]]
>
>Peer uses certificate payloads to send both full X.509 certificates
>and hash-and url "certificates", so yes, when peer uses hash-and-URL
>format it is still sending "certificates" inside the certificate
>payloads, even though the actual X.509 certificate is not there.

This is a significant technical change from RFC 4306, which clearly makes the two forms alternatives by using the word "unless".

>Would this be better:
>
>	   Certificate payloads SHOULD be included in an exchange if
>   certificates are available to the sender. The Hash and URL formats
>   of the Certificate payloads should be used instead of full X.509
>   certificates in case the peer has indicated an ability to retrieve
>   this information from elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED
>   Notify payload.
>
>(The section 3.6 already notices that term "certificate" is misleading
>as not all data is certificates in this payload).

No, that is still a technical change.

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Tue Jan 19 14:59:44 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D55A3A6AAD for ; Tue, 19 Jan 2010 14:59:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.993
X-Spam-Level: 
X-Spam-Status: No, score=-5.993 tagged_above=-999 required=5 tests=[AWL=0.053,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zim6mieKeG+5 for ; Tue, 19 Jan 2010 14:59:43 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 8A22F3A6859 for ; Tue, 19 Jan 2010 14:59:43 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0JMr31C094510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2010 15:53:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <19285.40664.791802.892678@fireball.kivinen.iki.fi>
References: <19284.34317.682796.84636@fireball.kivinen.iki.fi>  <19285.40664.791802.892678@fireball.kivinen.iki.fi>
Date: Tue, 19 Jan 2010 14:47:56 -0800
To: Tero Kivinen 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Cc: ipsec@ietf.org
Subject: Re: [IPsec] NAT-T text (was: Re: Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1 forward))
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 22:59:44 -0000

At 2:00 PM +0200 1/19/10, Tero Kivinen wrote:
>Paul Hoffman writes:
>> Also the bullet
>>
>>    - Store the original traffic selector IP addresses as real source
>>      and destination address in case we need to undo address
>>      substitution.
>>
>> needs to be changed to
>>
>>    - Store the original traffic selector IP addresses as real source
>>      and destination address and also in case we need them to undo
>>      address substitution.
>>
>> [[ Response: That wording doesn't make any sense to me. ]]
>
>There is two reason why original traffic selector IP addresses are
>stored: 1) to use as "real source and destination address" as
>specified by RFC3948 for TCP/UDP checksum fixup; 2) when they are
>needed to undo address substitution in case we need to fall back to
>tunnel mode.
>
>The original text only mentioned the second use, not first use, and my
>change tried to include both...
>
>Perhaps you can try to write some wording that makes sense...

That makes much more sense. Done.

>BTW, the RFC3948 uses term "peer's real source and destination IP
>addresses" (section 3.1.2, option 1). The RFC3947 uses therm "Original
>Source and Destination Addresses" (section 5.2).

It's a tad late to fix those...

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Tue Jan 19 14:59:44 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 947983A6859 for ; Tue, 19 Jan 2010 14:59:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.994
X-Spam-Level: 
X-Spam-Status: No, score=-5.994 tagged_above=-999 required=5 tests=[AWL=0.052,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJcSSBPcXGub for ; Tue, 19 Jan 2010 14:59:43 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id BF7BE3A680B for ; Tue, 19 Jan 2010 14:59:43 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0JMr31G094510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2010 15:53:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <19285.41398.297890.458286@fireball.kivinen.iki.fi>
References: <19284.34317.682796.84636@fireball.kivinen.iki.fi>  <19285.41398.297890.458286@fireball.kivinen.iki.fi>
Date: Tue, 19 Jan 2010 14:53:00 -0800
To: Tero Kivinen 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Section 1.7 (Was Re: Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1 forward))
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 22:59:44 -0000

At 2:12 PM +0200 1/19/10, Tero Kivinen wrote:
>Paul Hoffman writes:
>> Following things might or might not need to be added to section 1.7
>> (taken from appendix E):
>>
>> [[ Response: I included only some of those. 1.7 is not meant to be
>> exhaustive: it can't be. But I did add a bunch you had suggested
>> that I had missed on my pass. ]]
>
>Can you send new 1.7 (or at least list which entries you included, and
>which you left out) before putting out new version so we can see which
>one you included.

Yes. Given the large set of open issues, I'll publish another draft and give folks time to review it before we pass it along for IETF Last call.

>Some of those are important some are not, and I included in my list
>all that I tough might be important enough to be mentioned (and yes, I
>agree not all of them needs to be there, but those were entries I
>assumed someone might think needs to be there, so I think it might be
>good idea to get comments now, not only after next revision).

And others thought that some of the ones listed currently are not important enough to list. I have no idea how we will agree on this.

>BTW, you didn't anwer to my question what is the intended relationship
>between "Appendix D. Significant Changes from RFC 4306" and " 1.7.
>Differences Between RFC 4306 and This Document"?

I removed Appendix D.


--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Tue Jan 19 14:59:44 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C402B3A680B for ; Tue, 19 Jan 2010 14:59:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.995
X-Spam-Level: 
X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.051,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Y-e2NnRYNGe for ; Tue, 19 Jan 2010 14:59:44 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 01B8D3A69BD for ; Tue, 19 Jan 2010 14:59:43 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0JMr31E094510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2010 15:53:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <19285.47054.324974.228538@fireball.kivinen.iki.fi>
References:  <19285.47054.324974.228538@fireball.kivinen.iki.fi>
Date: Tue, 19 Jan 2010 14:51:02 -0800
To: Tero Kivinen 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Cc: IPsecme WG 
Subject: Re: [IPsec] Payload order section number (Re: Reviews of section 1 and 2 of the draft-ietf-ipsecme-ikev2)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 22:59:44 -0000

At 3:46 PM +0200 1/19/10, Tero Kivinen wrote:
>Paul Hoffman writes:
>> Section 1.3.1 now talks about the USE_TRANSPORT_MODE,
>> ESP_TFC_PADDING_NOT_SUPPORTED and NON_FIRST_FRAMENTS_ALSO notifications,
>> and says they can be included, but the packet figure does not include
>> them. Adding them to the figure would be easy, but the problem is that we
>> currently say that you should follow the order of payloads from the
>> figures (altough we do refer to section 2 not section 1, but this is one
>> of the open issues).
>>
>> So depending what we decided on the payload order and figures, it might
>> be better to add one extra ", [N]" to the figure before SA payload.
>>
>> [[ Response: It is not an open issue. The spec says "implementations
>> MUST NOT reject as invalid a message with those payloads in any
>> other order". Thus, putting the "[N]" in the figure is likely to be
>> more confusing than helpful because [N] can appear in almost *any*
>> of the figures. ]]
>
>Yes [N] Can appear in any figure.
>
>On the other hand we are now talking about Notification payloads in
>the section 1.3.1 and the figures don't show them at all, which can
>cause confusion.

My ability to predict confusion is better than yours. :-) Seriously, they both can be confusing, and I think that inconsistent placement of [N] is more confusing than consistent non-placement of [N].

>BTW, so we are going to leave the reference to point to only section 2
>in the end of section 2.5?

No, it now says sections 1 and 2.

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Tue Jan 19 14:59:45 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35E1C3A680B for ; Tue, 19 Jan 2010 14:59:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.996
X-Spam-Level: 
X-Spam-Status: No, score=-5.996 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQ1zgBOUFDRm for ; Tue, 19 Jan 2010 14:59:44 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 37E083A6A6E for ; Tue, 19 Jan 2010 14:59:44 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0JMr31A094510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2010 15:53:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <19285.31329.364411.591517@fireball.kivinen.iki.fi>
References: <808FD6E27AD4884E94820BC333B2DB7758410A954B@NOK-EUMSG-01.mgdnok.nokia.com> <19285.31329.364411.591517@fireball.kivinen.iki.fi>
Date: Tue, 19 Jan 2010 14:41:17 -0800
To: Tero Kivinen , 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Cc: ipsec@ietf.org
Subject: Re: [IPsec] INVALID_IKE_SPI inside IKE SA (was:  IKEv2bis, comments about sections 1-2)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 22:59:45 -0000

At 11:24 AM +0200 1/19/10, Tero Kivinen wrote:
>Pasi.Eronen@nokia.com writes:
>> - Section 1.5: I noticed the 1st paragraph nowadays (well, since -00
>> of the WG draft) allows sending INVALID_IKE_SPI notification inside an
>> existing IKE_SA. This contradicts a MUST NOT in RFC 4306, and I'm not
>> sure if it really brings any benefits?
>
>There is no way to send INVALID_IKE_SPI inside IKE SA, as the section
>3.10 says that the IKE SPI is never sent inside the notification
>payload (For a notification concerning the IKE SA, the SPI Size MUST
>be zero and the field must be empty.) and the IKE SPI is taken from
>the packet. Sending INVALID_IKE_SPI inside IKE SA would mean that the
>IKE SA you are sending the packet inside is invalid...
>
>The section 2.21.4 is very clear that INVALID_IKE_SPI MUST NOT be
>cryptographically protected, i.e. it is sent outside the IKE SA.
>
>I think the 1st paragraph is quite wrong and the
>
>  If the receiving node has an active IKE SA to the IP address from
>  whence the packet came, it MAY send a notification of the wayward
>  packet over that IKE SA in an INFORMATIONAL exchange.
>
>part should be removed.

Done.

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Tue Jan 19 15:52:43 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2A0C3A67E1 for ; Tue, 19 Jan 2010 15:52:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.997
X-Spam-Level: 
X-Spam-Status: No, score=-5.997 tagged_above=-999 required=5 tests=[AWL=0.049,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGkQM8BRgxwA for ; Tue, 19 Jan 2010 15:52:43 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 159EF3A67BD for ; Tue, 19 Jan 2010 15:52:42 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0JNqbta097711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2010 16:52:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7758410A9BC5@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB7758410A9BC5@NOK-EUMSG-01.mgdnok.nokia.com>
Date: Tue, 19 Jan 2010 15:52:34 -0800
To: , 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [IPsec] IKEv2bis, comments about sections 3-
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 23:52:43 -0000

Thanks for the careful review (although co-authors of the document are kinda expected to do this...). Only two things that stuck out as not done:

- Section 3.13.1: the paragraph about Mobility Header is very
confusing; suggested rephrasing:

   Traffic selectors can use IP Protocol ID 135 to match the IPv6
   mobility header [MIPV6].  As specified in [IPSECARCH], the IPv6
   mobility header (MH) message type is placed in the most significant
   eight bits of the 16-bit local port selector.  The direction
   semantics of TSi/TSr port fields are the same as for ICMP.


Based on an earlier comment, I have already reworded that as:

The traffic selector types 7 and 8 can also refer to ICMP or
ICMPv6 type and code fields, as well as MH Type fields for the IPv6
mobility header .  Note, however, that neither
ICMP nor MIPv6 packets have separate source and destination fields.
The method for specifying the traffic selectors for ICMP and MIPv6 is
shown by example in Section 4.4.1.3 of .

Does that meet your needs?



- Section 3.*: should we omit the UNSPECIFIED values? They don't
really help the reader here...

They do, in fact, help the reader. They tell them that 4306 specified these values but didn't tell you how to use them. That's important.

--Paul Hoffman, Director
--VPN Consortium

From wierbows@us.ibm.com  Tue Jan 19 19:12:41 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65E2C3A6809; Tue, 19 Jan 2010 19:12:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9YZFH9pP1R3; Tue, 19 Jan 2010 19:12:40 -0800 (PST)
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by core3.amsl.com (Postfix) with ESMTP id 11BA73A67E6; Tue, 19 Jan 2010 19:12:39 -0800 (PST)
Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e3.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o0K32PoN008384; Tue, 19 Jan 2010 22:02:25 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o0K3CTUl1724480; Tue, 19 Jan 2010 22:12:29 -0500
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o0K3CSDi030956; Wed, 20 Jan 2010 01:12:29 -0200
Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av02.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o0K3CSEG030928; Wed, 20 Jan 2010 01:12:28 -0200
In-Reply-To: 
References: <19284.34317.682796.84636@fireball.kivinen.iki.fi>	 <19285.40847.855520.352829@fireball.kivinen.iki.fi> 
X-KeepSent: 93E5BF5D:989B11B8-852576B1:000E056E; type=4; name=$KeepSent
To: Paul Hoffman 
X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009
Message-ID: 
From: David Wierbowski 
Date: Tue, 19 Jan 2010 22:12:27 -0500
X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 01/19/2010 22:12:28
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, Tero Kivinen 
Subject: Re: [IPsec] HTTP_CERT_LOOKUP_SUPPORTED (was: Re: Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1 forward))
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 03:12:41 -0000

>At 2:03 PM +0200 1/19/10, Tero Kivinen wrote:
>>Paul Hoffman writes:
>>> In section 3.6 we have text which says:
>>>
>>>             Certificate payloads SHOULD be included in an exchange if
>>>    certificates are available to the sender unless the peer has
>>>    indicated an ability to retrieve this information from elsewhere
>>>    using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload.
>>>
>>> which is bit misleading, as even if HTTP_CERT_LOOKUP_SUPPORTED notify
>>> payload is sent that does not mean peer should leave out all
Certificate
>>> payloads, it just means it should use Hash and URL formats instead of
>>> sending full certificates.
>>>
>>> Perhaps it should be changed to:
>>>
>>>             Certificate payloads SHOULD be included in an exchange if
>>>    certificates are available to the sender. The Hash and URL formats
of
>>>    the Certificate payloads should be used in case the peer has
indicated
>>>    an ability to retrieve this information from elsewhere using an
>>>    HTTP_CERT_LOOKUP_SUPPORTED Notify payload.
>>>
>>> [[ Response: The proposed change does not make sense: it sounds like
>>> a peer SHOULD send *both* the certificates and the hash-and-URL,
>>> which is silly. ]]
>>
>>Peer uses certificate payloads to send both full X.509 certificates
>>and hash-and url "certificates", so yes, when peer uses hash-and-URL
>>format it is still sending "certificates" inside the certificate
>>payloads, even though the actual X.509 certificate is not there.
>
>This is a significant technical change from RFC 4306, which clearly makes
>the two forms alternatives by using the word "unless".

Paul, are you saying that the word "unless" means that if the
HTTP_CERT_LOOKUP_SUPPORTED is received that no certificate payloads should
be sent?  That is not consistent with other mailing list discussions,
although that is what the sentence is saying.

Tero's statement is consistent with previous discussions and the
HTTP_CERT_LOOKUP_SUPPORTED Notify which "indicates that the
sender is capable of looking up certificates based on an HTTP-based
URL (and hence presumably would prefer to receive certificate
specifications in that format)."

Based on that description of the HTTP_CERT_LOOKUP_SUPPORTED Notify
and previous posts on the mailing list the sentence that Paul
references has been interpreted by some to mean:

   Certificate payloads containing encoding type 4 SHOULD be included
   in an exchange if
   certificates are available to the sender unless the peer has
   indicated an ability to retrieve this information from elsewhere
   using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload.

I'm not saying this is right, but that's consistent with previous
posts (most made by Tero).  It also seems to be consistent with the
description of the HTTP_CERT_LOOKUP_SUPPORTED Notify payload.

>
>>Would this be better:
>>
>>              Certificate payloads SHOULD be included in an exchange if
>>   certificates are available to the sender. The Hash and URL formats
>>   of the Certificate payloads should be used instead of full X.509
>>   certificates in case the peer has indicated an ability to retrieve
>>   this information from elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED
>>   Notify payload.
>>
>>(The section 3.6 already notices that term "certificate" is misleading
>>as not all data is certificates in this payload).
>
>No, that is still a technical change.

I'm not sure if this is a technical change or correcting a technical
error.  I agree with the wording Tero has provided and I think that is
what the intent of the original text was.

>
>--Paul Hoffman, Director
>--VPN Consortium

Dave Wierbowski


z/OS Comm Server Developer

 Phone:
    Tie line:   620-4055
    External:  607-429-4055




From paul.hoffman@vpnc.org  Tue Jan 19 20:29:31 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5B213A67EC; Tue, 19 Jan 2010 20:29:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.998
X-Spam-Level: 
X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=0.048,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAQZun3tPip1; Tue, 19 Jan 2010 20:29:30 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id CA0DE3A679C; Tue, 19 Jan 2010 20:29:30 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0K4TOIp012345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2010 21:29:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: <19284.34317.682796.84636@fireball.kivinen.iki.fi>  <19285.40847.855520.352829@fireball.kivinen.iki.fi>  
Date: Tue, 19 Jan 2010 20:29:23 -0800
To: David Wierbowski 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, Tero Kivinen 
Subject: Re: [IPsec] HTTP_CERT_LOOKUP_SUPPORTED (was: Re: Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1 forward))
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 04:29:31 -0000

At 10:12 PM -0500 1/19/10, David Wierbowski wrote:
> >At 2:03 PM +0200 1/19/10, Tero Kivinen wrote:
>>>Paul Hoffman writes:
>>>> In section 3.6 we have text which says:
>>>>
>>>>             Certificate payloads SHOULD be included in an exchange if
>>>>    certificates are available to the sender unless the peer has
>>>>    indicated an ability to retrieve this information from elsewhere
>>>>    using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload.
>>>>
>>>> which is bit misleading, as even if HTTP_CERT_LOOKUP_SUPPORTED notify
>>>> payload is sent that does not mean peer should leave out all
>Certificate
>>>> payloads, it just means it should use Hash and URL formats instead of
>>>> sending full certificates.
>>>>
>>>> Perhaps it should be changed to:
>>>>
>>>>             Certificate payloads SHOULD be included in an exchange if
>>>>    certificates are available to the sender. The Hash and URL formats
>of
>>>>    the Certificate payloads should be used in case the peer has
>indicated
>>>>    an ability to retrieve this information from elsewhere using an
>>>>    HTTP_CERT_LOOKUP_SUPPORTED Notify payload.
>>>>
>>>> [[ Response: The proposed change does not make sense: it sounds like
>>>> a peer SHOULD send *both* the certificates and the hash-and-URL,
>>>> which is silly. ]]
>>>
>>>Peer uses certificate payloads to send both full X.509 certificates
>>>and hash-and url "certificates", so yes, when peer uses hash-and-URL
>>>format it is still sending "certificates" inside the certificate
>>>payloads, even though the actual X.509 certificate is not there.
>>
>>This is a significant technical change from RFC 4306, which clearly makes
>>the two forms alternatives by using the word "unless".
>
>Paul, are you saying that the word "unless" means that if the
>HTTP_CERT_LOOKUP_SUPPORTED is received that no certificate payloads should
>be sent? 

Yes, exactly.

>That is not consistent with other mailing list discussions,
>although that is what the sentence is saying.

I am glad I am saying what the sentence is saying. We are not supposed to be changing things from 4306, particularly ones with SHOULDs in them.

>I'm not sure if this is a technical change or correcting a technical
>error. 

It is not a "technical error", it is a design choice that Tero doesn't like.

>I agree with the wording Tero has provided and I think that is
>what the intent of the original text was.

We disagree here. The point of hash-and-URL was to prevent people from sending certs.

--Paul Hoffman, Director
--VPN Consortium

From wierbows@us.ibm.com  Tue Jan 19 21:02:08 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D6683A692B; Tue, 19 Jan 2010 21:02:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNpsXPgCZzHO; Tue, 19 Jan 2010 21:02:07 -0800 (PST)
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by core3.amsl.com (Postfix) with ESMTP id 69DFA3A6876; Tue, 19 Jan 2010 21:02:07 -0800 (PST)
Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by e3.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o0K4pwR5020581; Tue, 19 Jan 2010 23:51:58 -0500
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o0K520WT132618; Wed, 20 Jan 2010 00:02:02 -0500
Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o0K520on029544; Wed, 20 Jan 2010 00:02:00 -0500
Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av01.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o0K51xI7029527; Wed, 20 Jan 2010 00:01:59 -0500
In-Reply-To: 
References: <19284.34317.682796.84636@fireball.kivinen.iki.fi>  <19285.40847.855520.352829@fireball.kivinen.iki.fi>   
X-KeepSent: A51C879E:5F85962A-852576B1:001AFD73; type=4; name=$KeepSent
To: Paul Hoffman 
X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009
Message-ID: 
From: David Wierbowski 
Date: Wed, 20 Jan 2010 00:01:58 -0500
X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 01/20/2010 00:01:59
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, Tero Kivinen 
Subject: Re: [IPsec] HTTP_CERT_LOOKUP_SUPPORTED (was: Re: Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1 forward))
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 05:02:08 -0000

>>I agree with the wording Tero has provided and I think that is
>>what the intent of the original text was.
>
>We disagree here. The point of hash-and-URL was to prevent people from
sending certs.

We do not disagree.  The point of hash-and-URL is to prevent people from
sending certs and it does.  The certificate is not sent when when a
hash-and-URL is used.  A hash and URL of the certificate is sent. That hash
and URL is sent in a certificate payload.  Note you did not say that the
point of hash-and-URL is to prevent people from sending certificate
payloads.  I think Tero's current wording does prevent the cert from being
sent.

Dave Wierbowski


z/OS Comm Server Developer

 Phone:
    Tie line:   620-4055
    External:  607-429-4055




From yaronf@checkpoint.com  Wed Jan 20 01:22:02 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B15F33A68A9 for ; Wed, 20 Jan 2010 01:22:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqAvQSKqaeqk for ; Wed, 20 Jan 2010 01:22:00 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id DB0013A67D9 for ; Wed, 20 Jan 2010 01:21:58 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0K9LsT7004387 for ; Wed, 20 Jan 2010 11:21:54 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 20 Jan 2010 11:22:07 +0200
From: Yaron Sheffer 
To: "ipsec@ietf.org" 
Date: Wed, 20 Jan 2010 11:22:03 +0200
Thread-Topic: IKEv2-bis, comments up to 2.16
Thread-Index: AcqZsgbraxKTIkrISMy1JxxRDLcb/A==
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21EF8@il-ex01.ad.checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21EF8ilex01adche_"
MIME-Version: 1.0
Subject: [IPsec] IKEv2-bis, comments up to 2.16
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 09:22:02 -0000

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21EF8ilex01adche_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Abstract: "It replaces" -> "This specification replaces" (otherwise "it" co=
uld refer to the protocol itself).

1: Remove bracketed first paragraph of the Introduction.

1: "IKE message flow" -> "An IKE message flow".

1.1.3: "IPsec- protected" - remove space.

1.2: in the table, add "IKE header (not a payload)" - the other items in th=
e table are all payloads.

1.2: The "E" payload is only mentioned here and in the Next Payload table. =
It is really the SK payload. I suggest to eliminate the confusing "E" notat=
ion, and replace it with SK.

1.3.2: for some reason we support negotiation of DH parameters when rekeyin=
g the IKE SA. So we should say that the INVALID_KE_PAYLOAD response is poss=
ible here, too.

1.3.3: in the exchange, replace "N" by "N(REKEY_SA)".

1.4: "The processing of an INFORMATIONAL exchange is determined by its comp=
onent payloads." Adding "The payloads are processed in strict left-to-right=
 order" would make it deterministic, and is probably what people do today.

1.4.1: "in your INFORMATIONAL" -> "in the INFORMATIONAL". In general the se=
ction is very wordy yet confusing: if each peer is responsible for deleting=
 (=3Dsending a delete payload for) its own incoming SAs, then why should we=
 say that "one never sends delete payloads for the two sides of an SA in a =
single message".

1.4.1: the last paragraph springs a surprise by defining the behavior of IK=
E SA deletion while discussing an unlikely "messing up" of Child SAs. IKE S=
A deletion deserves its own subsection.

2: the last paragraph, beginning "The UDP payload" is out of place here.

2.1: "allowed to forget response" -> "allowed to forget a response"

2.1: please delete the "zero non-ESP marker" from the list of things that m=
ay be mutable. It is kind of funny.

2.1: either here or in 1.5 we should say something about allowing limited r=
etransmission of the rare one-way IKE messages, for reliability.

2.3: do we allow to send SET_WINDOW_SIZE in the initial exchange? We don't =
say we don't - although we do say that it would only be effective starting =
with IKE_AUTH. But I believe we should not accept it until both peers are f=
ully authenticated.

2.4: this sentence is inconsistent: "The INITIAL_CONTACT notification, if s=
ent, MUST be in the first IKE_AUTH request or response, not as a separate e=
xchange afterwards; however, receiving parties MAY ignore it in other messa=
ges." If it MUST be only at a certain location, then it should be ignored (=
or even rejected) in others.

2.6, first paragraph: the historical discussion going back to the previous =
century is very confusing to a newcomer: instead of saying what a cookie is=
, we tell a story. I suggest to remove this discussion or move it to the en=
d of the section.

2.6: "they used to generate cookies" -> "used to...".

2.6: just a comment - I don't want to reopen this discussion: I think only =
the SPIi and Ni values should be hashed into the cookie, and not the IP. In=
 particular because only the SPI identifies the SA, and only Ni is needed t=
o identify a half-open SA.

2.6: can we separate the cookie discussion into its own subsection? For two=
 reasons: it is an implementation hint, rather than a specification (as opp=
osed to the normative text on SPIs earlier in 2.6); and it is not very impo=
rtant, given the prevalence of DDos.

2.8: this sentence  "It should do so if there has been no traffic since the=
 last time the SA was rekeyed" is useless: it talks about local policy for =
deletion, which we are not specifying. The policy "delete the SA if there's=
 been no traffic for the last 5 minutes" would be just as valid as this one=
.

2.8: the sentence "The node that initiated the surviving rekeyed SA should =
delete the replaced SA after the new one is established." is out of context=
.

2.8: the sentence beginning "From a technical correctness and interoperabil=
ity perspective" is not strictly correct: there is still a race condition b=
etween the first packets on the SA and the CCSA response. Immediately start=
ing to send is practical but not "technically correct".

2.8: "The responder can be assured that the initiator is prepared to receiv=
e messages on an SA if either (1) it has received a cryptographically valid=
 message on the new SA." this should really be "...on the new SA's dual SA"=
 (or better wording thereof) since there's a pair of SAs, and we are determ=
ining the state of one based on the other. In general I think we are using =
the terms SA and SA Pair interchangeably, which is rather confusing.

2.8: "An initiator MAY send a dummy message on a newly created SA if it has=
 no messages queued in order to assure the responder that the initiator is =
ready to receive messages." A dummy message on an IPsec SA is way out of sc=
ope. Whether such messages even exist is a matter of local implementation. =
We certainly don't have IPsec-level keepalives. Overall, the last 3 paragra=
phs of 2.8 (starting "There are timing windows") are a mess: you have to re=
ad them several times before you realize that this is not normative text, r=
ather it is several implementation alternatives.

2.8.2: this is inconsistent, and probably incorrect - the IKE SA with the l=
owest nonce wins here, whereas in 2.8.1 the Child SA with the lowest nonce =
loses.

2.8.2: we should add a sentence on what happens if the peer receives TEMPOR=
ARY_FAILURE and does not understand it (because it's new to this spec).

2.9: typo: "wants to sen".

2.9.1: "those traffic" -> "this traffic".

2.12: the sentence "Decisions as to..." is grammatically incorrect. Should =
be: "Decisions as to whether and when to reuse Diffie-Hellman exponentials =
are private in the sense that they do not affect interoperability."

2.15: the value GenIKEHDR is confusing, because it is actually NOT includin=
g in the calculation. Is suggest to replace it with a clarifying sentence.

2.16: it would be useful if we added the explicit calculation of AUTH. For =
example, is the padding string required for EAP as well? There are two case=
s, with MSK and with SK_pi+SK_pr.

2.16: if the responder sends an EAP Failure, is this IKE message acknowledg=
ed by the initiator?

2.16: the sentence saying "some simpler variations are documented here and =
in Section 3.16" may have been true once; it isn't now. In particular in vi=
ew of my next comment.

3.16: I suggest to remove the table quoted from the EAP RFC. There are doze=
ns of methods now in the IANA registry, many of which are preferable to the=
 ones mentioned here.

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21EF8ilex01adche_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















Abstract: "It replaces" -> "This
specification replaces" (otherwise "it" could refer to the
protocol itself).



 



1: Remove bracketed first paragraph of the Introductio=
n.



 



1: "IKE message flow" -> "An IKE mes=
sage
flow".



 



1.1.3: "IPsec- protected" - remove space.



 



1.2: in the table, add "IKE header (not a
payload)" - the other items in the table are all payloads.<=
/p>


 



1.2: The "E" payload is only mentioned here =
and in
the Next Payload table. It is really the SK payload. I suggest to eliminate=
 the
confusing "E" notation, and replace it with SK.



 



1.3.2: for some reason we support negotiation of DH
parameters when rekeying the IKE SA. So we should say that the
INVALID_KE_PAYLOAD response is possible here, too.



 



1.3.3: in the exchange, replace "N" by
"N(REKEY_SA)".



 



1.4: "The processing of an INFORMATIONAL exchange=
 is
determined by its component payloads." Adding "The payloads are
processed in strict left-to-right order" would make it deterministic, =
and
is probably what people do today.



 



1.4.1: "in your INFORMATIONAL" -> "i=
n the
INFORMATIONAL". In general the section is very wordy yet confusing: if
each peer is responsible for deleting (=3Dsending a delete payload for) its=
 own
incoming SAs, then why should we say that "one never sends delete payl=
oads
for the two sides of an SA in a single message".



 



1.4.1: the last paragraph springs a surprise by defini=
ng the
behavior of IKE SA deletion while discussing an unlikely "messing up&q=
uot;
of Child SAs. IKE SA deletion deserves its own subsection.



 



2: the last paragraph, beginning "The UDP payload=
"
is out of place here.



 



2.1: "allowed to forget response" ->
"allowed to forget a response"



 



2.1: please delete the "zero non-ESP marker"=
 from
the list of things that may be mutable. It is kind of funny.



 



2.1: either here or in 1.5 we should say something abo=
ut
allowing limited retransmission of the rare one-way IKE messages, for
reliability.



 



2.3: do we allow to send SET_WINDOW_SIZE in the initia=
l
exchange? We don't say we don't - although we do say that it would only be
effective starting with IKE_AUTH. But I believe we should not accept it unt=
il
both peers are fully authenticated.



 



2.4: this sentence is inconsistent: "The
INITIAL_CONTACT notification, if sent, MUST be in the first IKE_AUTH reques=
t or
response, not as a separate exchange afterwards; however, receiving parties=
 MAY
ignore it in other messages." If it MUST be only at a certain location=
,
then it should be ignored (or even rejected) in others.



 



2.6, first paragraph: the historical discussion going =
back
to the previous century is very confusing to a newcomer: instead of saying =
what
a cookie is, we tell a story. I suggest to remove this discussion or move i=
t to
the end of the section.



 



2.6: "they used to generate cookies" ->
"used to...".



 



2.6: just a comment - I don't want to reopen this
discussion: I think only the SPIi and Ni values should be hashed into the
cookie, and not the IP. In particular because only the SPI identifies the S=
A,
and only Ni is needed to identify a half-open SA.



 



2.6: can we separate the cookie discussion into its ow=
n
subsection? For two reasons: it is an implementation hint, rather than a
specification (as opposed to the normative text on SPIs earlier in 2.6); an=
d it
is not very important, given the prevalence of DDos.



 



2.8: this sentence  "It should do so if ther=
e has
been no traffic since the last time the SA was rekeyed" is useless: it
talks about local policy for deletion, which we are not specifying. The pol=
icy
"delete the SA if there's been no traffic for the last 5 minutes"
would be just as valid as this one.



 



2.8: the sentence "The node that initiated the
surviving rekeyed SA should delete the replaced SA after the new one is
established." is out of context.



 



2.8: the sentence beginning "From a technical
correctness and interoperability perspective" is not strictly correct:
there is still a race condition between the first packets on the SA and the
CCSA response. Immediately starting to send is practical but not
"technically correct".



 



2.8: "The responder can be assured that the initi=
ator
is prepared to receive messages on an SA if either (1) it has received a
cryptographically valid message on the new SA." this should really be
"...on the new SA's dual SA" (or better wording thereof) since
there's a pair of SAs, and we are determining the state of one based on the
other. In general I think we are using the terms SA and SA Pair
interchangeably, which is rather confusing.



 



2.8: "An initiator MAY send a dummy message on a =
newly
created SA if it has no messages queued in order to assure the responder th=
at
the initiator is ready to receive messages." A dummy message on an IPs=
ec
SA is way out of scope. Whether such messages even exist is a matter of loc=
al
implementation. We certainly don't have IPsec-level keepalives. Overall, th=
e
last 3 paragraphs of 2.8 (starting "There are timing windows") ar=
e a
mess: you have to read them several times before you realize that this is n=
ot
normative text, rather it is several implementation alternatives.



 



2.8.2: this is inconsistent, and probably incorrect - =
the
IKE SA with the lowest nonce wins here, whereas in 2.8.1 the Child SA with =
the
lowest nonce loses.



 



2.8.2: we should add a sentence on what happens if the=
 peer
receives TEMPORARY_FAILURE and does not understand it (because it's new to =
this
spec).



 



2.9: typo: "wants to sen".



 



2.9.1: "those traffic" -> "this
traffic".



 



2.12: the sentence "Decisions as to..." is g=
rammatically
incorrect. Should be: "Decisions as to whether and when to reuse
Diffie-Hellman exponentials are private in the sense that they do not affec=
t
interoperability."



 



2.15: the value GenIKEHDR is confusing, because it is
actually NOT including in the calculation. Is suggest to replace it with a
clarifying sentence.



 



2.16: it would be useful if we added the explicit
calculation of AUTH. For example, is the padding string required for EAP as
well? There are two cases, with MSK and with SK_pi+SK_pr.



 



2.16: if the responder sends an EAP Failure, is this I=
KE
message acknowledged by the initiator?



 



2.16: the sentence saying "some simpler variation=
s are
documented here and in Section 3.16" may have been true once; it isn't
now. In particular in view of my next comment.



 



3.16: I suggest to remove the table quoted from the EA=
P RFC.
There are dozens of methods now in the IANA registry, many of which are
preferable to the ones mentioned here.









--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21EF8ilex01adche_--

From yaronf@checkpoint.com  Wed Jan 20 01:27:10 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35ADA3A687C for ; Wed, 20 Jan 2010 01:27:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMH6CwDeGoJn for ; Wed, 20 Jan 2010 01:27:07 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 3EEC13A680C for ; Wed, 20 Jan 2010 01:27:06 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0K9R2T7005057 for ; Wed, 20 Jan 2010 11:27:02 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 20 Jan 2010 11:27:16 +0200
From: Yaron Sheffer 
To: "ipsec@ietf.org" 
Date: Wed, 20 Jan 2010 11:27:13 +0200
Thread-Topic: IKEv2-bis discussion - please jump in!
Thread-Index: AcqZsr/tbGkPkMW8QriSMWiIfeXZ/w==
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21EFC@il-ex01.ad.checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21EFCilex01adche_"
MIME-Version: 1.0
Subject: [IPsec] IKEv2-bis discussion - please jump in!
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 09:27:10 -0000

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21EFCilex01adche_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi everyone,

Right before this document is sent to our AD, this is the last chance for u=
s as a group to put the finishing touches on it. I'd like to urge you all t=
o read the comments that were sent to the list in the last few days, add yo=
ur own comments if necessary, and actively participate in the discussion.

Thanks,
                Yaron

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21EFCilex01adche_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















Hi everyone,



 



Right before this document is sent to our AD, this is =
the last
chance for us as a group to put the finishing touches on it. I’d like=
 to
urge you all to read the comments that were sent to the list in the last fe=
w
days, add your own comments if necessary, and actively participate in the
discussion.



 



Thanks,



         =
       Yaron









--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21EFCilex01adche_--

From kivinen@iki.fi  Wed Jan 20 02:32:47 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42F143A689C for ; Wed, 20 Jan 2010 02:32:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.556
X-Spam-Level: 
X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QU6gWsvPGGQ for ; Wed, 20 Jan 2010 02:32:46 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 015373A67A1 for ; Wed, 20 Jan 2010 02:32:45 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0KAWYCV026883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jan 2010 12:32:34 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0KAWWc9002436; Wed, 20 Jan 2010 12:32:32 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19286.56256.904609.349902@fireball.kivinen.iki.fi>
Date: Wed, 20 Jan 2010 12:32:32 +0200
From: Tero Kivinen 
To: David Wierbowski 
In-Reply-To: 
References: <19284.34317.682796.84636@fireball.kivinen.iki.fi>  <19285.40847.855520.352829@fireball.kivinen.iki.fi>    
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 15 min
X-Total-Time: 25 min
Cc: ipsec@ietf.org, Paul Hoffman 
Subject: Re: [IPsec] HTTP_CERT_LOOKUP_SUPPORTED (was: Re: Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1 forward))
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 10:32:47 -0000

David Wierbowski writes:
> >>I agree with the wording Tero has provided and I think that is
> >>what the intent of the original text was.
> >
> >We disagree here. The point of hash-and-URL was to prevent people from
> >sending certs.

There are two things here, there is HTTP_CERT_LOOKUP_SUPPORTED and
Hash-and-URL formats. The HTTP_CERT_LOOKUP_SUPPORTED means:

            This notification MAY be included in any message that can
            include a CERTREQ payload and indicates that the sender is
            capable of looking up certificates based on an HTTP-based
            URL (and hence presumably would prefer to receive
            certificate specifications in that format).

Here this "prefer to receive certificate specifications in that
format" is meaning the Hash-and-URL formats.

> We do not disagree.  The point of hash-and-URL is to prevent people from
> sending certs and it does.  The certificate is not sent when when a
> hash-and-URL is used.  A hash and URL of the certificate is sent. That hash
> and URL is sent in a certificate payload.  Note you did not say that the
> point of hash-and-URL is to prevent people from sending certificate
> payloads.  I think Tero's current wording does prevent the cert from being
> sent.

Yes.

I.e. if you see HTTP_CERT_LOOKUP_SUPPORTED, you still send Certificate
payloads, but they do not contain full X.509 certificates, they
contain Hash-and-URL of the certificate.

The idea was that you include CERTREQ for X.509 Certificate -
Signature (4) format containing the trust anchor information. Then you
can also include HTTP_CERT_LOOKUP_SUPPORTED notification in the same
packet to indicate that in addition to that format (4), the other end
can also use Hash-and-URL formats as you support fetching the
certificates using HTTP.

Now the other end has two options. If it can provide url for the
certificate (i.e. it for example runs its own http server which
contains the certificate, and it can send hash of the certificate and
make url pointing to that server running and make sure certificate is
available from there), it would be better to use that Hash-and-URL
format.

On the other hand if it is behind NAT, and knows that it cannot start
http-server in such way that other end can reach it, then there is no
point of using hash-and-URL format as the url would not work, so it
can use normal X.509 Certificate - Signature (4) format instead.

Of course the the url could also point to the CA server or some other
server, but the version I described above was one of the intended ways
also (we had discussions on the ipsec list what do to if the http
connection between ipsec peers is not possible, and one solution was
to store the certificate to some other server).
-- 
kivinen@iki.fi

From kivinen@iki.fi  Wed Jan 20 02:36:04 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D2E33A68B7 for ; Wed, 20 Jan 2010 02:36:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.557
X-Spam-Level: 
X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9x4trX938bC8 for ; Wed, 20 Jan 2010 02:36:03 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id F36863A68A9 for ; Wed, 20 Jan 2010 02:36:02 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0KAZvhR029882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jan 2010 12:35:57 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0KAZv7g017007; Wed, 20 Jan 2010 12:35:57 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19286.56461.625405.209156@fireball.kivinen.iki.fi>
Date: Wed, 20 Jan 2010 12:35:57 +0200
From: Tero Kivinen 
To: Paul Hoffman 
In-Reply-To: 
References:  <19285.47054.324974.228538@fireball.kivinen.iki.fi> 
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 3 min
X-Total-Time: 2 min
Cc: IPsecme WG 
Subject: Re: [IPsec] Payload order section number (Re: Reviews of section 1 and 2 of the draft-ietf-ipsecme-ikev2)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 10:36:04 -0000

Paul Hoffman writes:
> >BTW, so we are going to leave the reference to point to only section 2
> >in the end of section 2.5?
> 
> No, it now says sections 1 and 2.

Not in the draft-ietf-ipsecme-ikev2bis-06.txt. Am I missing something,
or is there newer version availabe from somewhere?
-- 
kivinen@iki.fi

From kivinen@iki.fi  Wed Jan 20 04:22:19 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D7D23A6A68 for ; Wed, 20 Jan 2010 04:22:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.559
X-Spam-Level: 
X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Sy5RClJC-x6 for ; Wed, 20 Jan 2010 04:22:18 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id C4AA03A6A63 for ; Wed, 20 Jan 2010 04:22:17 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0KCM29B007046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jan 2010 14:22:02 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0KCM2Ix010600; Wed, 20 Jan 2010 14:22:02 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19286.62825.898863.477577@fireball.kivinen.iki.fi>
Date: Wed, 20 Jan 2010 14:22:01 +0200
From: Tero Kivinen 
To: Yaron Sheffer 
In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21EF8@il-ex01.ad.checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21EF8@il-ex01.ad.checkpoint.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 34 min
X-Total-Time: 94 min
Cc: "ipsec@ietf.org" 
Subject: [IPsec]  IKEv2-bis, comments up to 2.16
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 12:22:19 -0000

I only commented to those cases where I disagreed with you (mostly I
think we do not need to make the change). The other comments were ok
for me.

Yaron Sheffer writes:
> 1.3.2: for some reason we support negotiation of DH parameters when
> rekeying the IKE SA. So we should say that the INVALID_KE_PAYLOAD
> response is possible here, too.

I think generic text in section 1.3 should be enough for it:

   If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of
   the SA offers MUST include the Diffie-Hellman group of the KEi.  The
   Diffie-Hellman group of the KEi MUST be an element of the group the
   initiator expects the responder to accept (additional Diffie-Hellman
   groups can be proposed).  If the responder selects a proposal using a
   different Diffie-Hellman group (other than NONE), the responder MUST
   reject the request and indicate its preferred Diffie-Hellman group in
   the INVALID_KE_PAYLOAD Notification payload.  There are two octets of
   data associated with this notification: the accepted D-H Group number
   in big endian order.  In the case of such a rejection, the
   CREATE_CHILD_SA exchange fails, and the initiator will probably retry
   the exchange with a Diffie-Hellman proposal and KEi in the group that
   the responder gave in the INVALID_KE_PAYLOAD.

and this covers all subsections of 1.3 including 1.3.2, so I think
that is enough, and no additional text is needed.

> 1.4: "The processing of an INFORMATIONAL exchange is determined by
> its component payloads." Adding "The payloads are processed in
> strict left-to-right order" would make it deterministic, and is
> probably what people do today. 

There should be no need to make the processing deterministic, as at
least I cannot think of case where the processing order would matter,
and I do not want someone to start complaining if someone process them
in "wrong" order.

I do not think the addition should be done.

> 2.1: either here or in 1.5 we should say something about allowing
> limited retransmission of the rare one-way IKE messages, for
> reliability.

I have always assumed that you do not retransmit those, you simply
rate limit sending of them, and if other end sends further packets
which trigger sending new one-way IKE messages, then you will send
next one-way IKE message.

I.e. the retransmission is done automatically by the other end either
retransmitting its message (IKE packets) or other end sending more ESP
packets.

If we add text, I would rather add text saying you MUST NOT retransmit
those one-way IKE messages as they are one-way messages. You may send
new (identical) one-way IKE messages in case the same situation is
triggered again (rate limited) because other end sent another packet.

This would be consistent that attacker sending only one IKE or ESP
packet can cause only one one-way IKE message to be sent. If it wants
to peer to send another, it again needs to send another packet (i.e.
no amplification provided for attacker).

> 2.3: do we allow to send SET_WINDOW_SIZE in the initial exchange?

Yes.

> We don't say we don't - although we do say that it would only be
> effective starting with IKE_AUTH. But I believe we should not accept
> it until both peers are fully authenticated.

Regardless of the SET_WINDOW_SIZE the window size is always one until
the initial exchanges completes and initial exchanges include
IKE_INIT_SA and IKE_AUTH, thus after those have completed the parties
have been authenticated, and as you cannot have any other exchanges
while you have initial exchanges still in progess it does not really
matter.

I do not think this requires new text (except perhaps to clarify that
SET_WINDOW_SIZE can be in the initial exchange (usually in IKE_AUTH)).

We do send it in the IKE_AUTH (the same one having SA and TS payloads
if multiple IKE_AUTH messages), in the IKE SA rekey, and in the next
exchange (regardless of type) if it is changed on the fly. 

> 2.4: this sentence is inconsistent: "The INITIAL_CONTACT
> notification, if sent, MUST be in the first IKE_AUTH request or
> response, not as a separate exchange afterwards; however,
> receiving parties MAY ignore it in other messages." If it MUST be
> only at a certain location, then it should be ignored (or even
> rejected) in others.

No. The first one says where you MUST send it, the second part says
what you do if someone does not follow that MUST, which tells you MAY
ignore it.

There is no inconsistancy there.

The text is written like this as this was changed between RFC4306 and
draft-ietf-ipsecme-ikev2. The RFC4306 does not specify the location,
but IKEv2bis does, and because of this old implementations might send
INITIAL_CONTACT notifications in wrong place, and the text says that
you are free to ignore it in those places.

Support for INITIAL_CONTACT is MAY anyways (both sending and
processing it on receive).

So no need to change anything there.

> 2.8: this sentence "It should do so if there has been no traffic
> since the last time the SA was rekeyed" is useless: it talks about
> local policy for deletion, which we are not specifying. The policy
> "delete the SA if there's been no traffic for the last 5 minutes"
> would be just as valid as this one.

Yes, but the local policy given in the IKEv2bis is very common and
useful one. I do not think the text is useless, and as it does not
mandate implementations doing anything, it just says what they might
want to do, I do not see any reason to remove it.

> 2.8: the sentence beginning "From a technical correctness and
> interoperability perspective" is not strictly correct: there is
> still a race condition between the first packets on the SA and the
> CCSA response. Immediately starting to send is practical but not
> "technically correct".

For the protocol point of view it is techinally correct. I.e. after
responder has sent the response to the CREATE_CHILD_SA, for its point
of view the SA is ready and it can be used immediately.

There is race condition built in to the protocol, which is why the
text is there, i.e. it says it is techinally correct, but may still
cause packets to be dropped.

I do not see any need to change this text.

> 2.8.2: we should add a sentence on what happens if the peer receives
> TEMPORARY_FAILURE and does not understand it (because it's new
> to this spec).

There is text for that alread which says (section 3.10.1):

   Types in the range 0 - 16383 are intended for reporting errors. An
   implementation receiving a Notify payload with one of these types
   that it does not recognize in a response MUST assume that the
   corresponding request has failed entirely.  

So I do not see need to change the the 2.8.2. If change is needed
perhaps adding pointer to the 3.10.1, but I think even that is not
needed). 
-- 
kivinen@iki.fi

From Pasi.Eronen@nokia.com  Wed Jan 20 05:18:05 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FD953A683C for ; Wed, 20 Jan 2010 05:18:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.628
X-Spam-Level: 
X-Spam-Status: No, score=-6.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rgs9K95sId2X for ; Wed, 20 Jan 2010 05:18:04 -0800 (PST)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id F1B013A688F for ; Wed, 20 Jan 2010 05:18:03 -0800 (PST)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0KDHLGa010733; Wed, 20 Jan 2010 15:17:50 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 20 Jan 2010 15:16:54 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 20 Jan 2010 15:16:54 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Wed, 20 Jan 2010 14:16:54 +0100
From: 
To: , 
Date: Wed, 20 Jan 2010 14:16:52 +0100
Thread-Topic: [IPsec] IKEv2bis, comments about sections 3-
Thread-Index: AcqZYpUvduF6UBjdSAuaJNbfNJ5i6gAb/0Rw
Message-ID: <808FD6E27AD4884E94820BC333B2DB7758410F727A@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB7758410A9BC5@NOK-EUMSG-01.mgdnok.nokia.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 20 Jan 2010 13:16:54.0634 (UTC) FILETIME=[D60564A0:01CA99D2]
X-Nokia-AV: Clean
Subject: Re: [IPsec] IKEv2bis, comments about sections 3-
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 13:18:05 -0000

Paul Hoffman wrote:

> - Section 3.13.1: the paragraph about Mobility Header is very
> confusing; suggested rephrasing:
>=20
>    Traffic selectors can use IP Protocol ID 135 to match the IPv6
>    mobility header [MIPV6].  As specified in [IPSECARCH], the IPv6
>    mobility header (MH) message type is placed in the most significant
>    eight bits of the 16-bit local port selector.  The direction
>    semantics of TSi/TSr port fields are the same as for ICMP.
>=20
> Based on an earlier comment, I have already reworded that as:
>=20
> The traffic selector types 7 and 8 can also refer to ICMP or
> ICMPv6 type and code fields, as well as MH Type fields for the IPv6
> mobility header .  Note, however, that neither
> ICMP nor MIPv6 packets have separate source and destination fields.
> The method for specifying the traffic selectors for ICMP and MIPv6 is
> shown by example in Section 4.4.1.3 of .
>=20
> Does that meet your needs?

Hmm -- which paragraph(s) would be replaced by that text?=20
(The important detail "MH type goes in most significant 8 bits"
is *not* in Section 4.4.1.3 of RFC 4301...)

> - Section 3.*: should we omit the UNSPECIFIED values? They don't
> really help the reader here...
>=20
> They do, in fact, help the reader. They tell them that 4306 specified
> these values but didn't tell you how to use them. That's important.

Ok, I can buy that argument. So let's leave them as they are now.

Best regards,
Pasi

From yaronf@checkpoint.com  Wed Jan 20 07:47:19 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 415583A68B3 for ; Wed, 20 Jan 2010 07:47:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0ZP9h7aAhs4 for ; Wed, 20 Jan 2010 07:47:17 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 79D553A6452 for ; Wed, 20 Jan 2010 07:47:17 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0KFlBT7026343; Wed, 20 Jan 2010 17:47:11 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 20 Jan 2010 17:47:25 +0200
From: Yaron Sheffer 
To: Tero Kivinen 
Date: Wed, 20 Jan 2010 17:47:22 +0200
Thread-Topic: [IPsec] IKEv2-bis, comments up to 2.16
Thread-Index: AcqZyzlLFmad1phiSDyfh4TxpieaagAGNXtg
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21FEA@il-ex01.ad.checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21EF8@il-ex01.ad.checkpoint.com> <19286.62825.898863.477577@fireball.kivinen.iki.fi>
In-Reply-To: <19286.62825.898863.477577@fireball.kivinen.iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ipsec@ietf.org" 
Subject: Re: [IPsec] IKEv2-bis, comments up to 2.16
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 15:47:19 -0000

Hi Tero, thanks for your response. Some comments below.

	Yaron

> -----Original Message-----
> From: Tero Kivinen [mailto:kivinen@iki.fi]
> Sent: Wednesday, January 20, 2010 14:22
> To: Yaron Sheffer
> Cc: ipsec@ietf.org
> Subject: [IPsec] IKEv2-bis, comments up to 2.16
>=20
> I only commented to those cases where I disagreed with you (mostly I
> think we do not need to make the change). The other comments were ok
> for me.
>=20
> Yaron Sheffer writes:
> > 1.3.2: for some reason we support negotiation of DH parameters when
> > rekeying the IKE SA. So we should say that the INVALID_KE_PAYLOAD
> > response is possible here, too.
>=20
> I think generic text in section 1.3 should be enough for it:
>=20
>    If a CREATE_CHILD_SA exchange includes a KEi payload, at least one
> of
>    the SA offers MUST include the Diffie-Hellman group of the KEi.  The
>    Diffie-Hellman group of the KEi MUST be an element of the group the
>    initiator expects the responder to accept (additional Diffie-Hellman
>    groups can be proposed).  If the responder selects a proposal using
> a
>    different Diffie-Hellman group (other than NONE), the responder MUST
>    reject the request and indicate its preferred Diffie-Hellman group
> in
>    the INVALID_KE_PAYLOAD Notification payload.  There are two octets
> of
>    data associated with this notification: the accepted D-H Group
> number
>    in big endian order.  In the case of such a rejection, the
>    CREATE_CHILD_SA exchange fails, and the initiator will probably
> retry
>    the exchange with a Diffie-Hellman proposal and KEi in the group
> that
>    the responder gave in the INVALID_KE_PAYLOAD.
>=20
> and this covers all subsections of 1.3 including 1.3.2, so I think
> that is enough, and no additional text is needed.
>=20
I agree.

> > 1.4: "The processing of an INFORMATIONAL exchange is determined by
> > its component payloads." Adding "The payloads are processed in
> > strict left-to-right order" would make it deterministic, and is
> > probably what people do today.
>=20
> There should be no need to make the processing deterministic, as at
> least I cannot think of case where the processing order would matter,
> and I do not want someone to start complaining if someone process them
> in "wrong" order.
>=20
> I do not think the addition should be done.

I'm not convinced. CP payloads can do many things, including side effects o=
n other network components. Notifications are even more open ended, with ev=
ery IKE extension adding a new one. We should recommend some deterministic =
processing.
>=20
> > 2.1: either here or in 1.5 we should say something about allowing
> > limited retransmission of the rare one-way IKE messages, for
> > reliability.
>=20
> I have always assumed that you do not retransmit those, you simply
> rate limit sending of them, and if other end sends further packets
> which trigger sending new one-way IKE messages, then you will send
> next one-way IKE message.
>=20
> I.e. the retransmission is done automatically by the other end either
> retransmitting its message (IKE packets) or other end sending more ESP
> packets.
>=20
> If we add text, I would rather add text saying you MUST NOT retransmit
> those one-way IKE messages as they are one-way messages. You may send
> new (identical) one-way IKE messages in case the same situation is
> triggered again (rate limited) because other end sent another packet.
>=20
> This would be consistent that attacker sending only one IKE or ESP
> packet can cause only one one-way IKE message to be sent. If it wants
> to peer to send another, it again needs to send another packet (i.e.
> no amplification provided for attacker).
>=20
I agree.

> > 2.3: do we allow to send SET_WINDOW_SIZE in the initial exchange?
>=20
> Yes.
>=20
> > We don't say we don't - although we do say that it would only be
> > effective starting with IKE_AUTH. But I believe we should not accept
> > it until both peers are fully authenticated.
>=20
> Regardless of the SET_WINDOW_SIZE the window size is always one until
> the initial exchanges completes and initial exchanges include
> IKE_INIT_SA and IKE_AUTH, thus after those have completed the parties
> have been authenticated, and as you cannot have any other exchanges
> while you have initial exchanges still in progess it does not really
> matter.
>=20
> I do not think this requires new text (except perhaps to clarify that
> SET_WINDOW_SIZE can be in the initial exchange (usually in IKE_AUTH)).
>=20
> We do send it in the IKE_AUTH (the same one having SA and TS payloads
> if multiple IKE_AUTH messages), in the IKE SA rekey, and in the next
> exchange (regardless of type) if it is changed on the fly.
>=20
OK.

> > 2.4: this sentence is inconsistent: "The INITIAL_CONTACT
> > notification, if sent, MUST be in the first IKE_AUTH request or
> > response, not as a separate exchange afterwards; however,
> > receiving parties MAY ignore it in other messages." If it MUST be
> > only at a certain location, then it should be ignored (or even
> > rejected) in others.
>=20
> No. The first one says where you MUST send it, the second part says
> what you do if someone does not follow that MUST, which tells you MAY
> ignore it.
>=20
> There is no inconsistancy there.
>=20
> The text is written like this as this was changed between RFC4306 and
> draft-ietf-ipsecme-ikev2. The RFC4306 does not specify the location,
> but IKEv2bis does, and because of this old implementations might send
> INITIAL_CONTACT notifications in wrong place, and the text says that
> you are free to ignore it in those places.
>=20
> Support for INITIAL_CONTACT is MAY anyways (both sending and
> processing it on receive).
>=20
> So no need to change anything there.
>=20
OK, the original sentence would suddenly make sense if the word "however" w=
ere removed.

> > 2.8: this sentence "It should do so if there has been no traffic
> > since the last time the SA was rekeyed" is useless: it talks about
> > local policy for deletion, which we are not specifying. The policy
> > "delete the SA if there's been no traffic for the last 5 minutes"
> > would be just as valid as this one.
>=20
> Yes, but the local policy given in the IKEv2bis is very common and
> useful one. I do not think the text is useless, and as it does not
> mandate implementations doing anything, it just says what they might
> want to do, I do not see any reason to remove it.

I disagree. If I rekey the SA once every 24 hours (which is a reasonable po=
licy), this would not be useful at all.
>=20
> > 2.8: the sentence beginning "From a technical correctness and
> > interoperability perspective" is not strictly correct: there is
> > still a race condition between the first packets on the SA and the
> > CCSA response. Immediately starting to send is practical but not
> > "technically correct".
>=20
> For the protocol point of view it is techinally correct. I.e. after
> responder has sent the response to the CREATE_CHILD_SA, for its point
> of view the SA is ready and it can be used immediately.
>=20
> There is race condition built in to the protocol, which is why the
> text is there, i.e. it says it is techinally correct, but may still
> cause packets to be dropped.
>=20
> I do not see any need to change this text.
>=20
This is getting philosophical, and it's not worth arguing about.

> > 2.8.2: we should add a sentence on what happens if the peer receives
> > TEMPORARY_FAILURE and does not understand it (because it's new
> > to this spec).
>=20
> There is text for that alread which says (section 3.10.1):
>=20
>    Types in the range 0 - 16383 are intended for reporting errors. An
>    implementation receiving a Notify payload with one of these types
>    that it does not recognize in a response MUST assume that the
>    corresponding request has failed entirely.
>=20
> So I do not see need to change the the 2.8.2. If change is needed
> perhaps adding pointer to the 3.10.1, but I think even that is not
> needed).

No, this is a very special case - because such implementations are still "R=
FC-compliant". So we should explain how the behavior would still be reasona=
ble with such peers.
> --
> kivinen@iki.fi
>=20
> Scanned by Check Point Total Security Gateway.

From root@core3.amsl.com  Wed Jan 20 08:15:02 2010
Return-Path: 
X-Original-To: ipsec@ietf.org
Delivered-To: ipsec@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 0E5B03A6962; Wed, 20 Jan 2010 08:15:01 -0800 (PST)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20100120161502.0E5B03A6962@core3.amsl.com>
Date: Wed, 20 Jan 2010 08:15:01 -0800 (PST)
Cc: ipsec@ietf.org
Subject: [IPsec] I-D Action:draft-ietf-ipsecme-traffic-visibility-12.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 16:15:02 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF.


	Title           : Wrapped ESP for Traffic Visibility
	Author(s)       : K. Grewal, et al.
	Filename        : draft-ietf-ipsecme-traffic-visibility-12.txt
	Pages           : 15
	Date            : 2010-01-20

This document describes the Wrapped Encapsulating Security 
Payload (WESP) protocol, which builds on the Encapsulating 
Security Payload (ESP) [RFC4303], and is designed to allow 
intermediate devices to (1) ascertain if data confidentiality is 
being employed within ESP and if not, (2) inspect the IPsec 
packets for network monitoring and access control functions.  
Currently in the IPsec ESP standard, there is no deterministic 
way to differentiate between encrypted and unencrypted payloads 
by simply examining a packet. This poses certain challenges to 
the intermediate devices that need to deep inspect the packet 
before making a decision on what should be done with that packet 
(Inspect and/or Allow/Drop). The mechanism described in this 
document can be used to easily disambiguate integrity-only ESP 
from ESP-encrypted packets, without compromising on the security 
provided by ESP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-traffic-visibility-12.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ipsecme-traffic-visibility-12.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-01-20081318.I-D@ietf.org>


--NextPart--

From kivinen@iki.fi  Wed Jan 20 08:29:19 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 442E53A6A29 for ; Wed, 20 Jan 2010 08:29:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.56
X-Spam-Level: 
X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYLi2-av11FD for ; Wed, 20 Jan 2010 08:29:18 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id A23113A6A20 for ; Wed, 20 Jan 2010 08:29:17 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0KGT2kx001659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jan 2010 18:29:02 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0KGT1Kx022717; Wed, 20 Jan 2010 18:29:01 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19287.12109.881311.935809@fireball.kivinen.iki.fi>
Date: Wed, 20 Jan 2010 18:29:01 +0200
From: Tero Kivinen 
To: Yaron Sheffer 
In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21FEA@il-ex01.ad.checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21EF8@il-ex01.ad.checkpoint.com> <19286.62825.898863.477577@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21FEA@il-ex01.ad.checkpoint.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 13 min
X-Total-Time: 13 min
Cc: "ipsec@ietf.org" 
Subject: Re: [IPsec] IKEv2-bis, comments up to 2.16
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 16:29:19 -0000

Yaron Sheffer writes:
> > > 1.4: "The processing of an INFORMATIONAL exchange is determined by
> > > its component payloads." Adding "The payloads are processed in
> > > strict left-to-right order" would make it deterministic, and is
> > > probably what people do today.
> > 
> > There should be no need to make the processing deterministic, as at
> > least I cannot think of case where the processing order would matter,
> > and I do not want someone to start complaining if someone process them
> > in "wrong" order.
> > 
> > I do not think the addition should be done.
> 
> I'm not convinced. CP payloads can do many things, including side
> effects on other network components. Notifications are even more
> open ended, with every IKE extension adding a new one. We should
> recommend some deterministic processing.

None of the current notifications or configuration payloads have such
deterministic processing requirements, and if some extension adds new
notifications of configuration payloads, then that document should
also add requirement for their deterministic processing.

For example in our implementation it is current impossible to process
payloads in the order they appear in the packet, as we first parse all
payloads from the packet, and during that tome process some of the
payloads (for example configration payloads, and some notify
payloads), but then for example delete payloads are processed later
during INFORMATIONAL exchange processing. Also most of the notify
payloads are processed later the initial pass just goes through those
we need to see early (for example the NAT_DETECTION_* payloads), but
some like INITIAL_CONTACT notifications are processed much later (i.e.
only after the IKE_AUTH AUTH payloads has been verified).

Adding requirement for order of payload processing would make
implementation quite a much harder, and as there is currently no
reason for it, I do not think it is good idea to add such requirement. 

> > > 2.4: this sentence is inconsistent: "The INITIAL_CONTACT
> > > notification, if sent, MUST be in the first IKE_AUTH request or
> > > response, not as a separate exchange afterwards; however,
> > > receiving parties MAY ignore it in other messages." If it MUST be
> > > only at a certain location, then it should be ignored (or even
> > > rejected) in others.
> > 
> > No. The first one says where you MUST send it, the second part says
> > what you do if someone does not follow that MUST, which tells you MAY
> > ignore it.
> > 
> > There is no inconsistancy there.
> > 
> > The text is written like this as this was changed between RFC4306 and
> > draft-ietf-ipsecme-ikev2. The RFC4306 does not specify the location,
> > but IKEv2bis does, and because of this old implementations might send
> > INITIAL_CONTACT notifications in wrong place, and the text says that
> > you are free to ignore it in those places.
> > 
> > Support for INITIAL_CONTACT is MAY anyways (both sending and
> > processing it on receive).
> > 
> > So no need to change anything there.
> > 
> OK, the original sentence would suddenly make sense if the word
> "however" were removed.

That would be ok for me.

> > > 2.8.2: we should add a sentence on what happens if the peer receives
> > > TEMPORARY_FAILURE and does not understand it (because it's new
> > > to this spec).
> > 
> > There is text for that alread which says (section 3.10.1):
> > 
> >    Types in the range 0 - 16383 are intended for reporting errors. An
> >    implementation receiving a Notify payload with one of these types
> >    that it does not recognize in a response MUST assume that the
> >    corresponding request has failed entirely.
> > 
> > So I do not see need to change the the 2.8.2. If change is needed
> > perhaps adding pointer to the 3.10.1, but I think even that is not
> > needed).
> 
> No, this is a very special case - because such implementations are
> still "RFC-compliant". So we should explain how the behavior would
> still be reasonable with such peers. 

But if someone makes special code for their implementation to
do something when it receives unknown error notify
(TEMPORARY_FAILURE), wouldn't it be better to instead make code that
understands the notify...

I mean the current code out there following the RFC4306 should be ok,
with new error codes. If it is changed in any way it should be changed
to send and understand TEMPORARY_FAILURE, not to add some special case
for unknown notifications.

Or are you thinking we should explicitly say that "if implementations
follow that 3.10.1 MUST then they work fine when they receive
TEMPORARY_FAILURE notifications even when they do not understand it"?
-- 
kivinen@iki.fi

From yaronf@checkpoint.com  Wed Jan 20 09:10:20 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 342233A694A for ; Wed, 20 Jan 2010 09:10:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzRvkzNcfGKh for ; Wed, 20 Jan 2010 09:10:19 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id DBFB63A67D7 for ; Wed, 20 Jan 2010 09:10:18 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0KHADT7008195; Wed, 20 Jan 2010 19:10:13 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 20 Jan 2010 19:10:27 +0200
From: Yaron Sheffer 
To: Tero Kivinen 
Date: Wed, 20 Jan 2010 19:10:25 +0200
Thread-Topic: [IPsec] IKEv2-bis, comments up to 2.16
Thread-Index: AcqZ7brJCwuMlfmgTyGL9056sOuWMwABTG8A
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A22023@il-ex01.ad.checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21EF8@il-ex01.ad.checkpoint.com> <19286.62825.898863.477577@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21FEA@il-ex01.ad.checkpoint.com> <19287.12109.881311.935809@fireball.kivinen.iki.fi>
In-Reply-To: <19287.12109.881311.935809@fireball.kivinen.iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ipsec@ietf.org" 
Subject: Re: [IPsec] IKEv2-bis, comments up to 2.16
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 17:10:20 -0000

Hi Tero,

I meant exactly what your last paragraph says: the simultaneous rekey text =
is descriptive. We should describe what happens when a "new" peer meets an =
"old" peer, given that BOTH are legitimate.

Thanks,
	Yaron
=20
> -----Original Message-----
> From: Tero Kivinen [mailto:kivinen@iki.fi]
> Sent: Wednesday, January 20, 2010 18:29
> To: Yaron Sheffer
> Cc: ipsec@ietf.org
> Subject: RE: [IPsec] IKEv2-bis, comments up to 2.16
>=20
> Yaron Sheffer writes:
[snip]
>=20
> > > > 2.8.2: we should add a sentence on what happens if the peer
> receives
> > > > TEMPORARY_FAILURE and does not understand it (because it's new
> > > > to this spec).
> > >
> > > There is text for that alread which says (section 3.10.1):
> > >
> > >    Types in the range 0 - 16383 are intended for reporting errors.
> An
> > >    implementation receiving a Notify payload with one of these
> types
> > >    that it does not recognize in a response MUST assume that the
> > >    corresponding request has failed entirely.
> > >
> > > So I do not see need to change the the 2.8.2. If change is needed
> > > perhaps adding pointer to the 3.10.1, but I think even that is not
> > > needed).
> >
> > No, this is a very special case - because such implementations are
> > still "RFC-compliant". So we should explain how the behavior would
> > still be reasonable with such peers.
>=20
> But if someone makes special code for their implementation to
> do something when it receives unknown error notify
> (TEMPORARY_FAILURE), wouldn't it be better to instead make code that
> understands the notify...
>=20
> I mean the current code out there following the RFC4306 should be ok,
> with new error codes. If it is changed in any way it should be changed
> to send and understand TEMPORARY_FAILURE, not to add some special case
> for unknown notifications.
>=20
> Or are you thinking we should explicitly say that "if implementations
> follow that 3.10.1 MUST then they work fine when they receive
> TEMPORARY_FAILURE notifications even when they do not understand it"?
> --
> kivinen@iki.fi
>=20
> Scanned by Check Point Total Security Gateway.

From paul.hoffman@vpnc.org  Wed Jan 20 09:37:56 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C39F63A6943 for ; Wed, 20 Jan 2010 09:37:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level: 
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.047,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cveptGWaxFOK for ; Wed, 20 Jan 2010 09:37:56 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 0E3A83A6924 for ; Wed, 20 Jan 2010 09:37:55 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0KHbov4063007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jan 2010 10:37:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <19286.56461.625405.209156@fireball.kivinen.iki.fi>
References:  <19285.47054.324974.228538@fireball.kivinen.iki.fi>  <19286.56461.625405.209156@fireball.kivinen.iki.fi>
Date: Wed, 20 Jan 2010 09:37:49 -0800
To: Tero Kivinen 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Cc: IPsecme WG 
Subject: Re: [IPsec] Payload order section number (Re: Reviews of section 1 and 2 of the draft-ietf-ipsecme-ikev2)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 17:37:56 -0000

At 12:35 PM +0200 1/20/10, Tero Kivinen wrote:
>Paul Hoffman writes:
>> >BTW, so we are going to leave the reference to point to only section 2
>> >in the end of section 2.5?
>>
>> No, it now says sections 1 and 2.
>
>Not in the draft-ietf-ipsecme-ikev2bis-06.txt. Am I missing something,
>or is there newer version availabe from somewhere?

Sorry. By "now" I mean "the version I am working on with the zillion WG LC comments". That is, the next one.

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Wed Jan 20 11:01:01 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE4893A6916; Wed, 20 Jan 2010 11:01:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6
X-Spam-Level: 
X-Spam-Status: No, score=-6 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sp7UA9yy2R-7; Wed, 20 Jan 2010 11:01:01 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 001903A6905; Wed, 20 Jan 2010 11:01:00 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0KJ0sJf069323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jan 2010 12:00:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: <19284.34317.682796.84636@fireball.kivinen.iki.fi>  <19285.40847.855520.352829@fireball.kivinen.iki.fi>    
Date: Wed, 20 Jan 2010 10:30:54 -0800
To: David Wierbowski 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, Tero Kivinen 
Subject: Re: [IPsec] HTTP_CERT_LOOKUP_SUPPORTED (was: Re: Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1 forward))
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 19:01:01 -0000

At 12:01 AM -0500 1/20/10, David Wierbowski wrote:
> >>I agree with the wording Tero has provided and I think that is
>>>what the intent of the original text was.
>>
>>We disagree here. The point of hash-and-URL was to prevent people from
>sending certs.
>
>We do not disagree.  The point of hash-and-URL is to prevent people from
>sending certs and it does.  The certificate is not sent when when a
>hash-and-URL is used.  A hash and URL of the certificate is sent. That hash
>and URL is sent in a certificate payload.  Note you did not say that the
>point of hash-and-URL is to prevent people from sending certificate
>payloads.  I think Tero's current wording does prevent the cert from being
>sent.

Arrrrgh. "Certificates" vs. "Certificate payloads". I completely missed that in Tero's initial note. This is clearly and editorial problem, I can fix it.

--Paul Hoffman, Director
--VPN Consortium

From yaronf@checkpoint.com  Wed Jan 20 11:15:16 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 756C43A69BA for ; Wed, 20 Jan 2010 11:15:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GNryMMv66ty for ; Wed, 20 Jan 2010 11:15:15 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 316B93A63EB for ; Wed, 20 Jan 2010 11:15:14 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0KJFAT7023956 for ; Wed, 20 Jan 2010 21:15:10 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 20 Jan 2010 21:15:23 +0200
From: Yaron Sheffer 
To: "ipsec@ietf.org" 
Date: Wed, 20 Jan 2010 21:15:21 +0200
Thread-Topic: new traffic visibility draft
Thread-Index: AcqZ6/SqPzqJXV5VS1yh/AoG8S/DBwAF6Jng
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A22034@il-ex01.ad.checkpoint.com>
References: <20100120161502.0E5B03A6962@core3.amsl.com>
In-Reply-To: <20100120161502.0E5B03A6962@core3.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [IPsec] new traffic visibility draft
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 19:15:16 -0000

So we finally have a draft that attempts to resolve all the issues that wer=
e raised by the IESG. As you know, some important changes were made, so if =
you care about the draft (basically every regular participant expressed an =
opinion during the poll...), please reread it now.

Thanks,
	Yaron

> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
> Of Internet-Drafts@ietf.org
> Sent: Wednesday, January 20, 2010 18:15
> To: i-d-announce@ietf.org
> Cc: ipsec@ietf.org
> Subject: [IPsec] I-D Action:draft-ietf-ipsecme-traffic-visibility-
> 12.txt
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IP Security Maintenance and Extensions
> Working Group of the IETF.
>=20
>=20
> 	Title           : Wrapped ESP for Traffic Visibility
> 	Author(s)       : K. Grewal, et al.
> 	Filename        : draft-ietf-ipsecme-traffic-visibility-12.txt
> 	Pages           : 15
> 	Date            : 2010-01-20
>=20
> This document describes the Wrapped Encapsulating Security Payload
> (WESP) protocol, which builds on the Encapsulating Security Payload
> (ESP) [RFC4303], and is designed to allow intermediate devices to (1)
> ascertain if data confidentiality is being employed within ESP and if
> not, (2) inspect the IPsec packets for network monitoring and access
> control functions.
> Currently in the IPsec ESP standard, there is no deterministic way to
> differentiate between encrypted and unencrypted payloads by simply
> examining a packet. This poses certain challenges to the intermediate
> devices that need to deep inspect the packet before making a decision
> on what should be done with that packet (Inspect and/or Allow/Drop).
> The mechanism described in this document can be used to easily
> disambiguate integrity-only ESP from ESP-encrypted packets, without
> compromising on the security provided by ESP.
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-traffic-
> visibility-12.txt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

From paul.hoffman@vpnc.org  Wed Jan 20 13:06:14 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3917E28C0EA for ; Wed, 20 Jan 2010 13:06:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.001
X-Spam-Level: 
X-Spam-Status: No, score=-6.001 tagged_above=-999 required=5 tests=[AWL=0.045,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7s+ZcXwbKAV2 for ; Wed, 20 Jan 2010 13:06:13 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 67D6A28C0E8 for ; Wed, 20 Jan 2010 13:06:13 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0KL68N7076659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Jan 2010 14:06:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
Date: Wed, 20 Jan 2010 13:01:23 -0800
To: IPsecme WG 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: [IPsec] Issue #147: Allowing limited retransmission of one-way IKE messages
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 21:06:14 -0000

Either in 2.1 or in 1.5 we should say something about allowing limited retransmission of the rare one-way IKE messages, for reliability.

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Wed Jan 20 13:06:15 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14E663A68E9 for ; Wed, 20 Jan 2010 13:06:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.002
X-Spam-Level: 
X-Spam-Status: No, score=-6.002 tagged_above=-999 required=5 tests=[AWL=0.044,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BoeiNYwkXMGb for ; Wed, 20 Jan 2010 13:06:14 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 4E78B28C0E8 for ; Wed, 20 Jan 2010 13:06:14 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0KL68NB076659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Jan 2010 14:06:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
Date: Wed, 20 Jan 2010 13:02:28 -0800
To: IPsecme WG 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: [IPsec] Issue #149: Use of "SA" and "SA pair"
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 21:06:15 -0000

2.8: "The responder can be assured that the initiator is prepared to receive messages on an SA if either (1) it has received a cryptographically valid message on the new SA." this should really be "...on the new SA's dual SA" (or better wording thereof) since there's a pair of SAs, and we are determining the state of one based on the other. In general I think we are using the terms SA and SA Pair interchangeably, which is rather confusing.

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Wed Jan 20 13:06:16 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 556D828C0F6 for ; Wed, 20 Jan 2010 13:06:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.002
X-Spam-Level: 
X-Spam-Status: No, score=-6.002 tagged_above=-999 required=5 tests=[AWL=0.044,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0nx8W-A-4pQ for ; Wed, 20 Jan 2010 13:06:15 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id E94FC3A67A7 for ; Wed, 20 Jan 2010 13:06:14 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0KL68ND076659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Jan 2010 14:06:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
Date: Wed, 20 Jan 2010 13:03:44 -0800
To: IPsecme WG 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: [IPsec] Issue #150: What happens if the peer receives TEMPORARY_FAILURE and does not understand it
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 21:06:16 -0000

2.8.2: we should add a sentence on what happens if the peer receives TEMPORARY_FAILURE and does not understand it (because it's new to this spec).

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Wed Jan 20 13:14:40 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFFFC28C101 for ; Wed, 20 Jan 2010 13:14:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.003
X-Spam-Level: 
X-Spam-Status: No, score=-6.003 tagged_above=-999 required=5 tests=[AWL=0.043,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8lFD3mdOVET for ; Wed, 20 Jan 2010 13:14:39 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id C64EE3A68E9 for ; Wed, 20 Jan 2010 13:14:39 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0KL68NH076659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Jan 2010 14:06:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
Date: Wed, 20 Jan 2010 13:05:14 -0800
To: IPsecme WG 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: [IPsec] Issue #152: EAP failure and acknowledgement
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 21:14:40 -0000

2.16: if the responder sends an EAP Failure, is this IKE message acknowledged by the initiator?

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Wed Jan 20 13:14:40 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D892828C10B for ; Wed, 20 Jan 2010 13:14:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.004
X-Spam-Level: 
X-Spam-Status: No, score=-6.004 tagged_above=-999 required=5 tests=[AWL=0.042,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ph05zxxEPp-Q for ; Wed, 20 Jan 2010 13:14:40 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 0BA093A6956 for ; Wed, 20 Jan 2010 13:14:40 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0KL68NJ076659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Jan 2010 14:06:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
Date: Wed, 20 Jan 2010 13:05:54 -0800
To: IPsecme WG 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: [IPsec] Issue #153: List of EAP methods
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 21:14:40 -0000

3.16: I suggest to remove the table quoted from the EAP RFC. There are dozens of methods now in the IANA registry, many of which are preferable to the ones mentioned here.

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Wed Jan 20 13:14:41 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1009E3A68E9 for ; Wed, 20 Jan 2010 13:14:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.005
X-Spam-Level: 
X-Spam-Status: No, score=-6.005 tagged_above=-999 required=5 tests=[AWL=0.041,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaGacsirANJU for ; Wed, 20 Jan 2010 13:14:40 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 49B5528C0F4 for ; Wed, 20 Jan 2010 13:14:40 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0KL68NF076659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Jan 2010 14:06:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
Date: Wed, 20 Jan 2010 13:04:29 -0800
To: IPsecme WG 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: [IPsec] Issue #151: Explicit calculation of AUTH
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 21:14:41 -0000

2.16: it would be useful if we added the explicit calculation of AUTH. For example, is the padding string required for EAP as well? There are two cases, with MSK and with SK_pi+SK_pr.

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Wed Jan 20 13:14:41 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D24A3A68E9 for ; Wed, 20 Jan 2010 13:14:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.005
X-Spam-Level: 
X-Spam-Status: No, score=-6.005 tagged_above=-999 required=5 tests=[AWL=0.041,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kJzAVPqun2F for ; Wed, 20 Jan 2010 13:14:40 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 89E7F28C0FD for ; Wed, 20 Jan 2010 13:14:40 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0KL68N9076659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Jan 2010 14:06:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
Date: Wed, 20 Jan 2010 13:01:52 -0800
To: IPsecme WG 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: [IPsec] Issue #148: Historical cookie discussion
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 21:14:41 -0000

In 2.6, first paragraph: the historical discussion going back to the previous century is very confusing to a newcomer: instead of saying what a cookie is, we tell a story. I suggest to remove this discussion or move it to the end of the section.

Can we separate the cookie discussion into its own subsection? For two reasons: it is an implementation hint, rather than a specification (as opposed to the normative text on SPIs earlier in 2.6); and it is not very important, given the prevalence of DDos.

--Paul Hoffman, Director
--VPN Consortium

From yaronf@checkpoint.com  Wed Jan 20 13:52:37 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B521728C122 for ; Wed, 20 Jan 2010 13:52:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+PJtqMw90fG for ; Wed, 20 Jan 2010 13:52:37 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 9EBE028C121 for ; Wed, 20 Jan 2010 13:52:36 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0KLqVT7011989; Wed, 20 Jan 2010 23:52:31 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 20 Jan 2010 23:52:44 +0200
From: Yaron Sheffer 
To: Paul Hoffman , IPsecme WG 
Date: Wed, 20 Jan 2010 23:52:43 +0200
Thread-Topic: [IPsec] Issue #152: EAP failure and acknowledgement
Thread-Index: AcqaFZ8ZZL149fZsT3qleRXrVuxXPgABHUyQ
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A2203E@il-ex01.ad.checkpoint.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [IPsec] Issue #152: EAP failure and acknowledgement
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 21:52:37 -0000

In fact, the whole message sequence of EAP Failure is not described anywher=
e, and is at best hinted in 2.21.2, which in general assumes the basic 2-me=
ssage IKE_AUTH exchange.

	Yaron

> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
> Of Paul Hoffman
> Sent: Wednesday, January 20, 2010 23:05
> To: IPsecme WG
> Subject: [IPsec] Issue #152: EAP failure and acknowledgement
>=20
> 2.16: if the responder sends an EAP Failure, is this IKE message
> acknowledged by the initiator?
>=20
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>=20
> Scanned by Check Point Total Security Gateway.

From paul.hoffman@vpnc.org  Wed Jan 20 13:57:18 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A5F03A6A97 for ; Wed, 20 Jan 2010 13:57:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.006
X-Spam-Level: 
X-Spam-Status: No, score=-6.006 tagged_above=-999 required=5 tests=[AWL=0.040,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNZZKTZTmwor for ; Wed, 20 Jan 2010 13:57:17 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 579D73A6A2D for ; Wed, 20 Jan 2010 13:57:17 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0KLv2YQ080022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jan 2010 14:57:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21EF8@il-ex01.ad.checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21EF8@il-ex01.ad.checkpoint.com>
Date: Wed, 20 Jan 2010 13:57:00 -0800
To: Yaron Sheffer , "ipsec@ietf.org" 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [IPsec] IKEv2-bis, comments up to 2.16
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 21:57:18 -0000

Thanks for the in-depth review; I expect we will hear more for sections after 2.16. I have incorporated all the editor comments and opened issues for many of the technical ones. Here is my list of ones that I have rejected; it does not include ones that Tero responded to and you agreed to drop. Please let me know if you have any issues with this list.

=====
1.4: "The processing of an INFORMATIONAL exchange is determined by its component payloads." Adding "The payloads are processed in strict left-to-right order" would make it deterministic, and is probably what people do today.

[[ Response: New requirement; not OK. ]]
 
=====
1.4.1: In general the section is very wordy yet confusing: if each peer is responsible for deleting (=sending a delete payload for) its own incoming SAs, then why should we say that "one never sends delete payloads for the two sides of an SA in a single message".
 
[[ Response: The wordiness helps implementers who were not here for the design of IKEv2. ]]

=====
1.4.1: the last paragraph springs a surprise by defining the behavior of IKE SA deletion while discussing an unlikely "messing up" of Child SAs. IKE SA deletion deserves its own subsection.
 
[[ Response: it is optional behavior and makes sense. If you want a section on IKE SA deletion, you have to write it. I propose that it might be very late for doing that. ]]

=====
2: the last paragraph, beginning "The UDP payload" is out of place here.
 
[[ Response: It is useful in the general sense of "IKE Protocol Details and Variations". It is described in more detail later. ]]

=====
2.3: do we allow to send SET_WINDOW_SIZE in the initial exchange? We don't say we don't - although we do say that it would only be effective starting with IKE_AUTH. But I believe we should not accept it until both peers are fully authenticated.

[[ Response: that would be a new prohibition. I don't see text in the current doc indicating this. ]]
 
=====
2.8: "An initiator MAY send a dummy message on a newly created SA if it has no messages queued in order to assure the responder that the initiator is ready to receive messages." A dummy message on an IPsec SA is way out of scope. Whether such messages even exist is a matter of local implementation. We certainly don't have IPsec-level keepalives. Overall, the last 3 paragraphs of 2.8 (starting "There are timing windows") are a mess: you have to read them several times before you realize that this is not normative text, rather it is several implementation alternatives.

[[ Response: I found those paragraphs clear, but I might have missed something. Suggest rewording in a new ticket if you wish. ]]
 
=====
2.15: the value GenIKEHDR is confusing, because it is actually NOT including in the calculation. Is suggest to replace it with a clarifying sentence.
 
[[ That is what we had earlier, and the WG reversed that and wanted it in the diagram. ]]

--Paul Hoffman, Director
--VPN Consortium

From yaronf@checkpoint.com  Wed Jan 20 14:26:20 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B0983A6920 for ; Wed, 20 Jan 2010 14:26:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JSS0UgIEq1g for ; Wed, 20 Jan 2010 14:26:19 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id AF0A93A690F for ; Wed, 20 Jan 2010 14:26:18 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0KMQDT7016402; Thu, 21 Jan 2010 00:26:13 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 21 Jan 2010 00:26:27 +0200
From: Yaron Sheffer 
To: Paul Hoffman , "ipsec@ietf.org" 
Date: Thu, 21 Jan 2010 00:26:24 +0200
Thread-Topic: [IPsec] IKEv2-bis, comments up to 2.16
Thread-Index: AcqaG45bE9TxxuuSRkmcRxB7DnWUbgAAHgVA
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A22040@il-ex01.ad.checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21EF8@il-ex01.ad.checkpoint.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [IPsec] IKEv2-bis, comments up to 2.16
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 22:26:20 -0000

Hi Paul,

Thanks for rejecting my issues so quickly :-) Please see some comments belo=
w. I have deleted issues where I accept the rejection.

	Yaron

> -----Original Message-----
>=20
> =3D=3D=3D=3D=3D
> 1.4.1: the last paragraph springs a surprise by defining the behavior
> of IKE SA deletion while discussing an unlikely "messing up" of Child
> SAs. IKE SA deletion deserves its own subsection.
>=20
> [[ Response: it is optional behavior and makes sense. If you want a
> section on IKE SA deletion, you have to write it. I propose that it
> might be very late for doing that. ]]
>
I suggest replacing the last paragraph by the following text (not a new sec=
tion, though):

Similarly to ESP and HA SAs, IKE SAs are also deleted by sending an Informa=
tional exchange. Deleting an IKE SA implicitly closes any remaining Child S=
As negotiated under it. The response to a request that deletes the IKE SA i=
s an empty INFORMATIONAL response.

Half-closed ESP or AH connections are anomalous, and a node with auditing c=
apability should probably audit their existence if they persist. Note that =
this specification nowhere specifies time periods, so it is up to individua=
l endpoints to decide how long to wait. A node MAY refuse to accept incomin=
g data on half-closed connections but MUST NOT unilaterally close them and =
reuse the SPIs. If connection state becomes sufficiently messed up, a node =
MAY close the IKE SA, as described above. It can then rebuild the SAs it ne=
eds on a clean base under a new IKE SA.
=20
> =3D=3D=3D=3D=3D
> 2: the last paragraph, beginning "The UDP payload" is out of place
> here.
>=20
> [[ Response: It is useful in the general sense of "IKE Protocol Details
> and Variations". It is described in more detail later. ]]
>=20
Yeah well, it still sticks out like a sore thumb. And it's fully described =
in 2.23, so it's redundant here.
> =3D=3D=3D=3D=3D
> 2.3: do we allow to send SET_WINDOW_SIZE in the initial exchange? We
> don't say we don't - although we do say that it would only be effective
> starting with IKE_AUTH. But I believe we should not accept it until
> both peers are fully authenticated.
>=20
> [[ Response: that would be a new prohibition. I don't see text in the
> current doc indicating this. ]]
>=20
In fact we do: "The window size is always one until the initial exchanges c=
omplete." And Tero mentioned correctly that the "initial exchanges" are bot=
h IKE_SA_INIT and IKE_AUTH. The current text is fine.
> =3D=3D=3D=3D=3D
> 2.8: "An initiator MAY send a dummy message on a newly created SA if it
> has no messages queued in order to assure the responder that the
> initiator is ready to receive messages." A dummy message on an IPsec SA
> is way out of scope. Whether such messages even exist is a matter of
> local implementation. We certainly don't have IPsec-level keepalives.

> Overall, the last 3 paragraphs of 2.8 (starting "There are timing
> windows") are a mess: you have to read them several times before you
> realize that this is not normative text, rather it is several
> implementation alternatives.
>=20
> [[ Response: I found those paragraphs clear, but I might have missed
> something. Suggest rewording in a new ticket if you wish. ]]
>=20
I will pass on the last 3 paragraphs. But please open an issue regarding th=
e "dummy message" text (the first part of my text above).

> --Paul Hoffman, Director
> --VPN Consortium
>=20
> Scanned by Check Point Total Security Gateway.

From root@core3.amsl.com  Wed Jan 20 14:30:02 2010
Return-Path: 
X-Original-To: ipsec@ietf.org
Delivered-To: ipsec@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 052703A6A97; Wed, 20 Jan 2010 14:30:01 -0800 (PST)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20100120223002.052703A6A97@core3.amsl.com>
Date: Wed, 20 Jan 2010 14:30:01 -0800 (PST)
Cc: ipsec@ietf.org
Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2bis-07.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 22:30:02 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF.


	Title           : Internet Key Exchange Protocol: IKEv2
	Author(s)       : C. Kaufman, et al.
	Filename        : draft-ietf-ipsecme-ikev2bis-07.txt
	Pages           : 159
	Date            : 2010-01-20

This document describes version 2 of the Internet Key Exchange (IKE)
protocol.  IKE is a component of IPsec used for performing mutual
authentication and establishing and maintaining security associations
(SAs).  This document replaces and updates RFC 4306, and includes all
of the clarifications from RFC 4718.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2bis-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ipsecme-ikev2bis-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-01-20142919.I-D@ietf.org>


--NextPart--

From paul.hoffman@vpnc.org  Wed Jan 20 15:03:36 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2739B3A69BB for ; Wed, 20 Jan 2010 15:03:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.007
X-Spam-Level: 
X-Spam-Status: No, score=-6.007 tagged_above=-999 required=5 tests=[AWL=0.039,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1X717Z5L2GT for ; Wed, 20 Jan 2010 15:03:35 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 590DD3A67D4 for ; Wed, 20 Jan 2010 15:03:35 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0KN3TLS084175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Jan 2010 16:03:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
Date: Wed, 20 Jan 2010 15:03:28 -0800
To: IPsecme WG 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: [IPsec] New IKEv2bis draft posted; please help close out the open issues
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 23:03:36 -0000

Greetings again. The -07 draft is now posted. You can see the numerous diffs at . Please review them to be sure I didn't screw anything up.

But, more importantly, there are 22 open issues () that we want to close *soon*. I have opened up email threads for each one already. Please read each open issue and weigh in, even if it is a two-word response. We can't go to IETF Last Call with this many open issues, and we would like to close them all out if possible.

--Paul Hoffman, Director
--VPN Consortium

From welterk@us.ibm.com  Wed Jan 20 17:30:41 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E79F3A67E1 for ; Wed, 20 Jan 2010 17:30:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MK2Mq9YgfG0V for ; Wed, 20 Jan 2010 17:30:40 -0800 (PST)
Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by core3.amsl.com (Postfix) with ESMTP id 1FEBC3A69C4 for ; Wed, 20 Jan 2010 17:30:40 -0800 (PST)
Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e37.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id o0L1T6wt012550 for ; Wed, 20 Jan 2010 18:29:06 -0700
Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id o0L1UNXN226806 for ; Wed, 20 Jan 2010 18:30:23 -0700
Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o0L1UKiq003814 for ; Wed, 20 Jan 2010 18:30:20 -0700
Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av01.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o0L1UJjh003771 for ; Wed, 20 Jan 2010 18:30:19 -0700
In-Reply-To: 
References: 
To: ipsec@ietf.org
MIME-Version: 1.0
X-KeepSent: EC692D84:C55B4E79-882576B2:00074139; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009
From: Keith Welter 
X-MIMETrack: S/MIME Sign by Notes Client on Keith Welter/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/20/2010 05:30:14 PM, Serialize by Notes Client on Keith Welter/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 01/20/2010 05:30:14 PM, Serialize complete at 01/20/2010 05:30:14 PM, S/MIME Sign failed at 01/20/2010 05:30:14 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 01/20/2010 18:30:19, Serialize complete at 01/20/2010 18:30:19
Message-ID: 
Date: Wed, 20 Jan 2010 17:30:18 -0800
Content-Type: multipart/alternative; boundary="=_alternative 00084334882576B2_="
Subject: Re: [IPsec] Issue #150: What happens if the peer receives TEMPORARY_FAILURE and does not understand it
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 01:30:41 -0000

This is a multipart message in MIME format.
--=_alternative 00084334882576B2_=
Content-Type: text/plain; charset="US-ASCII"

Tero Kivinen and David Wierbowski had some discussions on and off the list
that resulted in the new text in 2.8.2 that mentions sending 
TEMPOARY_FAILURE
and I acted as the scribe.  I have been a proponent of avoiding sending 
TEMPORARY_FAILURE to a peer that does not understand it by incrementing 
the
minor version number and only sending it to IKEv2.1 peers.  Incrementing
the minor version number got shot down, primarily by Tero.  Therefore, 
perhaps Tero could suggest the additional sentence for section 2.8.2 
that describes what will happen if a peer that does not understand
TEMPORARY_FAILURE receives it.

> Message: 3
> Date: Wed, 20 Jan 2010 13:03:44 -0800
> From: Paul Hoffman 
> Subject: [IPsec] Issue #150: What happens if the peer receives
>    TEMPORARY_FAILURE and does not understand it
> To: IPsecme WG 
> Message-ID: 
> Content-Type: text/plain; charset="us-ascii"
> 
> 2.8.2: we should add a sentence on what happens if the peer receives 
> TEMPORARY_FAILURE and does not understand it (because it's new to this 
spec).

--=_alternative 00084334882576B2_=
Content-Type: text/html; charset="US-ASCII"



Tero Kivinen and David Wierbowski had some discussions
on and off the list

that resulted in the new text in 2.8.2 that mentions
sending TEMPOARY_FAILURE

and I acted as the scribe.  I have been a proponent
of avoiding sending 

TEMPORARY_FAILURE to a peer that does not understand
it by incrementing the

minor version number and only sending it to IKEv2.1
peers.  Incrementing

the minor version number got shot down, primarily
by Tero.  Therefore, 

perhaps Tero could suggest the additional sentence
for section 2.8.2 

that describes what will happen if a peer that does
not understand

TEMPORARY_FAILURE receives it.



> Message: 3

> Date: Wed, 20 Jan 2010 13:03:44 -0800

> From: Paul Hoffman <paul.hoffman@vpnc.org>

> Subject: [IPsec] Issue #150: What happens if the peer receives

>    TEMPORARY_FAILURE and does not understand it

> To: IPsecme WG <ipsec@ietf.org>

> Message-ID: <p0624080fc77d20105f39@[10.20.30.158]>

> Content-Type: text/plain; charset="us-ascii"

> 

> 2.8.2: we should add a sentence on what happens if the peer receives


> TEMPORARY_FAILURE and does not understand it (because it's new to
this spec).


--=_alternative 00084334882576B2_=--

From ynir@checkpoint.com  Wed Jan 20 22:11:26 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E70363A6876 for ; Wed, 20 Jan 2010 22:11:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQs2IFZRlxVy for ; Wed, 20 Jan 2010 22:11:25 -0800 (PST)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 28F333A692C for ; Wed, 20 Jan 2010 22:11:18 -0800 (PST)
X-CheckPoint: {4B57ED94-10000-14201DC2-FFFF}
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 9F78A29C005; Thu, 21 Jan 2010 08:11:14 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 843AA29C002; Thu, 21 Jan 2010 08:11:14 +0200 (IST)
X-CheckPoint: {4B57ED93-10000-14201DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0L6BET7019750; Thu, 21 Jan 2010 08:11:14 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 21 Jan 2010 08:11:28 +0200
From: Yoav Nir 
To: Paul Hoffman 
Date: Thu, 21 Jan 2010 08:11:05 +0200
Thread-Topic: [IPsec] Issue #150: What happens if the peer receives TEMPORARY_FAILURE and does not understand it
Thread-Index: AcqaYJDtEaHdJwn0TgOszham1u0Ycg==
Message-ID: <9A8CAD98-1E6C-4C5D-AAB2-580FFECF6CAC@checkpoint.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IPsecme WG 
Subject: Re: [IPsec] Issue #150: What happens if the peer receives TEMPORARY_FAILURE and does not understand it
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 06:11:27 -0000

We can't really prescribe actions for (presumably older) implementations th=
at don't support this spec. =20

Such implementations will do what it says in RFC 4306 and the clarification=
s document: TEMPORARY_FAILURE is an error notification, so therefore the ex=
change failed. In that case the old SA remains until this or the other end =
deletes it. If the other side has rekeyed, we're fine.

On Jan 20, 2010, at 11:03 PM, Paul Hoffman wrote:

> 2.8.2: we should add a sentence on what happens if the peer receives TEMP=
ORARY_FAILURE and does not understand it (because it's new to this spec).
>=20
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>=20
> Scanned by Check Point Total Security Gateway.


From ynir@checkpoint.com  Wed Jan 20 22:28:38 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9498A3A6876 for ; Wed, 20 Jan 2010 22:28:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoRQUj0B0aRO for ; Wed, 20 Jan 2010 22:28:37 -0800 (PST)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 569E03A67AE for ; Wed, 20 Jan 2010 22:28:37 -0800 (PST)
X-CheckPoint: {4B57F1A2-10001-14201DC2-FFFF}
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 9E6BD29C005; Thu, 21 Jan 2010 08:28:32 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 8137129C002; Thu, 21 Jan 2010 08:28:32 +0200 (IST)
X-CheckPoint: {4B57F1A1-10000-14201DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0L6SWT7020857; Thu, 21 Jan 2010 08:28:32 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 21 Jan 2010 08:28:46 +0200
From: Yoav Nir 
To: Paul Hoffman 
Date: Thu, 21 Jan 2010 08:28:24 +0200
Thread-Topic: [IPsec] Issue #153: List of EAP methods
Thread-Index: AcqaYvwibQ6mRNJbSFGS9uKF4JjUaQ==
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IPsecme WG 
Subject: Re: [IPsec] Issue #153: List of EAP methods
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 06:28:38 -0000

Agree. Certainly types 4-6 have to be removed, as they are just methods, an=
d we RECOMMEND not to use them. I can see some value in mentioning type 1 (=
Identity), because later in that same section we mention that the responder=
 should not send such requests. I think we should remove all the rest, thou=
gh.
=20
On Jan 20, 2010, at 11:05 PM, Paul Hoffman wrote:

> 3.16: I suggest to remove the table quoted from the EAP RFC. There are do=
zens of methods now in the IANA registry, many of which are preferable to t=
he ones mentioned here.
>=20
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>=20
> Scanned by Check Point Total Security Gateway.


From ynir@checkpoint.com  Wed Jan 20 22:31:09 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEFD23A698E for ; Wed, 20 Jan 2010 22:31:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYN+igCDsTsN for ; Wed, 20 Jan 2010 22:31:09 -0800 (PST)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id EFD123A683B for ; Wed, 20 Jan 2010 22:31:08 -0800 (PST)
X-CheckPoint: {4B57F239-10005-14201DC2-FFFF}
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id A516E29C005; Thu, 21 Jan 2010 08:31:04 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 85BAB29C002; Thu, 21 Jan 2010 08:31:04 +0200 (IST)
X-CheckPoint: {4B57F239-10000-14201DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0L6V4T7021008; Thu, 21 Jan 2010 08:31:04 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 21 Jan 2010 08:31:18 +0200
From: Yoav Nir 
To: Paul Hoffman 
Date: Thu, 21 Jan 2010 08:30:56 +0200
Thread-Topic: [IPsec] Issue #152: EAP failure and acknowledgement
Thread-Index: AcqaY1bYpFMj/bOhS/WHQQZbXqtRdQ==
Message-ID: <051FD100-9869-4286-939D-C3C0F6FF536D@checkpoint.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IPsecme WG 
Subject: Re: [IPsec] Issue #152: EAP failure and acknowledgement
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 06:31:09 -0000

We do have this:

                                                                The
   responder MAY at any time terminate the IKE exchange by sending an
   EAP payload containing the Failure message.

I guess "terminate" means that the initiator does not send any more message=
s.=20

This is also one of the places where there is an ambiguity as to the meanin=
g of "exchange". Usually an "exchange" is one request-response pair, but he=
re it seems to be referring to the entire series of IKE_AUTH requests and r=
esponses.

On Jan 20, 2010, at 11:05 PM, Paul Hoffman wrote:

> 2.16: if the responder sends an EAP Failure, is this IKE message acknowle=
dged by the initiator?
>=20
> --Paul Hoffman, Director
> --VPN Consortium


From ynir@checkpoint.com  Wed Jan 20 22:33:37 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7C663A6848 for ; Wed, 20 Jan 2010 22:33:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1zcARE2-y4v for ; Wed, 20 Jan 2010 22:33:37 -0800 (PST)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id F21683A683B for ; Wed, 20 Jan 2010 22:33:36 -0800 (PST)
X-CheckPoint: {4B57F2CD-10009-14201DC2-FFFF}
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id A742129C005; Thu, 21 Jan 2010 08:33:32 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 8F1CB29C002; Thu, 21 Jan 2010 08:33:32 +0200 (IST)
X-CheckPoint: {4B57F2CD-10004-14201DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0L6XWT7021234; Thu, 21 Jan 2010 08:33:32 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 21 Jan 2010 08:33:46 +0200
From: Yoav Nir 
To: Paul Hoffman 
Date: Thu, 21 Jan 2010 08:33:23 +0200
Thread-Topic: [IPsec] Issue #148: Historical cookie discussion
Thread-Index: AcqaY667EdT3IRDVSi+NMQ9WWBnn6w==
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IPsecme WG 
Subject: Re: [IPsec] Issue #148: Historical cookie discussion
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 06:33:38 -0000

I think remove. Also the reference to PHOTURIS

On Jan 20, 2010, at 11:01 PM, Paul Hoffman wrote:

> In 2.6, first paragraph: the historical discussion going back to the prev=
ious century is very confusing to a newcomer: instead of saying what a cook=
ie is, we tell a story. I suggest to remove this discussion or move it to t=
he end of the section.
>=20
> Can we separate the cookie discussion into its own subsection? For two re=
asons: it is an implementation hint, rather than a specification (as oppose=
d to the normative text on SPIs earlier in 2.6); and it is not very importa=
nt, given the prevalence of DDos.
>=20
> --Paul Hoffman, Director
> --VPN Consortium


From yaronf@checkpoint.com  Wed Jan 20 23:26:32 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CB663A690B for ; Wed, 20 Jan 2010 23:26:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7goi0IntEfq0 for ; Wed, 20 Jan 2010 23:26:31 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 4E6DC3A67FB for ; Wed, 20 Jan 2010 23:26:30 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0L7QPT7025170; Thu, 21 Jan 2010 09:26:25 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 21 Jan 2010 09:26:39 +0200
From: Yaron Sheffer 
To: Yoav Nir , Paul Hoffman 
Date: Thu, 21 Jan 2010 09:26:36 +0200
Thread-Topic: [IPsec] Issue #150: What happens if the peer receives TEMPORARY_FAILURE and does not understand it
Thread-Index: AcqaYJDtEaHdJwn0TgOszham1u0YcgAChXEQ
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A22061@il-ex01.ad.checkpoint.com>
References:  <9A8CAD98-1E6C-4C5D-AAB2-580FFECF6CAC@checkpoint.com>
In-Reply-To: <9A8CAD98-1E6C-4C5D-AAB2-580FFECF6CAC@checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IPsecme WG 
Subject: Re: [IPsec] Issue #150: What happens if the peer receives TEMPORARY_FAILURE and does not understand it
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 07:26:32 -0000

See my earlier mail exchange with Tero. That section is descriptive, not pr=
escriptive, and we should describe why the (new) message sequence works fin=
e with older clients, even though they obviously don't support the new noti=
fication. What you say below may be sufficient: there's stale state lying a=
round, but both sides still agree on the correct IKE SA to use.

Thanks,
	Yaron

> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
> Of Yoav Nir
> Sent: Thursday, January 21, 2010 8:11
> To: Paul Hoffman
> Cc: IPsecme WG
> Subject: Re: [IPsec] Issue #150: What happens if the peer receives
> TEMPORARY_FAILURE and does not understand it
>=20
> We can't really prescribe actions for (presumably older)
> implementations that don't support this spec.
>=20
> Such implementations will do what it says in RFC 4306 and the
> clarifications document: TEMPORARY_FAILURE is an error notification, so
> therefore the exchange failed. In that case the old SA remains until
> this or the other end deletes it. If the other side has rekeyed, we're
> fine.
>=20
> On Jan 20, 2010, at 11:03 PM, Paul Hoffman wrote:
>=20
> > 2.8.2: we should add a sentence on what happens if the peer receives
> TEMPORARY_FAILURE and does not understand it (because it's new to this
> spec).
> >
> > --Paul Hoffman, Director
> > --VPN Consortium
> > _______________________________________________
> > IPsec mailing list
> > IPsec@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipsec
> >
> > Scanned by Check Point Total Security Gateway.
>=20
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>=20
> Scanned by Check Point Total Security Gateway.

From yaronf@checkpoint.com  Wed Jan 20 23:39:48 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A32A23A68D6 for ; Wed, 20 Jan 2010 23:39:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqyWA9mrPPDC for ; Wed, 20 Jan 2010 23:39:48 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 829373A67C1 for ; Wed, 20 Jan 2010 23:39:47 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0L7dgT7026434 for ; Thu, 21 Jan 2010 09:39:42 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 21 Jan 2010 09:39:56 +0200
From: Yaron Sheffer 
To: IPsecme WG 
Date: Thu, 21 Jan 2010 09:39:54 +0200
Thread-Topic: Issue #154: Sending dummy messages during rekey
Thread-Index: AcqabMJ8FkJGTTWZSye9923sViI/5QAAA2VQ
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A22069@il-ex01.ad.checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: [IPsec] Issue #154: Sending dummy messages during rekey
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 07:39:48 -0000

U2VjLiAyLjg6ICJBbiBpbml0aWF0b3IgTUFZIHNlbmQgYSBkdW1teSBtZXNzYWdlIG9uIGEgbmV3
bHkgY3JlYXRlZCBTQSBpZg0KIGl0IGhhcyBubyBtZXNzYWdlcyBxdWV1ZWQgaW4gb3JkZXIgdG8g
YXNzdXJlIHRoZSByZXNwb25kZXIgdGhhdCB0aGUNCiBpbml0aWF0b3IgaXMgcmVhZHkgdG8gcmVj
ZWl2ZSBtZXNzYWdlcy4iDQoNCiBBIGR1bW15IChoaWdoZXIgbGV2ZWwgcHJvdG9jb2wpIG1lc3Nh
Z2Ugb24gYW4gSVBzZWMgU0EgaXMgd2F5IG91dCBvZg0KIHNjb3BlLiBXaGV0aGVyIHN1Y2ggbWVz
c2FnZXMgZXZlbiBleGlzdCBpcyBhIG1hdHRlciBvZiBsb2NhbA0KIGltcGxlbWVudGF0aW9uLg0K
DQogT3IgZG9lcyB0aGUgZG9jdW1lbnQgcmVmZXIgdG8gImR1bW15IEVTUCBtZXNzYWdlcyIgKFJG
QyA0MzAzLCBzZWMuIDIuNik/DQogSWYgc28sIHBsZWFzZSBhZGQgdGhlIHJlZmVyZW5jZS4NCg0K
LS0gDQpUaWNrZXQgVVJMOiA8aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvaXBzZWNtZS90
cmFjL3RpY2tldC8xNTQ+DQppcHNlY21lIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaXBzZWNtZS8+
DQoNCg0KU2Nhbm5lZCBieSBDaGVjayBQb2ludCBUb3RhbCBTZWN1cml0eSBHYXRld2F5Lg0K

From ynir@checkpoint.com  Wed Jan 20 23:49:26 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC1113A6882 for ; Wed, 20 Jan 2010 23:49:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJ22qADxVS5o for ; Wed, 20 Jan 2010 23:49:26 -0800 (PST)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id C04833A6800 for ; Wed, 20 Jan 2010 23:49:25 -0800 (PST)
X-CheckPoint: {4B580491-10004-14201DC2-FFFF}
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 3620A29C009; Thu, 21 Jan 2010 09:49:21 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 19A2E29C002; Thu, 21 Jan 2010 09:49:21 +0200 (IST)
X-CheckPoint: {4B580491-10000-14201DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0L7nKT7027429; Thu, 21 Jan 2010 09:49:20 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 21 Jan 2010 09:49:34 +0200
From: Yoav Nir 
To: Paul Hoffman 
Date: Thu, 21 Jan 2010 09:49:11 +0200
Thread-Topic: [IPsec] Issue #138: Calculations involving Ni/Nr
Thread-Index: AcqabkWsUlLLwXMHSIy1cBcr1M2fEQ==
Message-ID: 
References: <064.0e5659162c4e55745d66c3ac8e8be7f8@tools.ietf.org> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IPsecme WG 
Subject: Re: [IPsec] Issue #138: Calculations involving Ni/Nr
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 07:49:27 -0000

I agree, and I don't think you need brackets:

only the first 64 bits of Ni and the first 64 bits of Nr are used in calcul=
ating SKEYSEED, but all the bits are used for input to the prf+ function.


(although I personally did not find it confusing)

On Jan 19, 2010, at 4:25 AM, Paul Hoffman wrote:

> Section 2.14: "only the first 64 bits of Ni and the first 64 bits of
> Nr are used in the calculation". This section has two calculations
> involving Ni/Nr, but this sentence should only apply to the former.
> Suggested rephrasing: "the calculation" -> "when calculating SKEYSEED
> (but all bits are used when calculating SK_*)"
>=20
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>=20
> Scanned by Check Point Total Security Gateway.


From ynir@checkpoint.com  Thu Jan 21 00:18:29 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 418473A69AE for ; Thu, 21 Jan 2010 00:18:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjzGeXVFQpiq for ; Thu, 21 Jan 2010 00:18:28 -0800 (PST)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id E48333A68BE for ; Thu, 21 Jan 2010 00:18:27 -0800 (PST)
X-CheckPoint: {4B580B5F-10004-14201DC2-FFFF}
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 4790829C005; Thu, 21 Jan 2010 10:18:23 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 2285729C002; Thu, 21 Jan 2010 10:18:23 +0200 (IST)
X-CheckPoint: {4B580B5F-10000-14201DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0L8IMT7000834; Thu, 21 Jan 2010 10:18:23 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 21 Jan 2010 10:18:36 +0200
From: Yoav Nir 
To: Paul Hoffman 
Date: Thu, 21 Jan 2010 10:18:14 +0200
Thread-Topic: [IPsec] Issue #139: Keying material taken in the order for RoHC
Thread-Index: AcqaclRvaZvKKtaESr6uNBFCP8VRlw==
Message-ID: <8C41856B-9D3B-4442-B214-5ED60C23906A@checkpoint.com>
References: <064.cff10879f1e3e888fa8930a85464b847@tools.ietf.org> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IPsecme WG 
Subject: Re: [IPsec] Issue #139: Keying material taken in the order for RoHC
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 08:18:29 -0000

I think extensions such as RoHC that change (or extend) the way keying mate=
rial is generated, should and do specify how it is done. Leaving that text =
there becomes a  recommendation for future draft writers, which I think is =
superfluous.

I think we should leave the text as it is.

On Jan 19, 2010, at 4:26 AM, Paul Hoffman wrote:

> One of the differences between RFC 4306 and the IKEv2bis draft is in
> Section 2.17, Generating Key Material for Child SAs. Appendix E.2 of the
> IKEv2bis draft indicates the following:
>=20
> In Section 2.17, removed "If multiple IPsec protocols are negotiated,
> keying material is taken in the order in which the protocol headers
> will appear in the encapsulated packet" because multiple IPsec
> protocols cannot be negotiated at one time.
>=20
> Is it possible to leave the quoted text in the spec? I agree that multipl=
e
> IPsec protocols cannot be negotiated at one time; however, the text is
> useful for ROHCoIPsec implementers, where multiple keys may need to be
> generated for a ROHC-enabled Child SA.
>=20
> For example, if a ROHC-enabled Child-SA with ROHC_INTEG [draft-ietf-rohc-
> ikev2-extensions-hcoipsec-09] is instantiated, first the IPsec
> encryption/authentication keying material will be taken, then an
> additional key will be taken for the algorithm used to verify the proper
> decompression of packet headers.
>=20
> Also:
>=20
> The original text in RFC 4306 was slightly confusing, but I think we
> should leave room for ROHCoIPsec here. Perhaps adding something like
> this after the bulleted list?
>=20
>    If the Child SA negotiation includes some future IPsec protocol(s)
>    in addition to (or instead of) ESP or AH (e.g., ROHC_INTEG), then
>    (1) all keys for SAs carrying data from the initiator to the
>    responder are taken before SAs going in the reverse direction, and
>    (2) keying material for the IPsec protocols are taken in the order
>    in which the protocol headers will appear in the encapsulated
>    packet.
>=20
> --Paul Hoffman, Director
> --VPN Consortium


From svanru@gmail.com  Thu Jan 21 00:55:22 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A9AD3A697A for ; Thu, 21 Jan 2010 00:55:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level: 
X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, XMAILER_MIMEOLE_OL_7533E=0.513]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+-ZhFXaBfn8 for ; Thu, 21 Jan 2010 00:55:21 -0800 (PST)
Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by core3.amsl.com (Postfix) with ESMTP id 9B8833A68DA for ; Thu, 21 Jan 2010 00:55:20 -0800 (PST)
Received: by ewy10 with SMTP id 10so669379ewy.14 for ; Thu, 21 Jan 2010 00:55:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:cc :references:subject:date:mime-version:content-type :content-transfer-encoding:x-priority:x-msmail-priority:x-mailer :x-mimeole; bh=hrcyhhwdB5af/ReX4ZtU0hCTcwSSQeEPEJ07c9uo0QA=; b=ah5pMTVM+J+IpDu94WYcW3JzHwU1sbVy3G4ft+zG1U1Tcc4MIYohpF/lXhl4893Nz8 jAz3wx7dyaQEFcOUIID3sFScjySgDF3VrJqvOY7wnUYr7s7eGnKizexSR/agD8wtceU0 tT5BIBfxVnP/M1r2VILKBal5mVmxYJptwFBq8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=oqO3Z2Tpaaphl7iKsaGAjNw0i0nN5ewK2r+FicsYcHWTz3tlxfNWtGaN89Pj64Mw/Q s1AuI5yfA7gsSHj2BOpeW0nu3hUAvYrzYuXml6p5v920BYVtg5YLCikU/freFJ5LHU4O glZaZ+kvU9BNDHdbLqCI3Ve1Bbd0gP6WQNeEw=
Received: by 10.213.23.156 with SMTP id r28mr1078639ebb.56.1264064108686; Thu, 21 Jan 2010 00:55:08 -0800 (PST)
Received: from svanpc ([82.138.51.4]) by mx.google.com with ESMTPS id 16sm658175ewy.2.2010.01.21.00.55.07 (version=SSLv3 cipher=RC4-MD5); Thu, 21 Jan 2010 00:55:08 -0800 (PST)
Message-ID: 
From: "Valery Smyslov" 
To: "Yoav Nir" , "Paul Hoffman" 
References: <064.cff10879f1e3e888fa8930a85464b847@tools.ietf.org> <8C41856B-9D3B-4442-B214-5ED60C23906A@checkpoint.com>
Date: Thu, 21 Jan 2010 11:55:47 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4963.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700
Cc: IPsecme WG 
Subject: Re: [IPsec] Issue #139: Keying material taken in the order for RoHC
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 08:55:22 -0000

Hi Yoav,

> I think extensions such as RoHC that change (or extend) the way keying
material is generated, should and do specify how it is done.

I don't think so. If multiple protocols are involves, the way how (in which
order)
each of them obtains its key from IKE keying material is in general out of
scope of
individual protocol specifications. Look, for example, at ESP, where
one generic rule exists, regardless of algorithms involved: first we take
keying bits for encryption (or combined) algorithm and then for
authentication algorithm.

Proposed text establishes similar generic rule for protocols.

I support adding proposed text to help interoperability.

Regards,
Valery Smyslov.

> On Jan 19, 2010, at 4:26 AM, Paul Hoffman wrote:
>
> > One of the differences between RFC 4306 and the IKEv2bis draft is in
> > Section 2.17, Generating Key Material for Child SAs. Appendix E.2 of the
> > IKEv2bis draft indicates the following:
> >
> > In Section 2.17, removed "If multiple IPsec protocols are negotiated,
> > keying material is taken in the order in which the protocol headers
> > will appear in the encapsulated packet" because multiple IPsec
> > protocols cannot be negotiated at one time.
> >
> > Is it possible to leave the quoted text in the spec? I agree that
multiple
> > IPsec protocols cannot be negotiated at one time; however, the text is
> > useful for ROHCoIPsec implementers, where multiple keys may need to be
> > generated for a ROHC-enabled Child SA.
> >
> > For example, if a ROHC-enabled Child-SA with ROHC_INTEG
[draft-ietf-rohc-
> > ikev2-extensions-hcoipsec-09] is instantiated, first the IPsec
> > encryption/authentication keying material will be taken, then an
> > additional key will be taken for the algorithm used to verify the proper
> > decompression of packet headers.
> >
> > Also:
> >
> > The original text in RFC 4306 was slightly confusing, but I think we
> > should leave room for ROHCoIPsec here. Perhaps adding something like
> > this after the bulleted list?
> >
> >    If the Child SA negotiation includes some future IPsec protocol(s)
> >    in addition to (or instead of) ESP or AH (e.g., ROHC_INTEG), then
> >    (1) all keys for SAs carrying data from the initiator to the
> >    responder are taken before SAs going in the reverse direction, and
> >    (2) keying material for the IPsec protocols are taken in the order
> >    in which the protocol headers will appear in the encapsulated
> >    packet.
> >
> > --Paul Hoffman, Director
> > --VPN Consortium
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec


From kivinen@iki.fi  Thu Jan 21 01:08:50 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC2FC3A68DA for ; Thu, 21 Jan 2010 01:08:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.562
X-Spam-Level: 
X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLnugpdTnLkY for ; Thu, 21 Jan 2010 01:08:50 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id BC2C93A6827 for ; Thu, 21 Jan 2010 01:08:49 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0L98ZMF015590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jan 2010 11:08:36 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0L98Zie019033; Thu, 21 Jan 2010 11:08:35 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19288.6547.134892.584511@fireball.kivinen.iki.fi>
Date: Thu, 21 Jan 2010 11:08:35 +0200
From: Tero Kivinen 
To: Yaron Sheffer 
In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A22040@il-ex01.ad.checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21EF8@il-ex01.ad.checkpoint.com>  <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A22040@il-ex01.ad.checkpoint.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 3 min
X-Total-Time: 3 min
Cc: "ipsec@ietf.org" , Paul Hoffman 
Subject: Re: [IPsec] IKEv2-bis, comments up to 2.16
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 09:08:51 -0000

Yaron Sheffer writes:
> > 1.4.1: the last paragraph springs a surprise by defining the behavior
> > of IKE SA deletion while discussing an unlikely "messing up" of Child
> > SAs. IKE SA deletion deserves its own subsection.
> > 
> > [[ Response: it is optional behavior and makes sense. If you want a
> > section on IKE SA deletion, you have to write it. I propose that it
> > might be very late for doing that. ]]
> >
> I suggest replacing the last paragraph by the following text (not a
> new section, though): 
> 
> Similarly to ESP and HA SAs, IKE SAs are also deleted by sending an
> Informational exchange. Deleting an IKE SA implicitly closes any
> remaining Child SAs negotiated under it. The response to a request
> that deletes the IKE SA is an empty INFORMATIONAL response. 
> 
> Half-closed ESP or AH connections are anomalous, and a node with
> auditing capability should probably audit their existence if they
> persist. Note that this specification nowhere specifies time
> periods, so it is up to individual endpoints to decide how long to
> wait. A node MAY refuse to accept incoming data on half-closed
> connections but MUST NOT unilaterally close them and reuse the SPIs.
> If connection state becomes sufficiently messed up, a node MAY close
> the IKE SA, as described above. It can then rebuild the SAs it needs
> on a clean base under a new IKE SA.

I support doing that change, as it does clarify things.
-- 
kivinen@iki.fi

From kivinen@iki.fi  Thu Jan 21 01:31:11 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 017733A68CC for ; Thu, 21 Jan 2010 01:31:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.563
X-Spam-Level: 
X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBzywjVPIQ1N for ; Thu, 21 Jan 2010 01:31:10 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 872123A68B6 for ; Thu, 21 Jan 2010 01:31:09 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0L9V06c011937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jan 2010 11:31:00 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0L9UxUU010884; Thu, 21 Jan 2010 11:30:59 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19288.7891.586345.228491@fireball.kivinen.iki.fi>
Date: Thu, 21 Jan 2010 11:30:59 +0200
From: Tero Kivinen 
To: Yoav Nir 
In-Reply-To: <051FD100-9869-4286-939D-C3C0F6FF536D@checkpoint.com>
References:  <051FD100-9869-4286-939D-C3C0F6FF536D@checkpoint.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 15 min
X-Total-Time: 15 min
Cc: IPsecme WG , Paul Hoffman 
Subject: Re: [IPsec] Issue #152: EAP failure and acknowledgement
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 09:31:11 -0000

Yoav Nir writes:
> We do have this:
> 
>                                                                 The
>    responder MAY at any time terminate the IKE exchange by sending an
>    EAP payload containing the Failure message.
> 
> I guess "terminate" means that the initiator does not send any more
> messages.

Yes. As the responder send EAP Failure, and it is the one who is
driving EAP exchanges, there is nothing initiator can do after that.

Also as responder already indicated that the authentication failed by
sending EAP failure, it most likely will mark that IKE SA as failed,
and will clean it up after suitable timeout, just like it does in
AUTHENTICATION_FAILED case (it cannot clean it up immediately, as it
needs to be able to retransmit its EAP failure message in case it
didn't reach the other end and initiator retransmits its last packet).

> This is also one of the places where there is an ambiguity as to the
> meaning of "exchange". Usually an "exchange" is one request-response
> pair, but here it seems to be referring to the entire series of
> IKE_AUTH requests and responses. 

As the EAP Failure goes into the IKE Response packet which completes
that current IKE_AUTH exchange anyways, I think the terminate here
really means the whole initial exchanges (i.e. combined IKE_SA_INIT
and IKE_AUTH exchanges).

> On Jan 20, 2010, at 11:05 PM, Paul Hoffman wrote:
> 
> > 2.16: if the responder sends an EAP Failure, is this IKE message
> > acknowledged by the initiator? 

How could the initiator acknowledge it? EAP failure was sent inside
the response packet, so only way to initiator to send anything is to
start new exchange. That new exchange cannot be INFORMATIONAL as those
can only be sent AFTER all IKE_AUTH exchanges have completed (from
section 1). So the only way would be to start new IKE_AUTH exchange
which contains N(AUTHENTICATION_FAILED) or similar, but most likely
the other end will not respond to that as for his point of view the
IKE SA authentication has already failed.

So the best way is probably just interpret the EAP Failure in the same
way we do for N(AUTHENTICATION_FAILED) notifications in IKE_AUTH, i.e.
the whole IKE SA creation failed, and half-created IKE SA will be
silently cleaned up (i.e. initiator can do that immediately when it
gets N(AUTHENTICATION_FAILED) or EAP(Failure), and responder can do it
after suitable timeout).

We could clarify this by modifying the text in 2.21 from:

   Only authentication failures (AUTHENTICATION_FAILED) and malformed
   messages (INVALID_SYNTAX) lead to a deletion of the IKE SA without
   requiring an explicit INFORMATIONAL exchange carrying a DELETE
   payload.  Other error conditions MAY require such an exchange if
   policy dictates that this is needed.

to

   Only authentication failures (AUTHENTICATION_FAILED and EAP
   Failure) and malformed messages (INVALID_SYNTAX) lead to a deletion
   of the IKE SA without requiring an explicit INFORMATIONAL exchange
   carrying a DELETE payload. Other error conditions MAY require such
   an exchange if policy dictates that this is needed.

I.e. expand that authentication failures include both
AUTHENTICATION_FAILED notification and EAP Failure cases.
-- 
kivinen@iki.fi

From yaronf@checkpoint.com  Thu Jan 21 02:06:27 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A48E63A688B for ; Thu, 21 Jan 2010 02:06:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BJtbqbNxO6X for ; Thu, 21 Jan 2010 02:06:26 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 220833A68C9 for ; Thu, 21 Jan 2010 02:06:25 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0LA6KT7014902; Thu, 21 Jan 2010 12:06:20 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 21 Jan 2010 12:06:34 +0200
From: Yaron Sheffer 
To: Tero Kivinen , Yoav Nir 
Date: Thu, 21 Jan 2010 12:06:29 +0200
Thread-Topic: [IPsec] Issue #152: EAP failure and acknowledgement
Thread-Index: AcqafIGVeFCdxYO6TByPSbaDRpXhngABF2hw
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A220D2@il-ex01.ad.checkpoint.com>
References:  <051FD100-9869-4286-939D-C3C0F6FF536D@checkpoint.com> <19288.7891.586345.228491@fireball.kivinen.iki.fi>
In-Reply-To: <19288.7891.586345.228491@fireball.kivinen.iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IPsecme WG , Paul Hoffman 
Subject: Re: [IPsec] Issue #152: EAP failure and acknowledgement
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 10:06:27 -0000

Also add at the end of the relevant paragraph of 2.16: "If the exchange is =
terminated with EAP Failure, an AUTHENTICATION_FAILED notification is not s=
ent."

Thanks,
	Yaron

> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
> Of Tero Kivinen
> Sent: Thursday, January 21, 2010 11:31
> To: Yoav Nir
> Cc: IPsecme WG; Paul Hoffman
> Subject: Re: [IPsec] Issue #152: EAP failure and acknowledgement
>=20
> Yoav Nir writes:
> > We do have this:
> >
> >                                                                 The
> >    responder MAY at any time terminate the IKE exchange by sending an
> >    EAP payload containing the Failure message.
> >
> > I guess "terminate" means that the initiator does not send any more
> > messages.
>=20
> Yes. As the responder send EAP Failure, and it is the one who is
> driving EAP exchanges, there is nothing initiator can do after that.
>=20
> Also as responder already indicated that the authentication failed by
> sending EAP failure, it most likely will mark that IKE SA as failed,
> and will clean it up after suitable timeout, just like it does in
> AUTHENTICATION_FAILED case (it cannot clean it up immediately, as it
> needs to be able to retransmit its EAP failure message in case it
> didn't reach the other end and initiator retransmits its last packet).
>=20
> > This is also one of the places where there is an ambiguity as to the
> > meaning of "exchange". Usually an "exchange" is one request-response
> > pair, but here it seems to be referring to the entire series of
> > IKE_AUTH requests and responses.
>=20
> As the EAP Failure goes into the IKE Response packet which completes
> that current IKE_AUTH exchange anyways, I think the terminate here
> really means the whole initial exchanges (i.e. combined IKE_SA_INIT
> and IKE_AUTH exchanges).
>=20
> > On Jan 20, 2010, at 11:05 PM, Paul Hoffman wrote:
> >
> > > 2.16: if the responder sends an EAP Failure, is this IKE message
> > > acknowledged by the initiator?
>=20
> How could the initiator acknowledge it? EAP failure was sent inside
> the response packet, so only way to initiator to send anything is to
> start new exchange. That new exchange cannot be INFORMATIONAL as those
> can only be sent AFTER all IKE_AUTH exchanges have completed (from
> section 1). So the only way would be to start new IKE_AUTH exchange
> which contains N(AUTHENTICATION_FAILED) or similar, but most likely
> the other end will not respond to that as for his point of view the
> IKE SA authentication has already failed.
>=20
> So the best way is probably just interpret the EAP Failure in the same
> way we do for N(AUTHENTICATION_FAILED) notifications in IKE_AUTH, i.e.
> the whole IKE SA creation failed, and half-created IKE SA will be
> silently cleaned up (i.e. initiator can do that immediately when it
> gets N(AUTHENTICATION_FAILED) or EAP(Failure), and responder can do it
> after suitable timeout).
>=20
> We could clarify this by modifying the text in 2.21 from:
>=20
>    Only authentication failures (AUTHENTICATION_FAILED) and malformed
>    messages (INVALID_SYNTAX) lead to a deletion of the IKE SA without
>    requiring an explicit INFORMATIONAL exchange carrying a DELETE
>    payload.  Other error conditions MAY require such an exchange if
>    policy dictates that this is needed.
>=20
> to
>=20
>    Only authentication failures (AUTHENTICATION_FAILED and EAP
>    Failure) and malformed messages (INVALID_SYNTAX) lead to a deletion
>    of the IKE SA without requiring an explicit INFORMATIONAL exchange
>    carrying a DELETE payload. Other error conditions MAY require such
>    an exchange if policy dictates that this is needed.
>=20
> I.e. expand that authentication failures include both
> AUTHENTICATION_FAILED notification and EAP Failure cases.
> --
> kivinen@iki.fi
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>=20
> Scanned by Check Point Total Security Gateway.

From kivinen@iki.fi  Thu Jan 21 03:40:28 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 440CB3A6966 for ; Thu, 21 Jan 2010 03:40:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.564
X-Spam-Level: 
X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRIJ0VQciD8Y for ; Thu, 21 Jan 2010 03:40:27 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id E49E83A68D0 for ; Thu, 21 Jan 2010 03:40:26 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0LBeEuN017191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jan 2010 13:40:14 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0LBeDel016027; Thu, 21 Jan 2010 13:40:13 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19288.15645.382443.519149@fireball.kivinen.iki.fi>
Date: Thu, 21 Jan 2010 13:40:13 +0200
From: Tero Kivinen 
To: Yoav Nir 
In-Reply-To: <8C41856B-9D3B-4442-B214-5ED60C23906A@checkpoint.com>
References: <064.cff10879f1e3e888fa8930a85464b847@tools.ietf.org>  <8C41856B-9D3B-4442-B214-5ED60C23906A@checkpoint.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 10 min
X-Total-Time: 10 min
Cc: IPsecme WG , Paul Hoffman 
Subject: Re: [IPsec] Issue #139: Keying material taken in the order for RoHC
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 11:40:28 -0000

Yoav Nir writes:
> I think extensions such as RoHC that change (or extend) the way
> keying material is generated, should and do specify how it is done.
> Leaving that text there becomes a  recommendation for future draft
> writers, which I think is superfluous. 

RoHC has text which explains how the keying material is generated, but
the problem comes when someone combines RoHC and some other extension
which also requires keying material. If we have generic rules in the
IKEv2bis (as we did have in RFC4306) then those two extensions can be
combined together by using those generic rules.

Currently RoHC says:

      1.  The keys (one for each direction) for this Integrity Algorithm
          are derived from the IKEv2 KEYMAT (see [IKEV2], Section 2.17).
          For the purposes of this key derivation, ROHC is considered to
          be an IPsec protocol.  When a ROHC-enabled CHILD_SA is
          rekeyed, the key associated with this integrity algorithm is
          rekeyed as well.

and that reference in RFC4306 section 2.17 said:

   Keying material MUST be taken from the expanded KEYMAT in the
   following order:

      All keys for SAs carrying data from the initiator to the responder
      are taken before SAs going in the reverse direction.

      If multiple IPsec protocols are negotiated, keying material is
      taken in the order in which the protocol headers will appear in
      the encapsulated packet.

      If a single protocol has both encryption and authentication keys,
      the encryption key is taken from the first octets of KEYMAT and
      the authentication key is taken from the next octets.

   Each cryptographic algorithm takes a fixed number of bits of keying
   material specified as part of the algorithm.

Now when we removed that text from 2.17 that will force RoHC document
to either still refer to RFC4306 or cut & paste that text from RFC4306
section 2.17 to its document. 

I think this generic rule was good in the RFC4306, as it makes it
definite how keying material is derived even when there are multiple
extensions present. Removing that in the IKEv2bis does not gain us
anything, but will remove text that is then needed to be copied to
each extension and which needs to be made sure that stays same in each
extension.

> >    If the Child SA negotiation includes some future IPsec protocol(s)
> >    in addition to (or instead of) ESP or AH (e.g., ROHC_INTEG), then
> >    (1) all keys for SAs carrying data from the initiator to the
> >    responder are taken before SAs going in the reverse direction, and
> >    (2) keying material for the IPsec protocols are taken in the order
> >    in which the protocol headers will appear in the encapsulated
> >    packet.

This leaves out the third bullet, i.e. "3) if single protocol has both
encryption and authentication keys, the encryption key is taken first
and the authentication key after the encryption key."
-- 
kivinen@iki.fi

From anumolu.sudheer@gmail.com  Thu Jan 21 06:05:21 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80F323A69E7 for ; Thu, 21 Jan 2010 06:05:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLEG+apUeovM for ; Thu, 21 Jan 2010 06:05:20 -0800 (PST)
Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 8956E3A6954 for ; Thu, 21 Jan 2010 06:05:20 -0800 (PST)
Received: by pwi20 with SMTP id 20so4221494pwi.29 for ; Thu, 21 Jan 2010 06:05:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=xsyycJ6djPCD//TydmqiMziUbpZ2dhH88cjGxXGX5Uo=; b=l2ZbteO6mrXvLnsIRi7kpthFpmd05qXly7u1SOYi+DkLnomCglaL866XzmNtwcONzD 3NZeVzH08N4BurGmbYXbtyCleuFjZvGHiM1qfN9UdtqpZe3fdBNh8D8H08H0wV95omQe Y+l3chJpVua0pei+qoA/Uhg6q4cI+lrjvBQIA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=a04C9m4gTodZsGz+IVSotsYfK2miIyDxv2i4Ds57oO67II0++7KKan/2wuO8RWGG7n CrMfwMaFWXLOkxEveElOCQYAPIbXZ1myq0OQWTom4QItyJs96gcjDPtUTPs248WxuDd4 Xvw7gpkjL7bysPNOv5ADQ4w+39E1CS9vw8uzo=
MIME-Version: 1.0
Received: by 10.114.29.15 with SMTP id c15mr1014696wac.218.1264082713565; Thu,  21 Jan 2010 06:05:13 -0800 (PST)
Date: Thu, 21 Jan 2010 19:35:13 +0530
Message-ID: <67e0e6021001210605v48792a77o5499f53089dc3973@mail.gmail.com>
From: sudheer anumolu 
To: ipsec@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [IPsec] Regarding aes-xcbc hashing using multiple ring entries
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 14:09:55 -0000

Hi

I would like to have information on aes-xcbc-mac96 hashing using
multiple ring entries.

I need to implement MD5, SHA-1 and AES-XCBC-MAC96 hashing algorithms
using multiple ring entries of the IPSec block.

For md5 and sha-1 the hash results i get, tally with that of results
generated when done with single ring entry. But for aes-xcbc-mac96, it
doesn't. I doubt if the multiple ring entries method can be applied
for aes-xcbc-mac96 as it also involves encryption and the previous
hash value to be considered as hash-key in the next iteration would be
a encrypted one.

Please let me know if any more information required.

Thanks in advance
Sudheer

From kivinen@iki.fi  Thu Jan 21 07:05:35 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A37693A697E for ; Thu, 21 Jan 2010 07:05:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.565
X-Spam-Level: 
X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4kXM8hEDO12 for ; Thu, 21 Jan 2010 07:05:34 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 577E33A68F4 for ; Thu, 21 Jan 2010 07:05:33 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0LF5MWr012996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Jan 2010 17:05:22 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0LF5LSi004229; Thu, 21 Jan 2010 17:05:21 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19288.27953.896891.499515@fireball.kivinen.iki.fi>
Date: Thu, 21 Jan 2010 17:05:21 +0200
From: Tero Kivinen 
To: ipsec@ietf.org
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 6 min
X-Total-Time: 9 min
Subject: [IPsec] Comments to draft-ietf-ipsecme-ikev2bis-07.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 15:05:35 -0000

It seems my number of lines in comment emails is going down (it was
1300 lines, then 950 lines, and now only 240 lines) so hopefully we
are getting closer to the get ready...

----------------------------------------------------------------------

In section 2.6 there is typo:

	       Also, incorporating SPi in the hash prevents an
   attacker from fetching one cookie from the other end, and then
   initiating many IKE_SA_INIT exchanges all with different initiator
   SPIs (and perhaps port numbers) so that the responder thinks that
   there are lots of machines behind one NAT box who are all trying to
   connect.

replace "SPi" with "SPIi".

----------------------------------------------------------------------

Section 2.8.2 there was removed paragraph:

	However, there is a twist to the other case where one rekeying
	finishes first:

and I think some kind of paragraph is needed, as the example given
below is not about normal simultaneous IKE SA rekey, but this special
case. Now someone might think that the example given is the normal
simulatenous IKE SA rekey example.

----------------------------------------------------------------------

In the sectioon 2.9 the "SHOULD" requirement was removed for the
very specific traffic selector as fist traffic selector.

I think that "SHOULD" requirement needs to be kept, as it affects
interoperability, as if other end does not include that triggering
packet then certain policies cannot interoperate.

Also in the interops we have seen implementations who could not
interoperate at all if sender end included triggering packet (I do not
know if the failure to create Child SA was because the traffic
selector containing port selectors, or whether it was because there
were multiple traffic selectors).

If there is "SHOULD" level requirement for that, then we can at least
point the other vendors to that and say, that as we SHOULD be sending
that triggering packet, then you also needs to be able to cope with
it...

Old text was:

   To enable the responder to choose the appropriate range in this case,
   if the initiator has requested the SA due to a data packet, the
   initiator SHOULD include as the first traffic selector in each of TSi
   and TSr a very specific traffic selector including the addresses in
   the packet triggering the request.

new text in draft-ietf-ipsecme-ikev2bis-07.txt is:

   If the initiator requests an SA because it wants to send a data
   packet, including the specific addresses in the packet triggering the
   request in the first traffic selector in both TSi and TSr enables the
   responder to choose the appropriate range.  

----------------------------------------------------------------------

In section 2.23.1:

Also there is extra "as" in this sentence:

   In this case, the server should first check that as initiator
						    ^^
   requested transport mode and do address substitution on the traffic
   selectors.  

This was already in my previous comments, and that change was not
done.

----------------------------------------------------------------------

The section 3.6 has some duplicate text:

		    Certificate payloads SHOULD be included in an
   exchange if certificates are available to the sender.  The Hash and
   URL formats of the Certificate payloads should be used in case the
   peer has indicated an ability to retrieve this information from
   elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload.
-  Certificate payloads SHOULD be included in an exchange if
-  certificates are available to the sender unless the peer has
-  indicated an ability to retrieve this information from elsewhere
-  using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload.  

I suggest removing the later half of the text marked with '-' in the
beginning of line.
   
----------------------------------------------------------------------

In section 3.14 we should remove the "or E" in the first sentence, as
we do not use E anymore, only SK{}

----------------------------------------------------------------------

Note, that In section 6, we need to add new IANA entry where we change
the exiting IKEv2 Payload Types table by changing:

46        Encrypted                        E          [RFC4306]

to 

46        Encrypted and Authenticated      SK         [RFCXXXX]

----------------------------------------------------------------------

In section 1.7 I do not know which change this 

   In Section 2.3, there is new material covering how the initiator's
   SPI and/or IP is used to differentiate if this is a "half-open" IKE
   SA or a new request.

item refers to. I do not find anything related to half-open IKE SAs in
the section 2.3. Also as 2.3 talks about Window Size, and Window size
is only active AFTER initial exchanges have completeled, it cannot
really be related to half-open IKE SAs.

Hmm... looking through old versions, I guess this was the change done
in the section 2.1 not 2.3:

I.e. when this text was added:

   {{ Clarif-2.3 }} Retransmissions of the IKE_SA_INIT request require	
   some special handling. When a responder receives an IKE_SA_INIT	
   request, it has to determine whether the packet is retransmission	
   belonging to an existing "half-open" IKE_SA (in which case the	
   responder retransmits the same response), or a new request (in which	
   case the responder creates a new IKE_SA and sends a fresh response),	
   or it belongs to an existing IKE_SA where the IKE_AUTH request has	
   been already received (in which case the responder ignores it).	
   	
   It is not sufficient to use the initiator's SPI and/or IP address to	
   differentiate between these three cases because two different peers	
   behind a single NAT could choose the same initiator SPI. Instead, a	
   robust responder will do the IKE_SA lookup using the whole packet,	
   its hash, or the Ni payload.

On the other hand I think the changed text allowing implementations to
forget old packets after serveral minutes, is change that will affect
implementors more, as now they do not need to keep those packets
forever, than this is. This helpful text is just implementantation
hint pointing out some possible problems if someone implemented things
wrongly.

----------------------------------------------------------------------

The section 1.7 should be more like description of changes, not just
listing section numbers with changed text. For example I think it
would be better to combine:

   In section 1.3.2, changed "The KEi payload SHOULD be included" to be
   "The KEi payload MUST be included".  This also lead to changes in
   section 2.18.

   Section 2.18 requires doing a Diffie-Hellman exchange when rekeying
   the IKE_SA.  In theory, RFC 4306 allowed a policy where the Diffie-
   Hellman exchange was optional, but this was not useful (or
   appropriate) when rekeying the IKE_SA.

to one item saying:

   Diffie-Hellman exchange is now required for IKE SA rekeys. In
   theory, RFC 4306 allowed a policy where the Diffie- Hellman
   exchange was optional, but this was not useful (or appropriate)
   when rekeying the IKE_SA (section 1.3.2 and section 2.18).

----------------------------------------------------------------------

For example in 1.7 the point:

   This document clarifies the use of the critical flag in Section 2.5.

does not help implementors at all, as they now need to go through the
old RFC4306 section 2.5 and compare it with the new section 2.5 to
find out what was done (and I do not remember that myself, so I need
to do that to provide better text for that bullet).

----------------------------------------------------------------------

In section 1.7 the bullet

   In 2.8, changed "Note that, when rekeying, the new Child SA MAY have
   different traffic selectors and algorithms than the old one" to "Note
   that, when rekeying, the new Child SA SHOULD NOT have different
   traffic selectors and algorithms than the old one".

should be rewritten to

   In the Child SA rekey the new recommended behavior is that the new
   Child SA SHOULD NOT have different traffic selectors and algorithms
   than what was used in the old Child SA. Previously it
   was that "Child SA MAY have different traffic selectors and
   algorithms then the old one" (section 2.8).

----------------------------------------------------------------------

Also I think the new sections could be combined together i.e. replace:

   The new Section 2.8.2 covers simultaneous IKE SA rekeying.

   The new Section 2.9.2 covers traffic selectors in rekeying.

   Added Section 2.23.1 to describe NAT traversal when transport mode is
   requested.

to

   There are completely new sections covering simultaneous IKE SA
   rekeying (Section 2.8.2), traffic selectors in rekeying (Section
   2.9.2) and NAT traversal in transport mode (2.23.1).

----------------------------------------------------------------------

In general implementators are not that interested in what parts of the
text changed, they are interested in what was the real change that
affects them.

----------------------------------------------------------------------

Also I think issue #40 requires its own item, as it do change behavior
of implementations.  Added text to 2.23: 

   An initiator can use port 4500, regardless whether or not there is
   NAT, even at the beginning of IKE.  When either side is using port
   4500, sending with UDP encapsulation is not required, but
   understanding received packets with UDP encapsulation is required.
   UDP encapsulation MUST NOT be done on port 500.  If NAT-T is
   supported (that is, if NAT_DETECTION_*_IP payloads were exchanged
   during IKE_SA_INIT), all devices MUST be able to receive and process
   both UDP encapsulated and non-UDP encapsulated packets at any time.
   Either side can decide whether or not to use UDP encapsulation
   irrespective of the choice made by the other side.  However, if a NAT
   is detected, both devices MUST send UDP encapsulated packets.

This could be summarized like this:

   NAT Traversal was clarified so that now both UDP encapsulated IPsec
   packets and non-UDP encapsulated IPsec packets packets needs to be
   understood when receiving (Section 2.23).
-- 
kivinen@iki.fi

From svanru@gmail.com  Thu Jan 21 08:47:56 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D76993A6818 for ; Thu, 21 Jan 2010 08:47:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level: 
X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, XMAILER_MIMEOLE_OL_7533E=0.513]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bE3bEtM0Bpdl for ; Thu, 21 Jan 2010 08:47:56 -0800 (PST)
Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id CCF023A68B3 for ; Thu, 21 Jan 2010 08:47:55 -0800 (PST)
Received: by ey-out-2122.google.com with SMTP id 22so61003eye.51 for ; Thu, 21 Jan 2010 08:47:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:cc :references:subject:date:mime-version:content-type :content-transfer-encoding:x-priority:x-msmail-priority:x-mailer :x-mimeole; bh=ONmFQmWTDROScOeQ6eV75Dcqp7Lf/HuNqLvPxBJ5noI=; b=dS4y+ZYHz5DTQ5yYC2++CvYhK//lusIAzDDmDhOpsuq/HGmQW+1ywC9g8FH9/nm3do Ksj746doY+/D1y+Tv3Zg+LkfHL/Iu5xplit5LJLS4yGI9D8UFeW8TN/oh2PmcFD8IbrV e5TNIJ3/jFkD+b141rRLqgKHXd011vqbtzJfI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=Uy6isg+3UuADdCZD4xuKmty7C5AMkmzKgRi5RbOtcIx9iOsb78B9ff6PaZ+zSvag3k GaygoNpIdL/vBRGGOO5bMgXWgWBjPcPM/z4GdVKOnVd91VvPwYTIaFhR2Pwun+lAgEuT Cb4mgNuAswqE562DVxl516tMNYgJVM6TrI30k=
Received: by 10.213.38.208 with SMTP id c16mr1507589ebe.85.1264092465657; Thu, 21 Jan 2010 08:47:45 -0800 (PST)
Received: from svanpc ([82.138.51.4]) by mx.google.com with ESMTPS id 13sm973776ewy.9.2010.01.21.08.47.43 (version=SSLv3 cipher=RC4-MD5); Thu, 21 Jan 2010 08:47:44 -0800 (PST)
Message-ID: 
From: "Valery Smyslov" 
To: "Tero Kivinen" , "Yoav Nir" 
References: <064.cff10879f1e3e888fa8930a85464b847@tools.ietf.org><8C41856B-9D3B-4442-B214-5ED60C23906A@checkpoint.com> <19288.15645.382443.519149@fireball.kivinen.iki.fi>
Date: Thu, 21 Jan 2010 19:48:24 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4963.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700
Cc: IPsecme WG , Paul Hoffman 
Subject: Re: [IPsec] Issue #139: Keying material taken in the order for RoHC
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 16:47:57 -0000

Tero Kivinen writes:


> I think this generic rule was good in the RFC4306, as it makes it
> definite how keying material is derived even when there are multiple
> extensions present. Removing that in the IKEv2bis does not gain us
> anything, but will remove text that is then needed to be copied to
> each extension and which needs to be made sure that stays same in each
> extension.

I agree.

> > >    If the Child SA negotiation includes some future IPsec protocol(s)
> > >    in addition to (or instead of) ESP or AH (e.g., ROHC_INTEG), then
> > >    (1) all keys for SAs carrying data from the initiator to the
> > >    responder are taken before SAs going in the reverse direction, and
> > >    (2) keying material for the IPsec protocols are taken in the order
> > >    in which the protocol headers will appear in the encapsulated
> > >    packet.
>
> This leaves out the third bullet, i.e. "3) if single protocol has both
> encryption and authentication keys, the encryption key is taken first
> and the authentication key after the encryption key."

This bullet is probably superfluous and incomplete.

First, RFC4301 already has the same requirement (section 4.5.2):

   To ensure that the IPsec implementations at each end of
   the SA use the same bits for the same keys, and irrespective of which
   part of the system divides the string of bits into individual keys,
   the encryption keys MUST be taken from the first (left-most,
   high-order) bits and the integrity keys MUST be taken from the
   remaining bits.  The number of bits for each key is defined in the
   relevant cryptographic algorithm specification RFC.  In the case of
   multiple encryption keys or multiple integrity keys, the
   specification for the cryptographic algorithm must specify the order
   in which they are to be selected from a single string of bits
   provided to the cryptographic algorithm.

And second, it defines only the order of encryption and authentication keys.
If some some bits need to be derived for some other purposes (like nonces
in GCM and CCM, etc.), this paragraph doesn't help at all.

So, I think it is better to rely on RFC4301 here and leave 3rd bullet out.

Regards,
Valery Smyslov.



From paul.hoffman@vpnc.org  Thu Jan 21 09:14:43 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52BD43A6A8E for ; Thu, 21 Jan 2010 09:14:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.019
X-Spam-Level: 
X-Spam-Status: No, score=-6.019 tagged_above=-999 required=5 tests=[AWL=0.027,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUyd1-ePGwgQ for ; Thu, 21 Jan 2010 09:14:42 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 599953A6A5F for ; Thu, 21 Jan 2010 09:14:42 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0LH3fLr056909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jan 2010 10:03:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <19288.6547.134892.584511@fireball.kivinen.iki.fi>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21EF8@il-ex01.ad.checkpoint.com>  <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A22040@il-ex01.ad.checkpoint.com> <19288.6547.134892.584511@fireball.kivinen.iki.fi>
Date: Thu, 21 Jan 2010 09:03:38 -0800
To: Tero Kivinen , Yaron Sheffer 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Cc: "ipsec@ietf.org" 
Subject: Re: [IPsec] IKEv2-bis, comments up to 2.16
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 17:14:43 -0000

At 11:08 AM +0200 1/21/10, Tero Kivinen wrote:
>Yaron Sheffer writes:
>> > 1.4.1: the last paragraph springs a surprise by defining the behavior
>> > of IKE SA deletion while discussing an unlikely "messing up" of Child
>> > SAs. IKE SA deletion deserves its own subsection.
>> >
>> > [[ Response: it is optional behavior and makes sense. If you want a
>> > section on IKE SA deletion, you have to write it. I propose that it
>> > might be very late for doing that. ]]
>> >
>> I suggest replacing the last paragraph by the following text (not a
>> new section, though):
>>
> > Similarly to ESP and HA SAs, IKE SAs are also deleted by sending an
>> Informational exchange. Deleting an IKE SA implicitly closes any
>> remaining Child SAs negotiated under it. The response to a request
>> that deletes the IKE SA is an empty INFORMATIONAL response.
>>
>> Half-closed ESP or AH connections are anomalous, and a node with
>> auditing capability should probably audit their existence if they
>> persist. Note that this specification nowhere specifies time
>> periods, so it is up to individual endpoints to decide how long to
>> wait. A node MAY refuse to accept incoming data on half-closed
>> connections but MUST NOT unilaterally close them and reuse the SPIs.
>> If connection state becomes sufficiently messed up, a node MAY close
>> the IKE SA, as described above. It can then rebuild the SAs it needs
>> on a clean base under a new IKE SA.
>
>I support doing that change, as it does clarify things.

I'll make this change unless anyone objects.

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Thu Jan 21 09:31:08 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9E143A6AB0 for ; Thu, 21 Jan 2010 09:31:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.019
X-Spam-Level: 
X-Spam-Status: No, score=-6.019 tagged_above=-999 required=5 tests=[AWL=0.027,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id athxOmXa-LkV for ; Thu, 21 Jan 2010 09:31:07 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 4C1F93A6A92 for ; Thu, 21 Jan 2010 09:30:55 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0LHUnl3058520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jan 2010 10:30:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <19288.27953.896891.499515@fireball.kivinen.iki.fi>
References: <19288.27953.896891.499515@fireball.kivinen.iki.fi>
Date: Thu, 21 Jan 2010 09:30:47 -0800
To: Tero Kivinen , ipsec@ietf.org
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [IPsec] Comments to draft-ietf-ipsecme-ikev2bis-07.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 17:31:09 -0000

At 5:05 PM +0200 1/21/10, Tero Kivinen wrote:

All changes made other than the following.

>----------------------------------------------------------------------
>
>Section 2.8.2 there was removed paragraph:
>
>	However, there is a twist to the other case where one rekeying
>	finishes first:
>
>and I think some kind of paragraph is needed, as the example given
>below is not about normal simultaneous IKE SA rekey, but this special
>case. Now someone might think that the example given is the normal
>simulatenous IKE SA rekey example.

Please open a new issue in the tracker and put specific text in it.

>----------------------------------------------------------------------
>
>The section 1.7 should be more like description of changes, not just
>listing section numbers with changed text. For example I think it
>would be better to combine:
>
>   In section 1.3.2, changed "The KEi payload SHOULD be included" to be
>   "The KEi payload MUST be included".  This also lead to changes in
>   section 2.18.
>
>   Section 2.18 requires doing a Diffie-Hellman exchange when rekeying
>   the IKE_SA.  In theory, RFC 4306 allowed a policy where the Diffie-
>   Hellman exchange was optional, but this was not useful (or
>   appropriate) when rekeying the IKE_SA.
>
>to one item saying:
>
>   Diffie-Hellman exchange is now required for IKE SA rekeys. In
>   theory, RFC 4306 allowed a policy where the Diffie- Hellman
>   exchange was optional, but this was not useful (or appropriate)
>   when rekeying the IKE_SA (section 1.3.2 and section 2.18).

This difference is not worth the effort of re-writing the whole section and possibly losing information.

>----------------------------------------------------------------------
>
>For example in 1.7 the point:
>
>   This document clarifies the use of the critical flag in Section 2.5.
>
>does not help implementors at all, as they now need to go through the
>old RFC4306 section 2.5 and compare it with the new section 2.5 to
>find out what was done (and I do not remember that myself, so I need
>to do that to provide better text for that bullet).

Clarifications such as this are welcome. Please provide text.

>----------------------------------------------------------------------
>
>In section 1.7 the bullet
>
>   In 2.8, changed "Note that, when rekeying, the new Child SA MAY have
>   different traffic selectors and algorithms than the old one" to "Note
>   that, when rekeying, the new Child SA SHOULD NOT have different
>   traffic selectors and algorithms than the old one".
>
>should be rewritten to
>
>   In the Child SA rekey the new recommended behavior is that the new
>   Child SA SHOULD NOT have different traffic selectors and algorithms
>   than what was used in the old Child SA. Previously it
>   was that "Child SA MAY have different traffic selectors and
>   algorithms then the old one" (section 2.8).

Those two feel equivalent to me; not done. I am quite hesitant to do wordsmithing at this stage, particularly if it could cause loss of information.

>----------------------------------------------------------------------
>
>Also I think the new sections could be combined together i.e. replace:
>
>   The new Section 2.8.2 covers simultaneous IKE SA rekeying.
>
>   The new Section 2.9.2 covers traffic selectors in rekeying.
>
>   Added Section 2.23.1 to describe NAT traversal when transport mode is
>   requested.
>
>to
>
>   There are completely new sections covering simultaneous IKE SA
>   rekeying (Section 2.8.2), traffic selectors in rekeying (Section
>   2.9.2) and NAT traversal in transport mode (2.23.1).

Ditto. These are equivalent.

>----------------------------------------------------------------------
>
>In general implementators are not that interested in what parts of the
>text changed, they are interested in what was the real change that
>affects them.

That's a very broad claim, made by someone who already fully implemented IKEv2. Other implementers, particularly those who are in the middle of implementing IKEv2, might differ.

>----------------------------------------------------------------------
>
>Also I think issue #40 requires its own item, as it do change behavior
>of implementations.

Good catch; added in the next version.


--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Thu Jan 21 09:44:43 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FD633A69C3 for ; Thu, 21 Jan 2010 09:44:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.02
X-Spam-Level: 
X-Spam-Status: No, score=-6.02 tagged_above=-999 required=5 tests=[AWL=0.026,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbKLM7ZxiV+Z for ; Thu, 21 Jan 2010 09:44:42 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 718A73A6878 for ; Thu, 21 Jan 2010 09:44:42 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0LHUnl5058520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Jan 2010 10:30:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
Date: Thu, 21 Jan 2010 09:11:14 -0800
To: IPsecme WG 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: [IPsec] Issue #155: SHOULD send triggering packet and interoperability
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 17:44:43 -0000

In the sectioon 2.9 the "SHOULD" requirement was removed for the
very specific traffic selector as fist traffic selector.

I think that "SHOULD" requirement needs to be kept, as it affects
interoperability, as if other end does not include that triggering
packet then certain policies cannot interoperate.

Also in the interops we have seen implementations who could not
interoperate at all if sender end included triggering packet (I do not
know if the failure to create Child SA was because the traffic
selector containing port selectors, or whether it was because there
were multiple traffic selectors).

If there is "SHOULD" level requirement for that, then we can at least
point the other vendors to that and say, that as we SHOULD be sending
that triggering packet, then you also needs to be able to cope with
it...

Old text was:

   To enable the responder to choose the appropriate range in this case,
   if the initiator has requested the SA due to a data packet, the
   initiator SHOULD include as the first traffic selector in each of TSi
   and TSr a very specific traffic selector including the addresses in
   the packet triggering the request.

new text in draft-ietf-ipsecme-ikev2bis-07.txt is:

   If the initiator requests an SA because it wants to send a data
   packet, including the specific addresses in the packet triggering the
   request in the first traffic selector in both TSi and TSr enables the
   responder to choose the appropriate range.  

--Paul Hoffman, Director
--VPN Consortium

From kivinen@iki.fi  Thu Jan 21 12:47:35 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1B463A6858 for ; Thu, 21 Jan 2010 12:47:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.566
X-Spam-Level: 
X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dekv3jcZpByp for ; Thu, 21 Jan 2010 12:47:35 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 224B53A6816 for ; Thu, 21 Jan 2010 12:47:32 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0LKlGwb017970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jan 2010 22:47:16 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0LKlF3f017979; Thu, 21 Jan 2010 22:47:15 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19288.48466.976054.136453@fireball.kivinen.iki.fi>
Date: Thu, 21 Jan 2010 22:47:14 +0200
From: Tero Kivinen 
To: "Valery Smyslov" 
In-Reply-To: 
References: <064.cff10879f1e3e888fa8930a85464b847@tools.ietf.org>  <8C41856B-9D3B-4442-B214-5ED60C23906A@checkpoint.com> <19288.15645.382443.519149@fireball.kivinen.iki.fi> 
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 0 min
X-Total-Time: 0 min
Cc: IPsecme WG , Yoav Nir , Paul Hoffman 
Subject: Re: [IPsec] Issue #139: Keying material taken in the order for RoHC
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 20:47:36 -0000

Valery Smyslov writes:
> > This leaves out the third bullet, i.e. "3) if single protocol has both
> > encryption and authentication keys, the encryption key is taken first
> > and the authentication key after the encryption key."
> 
> This bullet is probably superfluous and incomplete.
> 
> First, RFC4301 already has the same requirement (section 4.5.2):
> 
>    To ensure that the IPsec implementations at each end of
>    the SA use the same bits for the same keys, and irrespective of which
>    part of the system divides the string of bits into individual keys,
>    the encryption keys MUST be taken from the first (left-most,
>    high-order) bits and the integrity keys MUST be taken from the
>    remaining bits.  The number of bits for each key is defined in the
>    relevant cryptographic algorithm specification RFC.  In the case of
>    multiple encryption keys or multiple integrity keys, the
>    specification for the cryptographic algorithm must specify the order
>    in which they are to be selected from a single string of bits
>    provided to the cryptographic algorithm.
> 
> And second, it defines only the order of encryption and authentication keys.
> If some some bits need to be derived for some other purposes (like nonces
> in GCM and CCM, etc.), this paragraph doesn't help at all.
> 
> So, I think it is better to rely on RFC4301 here and leave 3rd bullet out.

That is fine by me. I didn't remember that RFC4301 already has text
like that.
-- 
kivinen@iki.fi

From Bill_Lofmark@timeinc.com  Thu Jan 21 12:51:25 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 777F13A6816 for ; Thu, 21 Jan 2010 12:51:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYL4QZyIVrl4 for ; Thu, 21 Jan 2010 12:51:24 -0800 (PST)
Received: from mail202.messagelabs.com (mail202.messagelabs.com [216.82.254.227]) by core3.amsl.com (Postfix) with SMTP id 9BF623A6767 for ; Thu, 21 Jan 2010 12:51:24 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: Bill_Lofmark@timeinc.com
X-Msg-Ref: server-12.tower-202.messagelabs.com!1264107057!47075477!11
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [64.236.82.32]
Received: (qmail 1491 invoked from network); 21 Jan 2010 20:51:20 -0000
Received: from unknown (HELO PSYMSGSM02.enterprise.corpad.timeinc.com) (64.236.82.32) by server-12.tower-202.messagelabs.com with SMTP; 21 Jan 2010 20:51:20 -0000
Received: from PSYMSGMB03.enterprise.corpad.timeinc.com ([10.177.28.177]) by PSYMSGSM02.enterprise.corpad.timeinc.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Jan 2010 15:51:08 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Thu, 21 Jan 2010 15:51:07 -0500
Message-ID: <400ECE932255AF4F8BAEDAA4D0AC5B92041BE573@PSYMSGMB03.enterprise.corpad.timeinc.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPsec] Issue #139: Keying material taken in the order for RoHC
Thread-Index: Acqa2vkELIvebckGSAix9Pxhf+Z+8QAAHtm+
From: 
To: , 
X-OriginalArrivalTime: 21 Jan 2010 20:51:08.0870 (UTC) FILETIME=[75398660:01CA9ADB]
Cc: ipsec@ietf.org, ynir@checkpoint.com, paul.hoffman@vpnc.org
Subject: Re: [IPsec] Issue #139: Keying material taken in the order for RoHC
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 20:51:25 -0000

VW5zdWJzY3JpYmUNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogaXBzZWMt
Ym91bmNlc0BpZXRmLm9yZyA8aXBzZWMtYm91bmNlc0BpZXRmLm9yZz4NClRvOiBWYWxlcnkgU215
c2xvdiA8c3ZhbnJ1QGdtYWlsLmNvbT4NCkNjOiBJUHNlY21lIFdHIDxpcHNlY0BpZXRmLm9yZz47
IFlvYXYgTmlyIDx5bmlyQGNoZWNrcG9pbnQuY29tPjsgUGF1bCBIb2ZmbWFuIDxwYXVsLmhvZmZt
YW5AdnBuYy5vcmc+DQpTZW50OiBUaHUgSmFuIDIxIDE1OjQ3OjE0IDIwMTANClN1YmplY3Q6IFJl
OiBbSVBzZWNdIElzc3VlICMxMzk6IEtleWluZyBtYXRlcmlhbCB0YWtlbiBpbiB0aGUgb3JkZXIg
Zm9yIFJvSEMNCg0KVmFsZXJ5IFNteXNsb3Ygd3JpdGVzOg0KPiA+IFRoaXMgbGVhdmVzIG91dCB0
aGUgdGhpcmQgYnVsbGV0LCBpLmUuICIzKSBpZiBzaW5nbGUgcHJvdG9jb2wgaGFzIGJvdGgNCj4g
PiBlbmNyeXB0aW9uIGFuZCBhdXRoZW50aWNhdGlvbiBrZXlzLCB0aGUgZW5jcnlwdGlvbiBrZXkg
aXMgdGFrZW4gZmlyc3QNCj4gPiBhbmQgdGhlIGF1dGhlbnRpY2F0aW9uIGtleSBhZnRlciB0aGUg
ZW5jcnlwdGlvbiBrZXkuIg0KPiANCj4gVGhpcyBidWxsZXQgaXMgcHJvYmFibHkgc3VwZXJmbHVv
dXMgYW5kIGluY29tcGxldGUuDQo+IA0KPiBGaXJzdCwgUkZDNDMwMSBhbHJlYWR5IGhhcyB0aGUg
c2FtZSByZXF1aXJlbWVudCAoc2VjdGlvbiA0LjUuMik6DQo+IA0KPiAgICBUbyBlbnN1cmUgdGhh
dCB0aGUgSVBzZWMgaW1wbGVtZW50YXRpb25zIGF0IGVhY2ggZW5kIG9mDQo+ICAgIHRoZSBTQSB1
c2UgdGhlIHNhbWUgYml0cyBmb3IgdGhlIHNhbWUga2V5cywgYW5kIGlycmVzcGVjdGl2ZSBvZiB3
aGljaA0KPiAgICBwYXJ0IG9mIHRoZSBzeXN0ZW0gZGl2aWRlcyB0aGUgc3RyaW5nIG9mIGJpdHMg
aW50byBpbmRpdmlkdWFsIGtleXMsDQo+ICAgIHRoZSBlbmNyeXB0aW9uIGtleXMgTVVTVCBiZSB0
YWtlbiBmcm9tIHRoZSBmaXJzdCAobGVmdC1tb3N0LA0KPiAgICBoaWdoLW9yZGVyKSBiaXRzIGFu
ZCB0aGUgaW50ZWdyaXR5IGtleXMgTVVTVCBiZSB0YWtlbiBmcm9tIHRoZQ0KPiAgICByZW1haW5p
bmcgYml0cy4gIFRoZSBudW1iZXIgb2YgYml0cyBmb3IgZWFjaCBrZXkgaXMgZGVmaW5lZCBpbiB0
aGUNCj4gICAgcmVsZXZhbnQgY3J5cHRvZ3JhcGhpYyBhbGdvcml0aG0gc3BlY2lmaWNhdGlvbiBS
RkMuICBJbiB0aGUgY2FzZSBvZg0KPiAgICBtdWx0aXBsZSBlbmNyeXB0aW9uIGtleXMgb3IgbXVs
dGlwbGUgaW50ZWdyaXR5IGtleXMsIHRoZQ0KPiAgICBzcGVjaWZpY2F0aW9uIGZvciB0aGUgY3J5
cHRvZ3JhcGhpYyBhbGdvcml0aG0gbXVzdCBzcGVjaWZ5IHRoZSBvcmRlcg0KPiAgICBpbiB3aGlj
aCB0aGV5IGFyZSB0byBiZSBzZWxlY3RlZCBmcm9tIGEgc2luZ2xlIHN0cmluZyBvZiBiaXRzDQo+
ICAgIHByb3ZpZGVkIHRvIHRoZSBjcnlwdG9ncmFwaGljIGFsZ29yaXRobS4NCj4gDQo+IEFuZCBz
ZWNvbmQsIGl0IGRlZmluZXMgb25seSB0aGUgb3JkZXIgb2YgZW5jcnlwdGlvbiBhbmQgYXV0aGVu
dGljYXRpb24ga2V5cy4NCj4gSWYgc29tZSBzb21lIGJpdHMgbmVlZCB0byBiZSBkZXJpdmVkIGZv
ciBzb21lIG90aGVyIHB1cnBvc2VzIChsaWtlIG5vbmNlcw0KPiBpbiBHQ00gYW5kIENDTSwgZXRj
LiksIHRoaXMgcGFyYWdyYXBoIGRvZXNuJ3QgaGVscCBhdCBhbGwuDQo+IA0KPiBTbywgSSB0aGlu
ayBpdCBpcyBiZXR0ZXIgdG8gcmVseSBvbiBSRkM0MzAxIGhlcmUgYW5kIGxlYXZlIDNyZCBidWxs
ZXQgb3V0Lg0KDQpUaGF0IGlzIGZpbmUgYnkgbWUuIEkgZGlkbid0IHJlbWVtYmVyIHRoYXQgUkZD
NDMwMSBhbHJlYWR5IGhhcyB0ZXh0DQpsaWtlIHRoYXQuDQotLSANCmtpdmluZW5AaWtpLmZpDQpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSVBzZWMgbWFp
bGluZyBsaXN0DQpJUHNlY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9pcHNlYw0K

From Black_David@emc.com  Thu Jan 21 13:25:26 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C90C28C1AB for ; Thu, 21 Jan 2010 13:25:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.099
X-Spam-Level: 
X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0EbJ0cqPU38 for ; Thu, 21 Jan 2010 13:25:25 -0800 (PST)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 2DAD93A6765 for ; Thu, 21 Jan 2010 13:25:24 -0800 (PST)
Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id o0LLPJQ2000620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jan 2010 16:25:19 -0500
Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Thu, 21 Jan 2010 16:25:14 -0500
Received: from corpussmtp1.corp.emc.com (corpussmtp1.corp.emc.com [128.221.166.44]) by mailhub.lss.emc.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id o0LLPDrO003521; Thu, 21 Jan 2010 16:25:14 -0500
Received: from CORPUSMX80B.corp.emc.com ([10.254.89.203]) by corpussmtp1.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Jan 2010 16:25:13 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 21 Jan 2010 16:25:12 -0500
Message-ID: 
In-Reply-To: <19288.48466.976054.136453@fireball.kivinen.iki.fi>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPsec] Issue #139: Keying material taken in the order for RoHC
Thread-Index: Acqa21UnZBaRZg78SyyKnN3FFmlcCwAAwd3A
References: <064.cff10879f1e3e888fa8930a85464b847@tools.ietf.org><8C41856B-9D3B-4442-B214-5ED60C23906A@checkpoint.com><19288.15645.382443.519149@fireball.kivinen.iki.fi> <19288.48466.976054.136453@fireball.kivinen.iki.fi>
From: 
To: , 
X-OriginalArrivalTime: 21 Jan 2010 21:25:13.0411 (UTC) FILETIME=[37DDB930:01CA9AE0]
X-EMM-EM: Active
Cc: ipsec@ietf.org, Black_David@emc.com
Subject: Re: [IPsec] Issue #139: Keying material taken in the order for RoHC
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 21:25:26 -0000

> > > This leaves out the third bullet, i.e. "3) if single protocol has =
both
> > > encryption and authentication keys, the encryption key is taken =
first
> > > and the authentication key after the encryption key."
> >
> > This bullet is probably superfluous and incomplete.
> >
> > First, RFC4301 already has the same requirement (section 4.5.2):
> >
> >    To ensure that the IPsec implementations at each end of
> >    the SA use the same bits for the same keys, and irrespective of =
which
> >    part of the system divides the string of bits into individual =
keys,
> >    the encryption keys MUST be taken from the first (left-most,
> >    high-order) bits and the integrity keys MUST be taken from the
> >    remaining bits.  The number of bits for each key is defined in =
the
> >    relevant cryptographic algorithm specification RFC.  In the case =
of
> >    multiple encryption keys or multiple integrity keys, the
> >    specification for the cryptographic algorithm must specify the =
order
> >    in which they are to be selected from a single string of bits
> >    provided to the cryptographic algorithm.
> >
> > And second, it defines only the order of encryption and =
authentication keys.
> > If some bits need to be derived for some other purposes (like nonces
> > in GCM and CCM, etc.), this paragraph doesn't help at all.
> >
> > So, I think it is better to rely on RFC4301 here and leave 3rd =
bullet out.

That also works for the GCM and CCM examples because their necessary =
details
are already specified in the GCM and CCM RFCs.  GCM and CCM actually =
take salt
values for nonces (as opposed to the nonces themselves from the =
generated keying
material.  The RFCs for these two transforms are carefully written to =
specify
that one larger chunk of keying material is taken and then divided into =
salt
and key (see RFC 4106, Section 8.1 and RFC 4309, Section 7.1).

What this means is that from the point of view of how the generated =
keying
material is consumed, a GCM or CCM salt is logically part of a larger
encryption key.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA=A0 01748
+1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) =
293-7786
black_david@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754
----------------------------------------------------


From paul.hoffman@vpnc.org  Thu Jan 21 17:49:21 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 483A33A6822 for ; Thu, 21 Jan 2010 17:49:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.021
X-Spam-Level: 
X-Spam-Status: No, score=-6.021 tagged_above=-999 required=5 tests=[AWL=0.025,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbxRJ+zFWVWZ for ; Thu, 21 Jan 2010 17:49:20 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 7D8963A6816 for ; Thu, 21 Jan 2010 17:49:20 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0M1nF56092623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Jan 2010 18:49:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
Date: Thu, 21 Jan 2010 17:49:12 -0800
To: IPsecme WG 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: [IPsec] Issue #156: SHOULD generate and accept which types?
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 01:49:21 -0000

Section 3.5 lists a bunch of ID types (ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, ID_IPV6_ADDR, ID_DER_ASN1_DN, ID_DER_ASN1_GN, and ID_KEY_ID), and then says:

Two implementations will interoperate only if each can generate a type of ID acceptable to the other. To assure maximum interoperability, implementations MUST be configurable to send at least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and MUST be configurable to accept all of these types. Implementations SHOULD be capable of generating and accepting all of these types. IPv6-capable implementations MUST additionally be configurable to accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable to send only ID_IPV6_ADDR.

What does "Implementations SHOULD be capable of generating and accepting all of these types" mean? It can't mean the four just listed, because that list of four comes with MUSTs. If it means all the listed types, the sentence should be changed to "Implementations SHOULD also be capable of generating ID_IPV6_ADDR, ID_DER_ASN1_DN, and ID_DER_ASN1_GN."

--Paul Hoffman, Director
--VPN Consortium

From Black_David@emc.com  Thu Jan 21 18:17:31 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 107E83A67F4 for ; Thu, 21 Jan 2010 18:17:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.224
X-Spam-Level: 
X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=0.375,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaI5tXqeoPKT for ; Thu, 21 Jan 2010 18:17:30 -0800 (PST)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id EAED73A62C1 for ; Thu, 21 Jan 2010 18:17:29 -0800 (PST)
Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id o0M2HOoL002791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jan 2010 21:17:24 -0500
Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 21 Jan 2010 21:17:15 -0500
Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.169.196]) by mailhub.lss.emc.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id o0M2HEi3017713; Thu, 21 Jan 2010 21:17:14 -0500
Received: from CORPUSMX80B.corp.emc.com ([10.254.89.203]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Jan 2010 21:17:13 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 21 Jan 2010 21:17:13 -0500
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPsec] Issue #156: SHOULD generate and accept which types?
Thread-Index: AcqbBSKKQLN1wk+7RZu8QUYLiWvLogAAwLqA
References: 
From: 
To: , 
X-OriginalArrivalTime: 22 Jan 2010 02:17:13.0937 (UTC) FILETIME=[02E9D410:01CA9B09]
X-EMM-EM: Active
Subject: Re: [IPsec] Issue #156: SHOULD generate and accept which types?
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 02:17:31 -0000

Paul,

> What does "Implementations SHOULD be capable of generating and
accepting all of these types" mean?

It's hair-splitting time ...

> To assure maximum interoperability, implementations MUST be
configurable to send at least one of
> ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and MUST be
configurable to accept all of these
> types.

Short version: MUST be able to send at least *1*, accept all *4*.

> Implementations SHOULD be capable of generating and accepting all of
these types.

Short version: In addition, SHOULD be able to send all *4*.

The SHOULD for "accepting" is redundant with the previous MUST, but the
SHOULD for "generating" is broader.

[... snip ...]

> If it means all the listed types, the sentence should be changed to
"Implementations SHOULD
> also be capable of generating ID_IPV6_ADDR, ID_DER_ASN1_DN, and
ID_DER_ASN1_GN."

Which I think amounts to a SHOULD for certificate support.  Is there a
good reason to go there?

Thanks,
--David


> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
Of Paul Hoffman
> Sent: Thursday, January 21, 2010 8:49 PM
> To: IPsecme WG
> Subject: [IPsec] Issue #156: SHOULD generate and accept which types?
>=20
> Section 3.5 lists a bunch of ID types (ID_IPV4_ADDR, ID_FQDN,
ID_RFC822_ADDR, ID_IPV6_ADDR,
> ID_DER_ASN1_DN, ID_DER_ASN1_GN, and ID_KEY_ID), and then says:
>=20
> Two implementations will interoperate only if each can generate a type
of ID acceptable to the other.
> To assure maximum interoperability, implementations MUST be
configurable to send at least one of
> ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and MUST be
configurable to accept all of these
> types. Implementations SHOULD be capable of generating and accepting
all of these types. IPv6-capable
> implementations MUST additionally be configurable to accept
ID_IPV6_ADDR. IPv6-only implementations
> MAY be configurable to send only ID_IPV6_ADDR.
>=20
> What does "Implementations SHOULD be capable of generating and
accepting all of these types" mean? It
> can't mean the four just listed, because that list of four comes with
MUSTs. If it means all the
> listed types, the sentence should be changed to "Implementations
SHOULD also be capable of generating
> ID_IPV6_ADDR, ID_DER_ASN1_DN, and ID_DER_ASN1_GN."
>=20
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec


From paul.hoffman@vpnc.org  Thu Jan 21 19:59:44 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C0463A6784 for ; Thu, 21 Jan 2010 19:59:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.022
X-Spam-Level: 
X-Spam-Status: No, score=-6.022 tagged_above=-999 required=5 tests=[AWL=0.024,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2pyNhrIEj9b for ; Thu, 21 Jan 2010 19:59:43 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 603A53A6823 for ; Thu, 21 Jan 2010 19:59:43 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0M3mTs5099291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jan 2010 20:48:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References:  
Date: Thu, 21 Jan 2010 19:48:27 -0800
To: , 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [IPsec] Issue #156: SHOULD generate and accept which types?
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 03:59:44 -0000

At 9:17 PM -0500 1/21/10,  wrote:
>Paul,
>
>> What does "Implementations SHOULD be capable of generating and
>accepting all of these types" mean?
>
>It's hair-splitting time ...
>
>> To assure maximum interoperability, implementations MUST be
>configurable to send at least one of
>> ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and MUST be
>configurable to accept all of these
>> types.
>
>Short version: MUST be able to send at least *1*, accept all *4*.
>
>> Implementations SHOULD be capable of generating and accepting all of
>these types.
>
>Short version: In addition, SHOULD be able to send all *4*.
>
>The SHOULD for "accepting" is redundant with the previous MUST, but the
>SHOULD for "generating" is broader.
>
>[... snip ...]
>
>> If it means all the listed types, the sentence should be changed to
>"Implementations SHOULD
>> also be capable of generating ID_IPV6_ADDR, ID_DER_ASN1_DN, and
>ID_DER_ASN1_GN."
>
>Which I think amounts to a SHOULD for certificate support.  Is there a
>good reason to go there?

This interpretation is quite surprising to me (but I am surprised often these days...). What do others think?

--Paul Hoffman, Director
--VPN Consortium

From svanru@gmail.com  Thu Jan 21 22:44:29 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D39273A68FA for ; Thu, 21 Jan 2010 22:44:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level: 
X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, XMAILER_MIMEOLE_OL_7533E=0.513]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nw-ucIDwqbW3 for ; Thu, 21 Jan 2010 22:44:29 -0800 (PST)
Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id D205E3A68AD for ; Thu, 21 Jan 2010 22:44:28 -0800 (PST)
Received: by ey-out-2122.google.com with SMTP id 22so217649eye.51 for ; Thu, 21 Jan 2010 22:44:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:cc :references:subject:date:mime-version:content-type :content-transfer-encoding:x-priority:x-msmail-priority:x-mailer :x-mimeole; bh=XzSbPnUdll44bBMl5L3pDyxmXf7OhEN/tLEbyy0qC6I=; b=VaDX3HPIa8HYPtA/Ui19Rj0dJSh2MpxUcwvKM+kCwPcOH8krlT8ydYtdFCD7f3mbZq dvw2lD5EbE9VWSbjWL13Mw4lNOBpqvkD2IMgnSsYgrD0om1G5ePs2/fbFGkL48t1Sre+ lZ6l9FaSI19Sb1jXBcRYbCRDDAwQCD1dKtZKo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=KbVIFi3Gs6f6HmVCskSoQctmsPVh+z+PmbFArImyl+vBHj5n0LqasOxW1v7aPRsHNd HN83GWw+DlMhxyAXDQj9KcDZcj5nluv+v5LuZoJjmH0i/1IKI096C+cvoAAnYDv1ITT4 W2Ui8i25MX/6ISu59tsJ7S215CfbqwC0FAgd8=
Received: by 10.213.104.72 with SMTP id n8mr3322634ebo.13.1264142661378; Thu, 21 Jan 2010 22:44:21 -0800 (PST)
Received: from svanpc ([82.138.51.4]) by mx.google.com with ESMTPS id 13sm1514208ewy.13.2010.01.21.22.44.18 (version=SSLv3 cipher=RC4-MD5); Thu, 21 Jan 2010 22:44:20 -0800 (PST)
Message-ID: <1BDA56B00626423DA442A39B4703BDF8@trustworks.com>
From: "Valery Smyslov" 
To: , 
References: <064.cff10879f1e3e888fa8930a85464b847@tools.ietf.org><8C41856B-9D3B-4442-B214-5ED60C23906A@checkpoint.com><19288.15645.382443.519149@fireball.kivinen.iki.fi> <19288.48466.976054.136453@fireball.kivinen.iki.fi> 
Date: Fri, 22 Jan 2010 09:45:01 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4963.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Issue #139: Keying material taken in the order for RoHC
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 06:44:30 -0000

> > So, I think it is better to rely on RFC4301 here and leave 3rd bullet
out.
>
> That also works for the GCM and CCM examples because their necessary
details
> are already specified in the GCM and CCM RFCs.  GCM and CCM actually take
salt
> values for nonces (as opposed to the nonces themselves from the generated
keying
> material.  The RFCs for these two transforms are carefully written to
specify
> that one larger chunk of keying material is taken and then divided into
salt
> and key (see RFC 4106, Section 8.1 and RFC 4309, Section 7.1).
>
> What this means is that from the point of view of how the generated keying
> material is consumed, a GCM or CCM salt is logically part of a larger
> encryption key.

Yes, I know it. Probably my example was a bit misleading. I meant that if
some
future protocol consumes key bits for purposes other than encryption or
authentication
(for example, some compression algorithm that needs to be initialized with
unpredictable
data), the 3rd bullet from RFC4306 will not work.

And, I think, it is better to rely on text from RFC4301 from architectural
point of view:
IKE defines rules for deriving keys for child SAs from keying material
(treating each child
SA key as one entity), and protocol specifications define rules for deriving
individual
keys from that child SA key (currently RFC4301 defines such rule for ESP and
AH).

Regards,
Valery Smyslov.



From svanru@gmail.com  Thu Jan 21 22:55:40 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A08F3A68E8 for ; Thu, 21 Jan 2010 22:55:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level: 
X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, XMAILER_MIMEOLE_OL_7533E=0.513]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEQ3Nyh-g6FC for ; Thu, 21 Jan 2010 22:55:39 -0800 (PST)
Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 338AE3A68AD for ; Thu, 21 Jan 2010 22:55:39 -0800 (PST)
Received: by ey-out-2122.google.com with SMTP id 22so49222eye.5 for ; Thu, 21 Jan 2010 22:55:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:references :subject:date:mime-version:content-type:content-transfer-encoding :x-priority:x-msmail-priority:x-mailer:x-mimeole; bh=zAAw+5PgLiwXboTJ5bvHSNEvAkPCOkjihs5VBvfLpsI=; b=QPuKba5HSyf/YmBAz8vewBWPERsk6EdlQECvMDVrgzf22efI5eBqPSsr/igp5cI5VF PHEdMLrj0goYOg9LLYZ6leNuc53ZXuD01W5VhCGt0lE1J+CIhIIJ/20mmOiGoBvTkwEp Yt/hyVKpALLdXLclRkek4yAsjKlKkERZfRCdo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=W9chuPfZ3opWStgZFps1qmg2iV30/pV8oVUa7l1zaLBi6eB4bpZDHq2hkXfOhIuGke jsJnZSbSjG6R1vyzI9UWv3ZqvJqBYy0J4pfiuuZmcmj1w2H6pxIrCQ7LVnXq3TW+J8AW j7wVskh1LwXykouUE/IhKen4IX0+XW+DFgDIQ=
Received: by 10.213.96.206 with SMTP id i14mr2352409ebn.74.1264143331776; Thu, 21 Jan 2010 22:55:31 -0800 (PST)
Received: from svanpc ([82.138.51.4]) by mx.google.com with ESMTPS id 16sm1520468ewy.2.2010.01.21.22.55.30 (version=SSLv3 cipher=RC4-MD5); Thu, 21 Jan 2010 22:55:30 -0800 (PST)
Message-ID: 
From: "Valery Smyslov" 
To: "IPsecme WG" , "Paul Hoffman" 
References: 
Date: Fri, 22 Jan 2010 09:56:12 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4963.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700
Subject: Re: [IPsec] Issue #156: SHOULD generate and accept which types?
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 06:55:40 -0000

Paul Hoffman writes:

> Section 3.5 lists a bunch of ID types (ID_IPV4_ADDR, ID_FQDN,
ID_RFC822_ADDR, ID_IPV6_ADDR, ID_DER_ASN1_DN, ID_DER_ASN1_GN, and
ID_KEY_ID), and then says:
>
> Two implementations will interoperate only if each can generate a type of
ID acceptable to the other. To assure maximum interoperability,
implementations MUST be configurable to send at least one of ID_IPV4_ADDR,
ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and MUST be configurable to accept
all of these types. Implementations SHOULD be capable of generating and
accepting all of these types. IPv6-capable implementations MUST additionally
be configurable to accept ID_IPV6_ADDR. IPv6-only implementations MAY be
configurable to send only ID_IPV6_ADDR.
>
> What does "Implementations SHOULD be capable of generating and accepting
all of these types" mean? It can't mean the four just listed, because that
list of four comes with MUSTs. If it means all the listed types, the
sentence should be changed to "Implementations SHOULD also be capable of
generating ID_IPV6_ADDR, ID_DER_ASN1_DN, and ID_DER_ASN1_GN."

In addition, this is inconsistent with section 4 (Conformance Requirements),
which states:

   For an implementation to be called conforming to this specification,
   it MUST be possible to configure it to accept the following:

   o  PKIX Certificates containing and signed by RSA keys of size 1024
      or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN,
      ID_RFC822_ADDR, or ID_DER_ASN1_DN.

   o  Shared key authentication where the ID passed is any of ID_KEY_ID,
      ID_FQDN, or ID_RFC822_ADDR.

   o  Authentication where the responder is authenticated using PKIX
      Certificates and the initiator is authenticated using shared key
      authentication.

Regards,
Valery Smyslov.



From svanru@gmail.com  Thu Jan 21 22:59:37 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE1293A68FA for ; Thu, 21 Jan 2010 22:59:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level: 
X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, XMAILER_MIMEOLE_OL_7533E=0.513]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfsZfFBKRhl6 for ; Thu, 21 Jan 2010 22:59:36 -0800 (PST)
Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by core3.amsl.com (Postfix) with ESMTP id 9E7A93A68E8 for ; Thu, 21 Jan 2010 22:59:36 -0800 (PST)
Received: by ewy3 with SMTP id 3so1138042ewy.13 for ; Thu, 21 Jan 2010 22:59:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:references :subject:date:mime-version:content-type:content-transfer-encoding :x-priority:x-msmail-priority:x-mailer:x-mimeole; bh=vNqwmYPzfEQvA4GRFueEjb17JWJ/p7TzKJiM75pcOPE=; b=W3Hf9euK/WiuFzZNRj41cU6b9Gygd7XhthnHJHmlZqE2/XaFt6awyftwLLeLLeAFG+ P9UjYxlSlL5p/bhmyHtuOYKZ/ShzAjibHo/ES53gkDesgxZAcNCmBE7svNr+1tcCfq6h qxIxDNexxtB9A6DVzqb0wi3JxTkiUW6xICzO8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=iEO0hDSa28Q2I/9y7yCY3coXL9iub6P0ivcVKLbdTzN42dXpZnjO7uOKpiyyUk/tQO HWwEM4rmy+6qUOyUhNwOvNSV3yA99g7XSlD4J0vio/EuN8AkS1tEdshB6/+8/Bth3h+n iKo6oHKWezImfi+53gVYFZsyqrKX9diQcr+7g=
Received: by 10.213.66.5 with SMTP id l5mr3336132ebi.15.1264143568743; Thu, 21 Jan 2010 22:59:28 -0800 (PST)
Received: from svanpc ([82.138.51.4]) by mx.google.com with ESMTPS id 14sm1525048ewy.11.2010.01.21.22.59.26 (version=SSLv3 cipher=RC4-MD5); Thu, 21 Jan 2010 22:59:27 -0800 (PST)
Message-ID: <21F680D406E04655B8B4D06CB8214BCF@trustworks.com>
From: "Valery Smyslov" 
To: , , 
References:  
Date: Fri, 22 Jan 2010 10:00:09 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4963.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700
Subject: Re: [IPsec] Issue #156: SHOULD generate and accept which types?
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 06:59:37 -0000

Black David writes:

> > If it means all the listed types, the sentence should be changed to
> "Implementations SHOULD
> > also be capable of generating ID_IPV6_ADDR, ID_DER_ASN1_DN, and
> ID_DER_ASN1_GN."
> 
> Which I think amounts to a SHOULD for certificate support.  Is there a
> good reason to go there?

It is already there :-) See section 4 (Conformance Requirements):

   For an implementation to be called conforming to this specification,
   it MUST be possible to configure it to accept the following:

   o  PKIX Certificates containing and signed by RSA keys of size 1024
      or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN,
      ID_RFC822_ADDR, or ID_DER_ASN1_DN.

   o  Shared key authentication where the ID passed is any of ID_KEY_ID,
      ID_FQDN, or ID_RFC822_ADDR.

   o  Authentication where the responder is authenticated using PKIX
      Certificates and the initiator is authenticated using shared key
      authentication.

Regards,
Valery Smyslov.



From kivinen@iki.fi  Fri Jan 22 01:54:24 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7C263A6970 for ; Fri, 22 Jan 2010 01:54:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.567
X-Spam-Level: 
X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPpcVbx7KTpo for ; Fri, 22 Jan 2010 01:54:24 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 973973A697A for ; Fri, 22 Jan 2010 01:54:22 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0M9s80Y013936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jan 2010 11:54:08 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0M9s7XJ024332; Fri, 22 Jan 2010 11:54:07 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19289.30143.562354.48214@fireball.kivinen.iki.fi>
Date: Fri, 22 Jan 2010 11:54:07 +0200
From: Tero Kivinen 
To: Paul Hoffman 
In-Reply-To: 
References:   
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 8 min
X-Total-Time: 7 min
Cc: ipsec@ietf.org, Black_David@emc.com
Subject: Re: [IPsec] Issue #156: SHOULD generate and accept which types?
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 09:54:24 -0000

Paul Hoffman writes:
> At 9:17 PM -0500 1/21/10,  wrote:
> >Paul,
> >
> >> What does "Implementations SHOULD be capable of generating and
> >accepting all of these types" mean?
> >
> >It's hair-splitting time ...
> >
> >> To assure maximum interoperability, implementations MUST be
> >configurable to send at least one of
> >> ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and MUST be
> >configurable to accept all of these
> >> types.
> >
> >Short version: MUST be able to send at least *1*, accept all *4*.
> >
> >> Implementations SHOULD be capable of generating and accepting all of
> >these types.
> >
> >Short version: In addition, SHOULD be able to send all *4*.
> >
> >The SHOULD for "accepting" is redundant with the previous MUST, but the
> >SHOULD for "generating" is broader.
> >
> >[... snip ...]
> >
> >> If it means all the listed types, the sentence should be changed to
> >"Implementations SHOULD
> >> also be capable of generating ID_IPV6_ADDR, ID_DER_ASN1_DN, and
> >ID_DER_ASN1_GN."
> >
> >Which I think amounts to a SHOULD for certificate support.  Is there a
> >good reason to go there?
> 
> This interpretation is quite surprising to me (but I am surprised
> often these days...). What do others think? 

I interpreted it so that MUST be able to send one, accept all four
and SHOULD be able to send all four.

Note, also that Section 4 also lists in its conformance list that all
implementations MUST be able to be configured to accept:
----------------------------------------------------------------------
   For an implementation to be called conforming to this specification,
   it MUST be possible to configure it to accept the following:

   o  PKIX Certificates containing and signed by RSA keys of size 1024
      or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN,
      ID_RFC822_ADDR, or ID_DER_ASN1_DN.

   o  Shared key authentication where the ID passed is any of ID_KEY_ID,
      ID_FQDN, or ID_RFC822_ADDR.

   o  Authentication where the responder is authenticated using PKIX
      Certificates and the initiator is authenticated using shared key
      authentication.
----------------------------------------------------------------------

I.e. that adds ID_DER_ASN1_DN for certificates, and does not list
ID_IPV*_ADDR at all.

I.e. even when ID_IPV4_ADDR is mandatory to be implement, that does
not need to be one of the configurations that is required from
implementation (which is ok, as if you make implementation which is
always behind NAT, then IP-address is not something you want to allow
to be configured as ID).

So Certificate support is already MUST, Shared key authentication is
MUST. ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR are MUST for accept for both
authentication, ands ID_DER_ASN1_DN is MUST for accept for certificate
authentication.

The section 4 can also be understood that sending all of the ID
formats is also required, as the text says "ID passed is any of ..."
which would indicate that it requires also sending those ID types.

These requirements are not required to be same, as the other covers
the ID payload support, and the other covers the how the whole system
is configured and used.
-- 
kivinen@iki.fi

From rsjenwar@gmail.com  Fri Jan 22 02:34:54 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B97183A6966 for ; Fri, 22 Jan 2010 02:34:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtZnj5ARtSfy for ; Fri, 22 Jan 2010 02:34:53 -0800 (PST)
Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id 1512B3A698A for ; Fri, 22 Jan 2010 02:34:52 -0800 (PST)
Received: by ewy8 with SMTP id 8so1107178ewy.29 for ; Fri, 22 Jan 2010 02:34:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=hpex4XUJA1BEPj+iL++Rxs7vl9meKAgn2qoOlpl3gzg=; b=H27UJXgCBP3lzFoJ6O5l4Pv/hBLIEejhpRGqqv0/PXdSTJUnF+HxIi9+nWvcQWsNQ0 aXjKY6ouxPQ/qIiGP5SD0BgJ3RvjvlDc7LGapBAc2xWWh2s+fdQqzswmCzNzJhP558nX QkYV2yBM1fGt+j+PGrDcQThQO0aktwIUMzhR0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bVGJHgcopHA5sGiXkKv1CDkCfK8Yd2koj+BGH+n03amue5Jc7bAqJfKfy4G3TZJvcS rVTrajED2OzVP3cRbS2ILPjMqxWsiWztE7z+UBtj2ovxvkpRMS6Gzgq8lUS2Ptg/z37H DIel/Xa+57RIrzyCKoiGASdW+bl4frlCdZ0Rs=
MIME-Version: 1.0
Received: by 10.216.89.137 with SMTP id c9mr1043875wef.228.1264156484884; Fri,  22 Jan 2010 02:34:44 -0800 (PST)
In-Reply-To: <19289.30143.562354.48214@fireball.kivinen.iki.fi>
References:    <19289.30143.562354.48214@fireball.kivinen.iki.fi>
Date: Fri, 22 Jan 2010 16:04:44 +0530
Message-ID: <7ccecf671001220234v2276f900t3460e5dfb776d837@mail.gmail.com>
From: Raj Singh 
To: Tero Kivinen 
Content-Type: multipart/alternative; boundary=0016e6d9714f38db56047dbe5ec5
Cc: ipsec@ietf.org, Valery Smyslov , Paul Hoffman , Black_David@emc.com
Subject: Re: [IPsec] Issue #156: SHOULD generate and accept which types?
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 10:34:54 -0000

--0016e6d9714f38db56047dbe5ec5
Content-Type: text/plain; charset=UTF-8

Hi Team,

I agree with Tero explanation and Valery objection as well.
There is discrepancy between 3.5 and 4.
1. Section 4 mandates certificates but section 3.5 doesn't.
2. Its seen in practice that some implementation uses IP addresses as
default ID even though they are
using certificate based authentication or they are behind NAT.
This should is NO use as explained by Tero and should be discouraged in
draft and proper ID types i.e. ID_DER_ASN1_DN for
certificate based authentication should be encouraged.

Regards,
Raj


On Fri, Jan 22, 2010 at 3:24 PM, Tero Kivinen  wrote:

> Paul Hoffman writes:
> > At 9:17 PM -0500 1/21/10,  wrote:
> > >Paul,
> > >
> > >> What does "Implementations SHOULD be capable of generating and
> > >accepting all of these types" mean?
> > >
> > >It's hair-splitting time ...
> > >
> > >> To assure maximum interoperability, implementations MUST be
> > >configurable to send at least one of
> > >> ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and MUST be
> > >configurable to accept all of these
> > >> types.
> > >
> > >Short version: MUST be able to send at least *1*, accept all *4*.
> > >
> > >> Implementations SHOULD be capable of generating and accepting all of
> > >these types.
> > >
> > >Short version: In addition, SHOULD be able to send all *4*.
> > >
> > >The SHOULD for "accepting" is redundant with the previous MUST, but the
> > >SHOULD for "generating" is broader.
> > >
> > >[... snip ...]
> > >
> > >> If it means all the listed types, the sentence should be changed to
> > >"Implementations SHOULD
> > >> also be capable of generating ID_IPV6_ADDR, ID_DER_ASN1_DN, and
> > >ID_DER_ASN1_GN."
> > >
> > >Which I think amounts to a SHOULD for certificate support.  Is there a
> > >good reason to go there?
> >
> > This interpretation is quite surprising to me (but I am surprised
> > often these days...). What do others think?
>
> I interpreted it so that MUST be able to send one, accept all four
> and SHOULD be able to send all four.
>
> Note, also that Section 4 also lists in its conformance list that all
> implementations MUST be able to be configured to accept:
> ----------------------------------------------------------------------
>    For an implementation to be called conforming to this specification,
>   it MUST be possible to configure it to accept the following:
>
>   o  PKIX Certificates containing and signed by RSA keys of size 1024
>      or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN,
>      ID_RFC822_ADDR, or ID_DER_ASN1_DN.
>
>   o  Shared key authentication where the ID passed is any of ID_KEY_ID,
>      ID_FQDN, or ID_RFC822_ADDR.
>
>   o  Authentication where the responder is authenticated using PKIX
>      Certificates and the initiator is authenticated using shared key
>      authentication.
> ----------------------------------------------------------------------
>
> I.e. that adds ID_DER_ASN1_DN for certificates, and does not list
> ID_IPV*_ADDR at all.
>
> I.e. even when ID_IPV4_ADDR is mandatory to be implement, that does
> not need to be one of the configurations that is required from
> implementation (which is ok, as if you make implementation which is
> always behind NAT, then IP-address is not something you want to allow
> to be configured as ID).
>
> So Certificate support is already MUST, Shared key authentication is
> MUST. ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR are MUST for accept for both
> authentication, ands ID_DER_ASN1_DN is MUST for accept for certificate
> authentication.
>
> The section 4 can also be understood that sending all of the ID
> formats is also required, as the text says "ID passed is any of ..."
> which would indicate that it requires also sending those ID types.
>
> These requirements are not required to be same, as the other covers
> the ID payload support, and the other covers the how the whole system
> is configured and used.
> --
> kivinen@iki.fi
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>

--0016e6d9714f38db56047dbe5ec5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Team,

I agree with Tero explanation and Valery objection as well.=

There is discrepancy between 3.5 and 4.
1. Section 4 mandates certif=
icates but section 3.5 doesn't.
2. Its seen in practice that some im=
plementation uses IP addresses as default ID even though they are 

using certificate based authentication or they are behind NAT. 
This sho=
uld is NO use as explained by Tero and should be discouraged in draft and p=
roper ID types i.e. ID_DER_ASN1_DN for 
certificate based authentication=
 should be encouraged.


Regards,
Raj


On Fri, Jan 22, 2=
010 at 3:24 PM, Tero Kivinen <kivinen@iki.fi> wrote:


<=
div>Paul Hoffman writes:

> At 9:17 PM -0500 1/21/10, <Black_David@emc.com> wrote:

> >Paul,

> >

> >> What does "Implementations SHOULD be capable of generati=
ng and

> >accepting all of these types" mean?

> >

> >It's hair-splitting time ...

> >

> >> To assure maximum interoperability, implementations MUST be
> >configurable to send at least one of

> >> ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and MUST=
 be

> >configurable to accept all of these

> >> types.

> >

> >Short version: MUST be able to send at least *1*, accept all *4*.<=
br>
> >

> >> Implementations SHOULD be capable of generating and accepting=
 all of

> >these types.

> >

> >Short version: In addition, SHOULD be able to send all *4*.

> >

> >The SHOULD for "accepting" is redundant with the previou=
s MUST, but the

> >SHOULD for "generating" is broader.

> >

> >[... snip ...]

> >

> >> If it means all the listed types, the sentence should be chan=
ged to

> >"Implementations SHOULD

> >> also be capable of generating ID_IPV6_ADDR, ID_DER_ASN1_DN, a=
nd

> >ID_DER_ASN1_GN."

> >

> >Which I think amounts to a SHOULD for certificate support. =C2=A0I=
s there a

> >good reason to go there?

>

> This interpretation is quite surprising to me (but I am surprised

> often these days...). What do others think?




I interpreted it so that MUST be able to send one, accept all f=
our

and SHOULD be able to send all four.



Note, also that Section 4 also lists in its conformance list that all

implementations MUST be able to be configured to accept:

----------------------------------------------------------------------


 =C2=A0 For an implementation to be called conforming to this specific=
ation,

 =C2=A0 it MUST be possible to configure it to accept the following:



 =C2=A0 o =C2=A0PKIX Certificates containing and signed by RSA keys of size=
 1024

 =C2=A0 =C2=A0 =C2=A0or 2048 bits, where the ID passed is any of ID_KEY_ID,=
 ID_FQDN,

 =C2=A0 =C2=A0 =C2=A0ID_RFC822_ADDR, or ID_DER_ASN1_DN.



 =C2=A0 o =C2=A0Shared key authentication where the ID passed is any of ID_=
KEY_ID,

 =C2=A0 =C2=A0 =C2=A0ID_FQDN, or ID_RFC822_ADDR.



 =C2=A0 o =C2=A0Authentication where the responder is authenticated using P=
KIX

 =C2=A0 =C2=A0 =C2=A0Certificates and the initiator is authenticated using =
shared key

 =C2=A0 =C2=A0 =C2=A0authentication.


---------------------------------------------------------------------=
-



I.e. that adds ID_DER_ASN1_DN for certificates, and does not list

ID_IPV*_ADDR at all.



I.e. even when ID_IPV4_ADDR is mandatory to be implement, that does

not need to be one of the configurations that is required from

implementation (which is ok, as if you make implementation which is

always behind NAT, then IP-address is not something you want to allow

to be configured as ID).



So Certificate support is already MUST, Shared key authentication is

MUST. ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR are MUST for accept for both

authentication, ands ID_DER_ASN1_DN is MUST for accept for certificate

authentication.



The section 4 can also be understood that sending all of the ID

formats is also required, as the text says "ID passed is any of ...&qu=
ot;

which would indicate that it requires also sending those ID types.



These requirements are not required to be same, as the other covers

the ID payload support, and the other covers the how the whole system

is configured and used.

--

kivinen@iki.fi


_______________________________________________=


IPsec mailing list

IPsec@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/ipsec





--0016e6d9714f38db56047dbe5ec5--

From kivinen@iki.fi  Fri Jan 22 03:46:05 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 918CF3A67C0 for ; Fri, 22 Jan 2010 03:46:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level: 
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNTabYvZCUkS for ; Fri, 22 Jan 2010 03:46:04 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 57FF83A6895 for ; Fri, 22 Jan 2010 03:46:03 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0MBjl35005084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jan 2010 13:45:47 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0MBjk4H018304; Fri, 22 Jan 2010 13:45:46 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19289.36842.223655.321621@fireball.kivinen.iki.fi>
Date: Fri, 22 Jan 2010 13:45:46 +0200
From: Tero Kivinen 
To: Raj Singh 
In-Reply-To: <7ccecf671001220234v2276f900t3460e5dfb776d837@mail.gmail.com>
References:    <19289.30143.562354.48214@fireball.kivinen.iki.fi> <7ccecf671001220234v2276f900t3460e5dfb776d837@mail.gmail.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 7 min
X-Total-Time: 7 min
Cc: ipsec@ietf.org, Valery Smyslov , Paul Hoffman , Black_David@emc.com
Subject: Re: [IPsec] Issue #156: SHOULD generate and accept which types?
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 11:46:05 -0000

Raj Singh writes:
> I agree with Tero explanation and Valery objection as well.
> There is discrepancy between 3.5 and 4.

Not really. Not all requirements needs to be in one place. One place
can say that XXX is required and another place can say that also YYY
is required, but only if doing ZZZ. 

> 1. Section 4 mandates certificates but section 3.5 doesn't.

Section 3.5 does not and should not say anything about certificates,
it just lists which ID types there are which of them needs to be
supported.

> 2. Its seen in practice that some implementation uses IP addresses as
> default ID even though they are
> using certificate based authentication or they are behind NAT.

And this is allowed and section 3.5 sees that ID_IPV4_ADDR support is
madantory (and ID_IPV6_ADDR is mandatory for IPv6-capable
implementations).

Nothing in the section 4 claims otherwise, so they are still mandatory
to accept from the other end. 

On the other hand section 4 does not require ID_IPV*_ADDR address to
be one of those which can be configured to be used and it adds one
more requirement compared to what section 3.5 said i.e. it says that
if PKIX certifiates are used then implementations need to also needto
be able to use ID_DER_ASN1_DN.

> This should is NO use as explained by Tero and should be discouraged in
> draft and proper ID types i.e. ID_DER_ASN1_DN for
> certificate based authentication should be encouraged.
-- 
kivinen@iki.fi

From rsjenwar@gmail.com  Fri Jan 22 05:14:53 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF48A3A698E for ; Fri, 22 Jan 2010 05:14:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ncVEYpNzpSe for ; Fri, 22 Jan 2010 05:14:53 -0800 (PST)
Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id BF9A83A68E7 for ; Fri, 22 Jan 2010 05:14:52 -0800 (PST)
Received: by ewy8 with SMTP id 8so1272495ewy.29 for ; Fri, 22 Jan 2010 05:14:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=VMuw2HRAlAWLeHmCBg+1lJrZuXZGKksp2hNyvGTZSUU=; b=DMrrpuO13IDCTVZM9nB7UdUKrwCZnc6yrx2/prntI8Fy41UXbFnuFQk0Gye4Po6h0d nFx4o4se0AGljxFJQQKlRMzM5a4TEdsnlXTPUxmY4X/OJiKvBekZL2EVzoFVv/sMnDVA UCI+TQCb8Bo5c38C20j+RfKng/4u59TajElQM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lcQIXvowtG4+aOaEwvPltWoGToF/8UYZvMYtVcNYccIpgHLarQDSkYcZWxiHb2z2wh Jb0MEsYa8sA+85DPnEsBkVMvfDaCo/nZBL54GY/r159YfSDOB+kO5FhXAJTD7go2tEB3 5P54nl9bU/5/WYsWy50WwxzMm6BNu9w7SRemQ=
MIME-Version: 1.0
Received: by 10.216.86.3 with SMTP id v3mr1173680wee.165.1264166082201; Fri,  22 Jan 2010 05:14:42 -0800 (PST)
In-Reply-To: <19289.36842.223655.321621@fireball.kivinen.iki.fi>
References:    <19289.30143.562354.48214@fireball.kivinen.iki.fi> <7ccecf671001220234v2276f900t3460e5dfb776d837@mail.gmail.com> <19289.36842.223655.321621@fireball.kivinen.iki.fi>
Date: Fri, 22 Jan 2010 18:44:42 +0530
Message-ID: <7ccecf671001220514w1af70d08m9eea22863126c0a5@mail.gmail.com>
From: Raj Singh 
To: Tero Kivinen 
Content-Type: text/plain; charset=UTF-8
Cc: ipsec@ietf.org, Valery Smyslov , Paul Hoffman , Black_David@emc.com
Subject: Re: [IPsec] Issue #156: SHOULD generate and accept which types?
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 13:14:54 -0000

On Fri, Jan 22, 2010 at 5:15 PM, Tero Kivinen  wrote:
>
> Raj Singh writes:
> > I agree with Tero explanation and Valery objection as well.
> > There is discrepancy between 3.5 and 4.
>
> Not really. Not all requirements needs to be in one place. One place
> can say that XXX is required and another place can say that also YYY
> is required, but only if doing ZZZ.
>
> > 1. Section 4 mandates certificates but section 3.5 doesn't.
>
> Section 3.5 does not and should not say anything about certificates,
> it just lists which ID types there are which of them needs to be
> supported.

Agree. But it should mandate ID_DER_ASN1_DN which it doesn't.
>
> > 2. Its seen in practice that some implementation uses IP addresses as
> > default ID even though they are
> > using certificate based authentication or they are behind NAT.
>
> And this is allowed and section 3.5 sees that ID_IPV4_ADDR support is
> madantory (and ID_IPV6_ADDR is mandatory for IPv6-capable
> implementations).
>
> Nothing in the section 4 claims otherwise, so they are still mandatory
> to accept from the other end.
>
> On the other hand section 4 does not require ID_IPV*_ADDR address to
> be one of those which can be configured to be used and it adds one
> more requirement compared to what section 3.5 said i.e. it says that
> if PKIX certifiates are used then implementations need to also needto
> be able to use ID_DER_ASN1_DN.

To put my point simply:
1. Section 3.5:
    -----------------
   Two implementations will interoperate only if each can generate a
   type of ID acceptable to the other.  To assure maximum
   interoperability, implementations MUST be configurable to send at
   least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and
   MUST be configurable to accept all of these types.
   -------------------

   Here we are mandating that an implementation MUST be able to configure to
   accept 4 ID types with types without any mention of ID_DER_ASN1_DN.

   Section 4:
   ---------------
   For an implementation to be called conforming to this specification,
   it MUST be possible to configure it to accept the following:

   - PKIX Certificates containing and signed by RSA keys of size 1024
      or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN,
      ID_RFC822_ADDR, or ID_DER_ASN1_DN.
   ----------------

  Here we are also mandating than an implementaion MUST be able to configure
  to accept  ID_DER_ASN1_DN.

This is what i was referring to that there is some discrepancy between
3.5 and 4.

As PKIX support is MUST for implementations of ikev2bis, we can't say that
we are adding one more requirement if PKIX is supported.
>
> > This should is NO use as explained by Tero and should be discouraged in
> > draft and proper ID types i.e. ID_DER_ASN1_DN for
> > certificate based authentication should be encouraged.
> --
> kivinen@iki.fi

From svanru@gmail.com  Fri Jan 22 06:04:32 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 926403A68AF for ; Fri, 22 Jan 2010 06:04:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level: 
X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, XMAILER_MIMEOLE_OL_7533E=0.513]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THblzUdEnKFv for ; Fri, 22 Jan 2010 06:04:31 -0800 (PST)
Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id 9EDA93A68A0 for ; Fri, 22 Jan 2010 06:04:31 -0800 (PST)
Received: by ewy8 with SMTP id 8so1327762ewy.29 for ; Fri, 22 Jan 2010 06:04:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:cc :references:subject:date:mime-version:content-type :content-transfer-encoding:x-priority:x-msmail-priority:x-mailer :x-mimeole; bh=OPzSQAlQvhcsKM6lD4y4BMioQlK2meQ868Hrmbm12Q8=; b=q0nCT3rXPZ7gC6lRAVh1e9bRu5jZ+SqBKj3qOej+LleC9ZUZeeVmpdJr42DrPvbPYU YfkuCMSa578bRoq+uKo/FxUQ6Inxu3uCfgzGCGuW38ko7dgoq0Ce8SK/A5avl9GzvqI4 x7W8QnnMVO1PjsCV6d8LGIRPvw3KjwEMS7jKk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=b24tH+OQCqEPlHmweG/Sc3Wr0/SoeUPqLoQGaUZxIUSBBArAbfI++WmfAU6Wnu8Z5S EGRaEHDk8KgN/kAdJuiq7R+cXhHUBiEztb4zXNpdnQPCXAgpLzfFnq3AL83hV5q2HZFF NJrYh2h0kI79FLsbGsBn/BiUlGv68/RvTjj6A=
Received: by 10.213.50.142 with SMTP id z14mr3816170ebf.30.1264169063792; Fri, 22 Jan 2010 06:04:23 -0800 (PST)
Received: from svanpc ([82.138.51.4]) by mx.google.com with ESMTPS id 16sm1776101ewy.14.2010.01.22.06.04.21 (version=SSLv3 cipher=RC4-MD5); Fri, 22 Jan 2010 06:04:22 -0800 (PST)
Message-ID: <0359F1DF4A124123AC37E5CE6F58F420@trustworks.com>
From: "Valery Smyslov" 
To: "Raj Singh" , "Tero Kivinen" 
References:    <19289.30143.562354.48214@fireball.kivinen.iki.fi> <7ccecf671001220234v2276f900t3460e5dfb776d837@mail.gmail.com> <19289.36842.223655.321621@fireball.kivinen.iki.fi> <7ccecf671001220514w1af70d08m9eea22863126c0a5@mail.gmail.com>
Date: Fri, 22 Jan 2010 17:05:01 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4963.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700
Cc: ipsec@ietf.org, Paul Hoffman , Black_David@emc.com
Subject: Re: [IPsec] Issue #156: SHOULD generate and accept which types?
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 14:04:32 -0000

Raj Singh writes:

> > Not really. Not all requirements needs to be in one place. One place
> > can say that XXX is required and another place can say that also YYY
> > is required, but only if doing ZZZ.
> >
> > > 1. Section 4 mandates certificates but section 3.5 doesn't.
> >
> > Section 3.5 does not and should not say anything about certificates,
> > it just lists which ID types there are which of them needs to be
> > supported.
> 
> Agree. But it should mandate ID_DER_ASN1_DN which it doesn't.

Yes, that's what I meant.

And I want to raise one more issue. Section 4 mandates support 
for both PKIX and preshared key for conformant implementation. 
Isnt't it too strong requirement?

First, for some very simple implementations (garage door opener) 
it may be unnecessary and difficult to implement, providing
resource constraints (note, that full PKIX support is required,
so raw RSA keys are out of scope). Then, I don't like "MUST"
for particular algorithm (RSA) with particular parameters. 
One might have good reasons not to use RSA at all in favour
of other public cryptography schemes. On the other hand, 
one might want to completely get rid of preshared key authentication
in his/her product. And last, these requirements will automatically 
make non-conformant such proposed protocol extensions 
as EAP-only and password-based authentication.

I fully understand desire to help interoperability, but I think
that all requirements listed at the end of section 4 may be lowered 
to "SHOULD" (note, that this will not make any existing product 
non-conformant).

What others think?

Regards,
Valery Smyslov.



From yaronf@checkpoint.com  Fri Jan 22 10:09:07 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F1C13A69F3 for ; Fri, 22 Jan 2010 10:09:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d46lxfaKj55I for ; Fri, 22 Jan 2010 10:09:06 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id D69E33A6961 for ; Fri, 22 Jan 2010 10:09:05 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0MI90T7016627; Fri, 22 Jan 2010 20:09:00 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 22 Jan 2010 20:09:14 +0200
From: Yaron Sheffer 
To: Tero Kivinen 
Date: Fri, 22 Jan 2010 20:09:12 +0200
Thread-Topic: [IPsec] IKEv2-bis, comments up to 2.16
Thread-Index: AcqZ7brJCwuMlfmgTyGL9056sOuWMwBn6xHA
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A221E8@il-ex01.ad.checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21EF8@il-ex01.ad.checkpoint.com> <19286.62825.898863.477577@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21FEA@il-ex01.ad.checkpoint.com> <19287.12109.881311.935809@fireball.kivinen.iki.fi>
In-Reply-To: <19287.12109.881311.935809@fireball.kivinen.iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ipsec@ietf.org" 
Subject: Re: [IPsec] IKEv2-bis, comments up to 2.16
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 18:09:07 -0000

Hi Tero,

I was ready to accept your answer, until I came across the following senten=
ce in -07.

"Payloads are processed in the order in which they appear in an IKE message=
 by invoking the appropriate processing routine according to the "Next Payl=
oad" field in the IKE header and subsequently according to the "Next Payloa=
d" field in the IKE payload itself until a "Next Payload" field of zero ind=
icates that no payloads follow."

This seems to say exactly what I was proposing! Did I miss another statemen=
t in the document where we say the opposite (that payload order doesn't mat=
ter)?

Thanks,
	Yaron

> -----Original Message-----
> From: Tero Kivinen [mailto:kivinen@iki.fi]
> Sent: Wednesday, January 20, 2010 18:29
> To: Yaron Sheffer
> Cc: ipsec@ietf.org
> Subject: RE: [IPsec] IKEv2-bis, comments up to 2.16
>=20
> Yaron Sheffer writes:
> > > > 1.4: "The processing of an INFORMATIONAL exchange is determined
> by
> > > > its component payloads." Adding "The payloads are processed in
> > > > strict left-to-right order" would make it deterministic, and is
> > > > probably what people do today.
> > >
> > > There should be no need to make the processing deterministic, as at
> > > least I cannot think of case where the processing order would
> matter,
> > > and I do not want someone to start complaining if someone process
> them
> > > in "wrong" order.
> > >
> > > I do not think the addition should be done.
> >
> > I'm not convinced. CP payloads can do many things, including side
> > effects on other network components. Notifications are even more
> > open ended, with every IKE extension adding a new one. We should
> > recommend some deterministic processing.
>=20
> None of the current notifications or configuration payloads have such
> deterministic processing requirements, and if some extension adds new
> notifications of configuration payloads, then that document should
> also add requirement for their deterministic processing.
>=20
> For example in our implementation it is current impossible to process
> payloads in the order they appear in the packet, as we first parse all
> payloads from the packet, and during that tome process some of the
> payloads (for example configration payloads, and some notify
> payloads), but then for example delete payloads are processed later
> during INFORMATIONAL exchange processing. Also most of the notify
> payloads are processed later the initial pass just goes through those
> we need to see early (for example the NAT_DETECTION_* payloads), but
> some like INITIAL_CONTACT notifications are processed much later (i.e.
> only after the IKE_AUTH AUTH payloads has been verified).
>=20
> Adding requirement for order of payload processing would make
> implementation quite a much harder, and as there is currently no
> reason for it, I do not think it is good idea to add such requirement.
>=20


From jasolin@orion.ncsc.mil  Fri Jan 22 10:48:23 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7A7A3A6A57 for ; Fri, 22 Jan 2010 10:48:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Enjim7LBxZT5 for ; Fri, 22 Jan 2010 10:48:23 -0800 (PST)
Received: from msux-gh1-uea02.nsa.gov (msux-gh1-uea02.nsa.gov [63.239.67.2]) by core3.amsl.com (Postfix) with ESMTP id EFCB23A6A2F for ; Fri, 22 Jan 2010 10:48:22 -0800 (PST)
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id o0MImFPU025999 for ; Fri, 22 Jan 2010 18:48:15 GMT
Received: from [144.51.26.44] (moss-warsteiner [144.51.26.44]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id o0MImHIA007565 for ; Fri, 22 Jan 2010 13:48:18 -0500
Message-ID: <4B59F2F1.9030107@orion.ncsc.mil>
Date: Fri, 22 Jan 2010 13:48:17 -0500
From: "Jerome A. Solinas" 
User-Agent: Thunderbird 1.5.0.12 (X11/20090624)
MIME-Version: 1.0
To: ipsec@ietf.org
References: <19243.32427.247190.77844@fireball.kivinen.iki.fi> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-01)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 18:48:24 -0000

Paul Hoffman wrote:
> First off, thank you for bringing the topic to the WG. As the Designated Expert, you are certainly allowed to make decisions without asking, so it is extra nice that you ask on decisions that might be controversial.
>
> On this particular topic, I would note that RFC 4753 is Informational RFC, not a standards-track document. Thus, I would think that desires of the authors of the RFC should have a heavier influence than the rest of us, although our input might be important inputs to them (and maybe to the Designated Expert). Maybe we should put the issue aside until we hear from them, which could be after the holiday.
>
> --Paul Hoffman, Director
>   
We would recommend keeping the same numbers (19, 20, 21) since it 
appears that all existing implementations have made the correction.  
Also, we would prefer to keep RFC4753 and RFC5114 distinct since we'd 
like to keep a separate document as a Suite B reference.  If the 
inclusion of the three ECP groups in two different standards is causing 
confusion, it might be worth thinking about removing them from the 
upcoming RFC5114 update.

-- Jerome A. Solinas, RFC4753 coauthor



From svanru@gmail.com  Fri Jan 22 10:55:29 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1046A3A6A31 for ; Fri, 22 Jan 2010 10:55:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.109
X-Spam-Level: 
X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97Ljvzlk42BX for ; Fri, 22 Jan 2010 10:55:28 -0800 (PST)
Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by core3.amsl.com (Postfix) with ESMTP id 11C143A6936 for ; Fri, 22 Jan 2010 10:55:27 -0800 (PST)
Received: by fg-out-1718.google.com with SMTP id 19so42967fgg.13 for ; Fri, 22 Jan 2010 10:55:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:cc :references:subject:date:mime-version:content-type :content-transfer-encoding:x-priority:x-msmail-priority:x-mailer :x-mimeole; bh=z/Qy6uELx68U3c74gLwYJgpfpaoG6QelOAUcRpsXs0Q=; b=OrgJZ3dhpESoCV9WrA98ozYUE2+Qbx5ixymqGIxQqZaxBgCmnUkiuftyv5CCHi7K4h jvJbmXKOMBiu/2sJNbjvRMkV+JHtpfyM8E1nhnTupMD184a2ofCH/2BVG9krtOKZPwUk YycziPRmlPdR7rqx4/CB9rEV1gyEyZYyKndsI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=bBTsukLuN6+f2rptIsp1de8RJsyDpPas19x8vVG8fheVSuleTlPQeC6L1d9o9sY/XO 0G31y9Uh4JG4yd/Oe7J5oeSJueeQNvg12fRCItq209CRteirskOnoVymNPZ0byqlY1BD 0ESA9uWY3Nf2Bmj6HsH5dc7cMvH/XsgRFu4Po=
Received: by 10.102.14.10 with SMTP id 10mr1758924mun.84.1264186520537; Fri, 22 Jan 2010 10:55:20 -0800 (PST)
Received: from chichi (ppp85-140-186-128.pppoe.mtu-net.ru [85.140.186.128]) by mx.google.com with ESMTPS id j6sm10106739mue.5.2010.01.22.10.55.18 (version=SSLv3 cipher=RC4-MD5); Fri, 22 Jan 2010 10:55:19 -0800 (PST)
Message-ID: <2534E62AE10A4D048624AA888E40693B@chichi>
From: "Valery Smyslov" 
To: "Yaron Sheffer" , "Tero Kivinen" 
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21EF8@il-ex01.ad.checkpoint.com><19286.62825.898863.477577@fireball.kivinen.iki.fi><7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21FEA@il-ex01.ad.checkpoint.com><19287.12109.881311.935809@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A221E8@il-ex01.ad.checkpoint.com>
Date: Fri, 22 Jan 2010 21:55:14 +0300
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5843
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Cc: ipsec@ietf.org
Subject: Re: [IPsec] IKEv2-bis, comments up to 2.16
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 18:55:29 -0000

Hi Yaron,

> Hi Tero,
>
> I was ready to accept your answer, until I came across the following 
> sentence in -07.
>
> "Payloads are processed in the order in which they appear in an IKE 
> message by invoking the appropriate processing routine according to the 
> "Next Payload" field in the IKE header and subsequently according to the 
> "Next Payload" field in the IKE payload itself until a "Next Payload" 
> field of zero indicates that no payloads follow."
>
> This seems to say exactly what I was proposing! Did I miss another 
> statement in the document where we say the opposite (that payload order 
> doesn't matter)?

The text you cited doesn't impose any requirements in terms of RFC2119.
It's just a general rule which is to be followed in most cases. But it 
doesn't
mean that there must be no exceptions to this rule.

I think, Tero is absolutely right here -  requiring payloads to be processed
in the same order as they appear in the message will make implementations
more complex. Moreover, VendorID payloads MUST be processed prior
to any other, otherwise we lose an ability to use any private values in the 
same
message (and, as a result - no private values in IKE_SA_INIT at all,
as there are no prior messages).

Regards,
Valery Smyslov.



From yaronf@checkpoint.com  Fri Jan 22 11:02:33 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8902D3A6AA8 for ; Fri, 22 Jan 2010 11:02:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSBHdX+q43Au for ; Fri, 22 Jan 2010 11:02:30 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 1C11A3A6936 for ; Fri, 22 Jan 2010 11:02:29 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0MJ2NT7022139; Fri, 22 Jan 2010 21:02:23 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 22 Jan 2010 21:02:37 +0200
From: Yaron Sheffer 
To: Valery Smyslov , Tero Kivinen 
Date: Fri, 22 Jan 2010 21:02:35 +0200
Thread-Topic: [IPsec] IKEv2-bis, comments up to 2.16
Thread-Index: AcqblH6xYaGuP+8sSM66iSTuCDUJtQAAICmA
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A221EA@il-ex01.ad.checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21EF8@il-ex01.ad.checkpoint.com><19286.62825.898863.477577@fireball.kivinen.iki.fi><7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21FEA@il-ex01.ad.checkpoint.com><19287.12109.881311.935809@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A221E8@il-ex01.ad.checkpoint.com> <2534E62AE10A4D048624AA888E40693B@chichi>
In-Reply-To: <2534E62AE10A4D048624AA888E40693B@chichi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ipsec@ietf.org" 
Subject: Re: [IPsec] IKEv2-bis, comments up to 2.16
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 19:02:33 -0000

Hi Valery,

I would like to hear other people's opinion on this issue. At the very leas=
t, the text I'm citing should be clarified.

BTW, Vendor ID payloads can appear anywhere in the message (per Appendix C)=
, so you can just put them first and you're fine.

Thanks,
	Yaron

> -----Original Message-----
> From: Valery Smyslov [mailto:svanru@gmail.com]
> Sent: Friday, January 22, 2010 20:55
> To: Yaron Sheffer; Tero Kivinen
> Cc: ipsec@ietf.org
> Subject: Re: [IPsec] IKEv2-bis, comments up to 2.16
>=20
> Hi Yaron,
>=20
> > Hi Tero,
> >
> > I was ready to accept your answer, until I came across the following
> > sentence in -07.
> >
> > "Payloads are processed in the order in which they appear in an IKE
> > message by invoking the appropriate processing routine according to
> the
> > "Next Payload" field in the IKE header and subsequently according to
> the
> > "Next Payload" field in the IKE payload itself until a "Next Payload"
> > field of zero indicates that no payloads follow."
> >
> > This seems to say exactly what I was proposing! Did I miss another
> > statement in the document where we say the opposite (that payload
> order
> > doesn't matter)?
>=20
> The text you cited doesn't impose any requirements in terms of RFC2119.
> It's just a general rule which is to be followed in most cases. But it
> doesn't
> mean that there must be no exceptions to this rule.
>=20
> I think, Tero is absolutely right here -  requiring payloads to be
> processed
> in the same order as they appear in the message will make
> implementations
> more complex. Moreover, VendorID payloads MUST be processed prior
> to any other, otherwise we lose an ability to use any private values in
> the
> same
> message (and, as a result - no private values in IKE_SA_INIT at all,
> as there are no prior messages).
>=20
> Regards,
> Valery Smyslov.
>=20
>=20
>=20
> Scanned by Check Point Total Security Gateway.

From yaronf@checkpoint.com  Fri Jan 22 13:57:55 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A0D63A6765 for ; Fri, 22 Jan 2010 13:57:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWTxymV9pCLp for ; Fri, 22 Jan 2010 13:57:54 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 72D2B3A63EB for ; Fri, 22 Jan 2010 13:57:54 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0MLvnT7008214 for ; Fri, 22 Jan 2010 23:57:49 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 22 Jan 2010 23:58:03 +0200
From: Yaron Sheffer 
To: "ipsec@ietf.org" 
Date: Fri, 22 Jan 2010 23:57:56 +0200
Thread-Topic: Issue #157: Illustrate the SA payload with a diagram
Thread-Index: AcqbrTU+sipMAesJQlezt+Uk0f9UeAAABI7w
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A221F3@il-ex01.ad.checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-cr-puzzleid: {C4A8CB1B-5931-4A86-9113-C2D9C72DA1D3}
x-cr-hashedpuzzle: zAw= ATjm Amfp A062 BBwd BPUv BmL4 DUfU EGwk EYNd EipU EsTS F1J/ G5jL HAJY JW1D; 1; aQBwAHMAZQBjAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {C4A8CB1B-5931-4A86-9113-C2D9C72DA1D3}; eQBhAHIAbwBuAGYAQABjAGgAZQBjAGsAcABvAGkAbgB0AC4AYwBvAG0A; Fri, 22 Jan 2010 21:57:56 GMT; SQBzAHMAdQBlACAAIwAxADUANwA6ACAASQBsAGwAdQBzAHQAcgBhAHQAZQAgAHQAaABlACAAUwBBACAAcABhAHkAbABvAGEAZAAgAHcAaQB0AGgAIABhACAAZABpAGEAZwByAGEAbQA=
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: [IPsec] Issue #157: Illustrate the SA payload with a diagram
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 21:57:55 -0000

VGhlIHRleHQgaW4gMy4zIHJlcXVpcmVzICJwZWFjZSBvZiBtaW5kIiB0byBmdWxseSBhcHByZWNp
YXRlLiBBIGRpYWdyYW0gbWlnaHQgYmUgaGVscGZ1bC4NCg0KSGVyZSdzIGEgZmlyc3Qgc2hvdCAo
d2UnbGwgbmVlZCB0byBhZGQgc29tZSBkZXNjcmlwdGl2ZSB0ZXh0KToNCg0KICAgICAgICAgICAg
ICAgICAgICAgICAgU0EgUGF5bG9hZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAg
ICAgICAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLS0uLi4uLi4uLi4uLi4tDQogICAgICAg
ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgfA0KICAgICAgICAgICAg
ICAgUHJvcG9zYWwgIzEgICAgICAgUHJvcG9zYWwgIzIgICBQcm9wb3NhbCAjbg0KICAgICAgICAg
ICAgICAgICAgICAgRVNQICAgICAgICAgICBFU1ANCiAgICAgICAgICAgICAgICAgICAgIFNQSXgg
ICAgICAgICAgU1BJeQ0KICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfA0KICAg
ICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0gICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAg
ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICB8DQog
ICAgICBUcmFuc2Zvcm0gQSAgICAgICAgVHJhbmZvcm0gQiAgICBUcmFuc2Zvcm0gQyBUcmFuc2Zv
cm0gRA0KICAgICAgICAgIEVOQ1IgICAgICAgICAgICAgICBBVVRIICAgICAgICAgIEVOQ1IgICAg
ICAgRVNODQogICAgICAgICAgQUVTICAgICAgICAgICAgSE1BQy1TSEEtMjU2ICAgIEFFUy1DQ00g
ICAgIEVTTj0xDQogICAgICAgICAgIHwNCiAgIC0tLS0tLS0tLS0tLS0tLS0tDQogICB8ICAgICAg
IHwgICAgICAgfA0KQXR0ciBBeCBBdHRyIEF5IEF0dHIgQXoNCiAgMTI4ICAgICAxOTIgICAgIDI1
Ng0KDQoNCi0tIA0KVGlja2V0IFVSTDogPGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2lw
c2VjbWUvdHJhYy90aWNrZXQvMTU3I2NvbW1lbnQ6MT4NCmlwc2VjbWUgPGh0dHA6Ly90b29scy5p
ZXRmLm9yZy9pcHNlY21lLz4NCg==

From paul.hoffman@vpnc.org  Fri Jan 22 17:28:08 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A54243A68EE for ; Fri, 22 Jan 2010 17:28:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.023
X-Spam-Level: 
X-Spam-Status: No, score=-6.023 tagged_above=-999 required=5 tests=[AWL=0.023,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zshmN821GjD8 for ; Fri, 22 Jan 2010 17:28:07 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id CD2733A67FD for ; Fri, 22 Jan 2010 17:28:07 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0N1Rqhv088184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jan 2010 18:27:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A221F3@il-ex01.ad.checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A221F3@il-ex01.ad.checkpoint.com>
Date: Fri, 22 Jan 2010 17:27:51 -0800
To: Yaron Sheffer , "ipsec@ietf.org" 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [IPsec] Issue #157: Illustrate the SA payload with a diagram
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Jan 2010 01:28:08 -0000

At 11:57 PM +0200 1/22/10, Yaron Sheffer wrote:
>The text in 3.3 requires "peace of mind" to fully appreciate. A diagram might be helpful.
>
>Here's a first shot (we'll need to add some descriptive text):
>
>                        SA Payload
>                            |
>                      ---------------............-
>                      |             |            |
>               Proposal #1       Proposal #2   Proposal #n
>                     ESP           ESP
>                     SPIx          SPIy
>                      |             |
>           ---------------------    --------------------
>           |                   |             |         |
>      Transform A        Tranform B    Transform C Transform D
>          ENCR               AUTH          ENCR       ESN
>          AES            HMAC-SHA-256    AES-CCM     ESN=1
>           |
>   -----------------
>   |       |       |
>Attr Ax Attr Ay Attr Az
>  128     192     256

In order for this not to be confusing, Transform A should be "ENCR" and "AES-CBC", and Transform C needs to (in fact, MUST) have at least one attribute specified.

Transform B should be listed as "INTEG", not "AUTH".

Further, is there a good reason for you to have not included an ESN transform on Proposal #1? Section 3.3 says "The number of different transforms is generally determined by the Protocol. ... ESP generally has three: ESN, an encryption algorithm and an integrity check algorithm."

Ditto for Proposal #2: is there a good reason for you to not have included an INTEG transform?

This begs the related question: given that there is no MUST or should for what goes into a Proposal, what does an ESP proposal that only has an ENCR and INTEG in it mean with respect to what is being proposed for ESN? What does an ESP proposal that has only an ENCR and ESN in it mean with respect to what is being proposed for INTEG? I see no MUSTs or SHOULDs answering this.

--Paul Hoffman, Director
--VPN Consortium

From dharkins@lounge.org  Sat Jan 23 00:13:17 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C75EA3A67B3 for ; Sat, 23 Jan 2010 00:13:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.265
X-Spam-Level: 
X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPG3Bbx-lXNv for ; Sat, 23 Jan 2010 00:13:15 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 237203A659C for ; Sat, 23 Jan 2010 00:13:15 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 8CFA01022404A; Sat, 23 Jan 2010 00:13:10 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sat, 23 Jan 2010 00:13:10 -0800 (PST)
Message-ID: <48e61fa1cc7322f35f4ddf99d4faedb0.squirrel@www.trepanning.net>
In-Reply-To: <4B59F2F1.9030107@orion.ncsc.mil>
References: <19243.32427.247190.77844@fireball.kivinen.iki.fi>  <4B59F2F1.9030107@orion.ncsc.mil>
Date: Sat, 23 Jan 2010 00:13:10 -0800 (PST)
From: "Dan Harkins" 
To: "Jerome A. Solinas" 
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: ipsec@ietf.org
Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-01)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Jan 2010 08:13:18 -0000

  I agree with Jerome's opinion. Let's leave 19, 20, and 21 the way
they are. If there is confusion between the 2 RFCs than let's fix it
in a -bis favoring the former of the two.

  Dan.

On Fri, January 22, 2010 10:48 am, Jerome A. Solinas wrote:
> Paul Hoffman wrote:
>> First off, thank you for bringing the topic to the WG. As the Designated
>> Expert, you are certainly allowed to make decisions without asking, so
>> it is extra nice that you ask on decisions that might be controversial.
>>
>> On this particular topic, I would note that RFC 4753 is Informational
>> RFC, not a standards-track document. Thus, I would think that desires of
>> the authors of the RFC should have a heavier influence than the rest of
>> us, although our input might be important inputs to them (and maybe to
>> the Designated Expert). Maybe we should put the issue aside until we
>> hear from them, which could be after the holiday.
>>
>> --Paul Hoffman, Director
>>
> We would recommend keeping the same numbers (19, 20, 21) since it
> appears that all existing implementations have made the correction.
> Also, we would prefer to keep RFC4753 and RFC5114 distinct since we'd
> like to keep a separate document as a Suite B reference.  If the
> inclusion of the three ECP groups in two different standards is causing
> confusion, it might be worth thinking about removing them from the
> upcoming RFC5114 update.
>
> -- Jerome A. Solinas, RFC4753 coauthor
>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>



From yaronf@checkpoint.com  Sat Jan 23 10:06:40 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D7C63A6807 for ; Sat, 23 Jan 2010 10:06:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxpiXu3o+hCr for ; Sat, 23 Jan 2010 10:06:39 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id CA7663A6818 for ; Sat, 23 Jan 2010 10:06:38 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0NI6XT7012844; Sat, 23 Jan 2010 20:06:33 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sat, 23 Jan 2010 20:06:47 +0200
From: Yaron Sheffer 
To: Paul Hoffman , "ipsec@ietf.org" 
Date: Sat, 23 Jan 2010 20:06:45 +0200
Thread-Topic: [IPsec] Issue #157: Illustrate the SA payload with a diagram
Thread-Index: Acqby1fHO671fQS/RRKggZ7d4wsOLAAixhIg
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A22201@il-ex01.ad.checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A221F3@il-ex01.ad.checkpoint.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [IPsec] Issue #157: Illustrate the SA payload with a diagram
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Jan 2010 18:06:40 -0000

Hi Paul,

Please see below.

> -----Original Message-----
> From: Paul Hoffman [mailto:paul.hoffman@vpnc.org]
> Sent: Saturday, January 23, 2010 3:28
> To: Yaron Sheffer; ipsec@ietf.org
> Subject: Re: [IPsec] Issue #157: Illustrate the SA payload with a
> diagram
>=20
> At 11:57 PM +0200 1/22/10, Yaron Sheffer wrote:
> >The text in 3.3 requires "peace of mind" to fully appreciate. A
> diagram might be helpful.
> >
> >Here's a first shot (we'll need to add some descriptive text):
> >
> >                        SA Payload
> >                            |
> >                      ---------------............-
> >                      |             |            |
> >               Proposal #1       Proposal #2   Proposal #n
> >                     ESP           ESP
> >                     SPIx          SPIy
> >                      |             |
> >           ---------------------    --------------------
> >           |                   |             |         |
> >      Transform A        Tranform B    Transform C Transform D
> >          ENCR               AUTH          ENCR       ESN
> >          AES            HMAC-SHA-256    AES-CCM     ESN=3D1
> >           |
> >   -----------------
> >   |       |       |
> >Attr Ax Attr Ay Attr Az
> >  128     192     256
>=20
> In order for this not to be confusing, Transform A should be "ENCR" and
> "AES-CBC", and Transform C needs to (in fact, MUST) have at least one
> attribute specified.
Agree.
>=20
> Transform B should be listed as "INTEG", not "AUTH".
Yes.
>=20
> Further, is there a good reason for you to have not included an ESN
> transform on Proposal #1? Section 3.3 says "The number of different
> transforms is generally determined by the Protocol. ... ESP generally
> has three: ESN, an encryption algorithm and an integrity check
> algorithm."
According to 3.3.3, ESN is mandatory for ESP and AH. So I should have inclu=
ded it.
>=20
> Ditto for Proposal #2: is there a good reason for you to not have
> included an INTEG transform?
I was trying to illustrate a combined mode algorithm. May have got it wrong=
...
>=20
> This begs the related question: given that there is no MUST or should
> for what goes into a Proposal, what does an ESP proposal that only has
> an ENCR and INTEG in it mean with respect to what is being proposed for
> ESN? What does an ESP proposal that has only an ENCR and ESN in it mean
> with respect to what is being proposed for INTEG? I see no MUSTs or
> SHOULDs answering this.
3.3.3 says ESN is mandatory. Which means if it is omitted, the recipient wi=
ll reject the proposal.
>=20
> --Paul Hoffman, Director
> --VPN Consortium
>=20
> Scanned by Check Point Total Security Gateway.

From paul.hoffman@vpnc.org  Sat Jan 23 11:29:53 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 213AD3A69E0 for ; Sat, 23 Jan 2010 11:29:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.023
X-Spam-Level: 
X-Spam-Status: No, score=-6.023 tagged_above=-999 required=5 tests=[AWL=0.023,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COyPry2VbX2D for ; Sat, 23 Jan 2010 11:29:52 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 451EF3A69D2 for ; Sat, 23 Jan 2010 11:29:52 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0NJJ7XK043716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Jan 2010 12:19:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A22201@il-ex01.ad.checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A221F3@il-ex01.ad.checkpoint.com>  <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A22201@il-ex01.ad.checkpoint.com>
Date: Sat, 23 Jan 2010 11:18:54 -0800
To: Yaron Sheffer , "ipsec@ietf.org" 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [IPsec] Issue #157: Illustrate the SA payload with a diagram
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Jan 2010 19:29:53 -0000

At 8:06 PM +0200 1/23/10, Yaron Sheffer wrote:
> > Further, is there a good reason for you to have not included an ESN
>> transform on Proposal #1? Section 3.3 says "The number of different
>> transforms is generally determined by the Protocol. ... ESP generally
>> has three: ESN, an encryption algorithm and an integrity check
>> algorithm."
>According to 3.3.3, ESN is mandatory for ESP and AH. So I should have included it.

Good.

> > Ditto for Proposal #2: is there a good reason for you to not have
>> included an INTEG transform?
>I was trying to illustrate a combined mode algorithm. May have got it wrong...

That would be INTEG = NULL.

> > This begs the related question: given that there is no MUST or should
>> for what goes into a Proposal, what does an ESP proposal that only has
>> an ENCR and INTEG in it mean with respect to what is being proposed for
>> ESN? What does an ESP proposal that has only an ENCR and ESN in it mean
>> with respect to what is being proposed for INTEG? I see no MUSTs or
>> SHOULDs answering this.
>3.3.3 says ESN is mandatory. Which means if it is omitted, the recipient will reject the proposal.

As I said, I don't see any MUST or SHOULD for that. It would be better if this was stated. A possible addition to 3.3.3 would be "A proposal that does not contain all of the mandatory transforms is malformed and MUST be rejected".

--Paul Hoffman, Director
--VPN Consortium

From yaronf@checkpoint.com  Sun Jan 24 13:05:57 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52B823A6837 for ; Sun, 24 Jan 2010 13:05:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level: 
X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-XgXA+NZzgR for ; Sun, 24 Jan 2010 13:05:55 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 08FF43A6801 for ; Sun, 24 Jan 2010 13:05:52 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0OL5tT7028741 for ; Sun, 24 Jan 2010 23:05:55 +0200 (IST)
X-CheckPoint: {4B5CB645-0-1B201DC2-5FFFF}
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 24 Jan 2010 23:06:09 +0200
From: Yaron Sheffer 
To: IPsecme WG 
Date: Sun, 24 Jan 2010 23:06:05 +0200
Thread-Topic: IKEv2-bis comments: 2.17 and onwards
Thread-Index: AcqdOQrfhaENfzWuSoeWLUvpZxYqEA==
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A804C9@il-ex01.ad.checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A804C9ilex01adche_"
MIME-Version: 1.0
Subject: [IPsec] IKEv2-bis comments: 2.17 and onwards
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Jan 2010 21:05:57 -0000

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A804C9ilex01adche_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

1.7: This also lead to -> This also led to

2.21.: EAP Failure cases are missing altogether. Also, the first paragraph =
says that if an auth failure occurs at the responder, AUTHENTICATION_FAILED=
 is included in the protected response (to IKE_AUTH), while the last paragr=
aph says it's a separate Informational exchange.

1.3.2 and 2.18 (IKE SA rekey) have lots of overlap. If we don't consolidate=
 them, we should at least have them reference one another.

2.19: grammar: "it simply causes the Child SA creation *to* fail".

2.21.2: grammar: "in case an error happened *in* when processing"

2.23: what do we mean by this - "In addition, firewalls may be configured t=
o pass IPsec traffic over UDP but not ESP/AH or vice versa"? This would be =
less confusing: "In addition, firewalls may be configured to pass UDP-encap=
sulated IPsec traffic but not plain, unencapsulated ESP/AH or vice versa".

2.23: "The recipient of either the NAT_DETECTION_SOURCE_IP or NAT_DETECTION=
_DESTINATION_IP notification MAY compare the supplied value to a SHA-1 hash=
 of the SPIs, source IP address, and port, and if they don't match it SHOUL=
D enable NAT traversal. In the case there is a mismatch of the NAT_DETECTIO=
N_SOURCE_IP hash with all of the NAT_DETECTION_SOURCE_IP payloads received,=
 the recipient MAY reject the connection attempt if NAT traversal is not su=
pported." In the first sentence, the comparison is not just with the source=
 address/port. Also, while NAT-T is a MAY, once you decide that you impleme=
nt NAT-T, this comparison becomes at least a SHOULD. "If they don't match i=
t SHOULD enable NAT-T" contradicts an earlier MUST: "if a NAT is detected, =
both devices MUST send UDP encapsulated packets". And the second sentence d=
oesn't make sense as pointed out before - if you recognize these payloads, =
then obviously you support NAT-T. Overall, the normative part of this secti=
on needs to be reworked.

2.23: replace the second-last bullet with a pointer to the subsequent subse=
ction, on Transport Mode and NAT.

2.23: the last bullet (automatically updating the peer's IP address) is too=
 important to be only mentioned as a side note. We should at least mention =
it in Sec. 2.6, following the sentence: "Incoming IKE packets are mapped to=
 an IKE SA only using the packet's SPI, not using (for example) the source =
IP address of the packet."

2.24: what's this section (ECN) doing here? It is 100% IPsec, nothing to do=
 with IKE. If there's a reason, let's explain it in the text.

3.1: "The Recipient SPI in the header identifies an instance of an IKE secu=
rity association. It is therefore possible for a single instance of IKE to =
multiplex distinct sessions with multiple peers." In fact it's more than th=
at, you can have multiple sessions with one peer! So I would rephrase: "The=
 Recipient SPI in the header identifies an instance of an IKE security asso=
ciation. It is therefore possible for a single instance of IKE to multiplex=
 distinct sessions with multiple peers, including multiple sessions per pee=
r."

3.2: grammar: "by appending it" -> "by appending them" (or "each one").

3.2, "Next Payload": we say that the Encrypted payload gets a different Nex=
t Payload value. But then, we should also say (here or where describing the=
 Encrypted payload) that the last *contained* payload gets a zero Next Payl=
oad value.

3.3.2: Tiger - we closed issue #33, but according to the text of the issue,=
 should have left the algorithm "unspecified". Which I think would be much =
more accurate.

3.3.5: "Attributes described as fixed length MUST NOT be encoded using the =
variable-length encoding." This cannot be correct, a new 4-octet attribute =
will have to be encoded as variable-length. It won't fit into the other for=
mat.

3.3.6: "The initiator of an exchange MUST check that the accepted offer is =
consistent with one of its proposals, and if not that response MUST be reje=
cted." We are not specifying how to reject such erroneous responses, so why=
 not say: "The initiator of an exchange MUST check that the accepted offer =
is consistent with one of its proposals, and if not MUST terminate the exch=
ange".

3.3.6: we somehow never say what you do when you receive a Transform ID (i.=
e. protocol) that you don't understand. This can be added to 3.3.6. E.g., c=
hange "Similarly, if the responder receives a transform that contains a Tra=
nsform Attribute it does not understand..." to "Similarly, if the responder=
 receives a transform that it does not understand, or one that contains a T=
ransform Attribute it does not understand...".

3.5: "IPv6-only implementations MAY be configurable to send only ID_IPV6_AD=
DR." We probably don't mean it, but rather: "IPv6-only implementations MAY =
be configurable to send only ID_IPV6_ADDR, rather than ID_IPV4_ADDR, in add=
ition to the other three types."

3.6: "DNS Signed Key" is marked Unspecified. Is it not RFC 4025? It's not u=
sed anywhere, but still...

3.6: [Hash and URL] "makes IKE less subject to denial of service attacks th=
at become easier to mount when IKE messages are large enough to require IP =
fragmentation." This statement is hard to take seriously. When the certific=
ate is NOT cached, this encoding eliminates a difficult-to-perform DOS atta=
ck, replacing it with a much easier one: stop the endpoint from obtaining t=
he cert.

3.6: clarification, replace "Use the following ASN.1 definition for an X.50=
9 bundle" by "The "Hash and URL of a bundle" type uses the following ASN.1 =
definition of an X.509 bundle:"

3.7: "If multiple CAs are trusted and the certificate encoding does not all=
ow a list, then multiple Certificate Request payloads would need to be tran=
smitted." This doesn't make sense: we are not sending the cert itself here.=
 we're just sending an encoding on a CA. Moreover, the text further down in=
dicates that the CA field is *always* a list - at least for the defined cer=
t types (4, 12, 13). Overall, this looks like a placeholder, and I suggest =
to delete the sentence.

3.9: "The size of a Nonce" -> "The size of the Nonce Data".

3.10.1: "in any case where the offered proposal" -> "... proposals".

3.10.1: INVALID_SELECTORS is underspecified. It should be rate limited (I s=
uppose), also, how long is the packet fragment included in the notification=
? In addition, Sec. 2.21.2 implies that it is sent during Child SA negotiat=
ion, which is not what 3.10.1 is saying.

3.14: "denoted SK{...} or E in this document" -> "denoted SK{...} in this d=
ocument."

3.15: "type length values" -> "Type Length Value (TLV) structures".

3.15.1: "With IPv6, a requestor MAY supply the low-order address octets it =
wants to use." This means to me that you *don't* provide all 16 octets. But=
 according to the table, the field is a fixed-length 16 octets!

3.15.2: "is in CFG_REQUESTs is unclear" - delete the first "is".

3.16: the text here, "...this field MAY be set to any value" implies that t=
he Identifier field can be constant, e.g. always zero. But this would contr=
adict RFC 3748, that says:

In order to avoid confusion between new Requests and retransmissions, the I=
dentifier value chosen for each new Request need only be different from the=
 previous Request, but need not be unique within the conversation.  One way=
 to achieve this is to start the Identifier at an initial value and increme=
nt it for each new Request.  Initializing the first Identifier with a rando=
m number rather than starting from zero is recommended, since it makes sequ=
ence attacks somewhat more difficult.

4: what do we mean by "Ability to support various types of legacy authentic=
ation"? If we mean, "Ability to support EAP-based authentication", let's sa=
y so.

5: what do we mean by "leaves all SAs vulnerable to ... overrun of either e=
ndpoint"?

5: unfortunately we have to revise the text about group strengths - or remo=
ve it altogether. It is non-normative, so it's probably best to eliminate i=
t.

6: the are not -> they are not.

B.1 (Group 1): We may want to add: "Use of this group is NOT RECOMMENDED."

C: I suggest to repeat at the top of this appendix this text from 2.5: "Alt=
hough new payload types may be added in the future and may appear interleav=
ed with the fields defined in this specification, implementations SHOULD se=
nd the payloads defined in this specification in the order shown in the fig=
ures in Sections 1 and 2; implementations MUST NOT reject as invalid a mess=
age with those payloads in any other order."

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A804C9ilex01adche_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















1.7: This also lead to -> This also led to



 



2.21.: EAP Failure cases are missing altogether. Also,=
 the
first paragraph says that if an auth failure occurs at the responder,
AUTHENTICATION_FAILED is included in the protected response (to IKE_AUTH),
while the last paragraph says it's a separate Informational exchange.<=
/o:p>



 



1.3.2 and 2.18 (IKE SA rekey) have lots of overlap. If=
 we
don't consolidate them, we should at least have them reference one another.=




 



2.19: grammar: "it simply causes the Child SA cre=
ation
*to* fail".



 



2.21.2: grammar: "in case an error happened *in* =
when
processing"



 



2.23: what do we mean by this - "In addition, fir=
ewalls
may be configured to pass IPsec traffic over UDP but not ESP/AH or vice
versa"? This would be less confusing: "In addition, firewalls may=
 be
configured to pass UDP-encapsulated IPsec traffic but not plain, unencapsul=
ated
ESP/AH or vice versa".



 



2.23: "The recipient of either the
NAT_DETECTION_SOURCE_IP or NAT_DETECTION_DESTINATION_IP notification MAY
compare the supplied value to a SHA-1 hash of the SPIs, source IP address, =
and
port, and if they don't match it SHOULD enable NAT traversal. In the case t=
here
is a mismatch of the NAT_DETECTION_SOURCE_IP hash with all of the
NAT_DETECTION_SOURCE_IP payloads received, the recipient MAY reject the
connection attempt if NAT traversal is not supported." In the first
sentence, the comparison is not just with the source address/port. Also, wh=
ile
NAT-T is a MAY, once you decide that you implement NAT-T, this comparison
becomes at least a SHOULD. "If they don't match it SHOULD enable
NAT-T" contradicts an earlier MUST: "if a NAT is detected, both
devices MUST send UDP encapsulated packets". And the second sentence
doesn't make sense as pointed out before - if you recognize these payloads,
then obviously you support NAT-T. Overall, the normative part of this secti=
on
needs to be reworked.



 



2.23: replace the second-last bullet with a pointer to=
 the
subsequent subsection, on Transport Mode and NAT.



 



2.23: the last bullet (automatically updating the peer=
's IP
address) is too important to be only mentioned as a side note. We should at
least mention it in Sec. 2.6, following the sentence: "Incoming IKE
packets are mapped to an IKE SA only using the packet's SPI, not using (for
example) the source IP address of the packet."



 



2.24: what's this section (ECN) doing here? It is 100%
IPsec, nothing to do with IKE. If there's a reason, let's explain it in the
text.



 



3.1: "The Recipient SPI in the header identifies =
an
instance of an IKE security association. It is therefore possible for a sin=
gle
instance of IKE to multiplex distinct sessions with multiple peers." I=
n
fact it's more than that, you can have multiple sessions with one peer! So =
I
would rephrase: "The Recipient SPI in the header identifies an instanc=
e of
an IKE security association. It is therefore possible for a single instance=
 of
IKE to multiplex distinct sessions with multiple peers, including multiple
sessions per peer."



 



3.2: grammar: "by appending it" -> "=
by
appending them" (or "each one").



 



3.2, "Next Payload": we say that the Encrypt=
ed
payload gets a different Next Payload value. But then, we should also say (=
here
or where describing the Encrypted payload) that the last *contained* payloa=
d
gets a zero Next Payload value.



 



3.3.2: Tiger - we closed issue #33, but according to t=
he
text of the issue, should have left the algorithm "unspecified".
Which I think would be much more accurate.



 



3.3.5: "Attributes described as fixed length MUST=
 NOT
be encoded using the variable-length encoding." This cannot be correct=
, a
new 4-octet attribute will have to be encoded as variable-length. It won't =
fit
into the other format.



 



3.3.6: "The initiator of an exchange MUST check t=
hat
the accepted offer is consistent with one of its proposals, and if not that
response MUST be rejected." We are not specifying how to reject such
erroneous responses, so why not say: "The initiator of an exchange MUS=
T
check that the accepted offer is consistent with one of its proposals, and =
if
not MUST terminate the exchange".



 



3.3.6: we somehow never say what you do when you recei=
ve a
Transform ID (i.e. protocol) that you don't understand. This can be added t=
o
3.3.6. E.g., change "Similarly, if the responder receives a transform =
that
contains a Transform Attribute it does not understand..." to
"Similarly, if the responder receives a transform that it does not
understand, or one that contains a Transform Attribute it does not
understand...".



 



3.5: "IPv6-only implementations MAY be configurab=
le to
send only ID_IPV6_ADDR." We probably don't mean it, but rather:
"IPv6-only implementations MAY be configurable to send only ID_IPV6_AD=
DR,
rather than ID_IPV4_ADDR, in addition to the other three types."<=
/o:p>



 



3.6: "DNS Signed Key" is marked Unspecified.=
 Is it
not RFC 4025? It's not used anywhere, but still...



 



3.6: [Hash and URL] "makes IKE less subject to de=
nial
of service attacks that become easier to mount when IKE messages are large
enough to require IP fragmentation." This statement is hard to take
seriously. When the certificate is NOT cached, this encoding eliminates a
difficult-to-perform DOS attack, replacing it with a much easier one: stop =
the
endpoint from obtaining the cert.



 



3.6: clarification, replace "Use the following AS=
N.1
definition for an X.509 bundle" by "The "Hash and URL of a
bundle" type uses the following ASN.1 definition of an X.509 bundle:&q=
uot;



 



3.7: "If multiple CAs are trusted and the certifi=
cate
encoding does not allow a list, then multiple Certificate Request payloads
would need to be transmitted." This doesn't make sense: we are not sen=
ding
the cert itself here. we're just sending an encoding on a CA. Moreover, the
text further down indicates that the CA field is *always* a list - at least=
 for
the defined cert types (4, 12, 13). Overall, this looks like a placeholder,=
 and
I suggest to delete the sentence.



 



3.9: "The size of a Nonce" -> "The s=
ize of
the Nonce Data".



 



3.10.1: "in any case where the offered proposal&q=
uot;
-> "... proposals".



 



3.10.1: INVALID_SELECTORS is underspecified. It should=
 be
rate limited (I suppose), also, how long is the packet fragment included in=
 the
notification? In addition, Sec. 2.21.2 implies that it is sent during Child=
 SA negotiation,
which is not what 3.10.1 is saying.



 



3.14: "denoted SK{...} or E in this document"=
;
-> "denoted SK{...} in this document."



 



3.15: "type length values" -> "Type =
Length
Value (TLV) structures".



 



3.15.1: "With IPv6, a requestor MAY supply the
low-order address octets it wants to use." This means to me that you
*don't* provide all 16 octets. But according to the table, the field is a
fixed-length 16 octets!



 



3.15.2: "is in CFG_REQUESTs is unclear" - de=
lete
the first "is".



 



3.16: the text here, "...this field MAY be set to=
 any
value" implies that the Identifier field can be constant, e.g. always
zero. But this would contradict RFC 3748, that says:



 



In order to avoid confusion between new Requests and
retransmissions, the Identifier value chosen for each new Request need only=
 be
different from the previous Request, but need not be unique within the
conversation.  One way to achieve this is to start the Identifier at a=
n
initial value and increment it for each new Request.  Initializing the
first Identifier with a random number rather than starting from zero is
recommended, since it makes sequence attacks somewhat more difficult.<=
/o:p>



 



4: what do we mean by "Ability to support various=
 types
of legacy authentication"? If we mean, "Ability to support EAP-ba=
sed
authentication", let's say so.



 



5: what do we mean by "leaves all SAs vulnerable =
to ...
overrun of either endpoint"?



 



5: unfortunately we have to revise the text about grou=
p
strengths - or remove it altogether. It is non-normative, so it's probably =
best
to eliminate it.



 



6: the are not -> they are not.



 



B.1 (Group 1): We may want to add: "Use of this g=
roup
is NOT RECOMMENDED."



 



C: I suggest to repeat at the top of this appendix thi=
s text
from 2.5: "Although new payload types may be added in the future and m=
ay
appear interleaved with the fields defined in this specification,
implementations SHOULD send the payloads defined in this specification in t=
he
order shown in the figures in Sections 1 and 2; implementations MUST NOT re=
ject
as invalid a message with those payloads in any other order."









--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A804C9ilex01adche_--

From paul.hoffman@vpnc.org  Sun Jan 24 16:46:18 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DC0F3A69A0 for ; Sun, 24 Jan 2010 16:46:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.046
X-Spam-Level: 
X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESG8WoWFJy01 for ; Sun, 24 Jan 2010 16:46:17 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 7DC6E3A68FE for ; Sun, 24 Jan 2010 16:46:17 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0P0kBX6031726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Jan 2010 17:46:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A804C9@il-ex01.ad.checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A804C9@il-ex01.ad.checkpoint.com>
Date: Sun, 24 Jan 2010 16:45:43 -0800
To: Yaron Sheffer , IPsecme WG 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
Subject: Re: [IPsec] IKEv2-bis comments: 2.17 and onwards
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2010 00:46:18 -0000

Thanks again for the careful review. All changes made other than those listed below.

--Paul HOffman

At 11:06 PM +0200 1/24/10, Yaron Sheffer wrote:
>2.21.: EAP Failure cases are missing altogether. Also, the first paragraph says that if an auth failure occurs at the responder, AUTHENTICATION_FAILED is included in the protected response (to IKE_AUTH), while the last paragraph says it's a separate Informational exchange.

Please open a tracker issue for this.

>2.23: "The recipient of either the NAT_DETECTION_SOURCE_IP or NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied value to a SHA-1 hash of the SPIs, source IP address, and port, and if they don't match it SHOULD enable NAT traversal. In the case there is a mismatch of the NAT_DETECTION_SOURCE_IP hash with all of the NAT_DETECTION_SOURCE_IP payloads received, the recipient MAY reject the connection attempt if NAT traversal is not supported." In the first sentence, the comparison is not just with the source address/port. Also, while NAT-T is a MAY, once you decide that you implement NAT-T, this comparison becomes at least a SHOULD. "If they don't match it SHOULD enable NAT-T" contradicts an earlier MUST: "if a NAT is detected, both devices MUST send UDP encapsulated packets". And the second sentence doesn't make sense as pointed out before - if you recognize these payloads, then obviously you support NAT-T. Overall, the normative part of this section needs to b!
 e reworked.

Please open a tracker issue for this.

>2.23: replace the second-last bullet with a pointer to the subsequent subsection, on Transport Mode and NAT.

Added a forward reference instead.

>2.23: the last bullet (automatically updating the peer's IP address) is too important to be only mentioned as a side note. We should at least mention it in Sec. 2.6, following the sentence: "Incoming IKE packets are mapped to an IKE SA only using the packet's SPI, not using (for example) the source IP address of the packet."

Please propose specific wording for that insertion to 2.6.

>2.24: what's this section (ECN) doing here? It is 100% IPsec, nothing to do with IKE. If there's a reason, let's explain it in the text.

Disagree. This section lists new mandatory actions that were not in IKEv1.

>3.2, "Next Payload": we say that the Encrypted payload gets a different Next Payload value. But then, we should also say (here or where describing the Encrypted payload) that the last *contained* payload gets a zero Next Payload value.

This is significant. Please propose changes in a new tracker issue.

>3.3.5: "Attributes described as fixed length MUST NOT be encoded using the variable-length encoding." This cannot be correct, a new 4-octet attribute will have to be encoded as variable-length. It won't fit into the other format.

Please open a tracker issue for this.

>3.6: "DNS Signed Key" is marked Unspecified. Is it not RFC 4025? It's not used anywhere, but still...

RFC 4025 only specifies how to format those keys in the DNS and in display, not in IKE. You can guess that you should use the RDATA format, but that's only a guess.

>3.6: [Hash and URL] "makes IKE less subject to denial of service attacks that become easier to mount when IKE messages are large enough to require IP fragmentation." This statement is hard to take seriously. When the certificate is NOT cached, this encoding eliminates a difficult-to-perform DOS attack, replacing it with a much easier one: stop the endpoint from obtaining the cert.

See the IPsec WG archives. If you really think this subjective rathole is worth opening again, open a tracker issue.

>3.10.1: INVALID_SELECTORS is underspecified. It should be rate limited (I suppose), also, how long is the packet fragment included in the notification? In addition, Sec. 2.21.2 implies that it is sent during Child SA negotiation, which is not what 3.10.1 is saying.

Please open a tracker issue for this.

>3.15.1: "With IPv6, a requestor MAY supply the low-order address octets it wants to use." This means to me that you *don't* provide all 16 octets. But according to the table, the field is a fixed-length 16 octets!

Please open a tracker issue for this.

>3.16: the text here, "...this field MAY be set to any value" implies that the Identifier field can be constant, e.g. always zero. But this would contradict RFC 3748, that says:
> 
>In order to avoid confusion between new Requests and retransmissions, the Identifier value chosen for each new Request need only be different from the previous Request, but need not be unique within the conversation.  One way to achieve this is to start the Identifier at an initial value and increment it for each new Request.  Initializing the first Identifier with a random number rather than starting from zero is recommended, since it makes sequence attacks somewhat more difficult.

Please open a tracker issue for this.

>5: what do we mean by "leaves all SAs vulnerable to ... overrun of either endpoint"?

Please open a tracker issue for this.

>5: unfortunately we have to revise the text about group strengths - or remove it altogether. It is non-normative, so it's probably best to eliminate it.

Why?

>B.1 (Group 1): We may want to add: "Use of this group is NOT RECOMMENDED."

Please open a tracker issue for this. Even though this is obvious, it is a tad late to be suggesting new normative language.

>C: I suggest to repeat at the top of this appendix this text from 2.5: "Although new payload types may be added in the future and may appear interleaved with the fields defined in this specification, implementations SHOULD send the payloads defined in this specification in the order shown in the figures in Sections 1 and 2; implementations MUST NOT reject as invalid a message with those payloads in any other order."

If the appendix is as "purely informative" as it says, then putting normative language in it (even as duplication) is inappropriate.

From ynir@checkpoint.com  Sun Jan 24 22:12:25 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BD853A67AD for ; Sun, 24 Jan 2010 22:12:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XATM8r41aIMJ for ; Sun, 24 Jan 2010 22:12:19 -0800 (PST)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 51B3F3A67F6 for ; Sun, 24 Jan 2010 22:12:17 -0800 (PST)
X-CheckPoint: {4B5D33A9-10000-14201DC2-FFFF}
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 8517829C01C; Mon, 25 Jan 2010 08:12:21 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 62A1229C019 for ; Mon, 25 Jan 2010 08:12:21 +0200 (IST)
X-CheckPoint: {4B5D33A8-10000-14201DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0P6CLT7000012 for ; Mon, 25 Jan 2010 08:12:21 +0200 (IST)
X-CheckPoint: {4B5D3652-0-1B201DC2-5FFFF}
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 25 Jan 2010 08:12:35 +0200
From: Yoav Nir 
To: IPsecme WG 
Date: Mon, 25 Jan 2010 08:12:13 +0200
Thread-Topic: Closing some of the open tickets for IKEv2bis
Thread-Index: AcqdhWMHLR3JsowOR7yFiTBDU2C59A==
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [IPsec] Closing some of the open tickets for IKEv2bis
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2010 06:12:25 -0000

Hi all

We would like to begin closing IKEv2bis issue at a faster rate than we are =
opening new ones. Paul has sent the list a several issues. Some we have dis=
cussed, others - not so much. Here's a summary of three issues, which I thi=
nk are ready for closure.



Issue #138 - Calculations involving Ni/Nr
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Section 2.14: "only the first 64 bits of Ni and the first 64 bits of Nr are=
 used in the calculation". This section has two calculations involving Ni/N=
r, but this sentence should only apply to the former. Suggested rephrasing:=
 "the calculation" -> "when calculating SKEYSEED (but all bits are used whe=
n calculating SK_*)"

There was just one response (from me), and I suggested the following text:
   only the first 64 bits of Ni and the first 64 bits of Nr are used in cal=
culating SKEYSEED, but all the bits are used for input to the prf+ function=
.

If anyone else has comments about this issue, please raise them NOW, becaus=
e we are going to close this in a few days.



Issue #139 - Keying material taken in the order for RoHC
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
One of the differences between RFC 4306 and the IKEv2bis draft is in Sectio=
n 2.17, Generating Key Material for Child SAs. Appendix E.2 of the IKEv2bis=
 draft indicates the following:
In Section 2.17, removed "If multiple IPsec protocols are negotiated, keyin=
g material is taken in the order in which the protocol headers will appear =
in the encapsulated packet" because multiple IPsec protocols cannot be nego=
tiated at one time.
Is it possible to leave the quoted text in the spec? I agree that multiple =
IPsec protocols cannot be negotiated at one time; however, the text is usef=
ul for ROHCoIPsec implementers, where multiple keys may need to be generate=
d for a ROHC-enabled Child SA.
For example, if a ROHC-enabled Child-SA with ROHC_INTEG [draft-ietf-rohc-ik=
ev2-extensions-hcoipsec-09] is instantiated, first the IPsec encryption/aut=
hentication keying material will be taken, then an additional key will be t=
aken for the algorithm used to verify the proper decompression of packet he=
aders.

I said I preferred to leave the text as it is, and let RoHC specify their m=
odifications (which they did). Valery, Tero, and David chimed in, correctly=
 pointing out that if multiple extensions are negotiated (RoHC + GCM + some=
 future extension) it is up to the base document to specify the order betwe=
en them. I'm convinced. Paul also suggested some text (below) for a bullete=
d list of two points. Tero suggested a third (encryption before authenticat=
ion), but Valery pointed out that this is already in 4301.

   If the Child SA negotiation includes some future IPsec protocol(s)
   in addition to (or instead of) ESP or AH (e.g., ROHC_INTEG), then
   (1) all keys for SAs carrying data from the initiator to the
   responder are taken before SAs going in the reverse direction, and
   (2) keying material for the IPsec protocols are taken in the order
   in which the protocol headers will appear in the encapsulated
   packet.

If anyone else has comments about this issue, please raise them NOW, becaus=
e we are going to close this in a few days.




Issue #141 - Silently deleting the Child SA after a CHILD_SA_NOT_FOUND
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Section 2.25: "A peer that receives a CHILD_SA_NOT_FOUND
notification SHOULD silently delete the Child SA": Is this really
necessary? I think this notification should only occur in cases where
DELETE payload for this Child SA pair has already been sent, and
probably has been processed already by the time the CHILD_SA_NOT_FOUND
notification is received.

No responses were received for this. My opinion is that CHILD_SA_NOT_FOUND =
will usually not occur at all. Even if lifetime is the same on both peers, =
rekeying is always done earlier than deleting (for example, if your SAs las=
t 1 hour, you might rekey at 58 minutes, but only delete after 60 minmutes)=
, so collisions of rekey and delete will be rare. Because of this, I believ=
e that the CHILD_SA_NOT_FOUND will stem from some mismatch in the SAD betwe=
en the two peers. Yes, this probably indicates a bug somewhere, but these t=
hings do happen. I believe the text should stay, as it clarifies that the p=
eer does not need to create a new INFORMATIONAL exchange with a DELETE payl=
oad to discard. In fact the text already has in brackets "(if it still exis=
ts)"

If anyone else has comments about this issue, please raise them NOW, becaus=
e we are going to close this in a few days.




I would also like to take this opportunity to ask people to look into issue=
 #140 (No SPD entry for transport mode), as I think this one needs some ser=
ious discussion before closing.


Yoav


From svanru@gmail.com  Sun Jan 24 23:03:51 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 257823A6808 for ; Sun, 24 Jan 2010 23:03:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.328
X-Spam-Level: 
X-Spam-Status: No, score=0.328 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, XMAILER_MIMEOLE_OL_7533E=0.513]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFkZQRExfPeU for ; Sun, 24 Jan 2010 23:03:50 -0800 (PST)
Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 2A4BD3A67AD for ; Sun, 24 Jan 2010 23:03:49 -0800 (PST)
Received: by ewy26 with SMTP id 26so1979394ewy.28 for ; Sun, 24 Jan 2010 23:03:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:references :subject:date:mime-version:content-type:content-transfer-encoding :x-priority:x-msmail-priority:x-mailer:x-mimeole; bh=22aM4YHKaJQOACfxLLBhpfF9KJtJhlLULHg6Uwl6awA=; b=CN2mp6sb86uzwgaWRHvwZCBDmC0dGtMjUcmVPAab9wcdmXJi1Td8dEzaMomeLWNIeF 8WYb8QgmOIQI9eUJBBRRqV3+mT2MBnSJTojPVcgnb5LrEbLYC4FmC9JvKjovvd6Vfo4R rbCJ/zsPwiskX8GsreMHtd5QS9BEKnOuDUwMg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=wBJlgdR1ks1Mr31I+nzdQHOHcjNtGKOudFhmV4zL3hb8cMFBXgfiC+8+xMGL0XZ/rE aNn/uisg7x7er++r1jYeX+LUdF43CuMTMUarYMWc1PK5qHEVhK2kEO6k5lrP+NDIAg2m BWP48kD4fzoOqfZXkJoFaW/iIt0rIK1rT3GzU=
Received: by 10.213.46.73 with SMTP id i9mr1586469ebf.57.1264403031981; Sun, 24 Jan 2010 23:03:51 -0800 (PST)
Received: from svanpc ([82.138.51.4]) by mx.google.com with ESMTPS id 15sm4302452ewy.12.2010.01.24.23.03.49 (version=SSLv3 cipher=RC4-MD5); Sun, 24 Jan 2010 23:03:50 -0800 (PST)
Message-ID: <26674719F6D84DAFB247A6AFC886DC75@trustworks.com>
From: "Valery Smyslov" 
To: "Yaron Sheffer" , , "Paul Hoffman" 
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A221F3@il-ex01.ad.checkpoint.com><7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A22201@il-ex01.ad.checkpoint.com> 
Date: Mon, 25 Jan 2010 10:04:38 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4963.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700
Subject: Re: [IPsec] Issue #157: Illustrate the SA payload with a diagram
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2010 07:03:51 -0000

Hi Paul,

Paul Hoffman writes:
> > > Ditto for Proposal #2: is there a good reason for you to not have
> >> included an INTEG transform?
> >I was trying to illustrate a combined mode algorithm. May have got it
wrong...
>
> That would be INTEG = NULL.

Omitting it completely is also allowed (section 3.3.3):

   A proposal MAY omit the optional types if the only value for them it will
accept is
   NONE.

Look also at section 2.7

   If an initiator proposes both normal ciphers with integrity
   protection as well as combined-mode ciphers, then two proposals are
   needed.  One of the proposals includes the normal ciphers with the
   integrity algoritms for them, and the other proposal includes all the
   combined mode ciphers without the integrity algorithms (because
   combined mode ciphers are not allowed to have any integrity algorithm
   other than "none").

...ant at section 3.3:

   Combined-mode ciphers include both
   integrity and encryption in a single encryption algorithm, and MUST
   either offer no integrity algorithm or a single integrity algorithm
   of "none", with no integrity algorithm being the RECOMMENDED method.


Probably both cases (NONE and omitting) could be included in the diagram.

Regards,
Valery Smyslov.



From svanru@gmail.com  Sun Jan 24 23:52:21 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0B673A6767 for ; Sun, 24 Jan 2010 23:52:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.879
X-Spam-Level: 
X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[AWL=1.207,  BAYES_00=-2.599, XMAILER_MIMEOLE_OL_7533E=0.513]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+SIugxW0BqH for ; Sun, 24 Jan 2010 23:52:20 -0800 (PST)
Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 982333A67B0 for ; Sun, 24 Jan 2010 23:52:19 -0800 (PST)
Received: by ey-out-2122.google.com with SMTP id 22so481858eye.5 for ; Sun, 24 Jan 2010 23:52:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:references :subject:date:mime-version:content-type:content-transfer-encoding :x-priority:x-msmail-priority:x-mailer:x-mimeole; bh=HCo8A/fMeCkusogZeUdnQBiE2CDZ8qThVzTfNpZjl2g=; b=IdiRKF+c1wq0SCIsRyeNepBloaojyWFT8/iAntEncwih0H6uBZFCLt4Y5mxv4bsuAZ C/5RLfrBla4+KUbImydgQ84zpIAzXWH5GwlmDzMpwG/h3KadP5E0HpR574/nbnzjZ9aW evxESj5E/HdbUeVKMqMne7RLqXLT/rqdG8t9U=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=gSyHAsUyTtE3SyE1QKHhe1IFCskEnTt+AWjkCuXgdw24e0pepDp/qcsFcy5NrTVBGD OcVAz6eExQW46H2O8VoBMN2W5p6FI+L8RMDUDIGHAXVses1XMkYMM/mDmixzN3aXl+Xs Hj6j5SpBHVA19zQR7oNx9kfapjoEbiyXhJRdM=
Received: by 10.213.2.67 with SMTP id 3mr3263377ebi.77.1264405941694; Sun, 24 Jan 2010 23:52:21 -0800 (PST)
Received: from svanpc ([82.138.51.4]) by mx.google.com with ESMTPS id 13sm4314067ewy.9.2010.01.24.23.52.20 (version=SSLv3 cipher=RC4-MD5); Sun, 24 Jan 2010 23:52:21 -0800 (PST)
Message-ID: <39AFF7414AB347EA89ADAE7E6053E9DC@trustworks.com>
From: "Valery Smyslov" 
To: "Yoav Nir" , "IPsecme WG" 
References: 
Date: Mon, 25 Jan 2010 10:53:09 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4963.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700
Subject: Re: [IPsec] Closing some of the open tickets for IKEv2bis
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2010 07:52:22 -0000

Yoav Nir writes:

> Issue #139 - Keying material taken in the order for RoHC
> ========================================================
> One of the differences between RFC 4306 and the IKEv2bis draft is in
Section 2.17, Generating Key Material for Child SAs. Appendix E.2 of the
IKEv2bis draft indicates the following:
> In Section 2.17, removed "If multiple IPsec protocols are negotiated,
keying material is taken in the order in which the protocol headers will
appear in the encapsulated packet" because multiple IPsec protocols cannot
be negotiated at one time.
> Is it possible to leave the quoted text in the spec? I agree that multiple
IPsec protocols cannot be negotiated at one time; however, the text is
useful for ROHCoIPsec implementers, where multiple keys may need to be
generated for a ROHC-enabled Child SA.
> For example, if a ROHC-enabled Child-SA with ROHC_INTEG
[draft-ietf-rohc-ikev2-extensions-hcoipsec-09] is instantiated, first the
IPsec encryption/authentication keying material will be taken, then an
additional key will be taken for the algorithm used to verify the proper
decompression of packet headers.
>
> I said I preferred to leave the text as it is, and let RoHC specify their
modifications (which they did). Valery, Tero, and David chimed in, correctly
pointing out that if multiple extensions are negotiated (RoHC + GCM + some
future extension) it is up to the base document to specify the order between
them. I'm convinced. Paul also suggested some text (below) for a bulleted
list of two points. Tero suggested a third (encryption before
authentication), but Valery pointed out that this is already in 4301.
>
>    If the Child SA negotiation includes some future IPsec protocol(s)
>    in addition to (or instead of) ESP or AH (e.g., ROHC_INTEG), then
>    (1) all keys for SAs carrying data from the initiator to the
>    responder are taken before SAs going in the reverse direction, and
>    (2) keying material for the IPsec protocols are taken in the order
>    in which the protocol headers will appear in the encapsulated
>    packet.
>
> If anyone else has comments about this issue, please raise them NOW,
because we are going to close this in a few days.

Sorry for being tedious, but I don't understand whether proposed text is in
addition
to current one, or replaces it. Current text from draft-07 overlaps with
RFC4301,
which already prescribes the order for deriving encryption and
authentication keys
for single SA. I see no point to repeat this rule (at least in RFC2119
terms).

I would suugest replacing current text from draft-07:
========================================================
   For ESP and AH, a single Child SA negotiation results in two security
   associations (one in each direction).  Keying material MUST be taken
   from the expanded KEYMAT in the following order:

   o  The encryption key (if any) for the SA carrying data from the
      initiator to the responder.

   o  The authentication key (if any) for the SA carrying data from the
      initiator to the responder.

   o  The encryption key (if any) for the SA carrying data from the
      responder to the initiator.

   o  The authentication key (if any) for the SA carrying data from the
      responder to the initiator.
========================================================

with the following:
========================================================
   A single CHILD_SA negotiation may result in multiple security
   associations.  ESP and AH SAs exist in pairs (one in each direction),
   so two SAs are created in a single Child SA negotiation for them.
   Furthermore, Child SA negotiation may include some future IPsec
protocol(s)
   in addition to (or instead of) ESP or AH (e.g., ROHC_INTEG).
   In any case, keying material for each child SA MUST be taken from the
   expanded KEYMAT in the following order:

   o  All keys for SAs carrying data from the initiator to the responder
      are taken before SAs going in the reverse direction.

   o  If multiple IPsec protocols are negotiated, keying material is
      taken in the order in which the protocol headers will appear in
      the encapsulated packet.

   If IPsec protocol requires multiple keys, the order in which they are
derived
   from SA's keyng material MUST be described in protocol specification. For
ESP
   and AH [IPSECARCH] defines the order, namely: the encryption key (if any)
   MUST be taken from the first bits and the integrity key (if any) MUST be
taken
   from the remaining bits.
========================================================

Regards,
Valery Smyslov.



From yaronf@checkpoint.com  Mon Jan 25 00:39:52 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E7B53A6405 for ; Mon, 25 Jan 2010 00:39:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZmzCJX+FmoM for ; Mon, 25 Jan 2010 00:39:51 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 4A3943A6767 for ; Mon, 25 Jan 2010 00:39:50 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0P8dtT7016872; Mon, 25 Jan 2010 10:39:55 +0200 (IST)
X-CheckPoint: {4B5D58E7-0-1B201DC2-5FFFF}
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 25 Jan 2010 10:40:09 +0200
From: Yaron Sheffer 
To: Paul Hoffman , "ipsec@ietf.org" 
Date: Mon, 25 Jan 2010 10:40:06 +0200
Thread-Topic: [IPsec] Issue #157: Illustrate the SA payload with a diagram
Thread-Index: AcqcYP4frLVcSSjjQGWORdmGz3wZnABOLBug
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A8052E@il-ex01.ad.checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A221F3@il-ex01.ad.checkpoint.com>  <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A22201@il-ex01.ad.checkpoint.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [IPsec] Issue #157: Illustrate the SA payload with a diagram
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2010 08:39:52 -0000

3.3.6 mentions it quite explicitly, and I don't think need to say it again =
is 3.3.3:

"If the responder receives a proposal that contains a Transform Type it doe=
s not understand, or a proposal that is missing a mandatory Transform Type,=
 it MUST consider this proposal unacceptable; however, other proposals in t=
he same SA payload are processed as usual."

Thanks,
	Yaron

> -----Original Message-----
> From: Paul Hoffman [mailto:paul.hoffman@vpnc.org]
> Sent: Saturday, January 23, 2010 21:19
> To: Yaron Sheffer; ipsec@ietf.org
> Subject: RE: [IPsec] Issue #157: Illustrate the SA payload with a
> diagram
>=20
[snip]
>=20
> > > This begs the related question: given that there is no MUST or
> should
> >> for what goes into a Proposal, what does an ESP proposal that only
> has
> >> an ENCR and INTEG in it mean with respect to what is being proposed
> for
> >> ESN? What does an ESP proposal that has only an ENCR and ESN in it
> mean
> >> with respect to what is being proposed for INTEG? I see no MUSTs or
> >> SHOULDs answering this.
> >3.3.3 says ESN is mandatory. Which means if it is omitted, the
> recipient will reject the proposal.
>=20
> As I said, I don't see any MUST or SHOULD for that. It would be better
> if this was stated. A possible addition to 3.3.3 would be "A proposal
> that does not contain all of the mandatory transforms is malformed and
> MUST be rejected".
>=20
> --Paul Hoffman, Director
> --VPN Consortium
>=20
> Scanned by Check Point Total Security Gateway.

From kivinen@iki.fi  Mon Jan 25 01:10:36 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B94E33A6915 for ; Mon, 25 Jan 2010 01:10:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfjI+qWuLlDS for ; Mon, 25 Jan 2010 01:10:35 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id C6E893A68A3 for ; Mon, 25 Jan 2010 01:10:34 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0P9ATsB002080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 11:10:29 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0P9ARVj003308; Mon, 25 Jan 2010 11:10:27 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19293.24579.351944.494849@fireball.kivinen.iki.fi>
Date: Mon, 25 Jan 2010 11:10:27 +0200
From: Tero Kivinen 
To: Yaron Sheffer 
In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A221E8@il-ex01.ad.checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21EF8@il-ex01.ad.checkpoint.com> <19286.62825.898863.477577@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A21FEA@il-ex01.ad.checkpoint.com> <19287.12109.881311.935809@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A221E8@il-ex01.ad.checkpoint.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 8 min
X-Total-Time: 7 min
Cc: "ipsec@ietf.org" 
Subject: Re: [IPsec] IKEv2-bis, comments up to 2.16
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2010 09:10:36 -0000

Yaron Sheffer writes:
> Hi Tero,
> 
> I was ready to accept your answer, until I came across the following
> sentence in -07. 
> 
> "Payloads are processed in the order in which they appear in an IKE
> message by invoking the appropriate processing routine according to
> the "Next Payload" field in the IKE header and subsequently
> according to the "Next Payload" field in the IKE payload itself
> until a "Next Payload" field of zero indicates that no payloads
> follow." 

That says there is nothing in the spec which requires you to do out of
order payload processing. It does not say you cannot do that, and as
there is not really anything where the result would be different
depending in which order you process payloads the way implementation
processes payloads does not really matter.

On the other hand the parsing needs to be done in the order the
payloads are in the packet (it would be very hard to do in any other
order :-), and if the parsing causes for example
UNSUPPORTED_CRITICAL_PAYLOAD, then that should be sent before the rest
of the payloads are parsed (i.e. the first unsupported critical
payload should trigger that error). 

> This seems to say exactly what I was proposing! Did I miss another
> statement in the document where we say the opposite (that payload
> order doesn't matter)? 

Nope, but the text above does not forbid any other processing order,
as long as the end result will be same, or at least this is how I have
interpreted it.

The text is not MUST in interoperability sense, it is just text
explaining how the processing of packets happens, and as there is not
really a way to detect how the implementation processes packets from
the outside, it does not need MUST in interoperability sense.

Your text would add MUST in interoperability sense, and I would like
to see how you are going to test that some product really supports
that MUST. 
-- 
kivinen@iki.fi

From kivinen@iki.fi  Mon Jan 25 01:18:21 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37A5F3A6915 for ; Mon, 25 Jan 2010 01:18:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lf3XDNFtj+rV for ; Mon, 25 Jan 2010 01:18:20 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id F22863A683E for ; Mon, 25 Jan 2010 01:18:19 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0P9IN0D003861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 11:18:23 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0P9ILlm001649; Mon, 25 Jan 2010 11:18:21 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19293.25053.902474.678053@fireball.kivinen.iki.fi>
Date: Mon, 25 Jan 2010 11:18:21 +0200
From: Tero Kivinen 
To: "Jerome A. Solinas" 
In-Reply-To: <4B59F2F1.9030107@orion.ncsc.mil>
References: <19243.32427.247190.77844@fireball.kivinen.iki.fi>  <4B59F2F1.9030107@orion.ncsc.mil>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 7 min
X-Total-Time: 6 min
Cc: ipsec@ietf.org
Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-01)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2010 09:18:21 -0000

Jerome A. Solinas writes:
> We would recommend keeping the same numbers (19, 20, 21) since it 
> appears that all existing implementations have made the correction.

Not true.

For example our QuickSec OEM IPsec toolkit did originally use only X,
but then some vendor complained that RFC4753 uses both X and Y so we
"fixed" our toolkit to use both. All version shipped between 2007 and
end of 2009 uses both X and Y, and only the latest version uses only
X.

Yes, this will mean that our latest version is not compatible with our
old versions, so most likely that will cause the connections timeout
when ECP groups are used, thus most likely users will then just notice
that "Do not use ECP, it does not work".

And note, that we only modified our code when some OTHER vendor told
us that RFC4753 uses both X and Y.

So we were not the only implementation out there which followed
original RFC4753.

Also as our customer has quite a long product cycles usually meaning
that the release we make now will most likely get into the products
only after year or two, and when we provide fixes for old versions for
them, they might or might not make their actual products, that is not
something we can tell. Usually it takes long time to get them into
their products, which means the QuickSec toolkit based implementations
using X and Y are going to be out there for long time... 
-- 
kivinen@iki.fi

From kivinen@iki.fi  Mon Jan 25 01:59:06 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81C733A68F3 for ; Mon, 25 Jan 2010 01:59:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WD5v0qmL-vmk for ; Mon, 25 Jan 2010 01:59:05 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 1BD6D3A672E for ; Mon, 25 Jan 2010 01:59:04 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0P9x4ee014243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 11:59:04 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0P9x3K0006861; Mon, 25 Jan 2010 11:59:03 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19293.27495.671116.48830@fireball.kivinen.iki.fi>
Date: Mon, 25 Jan 2010 11:59:03 +0200
From: Tero Kivinen 
To: Yaron Sheffer 
In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A221F3@il-ex01.ad.checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A221F3@il-ex01.ad.checkpoint.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 36 min
X-Total-Time: 38 min
Cc: "ipsec@ietf.org" 
Subject: [IPsec]  Issue #157: Illustrate the SA payload with a diagram
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2010 09:59:06 -0000

Yaron Sheffer writes:
> The text in 3.3 requires "peace of mind" to fully appreciate. A diagram might be helpful.
> 
> Here's a first shot (we'll need to add some descriptive text):
> 
>                         SA Payload
>                             |
>                       ---------------............-
>                       |             |            |
>                Proposal #1       Proposal #2   Proposal #n
>                      ESP           ESP
>                      SPIx          SPIy
>                       |             |
>            ---------------------    --------------------
>            |                   |             |         |
>       Transform A        Tranform B    Transform C Transform D
>           ENCR               AUTH          ENCR       ESN
>           AES            HMAC-SHA-256    AES-CCM     ESN=1
>            |
>    -----------------
>    |       |       |
> Attr Ax Attr Ay Attr Az
>   128     192     256

Remove the Proposal #n part, as there is no need for that. It is bad
idea to include more than 2 proposals, as it just makes the payloads
bigger, and causes all kind of problems (for example in IKEv1 this
only way to do this, and vendors had very small upper limit for
number of proposals (2, 4 or 8 or so)). 

As in IKEv2 multiple proposals is really needed only for normal
ciphers + authentication vs combined mode ciphers, so the example
should also show two, and this is something we should try to get
vendors to implement.

I have noticed that some vendors have taken their IKEv1 SA payload
processing and are making lots of proposals each having one algorithm
suite and in some cases they still have combination suite including
all alrogithms. This is just stupid and makes packets bigger and can
cause for example fragmentation for the packets, which would be much
smaller if the normal IKEv2 SA payload would be used.

This might be better example:
----------------------------------------------------------------------

                          SA Payload
                              |
           +------------------+---------------------------+
           |                                              |
           |                                              |
       Proposal #1                                    Proposal #2
   Proto ID = ESP (3)                             Proto ID = ESP (3)
     SPI size = 4                                   SPI size = 4
     5 transforms                                   2 transforms
   SPI = 0x95903423                               SPI = 0x12345678
         |                                              |
     +---+-----+---------+---------+---------+          +---------+
     |         |         |         |         |          |         |
 Transform Transform Transform Transform Transform  Transform Transform
   ENCR      INTEG     INTEG      ESN       ESN       ENCR       ESN
   ENCR    AUTH_HMAC  AUTH_AES   ESN=0     ESN=1    AES-GCM     ESN=1
 _AES_CBC   _SHA1_96  _XCBC_96                      w/8 octet
     |                                                ICV
     |                                                 |
   +-+---------+-----------+            +-----------+--+--------+
   |           |           |            |           |           |
Attribute   Attribute   Attribute    Attribute   Attribute   Attribute
Key Length  Key Length  Key Length   Key Length  Key Length  Key Length
   128         192         256          128         192         256

----------------------------------------------------------------------
And that proposes 3 (ciphers) * 2 (integrity algorithms) * 2 (esn or
no esn) + 3 (combined mode with 3 key lengths) = 15 combinations:

ENCR_AES_CBC 128 bit key, AUTH_HMAC_SHA1_96, ESN=0
ENCR_AES_CBC 128 bit key, AUTH_HMAC_SHA1_96, ESN=1
ENCR_AES_CBC 128 bit key, AUTH_HMAC_XCBC_96, ESN=0
ENCR_AES_CBC 128 bit key, AUTH_HMAC_XCBC_96, ESN=1
ENCR_AES_CBC 192 bit key, AUTH_HMAC_SHA1_96, ESN=0
ENCR_AES_CBC 192 bit key, AUTH_HMAC_SHA1_96, ESN=1
ENCR_AES_CBC 192 bit key, AUTH_HMAC_XCBC_96, ESN=0
ENCR_AES_CBC 192 bit key, AUTH_HMAC_XCBC_96, ESN=1
ENCR_AES_CBC 256 bit key, AUTH_HMAC_SHA1_96, ESN=0
ENCR_AES_CBC 256 bit key, AUTH_HMAC_SHA1_96, ESN=1
ENCR_AES_CBC 256 bit key, AUTH_HMAC_XCBC_96, ESN=0
ENCR_AES_CBC 256 bit key, AUTH_HMAC_XCBC_96, ESN=1
AES-GCM with 8 octet ICV 128 bit key, ESN=1
AES-GCM with 8 octet ICV 192 bit key, ESN=1
AES-GCM with 8 octet ICV 256 bit key, ESN=1

and the full SA payload takes 108 bytes.

BTW, If expanded to IKEv1 style the same SA payload would contain 15
proposals and would be 576 bytes...

If someone wanted to also allow PFS with for example 2 different
groups (plus none) it would add 48 bytes to the IKEv2 style payload,
but would multiply be IKEv1 style payload with 3 plus some raising it
to 2088 bytes...
-- 
kivinen@iki.fi

From kivinen@iki.fi  Mon Jan 25 02:48:12 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E7CC3A67A8 for ; Mon, 25 Jan 2010 02:48:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJbb965jYpWt for ; Mon, 25 Jan 2010 02:48:11 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 3D8343A672E for ; Mon, 25 Jan 2010 02:48:11 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0PAm7Y9021836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 12:48:07 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0PAm6q3006894; Mon, 25 Jan 2010 12:48:06 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19293.30438.102271.679591@fireball.kivinen.iki.fi>
Date: Mon, 25 Jan 2010 12:48:06 +0200
From: Tero Kivinen 
To: Paul Hoffman 
In-Reply-To: 
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A221F3@il-ex01.ad.checkpoint.com> 
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 10 min
X-Total-Time: 47 min
Cc: "ipsec@ietf.org" 
Subject: Re: [IPsec] Issue #157: Illustrate the SA payload with a diagram
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2010 10:48:12 -0000

Paul Hoffman writes:
> Ditto for Proposal #2: is there a good reason for you to not have
> included an INTEG transform?

Proposal #2 is the combined mode cipher, thus it cannot have INTEG
other than none, and I though we agreed that it would be better to
leave the whole INTEG transform out in those cases (in section 3.3):

		      Combined-mode ciphers include both
   integrity and encryption in a single encryption algorithm, and MUST
   either offer no integrity algorithm or a single integrity algorithm
   of "none", with no integrity algorithm being the RECOMMENDED method.

> This begs the related question: given that there is no MUST or
> should for what goes into a Proposal, what does an ESP proposal that
> only has an ENCR and INTEG in it mean with respect to what is being
> proposed for ESN? What does an ESP proposal that has only an ENCR
> and ESN in it mean with respect to what is being proposed for INTEG?
> I see no MUSTs or SHOULDs answering this. 

As already pointed out that would be incorrect proposal, but I would
expect lots of the implementations will actually accept it and assume
it means the same thing as ESN=0.

So complient implementation cannot send such proposals. If complient
implementations receives such proposal it should either return error
or assume ESN=0. This is because RFC4306 said in 3.3.3:


                                A proposal MAY
   omit the optional types if the only value for them it will accept is
   NONE.

and implementations assumed NONE == 0 == No Extended Sequence Numbers,
meaning if No Extended Sequence Numbers were to be proposed, that
transform could be left out.

As this was confusing that was the reason ESN text was clarified a bit
(i.e. added the paragraph after ESN section in IKEv2bis) and there is
more about it in the RFC4718 section 4.4.
-- 
kivinen@iki.fi

From ynir@checkpoint.com  Mon Jan 25 03:20:33 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB16B3A672E for ; Mon, 25 Jan 2010 03:20:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level: 
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUbxM9PAPN+M for ; Mon, 25 Jan 2010 03:20:32 -0800 (PST)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 0DB113A67CF for ; Mon, 25 Jan 2010 03:20:31 -0800 (PST)
X-CheckPoint: {4B5D7BE6-10000-14201DC2-FFFF}
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id D378129C069; Mon, 25 Jan 2010 13:20:36 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id AA51C29C068 for ; Mon, 25 Jan 2010 13:20:36 +0200 (IST)
X-CheckPoint: {4B5D7BE5-10000-14201DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0PBKaT7013688 for ; Mon, 25 Jan 2010 13:20:36 +0200 (IST)
X-CheckPoint: {4B5D7E8E-1-1B201DC2-5FFFF}
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 25 Jan 2010 13:20:50 +0200
From: Yoav Nir 
To: Yaron Sheffer 
Date: Mon, 25 Jan 2010 13:20:27 +0200
Thread-Topic: [IPsec] Issue #157: Illustrate the SA payload with a diagram
Thread-Index: AcqdsHKXdZsIYmYqS2eE8LWPhC+tOg==
Message-ID: <659E83FA-0A21-4DE6-88C1-5D67A1C78F68@checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A221F3@il-ex01.ad.checkpoint.com>
In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A221F3@il-ex01.ad.checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ipsec@ietf.org" 
Subject: Re: [IPsec] Issue #157: Illustrate the SA payload with a diagram
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2010 11:20:33 -0000

On Jan 22, 2010, at 11:57 PM, Yaron Sheffer wrote:

> The text in 3.3 requires "peace of mind" to fully appreciate. A diagram m=
ight be helpful.
>=20
> Here's a first shot (we'll need to add some descriptive text):
>=20
>                        SA Payload
>                            |
>                      ---------------............-
>                      |             |            |
>               Proposal #1       Proposal #2   Proposal #n
>                     ESP           ESP
>                     SPIx          SPIy
>                      |             |
>           ---------------------    --------------------
>           |                   |             |         |
>      Transform A        Tranform B    Transform C Transform D
>          ENCR               AUTH          ENCR       ESN
>          AES            HMAC-SHA-256    AES-CCM     ESN=3D1
>           |
>   -----------------
>   |       |       |
> Attr Ax Attr Ay Attr Az
>  128     192     256

I'm sorry I just noticed this, but is this even allowed?  Can you include m=
ultiple key length attributes in the same transform?

Section 3.3.6 says:

                 If there are multiple proposals, the responder MUST
   choose a single proposal.  If the selected proposal has multiple
   Transforms with the same type, the responder MUST choose a single
   one.

So far, it's OK. The responder chooses one proposal, and if that proposal c=
ontains multiple transforms of the same type (say AUTH=3DHMAC-SHA-1 and AUT=
H=3DHMAC-SHA-256) then the responder chooses just one of those.


         Any attributes of a selected transform MUST be returned
   unmodified.

To me, "unmodified" does not mean choose one of three. So IMO the above Pro=
posal #1 should be as follows (ignoring the missing ESN):

              Proposal #1=20
                    ESP  =20
                    SPIx =20
                     |   =20
      --------------------- =20
      |                   |    =20
 Transform A   Transform B   Transform C   Transform D =20
     ENCR          ENCR          ENCR          AUTH   =20
     AES           AES           AES       HMAC-SHA-256=20
      |             |             |
   Attr Ax       Attr Ay       Attr Az
     128           192           256

                The initiator of an exchange MUST check that the
   accepted offer is consistent with one of its proposals, and if not
   that response MUST be rejected.

BTW: how do you reject a response?

Yoav=

From kivinen@iki.fi  Mon Jan 25 03:30:54 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 614FA3A6827 for ; Mon, 25 Jan 2010 03:30:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBPc4BbGc5UT for ; Mon, 25 Jan 2010 03:30:53 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 915C83A67B6 for ; Mon, 25 Jan 2010 03:30:52 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0PBUq3Z019843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 13:30:52 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0PBUqYK005691; Mon, 25 Jan 2010 13:30:52 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19293.33004.243945.230722@fireball.kivinen.iki.fi>
Date: Mon, 25 Jan 2010 13:30:52 +0200
From: Tero Kivinen 
To: Yaron Sheffer 
In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A804C9@il-ex01.ad.checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A804C9@il-ex01.ad.checkpoint.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 40 min
X-Total-Time: 41 min
Cc: IPsecme WG 
Subject: [IPsec]  IKEv2-bis comments: 2.17 and onwards
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2010 11:30:54 -0000

Yaron Sheffer writes:
> 2.21.: EAP Failure cases are missing altogether. Also, the first
> paragraph says that if an auth failure occurs at the responder,
> AUTHENTICATION_FAILED is included in the protected response (to
> IKE_AUTH),

Yes.

> while the last paragraph says it's a separate
> Informational exchange.

Where does it say that if failure occurs at the responder you are
allowed to use separate INFORMATIONAL exchange? It was supposed to say
that in case the failure occurs at the INITIATOR (i.e. parsing the
response packet) then it MAY use INFORMATIONAL exchange.

> 2.24: what's this section (ECN) doing here? It is 100% IPsec,
> nothing to do with IKE. If there's a reason, let's explain it in
> the text.

It is here because if IKEv2 is used then ECN behavior is implictly
mandated by just using IKEv2. In IKEv1 we had negotiation ability for
it, but not in IKEv2. I think the current text already explains this:

            ECN support for IPsec tunnels for IKEv1-
   based IPsec requires multiple operating modes and negotiation (see
   [ECN]).  IKEv2 simplifies this situation by requiring that ECN be
   usable in the outer IP headers of all tunnel-mode Child SAs created
   by IKEv2.  Specifically, tunnel encapsulators and decapsulators for
   all tunnel-mode SAs created by IKEv2 MUST support the ECN full-
   functionality option for tunnels specified in [ECN] and MUST
   implement the tunnel encapsulation and decapsulation processing
   specified in [IPSECARCH] to prevent discarding of ECN congestion
   indications.

> 3.3.2: Tiger - we closed issue #33, but according to the text of the
> issue, should have left the algorithm "unspecified". Which I think
> would be much more accurate.

The "Not done" part is from the time Paul opened the issue, not the
final outcome from the issue.

Final outcome can be found from here:

http://www.ietf.org/mail-archive/web/ipsec/current/msg03187.html

> 3.3.5: "Attributes described as fixed length MUST NOT be encoded
> using the variable-length encoding." This cannot be correct, a new
> 4-octet attribute will have to be encoded as variable-length. It
> won't fit into the other format.

This should use "TV" and "TLV" format text instead:

   The only currently defined attribute type (Key Length) is using TV
   encoding; the TLV encoding specification is included only for
   future extensions. Attributes described as using TV encoding MUST
   NOT be encoded using the TLV encoding. Attributes described as
   using TLV encoding MUST NOT be encoded as using TV encoding even if
   their value can fit into two octets. NOTE: This is a change from
   IKEv1, where increased flexibility may have simplified the composer
   of messages but certainly complicated the parser.

> 3.6: "DNS Signed Key" is marked Unspecified. Is it not RFC 4025?
> It's not used anywhere, but still...

I do not think the DNS Signed Key mans the same as IPSECKEY RR
specified in the RFC4025. Or it could be it means, but nobody knows,
thus I think it is correct to keep it UNSPECIFIED, especially as this
value dates back to the RFC2408 which predates RFC4025 and RFC4025
does not mention that it actually specifies what this format in IKE
should mean.

> 3.7: "If multiple CAs are trusted and the certificate encoding does
> not allow a list, then multiple Certificate Request payloads would
> need to be transmitted." This doesn't make sense: we are not sending
> the cert itself here. we're just sending an encoding on a CA.
> Moreover, the text further down indicates that the CA field is
> *always* a list - at least for the defined cert types (4, 12, 13).
> Overall, this looks like a placeholder, and I suggest to delete the
> sentence.

It is placeholder for other formats not defined in this document, i.e.
it explictly says that if some future certificate encoding type
defines format how certificate authorities are sent inside the CERTREQ
payload and that newly defined format does not allow list then
multiple CERTREQ payloads are sent.

As all currently defined certificate encodings do allow list, this
does not affect them.

I suggest keeping that text.

> 3.10.1: INVALID_SELECTORS is underspecified. It should be rate
> limited (I suppose), also, how long is the packet fragment included
> in the notification?

Yes, most likely it should be rate limited, but that is not hard
requirement, as this is caused when authenticated entity does
something incorrect (i.e includes traffic that is not allowed in this
SA).

Also RFC4301 already mentions rate limitation etc:
----------------------------------------------------------------------
   5.  If an IPsec system receives an inbound packet on an SA and the
       packet's header fields are not consistent with the selectors for
       the SA, it MUST discard the packet.  This is an auditable event.
       The audit log entry for this event SHOULD include the current
       date/time, SPI, IPsec protocol(s), source and destination of the
       packet, any other selector values of the packet that are
       available, and the selector values from the relevant SAD entry.
       The system SHOULD also be capable of generating and sending an
       IKE notification of INVALID_SELECTORS to the sender (IPsec peer),
       indicating that the received packet was discarded because of
       failure to pass selector checks.

   To minimize the impact of a DoS attack, or a mis-configured peer, the
   IPsec system SHOULD include a management control to allow an
   administrator to configure the IPsec implementation to send or not
   send this IKE notification, and if this facility is selected, to rate
   limit the transmission of such notifications.
----------------------------------------------------------------------

I think the as in ICMP message provides good enough hint how the
packet fragment should be included (i.e. not too long as it would
waste bandwidth, but long enough to allow other end to see all
selectors). 

> In addition, Sec. 2.21.2 implies that it is sent during Child SA
> negotiation, which is not what 3.10.1 is saying.

Yes, the 2.21.2 should not include INVALID_SELECTORS in its list of
notify paylaods there, so changing

				Specifically, a
   responder may include all the payloads associated with authentication
   (IDr, Cert and AUTH) while sending error notifications for the
   piggybacked exchanges (FAILED_CP_REQUIRED, INVALID_SELECTORS,
   NO_PROPOSAL_CHOSEN, and so on), and the initiator MUST NOT fail the
   authentication because of this.  

to

				Specifically, a
   responder may include all the payloads associated with
   authentication (IDr, Cert and AUTH) while sending error
   notifications for the piggybacked exchanges (FAILED_CP_REQUIRED
   NO_PROPOSAL_CHOSEN, and so on), and the initiator MUST NOT fail the
   authentication because of this.

is required.

> 3.15.1: "With IPv6, a requestor MAY supply the low-order address
> octets it wants to use." This means to me that you *don't* provide
> all 16 octets. But according to the table, the field is a
> fixed-length 16 octets!

No, you always include full 16 octets, but you might only fill in the
lower 8 octets. You can also fill in the full 16 octets, if you have
address from previous runs.

I.e. you can send following INTERNAL_IP6_ADDRESS payloads in the
CFG_REQUEST:

INTERNAL_IP6_ADDRESS(2001:1bc8:100d:2:21d:9ff:fea5:c19a/64) = 17 bytes
INTERNAL_IP6_ADDRESS(::21d:9ff:fea5:c19a/64) = 17 bytes
INTERNAL_IP6_ADDRESS() = 0 bytes.

> 5: unfortunately we have to revise the text about group strengths -
> or remove it altogether. It is non-normative, so it's probably best
> to eliminate it.

Why is that, and what text you mean?

I still think group 2 (1024-bit group) is common for use with 3DES.
Also group 5 (1536-bit group) does provide more security than group 2
(1024-bit group).

Also group 1 (768-bit group) is for historic purposes only and does
not provide sufficient strength except for use with DES, which is also
for historic use only.

So which of those statement requires revising? 
-- 
kivinen@iki.fi

From kivinen@iki.fi  Mon Jan 25 03:44:05 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BA623A6995 for ; Mon, 25 Jan 2010 03:44:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdDUVLddprKB for ; Mon, 25 Jan 2010 03:44:04 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id C398C3A6978 for ; Mon, 25 Jan 2010 03:44:03 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0PBi68R004619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 13:44:06 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0PBi6XQ011725; Mon, 25 Jan 2010 13:44:06 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19293.33798.66951.414633@fireball.kivinen.iki.fi>
Date: Mon, 25 Jan 2010 13:44:06 +0200
From: Tero Kivinen 
To: Yoav Nir 
In-Reply-To: 
References: 
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 10 min
X-Total-Time: 10 min
Cc: IPsecme WG 
Subject: [IPsec]  Closing some of the open tickets for IKEv2bis
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2010 11:44:05 -0000

Yoav Nir writes:
> Issue #138 - Calculations involving Ni/Nr
> =========================================
> Section 2.14: "only the first 64 bits of Ni and the first 64 bits of
> Nr are used in the calculation". This section has two calculations
> involving Ni/Nr, but this sentence should only apply to the former.
> Suggested rephrasing: "the calculation" -> "when calculating
> SKEYSEED (but all bits are used when calculating SK_*)" 
> 
> There was just one response (from me), and I suggested the following text:
>    only the first 64 bits of Ni and the first 64 bits of Nr are used
> in calculating SKEYSEED, but all the bits are used for input to the
> prf+ function. 

That change is ok for me.

> Issue #139 - Keying material taken in the order for RoHC
> ========================================================
> One of the differences between RFC 4306 and the IKEv2bis draft is in
> Section 2.17, Generating Key Material for Child SAs. Appendix E.2 of
> the IKEv2bis draft indicates the following: 
> In Section 2.17, removed "If multiple IPsec protocols are
> negotiated, keying material is taken in the order in which the
> protocol headers will appear in the encapsulated packet" because
> multiple IPsec protocols cannot be negotiated at one time. 
> Is it possible to leave the quoted text in the spec? I agree that
> multiple IPsec protocols cannot be negotiated at one time; however,
> the text is useful for ROHCoIPsec implementers, where multiple keys
> may need to be generated for a ROHC-enabled Child SA. 
> For example, if a ROHC-enabled Child-SA with ROHC_INTEG
> [draft-ietf-rohc-ikev2-extensions-hcoipsec-09] is instantiated,
> first the IPsec encryption/authentication keying material will be
> taken, then an additional key will be taken for the algorithm used
> to verify the proper decompression of packet headers. 
> 
> I said I preferred to leave the text as it is, and let RoHC specify
> their modifications (which they did). Valery, Tero, and David chimed
> in, correctly pointing out that if multiple extensions are
> negotiated (RoHC + GCM + some future extension) it is up to the base
> document to specify the order between them. I'm convinced. Paul also
> suggested some text (below) for a bulleted list of two points. Tero
> suggested a third (encryption before authentication), but Valery
> pointed out that this is already in 4301. 
> 
>    If the Child SA negotiation includes some future IPsec protocol(s)
>    in addition to (or instead of) ESP or AH (e.g., ROHC_INTEG), then
>    (1) all keys for SAs carrying data from the initiator to the
>    responder are taken before SAs going in the reverse direction, and
>    (2) keying material for the IPsec protocols are taken in the order
>    in which the protocol headers will appear in the encapsulated
>    packet.
> 
> If anyone else has comments about this issue, please raise them NOW,
> because we are going to close this in a few days.

This two bullet version is fine by me, I had missed the text in the
RFC4301, so my proposed 3rd bullet is not need.

> Issue #141 - Silently deleting the Child SA after a CHILD_SA_NOT_FOUND
> ======================================================================
> Section 2.25: "A peer that receives a CHILD_SA_NOT_FOUND
> notification SHOULD silently delete the Child SA": Is this really
> necessary? I think this notification should only occur in cases where
> DELETE payload for this Child SA pair has already been sent, and
> probably has been processed already by the time the CHILD_SA_NOT_FOUND
> notification is received.
> 
> No responses were received for this.

I proposed new text for this:

http://www.ietf.org/mail-archive/web/ipsec/current/msg05695.html

> My opinion is that CHILD_SA_NOT_FOUND will usually not occur at all.
> Even if lifetime is the same on both peers, rekeying is always done
> earlier than deleting (for example, if your SAs last 1 hour, you
> might rekey at 58 minutes, but only delete after 60 minmutes), so
> collisions of rekey and delete will be rare. Because of this, I
> believe that the CHILD_SA_NOT_FOUND will stem from some mismatch in
> the SAD between the two peers. Yes, this probably indicates a bug
> somewhere, but these things do happen. I believe the text should
> stay, as it clarifies that the peer does not need to create a new
> INFORMATIONAL exchange with a DELETE payload to discard. In fact the
> text already has in brackets "(if it still exists)"

That bracketed part was added to solve this #141. 

> If anyone else has comments about this issue, please raise them NOW,
> because we are going to close this in a few days.

So I think this issue can already be closed, as the at least from my
point of view the fix has already been added to the -07 version. 

> I would also like to take this opportunity to ask people to look
> into issue #140 (No SPD entry for transport mode), as I think this
> one needs some serious discussion before closing. 

As I pointed out in my email
http://www.ietf.org/mail-archive/web/ipsec/current/msg05694.html
I need more information what RFC5555 really needs before I can comment
on this issue. I used about half an hour writing about 200 lines of
more detailed analysis about the issue, but then ended up deleting it
when I realized that it is no point for me to go and try to cover all
possible cases, as everything depends what RFC5555 really needs.
-- 
kivinen@iki.fi

From kivinen@iki.fi  Mon Jan 25 03:47:43 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EC8D3A6995 for ; Mon, 25 Jan 2010 03:47:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9EKTjlmY0Lt for ; Mon, 25 Jan 2010 03:47:42 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 2E9673A698F for ; Mon, 25 Jan 2010 03:47:41 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0PBlgQo004150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 13:47:42 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0PBlg7Q009511; Mon, 25 Jan 2010 13:47:42 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19293.34014.214220.682548@fireball.kivinen.iki.fi>
Date: Mon, 25 Jan 2010 13:47:42 +0200
From: Tero Kivinen 
To: "Valery Smyslov" 
In-Reply-To: <39AFF7414AB347EA89ADAE7E6053E9DC@trustworks.com>
References:  <39AFF7414AB347EA89ADAE7E6053E9DC@trustworks.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 1 min
X-Total-Time: 1 min
Cc: IPsecme WG , Yoav Nir 
Subject: Re: [IPsec] Closing some of the open tickets for IKEv2bis
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2010 11:47:43 -0000

Valery Smyslov writes:
> I would suugest replacing current text from draft-07:
> ========================================================
>    For ESP and AH, a single Child SA negotiation results in two security
>    associations (one in each direction).  Keying material MUST be taken
>    from the expanded KEYMAT in the following order:
> 
>    o  The encryption key (if any) for the SA carrying data from the
>       initiator to the responder.
> 
>    o  The authentication key (if any) for the SA carrying data from the
>       initiator to the responder.
> 
>    o  The encryption key (if any) for the SA carrying data from the
>       responder to the initiator.
> 
>    o  The authentication key (if any) for the SA carrying data from the
>       responder to the initiator.
> ========================================================
> 
> with the following:
> ========================================================
>    A single CHILD_SA negotiation may result in multiple security
>    associations.  ESP and AH SAs exist in pairs (one in each direction),
>    so two SAs are created in a single Child SA negotiation for them.
>    Furthermore, Child SA negotiation may include some future IPsec
> protocol(s)
>    in addition to (or instead of) ESP or AH (e.g., ROHC_INTEG).
>    In any case, keying material for each child SA MUST be taken from the
>    expanded KEYMAT in the following order:
> 
>    o  All keys for SAs carrying data from the initiator to the responder
>       are taken before SAs going in the reverse direction.
> 
>    o  If multiple IPsec protocols are negotiated, keying material is
>       taken in the order in which the protocol headers will appear in
>       the encapsulated packet.
> 
>    If IPsec protocol requires multiple keys, the order in which they are
> derived
>    from SA's keyng material MUST be described in protocol specification. For
> ESP
>    and AH [IPSECARCH] defines the order, namely: the encryption key (if any)
>    MUST be taken from the first bits and the integrity key (if any) MUST be
> taken
>    from the remaining bits.
> ========================================================

That change looks fine for me.
-- 
kivinen@iki.fi

From ynir@checkpoint.com  Mon Jan 25 03:54:11 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 574973A67CF for ; Mon, 25 Jan 2010 03:54:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level: 
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdog5Py7VPDG for ; Mon, 25 Jan 2010 03:54:10 -0800 (PST)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 21C2E3A67EC for ; Mon, 25 Jan 2010 03:54:10 -0800 (PST)
X-CheckPoint: {4B5D83C8-10003-14201DC2-FFFF}
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 1114829C06F; Mon, 25 Jan 2010 13:54:15 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id D8B4F29C00C; Mon, 25 Jan 2010 13:54:14 +0200 (IST)
X-CheckPoint: {4B5D83C7-10000-14201DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0PBsET7018287; Mon, 25 Jan 2010 13:54:14 +0200 (IST)
X-CheckPoint: {4B5D8670-0-1B201DC2-5FFFF}
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 25 Jan 2010 13:54:28 +0200
From: Yoav Nir 
To: Tero Kivinen 
Date: Mon, 25 Jan 2010 13:54:05 +0200
Thread-Topic: [IPsec] Closing some of the open tickets for IKEv2bis
Thread-Index: AcqdtSWB9BPrA9bzQSy/q8EnAx52Mg==
Message-ID: 
References:  <19293.33798.66951.414633@fireball.kivinen.iki.fi>
In-Reply-To: <19293.33798.66951.414633@fireball.kivinen.iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IPsecme WG 
Subject: Re: [IPsec] Closing some of the open tickets for IKEv2bis
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2010 11:54:11 -0000

On Jan 25, 2010, at 1:44 PM, Tero Kivinen wrote:

> Yoav Nir writes:
>=20
>> Issue #141 - Silently deleting the Child SA after a CHILD_SA_NOT_FOUND
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> Section 2.25: "A peer that receives a CHILD_SA_NOT_FOUND
>> notification SHOULD silently delete the Child SA": Is this really
>> necessary? I think this notification should only occur in cases where
>> DELETE payload for this Child SA pair has already been sent, and
>> probably has been processed already by the time the CHILD_SA_NOT_FOUND
>> notification is received.
>>=20
>> No responses were received for this.
>=20
> I proposed new text for this:
>=20
> http://www.ietf.org/mail-archive/web/ipsec/current/msg05695.html
>=20
>> My opinion is that CHILD_SA_NOT_FOUND will usually not occur at all.
>> Even if lifetime is the same on both peers, rekeying is always done
>> earlier than deleting (for example, if your SAs last 1 hour, you
>> might rekey at 58 minutes, but only delete after 60 minmutes), so
>> collisions of rekey and delete will be rare. Because of this, I
>> believe that the CHILD_SA_NOT_FOUND will stem from some mismatch in
>> the SAD between the two peers. Yes, this probably indicates a bug
>> somewhere, but these things do happen. I believe the text should
>> stay, as it clarifies that the peer does not need to create a new
>> INFORMATIONAL exchange with a DELETE payload to discard. In fact the
>> text already has in brackets "(if it still exists)"
>=20
> That bracketed part was added to solve this #141.=20
>=20
>> If anyone else has comments about this issue, please raise them NOW,
>> because we are going to close this in a few days.
>=20
> So I think this issue can already be closed, as the at least from my
> point of view the fix has already been added to the -07 version.=20

Thanks. Closed.


From kivinen@iki.fi  Mon Jan 25 04:33:06 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C8A23A67EC for ; Mon, 25 Jan 2010 04:33:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.199
X-Spam-Level: 
X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[AWL=-1.400, BAYES_00=-2.599, SARE_BAYES_7x5=0.8, SARE_BAYES_8x5=0.8, SARE_BAYES_9x5=1.2]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFOaDxLEbrv3 for ; Mon, 25 Jan 2010 04:33:05 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id D3DD53A659C for ; Mon, 25 Jan 2010 04:33:04 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0PCX1eZ020852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 14:33:01 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0PCX1DV018828; Mon, 25 Jan 2010 14:33:01 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19293.36733.57362.733749@fireball.kivinen.iki.fi>
Date: Mon, 25 Jan 2010 14:33:01 +0200
From: Tero Kivinen 
To: Yoav Nir 
In-Reply-To: <659E83FA-0A21-4DE6-88C1-5D67A1C78F68@checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A221F3@il-ex01.ad.checkpoint.com> <659E83FA-0A21-4DE6-88C1-5D67A1C78F68@checkpoint.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 16 min
X-Total-Time: 15 min
Cc: "ipsec@ietf.org" 
Subject: Re: [IPsec] Issue #157: Illustrate the SA payload with a diagram
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2010 12:33:06 -0000

Yoav Nir writes:
> I'm sorry I just noticed this, but is this even allowed?  Can you
> include multiple key length attributes in the same transform?

Yes, you are right, you cannot include multiple key length attributes,
as they would be AND for all of them. So yes, they need to be separate
transform each of them. 

Here is my fixed proposal picture:
----------------------------------------------------------------------

                          SA Payload
                              |
           +------------------+---------------------------+
           |                                              |
           |                                              |
       Proposal #1                                    Proposal #2
   Proto ID = ESP (3)                             Proto ID = ESP (3)
     SPI size = 4                                   SPI size = 4
     7 transforms                                   4 transforms
   SPI = 0x95903423                               SPI = 0x12345678
           |                                              |
  +------+-+----+------+------+------+------+      +------+------+------+
  |      |      |      |      |      |      |      |      |      |      |
 Trans  Trans  Trans  Trans  Trans  Trans  Trans  Trans  Trans  Trans  Trans
 form   form   form   form   form   form   form   form   form   form   form
 ENCR   INTEG  ENCR   INTEG  ENCR    ESN   ESN    ENCR   ESN    ENCR   ESN
 ENCR   AUTH   ENCR   AUTH   ENCR    No    Use    AES-   No     AES-   Use
 _AES   _HMAC  _AES   _AES   _AES    ESN   ESN    GCM    ESN    GCM    ESN
 _CBC   _SHA1  _CBC   _XCBC  _CBC     0     1     w/8     0     w/8     1
   |    _96      |    _96      |                  octet         octet
   |             |             |                  ICV           ICV
   |             |             |                   |             |
   |             |             |                   |             |
Attribute     Attribute     Attribute           Attribute     Attribute
Key Length    Key Length    Key Length          Key Length    Key Length
   128           192           256                 128           256

----------------------------------------------------------------------

>                 The initiator of an exchange MUST check that the
>    accepted offer is consistent with one of its proposals, and if not
>    that response MUST be rejected.
> 
> BTW: how do you reject a response?

Silently drop the negotiation (or just the packet if this is
IKE_SA_INIT) with the peer, as it is clearly not following the
specification, and this is not a problem that will be fixed by
changing configuration or similar, it does require software update of
the other end.
-- 
kivinen@iki.fi

From svanru@gmail.com  Mon Jan 25 23:52:38 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16CFB3A6895 for ; Mon, 25 Jan 2010 23:52:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.738
X-Spam-Level: 
X-Spam-Status: No, score=-0.738 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_05=-1.11, XMAILER_MIMEOLE_OL_7533E=0.513]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCNYqLvrKy2y for ; Mon, 25 Jan 2010 23:52:37 -0800 (PST)
Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 063D03A6879 for ; Mon, 25 Jan 2010 23:52:36 -0800 (PST)
Received: by ey-out-2122.google.com with SMTP id 22so1130106eye.51 for ; Mon, 25 Jan 2010 23:52:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:subject :date:mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:x-mailer:x-mimeole; bh=NE1h3tzIt6af8XxO+IAIFJcyHlA+lvXDWsnLbNdv4Ig=; b=K61qYvPVhldnOkv9Ge2JDLKU+cVu1XGn0PjLBQBsz8wJg7tw8rOaJP+NXj86w6DwiM 31BtPNSwnvu1D8diCTt780e6KG/tX3i/QHsmcDIk2BnK48PeNu63JMA1Y0EoHf0QApal 0CrHC/aHg+G6f9crOD6eKCGZzJxHwdPKfnSEA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:mime-version:content-type :content-transfer-encoding:x-priority:x-msmail-priority:x-mailer :x-mimeole; b=mxyEuJUzqAIKcnqk5ePozGld4MpJdecNFQkN9inTFJ5U4H6Lju4LoEyiRX1/qektxe 0IqUaJCgvEIVDLibuqotgKqACCVxQnedv5gXB8TxG6KZdDmcaBkf9p9k2px//CzSDFYJ CYC/fZuCB/9SYEKDtXpCOZRnzmxcgqjsEsBBo=
Received: by 10.213.46.12 with SMTP id h12mr504257ebf.39.1264492361275; Mon, 25 Jan 2010 23:52:41 -0800 (PST)
Received: from svanpc ([82.138.51.4]) by mx.google.com with ESMTPS id 16sm5049807ewy.14.2010.01.25.23.52.39 (version=SSLv3 cipher=RC4-MD5); Mon, 25 Jan 2010 23:52:40 -0800 (PST)
Message-ID: 
From: "Valery Smyslov" 
To: 
Date: Tue, 26 Jan 2010 10:53:31 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4963.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700
Subject: [IPsec] IKEv2-bis, conformance requirements
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2010 07:52:38 -0000

Section 4 lists conformance requirements for IKEv2 implementations.

First, the following text:

   Every implementation MUST be capable of doing four-message
   IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE,
   one for ESP or AH).  

is formally incorrect, because IKE_AUTH results in two child SAs - one in each direction.
Moreover, AH support is purely optional, so why is it here? I suggest to rephrase:

   Every implementation MUST be capable of doing four-message
   IKE_SA_INIT and IKE_AUTH exchanges establishing one SA for IKE,
   and a pair SAs for ESP.  


Then, paragraphs:

   A minimal IPv4 responder implementation will ignore the contents of
   the CP payload except to determine that it includes an
   INTERNAL_IP4_ADDRESS attribute and will respond with the address and
   other related attributes regardless of whether the initiator
   requested them.

   A minimal IPv4 initiator will generate a CP payload containing only
   an INTERNAL_IP4_ADDRESS attribute and will parse the response
   ignoring attributes it does not know how to use.

seem just to repeat what is said in previous paragraph. I suggest to remove them.


And last (but not least). THe following requrements:

   For an implementation to be called conforming to this specification,
   it MUST be possible to configure it to accept the following:

   o  PKIX Certificates containing and signed by RSA keys of size 1024
      or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN,
      ID_RFC822_ADDR, or ID_DER_ASN1_DN.

   o  Shared key authentication where the ID passed is any of ID_KEY_ID,
      ID_FQDN, or ID_RFC822_ADDR.

   o  Authentication where the responder is authenticated using PKIX
      Certificates and the initiator is authenticated using shared key
      authentication.

suggest that every implementation MUST support both RSA PKIX certificates
and preshared key. Isn't it too strong requirement?

1. Why to pay so much attention to "minimal IKEv2 implementation"
    lacking some not-so-difficult-to-implement functions, if we still
    require it to have full PKIX support? I see no logic here.
    PKIX support requires quite a lot of code and resources, so making 
    "IPsec garage opener" becomes problematic.

2. Some implementations may have pluggable crypto modules
    (or use external tokens for authentication), so it may not have 
    RSA at all, while having all public key authentication support for other 
    algorithms. Or implementation may elect not to support 1024 bits RSA keys 
    as not so strong. Do such implementations become non-conformant?


Is it possible to lower those requirements from MUST to SHOULD?


Regards,
Valery Smyslov.




From kivinen@iki.fi  Tue Jan 26 01:15:43 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F3BF3A68B3 for ; Tue, 26 Jan 2010 01:15:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.424
X-Spam-Level: 
X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0zYQPQjE+0X for ; Tue, 26 Jan 2010 01:15:42 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id D08733A6405 for ; Tue, 26 Jan 2010 01:15:41 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0Q9FjkW003988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jan 2010 11:15:45 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0Q9Fi0I021385; Tue, 26 Jan 2010 11:15:44 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19294.45760.751872.906840@fireball.kivinen.iki.fi>
Date: Tue, 26 Jan 2010 11:15:44 +0200
From: Tero Kivinen 
To: "Valery Smyslov" 
In-Reply-To: 
References: 
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 12 min
X-Total-Time: 13 min
Cc: ipsec@ietf.org
Subject: [IPsec]  IKEv2-bis, conformance requirements
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2010 09:15:43 -0000

Valery Smyslov writes:
> Section 4 lists conformance requirements for IKEv2 implementations.
> 
> First, the following text:
> 
>    Every implementation MUST be capable of doing four-message
>    IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE,
>    one for ESP or AH).  
> 
> is formally incorrect, because IKE_AUTH results in two child SAs -
> one in each direction. Moreover, AH support is purely optional, so
> why is it here? I suggest to rephrase:
> 
>    Every implementation MUST be capable of doing four-message
>    IKE_SA_INIT and IKE_AUTH exchanges establishing one SA for IKE,
>    and a pair SAs for ESP.  

This change looks good to me.

> Then, paragraphs:
> 
>    A minimal IPv4 responder implementation will ignore the contents of
>    the CP payload except to determine that it includes an
>    INTERNAL_IP4_ADDRESS attribute and will respond with the address and
>    other related attributes regardless of whether the initiator
>    requested them.
> 
>    A minimal IPv4 initiator will generate a CP payload containing only
>    an INTERNAL_IP4_ADDRESS attribute and will parse the response
>    ignoring attributes it does not know how to use.
> 
> seem just to repeat what is said in previous paragraph. I suggest to
> remove them.

Yes, they just repeat what could be also seen from the generic text,
but they do agree on the same thing and I think they clarify (at least
a bit) what are the minimal requirements. 

> And last (but not least). THe following requrements:
> 
>    For an implementation to be called conforming to this specification,
>    it MUST be possible to configure it to accept the following:
> 
>    o  PKIX Certificates containing and signed by RSA keys of size 1024
>       or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN,
>       ID_RFC822_ADDR, or ID_DER_ASN1_DN.
> 
>    o  Shared key authentication where the ID passed is any of ID_KEY_ID,
>       ID_FQDN, or ID_RFC822_ADDR.
> 
>    o  Authentication where the responder is authenticated using PKIX
>       Certificates and the initiator is authenticated using shared key
>       authentication.
> 
> suggest that every implementation MUST support both RSA PKIX certificates
> and preshared key. Isn't it too strong requirement?
> 
> 1. Why to pay so much attention to "minimal IKEv2 implementation"
>     lacking some not-so-difficult-to-implement functions, if we still
>     require it to have full PKIX support? I see no logic here.
>     PKIX support requires quite a lot of code and resources, so making 
>     "IPsec garage opener" becomes problematic.
> 
> 2. Some implementations may have pluggable crypto modules (or use
>     external tokens for authentication), so it may not have RSA at
>     all, while having all public key authentication support for
>     other algorithms. Or implementation may elect not to support
>     1024 bits RSA keys as not so strong. Do such implementations
>     become non-conformant?
> 
> 
> Is it possible to lower those requirements from MUST to SHOULD?

We need at least one "MUST to implement" authentication methods, so we
know two complient implementations can talk to each other. Selecting
Shared key authentication would put the limit too low. On the other
hand I agree that full PKIX Certificates support puts the rquirement
bit too high.

On the other hand, does it really matter that your garage door opener
is conformant to the RFC4306 / IKEv2bis. Shouldn't it be enough to say
that your garage door opener is implementing enough IKEv2bis that it
can talk to the conformant IKEv2bis server implementation?

If we want to set one mandatory to implement authentication method I
think the some type of RSA keys is the logical choice. This would not
care whether the RSA keys are in form of RAW RSA keys or whether they
are in form of PKIX Certificate. You can always take the PKIX
Certificate having RSA key and extract the RSA key from there and
configure it to the system which only supports RAW RSA keys. Also you
can take RAW RSA key and make self-signed certificate it using
generally available tools, and if you configure that self-signed
certificate as trusted in your system with suitable ID data, then
other end can use the raw rsa keys and you can use certificates.

Anyways the certificates is mandatory to implement feature of RFC4306,
and I think it should stay there, even when it makes some of those
very minimal garage door openers not following the full spec as they
might use raw rsa keys or even shared keys instead of certificates.

For example section 3.6 also says:

   Implementations MUST be capable of being configured to send and
   accept up to four X.509 certificates in support of authentication,
   and also MUST be capable of being configured to send and accept the
   two Hash and URL formats (with HTTP URLs).  
-- 
kivinen@iki.fi

From ynir@checkpoint.com  Tue Jan 26 01:43:51 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5936C3A67EB for ; Tue, 26 Jan 2010 01:43:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.166
X-Spam-Level: 
X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhaOSKKBkH7r for ; Tue, 26 Jan 2010 01:43:50 -0800 (PST)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id B9BC83A67E3 for ; Tue, 26 Jan 2010 01:43:49 -0800 (PST)
X-CheckPoint: {4B5EB6B5-10000-14201DC2-FFFF}
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 7649629C031; Tue, 26 Jan 2010 11:43:58 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 5AD5F29C017 for ; Tue, 26 Jan 2010 11:43:58 +0200 (IST)
X-CheckPoint: {4B5EB6B4-10000-14201DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0Q9hwT7010714 for ; Tue, 26 Jan 2010 11:43:58 +0200 (IST)
X-CheckPoint: {4B5EB95C-1-1B201DC2-5FFFF}
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 26 Jan 2010 11:44:12 +0200
From: Yoav Nir 
To: IPsecme WG 
Date: Tue, 26 Jan 2010 11:43:48 +0200
Thread-Topic: Closing some more issues for IKEv2bis
Thread-Index: AcqebBzvRZca2ThJTDGVqoTNQZ1fAQ==
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [IPsec] Closing some more issues for IKEv2bis
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2010 09:43:51 -0000

Hi all. Time for another set of issues.


Issue #142 - Difference from RFC 4718 in rekeying IKE SA
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
Section 2.25.2, "If a peer receives a request to delete a Child SA when it =
is currently rekeying the IKE SA, it SHOULD reply as usual, with a Delete p=
ayload." I noticed this is different from whatRFC 4718 recommended, but thi=
s is probably OK, given the other text... (but I still hope this was intent=
ional change :-)

The relevant text in RFC 4718 is in section 5.11.8:
   It seems this situation is tricky to handle correctly.  Our proposal
   is as follows: if a host receives a request to rekey the IKE_SA when
   it has CHILD_SAs in "half-open" state (currently being created or
   rekeyed), it should reply with NO_PROPOSAL_CHOSEN.  If a host
   receives a request to create or rekey a CHILD_SA after it has started
   rekeying the IKE_SA, it should reply with NO_ADDITIONAL_SAS.

   The case where CHILD_SAs are being closed is even worse.  Our
   recommendation is that if a host receives a request to rekey the
   IKE_SA when it has CHILD_SAs in "half-closed" state (currently being
   closed), it should reply with NO_PROPOSAL_CHOSEN.  And if a host
   receives a request to close a CHILD_SA after it has started rekeying
   the IKE_SA, it should reply with an empty Informational response.
   This ensures that at least the other peer will eventually notice that
   the CHILD_SA is still in "half-closed" state and will start a new
   IKE_SA from scratch.

This seems to be a change to bits on the wire, so we would like the group's=
 approval. AFAICT no discussion has taken place so far.



Issue #145 - IKE_SA rekeying wording in 2.8
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Section 2.8, sentence: "Note that, when rekeying..." This is in wrong place=
; the rest of this paragraph is about IKE_SA rekeying, so it should be move=
d to the previous paragraph.
[[ Tero noted this as well, but Paul disagreed, saying that the placement w=
as correct. This needs to be resolved. ]]

I don't really see how this is in the wrong place. The entire paragraph rea=
ds as follows:
   To rekey a Child SA within an existing IKE SA, create a new,
   equivalent SA (see Section 2.17 below), and when the new one is
   established, delete the old one.  Note that, when rekeying, the new
   Child SA SHOULD NOT have different traffic selectors and algorithms
   than the old one.

This is about Child SAs. It's only the next paragraph that talks about IKE =
SAs. I think this should stay where it is. Again, no discussion was spotted=
 on the list.



Issue #144 - Placement of INVALID_KE_PAYLOAD text
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
There are two places that have very similar text about INVALID_KE_PAYLOAD: =
Section 1.3 (for CREATE_CHILD_SA exchange), and Section 2.7 (for IKE_SA_INI=
T exchange). Especially the latter seems a bit strange, everything else in =
that section applies to CREATE_CHILD_SA exchanges, too, but this paragraph =
explicitly applies to IKE_SA_INIT only (although INVALID_KE_PAYLOAD works r=
oughly the same way in CREATE_CHILD_SA, too). Perhaps the text in 2.7 shoul=
d be moved to 1.2?

So the proposal is to move the contents of the penultimate paragraph (below=
) in section 2.7 ("Cryptographic Algorithm Negotiation") to section 1.2 ("I=
nitial Exchanges").  What do you think?

   Since the initiator sends its Diffie-Hellman value in the
   IKE_SA_INIT, it must guess the Diffie-Hellman group that the
   responder will select from its list of supported groups.  If the
   initiator guesses wrong, the responder will respond with a Notify
   payload of type INVALID_KE_PAYLOAD indicating the selected group.  In
   this case, the initiator MUST retry the IKE_SA_INIT with the
   corrected Diffie-Hellman group.  The initiator MUST again propose its
   full set of acceptable cryptographic suites because the rejection
   message was unauthenticated and otherwise an active attacker could
   trick the endpoints into negotiating a weaker suite than a stronger
   one that they both prefer.





Regarding issue #140, we're still waiting for an explanation about how the =
whole transport mode through NAT issue is relevant to RFC 5555.

Yoav




From yaronf@checkpoint.com  Tue Jan 26 02:13:17 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD2253A63EC for ; Tue, 26 Jan 2010 02:13:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.949
X-Spam-Level: 
X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.650,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxxwBQFyJd5S for ; Tue, 26 Jan 2010 02:13:16 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 01F213A67EF for ; Tue, 26 Jan 2010 02:13:15 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0QADNT7015860; Tue, 26 Jan 2010 12:13:23 +0200 (IST)
X-CheckPoint: {4B5EC041-0-1B201DC2-5FFFF}
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 26 Jan 2010 12:13:37 +0200
From: Yaron Sheffer 
To: Tero Kivinen , Valery Smyslov 
Date: Tue, 26 Jan 2010 12:13:34 +0200
Thread-Topic: [IPsec]  IKEv2-bis, conformance requirements
Thread-Index: AcqeaDR2gjEdW+uZR+q2a2BwWTcxdAAA6AjQ
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A8073C@il-ex01.ad.checkpoint.com>
References:  <19294.45760.751872.906840@fireball.kivinen.iki.fi>
In-Reply-To: <19294.45760.751872.906840@fireball.kivinen.iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ipsec@ietf.org" 
Subject: Re: [IPsec] IKEv2-bis, conformance requirements
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2010 10:13:18 -0000

Hi Tero, Valery,

As much as it would be fun to discuss the conformance criteria (personally =
I agree that they are too stringent, and would become even less relevant if=
 we add things like password-based auth), it is out of scope of the IKEv2-b=
is discussion. Referring to the guidelines we agreed upon, http://www.ietf.=
org/mail-archive/web/ipsec/current/msg02958.html, the goal of this document=
 is to *clarify* RFC 4306, not to change any normative language.

Thanks,
	Yaron

> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
> Of Tero Kivinen
> Sent: Tuesday, January 26, 2010 11:16
> To: Valery Smyslov
> Cc: ipsec@ietf.org
> Subject: [IPsec] IKEv2-bis, conformance requirements
>=20
> Valery Smyslov writes:
> > Section 4 lists conformance requirements for IKEv2 implementations.
> >
> > First, the following text:
> >
> >    Every implementation MUST be capable of doing four-message
> >    IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for
> IKE,
> >    one for ESP or AH).
> >
> > is formally incorrect, because IKE_AUTH results in two child SAs -
> > one in each direction. Moreover, AH support is purely optional, so
> > why is it here? I suggest to rephrase:
> >
> >    Every implementation MUST be capable of doing four-message
> >    IKE_SA_INIT and IKE_AUTH exchanges establishing one SA for IKE,
> >    and a pair SAs for ESP.
>=20
> This change looks good to me.
>=20
> > Then, paragraphs:
> >
> >    A minimal IPv4 responder implementation will ignore the contents
> of
> >    the CP payload except to determine that it includes an
> >    INTERNAL_IP4_ADDRESS attribute and will respond with the address
> and
> >    other related attributes regardless of whether the initiator
> >    requested them.
> >
> >    A minimal IPv4 initiator will generate a CP payload containing
> only
> >    an INTERNAL_IP4_ADDRESS attribute and will parse the response
> >    ignoring attributes it does not know how to use.
> >
> > seem just to repeat what is said in previous paragraph. I suggest to
> > remove them.
>=20
> Yes, they just repeat what could be also seen from the generic text,
> but they do agree on the same thing and I think they clarify (at least
> a bit) what are the minimal requirements.
>=20
> > And last (but not least). THe following requrements:
> >
> >    For an implementation to be called conforming to this
> specification,
> >    it MUST be possible to configure it to accept the following:
> >
> >    o  PKIX Certificates containing and signed by RSA keys of size
> 1024
> >       or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN,
> >       ID_RFC822_ADDR, or ID_DER_ASN1_DN.
> >
> >    o  Shared key authentication where the ID passed is any of
> ID_KEY_ID,
> >       ID_FQDN, or ID_RFC822_ADDR.
> >
> >    o  Authentication where the responder is authenticated using PKIX
> >       Certificates and the initiator is authenticated using shared
> key
> >       authentication.
> >
> > suggest that every implementation MUST support both RSA PKIX
> certificates
> > and preshared key. Isn't it too strong requirement?
> >
> > 1. Why to pay so much attention to "minimal IKEv2 implementation"
> >     lacking some not-so-difficult-to-implement functions, if we still
> >     require it to have full PKIX support? I see no logic here.
> >     PKIX support requires quite a lot of code and resources, so
> making
> >     "IPsec garage opener" becomes problematic.
> >
> > 2. Some implementations may have pluggable crypto modules (or use
> >     external tokens for authentication), so it may not have RSA at
> >     all, while having all public key authentication support for
> >     other algorithms. Or implementation may elect not to support
> >     1024 bits RSA keys as not so strong. Do such implementations
> >     become non-conformant?
> >
> >
> > Is it possible to lower those requirements from MUST to SHOULD?
>=20
> We need at least one "MUST to implement" authentication methods, so we
> know two complient implementations can talk to each other. Selecting
> Shared key authentication would put the limit too low. On the other
> hand I agree that full PKIX Certificates support puts the rquirement
> bit too high.
>=20
> On the other hand, does it really matter that your garage door opener
> is conformant to the RFC4306 / IKEv2bis. Shouldn't it be enough to say
> that your garage door opener is implementing enough IKEv2bis that it
> can talk to the conformant IKEv2bis server implementation?
>=20
> If we want to set one mandatory to implement authentication method I
> think the some type of RSA keys is the logical choice. This would not
> care whether the RSA keys are in form of RAW RSA keys or whether they
> are in form of PKIX Certificate. You can always take the PKIX
> Certificate having RSA key and extract the RSA key from there and
> configure it to the system which only supports RAW RSA keys. Also you
> can take RAW RSA key and make self-signed certificate it using
> generally available tools, and if you configure that self-signed
> certificate as trusted in your system with suitable ID data, then
> other end can use the raw rsa keys and you can use certificates.
>=20
> Anyways the certificates is mandatory to implement feature of RFC4306,
> and I think it should stay there, even when it makes some of those
> very minimal garage door openers not following the full spec as they
> might use raw rsa keys or even shared keys instead of certificates.
>=20
> For example section 3.6 also says:
>=20
>    Implementations MUST be capable of being configured to send and
>    accept up to four X.509 certificates in support of authentication,
>    and also MUST be capable of being configured to send and accept the
>    two Hash and URL formats (with HTTP URLs).
> --
> kivinen@iki.fi
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>=20
> Scanned by Check Point Total Security Gateway.

From Pasi.Eronen@nokia.com  Tue Jan 26 02:27:57 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D3283A67EF for ; Tue, 26 Jan 2010 02:27:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.638
X-Spam-Level: 
X-Spam-Status: No, score=-5.638 tagged_above=-999 required=5 tests=[AWL=0.961,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDveVh10Oj9C for ; Tue, 26 Jan 2010 02:27:56 -0800 (PST)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 9507A3A63EC for ; Tue, 26 Jan 2010 02:27:56 -0800 (PST)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0QAS36p002142; Tue, 26 Jan 2010 04:28:04 -0600
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 26 Jan 2010 12:27:55 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 26 Jan 2010 12:27:51 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Tue, 26 Jan 2010 11:27:50 +0100
From: 
To: , 
Date: Tue, 26 Jan 2010 11:27:49 +0100
Thread-Topic: [IPsec] Issue #156: SHOULD generate and accept which types?
Thread-Index: Acqba+fC/wTt+ngyTmWFAdymrIz03ADBc0pQ
Message-ID: <808FD6E27AD4884E94820BC333B2DB775841199BA2@NOK-EUMSG-01.mgdnok.nokia.com>
References:    <19289.30143.562354.48214@fireball.kivinen.iki.fi> <7ccecf671001220234v2276f900t3460e5dfb776d837@mail.gmail.com> <19289.36842.223655.321621@fireball.kivinen.iki.fi> <7ccecf671001220514w1af70d08m9eea22863126c0a5@mail.gmail.com> <0359F1DF4A124123AC37E5CE6F58F420@trustworks.com>
In-Reply-To: <0359F1DF4A124123AC37E5CE6F58F420@trustworks.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 26 Jan 2010 10:27:51.0172 (UTC) FILETIME=[36866C40:01CA9E72]
X-Nokia-AV: Clean
Subject: Re: [IPsec] Issue #156: SHOULD generate and accept which types?
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2010 10:27:57 -0000

Valery Smyslov wrote:

> And I want to raise one more issue. Section 4 mandates support
> for both PKIX and preshared key for conformant implementation.
> Isnt't it too strong requirement?


This requirement has been in the document for 4+ years.=20

Unless there is concrete evidence of multiple implementors
encountering difficulties with it (and not just hypothetical=20
garage door openers), I would propose *not* re-visiting this=20
topic at this time.

Best regards,
Pasi
(not wearing any hats)

From Pasi.Eronen@nokia.com  Tue Jan 26 02:34:04 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3D973A6828 for ; Tue, 26 Jan 2010 02:34:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.318
X-Spam-Level: 
X-Spam-Status: No, score=-4.318 tagged_above=-999 required=5 tests=[AWL=-0.519, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_BAYES_7x5=0.8, SARE_BAYES_8x5=0.8, SARE_BAYES_9x5=1.2]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiSTUimkKAZF for ; Tue, 26 Jan 2010 02:34:02 -0800 (PST)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id B4B573A63EC for ; Tue, 26 Jan 2010 02:34:02 -0800 (PST)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0QAXqgN007189; Tue, 26 Jan 2010 04:34:04 -0600
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 26 Jan 2010 12:34:01 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 26 Jan 2010 12:33:56 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Tue, 26 Jan 2010 11:33:55 +0100
From: 
To: , 
Date: Tue, 26 Jan 2010 11:33:54 +0100
Thread-Topic: [IPsec] Issue #157: Illustrate the SA payload with a diagram
Thread-Index: Acqdup6oW4qSKy/JTBSfXMfQpfiFjgAuDKJw
Message-ID: <808FD6E27AD4884E94820BC333B2DB775841199BB9@NOK-EUMSG-01.mgdnok.nokia.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A221F3@il-ex01.ad.checkpoint.com> <659E83FA-0A21-4DE6-88C1-5D67A1C78F68@checkpoint.com> <19293.36733.57362.733749@fireball.kivinen.iki.fi>
In-Reply-To: <19293.36733.57362.733749@fireball.kivinen.iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 26 Jan 2010 10:33:56.0269 (UTC) FILETIME=[1023CDD0:01CA9E73]
X-Nokia-AV: Clean
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Issue #157: Illustrate the SA payload with a diagram
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2010 10:34:04 -0000

Hi Tero,

This picture looks correct to me.

Best regards,
Pasi

> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
> Of ext Tero Kivinen
> Sent: 25 January, 2010 14:33
> To: Yoav Nir
> Cc: ipsec@ietf.org
> Subject: Re: [IPsec] Issue #157: Illustrate the SA payload with a
> diagram
>=20
> Yoav Nir writes:
> > I'm sorry I just noticed this, but is this even allowed?  Can you
> > include multiple key length attributes in the same transform?
>=20
> Yes, you are right, you cannot include multiple key length attributes,
> as they would be AND for all of them. So yes, they need to be separate
> transform each of them.
>=20
> Here is my fixed proposal picture:
> ----------------------------------------------------------------------
>=20
>                           SA Payload
>                               |
>            +------------------+---------------------------+
>            |                                              |
>            |                                              |
>        Proposal #1                                    Proposal #2
>    Proto ID =3D ESP (3)                             Proto ID =3D ESP (3)
>      SPI size =3D 4                                   SPI size =3D 4
>      7 transforms                                   4 transforms
>    SPI =3D 0x95903423                               SPI =3D 0x12345678
>            |                                              |
>   +------+-+----+------+------+------+------+      +------+------+-----
> -+
>   |      |      |      |      |      |      |      |      |      |
> |
>  Trans  Trans  Trans  Trans  Trans  Trans  Trans  Trans  Trans  Trans
> Trans
>  form   form   form   form   form   form   form   form   form   form
> form
>  ENCR   INTEG  ENCR   INTEG  ENCR    ESN   ESN    ENCR   ESN    ENCR
> ESN
>  ENCR   AUTH   ENCR   AUTH   ENCR    No    Use    AES-   No     AES-
> Use
>  _AES   _HMAC  _AES   _AES   _AES    ESN   ESN    GCM    ESN    GCM
> ESN
>  _CBC   _SHA1  _CBC   _XCBC  _CBC     0     1     w/8     0     w/8
> 1
>    |    _96      |    _96      |                  octet         octet
>    |             |             |                  ICV           ICV
>    |             |             |                   |             |
>    |             |             |                   |             |
> Attribute     Attribute     Attribute           Attribute     Attribute
> Key Length    Key Length    Key Length          Key Length    Key
> Length
>    128           192           256                 128           256
>=20
> ----------------------------------------------------------------------
>=20
> >                 The initiator of an exchange MUST check that the
> >    accepted offer is consistent with one of its proposals, and if not
> >    that response MUST be rejected.
> >
> > BTW: how do you reject a response?
>=20
> Silently drop the negotiation (or just the packet if this is
> IKE_SA_INIT) with the peer, as it is clearly not following the
> specification, and this is not a problem that will be fixed by
> changing configuration or similar, it does require software update of
> the other end.
> --
> kivinen@iki.fi
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

From Pasi.Eronen@nokia.com  Tue Jan 26 02:39:36 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 057E43A68F7 for ; Tue, 26 Jan 2010 02:39:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.678
X-Spam-Level: 
X-Spam-Status: No, score=-5.678 tagged_above=-999 required=5 tests=[AWL=0.921,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cH9hKqQ0WGYZ for ; Tue, 26 Jan 2010 02:39:35 -0800 (PST)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id D1B443A68C9 for ; Tue, 26 Jan 2010 02:39:34 -0800 (PST)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0QAdcPc030559; Tue, 26 Jan 2010 12:39:42 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 26 Jan 2010 12:38:59 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 26 Jan 2010 12:38:59 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 26 Jan 2010 11:38:47 +0100
From: 
To: 
Date: Tue, 26 Jan 2010 11:38:45 +0100
Thread-Topic: RFC5555 and Section 2.23.1 (was: [IPsec] IKEv2bis, comments about sections 1-2)
Thread-Index: AcqY+E+ldeEtiuntQQKonJVu5Uu9hQFetW6w
Message-ID: <808FD6E27AD4884E94820BC333B2DB775841199BC3@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB7758410A954B@NOK-EUMSG-01.mgdnok.nokia.com> <19285.37771.259456.852530@fireball.kivinen.iki.fi>
In-Reply-To: <19285.37771.259456.852530@fireball.kivinen.iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 26 Jan 2010 10:38:59.0224 (UTC) FILETIME=[C4B71180:01CA9E73]
X-Nokia-AV: Clean
Cc: ipsec@ietf.org
Subject: Re: [IPsec] RFC5555 and Section 2.23.1 (was:  IKEv2bis, comments about sections 1-2)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2010 10:39:36 -0000

Tero Kivinen wrote:

> Pasi.Eronen@nokia.com writes:
> > - Section 2.23.1: If the responder doesn't find SPD entry for
> > transport mode with the modified traffic selectors, and does a lookup
> > with the original selectors, if it finds an entry for transport mode,
> > can it use it?
>=20
> I do not think it can use the transport mode SA using original
> selectors. This of course depends which traffic selectors are used
> when installing the SA data to SAD. If those original selectors are
> used then incoming packets will be dropped because they do not match
> the selectors for the SA (RFC4301 section 5.2, step 5).

Actually, the incoming packets could actually match the selectors if
they somehow take a different "route" than the IKEv2 packets, and
bypass the NAT.

(This is what's happening in RFC5555; see below)

> If modified selectors is used when installing SA then those selectors
> were not matched against the SPD, and this can cause spoofing attacks.

I agree this would violate the policy.

> > (And would that screw up the initiator processing of
> > the reply?
>=20
> That again depends which traffic selectors are returned. If original
> traffic selectors are returned then initiator do not get information
> about the original addresses, thus it cannot do incremental checksum
> updating. Also depending what kind of checks initiator does, it might
> cause initiator to fail the reply processing.
>=20
> > Unfortunately,this question is relevant for RFC 5555...)
>=20
> What kind of things does the RFC5555 require?

Basically, it's assuming that even if you're running IKEv2 over IPv4
(and that IPv4 address is NATted), you can still negotiate transport
mode SAs for IPv6 addresses (which won't get NATted).

Best regards,
Pasi

From Pasi.Eronen@nokia.com  Tue Jan 26 02:41:36 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27F3F3A68FF for ; Tue, 26 Jan 2010 02:41:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.744
X-Spam-Level: 
X-Spam-Status: No, score=-5.744 tagged_above=-999 required=5 tests=[AWL=0.855,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id er2qolCH-Pnh for ; Tue, 26 Jan 2010 02:41:35 -0800 (PST)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 907373A68C9 for ; Tue, 26 Jan 2010 02:41:34 -0800 (PST)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0QAfcYw007704; Tue, 26 Jan 2010 12:41:41 +0200
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 26 Jan 2010 12:41:40 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 26 Jan 2010 12:41:28 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Tue, 26 Jan 2010 11:41:27 +0100
From: 
To: 
Date: Tue, 26 Jan 2010 11:41:26 +0100
Thread-Topic: CHILD_SA_NOT_FOUND error (was: [IPsec] IKEv2bis, comments about sections 1-2) (#142)
Thread-Index: AcqY+W/b0Ujz695CSwq1ThDa/IwLOQFelhrg
Message-ID: <808FD6E27AD4884E94820BC333B2DB775841199BCC@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB7758410A954B@NOK-EUMSG-01.mgdnok.nokia.com> <19285.38261.379439.873648@fireball.kivinen.iki.fi>
In-Reply-To: <19285.38261.379439.873648@fireball.kivinen.iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 26 Jan 2010 10:41:28.0117 (UTC) FILETIME=[1D765650:01CA9E74]
X-Nokia-AV: Clean
Cc: ipsec@ietf.org
Subject: Re: [IPsec] CHILD_SA_NOT_FOUND error (was:  IKEv2bis, comments about sections 1-2) (#142)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2010 10:41:36 -0000

Tero Kivinen wrote:
>=20
> Pasi.Eronen@nokia.com writes:
> > - Section 2.25: "A peer that receives a CHILD_SA_NOT_FOUND
> > notification SHOULD silently delete the Child SA": Is this really
> > necessary? I think this notification should only occur in cases where
> > DELETE payload for this Child SA pair has already been sent, and
> > probably has been processed already by the time the
> > CHILD_SA_NOT_FOUND
> > notification is received.
>=20
> I agree on that, and I proposed new wording for that:
>=20
>    A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer
>    receives a request to rekey a Child SA that does not exist A peer
>    that receives a CHILD_SA_NOT_FOUND notification SHOULD silently
>    delete the Child SA (if it still exists, as most likely delete
>    notification sent by the other hand has already deleted it) and
>    send a request to create a new Child SA from scratch if such
>    Child SA does not yet exists.

Thanks -- this is much clearer.

> > - Section 2.25.2, "If a peer receives a request to delete a Child
> > SA when it is currently rekeying the IKE SA, it SHOULD reply as
> > usual, with a Delete payload." I noticed this is different from
> > what RFC 4718 recommended, but this is probably OK, given the
> > other text...  (but I still hope this was intentional change :-)
>=20
> This was intentional change.


OK; with this reply, I'm OK with closing issue #142.

Best regards,
Pasi

From Pasi.Eronen@Nokia.com  Tue Jan 26 02:57:09 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B24F93A683E for ; Tue, 26 Jan 2010 02:57:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.801
X-Spam-Level: 
X-Spam-Status: No, score=-5.801 tagged_above=-999 required=5 tests=[AWL=0.798,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhpZOhKVpZ-V for ; Tue, 26 Jan 2010 02:57:08 -0800 (PST)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 6CC473A63EC for ; Tue, 26 Jan 2010 02:57:08 -0800 (PST)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0QAv0E2008965; Tue, 26 Jan 2010 12:57:14 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 26 Jan 2010 12:56:53 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 26 Jan 2010 12:56:53 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 26 Jan 2010 11:56:52 +0100
From: 
To: , 
Date: Tue, 26 Jan 2010 11:56:50 +0100
Thread-Topic: [IPsec] Issue #148: Historical cookie discussion
Thread-Index: AcqaFa/mVW/sp9gcRlG8ZkC79JFV0AEYF+dQ
Message-ID: <808FD6E27AD4884E94820BC333B2DB775841199BF4@NOK-EUMSG-01.mgdnok.nokia.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 26 Jan 2010 10:56:53.0637 (UTC) FILETIME=[451D7B50:01CA9E76]
X-Nokia-AV: Clean
Subject: Re: [IPsec] Issue #148: Historical cookie discussion
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2010 10:57:09 -0000

I don't find current 2.6 confusing, so the path of least effort
would be to leave it as-is. (But I'm not opposed to some editing
if someone is willing to propose text.)
=20
Best regards,
Pasi

> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
> Of ext Paul Hoffman
> Sent: 20 January, 2010 23:02
> To: IPsecme WG
> Subject: [IPsec] Issue #148: Historical cookie discussion
>=20
> In 2.6, first paragraph: the historical discussion going back to the
> previous century is very confusing to a newcomer: instead of saying
> what a cookie is, we tell a story. I suggest to remove this discussion
> or move it to the end of the section.
>=20
> Can we separate the cookie discussion into its own subsection? For two
> reasons: it is an implementation hint, rather than a specification (as
> opposed to the normative text on SPIs earlier in 2.6); and it is not
> very important, given the prevalence of DDos.
>=20
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

From Pasi.Eronen@nokia.com  Tue Jan 26 03:09:55 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E6D03A63EC for ; Tue, 26 Jan 2010 03:09:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.851
X-Spam-Level: 
X-Spam-Status: No, score=-5.851 tagged_above=-999 required=5 tests=[AWL=0.748,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7LmO5N+NhIV for ; Tue, 26 Jan 2010 03:09:54 -0800 (PST)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 43F843A6864 for ; Tue, 26 Jan 2010 03:09:54 -0800 (PST)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0QB9Umd029653; Tue, 26 Jan 2010 13:09:55 +0200
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 26 Jan 2010 13:09:52 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 26 Jan 2010 13:09:47 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Tue, 26 Jan 2010 12:09:46 +0100
From: 
To: , , 
Date: Tue, 26 Jan 2010 12:09:46 +0100
Thread-Topic: [IPsec] IKEv2-bis comments: 2.17 and onwards (#170)
Thread-Index: AcqdV9nbCJQepB94QZuswLUjtB7G2gBH69hw
Message-ID: <808FD6E27AD4884E94820BC333B2DB775841199C1B@NOK-EUMSG-01.mgdnok.nokia.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A804C9@il-ex01.ad.checkpoint.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 26 Jan 2010 11:09:47.0451 (UTC) FILETIME=[125820B0:01CA9E78]
X-Nokia-AV: Clean
Subject: Re: [IPsec] IKEv2-bis comments: 2.17 and onwards (#170)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2010 11:09:55 -0000

Paul Hoffman wrote:

> >B.1 (Group 1): We may want to add: "Use of this group is NOT
> RECOMMENDED."
>=20
> Please open a tracker issue for this. Even though this is obvious, it
> is a tad late to be suggesting new normative language.

This "NOT RECOMMENDED" would belong in an update to RFC 4307,
not this document.

Best regards,
Pasi


From kivinen@iki.fi  Tue Jan 26 03:42:48 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEF8E3A6823 for ; Tue, 26 Jan 2010 03:42:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.443
X-Spam-Level: 
X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VNF2qUfbeXh for ; Tue, 26 Jan 2010 03:42:47 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 175903A6405 for ; Tue, 26 Jan 2010 03:42:46 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0QBgnbQ015998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jan 2010 13:42:49 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0QBgnmA019573; Tue, 26 Jan 2010 13:42:49 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19294.54585.323389.376901@fireball.kivinen.iki.fi>
Date: Tue, 26 Jan 2010 13:42:49 +0200
From: Tero Kivinen 
To: Yoav Nir 
In-Reply-To: 
References: 
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 11 min
X-Total-Time: 14 min
Cc: IPsecme WG 
Subject: [IPsec]  Closing some more issues for IKEv2bis
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2010 11:42:48 -0000

Yoav Nir writes:
> Issue #142 - Difference from RFC 4718 in rekeying IKE SA
> ========================================================
> Section 2.25.2, "If a peer receives a request to delete a Child SA
> when it is currently rekeying the IKE SA, it SHOULD reply as usual,
> with a Delete payload." I noticed this is different from whatRFC
> 4718 recommended, but this is probably OK, given the other text...
> (but I still hope this was intentional change :-) 
> 
> The relevant text in RFC 4718 is in section 5.11.8:
>    It seems this situation is tricky to handle correctly.  Our proposal
>    is as follows: if a host receives a request to rekey the IKE_SA when
>    it has CHILD_SAs in "half-open" state (currently being created or
>    rekeyed), it should reply with NO_PROPOSAL_CHOSEN.  If a host
>    receives a request to create or rekey a CHILD_SA after it has started
>    rekeying the IKE_SA, it should reply with NO_ADDITIONAL_SAS.
> 
>    The case where CHILD_SAs are being closed is even worse.  Our
>    recommendation is that if a host receives a request to rekey the
>    IKE_SA when it has CHILD_SAs in "half-closed" state (currently being
>    closed), it should reply with NO_PROPOSAL_CHOSEN.  And if a host
>    receives a request to close a CHILD_SA after it has started rekeying
>    the IKE_SA, it should reply with an empty Informational response.
>    This ensures that at least the other peer will eventually notice that
>    the CHILD_SA is still in "half-closed" state and will start a new
>    IKE_SA from scratch.
> 
> This seems to be a change to bits on the wire, so we would like the
> group's approval. AFAICT no discussion has taken place so far.

Me and Pasi exchanged few emails about this issue:

http://www.ietf.org/mail-archive/web/ipsec/current/msg05695.html
http://www.ietf.org/mail-archive/web/ipsec/current/msg05817.html

and the final comment from Pasi was:

----------------------------------------------------------------------
> > - Section 2.25.2, "If a peer receives a request to delete a Child
> > SA when it is currently rekeying the IKE SA, it SHOULD reply as
> > usual, with a Delete payload." I noticed this is different from
> > what RFC 4718 recommended, but this is probably OK, given the
> > other text...  (but I still hope this was intentional change :-)
> 
> This was intentional change.


OK; with this reply, I'm OK with closing issue #142.
----------------------------------------------------------------------

> Issue #145 - IKE_SA rekeying wording in 2.8
> ===========================================
> Section 2.8, sentence: "Note that, when rekeying..." This is in
> wrong place; the rest of this paragraph is about IKE_SA rekeying, so
> it should be moved to the previous paragraph. 
> [[ Tero noted this as well, but Paul disagreed, saying that the
> placement was correct. This needs to be resolved. ]] 
> 
> I don't really see how this is in the wrong place. The entire
> paragraph reads as follows: 
>    To rekey a Child SA within an existing IKE SA, create a new,
>    equivalent SA (see Section 2.17 below), and when the new one is
>    established, delete the old one.  Note that, when rekeying, the new
>    Child SA SHOULD NOT have different traffic selectors and algorithms
>    than the old one.
> 
> This is about Child SAs. It's only the next paragraph that talks
> about IKE SAs. I think this should stay where it is. Again, no
> discussion was spotted on the list.

This was already fixed in the draft-ietf-ipsecme-ikev2bis-07.txt:

http://www.ietf.org/mail-archive/web/ipsec/current/msg05710.html

So this issue can be closed.

This issue was originally brought up by Scott C Moonen
(http://www.ietf.org/mail-archive/web/ipsec/current/msg05376.html) in
December, and Paul fixed it already then in his internal draft copy
(http://www.ietf.org/mail-archive/web/ipsec/current/msg05378.html),
and then when both me and Pasi noticed this again in January, he
probably didn't remember that he had already fixed this already and
when he checked his internal draft he didn't find anything wrong with
the text, as he had already fixed it earlier.

> Issue #144 - Placement of INVALID_KE_PAYLOAD text
> =================================================
> There are two places that have very similar text about
> INVALID_KE_PAYLOAD: Section 1.3 (for CREATE_CHILD_SA exchange), and
> Section 2.7 (for IKE_SA_INIT exchange). Especially the latter seems
> a bit strange, everything else in that section applies to
> CREATE_CHILD_SA exchanges, too, but this paragraph explicitly
> applies to IKE_SA_INIT only (although INVALID_KE_PAYLOAD works
> roughly the same way in CREATE_CHILD_SA, too). Perhaps the text in
> 2.7 should be moved to 1.2?
> 
> So the proposal is to move the contents of the penultimate paragraph
> (below) in section 2.7 ("Cryptographic Algorithm Negotiation") to
> section 1.2 ("Initial Exchanges").  What do you think? 
> 
>    Since the initiator sends its Diffie-Hellman value in the
>    IKE_SA_INIT, it must guess the Diffie-Hellman group that the
>    responder will select from its list of supported groups.  If the
>    initiator guesses wrong, the responder will respond with a Notify
>    payload of type INVALID_KE_PAYLOAD indicating the selected group.  In
>    this case, the initiator MUST retry the IKE_SA_INIT with the
>    corrected Diffie-Hellman group.  The initiator MUST again propose its
>    full set of acceptable cryptographic suites because the rejection
>    message was unauthenticated and otherwise an active attacker could
>    trick the endpoints into negotiating a weaker suite than a stronger
>    one that they both prefer.

I think this section can be moved, and it might even be better in the
section 1.2 than in the 2.7. This also means that the reference in the
section 3.10.1 for INVALID_KE_PAYLOAD needs to be updated to point to
section 1.2 after the change too. 

> Regarding issue #140, we're still waiting for an explanation about
> how the whole transport mode through NAT issue is relevant to RFC
> 5555.

Yes.
-- 
kivinen@iki.fi

From kivinen@iki.fi  Tue Jan 26 03:51:02 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4046628C0D7 for ; Tue, 26 Jan 2010 03:51:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.459
X-Spam-Level: 
X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1+WJ3+hewZG for ; Tue, 26 Jan 2010 03:51:01 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 1DFE328C0CE for ; Tue, 26 Jan 2010 03:51:00 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0QBp7Jr021043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jan 2010 13:51:07 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0QBp7Ij019758; Tue, 26 Jan 2010 13:51:07 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19294.55083.300196.793537@fireball.kivinen.iki.fi>
Date: Tue, 26 Jan 2010 13:51:07 +0200
From: Tero Kivinen 
To: 
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB775841199C1B@NOK-EUMSG-01.mgdnok.nokia.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A804C9@il-ex01.ad.checkpoint.com>  <808FD6E27AD4884E94820BC333B2DB775841199C1B@NOK-EUMSG-01.mgdnok.nokia.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 2 min
X-Total-Time: 4 min
Cc: ipsec@ietf.org, paul.hoffman@vpnc.org
Subject: Re: [IPsec] IKEv2-bis comments: 2.17 and onwards (#170)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2010 11:51:02 -0000

Pasi.Eronen@nokia.com writes:
> Paul Hoffman wrote:
> 
> > >B.1 (Group 1): We may want to add: "Use of this group is NOT
> > RECOMMENDED."
> > 
> > Please open a tracker issue for this. Even though this is obvious, it
> > is a tad late to be suggesting new normative language.
> 
> This "NOT RECOMMENDED" would belong in an update to RFC 4307,
> not this document.

The current RFC4306 Security Considerations section already says:

            Group one is for historic purposes only and does not
   provide sufficient strength except for use with DES, which is also
   for historic use only.  

and I would think that group and algorithms which are historic use
only, are also NOT RECOMMENDED...

And yes, I agree it should really be in RFC4307, but the group is
defined here, so word of it not being recommended, might be good idea
in this document too.
-- 
kivinen@iki.fi

From svanru@gmail.com  Tue Jan 26 03:54:53 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8BB128C0E9 for ; Tue, 26 Jan 2010 03:54:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.436
X-Spam-Level: 
X-Spam-Status: No, score=-1.436 tagged_above=-999 required=5 tests=[AWL=0.650,  BAYES_00=-2.599, XMAILER_MIMEOLE_OL_7533E=0.513]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMYvQRzkMXbl for ; Tue, 26 Jan 2010 03:54:53 -0800 (PST)
Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id D2F3F3A6767 for ; Tue, 26 Jan 2010 03:54:52 -0800 (PST)
Received: by ey-out-2122.google.com with SMTP id 22so1178556eye.51 for ; Tue, 26 Jan 2010 03:54:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:cc :references:subject:date:mime-version:content-type :content-transfer-encoding:x-priority:x-msmail-priority:x-mailer :x-mimeole; bh=vxP7ovTbjYkobKUSrQHwnYetVWpqFJdNq6Wv4fyUapA=; b=OPG8v0Ma6ajyoihnG+eEsEyS+IPOj1I1bDprertovwUI+vKkuTqzyoqLFe+DtnPpLw yXDqx9qr4mHBwhoDjwBeSvExX0NAgJ63Haf0uoD/XYjfWuPxfdWcE/yrebV1hPf53niv 26i1wWj64iNMobn9zNntG2iNw3DtyljRhdDbw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=YhvFHKQabPzTdqMW5VfIRWJCiesHQQcnNRmkwEUNXEQkQGsdrXgNBzI8j+64FV2IcQ 7uc6dVsfDgojRpKROrRrnftRFyl5BNQxQs10AgpT3ib6UnNX7LAp/DYerIfbRkx3okSI yRePMsbHl5PMa4H8bG1anNuORDgS8FRz0gM2M=
Received: by 10.213.97.71 with SMTP id k7mr4044992ebn.41.1264506898961; Tue, 26 Jan 2010 03:54:58 -0800 (PST)
Received: from svanpc ([82.138.51.4]) by mx.google.com with ESMTPS id 15sm5185044ewy.8.2010.01.26.03.54.58 (version=SSLv3 cipher=RC4-MD5); Tue, 26 Jan 2010 03:54:58 -0800 (PST)
Message-ID: <9CC869AEA3EB43349410FB827E4642FD@trustworks.com>
From: "Valery Smyslov" 
To: "Tero Kivinen" 
References:  <19294.45760.751872.906840@fireball.kivinen.iki.fi>
Date: Tue, 26 Jan 2010 14:55:50 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4963.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700
Cc: ipsec@ietf.org
Subject: Re: [IPsec] IKEv2-bis, conformance requirements
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2010 11:54:53 -0000

Hi Tero, 

Tero Kivinen writes:
> >    A minimal IPv4 responder implementation will ignore the contents of
> >    the CP payload except to determine that it includes an
> >    INTERNAL_IP4_ADDRESS attribute and will respond with the address and
> >    other related attributes regardless of whether the initiator
> >    requested them.
> > 
> >    A minimal IPv4 initiator will generate a CP payload containing only
> >    an INTERNAL_IP4_ADDRESS attribute and will parse the response
> >    ignoring attributes it does not know how to use.
> > 
> > seem just to repeat what is said in previous paragraph. I suggest to
> > remove them.
> 
> Yes, they just repeat what could be also seen from the generic text,
> but they do agree on the same thing and I think they clarify (at least
> a bit) what are the minimal requirements. 

Then, probably similar paragraphs about minimal IPv6 initiator
and responder behaviour should be added? Otherwise it looks a bit 
out of logic to me: either remove this paragraphs or treat IPv4 and IPv6 equally
and describe IPv6 implementation behaviour to the same extent.

Regards,
Valery Smyslov.



From kivinen@iki.fi  Tue Jan 26 04:14:32 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1905A3A6947 for ; Tue, 26 Jan 2010 04:14:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.472
X-Spam-Level: 
X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUwWfHnC7DNS for ; Tue, 26 Jan 2010 04:14:30 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 5E3A03A693F for ; Tue, 26 Jan 2010 04:14:30 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0QCEas3020701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jan 2010 14:14:36 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0QCEZxp020710; Tue, 26 Jan 2010 14:14:35 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19294.56491.761386.235273@fireball.kivinen.iki.fi>
Date: Tue, 26 Jan 2010 14:14:35 +0200
From: Tero Kivinen 
To: 
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB775841199BC3@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB7758410A954B@NOK-EUMSG-01.mgdnok.nokia.com> <19285.37771.259456.852530@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB775841199BC3@NOK-EUMSG-01.mgdnok.nokia.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 14 min
X-Total-Time: 22 min
Cc: ipsec@ietf.org
Subject: Re: [IPsec] RFC5555 and Section 2.23.1 (was:  IKEv2bis, comments about sections 1-2)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2010 12:14:32 -0000

Pasi.Eronen@nokia.com writes:
> Tero Kivinen wrote:
> 
> > Pasi.Eronen@nokia.com writes:
> > > - Section 2.23.1: If the responder doesn't find SPD entry for
> > > transport mode with the modified traffic selectors, and does a lookup
> > > with the original selectors, if it finds an entry for transport mode,
> > > can it use it?
> > 
> > I do not think it can use the transport mode SA using original
> > selectors. This of course depends which traffic selectors are used
> > when installing the SA data to SAD. If those original selectors are
> > used then incoming packets will be dropped because they do not match
> > the selectors for the SA (RFC4301 section 5.2, step 5).
> 
> Actually, the incoming packets could actually match the selectors if
> they somehow take a different "route" than the IKEv2 packets, and
> bypass the NAT.
> 
> (This is what's happening in RFC5555; see below)
> 
> > If modified selectors is used when installing SA then those selectors
> > were not matched against the SPD, and this can cause spoofing attacks.
> 
> I agree this would violate the policy.
> 
> > > (And would that screw up the initiator processing of
> > > the reply?
> > 
> > That again depends which traffic selectors are returned. If original
> > traffic selectors are returned then initiator do not get information
> > about the original addresses, thus it cannot do incremental checksum
> > updating. Also depending what kind of checks initiator does, it might
> > cause initiator to fail the reply processing.
> > 
> > > Unfortunately,this question is relevant for RFC 5555...)
> > 
> > What kind of things does the RFC5555 require?
> 
> Basically, it's assuming that even if you're running IKEv2 over IPv4
> (and that IPv4 address is NATted), you can still negotiate transport
> mode SAs for IPv6 addresses (which won't get NATted).

Hmm.... Let me see. They have IKEv2 session running over IPv4
addresses, and then they try to create IPsec SA using IPv6 addresses
using transport mode over that IKEv2 SA. How are they going to do it,
as section 2.11 says:

----------------------------------------------------------------------
2.11.  Address and Port Agility

   IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and
   AH associations for the same IP addresses it runs over.
----------------------------------------------------------------------

which usually means that for transport mode the addresses you expect
to se on ESP packets are same as what they were for the IKE packet
too, which is impossible now as the IKEv2 runs over IPv4, but ESP
packets run over IPv6.

Also even if they use packet where src = IP1 (ipv4), and dst = IPN2
(ipv4) and then it is natted twice to src = IPN1 (ipv4) and dst = IP2
(ipv4) (using the picture in section 2.23.1), with traffic selectors:

   TSi = any, any, src-IPv6-address - src-IPv6-address
   TSr = any, any, dst-IPv6-address - dst-IPv6-address

and try to negotiate transport mode using those traffic selectors, I
think most of the implementations will not allow such SA to be
created.

As there is no NAT for the IPv6 addresses, then the SPD lookup based
on the traffic selectors would be fine, but there is no way to know
whether there is NAT between the IPv6 address or not, as we only
tested the presense of NAT for IPv4 addresses.

I think the only easy solution to that kind of problem is to run two
IKEv2 SAs between the peer, one for IPv4 traffic using NAT'ed IPv4
addresses, and another using IPv6 addresses and IPv6 transport mode
traffic.

It seems the RFC5555 is trying to break the section 2.11 rule, and
thinks IKE can be used in such way to create SAs between any
IP-addresses instead between the address over which the IKE SA runs
on.
-- 
kivinen@iki.fi

From svanru@gmail.com  Tue Jan 26 04:37:18 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CEAE3A6948 for ; Tue, 26 Jan 2010 04:37:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.598
X-Spam-Level: 
X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[AWL=0.488,  BAYES_00=-2.599, XMAILER_MIMEOLE_OL_7533E=0.513]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRj9JiPEqcCN for ; Tue, 26 Jan 2010 04:37:17 -0800 (PST)
Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id 19BEB3A695F for ; Tue, 26 Jan 2010 04:37:16 -0800 (PST)
Received: by ewy8 with SMTP id 8so5398797ewy.29 for ; Tue, 26 Jan 2010 04:37:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:references :subject:date:mime-version:content-type:content-transfer-encoding :x-priority:x-msmail-priority:x-mailer:x-mimeole; bh=hoYlSOKZGHnggUJU5u2B5AfpL/yFU/cnppTInEhp9Fc=; b=EkErNAMHQoBHGK04uJiLU/Klu0w0KSgrRcagAVImRrFUESEYVfUVD12J/emYrEFKmK bH0ykTaeT2LBAyv3a9GkJodi+CVQzP3GKXsfFtDgZCMXHbC6A2iaeiXHUHjEa6qSjcBO dLVCjVXf8lnpDMZptmaJsAvd50WvwY4h/AfsU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=q/hXPB7rp/RmQnBwrTZRu4Zu2esb0PTt+HTainkM4OEOZlfkQk2QKA/9zbqSaLkOu7 HXrJQjP+D6MzZSiduH4lTc4V1xOmV/IDIVSktHpgoe4974NAIFWztO2F+kp5hkZuFpRM IxRYyBu7CetlyGPt8y/6G0wpr09RANTJCUiKE=
Received: by 10.213.80.204 with SMTP id u12mr1896321ebk.95.1264509446381; Tue, 26 Jan 2010 04:37:26 -0800 (PST)
Received: from svanpc ([82.138.51.4]) by mx.google.com with ESMTPS id 16sm5198430ewy.6.2010.01.26.04.37.25 (version=SSLv3 cipher=RC4-MD5); Tue, 26 Jan 2010 04:37:25 -0800 (PST)
Message-ID: 
From: "Valery Smyslov" 
To: , 
References: <19289.30143.562354.48214@fireball.kivinen.iki.fi><7ccecf671001220234v2276f900t3460e5dfb776d837@mail.gmail.com><19289.36842.223655.321621@fireball.kivinen.iki.fi><7ccecf671001220514w1af70d08m9eea22863126c0a5@mail.gmail.com> <0359F1DF4A124123AC37E5CE6F58F420@trustworks.com> <808FD6E27AD4884E94820BC333B2DB775841199BA2@NOK-EUMSG-01.mgdnok.nokia.com>
Date: Tue, 26 Jan 2010 15:38:17 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4963.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700
Subject: Re: [IPsec] Issue #156: SHOULD generate and accept which types?
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2010 12:37:18 -0000

Hi Pasi,

Pasi Eronen writes:

> > And I want to raise one more issue. Section 4 mandates support
> > for both PKIX and preshared key for conformant implementation.
> > Isnt't it too strong requirement?
> 
> 
> This requirement has been in the document for 4+ years. 
> 
> Unless there is concrete evidence of multiple implementors
> encountering difficulties with it (and not just hypothetical 
> garage door openers), I would propose *not* re-visiting this 
> topic at this time.

The main problem is not in the requirement for PKIX support per se
(althouth it seems to be too much for small implementation).
The problem is in requirement for particular algorithm - RSA.
I understand, that RSA is widely used, but there may 
be situations when it is unavailable for some reason. 
For example, here in Russia all state organizations 
are not allowed to use RSA and must use only 
GOST 3410-2001 signature algorithm. I suspect the
same situation may take place in other countries as well.

>From my point of view, it is better to move all requirements
for particular algorithm support from RFC4306 to RFC4307,
where most of them already resides. That will allow
building implementations conformant to RFC4306 with
any set of algorithms (as protocol itself is completely
algorithm independent), while RFC4307 will list those
algorithms which will provide "universal" interoperability.

Regards,
Valery Smyslov.



From kivinen@iki.fi  Tue Jan 26 04:39:13 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 746EF3A695A for ; Tue, 26 Jan 2010 04:39:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.482
X-Spam-Level: 
X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9TN2bw5FWuQ for ; Tue, 26 Jan 2010 04:39:12 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id C32583A6957 for ; Tue, 26 Jan 2010 04:39:11 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0QCdKMv027014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jan 2010 14:39:20 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0QCdJCl007967; Tue, 26 Jan 2010 14:39:19 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19294.57975.644452.373951@fireball.kivinen.iki.fi>
Date: Tue, 26 Jan 2010 14:39:19 +0200
From: Tero Kivinen 
To: Paul Hoffman 
In-Reply-To: 
References: <19288.27953.896891.499515@fireball.kivinen.iki.fi> 
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 15 min
X-Total-Time: 17 min
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Comments to draft-ietf-ipsecme-ikev2bis-07.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2010 12:39:13 -0000

Paul Hoffman writes:
> At 5:05 PM +0200 1/21/10, Tero Kivinen wrote:
> 
> All changes made other than the following.
> 
> >----------------------------------------------------------------------
> >
> >Section 2.8.2 there was removed paragraph:
> >
> >	However, there is a twist to the other case where one rekeying
> >	finishes first:
> >
> >and I think some kind of paragraph is needed, as the example given
> >below is not about normal simultaneous IKE SA rekey, but this special
> >case. Now someone might think that the example given is the normal
> >simulatenous IKE SA rekey example.
> 
> Please open a new issue in the tracker and put specific text in it.

Opened ticket #171.

> >The section 1.7 should be more like description of changes, not just
> >listing section numbers with changed text. For example I think it
> >would be better to combine:
> >
> >   In section 1.3.2, changed "The KEi payload SHOULD be included" to be
> >   "The KEi payload MUST be included".  This also lead to changes in
> >   section 2.18.
> >
> >   Section 2.18 requires doing a Diffie-Hellman exchange when rekeying
> >   the IKE_SA.  In theory, RFC 4306 allowed a policy where the Diffie-
> >   Hellman exchange was optional, but this was not useful (or
> >   appropriate) when rekeying the IKE_SA.
> >
> >to one item saying:
> >
> >   Diffie-Hellman exchange is now required for IKE SA rekeys. In
> >   theory, RFC 4306 allowed a policy where the Diffie- Hellman
> >   exchange was optional, but this was not useful (or appropriate)
> >   when rekeying the IKE_SA (section 1.3.2 and section 2.18).
> 
> This difference is not worth the effort of re-writing the whole
> section and possibly losing information.

I do not think we need to rewrite whole section, but I think it would
be worth of cleaning up some of the items to better explain what is
changed, compared to just listing changed section numbers with very
cryptic texts.

And as you pointed out we do not try to include every single change,
only those which are important, meaning if we loose some information
while changing those sections then it is probably ok, as if we do not
notice we are loosing important information then that information we
loose cannot be very important, thus it can be left out anyways.

This is section listing changes happening in otherwhere in the
document, so we cannot really loose real information. Everything here
needs to be something that is already explained somewhere else.

> >----------------------------------------------------------------------
> >
> >For example in 1.7 the point:
> >
> >   This document clarifies the use of the critical flag in Section 2.5.
> >
> >does not help implementors at all, as they now need to go through the
> >old RFC4306 section 2.5 and compare it with the new section 2.5 to
> >find out what was done (and I do not remember that myself, so I need
> >to do that to provide better text for that bullet).
> 
> Clarifications such as this are welcome. Please provide text.

Hmm.. I think this comment is about the this added text in IKEv2bis
(by looking at the diff of section 2.5 between RFC4306 and
draft-ietf-ipsecme-ikev2bis-07):

		     Payloads sent in IKE response messages MUST
   NOT have the critical flag set.  Note that the critical flag applies
   only to the payload type, not the contents.  If the payload type is
   recognized, but the payload contains something which is not (such as
   an unknown transform inside an SA payload, or an unknown Notify
   Message Type inside a Notify payload), the critical flag is ignored.

So the more descriptive text could be:

  This document clarifies that critical flag MUST NOT be used in
  response messages, and that critical flag applies only to the
  payload type, note the contents (Section 2.5). 

> >----------------------------------------------------------------------
> >
> >In section 1.7 the bullet
> >
> >   In 2.8, changed "Note that, when rekeying, the new Child SA MAY have
> >   different traffic selectors and algorithms than the old one" to "Note
> >   that, when rekeying, the new Child SA SHOULD NOT have different
> >   traffic selectors and algorithms than the old one".
> >
> >should be rewritten to
> >
> >   In the Child SA rekey the new recommended behavior is that the new
> >   Child SA SHOULD NOT have different traffic selectors and algorithms
> >   than what was used in the old Child SA. Previously it
> >   was that "Child SA MAY have different traffic selectors and
> >   algorithms then the old one" (section 2.8).
> 
> Those two feel equivalent to me; not done. I am quite hesitant to do
> wordsmithing at this stage, particularly if it could cause loss of
> information.

Yes, I tried to write them so they are equivalent, but I think it is
better to try to explain the change in normal words, than just provide
diff. If diff would be enough, then we could just point everybody to
the rfcdiff between RFC4306 vs IKEv2bis.

> >----------------------------------------------------------------------
> >
> >Also I think the new sections could be combined together i.e. replace:
> >
> >   The new Section 2.8.2 covers simultaneous IKE SA rekeying.
> >
> >   The new Section 2.9.2 covers traffic selectors in rekeying.
> >
> >   Added Section 2.23.1 to describe NAT traversal when transport mode is
> >   requested.
> >
> >to
> >
> >   There are completely new sections covering simultaneous IKE SA
> >   rekeying (Section 2.8.2), traffic selectors in rekeying (Section
> >   2.9.2) and NAT traversal in transport mode (2.23.1).
> 
> Ditto. These are equivalent.

Yes, but same reason again. Put emphasis on the new information, not
to new section numbers.

> >----------------------------------------------------------------------
> >
> >In general implementators are not that interested in what parts of the
> >text changed, they are interested in what was the real change that
> >affects them.
> 
> That's a very broad claim, made by someone who already fully
> implemented IKEv2. Other implementers, particularly those who are in
> the middle of implementing IKEv2, might differ.

If someone are middle of implementing IKEv2 then either they have
already implemented something that needs to be changed, in which case
they are interested what parts of text that affects them has changeed,
or they have not yet implemented that part, in which case that change
does not interest them at all, in which case they just ignore the old
RFC4306 and directly read new IKEv2bis text.

If they are new to IKEv2 they do not need this section at all, as it
is not important to know what was before, if they are just trying to
see what they need to make for their implementation. 
-- 
kivinen@iki.fi

From yaronf@checkpoint.com  Tue Jan 26 05:37:48 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3C873A67BD for ; Tue, 26 Jan 2010 05:37:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.165
X-Spam-Level: 
X-Spam-Status: No, score=-3.165 tagged_above=-999 required=5 tests=[AWL=0.434,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6uTLOkv++CW for ; Tue, 26 Jan 2010 05:37:46 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 27FED3A6359 for ; Tue, 26 Jan 2010 05:37:45 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0QDbsT8016444; Tue, 26 Jan 2010 15:37:55 +0200 (IST)
X-CheckPoint: {4B5EF02F-1-1B201DC2-5FFFF}
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 26 Jan 2010 15:38:09 +0200
From: Yaron Sheffer 
To: Tero Kivinen 
Date: Tue, 26 Jan 2010 15:38:06 +0200
Thread-Topic: [IPsec] IKEv2-bis comments: 2.17 and onwards
Thread-Index: AcqdseVV3Sf3JczwRZ2+dzi+tpH0/AAyS1zw
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A807B3@il-ex01.ad.checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A804C9@il-ex01.ad.checkpoint.com> <19293.33004.243945.230722@fireball.kivinen.iki.fi>
In-Reply-To: <19293.33004.243945.230722@fireball.kivinen.iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IPsecme WG 
Subject: Re: [IPsec] IKEv2-bis comments: 2.17 and onwards
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2010 13:37:48 -0000

Hi Tero, please see below.

Thanks,
	Yaron

> -----Original Message-----
> From: Tero Kivinen [mailto:kivinen@iki.fi]
> Sent: Monday, January 25, 2010 13:31
> To: Yaron Sheffer
> Cc: IPsecme WG
> Subject: [IPsec] IKEv2-bis comments: 2.17 and onwards
>=20
> Yaron Sheffer writes:
> > 2.21.: EAP Failure cases are missing altogether. Also, the first
> > paragraph says that if an auth failure occurs at the responder,
> > AUTHENTICATION_FAILED is included in the protected response (to
> > IKE_AUTH),
>=20
> Yes.
>=20
> > while the last paragraph says it's a separate
> > Informational exchange.
>=20
> Where does it say that if failure occurs at the responder you are
> allowed to use separate INFORMATIONAL exchange? It was supposed to say
> that in case the failure occurs at the INITIATOR (i.e. parsing the
> response packet) then it MAY use INFORMATIONAL exchange.
>=20
Yes, I misunderstood the parentheses in that last paragraph of 2.21.2. It w=
ould have been clearer if we said "in case an error happened when the initi=
ator processes a response to IKE_AUTH).

> > 2.24: what's this section (ECN) doing here? It is 100% IPsec,
> > nothing to do with IKE. If there's a reason, let's explain it in
> > the text.
>=20
> It is here because if IKEv2 is used then ECN behavior is implictly
> mandated by just using IKEv2. In IKEv1 we had negotiation ability for
> it, but not in IKEv2. I think the current text already explains this:
>=20
>             ECN support for IPsec tunnels for IKEv1-
>    based IPsec requires multiple operating modes and negotiation (see
>    [ECN]).  IKEv2 simplifies this situation by requiring that ECN be
>    usable in the outer IP headers of all tunnel-mode Child SAs created
>    by IKEv2.  Specifically, tunnel encapsulators and decapsulators for
>    all tunnel-mode SAs created by IKEv2 MUST support the ECN full-
>    functionality option for tunnels specified in [ECN] and MUST
>    implement the tunnel encapsulation and decapsulation processing
>    specified in [IPSECARCH] to prevent discarding of ECN congestion
>    indications.
>=20
> > 3.3.2: Tiger - we closed issue #33, but according to the text of the
> > issue, should have left the algorithm "unspecified". Which I think
> > would be much more accurate.
>=20
> The "Not done" part is from the time Paul opened the issue, not the
> final outcome from the issue.
>=20
> Final outcome can be found from here:
>=20
> http://www.ietf.org/mail-archive/web/ipsec/current/msg03187.html

No, there were follow-ups to that message, including one that gave the refe=
rence that we should include in bis:

Ross Anderson, Eli Biham, Tiger: A Fast New Hash Function, Fast Software En=
cryption 3, 1996, LNCS 1039.

>=20
> > 3.3.5: "Attributes described as fixed length MUST NOT be encoded
> > using the variable-length encoding." This cannot be correct, a new
> > 4-octet attribute will have to be encoded as variable-length. It
> > won't fit into the other format.
>=20
> This should use "TV" and "TLV" format text instead:
>=20
>    The only currently defined attribute type (Key Length) is using TV
>    encoding; the TLV encoding specification is included only for
>    future extensions. Attributes described as using TV encoding MUST
>    NOT be encoded using the TLV encoding. Attributes described as
>    using TLV encoding MUST NOT be encoded as using TV encoding even if
>    their value can fit into two octets. NOTE: This is a change from
>    IKEv1, where increased flexibility may have simplified the composer
>    of messages but certainly complicated the parser.
>=20
> > 3.6: "DNS Signed Key" is marked Unspecified. Is it not RFC 4025?
> > It's not used anywhere, but still...
>=20
> I do not think the DNS Signed Key mans the same as IPSECKEY RR
> specified in the RFC4025. Or it could be it means, but nobody knows,
> thus I think it is correct to keep it UNSPECIFIED, especially as this
> value dates back to the RFC2408 which predates RFC4025 and RFC4025
> does not mention that it actually specifies what this format in IKE
> should mean.
>=20
> > 3.7: "If multiple CAs are trusted and the certificate encoding does
> > not allow a list, then multiple Certificate Request payloads would
> > need to be transmitted." This doesn't make sense: we are not sending
> > the cert itself here. we're just sending an encoding on a CA.
> > Moreover, the text further down indicates that the CA field is
> > *always* a list - at least for the defined cert types (4, 12, 13).
> > Overall, this looks like a placeholder, and I suggest to delete the
> > sentence.
>=20
> It is placeholder for other formats not defined in this document, i.e.
> it explictly says that if some future certificate encoding type
> defines format how certificate authorities are sent inside the CERTREQ
> payload and that newly defined format does not allow list then
> multiple CERTREQ payloads are sent.
>=20
> As all currently defined certificate encodings do allow list, this
> does not affect them.
>=20
> I suggest keeping that text.
>=20
> > 3.10.1: INVALID_SELECTORS is underspecified. It should be rate
> > limited (I suppose), also, how long is the packet fragment included
> > in the notification?
>=20
> Yes, most likely it should be rate limited, but that is not hard
> requirement, as this is caused when authenticated entity does
> something incorrect (i.e includes traffic that is not allowed in this
> SA).
>=20
> Also RFC4301 already mentions rate limitation etc:
> ----------------------------------------------------------------------
>    5.  If an IPsec system receives an inbound packet on an SA and the
>        packet's header fields are not consistent with the selectors for
>        the SA, it MUST discard the packet.  This is an auditable event.
>        The audit log entry for this event SHOULD include the current
>        date/time, SPI, IPsec protocol(s), source and destination of the
>        packet, any other selector values of the packet that are
>        available, and the selector values from the relevant SAD entry.
>        The system SHOULD also be capable of generating and sending an
>        IKE notification of INVALID_SELECTORS to the sender (IPsec
> peer),
>        indicating that the received packet was discarded because of
>        failure to pass selector checks.
>=20
>    To minimize the impact of a DoS attack, or a mis-configured peer,
> the
>    IPsec system SHOULD include a management control to allow an
>    administrator to configure the IPsec implementation to send or not
>    send this IKE notification, and if this facility is selected, to
> rate
>    limit the transmission of such notifications.
> ----------------------------------------------------------------------
>=20
> I think the as in ICMP message provides good enough hint how the
> packet fragment should be included (i.e. not too long as it would
> waste bandwidth, but long enough to allow other end to see all
> selectors).

I think we should give better guidance than a hint.

>=20
> > In addition, Sec. 2.21.2 implies that it is sent during Child SA
> > negotiation, which is not what 3.10.1 is saying.
>=20
> Yes, the 2.21.2 should not include INVALID_SELECTORS in its list of
> notify paylaods there, so changing
>=20
> 				Specifically, a
>    responder may include all the payloads associated with
> authentication
>    (IDr, Cert and AUTH) while sending error notifications for the
>    piggybacked exchanges (FAILED_CP_REQUIRED, INVALID_SELECTORS,
>    NO_PROPOSAL_CHOSEN, and so on), and the initiator MUST NOT fail the
>    authentication because of this.
>=20
> to
>=20
> 				Specifically, a
>    responder may include all the payloads associated with
>    authentication (IDr, Cert and AUTH) while sending error
>    notifications for the piggybacked exchanges (FAILED_CP_REQUIRED
>    NO_PROPOSAL_CHOSEN, and so on), and the initiator MUST NOT fail the
>    authentication because of this.
>=20
> is required.
>=20
> > 3.15.1: "With IPv6, a requestor MAY supply the low-order address
> > octets it wants to use." This means to me that you *don't* provide
> > all 16 octets. But according to the table, the field is a
> > fixed-length 16 octets!
>=20
> No, you always include full 16 octets, but you might only fill in the
> lower 8 octets. You can also fill in the full 16 octets, if you have
> address from previous runs.
>=20
> I.e. you can send following INTERNAL_IP6_ADDRESS payloads in the
> CFG_REQUEST:
>=20
> INTERNAL_IP6_ADDRESS(2001:1bc8:100d:2:21d:9ff:fea5:c19a/64) =3D 17 bytes
> INTERNAL_IP6_ADDRESS(::21d:9ff:fea5:c19a/64) =3D 17 bytes
> INTERNAL_IP6_ADDRESS() =3D 0 bytes.

So you are saying the responder (the IRAS) should interpret the prefix-leng=
th field as "the last X octets are the ones that I want retained in the new=
 address, if that is possible"? This is not clear from the existing text.

>=20
> > 5: unfortunately we have to revise the text about group strengths -
> > or remove it altogether. It is non-normative, so it's probably best
> > to eliminate it.
>=20
> Why is that, and what text you mean?
>=20
> I still think group 2 (1024-bit group) is common for use with 3DES.
> Also group 5 (1536-bit group) does provide more security than group 2
> (1024-bit group).
>=20
> Also group 1 (768-bit group) is for historic purposes only and does
> not provide sufficient strength except for use with DES, which is also
> for historic use only.
>=20
> So which of those statement requires revising?

The one about Group 2. But I accept Pasi's judgment that this would be a re=
write of RFC 4307, i.e. let's forget it for now.

> --
> kivinen@iki.fi
>=20
> Scanned by Check Point Total Security Gateway.

From paul.hoffman@vpnc.org  Tue Jan 26 10:39:06 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12A0A3A698F for ; Tue, 26 Jan 2010 10:39:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.039
X-Spam-Level: 
X-Spam-Status: No, score=-6.039 tagged_above=-999 required=5 tests=[AWL=0.007,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5UO59eyrMIp for ; Tue, 26 Jan 2010 10:39:05 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 2E6A63A6985 for ; Tue, 26 Jan 2010 10:39:04 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0QId9ux093256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jan 2010 11:39:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <1BDA56B00626423DA442A39B4703BDF8@trustworks.com>
References: <064.cff10879f1e3e888fa8930a85464b847@tools.ietf.org><8C41856B-9D3B-4442-B214-5ED60C23906A@checkpoint.com><192 88.15645.382443.519149@fireball.kivinen.iki.fi> <19288.48466.976054.136453@fireball.kivinen.iki.fi>  <1BDA56B00626423DA442A39B4703BDF8@trustworks.com>
Date: Tue, 26 Jan 2010 10:39:07 -0800
To: "Valery Smyslov" , , 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Issue #139: Keying material taken in the order for RoHC
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2010 18:39:06 -0000

I have closed the issue, but wanted to post my new text because it rearranges some of Valery's proposed text. Please reply on this thread if you think I have muffed it.

   A single CHILD_SA negotiation may result in multiple security
   associations.  ESP and AH SAs exist in pairs (one in each direction),
   so two SAs are created in a single Child SA negotiation for them.
   Furthermore, Child SA negotiation may include some future IPsec
   protocol(s) in addition to, or instead of.  ESP or AH (for example,
   ROHC_INTEG).  In any case, keying material for each child SA MUST be
   taken from the expanded KEYMAT using the following rules:

   o  All keys for SAs carrying data from the initiator to the responder
      are taken before SAs going from the responder to the initiator.

   o  If an IPsec protocol requires multiple keys, the order in which
      they are taken from KEYMAT needs to be described in protocol
      specification.  For ESP  and AH, [IPSECARCH] defines the order,
      namely: the encryption key (if any) MUST be taken from the first
      bits and the integrity key (if any) MUST be taken from the
      remaining bits.

   o  If multiple IPsec protocols are negotiated, keying material is
      taken in the order in which the protocol headers will appear in
      the encapsulated packet.

--Paul Hoffman, Director
--VPN Consortium

From svanru@gmail.com  Tue Jan 26 11:48:02 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 021753A68B7 for ; Tue, 26 Jan 2010 11:48:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcuvqWT2KFaz for ; Tue, 26 Jan 2010 11:48:01 -0800 (PST)
Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.189]) by core3.amsl.com (Postfix) with ESMTP id D08973A69A7 for ; Tue, 26 Jan 2010 11:48:00 -0800 (PST)
Received: by gv-out-0910.google.com with SMTP id y18so121757gvf.15 for ; Tue, 26 Jan 2010 11:48:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:cc :references:subject:date:mime-version:content-type :content-transfer-encoding:x-priority:x-msmail-priority:x-mailer :x-mimeole; bh=KllgT1diHSDUrI3cmt19Hp9FdwBrOemWDaZHtUu49V0=; b=l+ADQzQcYX7wcLdtzoK4FCokOj2xiGY5IdbNhceufVmW0VzDL0AnbowESgWVL+ugT8 wYllJcmc2sLjKRXa6mVPCOxnO6FMm2yRYtsc7FBWoffhMRe8T/Q4ydbmKYH1mvEd+89g WGkOqSHzTFURgLQ89p0ALikGhe69p5uYZLLTk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=B+asEUwzxqyVYTa2uWPu3ycDnbTeZAsYbvq9jwmGbCi9iyxrWFjBMPzJGA9Kf7UQ0/ TDz8hULXViGLsvmdyl/2nrTBsHMTqagkV+5rR81IJjyGk8s8f+fyUlgO0T/B0C7uxsRq +O11SKmEXuAbX1uw+cKog7Qv3Ho/rGTvTYyzo=
Received: by 10.103.85.28 with SMTP id n28mr4271047mul.121.1264535288543; Tue, 26 Jan 2010 11:48:08 -0800 (PST)
Received: from chichi (ppp85-140-185-77.pppoe.mtu-net.ru [85.140.185.77]) by mx.google.com with ESMTPS id 23sm4994238mum.33.2010.01.26.11.48.06 (version=SSLv3 cipher=RC4-MD5); Tue, 26 Jan 2010 11:48:07 -0800 (PST)
Message-ID: <3ED373FCE26B4B24A3C3D5B31E7DC0F5@chichi>
From: "Valery Smyslov" 
To: , , "Paul Hoffman" 
References: <064.cff10879f1e3e888fa8930a85464b847@tools.ietf.org><8C41856B-9D3B-4442-B214-5ED60C23906A@checkpoint.com><192 88.15645.382443.519149@fireball.kivinen.iki.fi> <19288.48466.976054.136453@fireball.kivinen.iki.fi>  <1BDA56B00626423DA442A39B4703BDF8@trustworks.com> 
Date: Tue, 26 Jan 2010 22:48:05 +0300
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5843
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Issue #139: Keying material taken in the order for RoHC
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2010 19:48:02 -0000

Paul Hoffman writes:

>I have closed the issue, but wanted to post my new text because it 
>rearranges some of Valery's proposed text. Please reply on this thread if 
>you think I have muffed it.
>
>   A single CHILD_SA negotiation may result in multiple security
>   associations.  ESP and AH SAs exist in pairs (one in each direction),
>   so two SAs are created in a single Child SA negotiation for them.
>   Furthermore, Child SA negotiation may include some future IPsec
>   protocol(s) in addition to, or instead of.  ESP or AH (for example,

Erroneous period after "instead of".

>   ROHC_INTEG).  In any case, keying material for each child SA MUST be
>   taken from the expanded KEYMAT using the following rules:
>
>   o  All keys for SAs carrying data from the initiator to the responder
>      are taken before SAs going from the responder to the initiator.
>
>   o  If an IPsec protocol requires multiple keys, the order in which
>      they are taken from KEYMAT needs to be described in protocol

I'm afraid that KEYMAT here might be confused with KEYMAT as
the source for all keys (output of prf+). They are not the same. Here we
already have already taken all the necessary key bits for particular child 
SA
from KEYMAT (output of prf+), and we are talking how individual keys
should be extracted from them if this SA's protocol requires several keys
(e.g. for encryption and for authentication). I would prefer using term
"SA's keying material" to avoid confusion.

>      specification.  For ESP  and AH, [IPSECARCH] defines the order,
>      namely: the encryption key (if any) MUST be taken from the first
>      bits and the integrity key (if any) MUST be taken from the
>      remaining bits.
>
>   o  If multiple IPsec protocols are negotiated, keying material is

Probably it's worth adding "for each child SA" after "keying material"
for clarification.

>      taken in the order in which the protocol headers will appear in
>      the encapsulated packet.

I would still prefer swapping the last two bullets, as it will be more 
logical order:
first 2 bullets describe how to extract SA's keyng material from KEYMAT
and 3rd - how to extract individual keys from SA's keying material.
But I won't insist on that.

Regards,
Valery Smyslov.


From wwwrun@core3.amsl.com  Tue Jan 26 12:29:22 2010
Return-Path: 
X-Original-To: ipsec@ietf.org
Delivered-To: ipsec@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id 527BE3A68DA; Tue, 26 Jan 2010 12:29:22 -0800 (PST)
X-idtracker: yes
From: The IESG 
To: IETF-Announce 
Message-Id: <20100126202922.527BE3A68DA@core3.amsl.com>
Date: Tue, 26 Jan 2010 12:29:22 -0800 (PST)
Cc: ipsecme mailing list , ipsecme chair , Internet Architecture Board , RFC Editor 
Subject: [IPsec] Protocol Action: 'Wrapped ESP for Traffic Visibility' to Proposed Standard
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2010 20:29:22 -0000

The IESG has approved the following document:

- 'Wrapped ESP for Traffic Visibility '
    as a Proposed Standard


This document is the product of the IP Security Maintenance and Extensions Working Group. 

The IESG contact persons are Pasi Eronen and Tim Polk.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-traffic-visibility-12.txt

Technical Summary

   This document describes the Wrapped Encapsulating Security Payload
   (WESP) protocol, which is based on the Encapsulating Security
   Payload (ESP) protocol and is designed to allow intermediate
   devices to ascertain if ESP with null encryption is being employed
   and if so, inspect the IPsec packets for network monitoring and
   access control functions. The mechanism described in this document
   can be used to easily disambiguate ESP-NULL from encrypted ESP
   packets, without compromising on the security provided by ESP.

Working Group Summary

   Early on there was prolonged WG discussion about the relative
   merits of the Wrapped ESP solution for identifying ESP-null
   traffic, compared to heuristic methods for traffic
   inspection. Eventually the WG reached consensus on the usefulness
   of having both solutions published, with the heuristics solution
   targeted for the interim period until WESP is widely deployed. This
   consensus is documented in both protocol documents.

   IESG review also lead to clarifying the protocol's extensibility
   model: if there is consensus in the future to extend the protocol,
   those extensions need a new WESP version number, and have to be
   negotiated by the endpoints. This simplified the protocol by, 
   for example, keeping the ICV coverage unchanged from ESP.

Document Quality

   Currently, there are no known implementations. However, a number of
   vendors have expressed interest and supported this activity.

Personnel

   The document shepherd is Yaron Sheffer, and the responsible
   area director is Pasi Eronen.


From paul.hoffman@vpnc.org  Tue Jan 26 13:23:53 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F70E28C0EC for ; Tue, 26 Jan 2010 13:23:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.04
X-Spam-Level: 
X-Spam-Status: No, score=-6.04 tagged_above=-999 required=5 tests=[AWL=0.007,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBV73Ee-MRMN for ; Tue, 26 Jan 2010 13:23:51 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id CDF5B3A6890 for ; Tue, 26 Jan 2010 13:23:51 -0800 (PST)
Received: from [10.20.30.158] (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0QLO14q005794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 26 Jan 2010 14:24:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
Date: Tue, 26 Jan 2010 13:23:59 -0800
To: IPsecme WG 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: [IPsec] Fwd: Internal WG Review: Recharter of IP Security Maintenance and Extensions (ipsecme)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2010 21:23:53 -0000

Comments should be sent to all of this list, the IESG, and the IAB.

--Paul Hoffman

>From: IESG Secretary 
>To: iesg@ietf.org, iab@iab.org, paul.hoffman@vpnc.org, yaronf@checkpoint.com
>Subject: Internal WG Review: Recharter of IP Security Maintenance and
>         Extensions (ipsecme)
>reply-to: iesg@ietf.org
>Date: Tue, 26 Jan 2010 12:30:02 -0800 (PST)
>
>A new charter for the IP Security Maintenance and Extensions (ipsecme)
>working group in the Security Area of the IETF is being considered.  The
>draft charter is provided below for your review and comment.
>
>Review time is one week.
>
>The IETF Secretariat
>
>IP Security Maintenance and Extensions (ipsecme)
>---------------------------------------------------
>Current Status: Active Working Group
>Last Modified: 2010-01-21
>
>Chair(s):
>    * Paul Hoffman (paul.hoffman@vpnc.org)
>    * Yaron Sheffer (yaronf@checkpoint.com)
>
>Security Area Director(s):
>    * Tim Polk (tim.polk@nist.gov)
>    * Pasi Eronen (pasi.eronen@nokia.com)
>
>Security Area Advisor:
>    * Pasi Eronen (pasi.eronen@nokia.com)
>
>Mailing Lists:
>  General Discussion: ipsec@ietf.org
>  To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec
>  Archive: http://www.ietf.org/mail-archive/web/ipsec/
>
>Description of Working Group:
>
>The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated
>RFCs), IKEv2 (RFC 4306, RFC 4718, and associated RFCs), and the IPsec
>security architecture (RFC 4301). IPsec is widely deployed in VPN
>gateways, VPN remote access clients, and as a substrate for
>host-to-host, host-to-network, and network-to-network security.
>
>The IPsec Maintenance and Extensions Working Group continues the work
>of the earlier IPsec Working Group which was concluded in 2005. Its
>purpose is to maintain the IPsec standard and to facilitate discussion
>of clarifications, improvements, and extensions to IPsec, mostly to
>IKEv2. The working group also serves as a focus point for other IETF
>Working Groups who use IPsec in their own protocols.
>
>The work items are:
>
>- A standards-track IKEv2 extension that allows an IKE peer to quickly
>and securely detect that its opposite peer, while currently reachable,
>has lost its IKEv2/IPsec state. Changes to how the peers recover from
>this situation are beyond the scope of this work item, as is improving
>the detection of an unreachable or dead peer. Ideas from
>draft-nir-ike-qcd-05 and draft-detienne-ikev2-recovery-03 can be used
>as starting points.
>
>- A standards-track IKEv2 extension to allow mutual EAP-based
>authentication in IKEv2, eliminating the need for the responder to
>present a certificate. The document will define the conditions that
>EAP methods need to fulfill in order to use this extension. The
>document will recommend, but will not require, the use of EAP methods
>that provide EAP channel binding. The proposed starting point for this
>work is draft-eronen-ipsec-ikev2-eap-auth-07.txt.
>
>- IKEv2 supports mutual authentication with a shared secret, but this
>mechanism is intended for "strong" shared secrets. User-chosen
>passwords are typically of low entropy and subject to off-line
>dictionary attacks when used with this mechanism. Thus, RFC 4306
>recommends using EAP with public-key based authentication of the
>responder instead. This approach would be typically used in enterprise
>remote access VPN scenarios where the VPN gateway does not usually
>even have the actual passwords for all users, but instead typically
>communicates with a back-end RADIUS server.
>
>However, user-configured shared secrets are still useful for many
>other IPsec scenarios, such as authentication between two servers or
>routers. These scenarios are usually symmetric: both peers know the
>shared secret, no back-end authentication servers are involved, and
>either peer can initiate an IKEv2 SA. These features make using EAP
>(with its strict client-server separation) undesirable.
>
>The WG will develop a standards-track extension to IKEv2 to allow
>mutual authentication based on "weak" (low-entropy) shared
>secrets. The goal is to avoid off-line dictionary attacks without
>requiring the use of certificates or EAP. There are many
>already-developed algorithms that can be used, and the WG would need
>to pick one that both is believed to be secure and is believed to have
>acceptable intellectual property features. The WG would also need to
>develop the protocol to use the chosen algorithm in IKEv2 in a secure
>fashion. It is noted up front that this work item poses a higher
>chance of failing to be completed than other WG work items; this is
>balanced by the very high expected value of the extension if it is
>standardized and deployed.
>
>- IPsec gateways are often deployed in clusters that look like a
>single gateway to the peer (such as for high availability and load
>balancing reasons). However, correctly maintaining the appearance to
>the peer of a single gateway is complicated; one of the main
>challenges is the strict use of sequence numbers both in IKEv2 and
>ESP/AH.
>
>This work item will define a problem statement and requirements for
>potential IPsec/IKEv2 mechanism (or multiple mechanisms) to simplify
>cluster implementations. The result will be an informational document
>that, once completed, may lead to chartering one or more new work
>items to specify the actual mechanisms. The scope is restricted to
>mechanism(s) that are visible to the peer, and thus usually require
>interoperability between vendors. Mixed-vendor clusters, and protocols
>between the cluster members, are explicitly out of scope of this work
>item. The starting point will be draft-nir-ipsecme-ipsecha-00.
>
>
>In addition, the following items from the existing charter are
>expected to be completed soon:
>
>- A revision to IKEv2 (RFC 4306) that incorporates the clarifications
>from RFC 4718, and otherwise improves the quality of the
>specification, taking into account implementation and interoperability
>experience. In some cases, the revision may include small technical
>corrections; however, impact on existing implementations must be
>considered. Major changes and adding new features is beyond the scope
>of this work item. One part of this work item, clarifying how AES
>counter mode is used for the IKEv2 encrypted payload, is in a separate
>document.
>
>- An IPsec document roadmap that describes the various RFC documents
>covering IPsec, including both the core RFC 240x and RFC 430x versions
>of IPsec, and extensions specified in other documents. This document
>will be informational.
>
>- A standards-track mechanism that allows an intermediary device, such
>as a firewall or intrusion detection system, to easily and reliably
>determine whether an ESP packet is encrypted with the NULL cipher; and
>if it is, determine the location of the actual payload data inside the
>packet.
>
>
>The scope of the WG is restricted to the work items listed above. The
>WG shall not consider adding new work items until there are four or
>fewer documents being actively worked on (not yet progressed to IETF
>Last Call). At that time, the WG can propose rechartering.
>
>Work on IPsec extensions that are not included in this charter can
>happen as usual in other WGs, or as individual submissions.
>
>This charter will expire in February 2012 (24 months from
>approval). If the charter is not updated before that time, the WG will
>be closed and any remaining documents revert back to individual
>Internet-Drafts.
>
>Goals and Milestones:
>
>Aug 2010 - WG last call on HA requirements
>Dec 2010 - WG last call on quick crash discovery
>Jan 2011 - WG last call on EAP-only authentication
>Mar 2011 - WG last call on password-based authentication


From ynir@checkpoint.com  Tue Jan 26 13:33:20 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37B3C3A6A0E for ; Tue, 26 Jan 2010 13:33:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.274
X-Spam-Level: 
X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8A3P1XgwGwEx for ; Tue, 26 Jan 2010 13:33:19 -0800 (PST)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 272A53A6830 for ; Tue, 26 Jan 2010 13:29:05 -0800 (PST)
X-CheckPoint: {4B5F5BFC-10005-14201DC2-FFFF}
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id CF15629C00B; Tue, 26 Jan 2010 23:29:15 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id B56D229C002; Tue, 26 Jan 2010 23:29:15 +0200 (IST)
X-CheckPoint: {4B5F5BFC-10000-14201DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0QLTFT7021509; Tue, 26 Jan 2010 23:29:15 +0200 (IST)
X-CheckPoint: {4B5F5EA4-0-1B201DC2-5FFFF}
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 26 Jan 2010 23:29:30 +0200
From: Yoav Nir 
To: Paul Hoffman , IPsecme WG 
Date: Tue, 26 Jan 2010 23:27:47 +0200
Thread-Topic: [IPsec] Fwd: Internal WG Review: Recharter of IP Security Maintenance and Extensions (ipsecme)
Thread-Index: Acqeze+sApUO7vZMTK+b3c+LWGI4QQAAHfqS
Message-ID: <006FEB08D9C6444AB014105C9AEB133FB36A4ECB4E@il-ex01.ad.checkpoint.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [IPsec] Fwd: Internal WG Review: Recharter of IP Security Maintenance and Extensions (ipsecme)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2010 21:33:20 -0000

Hasn't this item just been approved by the IESG?  Isn't it done?
________________________________________

>
>- A standards-track mechanism that allows an intermediary device, such
>as a firewall or intrusion detection system, to easily and reliably
>determine whether an ESP packet is encrypted with the NULL cipher; and
>if it is, determine the location of the actual payload data inside the
>packet.
>
=

From yaronf@checkpoint.com  Tue Jan 26 13:40:07 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 398CD3A6926 for ; Tue, 26 Jan 2010 13:40:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.274
X-Spam-Level: 
X-Spam-Status: No, score=-3.274 tagged_above=-999 required=5 tests=[AWL=0.325,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTSj3NsA7rNw for ; Tue, 26 Jan 2010 13:40:06 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 9AB893A69F9 for ; Tue, 26 Jan 2010 13:39:39 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0QLdnT7022651; Tue, 26 Jan 2010 23:39:49 +0200 (IST)
X-CheckPoint: {4B5F611E-0-1B201DC2-5FFFF}
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 26 Jan 2010 23:40:04 +0200
From: Yaron Sheffer 
To: Yoav Nir , Paul Hoffman , IPsecme WG 
Date: Tue, 26 Jan 2010 23:40:02 +0200
Thread-Topic: [IPsec] Fwd: Internal WG Review: Recharter of IP Security Maintenance and Extensions (ipsecme)
Thread-Index: Acqeze+sApUO7vZMTK+b3c+LWGI4QQAAHfqSAABocsA=
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A8084B@il-ex01.ad.checkpoint.com>
References:  <006FEB08D9C6444AB014105C9AEB133FB36A4ECB4E@il-ex01.ad.checkpoint.com>
In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB36A4ECB4E@il-ex01.ad.checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [IPsec] Fwd: Internal WG Review: Recharter of IP Security Maintenance and Extensions (ipsecme)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2010 21:40:07 -0000

1. It's a race condition.
2. It ain't over till it's over - published by the RFC Editor.

> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
> Of Yoav Nir
> Sent: Tuesday, January 26, 2010 23:28
> To: Paul Hoffman; IPsecme WG
> Subject: Re: [IPsec] Fwd: Internal WG Review: Recharter of IP Security
> Maintenance and Extensions (ipsecme)
>=20
> Hasn't this item just been approved by the IESG?  Isn't it done?
> ________________________________________
> 
> >
> >- A standards-track mechanism that allows an intermediary device, such
> >as a firewall or intrusion detection system, to easily and reliably
> >determine whether an ESP packet is encrypted with the NULL cipher; and
> >if it is, determine the location of the actual payload data inside the
> >packet.
> >
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>=20
> Scanned by Check Point Total Security Gateway.

From paul.hoffman@vpnc.org  Tue Jan 26 13:40:59 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD3AF3A6877 for ; Tue, 26 Jan 2010 13:40:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.04
X-Spam-Level: 
X-Spam-Status: No, score=-6.04 tagged_above=-999 required=5 tests=[AWL=0.006,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mma0MmGXxpPO for ; Tue, 26 Jan 2010 13:40:59 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id C9A5B3A6830 for ; Tue, 26 Jan 2010 13:40:58 -0800 (PST)
Received: from [10.20.30.158] (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0QLf1Za006858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jan 2010 14:41:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB36A4ECB4E@il-ex01.ad.checkpoint.com>
References:  <006FEB08D9C6444AB014105C9AEB133FB36A4ECB4E@il-ex01.ad.checkpoint.com>
Date: Tue, 26 Jan 2010 13:41:00 -0800
To: Yoav Nir , IPsecme WG 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [IPsec] Fwd: Internal WG Review: Recharter of IP Security Maintenance and Extensions (ipsecme)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2010 21:41:00 -0000

At 11:27 PM +0200 1/26/10, Yoav Nir wrote:
>Hasn't this item just been approved by the IESG?  Isn't it done?
>________________________________________
>
>>
>>- A standards-track mechanism that allows an intermediary device, such
>>as a firewall or intrusion detection system, to easily and reliably
>>determine whether an ESP packet is encrypted with the NULL cipher; and
>>if it is, determine the location of the actual payload data inside the
>>packet.
>>
>

The heuristics document has not passed into, much less out of, IESG review.

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org  Tue Jan 26 18:41:06 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7A833A686D for ; Tue, 26 Jan 2010 18:41:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.041
X-Spam-Level: 
X-Spam-Status: No, score=-6.041 tagged_above=-999 required=5 tests=[AWL=0.005,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zElCxXlwjWUV for ; Tue, 26 Jan 2010 18:41:05 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id DC2583A683A for ; Tue, 26 Jan 2010 18:41:05 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0R2fBLi024056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jan 2010 19:41:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <3ED373FCE26B4B24A3C3D5B31E7DC0F5@chichi>
References: <064.cff10879f1e3e888fa8930a85464b847@tools.ietf.org><8C41856B-9D3B-4442-B214-5ED60C23906A@checkpoint.com><192 88.15645.382443.519149@fireball.kivinen.iki.fi> <19288.48466.976054.136453@fireball.kivinen.iki.fi>  <1BDA56B00626423DA442A39B4703BDF8@trustworks.com>  <3ED373FCE26B4B24A3C3D5B31E7DC0F5@chichi>
Date: Tue, 26 Jan 2010 18:41:10 -0800
To: "Valery Smyslov" , , 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Issue #139: Keying material taken in the order for RoHC
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2010 02:41:06 -0000

All good points, Valery. Here's another attempt; please check carefully.

   A single CHILD_SA negotiation may result in multiple security
   associations.  ESP and AH SAs exist in pairs (one in each direction),
   so two SAs are created in a single Child SA negotiation for them.
   Furthermore, Child SA negotiation may include some future IPsec
   protocol(s) in addition to, or instead of, ESP or AH (for example,
   ROHC_INTEG).  In any case, keying material for each child SA MUST be
   taken from the expanded KEYMAT using the following rules:

   o  All keys for SAs carrying data from the initiator to the responder
      are taken before SAs going from the responder to the initiator.

   o  If multiple IPsec protocols are negotiated, keying material for
      each Child SA is taken in the order in which the protocol headers
      will appear in the encapsulated packet.

   o  If an IPsec protocol requires multiple keys, the order in which
      they are taken from the SA's keying material needs to be described
      in protocol specification.  For ESP  and AH, [IPSECARCH] defines
      the order, namely: the encryption key (if any) MUST be taken from
      the first bits and the integrity key (if any) MUST be taken from
      the remaining bits.

--Paul Hoffman, Director
--VPN Consortium

From svanru@gmail.com  Tue Jan 26 22:39:49 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 267023A68EE for ; Tue, 26 Jan 2010 22:39:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.696
X-Spam-Level: 
X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[AWL=0.390,  BAYES_00=-2.599, XMAILER_MIMEOLE_OL_7533E=0.513]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHA3B73QzMJW for ; Tue, 26 Jan 2010 22:39:48 -0800 (PST)
Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id 183D03A67D8 for ; Tue, 26 Jan 2010 22:39:47 -0800 (PST)
Received: by ewy8 with SMTP id 8so6380005ewy.29 for ; Tue, 26 Jan 2010 22:39:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:cc :references:subject:date:mime-version:content-type :content-transfer-encoding:x-priority:x-msmail-priority:x-mailer :x-mimeole; bh=fFGAMR/6hGs3sj8GvWow+hkk/DD65fMVQglN5+0MeKE=; b=I9Kf2SlwIfVG0jf1w5XTxNhFVq9UhOl006jupCxALsU9A9sXZMmVu3usmC79RjZe0X LXxNj0l/c7zRqRM4YgJz+vccECdOsFZb8pZ0E0+NH1AB546DTd/SOWsXxsPcBOztKhLq 6xvvRozrrxpWWwWHS/F8NugVDu0pGtz+V6E2k=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=mvWsmZurogUQVI2Wb5+eaoIkC11TuVnqCCkOxD2s2fJ6BDzApttE+wx/13qhzMeMlo dTEf/5Qb/ICzfYVjGA5VTGz85V/9KGwtI100YMlEUDxYslYhT6aUCRGRDkQOmt9rt3iW MaYIPC1o6oeQHuimqZjkj8Zrtki8HjBEBkZ9w=
Received: by 10.213.44.17 with SMTP id y17mr3494406ebe.25.1264574397493; Tue, 26 Jan 2010 22:39:57 -0800 (PST)
Received: from svanpc ([82.138.51.4]) by mx.google.com with ESMTPS id 15sm5780557ewy.8.2010.01.26.22.39.55 (version=SSLv3 cipher=RC4-MD5); Tue, 26 Jan 2010 22:39:56 -0800 (PST)
Message-ID: <86AF78D23760458FAD7FD3E1950E71EE@trustworks.com>
From: "Valery Smyslov" 
To: , , "Paul Hoffman" 
References: <064.cff10879f1e3e888fa8930a85464b847@tools.ietf.org><8C41856B-9D3B-4442-B214-5ED60C23906A@checkpoint.com><192 88.15645.382443.519149@fireball.kivinen.iki.fi> <19288.48466.976054.136453@fireball.kivinen.iki.fi>  <1BDA56B00626423DA442A39B4703BDF8@trustworks.com>  <3ED373FCE26B4B24A3C3D5B31E7DC0F5@chichi> 
Date: Wed, 27 Jan 2010 09:40:49 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4963.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Issue #139: Keying material taken in the order for RoHC
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2010 06:39:49 -0000

Paul Hoffman writes:


> All good points, Valery. Here's another attempt; please check carefully.
> 
>    A single CHILD_SA negotiation may result in multiple security
>    associations.  ESP and AH SAs exist in pairs (one in each direction),
>    so two SAs are created in a single Child SA negotiation for them.
>    Furthermore, Child SA negotiation may include some future IPsec
>    protocol(s) in addition to, or instead of, ESP or AH (for example,
>    ROHC_INTEG).  In any case, keying material for each child SA MUST be
>    taken from the expanded KEYMAT using the following rules:
> 
>    o  All keys for SAs carrying data from the initiator to the responder
>       are taken before SAs going from the responder to the initiator.
> 
>    o  If multiple IPsec protocols are negotiated, keying material for
>       each Child SA is taken in the order in which the protocol headers
>       will appear in the encapsulated packet.
> 
>    o  If an IPsec protocol requires multiple keys, the order in which
>       they are taken from the SA's keying material needs to be described
>       in protocol specification.  For ESP  and AH, [IPSECARCH] defines
>       the order, namely: the encryption key (if any) MUST be taken from
>       the first bits and the integrity key (if any) MUST be taken from
>       the remaining bits.

Looks fine to me.

Regards,
Valery Smyslov.


From ynir@checkpoint.com  Tue Jan 26 23:42:54 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE6413A68FC for ; Tue, 26 Jan 2010 23:42:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.339
X-Spam-Level: 
X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9l3p6VOCawsJ for ; Tue, 26 Jan 2010 23:42:53 -0800 (PST)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id DC32A3A6852 for ; Tue, 26 Jan 2010 23:42:51 -0800 (PST)
X-CheckPoint: {4B5FEBD4-10006-14201DC2-FFFF}
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 4CBF329C099; Wed, 27 Jan 2010 09:43:04 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 2CC4429C094; Wed, 27 Jan 2010 09:43:04 +0200 (IST)
X-CheckPoint: {4B5FEBD4-10000-14201DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0R7h3T7009936; Wed, 27 Jan 2010 09:43:03 +0200 (IST)
X-CheckPoint: {4B5FEE7B-1-1B201DC2-5FFFF}
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 27 Jan 2010 09:43:18 +0200
From: Yoav Nir 
To: Paul Hoffman 
Date: Wed, 27 Jan 2010 09:42:55 +0200
Thread-Topic: [IPsec] Fwd: Internal WG Review: Recharter of IP Security Maintenance and Extensions (ipsecme)
Thread-Index: AcqfJGRL+ePFIr6HS8CHUQSD2NaDoA==
Message-ID: <7E2C98AC-49D8-4BFB-9E51-1C1F50428A94@checkpoint.com>
References:  <006FEB08D9C6444AB014105C9AEB133FB36A4ECB4E@il-ex01.ad.checkpoint.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IPsecme WG 
Subject: Re: [IPsec] Fwd: Internal WG Review: Recharter of IP Security Maintenance and Extensions (ipsecme)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2010 07:42:54 -0000

Yes, but the heuristics  document is not standards-track.

Never mind, I'm not trying to nit-pick our charter proposal.

On Jan 26, 2010, at 11:41 PM, Paul Hoffman wrote:

> At 11:27 PM +0200 1/26/10, Yoav Nir wrote:
>> Hasn't this item just been approved by the IESG?  Isn't it done?
>> ________________________________________
>> 
>>>=20
>>> - A standards-track mechanism that allows an intermediary device, such
>>> as a firewall or intrusion detection system, to easily and reliably
>>> determine whether an ESP packet is encrypted with the NULL cipher; and
>>> if it is, determine the location of the actual payload data inside the
>>> packet.
>>>=20
>> 
>=20
> The heuristics document has not passed into, much less out of, IESG revie=
w.
>=20
> --Paul Hoffman, Director
> --VPN Consortium
>=20
> Scanned by Check Point Total Security Gateway.


From kivinen@iki.fi  Wed Jan 27 01:16:08 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2FA53A6A2D for ; Wed, 27 Jan 2010 01:16:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.491
X-Spam-Level: 
X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKSKwWISTlnt for ; Wed, 27 Jan 2010 01:16:07 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id AC2503A6A28 for ; Wed, 27 Jan 2010 01:16:06 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0R9GCWG022263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jan 2010 11:16:12 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0R9GBu8017706; Wed, 27 Jan 2010 11:16:11 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19296.1115.629499.347945@fireball.kivinen.iki.fi>
Date: Wed, 27 Jan 2010 11:16:11 +0200
From: Tero Kivinen 
To: Yaron Sheffer 
In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A807B3@il-ex01.ad.checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A804C9@il-ex01.ad.checkpoint.com> <19293.33004.243945.230722@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A807B3@il-ex01.ad.checkpoint.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 28 min
X-Total-Time: 27 min
Cc: IPsecme WG 
Subject: Re: [IPsec] IKEv2-bis comments: 2.17 and onwards
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2010 09:16:08 -0000

Yaron Sheffer writes:
> > Yaron Sheffer writes:
> > > 2.21.: EAP Failure cases are missing altogether. Also, the first
> > > paragraph says that if an auth failure occurs at the responder,
> > > AUTHENTICATION_FAILED is included in the protected response (to
> > > IKE_AUTH),
> > 
> > Yes.
> > 
> > > while the last paragraph says it's a separate
> > > Informational exchange.
> > 
> > Where does it say that if failure occurs at the responder you are
> > allowed to use separate INFORMATIONAL exchange? It was supposed to say
> > that in case the failure occurs at the INITIATOR (i.e. parsing the
> > response packet) then it MAY use INFORMATIONAL exchange.
> > 
> Yes, I misunderstood the parentheses in that last paragraph of
> 2.21.2. It would have been clearer if we said "in case an error
> happened when the initiator processes a response to IKE_AUTH).

Yes, that clarification might be better, i.e. the whole pararaph would
be then this:

   In an IKE_AUTH exchange, or in the INFORMATIONAL exchange
   immediately following it (in case an error happened when the
   initiator processes a response response to IKE_AUTH), the
   UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and
   AUTHENTICATION_FAILED notifications are the only ones to cause the
   IKE SA to be deleted or not created, without a DELETE payload.
   Extension documents may define new error notifications with these
   semantics, but MUST NOT use them unless the peer has been shown to
   understand them.

> > > 3.3.2: Tiger - we closed issue #33, but according to the text of the
> > > issue, should have left the algorithm "unspecified". Which I think
> > > would be much more accurate.
> > 
> > The "Not done" part is from the time Paul opened the issue, not the
> > final outcome from the issue.
> > 
> > Final outcome can be found from here:
> > 
> > http://www.ietf.org/mail-archive/web/ipsec/current/msg03187.html
> 
> No, there were follow-ups to that message, including one that gave
> the reference that we should include in bis: 
> 
> Ross Anderson, Eli Biham, Tiger: A Fast New Hash Function, Fast
> Software Encryption 3, 1996, LNCS 1039.

Yes there is responses and reference to Tiger hash function, but as
the RFC2104 works for any generic hash it works also with Tiger, and I
understood from Paul's message that he was ok with the RFC2104
reference and I do not think we need separate reference for each
algorithm. We have some of those references, and in some case we refer
to RFC which has references to the algorithm and in some cases (IDEA)
we have both, i.e. both reference to the RFC having reference to the
algorithm description and the direct reference to the algorithm
reference.

I think TIGER is the only algorithm where we do not have such
reference (either direct or inderect), so it might be good to add
reference for it.

> > > 3.10.1: INVALID_SELECTORS is underspecified. It should be rate
> > > limited (I suppose), also, how long is the packet fragment included
> > > in the notification?
> > 
> > Yes, most likely it should be rate limited, but that is not hard
> > requirement, as this is caused when authenticated entity does
> > something incorrect (i.e includes traffic that is not allowed in this
> > SA).
> > 
> > Also RFC4301 already mentions rate limitation etc:
> > ----------------------------------------------------------------------
> >    5.  If an IPsec system receives an inbound packet on an SA and the
> >        packet's header fields are not consistent with the selectors for
> >        the SA, it MUST discard the packet.  This is an auditable event.
> >        The audit log entry for this event SHOULD include the current
> >        date/time, SPI, IPsec protocol(s), source and destination of the
> >        packet, any other selector values of the packet that are
> >        available, and the selector values from the relevant SAD entry.
> >        The system SHOULD also be capable of generating and sending an
> >        IKE notification of INVALID_SELECTORS to the sender (IPsec
> > peer),
> >        indicating that the received packet was discarded because of
> >        failure to pass selector checks.
> > 
> >    To minimize the impact of a DoS attack, or a mis-configured peer,
> > the
> >    IPsec system SHOULD include a management control to allow an
> >    administrator to configure the IPsec implementation to send or not
> >    send this IKE notification, and if this facility is selected, to
> > rate
> >    limit the transmission of such notifications.
> > ----------------------------------------------------------------------
> > 
> > I think the as in ICMP message provides good enough hint how the
> > packet fragment should be included (i.e. not too long as it would
> > waste bandwidth, but long enough to allow other end to see all
> > selectors).
> 
> I think we should give better guidance than a hint.

Perhaps, but in the general I do not expect any kind of automatic
parsing of those INVALID_SELECTORS messages, so this is not so
important. In most cases I think the implementations will most likely
just audit and log the INVALID_SELECTORS notification and put the
notify data in the log file too, so adminstrator can check that later.

INVALID_SELECTORS message usually means that one end is not following
specification. If you want to provide some kind of guidance, I think
that is ok, but I do not think we should waste too much time working
on it. 

> > > 3.15.1: "With IPv6, a requestor MAY supply the low-order address
> > > octets it wants to use." This means to me that you *don't* provide
> > > all 16 octets. But according to the table, the field is a
> > > fixed-length 16 octets!
> > 
> > No, you always include full 16 octets, but you might only fill in the
> > lower 8 octets. You can also fill in the full 16 octets, if you have
> > address from previous runs.
> > 
> > I.e. you can send following INTERNAL_IP6_ADDRESS payloads in the
> > CFG_REQUEST:
> > 
> > INTERNAL_IP6_ADDRESS(2001:1bc8:100d:2:21d:9ff:fea5:c19a/64) = 17 bytes
> > INTERNAL_IP6_ADDRESS(::21d:9ff:fea5:c19a/64) = 17 bytes
> > INTERNAL_IP6_ADDRESS() = 0 bytes.
> 
> So you are saying the responder (the IRAS) should interpret the
> prefix-length field as "the last X octets are the ones that I want
> retained in the new address, if that is possible"?

No. The prefix len is not really meaningful in the
INTERNALIP6_ADDRESS, in the same way as INTERNAL_IP4_NETMASK is not
really meaningful.

The gateway knows the real prefix len it has, and will replace the
prefix with the one it has regardless what prefixlen was requested by
the client.

I.e. if client had the 2001:1bc8:100d:2:21d:9ff:fea5:c19a/64 before
(i.e. the server gave that address last time etc), then it sends
request saying:

INTERNAL_IP6_ADDRESS(2001:1bc8:100d:2:21d:9ff:fea5:c19a/64)

Server might respond with any of the following:

INTERNAL_IP6_ADDRESS(2001:1bc8:100d:2:21d:9ff:fea5:c19a/64)

	Keep the same address, if it s free.

INTERNAL_IP6_ADDRESS(2001:1bc8:100d:ff00:21d:9ff:fea5:c19a/64)

	Keep the same /48 prefix (2001:1bc8:100d::/48), but change the
	subnet inside it from 0002 to for example ff00, but keep the
	lower 64 bits.

INTERNAL_IP6_ADDRESS(2001:1234:5678:0:21d:9ff:fea5:c19a/64)

	If server has multiple /48 prefixes (for example
	2001:1234:5678::/48 in addition the 2001:1bc8:100d::/48 listed
	before), it can change the prefix and also subnet inside it or
	keep the same subnet.

INTERNAL_IP6_ADDRESS(2001:1bc8:100d:2:3333:4444:5555:6666:/64)

	Server might want to change the lower 64-bits for any reason,
	for example if the address requested is still in use (for
	example the same machine has requested it before reboot, and
	the old IKE SA was not yet deleted, thus the address is still
	in use for that IKE SA), or for example to randomize the lower
	64-bits to hide the fact that this is same machine than before
	etc.

or the server can also do something else... :-)

Anyways the prefix length request and reply is not really meaningful.
In reply it has same meaning as INTERNAL_IP4_NETMASK has. In request
it is just whatever the server returned last time. I would except it
to be /64 always...

>From draft-ietf-ipsecme-ikev2bis-07:
----------------------------------------------------------------------
   o  INTERNAL_IP4_NETMASK - The internal network's netmask.  Only one
      netmask is allowed in the request and response messages (e.g.,
      255.255.255.0), and it MUST be used only with an
      INTERNAL_IP4_ADDRESS attribute.  INTERNAL_IP4_NETMASK in a
      CFG_REPLY means roughly the same thing as INTERNAL_IP4_SUBNET
      containing the same information ("send traffic to these addresses
      through me"), but also implies a link boundary.  For instance, the
      client could use its own address and the netmask to calculate the
      broadcast address of the link.  An empty INTERNAL_IP4_NETMASK
      attribute can be included in a CFG_REQUEST to request this
      information (although the gateway can send the information even
      when not requested).  Non-empty values for this attribute in a
      CFG_REQUEST do not make sense and thus MUST NOT be included.
...
   The INTERNAL_IP6_ADDRESS attribute also contains a prefix length
   field.  When used in a CFG_REPLY, this corresponds to the
   INTERNAL_IP4_NETMASK attribute in the IPv4 case.
----------------------------------------------------------------------

> This is not clear from the existing text.

True, but as we have already work in progress to change the whole IPv6
address allocation situation, I do not think we should change this
text in IKEv2bis.


> > > 5: unfortunately we have to revise the text about group strengths -
> > > or remove it altogether. It is non-normative, so it's probably best
> > > to eliminate it.
> > 
> > Why is that, and what text you mean?
> > 
> > I still think group 2 (1024-bit group) is common for use with 3DES.
> > Also group 5 (1536-bit group) does provide more security than group 2
> > (1024-bit group).
> > 
> > Also group 1 (768-bit group) is for historic purposes only and does
> > not provide sufficient strength except for use with DES, which is also
> > for historic use only.
> > 
> > So which of those statement requires revising?
> 
> The one about Group 2. But I accept Pasi's judgment that this would
> be a rewrite of RFC 4307, i.e. let's forget it for now. 

So you think group 2 is not common use with 3DES? The text is very
careful about not saying anything about the actual strength of either
algorithm (group 2 or 3DES), just comments that it is common use with
3DES (not that its strength match with it), and that it needs to be
used with random exponent longer than 200 bits for that use.
-- 
kivinen@iki.fi

From kivinen@iki.fi  Wed Jan 27 01:21:12 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E2693A6A14 for ; Wed, 27 Jan 2010 01:21:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level: 
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FeBwLQh8m7c for ; Wed, 27 Jan 2010 01:21:09 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id E96863A6A28 for ; Wed, 27 Jan 2010 01:21:08 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0R9LEYX020209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jan 2010 11:21:14 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0R9LDNE019553; Wed, 27 Jan 2010 11:21:13 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19296.1417.337564.671788@fireball.kivinen.iki.fi>
Date: Wed, 27 Jan 2010 11:21:13 +0200
From: Tero Kivinen 
To: "Valery Smyslov" 
In-Reply-To: <86AF78D23760458FAD7FD3E1950E71EE@trustworks.com>
References: <064.cff10879f1e3e888fa8930a85464b847@tools.ietf.org>  <8C41856B-9D3B-4442-B214-5ED60C23906A@checkpoint.com> <192 88.15645.382443.519149@fireball.kivinen.iki.fi>  <19288.48466.976054.136453@fireball.kivinen.iki.fi>  <1BDA56B00626423DA442A39B4703BDF8@trustworks.com>  <3ED373FCE26B4B24A3C3D5B31E7DC0F5@chichi>  <86AF78D23760458FAD7FD3E1950E71EE@trustworks.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 1 min
X-Total-Time: 0 min
Cc: ipsec@ietf.org, Black_David@emc.com, Paul Hoffman 
Subject: Re: [IPsec] Issue #139: Keying material taken in the order for RoHC
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2010 09:21:13 -0000

Valery Smyslov writes:
> Paul Hoffman writes:
> > All good points, Valery. Here's another attempt; please check carefully.
> > 
> >    A single CHILD_SA negotiation may result in multiple security
> >    associations.  ESP and AH SAs exist in pairs (one in each direction),
> >    so two SAs are created in a single Child SA negotiation for them.
> >    Furthermore, Child SA negotiation may include some future IPsec
> >    protocol(s) in addition to, or instead of, ESP or AH (for example,
> >    ROHC_INTEG).  In any case, keying material for each child SA MUST be
> >    taken from the expanded KEYMAT using the following rules:
> > 
> >    o  All keys for SAs carrying data from the initiator to the responder
> >       are taken before SAs going from the responder to the initiator.
> > 
> >    o  If multiple IPsec protocols are negotiated, keying material for
> >       each Child SA is taken in the order in which the protocol headers
> >       will appear in the encapsulated packet.
> > 
> >    o  If an IPsec protocol requires multiple keys, the order in which
> >       they are taken from the SA's keying material needs to be described
> >       in protocol specification.  For ESP  and AH, [IPSECARCH] defines
> >       the order, namely: the encryption key (if any) MUST be taken from
> >       the first bits and the integrity key (if any) MUST be taken from
> >       the remaining bits.
> 
> Looks fine to me.

Looks good for me too.
-- 
kivinen@iki.fi

From Pasi.Eronen@nokia.com  Wed Jan 27 02:06:48 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F33C3A68A8 for ; Wed, 27 Jan 2010 02:06:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.029
X-Spam-Level: 
X-Spam-Status: No, score=-6.029 tagged_above=-999 required=5 tests=[AWL=0.570,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kzeEf36og2B for ; Wed, 27 Jan 2010 02:06:47 -0800 (PST)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id CE6C43A689D for ; Wed, 27 Jan 2010 02:06:46 -0800 (PST)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0RA6apT014008 for ; Wed, 27 Jan 2010 12:06:57 +0200
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 27 Jan 2010 12:06:10 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 27 Jan 2010 12:06:06 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Wed, 27 Jan 2010 11:06:05 +0100
From: 
To: 
Date: Wed, 27 Jan 2010 11:06:04 +0100
Thread-Topic: AD review of draft-ietf-ipsecme-aes-ctr-ikev2-04
Thread-Index: AcqfOFYJeKGBTdOtTw2PYvsrlRyoHg==
Message-ID: <808FD6E27AD4884E94820BC333B2DB7758411DDAE1@NOK-EUMSG-01.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 27 Jan 2010 10:06:06.0297 (UTC) FILETIME=[572C0C90:01CA9F38]
X-Nokia-AV: Clean
Subject: [IPsec] AD review of draft-ietf-ipsecme-aes-ctr-ikev2-04
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2010 10:06:48 -0000

Now that traffic-visibility has progressed, I've finally done my AD
review of draft-ietf-ipsecme-aes-ctr-ikev2-04.

This document copies most of its text verbatim from RFC 3686, and does
not even acknowledge the source (or have the disclaimer about pre-5378
text).

However, it's been noted that people have already managed to implement
AES CTR mode for IKEv2, because RFC 3686 and 4306 already contain 99%
of the details, and people have guessed the remaining 1%.

Instead of repeating several pages worth of complex technical text
(such as the precise definitions of CTR modes and their security
considerations), this document should focus on the remaining 1%.

Here's a rough sketch what the edits should look like:

- Keep the first two paragraphs of section 1, and whole 1.1 (and=20
  remove everything else)
- Remove section 2.
- Replace sections 3 and 4 with something like this:

   "When using AES-CTR in the IKEv2 Encrypted Payload, the
   Initialization Vector is 8 octets.  Requirements for this IV are
   specified in [RFC3686] Section 3.1; the counter block is
   constructed as specified in [RFC3686], Section 4.

   When AES-CTR is used in IKEv2, no padding is required; the Padding
   Length field of the Encrypted Payload SHOULD be set to
   zero. However, the recipient MUST accept any length."

- Replace section 5 with something like this:

   "The use of AES-CTR for the IKE SA is negotiated the same way as
   AES-CTR for ESP. The Transform ID (ENCR_AES_CTR) is the same; the
   key length transform attribute is used the same way; and the keying
   material (consisting of the actual key and the nonce) is derived
   the same way."

- Replace section 6 with something like this:

   "The security considerations for using AES-CTR in IKEv2 are similar
   to its use in ESP with fresh keys and integrity protection; see
   [RFC3686] for details.  (Note that static keys are never used for
   the IKE SA, and the IKE_SA always uses integrity protection.)"

- Replace section 7 with something like this:

   "The IKEv2 Encryption Transform ID "ENCR_AES_CTR" has already been
   assigned by IANA. IANA is asked to add a reference to this RFC in
   that entry."


With these changes, the whole document (without boilerplate and=20
reference list) should be probably less than two pages.

Best regards,
Pasi

From eabailey@us.ibm.com  Wed Jan 27 03:01:04 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E02C83A6A4D for ; Wed, 27 Jan 2010 03:01:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoN3dmlbMUCg for ; Wed, 27 Jan 2010 03:01:04 -0800 (PST)
Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by core3.amsl.com (Postfix) with ESMTP id 04F8E3A6A47 for ; Wed, 27 Jan 2010 03:01:03 -0800 (PST)
Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e33.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id o0RAvs9u013285 for ; Wed, 27 Jan 2010 03:57:54 -0700
Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o0RB0txv041848 for ; Wed, 27 Jan 2010 04:00:59 -0700
Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o0RB34ia018968 for ; Wed, 27 Jan 2010 04:03:04 -0700
Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av06.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o0RB33Do018965 for ; Wed, 27 Jan 2010 04:03:03 -0700
Auto-Submitted: auto-generated
From: Allen Bailey 
To: ipsec@ietf.org
Message-ID: 
Date: Wed, 27 Jan 2010 04:00:53 -0700
X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 01/27/2010 04:00:53
MIME-Version: 1.0
Content-type: multipart/alternative;  Boundary="0__=08BBFC2BDFAF070E8f9e8a93df938690918c08BBFC2BDFAF070E"
Content-Disposition: inline
Subject: [IPsec] AUTO: Allen Bailey is out of the office. (returning 02/08/2010)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2010 11:01:05 -0000

--0__=08BBFC2BDFAF070E8f9e8a93df938690918c08BBFC2BDFAF070E
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: quoted-printable



I am out of the office until 02/08/2010.

I will respond to your message when I return.


Note: This is an automated response to your message  "IPsec Digest, Vol=
 69,
Issue 71" sent on 1/26/10 23:39:49.

This is the only notification you will receive while this person is awa=
y.=

--0__=08BBFC2BDFAF070E8f9e8a93df938690918c08BBFC2BDFAF070E
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline
Content-transfer-encoding: quoted-printable



I am out of the office until 02/08/2010.



I will respond to your message when I return.




Note: This is an automated re=
sponse to your message  "IPsec Digest, =
Vol 69, Issue 71" se=
nt on 1/26/10 23:39:49. 



This is the only notification=
 you will receive while this person is away.=

--0__=08BBFC2BDFAF070E8f9e8a93df938690918c08BBFC2BDFAF070E--


From Pasi.Eronen@nokia.com  Wed Jan 27 03:38:22 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFD393A68FC for ; Wed, 27 Jan 2010 03:38:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.055
X-Spam-Level: 
X-Spam-Status: No, score=-6.055 tagged_above=-999 required=5 tests=[AWL=0.544,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzVQFN9-j6ys for ; Wed, 27 Jan 2010 03:38:21 -0800 (PST)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id D1F8A3A67F5 for ; Wed, 27 Jan 2010 03:38:20 -0800 (PST)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0RBcIVt004310 for ; Wed, 27 Jan 2010 13:38:29 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 27 Jan 2010 13:37:45 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 27 Jan 2010 13:37:45 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Wed, 27 Jan 2010 12:37:38 +0100
From: 
To: 
Date: Wed, 27 Jan 2010 12:37:38 +0100
Thread-Topic: AD review of draft-ietf-ipsecme-esp-null-heuristics-03
Thread-Index: AcqfRSC6xkpClHZlQnCjr9Nl/jw+1g==
Message-ID: <808FD6E27AD4884E94820BC333B2DB7758411DDBBD@NOK-EUMSG-01.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 27 Jan 2010 11:37:45.0879 (UTC) FILETIME=[252DAA70:01CA9F45]
X-Nokia-AV: Clean
Subject: [IPsec] AD review of draft-ietf-ipsecme-esp-null-heuristics-03
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2010 11:38:22 -0000

I've now done my AD review for the heuristics draft. Mostly the draft
looks good, and all my comments are relatively minor. Least-minor
first:

- Appendix A.1: The pseudocode has couple of places where it says
"Drop invalid packet"; it seems these are wrong when the packet is UDP
encapsulated (this could still be perfectly valid UDP traffic, just
something else than ESP).

- Section 8.1: AUTH_HMAC_MD5_128 and AUTH_HMAC_SHA1_160 are not
defined for IPsec ESP; these algorithms apply only to the FiberChannel
security protocols. So they should be removed from this list (and
since this was the only algorithm with 160-bit ICV, handling that=20
case can be removed).

- Section 8.1: AUTH_AES_128/192/256_GMAC cannot be used in ESP, only
in AH; for ESP, the relevant algorithm is ENCR_NULL_AUTH_AES_GMAC.

- Appendix A.1: shouldn't we also have tests for WESP here?
"If IP protocol is WESP, process as described in [traffic-visibility]"
"If first 4 bytes of UDP packet are 0x00000002, process as.. "
(the details of WESP don't belong there, though, and a pointer would
be quite sufficient IMHO)

- Appendix A.2, "Verify TCP": the bits that are currently reserved
might get allocated in the future (and half of the bits that were
reserved in RFC 793 have been since allocated -- so it's not very
clear exactly what "TCP.reserved_bits" means).

- The document doesn't cover RSA authentication in ESP (RFC 4359).=20
I guess this isn't really very relevant for environments where the
heuristics might be used, so perhaps a sentence saying this is beyond
the scope of this document would be sufficient.

- Section 2.1, suggesting that AH might have more bugs doesn't sound
like an argument that belongs in this document.

- Section 2.3: the discussion about IPv6 and NATs does not belong in
this document.

- Section 3, 2nd para: "state of the flows" -> "... IPsec flows"

Best regards,
Pasi

From Pasi.Eronen@nokia.com  Wed Jan 27 04:45:16 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CBE03A6901 for ; Wed, 27 Jan 2010 04:45:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.139
X-Spam-Level: 
X-Spam-Status: No, score=-6.139 tagged_above=-999 required=5 tests=[AWL=0.460,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZZIhsWfb4Gm for ; Wed, 27 Jan 2010 04:45:15 -0800 (PST)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 1D2733A689A for ; Wed, 27 Jan 2010 04:45:14 -0800 (PST)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0RCjPJo007090 for ; Wed, 27 Jan 2010 14:45:26 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 27 Jan 2010 14:44:59 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.5]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 27 Jan 2010 14:44:59 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Wed, 27 Jan 2010 13:44:58 +0100
From: 
To: 
Date: Wed, 27 Jan 2010 13:44:57 +0100
Thread-Topic: [IPsec] Issue #139: Keying material taken in the order for RoHC
Thread-Index: AcqfMjHI8rBikzWcSQ2O1FsknFTeeAAHELzw
Message-ID: <808FD6E27AD4884E94820BC333B2DB7758411DDDFA@NOK-EUMSG-01.mgdnok.nokia.com>
References: <064.cff10879f1e3e888fa8930a85464b847@tools.ietf.org>  <8C41856B-9D3B-4442-B214-5ED60C23906A@checkpoint.com>	<192 88.15645.382443.519149@fireball.kivinen.iki.fi>		<19288.48466.976054.136453@fireball.kivinen.iki.fi>  <1BDA56B00626423DA442A39B4703BDF8@trustworks.com>  <3ED373FCE26B4B24A3C3D5B31E7DC0F5@chichi>  <86AF78D23760458FAD7FD3E1950E71EE@trustworks.com> <19296.1417.337564.671788@fireball.kivinen.iki.fi>
In-Reply-To: <19296.1417.337564.671788@fireball.kivinen.iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 27 Jan 2010 12:44:59.0420 (UTC) FILETIME=[895B2DC0:01CA9F4E]
X-Nokia-AV: Clean
Subject: Re: [IPsec] Issue #139: Keying material taken in the order for RoHC
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2010 12:45:16 -0000

+1.

Best regards,
Pasi
(not wearing any hats)

> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
> Of ext Tero Kivinen
> Sent: 27 January, 2010 11:21
> To: Valery Smyslov
> Cc: ipsec@ietf.org; Black_David@emc.com; Paul Hoffman
> Subject: Re: [IPsec] Issue #139: Keying material taken in the order for
> RoHC
>=20
> Valery Smyslov writes:
> > Paul Hoffman writes:
> > > All good points, Valery. Here's another attempt; please check
> carefully.
> > >
> > >    A single CHILD_SA negotiation may result in multiple security
> > >    associations.  ESP and AH SAs exist in pairs (one in each
> direction),
> > >    so two SAs are created in a single Child SA negotiation for
> them.
> > >    Furthermore, Child SA negotiation may include some future IPsec
> > >    protocol(s) in addition to, or instead of, ESP or AH (for
> example,
> > >    ROHC_INTEG).  In any case, keying material for each child SA
> MUST be
> > >    taken from the expanded KEYMAT using the following rules:
> > >
> > >    o  All keys for SAs carrying data from the initiator to the
> responder
> > >       are taken before SAs going from the responder to the
> initiator.
> > >
> > >    o  If multiple IPsec protocols are negotiated, keying material
> for
> > >       each Child SA is taken in the order in which the protocol
> headers
> > >       will appear in the encapsulated packet.
> > >
> > >    o  If an IPsec protocol requires multiple keys, the order in
> which
> > >       they are taken from the SA's keying material needs to be
> described
> > >       in protocol specification.  For ESP  and AH, [IPSECARCH]
> defines
> > >       the order, namely: the encryption key (if any) MUST be taken
> from
> > >       the first bits and the integrity key (if any) MUST be taken
> from
> > >       the remaining bits.
> >
> > Looks fine to me.
>=20
> Looks good for me too.
> --
> kivinen@iki.fi
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

From kivinen@iki.fi  Wed Jan 27 06:29:10 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E0943A6A9D for ; Wed, 27 Jan 2010 06:29:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.506
X-Spam-Level: 
X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXiyCGLZRh0R for ; Wed, 27 Jan 2010 06:29:09 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 6967A3A6A5D for ; Wed, 27 Jan 2010 06:29:07 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0RETIuL008523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jan 2010 16:29:18 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0RETHdk026123; Wed, 27 Jan 2010 16:29:17 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19296.19901.825611.27758@fireball.kivinen.iki.fi>
Date: Wed, 27 Jan 2010 16:29:17 +0200
From: Tero Kivinen 
To: 
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7758411DDBBD@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB7758411DDBBD@NOK-EUMSG-01.mgdnok.nokia.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 23 min
X-Total-Time: 47 min
Cc: ipsec@ietf.org
Subject: [IPsec]  AD review of draft-ietf-ipsecme-esp-null-heuristics-03
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2010 14:29:10 -0000

Pasi.Eronen@nokia.com writes:
> I've now done my AD review for the heuristics draft. Mostly the draft
> looks good, and all my comments are relatively minor. Least-minor
> first:
> 
> - Appendix A.1: The pseudocode has couple of places where it says
> "Drop invalid packet"; it seems these are wrong when the packet is UDP
> encapsulated (this could still be perfectly valid UDP traffic, just
> something else than ESP).

True. Changed those now to continue packet processing with some
comments explaining the situation. 

> - Section 8.1: AUTH_HMAC_MD5_128 and AUTH_HMAC_SHA1_160 are not
> defined for IPsec ESP; these algorithms apply only to the FiberChannel
> security protocols. So they should be removed from this list (and
> since this was the only algorithm with 160-bit ICV, handling that 
> case can be removed).

Removed.

> - Section 8.1: AUTH_AES_128/192/256_GMAC cannot be used in ESP, only
> in AH; for ESP, the relevant algorithm is ENCR_NULL_AUTH_AES_GMAC.

True. Removed AUTH_AES*_GMAC and added paragraph explaining about the
ENCR_NULL_AUTH_AES_GMAC:

    In addition to the ESP authentication algorithms listed above,
    there is also encryption algorithm ENCR_NULL_AUTH_AES_GMAC which
    does not provide confidentiality but provides authentication, just
    like ESP-NULL does. This algorithm has ICV Length of 128 bits, and
    it also requires eight bytes of IV.

(this is just after the Algorithm / ICV Length table before the
paragarph about the IV). 

> - Appendix A.1: shouldn't we also have tests for WESP here?
> "If IP protocol is WESP, process as described in [traffic-visibility]"
> "If first 4 bytes of UDP packet are 0x00000002, process as.. "
> (the details of WESP don't belong there, though, and a pointer would
> be quite sufficient IMHO)

Added reference and basic selection rules:
----------------------------------------------------------------------
////////////////////////////////////////////////////////////
// This is the main processing code for the packet
// This will check if the packet requires ESP processing,
//
Process packet:
  * If IP protocol is ESP
       * Set SPI_offset to 0 bytes
       * Goto Process ESP
  * If IP protocol is UDP
       * Goto Process UDP
  * If IP protocol is WESP
       // For information about WESP processing see WESP
       // specification.
       * Continue WESP processing
  * Continue Non-ESP processing

////////////////////////////////////////////////////////////
// This code is run for UDP packets, and it checks if the
// packet is UDP encapsulated UDP packet, or UDP
// encapsulated IKE packet, or keepalive packet.
//
Process UDP:
  // Reassembly is not mandatory here, we could
  // do reassembly also only after detecting the
  // packet being UDP encapsulated ESP packet, but
  // that would complicated the pseudocode here
  // a lot, as then we would need to add code
  // for checking if the UDP header is in this
  // packet or not.
  // Reassembly is to simplify things
  * If packet is fragment
       * Do full reassembly before processing
  * If UDP_src_port != 4500 and UDP_dst_port != 4500
       * Continue Non-ESP processing
  * Set SPI_offset to 8 bytes
  * If UDP_len > 4 and first 4 bytes of UDP packet are 0x000000
       * Continue Non-ESP processing (pass IKE-packet)
  * If UDP_len > 4 and first 4 bytes of UDP packet are 0x000002
       * Continue WESP processing
  * If UDP_len == 1 and first byte is 0xff
       * Continue Non-ESP processing (pass NAT-Keepalive Packet)
  * Goto Process ESP

----------------------------------------------------------------------

Cannot add reference to WESP directly there in pseudocode, as xmltorfc
seems to barf if I try to put  inside the artwork. We do have
reference to WESP already in the main body of text.

> - Appendix A.2, "Verify TCP": the bits that are currently reserved
> might get allocated in the future (and half of the bits that were
> reserved in RFC 793 have been since allocated -- so it's not very
> clear exactly what "TCP.reserved_bits" means).

All of those tests are something that depends on other standards, i.e.
TCP. Normally deep inspection engines etc will check all kind of TCP
fields, and depending on the them does something (drop, pass, clear,
set, modify etc), and usually those people writing the deep inspection
engines etc have quite good idea which bits they can check and which
not.

The reason we do not explictly mention what reserved_bits is just
because it can change in future. 

> - The document doesn't cover RSA authentication in ESP (RFC 4359). 
> I guess this isn't really very relevant for environments where the
> heuristics might be used, so perhaps a sentence saying this is beyond
> the scope of this document would be sufficient.

Added paragraph to the end of ESP-NULL format:

   This document does not cover RSA authentication in ESP ([RFC4359]),
   as it is considered being beyond the scope of this document.

> - Section 2.1, suggesting that AH might have more bugs doesn't sound
> like an argument that belongs in this document.

It was one of the arguments which was given when people said why they
do not want to use AH. 

> - Section 2.3: the discussion about IPv6 and NATs does not belong in
> this document.

I am trying explain there why I do not belive that modifying all end
peer is that easy thing to do, and modifying the intermediate devices
instead is much faster to deploy.

I think it provides reasons why people might want to implement this
even when WESP is the other alternative.

> - Section 3, 2nd para: "state of the flows" -> "... IPsec flows"

Added "IPsec".

I will submit new -04 version now. Argh, I mean I will submit it AFTER
I have updated my xml2rfc tools again!
-- 
kivinen@iki.fi

From root@core3.amsl.com  Wed Jan 27 06:45:03 2010
Return-Path: 
X-Original-To: ipsec@ietf.org
Delivered-To: ipsec@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 9AEBF3A6AA0; Wed, 27 Jan 2010 06:45:02 -0800 (PST)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20100127144502.9AEBF3A6AA0@core3.amsl.com>
Date: Wed, 27 Jan 2010 06:45:02 -0800 (PST)
Cc: ipsec@ietf.org
Subject: [IPsec] I-D Action:draft-ietf-ipsecme-esp-null-heuristics-04.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2010 14:45:03 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF.


	Title           : Heuristics for Detecting ESP-NULL packets
	Author(s)       : T. Kivinen, D. McDonald
	Filename        : draft-ietf-ipsecme-esp-null-heuristics-04.txt
	Pages           : 37
	Date            : 2010-01-27

This document describes a set of heuristics for distinguishing IPsec
ESP-NULL (Encapsulating Security Payload without encryption) packets
from encrypted ESP packets.  These heuristics can be used on
intermediate devices, like traffic analyzers, and deep inspection
engines, to quickly decide whether given packet flow is interesting
or not.  Use of these heuristics does not require any changes made on
existing RFC4303 compliant IPsec hosts.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-esp-null-heuristics-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ipsecme-esp-null-heuristics-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-01-27063917.I-D@ietf.org>


--NextPart--

From A.Hoenes@TR-Sys.de  Wed Jan 27 08:38:52 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 070F93A6961 for ; Wed, 27 Jan 2010 08:38:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.566
X-Spam-Level: 
X-Spam-Status: No, score=0.566 tagged_above=-999 required=5 tests=[AWL=-0.685,  BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNSV8JK3WCFq for ; Wed, 27 Jan 2010 08:38:50 -0800 (PST)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id A772B3A6359 for ; Wed, 27 Jan 2010 08:38:49 -0800 (PST)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA271640330; Wed, 27 Jan 2010 17:38:50 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id RAA08437; Wed, 27 Jan 2010 17:38:49 +0100 (MEZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?= 
Message-Id: <201001271638.RAA08437@TR-Sys.de>
To: ipsec@ietf.org
Date: Wed, 27 Jan 2010 17:38:49 +0100 (MEZ)
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 7bit
Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-esp-null-heuristics-03 -- TCP flags
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2010 16:38:52 -0000

Regarding Pasi's comment on TCP header flags:

> - Appendix A.2, "Verify TCP": the bits that are currently reserved
>   might get allocated in the future (and half of the bits that were
>   reserved in RFC 793 have been since allocated -- so it's not very
>   clear exactly what "TCP.reserved_bits" means).

Please note that the second diagram at
   
does not represent the current state of assignments.
It is drawn from RFC 3168 and does not depict the assignment
performed for RFC 3540.
The effective current state is shown in the diagram below.

(However, note that there are already proposals floating around
 to make use of the remaining available flags, e.g. for PCN
 signalling, IIRC.)

Generally, 'mbz' fields should never be checked by destination
systems or intermediate systems that don't support functionality
related to such bits specified in more recent documents --
otherwise transparency and protocol extensibility would be
impacted substantially.

RFC 2780 simply says:

|9.2 Reserved Bits in TCP Header
|
|  The reserved bits in the TCP header are assigned following a
|  Standards Action process.

... and RFC 4717 says:

|7.2.  Reserved Bits in TCP Header
|
|  There are not enough reserved bits to allocate any for
|  experimentation.

The TCP section of RFC 1812 refers to the IP sections of that document
for generally applicable rules, and there it states:

                                    [...]  A router MUST NOT set either
   of these bits to one in datagrams originated by the router.  A router
   MUST NOT drop (refuse to receive or forward) a packet merely because
   one or more of these reserved bits has a non-zero value; i.e., the
   router MUST NOT check the values of thes bits.

and later:

                                       [...]   Routers MUST NOT drop
     packets merely because one or more of these reserved bits has a
     non-zero value.



The aforementioned IANA registry should say (a request for correction
has been stalled long ago; at some point in time, I ran out of energy
to insist on action and follow up) -- change bars mark modified lines:


--------snip--------

The Transmission Control Protocol (TCP) included a 6-bit Reserved
field defined in RFC 793, reserved for future use, in bytes 13 and 14
of the TCP header, as illustrated below.
The other six Control bits are defined separately by RFC 793.

     0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |               |                       | U | A | P | R | S | F |
   | Header Length |        Reserved       | R | C | S | S | Y | I |
   |               |                       | G | K | H | T | N | N |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

|RFC 3168 defines two of the six bits from the RFC 793 Reserved field
|to be used for ECN, and RFC 3540 added another bit, as follows:

     0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|  |               |           | N | C | E | U | A | P | R | S | F |
|  | Header Length | Reserved  | S | W | C | R | C | S | S | Y | I |
|  |               |           |   | R | E | G | K | H | T | N | N |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

--------snip--------


Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |
+------------------------+--------------------------------------------+


From wierbows@us.ibm.com  Wed Jan 27 12:48:50 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93BE83A67FB for ; Wed, 27 Jan 2010 12:48:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wx+tDXeTAEgg for ; Wed, 27 Jan 2010 12:48:49 -0800 (PST)
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by core3.amsl.com (Postfix) with ESMTP id 9D3403A635F for ; Wed, 27 Jan 2010 12:48:49 -0800 (PST)
Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e4.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o0RKd3F5005023 for ; Wed, 27 Jan 2010 15:39:03 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o0RKn4xX115444 for ; Wed, 27 Jan 2010 15:49:04 -0500
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o0RKn3J6024320 for ; Wed, 27 Jan 2010 18:49:03 -0200
Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av02.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o0RKn3JL024317 for ; Wed, 27 Jan 2010 18:49:03 -0200
X-KeepSent: 44BADDAD:EF28F322-852576B8:00720BF1; type=4; name=$KeepSent
To: IPsecme WG 
X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009
Message-ID: 
From: David Wierbowski 
Date: Wed, 27 Jan 2010 15:49:02 -0500
X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 01/27/2010 15:49:03
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Subject: [IPsec] Issue #172: Config payload text in Section 4
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2010 20:48:50 -0000

 Section 4 of IKEv2bis states:

    A minimal IPv4 responder implementation will ignore the contents of
    the CP payload except to determine that it includes an
    INTERNAL_IP4_ADDRESS attribute and will respond with the address and
    other related attributes regardless of whether the initiator
    requested them.

    A minimal IPv4 initiator will generate a CP payload containing only
    an INTERNAL_IP4_ADDRESS attribute and will parse the response
    ignoring attributes it does not know how to use.

 The terms "minimal IPv4 responder implementation" and "minimal IPv4
 initiator" are confusing and misleading.  This text is a  restatement of
 the previous paragraph.

 This text should be removed or reworded to describe IPv6 implementation
 behavior to the same extent. It should also be reworded to clarify what
 is meant by "minimal implementation." Since responding to a config payload
 is optional, a "minimal implementation" in this context must refer to an
 implementation that minimally supports responding to a config payload.

 The recommendation is to remove this paragraph.  It adds no new
 information and adds no clarify to the text in the previous paragraph.


Dave Wierbowski


z/OS Comm Server Developer

 Phone:
    Tie line:   620-4055
    External:  607-429-4055




From kohn.jack@gmail.com  Wed Jan 27 16:17:53 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AB7B3A68C0 for ; Wed, 27 Jan 2010 16:17:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N64a9+-m64uW for ; Wed, 27 Jan 2010 16:17:52 -0800 (PST)
Received: from mail-yw0-f201.google.com (mail-yw0-f201.google.com [209.85.211.201]) by core3.amsl.com (Postfix) with ESMTP id 7EB2B3A6AE2 for ; Wed, 27 Jan 2010 16:17:52 -0800 (PST)
Received: by ywh39 with SMTP id 39so372186ywh.17 for ; Wed, 27 Jan 2010 16:18:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0KrAXafKBQAm/IoqbBok/UTlenLfwnUBgPEzD0uWcag=; b=uyMe5Ag0xZQDmF0lGNYKlpd7Q+2flSrJ9ReE+PvCNMVSzZ8NTpZXBQZFcIpUp62g6f z/Yw6V13I4kKhF+G+ZkFxhWgJqiVAhiwc26lKo1JLn4bHPVfFxtJQldvLEKCFT8/rG/W qvoWhzj+mGNlCI4XjK/mbFSCKi+Uy5/W/AHOA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=K5TpP1EWCTbYSrzqR/BIXu5Pz5hqTG7J6jfMR4dizNPPRFDfpSIwiaUzC/G1atvYm/ q5TfDAaXml95nP3QcvYbkY/M39P5TK/a7/a7Tsibu8kxKli9SSzZAL6+mxHfGXoA9Mih nDXtt86p/mRegB/AJDiu7pLkyOwQUHGMCeSNk=
MIME-Version: 1.0
Received: by 10.91.160.30 with SMTP id m30mr1488404ago.1.1264637884808; Wed,  27 Jan 2010 16:18:04 -0800 (PST)
In-Reply-To: <20100127144502.9AEBF3A6AA0@core3.amsl.com>
References: <20100127144502.9AEBF3A6AA0@core3.amsl.com>
Date: Thu, 28 Jan 2010 05:48:04 +0530
Message-ID: 
From: Jack Kohn 
To: ipsec@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Pasi.Eronen@nokia.com, Tero Kivinen 
Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-esp-null-heuristics-04.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2010 00:17:53 -0000

Hi,

Do folks have to implement this RFC since its of the INFORMATIONAL type?

If Yes, then i would like some sort of resolution to the issues raised in
http://www.ietf.org/mail-archive/web/ipsec/current/msg05471.html

As a developer i would like to understand as to how i am required to
do cache management, etc and some pointers to this effect would be
appreciated.

I also think that we need to mention that this does open up a window
for DoS attacks as explained in the above post in the Security
Considerations section.

Jack

On Wed, Jan 27, 2010 at 8:15 PM,   wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
> This draft is a work item of the IP Security Maintenance and Extensions W=
orking Group of the IETF.
>
>
> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Heuristics for Detecting ESP-N=
ULL packets
> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : T. Kivinen, D. McDonald
> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-ipsecme-esp-null-heur=
istics-04.txt
> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 37
> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-01-27
>
> This document describes a set of heuristics for distinguishing IPsec
> ESP-NULL (Encapsulating Security Payload without encryption) packets
> from encrypted ESP packets. =A0These heuristics can be used on
> intermediate devices, like traffic analyzers, and deep inspection
> engines, to quickly decide whether given packet flow is interesting
> or not. =A0Use of these heuristics does not require any changes made on
> existing RFC4303 compliant IPsec hosts.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-esp-null-heuristic=
s-04.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
>

From paul.hoffman@vpnc.org  Wed Jan 27 17:26:31 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6A2D3A68BE for ; Wed, 27 Jan 2010 17:26:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.065
X-Spam-Level: 
X-Spam-Status: No, score=-6.065 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CNsCNo6Bw+b for ; Wed, 27 Jan 2010 17:26:31 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id E17993A6879 for ; Wed, 27 Jan 2010 17:26:30 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0S1M4xk021732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jan 2010 18:22:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: <20100127144502.9AEBF3A6AA0@core3.amsl.com> 
Date: Wed, 27 Jan 2010 17:22:03 -0800
To: Jack Kohn , ipsec@ietf.org
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Cc: Pasi.Eronen@nokia.com, Tero Kivinen 
Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-esp-null-heuristics-04.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2010 01:26:31 -0000

At 5:48 AM +0530 1/28/10, Jack Kohn wrote:
>Do folks have to implement this RFC since its of the INFORMATIONAL type?

No one has to implement anything, ever. You don't have implement every IETF standard, only the ones you want. To be clear: I'm not being facetious. The fact that something is on standards track or is experimental or informational is not correlated to whether or not you want to implement it.

--Paul Hoffman, Director
--VPN Consortium

From kivinen@iki.fi  Thu Jan 28 03:13:55 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE7EC3A690F for ; Thu, 28 Jan 2010 03:13:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.511
X-Spam-Level: 
X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMqgWtMm9JIn for ; Thu, 28 Jan 2010 03:13:54 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 528BF3A6A02 for ; Thu, 28 Jan 2010 03:13:53 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0SBE5i9020293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jan 2010 13:14:05 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0SBE3Mc002156; Thu, 28 Jan 2010 13:14:03 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19297.29051.606291.367732@fireball.kivinen.iki.fi>
Date: Thu, 28 Jan 2010 13:14:03 +0200
From: Tero Kivinen 
To: Jack Kohn 
In-Reply-To: 
References: <20100127144502.9AEBF3A6AA0@core3.amsl.com> 
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 10 min
X-Total-Time: 14 min
Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com
Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-esp-null-heuristics-04.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2010 11:13:55 -0000

Jack Kohn writes:
> Do folks have to implement this RFC since its of the INFORMATIONAL
> type?

No, and same applies to WESP. You need either (or both) them only and
only if you operate in enviroments where they are suitable, and where
you require features provided by them. 

> If Yes, then i would like some sort of resolution to the issues raised in
> http://www.ietf.org/mail-archive/web/ipsec/current/msg05471.html

I do not see any explicit issues raised in the that email, mostly I
see comments saying mixing up TCP/UDP flows (which can be short lived)
and IPsec flows (which usually are not short lived), and comments that
it is not suitable for certain limited platforms.

> As a developer i would like to understand as to how i am required to
> do cache management, etc and some pointers to this effect would be
> appreciated.

This is engineering problem that does not really affect the heuristics
that much, and there is lots of algorithms that can be used there.
Which of them is best depends quite a lot about the network
environments. In some environments one alrogithm works best, and on
some other environments some other algorithm is better.

There are already devices which solve much harder problems, for
example deep inspection engine devices (intrusion detection and/or
preventation systems). The problems they solve are much harder than
what heuristics needs to do as they need to keep track on each UDP and
TCP flow separately. Heuristics only need to keep track of IPsec SAs.

Usually single IPsec SA has multiple TCP/UDP flows inside, so the
problem of keeping track IPsec flows is easier than keeping track of
TCP/UDP flows.

As this problem of keeping track of TCP/UDP flows has already been
solved by multiple vendors, in multiple products, I do not think we
need to start writing text about the cache management or algorithms.
This problem is not specific to the ESP-NULL heuristics, it is generic
flow management problem, which have been solved before.

> I also think that we need to mention that this does open up a window
> for DoS attacks as explained in the above post in the Security
> Considerations section.

What DoS attack you are talking. If you can provide me some text I can
put to draft, I am happy to do so, but anyways I would first need to
know which DoS attack you are talking about.
-- 
kivinen@iki.fi

From Pasi.Eronen@nokia.com  Thu Jan 28 03:18:02 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95CC13A68A8 for ; Thu, 28 Jan 2010 03:18:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.2
X-Spam-Level: 
X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkHVV4DRCBxO for ; Thu, 28 Jan 2010 03:18:01 -0800 (PST)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id A54BF3A6A0A for ; Thu, 28 Jan 2010 03:17:59 -0800 (PST)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0SBHoVs007762; Thu, 28 Jan 2010 13:18:12 +0200
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 28 Jan 2010 13:18:05 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 28 Jan 2010 13:18:00 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Thu, 28 Jan 2010 12:18:00 +0100
From: 
To: 
Date: Thu, 28 Jan 2010 12:17:58 +0100
Thread-Topic: [IPsec] IKEv2-bis comments: 2.17 and onwards (#170)
Thread-Index: Acqefet9N9QRkdlYRySaGE1ZMRPbDgBjWOEw
Message-ID: <808FD6E27AD4884E94820BC333B2DB7758411DE72F@NOK-EUMSG-01.mgdnok.nokia.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF8A804C9@il-ex01.ad.checkpoint.com>  <808FD6E27AD4884E94820BC333B2DB775841199C1B@NOK-EUMSG-01.mgdnok.nokia.com> <19294.55083.300196.793537@fireball.kivinen.iki.fi>
In-Reply-To: <19294.55083.300196.793537@fireball.kivinen.iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 28 Jan 2010 11:18:00.0499 (UTC) FILETIME=[8D0CC830:01CAA00B]
X-Nokia-AV: Clean
Cc: ipsec@ietf.org, paul.hoffman@vpnc.org
Subject: Re: [IPsec] IKEv2-bis comments: 2.17 and onwards (#170)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2010 11:18:02 -0000

Tero Kivinen wrote:
> Pasi.Eronen@nokia.com writes:
> > Paul Hoffman wrote:
> >
> > > >B.1 (Group 1): We may want to add: "Use of this group is NOT
> > > RECOMMENDED."
> > >
> > > Please open a tracker issue for this. Even though this is obvious,
> > > it is a tad late to be suggesting new normative language.
> >
> > This "NOT RECOMMENDED" would belong in an update to RFC 4307,
> > not this document.
>=20
> The current RFC4306 Security Considerations section already says:
>=20
>             Group one is for historic purposes only and does not
>    provide sufficient strength except for use with DES, which is also
>    for historic use only.
>=20
> and I would think that group and algorithms which are historic use
> only, are also NOT RECOMMENDED...
>=20
> And yes, I agree it should really be in RFC4307, but the group is
> defined here, so word of it not being recommended, might be good idea
> in this document too.

Hmm... I think the current security considerations text is quite=20
sufficient to discourage people from using this, and repeating the same=20
thing with upper-case RFC 2119 keywords doesn't seem to add anything
(and we have earlier agreed those keywords belong in a separate=20
document anyway).

Best regards,
Pasi

From Pasi.Eronen@nokia.com  Thu Jan 28 03:31:05 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6D3A3A68FB for ; Thu, 28 Jan 2010 03:31:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.213
X-Spam-Level: 
X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=0.386,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxIrRdjvfP+d for ; Thu, 28 Jan 2010 03:31:04 -0800 (PST)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 7A8A33A67AD for ; Thu, 28 Jan 2010 03:31:04 -0800 (PST)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0SBUtgq016422; Thu, 28 Jan 2010 13:31:19 +0200
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 28 Jan 2010 13:31:07 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 28 Jan 2010 13:30:57 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Thu, 28 Jan 2010 12:30:57 +0100
From: 
To: 
Date: Thu, 28 Jan 2010 12:30:55 +0100
Thread-Topic: [IPsec] RFC5555 and Section 2.23.1 (was:  IKEv2bis, comments about sections 1-2)
Thread-Index: AcqegS7zsFmd23lQQCyhmHuDRqEPBwBinYuw
Message-ID: <808FD6E27AD4884E94820BC333B2DB7758411DE74C@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB7758410A954B@NOK-EUMSG-01.mgdnok.nokia.com> <19285.37771.259456.852530@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB775841199BC3@NOK-EUMSG-01.mgdnok.nokia.com> <19294.56491.761386.235273@fireball.kivinen.iki.fi>
In-Reply-To: <19294.56491.761386.235273@fireball.kivinen.iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 28 Jan 2010 11:30:57.0514 (UTC) FILETIME=[5C2FDCA0:01CAA00D]
X-Nokia-AV: Clean
Cc: ipsec@ietf.org
Subject: Re: [IPsec] RFC5555 and Section 2.23.1 (was:  IKEv2bis, comments about sections 1-2)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2010 11:31:05 -0000

Tero Kivinen wrote:

> > > What kind of things does the RFC5555 require?
> >
> > Basically, it's assuming that even if you're running IKEv2 over IPv4
> > (and that IPv4 address is NATted), you can still negotiate transport
> > mode SAs for IPv6 addresses (which won't get NATted).
>=20
> Hmm.... Let me see. They have IKEv2 session running over IPv4
> addresses, and then they try to create IPsec SA using IPv6 addresses
> using transport mode over that IKEv2 SA. How are they going to do it,
> as section 2.11 says:
>=20
> ----------------------------------------------------------------------
> 2.11.  Address and Port Agility
>=20
>    IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and
>    AH associations for the same IP addresses it runs over.
> ----------------------------------------------------------------------
>=20
> which usually means that for transport mode the addresses you expect
> to se on ESP packets are same as what they were for the IKE packet
> too, which is impossible now as the IKEv2 runs over IPv4, but ESP
> packets run over IPv6.

Hmm... What exactly that text means is actually a good question. =20
If you have a multi-homed host using SCTP, for example, it would make
sense to create a transport mode SA whose traffic selectors include
more than one IP address. If there are no NATs, this would work fine
(even though only one of the addresses in TS payloads would be equal
to the address used for sending the IKE packet).

So I'm not so sure if this text really prohibits the situation where
transport mode traffic selectors aren't exactly the same as the
addresses used for sending the IKE packet...
=20
> Also even if they use packet where src =3D IP1 (ipv4), and dst =3D IPN2
> (ipv4) and then it is natted twice to src =3D IPN1 (ipv4) and dst =3D IP2
> (ipv4) (using the picture in section 2.23.1), with traffic selectors:
>=20
>    TSi =3D any, any, src-IPv6-address - src-IPv6-address
>    TSr =3D any, any, dst-IPv6-address - dst-IPv6-address
>=20
> and try to negotiate transport mode using those traffic selectors, I
> think most of the implementations will not allow such SA to be
> created.

Well, this is not the only place where RFC5555 may not work with just
any IPsec implementation, and can require MIP-specific tweaks...=20
(search for "implementation" in Section 5 if you really want to know)
=20
> As there is no NAT for the IPv6 addresses, then the SPD lookup based
> on the traffic selectors would be fine, but there is no way to know
> whether there is NAT between the IPv6 address or not, as we only
> tested the presense of NAT for IPv4 addresses.

Yes, that's true. (And even if you know there's NAT, you would not know
what the mapped addresses are.)
=20
> I think the only easy solution to that kind of problem is to run two
> IKEv2 SAs between the peer, one for IPv4 traffic using NAT'ed IPv4
> addresses, and another using IPv6 addresses and IPv6 transport mode
> traffic.
>=20
> It seems the RFC5555 is trying to break the section 2.11 rule, and
> thinks IKE can be used in such way to create SAs between any
> IP-addresses instead between the address over which the IKE SA runs
> on.

Personally, I've come to the conclusion that the IPsec text in RFC
5555 was a big mistake (and I share some blame for much of that=20
text -- at the time it was written, I still thought it was just ugly,=20
but would work)...

Best regards,
Pasi

From Pasi.Eronen@nokia.com  Thu Jan 28 04:18:16 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9FCC3A6A08 for ; Thu, 28 Jan 2010 04:18:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.236
X-Spam-Level: 
X-Spam-Status: No, score=-6.236 tagged_above=-999 required=5 tests=[AWL=0.363,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKZqkOeCn8Py for ; Thu, 28 Jan 2010 04:18:15 -0800 (PST)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 30D633A6814 for ; Thu, 28 Jan 2010 04:18:15 -0800 (PST)
Received: from mgw-mx09.nokia.com ([192.100.105.134]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0SCIR1M010038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 28 Jan 2010 14:18:29 +0200
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0SCI9eC032691; Thu, 28 Jan 2010 06:18:26 -0600
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 28 Jan 2010 14:18:20 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 28 Jan 2010 14:18:16 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Thu, 28 Jan 2010 13:18:15 +0100
From: "Pasi.Eronen@nokia.com" 
To: 
Date: Thu, 28 Jan 2010 13:18:15 +0100
Thread-Topic: [IPsec] AD review of draft-ietf-ipsecme-esp-null-heuristics-03
Thread-Index: AcqfXS0vkfRgqv27SES7u3zJVfGHJQAtXWhg
Message-ID: <808FD6E27AD4884E94820BC333B2DB775841227024@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB7758411DDBBD@NOK-EUMSG-01.mgdnok.nokia.com> <19296.19901.825611.27758@fireball.kivinen.iki.fi>
In-Reply-To: <19296.19901.825611.27758@fireball.kivinen.iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 28 Jan 2010 12:18:16.0133 (UTC) FILETIME=[F822BF50:01CAA013]
X-Nokia-AV: Clean
Cc: ipsec@ietf.org
Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-esp-null-heuristics-03
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2010 12:18:17 -0000

Tero Kivinen wrote:

> > - Section 8.1: AUTH_HMAC_MD5_128 and AUTH_HMAC_SHA1_160 are not
> > defined for IPsec ESP; these algorithms apply only to the
> > FiberChannel security protocols. So they should be removed from
> > this list (and since this was the only algorithm with 160-bit ICV,
> > handling that case can be removed).
>=20
> Removed.

Section 8.2 still has some old text that assumes five (instead of
four) different ICV lengths.


> > - Appendix A.2, "Verify TCP": the bits that are currently reserved
> > might get allocated in the future (and half of the bits that were
> > reserved in RFC 793 have been since allocated -- so it's not very
> > clear exactly what "TCP.reserved_bits" means).
>=20
> All of those tests are something that depends on other standards, i.e.
> TCP. Normally deep inspection engines etc will check all kind of TCP
> fields, and depending on the them does something (drop, pass, clear,
> set, modify etc), and usually those people writing the deep inspection
> engines etc have quite good idea which bits they can check and which
> not.
>=20
> The reason we do not explictly mention what reserved_bits is just
> because it can change in future.

The reserved bits MUST be ignored if you don't understand them,
so testing whether they're zero (and returning failure if they're not)
is not correct behavior here (and would unnecessarily complicate deployment
of new TCP features in the future).


> > - Section 2.1, suggesting that AH might have more bugs doesn't sound
> > like an argument that belongs in this document.
>=20
> It was one of the arguments which was given when people said why they
> do not want to use AH.

Nevertheless, as it's currently written, it sounds more like FUD=20
than a reasonable argument. Let's just delete it.

> > - Section 2.3: the discussion about IPv6 and NATs does not belong in
> > this document.
>=20
> I am trying explain there why I do not belive that modifying all end
> peer is that easy thing to do, and modifying the intermediate devices
> instead is much faster to deploy.
>
> I think it provides reasons why people might want to implement this
> even when WESP is the other alternative.

I understand the argument you're making, and I think for ESP-NULL
heuristics, it's a reasonable argument.

But the comparison to IPv6 is very misleading here -- I think many
folks would argue that for IPv6 it's been easier to update the end
nodes (many of which do support IPv6 today) than the intermediate
nodes (when e.g. travelling, how often do you find that the
routers/whatever in the access network actually provide v6?). And
probably some folks would say this argument is too simplistic and
wrong, too -- either way, it's not a discussion for this document.

Best regards,
Pasi

From kivinen@iki.fi  Thu Jan 28 04:18:26 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD44628C0E5 for ; Thu, 28 Jan 2010 04:18:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.517
X-Spam-Level: 
X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmCeGRTi1f2u for ; Thu, 28 Jan 2010 04:18:19 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 424153A67AD for ; Thu, 28 Jan 2010 04:18:17 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0SCIUQc002737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jan 2010 14:18:30 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0SCITVo006506; Thu, 28 Jan 2010 14:18:29 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19297.32917.576733.476032@fireball.kivinen.iki.fi>
Date: Thu, 28 Jan 2010 14:18:29 +0200
From: Tero Kivinen 
To: 
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7758411DE74C@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB7758410A954B@NOK-EUMSG-01.mgdnok.nokia.com> <19285.37771.259456.852530@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB775841199BC3@NOK-EUMSG-01.mgdnok.nokia.com> <19294.56491.761386.235273@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7758411DE74C@NOK-EUMSG-01.mgdnok.nokia.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 25 min
X-Total-Time: 36 min
Cc: ipsec@ietf.org
Subject: Re: [IPsec] RFC5555 and Section 2.23.1 (was:  IKEv2bis, comments about sections 1-2)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2010 12:18:26 -0000

Pasi.Eronen@nokia.com writes:
> > ----------------------------------------------------------------------
> > 2.11.  Address and Port Agility
> > 
> >    IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and
> >    AH associations for the same IP addresses it runs over.
> > ----------------------------------------------------------------------
> > 
> > which usually means that for transport mode the addresses you expect
> > to se on ESP packets are same as what they were for the IKE packet
> > too, which is impossible now as the IKEv2 runs over IPv4, but ESP
> > packets run over IPv6.
> 
> Hmm... What exactly that text means is actually a good question.  
> If you have a multi-homed host using SCTP, for example, it would make
> sense to create a transport mode SA whose traffic selectors include
> more than one IP address. If there are no NATs, this would work fine
> (even though only one of the addresses in TS payloads would be equal
> to the address used for sending the IKE packet).
> 
> So I'm not so sure if this text really prohibits the situation where
> transport mode traffic selectors aren't exactly the same as the
> addresses used for sending the IKE packet...

I agree that it does not explictly forbid having multiple addresses in
transport mode SA, but I do not think it is possible.

If we think this setup from the initiator point of view. He is sending
packet from src1 to dst1. The packet will trigger IPsec negotiation
which will then do SPD lookup. If entry is found from there, and this
is transport mode then the SPD does not have local and remote tunnel
addresses, but instead it assumes that src1 and dst1 are the address
used when creating IKE (or selecting IKE).

How do you plan to create such things using RFC4301 architecture?

I do not think SPD have any other places to store that kind of
information than in the local/remote tunnel addresses, and those are
only used in tunnel mode:

                - (if tunnel mode) local tunnel address -- For a
                  non-mobile host, if there is just one interface, this
                  is straightforward; if there are multiple
                  interfaces, this must be statically configured.  For a
                  mobile host, the specification of the local address
                  is handled externally to IPsec.
                - (if tunnel mode) remote tunnel address -- There is no
                  standard way to determine this.  See 4.5.3, "Locating
                  a Security Gateway".


Hmm.. it might be possible that if the PAD entry linked with that
transport mode SPD contains "peer gateway information" field which
indicates the security gateway, but the RFC4301 also says that:

   For example, assume that IKE A receives an outbound packet destined
   for IP address X, a host served by a security gateway.  RFC 2401
   [RFC2401] and this document do not specify how A determines the
   address of the IKE peer serving X.

which would indicate that it might be possible to do this kind of
things with RFC4301 architecture. On the other hand it is talking
about security gateway, which usually indicates tunnel mode, as
security gateway is defined to be:

	 A security gateway is an intermediate system implementing
   IPsec, e.g., a firewall or router that has been IPsec-enabled.

> Well, this is not the only place where RFC5555 may not work with just
> any IPsec implementation, and can require MIP-specific tweaks... 
> (search for "implementation" in Section 5 if you really want to know)

I think knowledge adds pain, so I rather not... every time I try read
those MIP specific tweaks my heads start hurting, and I feel that
those tweaks are not going to work ever with any real IPsec
implementation.

> > As there is no NAT for the IPv6 addresses, then the SPD lookup based
> > on the traffic selectors would be fine, but there is no way to know
> > whether there is NAT between the IPv6 address or not, as we only
> > tested the presense of NAT for IPv4 addresses.
> 
> Yes, that's true. (And even if you know there's NAT, you would not know
> what the mapped addresses are.)

Yes.
-- 
kivinen@iki.fi

From Pasi.Eronen@nokia.com  Thu Jan 28 04:30:14 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 160FD3A67B4 for ; Thu, 28 Jan 2010 04:30:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.247
X-Spam-Level: 
X-Spam-Status: No, score=-6.247 tagged_above=-999 required=5 tests=[AWL=0.352,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mid+USJUvHvG for ; Thu, 28 Jan 2010 04:30:13 -0800 (PST)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id E6F5B3A6782 for ; Thu, 28 Jan 2010 04:30:12 -0800 (PST)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0SCTrVL010789; Thu, 28 Jan 2010 06:30:29 -0600
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 28 Jan 2010 14:30:23 +0200
Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 28 Jan 2010 14:30:13 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 28 Jan 2010 14:30:09 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Thu, 28 Jan 2010 13:30:07 +0100
From: 
To: 
Date: Thu, 28 Jan 2010 13:30:07 +0100
Thread-Topic: [IPsec] RFC5555 and Section 2.23.1 (was:  IKEv2bis, comments about sections 1-2)
Thread-Index: AcqgFB9S+Dq6Bzf0RuaXV2n6k4PETQAABsWQ
Message-ID: <808FD6E27AD4884E94820BC333B2DB77584122704C@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB7758410A954B@NOK-EUMSG-01.mgdnok.nokia.com> <19285.37771.259456.852530@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB775841199BC3@NOK-EUMSG-01.mgdnok.nokia.com> <19294.56491.761386.235273@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7758411DE74C@NOK-EUMSG-01.mgdnok.nokia.com> <19297.32917.576733.476032@fireball.kivinen.iki.fi>
In-Reply-To: <19297.32917.576733.476032@fireball.kivinen.iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 28 Jan 2010 12:30:09.0085 (UTC) FILETIME=[A11696D0:01CAA015]
X-Nokia-AV: Clean
Cc: ipsec@ietf.org
Subject: Re: [IPsec] RFC5555 and Section 2.23.1 (was:  IKEv2bis, comments about sections 1-2)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2010 12:30:14 -0000

Hi Tero,

RFC 4555 Appendix A.2 has more text discussing this topic (when you
need to create a new ESP/AH SA, how do you know where to send the IKE
packets). It basically concluded this is beyond the scope of the spec,
and could be very simple (e.g. just configure a single IP address
somewhere), or quite complex (e.g. multiple gateways to select from).

So I think this is quite possible with RFC 4301 architecture...
(but probably not supported by all implementations)

Best regards,
Pasi

> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
> Of ext Tero Kivinen
> Sent: 28 January, 2010 14:18
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: ipsec@ietf.org
> Subject: Re: [IPsec] RFC5555 and Section 2.23.1 (was: IKEv2bis,
> comments about sections 1-2)
>=20
> Pasi.Eronen@nokia.com writes:
> > > -------------------------------------------------------------------
> ---
> > > 2.11.  Address and Port Agility
> > >
> > >    IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP
> and
> > >    AH associations for the same IP addresses it runs over.
> > > -------------------------------------------------------------------
> ---
> > >
> > > which usually means that for transport mode the addresses you
> expect
> > > to se on ESP packets are same as what they were for the IKE packet
> > > too, which is impossible now as the IKEv2 runs over IPv4, but ESP
> > > packets run over IPv6.
> >
> > Hmm... What exactly that text means is actually a good question.
> > If you have a multi-homed host using SCTP, for example, it would make
> > sense to create a transport mode SA whose traffic selectors include
> > more than one IP address. If there are no NATs, this would work fine
> > (even though only one of the addresses in TS payloads would be equal
> > to the address used for sending the IKE packet).
> >
> > So I'm not so sure if this text really prohibits the situation where
> > transport mode traffic selectors aren't exactly the same as the
> > addresses used for sending the IKE packet...
>=20
> I agree that it does not explictly forbid having multiple addresses in
> transport mode SA, but I do not think it is possible.
>=20
> If we think this setup from the initiator point of view. He is sending
> packet from src1 to dst1. The packet will trigger IPsec negotiation
> which will then do SPD lookup. If entry is found from there, and this
> is transport mode then the SPD does not have local and remote tunnel
> addresses, but instead it assumes that src1 and dst1 are the address
> used when creating IKE (or selecting IKE).
>=20
> How do you plan to create such things using RFC4301 architecture?
>=20
> I do not think SPD have any other places to store that kind of
> information than in the local/remote tunnel addresses, and those are
> only used in tunnel mode:
>=20
>                 - (if tunnel mode) local tunnel address -- For a
>                   non-mobile host, if there is just one interface, this
>                   is straightforward; if there are multiple
>                   interfaces, this must be statically configured.  For
> a
>                   mobile host, the specification of the local address
>                   is handled externally to IPsec.
>                 - (if tunnel mode) remote tunnel address -- There is no
>                   standard way to determine this.  See 4.5.3, "Locating
>                   a Security Gateway".
>=20
>=20
> Hmm.. it might be possible that if the PAD entry linked with that
> transport mode SPD contains "peer gateway information" field which
> indicates the security gateway, but the RFC4301 also says that:
>=20
>    For example, assume that IKE A receives an outbound packet destined
>    for IP address X, a host served by a security gateway.  RFC 2401
>    [RFC2401] and this document do not specify how A determines the
>    address of the IKE peer serving X.
>=20
> which would indicate that it might be possible to do this kind of
> things with RFC4301 architecture. On the other hand it is talking
> about security gateway, which usually indicates tunnel mode, as
> security gateway is defined to be:
>=20
> 	 A security gateway is an intermediate system implementing
>    IPsec, e.g., a firewall or router that has been IPsec-enabled.
>=20
> > Well, this is not the only place where RFC5555 may not work with just
> > any IPsec implementation, and can require MIP-specific tweaks...
> > (search for "implementation" in Section 5 if you really want to know)
>=20
> I think knowledge adds pain, so I rather not... every time I try read
> those MIP specific tweaks my heads start hurting, and I feel that
> those tweaks are not going to work ever with any real IPsec
> implementation.
>=20
> > > As there is no NAT for the IPv6 addresses, then the SPD lookup
> based
> > > on the traffic selectors would be fine, but there is no way to know
> > > whether there is NAT between the IPv6 address or not, as we only
> > > tested the presense of NAT for IPv4 addresses.
> >
> > Yes, that's true. (And even if you know there's NAT, you would not
> know
> > what the mapped addresses are.)
>=20
> Yes.
> --
> kivinen@iki.fi
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec


From kivinen@iki.fi  Thu Jan 28 04:36:59 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFAC13A6A35 for ; Thu, 28 Jan 2010 04:36:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.521
X-Spam-Level: 
X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8uWlD3HwsBF for ; Thu, 28 Jan 2010 04:36:58 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 4A94E3A68C9 for ; Thu, 28 Jan 2010 04:36:58 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0SCbE0N017720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jan 2010 14:37:14 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0SCbE71027776; Thu, 28 Jan 2010 14:37:14 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19297.34042.656951.508655@fireball.kivinen.iki.fi>
Date: Thu, 28 Jan 2010 14:37:14 +0200
From: Tero Kivinen 
To: 
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB775841227024@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB7758411DDBBD@NOK-EUMSG-01.mgdnok.nokia.com> <19296.19901.825611.27758@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB775841227024@NOK-EUMSG-01.mgdnok.nokia.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 8 min
X-Total-Time: 15 min
Cc: ipsec@ietf.org
Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-esp-null-heuristics-03
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2010 12:36:59 -0000

Pasi.Eronen@nokia.com writes:
> Tero Kivinen wrote:
> 
> > > - Section 8.1: AUTH_HMAC_MD5_128 and AUTH_HMAC_SHA1_160 are not
> > > defined for IPsec ESP; these algorithms apply only to the
> > > FiberChannel security protocols. So they should be removed from
> > > this list (and since this was the only algorithm with 160-bit ICV,
> > > handling that case can be removed).
> > 
> > Removed.
> 
> Section 8.2 still has some old text that assumes five (instead of
> four) different ICV lengths.

Ups. And it seems to affect the calculations, so need to recalculate
them too... 

> > > - Appendix A.2, "Verify TCP": the bits that are currently reserved
> > > might get allocated in the future (and half of the bits that were
> > > reserved in RFC 793 have been since allocated -- so it's not very
> > > clear exactly what "TCP.reserved_bits" means).
> > 
> > All of those tests are something that depends on other standards, i.e.
> > TCP. Normally deep inspection engines etc will check all kind of TCP
> > fields, and depending on the them does something (drop, pass, clear,
> > set, modify etc), and usually those people writing the deep inspection
> > engines etc have quite good idea which bits they can check and which
> > not.
> > 
> > The reason we do not explictly mention what reserved_bits is just
> > because it can change in future.
> 
> The reserved bits MUST be ignored if you don't understand them,
> so testing whether they're zero (and returning failure if they're not)
> is not correct behavior here (and would unnecessarily complicate deployment
> of new TCP features in the future).

Ok, I removed that part of pseudocode.

> 
> 
> > > - Section 2.1, suggesting that AH might have more bugs doesn't sound
> > > like an argument that belongs in this document.
> > 
> > It was one of the arguments which was given when people said why they
> > do not want to use AH.
> 
> Nevertheless, as it's currently written, it sounds more like FUD 
> than a reasonable argument. Let's just delete it.

Ok, removed the ", meaning it might have more bugs than ESP
implementations" part. Would this text be ok:

    AH has also quite complex processing rules compared to ESP when
    calculating the ICV, including things like zeroing out mutable
    fields, also as AH is not as widely used than ESP, the AH support
    is not as well tested in the interoperability events.

or do you think we should leave only the complexcity issue:

    AH has also quite complex processing rules compared to ESP when
    calculating the ICV, including things like zeroing out mutable
    fields.

> But the comparison to IPv6 is very misleading here -- I think many
> folks would argue that for IPv6 it's been easier to update the end
> nodes (many of which do support IPv6 today) than the intermediate
> nodes (when e.g. travelling, how often do you find that the
> routers/whatever in the access network actually provide v6?). And
> probably some folks would say this argument is too simplistic and
> wrong, too -- either way, it's not a discussion for this document.

Hmm... true... Ok. I removed the IPv6 vs NAT text so the pragraph
looks like this:

    All of the aforementioned drafts require modification to ESP,
    which requires that all end nodes need to be modified before
    intermediate devices can assume that this new ESP format is in
    use. Updating end nodes will require lots of time. An example of
    slow end-node deployment is IKEv2. Considering an implementation
    that requires both IKEv2 and a new ESP format, it would take
    several years, possibly as long as a decade, before widespread
    deployment.

I will submit new draft tomorrow (before I leave for one week long
vacation). 
-- 
kivinen@iki.fi

From ynir@checkpoint.com  Thu Jan 28 04:39:35 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC0033A6891 for ; Thu, 28 Jan 2010 04:39:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.936
X-Spam-Level: 
X-Spam-Status: No, score=-2.936 tagged_above=-999 required=5 tests=[AWL=0.662,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsRArHUEFxlo for ; Thu, 28 Jan 2010 04:39:27 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 29A9A3A672E for ; Thu, 28 Jan 2010 04:39:26 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0SCdhT7001544 for ; Thu, 28 Jan 2010 14:39:43 +0200 (IST)
X-CheckPoint: {4B6185A5-0-1B201DC2-5FFFF}
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 28 Jan 2010 14:40:04 +0200
From: Yoav Nir 
To: "ipsec@ietf.org" 
Date: Thu, 28 Jan 2010 14:40:02 +0200
Thread-Topic: Closing issue #143 (rewrite of section 1.5)
Thread-Index: AcqgFvpWz1P8j44URy6gByBhuLb7xg==
Message-ID: <006FEB08D9C6444AB014105C9AEB133FB36A511145@il-ex01.ad.checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_006FEB08D9C6444AB014105C9AEB133FB36A511145ilex01adcheck_"
MIME-Version: 1.0
Subject: [IPsec] Closing issue #143 (rewrite of section 1.5)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2010 12:39:36 -0000

--_000_006FEB08D9C6444AB014105C9AEB133FB36A511145ilex01adcheck_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all.

Combining Pasi's proposed text with Tero's comments I came up with this ver=
sion.

Is this acceptable to everyone?

Yoav

   There are couple of cases when a node receives a packet it cannot
   process, but may want to notify the sender about this situation:

   o  If an ESP or AH packet arrives with an unrecognized SPI, it
      could be because the receiving node has recently crashed and
      lost state or because of some other system malfunction or
      attack.

   o  If an encrypted IKE request packet arrives on port 500 or 4500
      with an unrecognized IKE SPI, it could be because the receiving node
      has recently crashed and lost state, or because of some other
      system malfunction or attack.

   o If an IKE request packet arrives with a higher major version
     number than the implementation supports.

   (Note that the second and third cases apply only to IKE request
   packets, not response packets.)

   In the first case, if the receiving node has an active IKE SA to
   the IP address from whence the packet came, it MAY send an
   INVALID_SPI notification of the wayward packet over that IKE SA in
   an INFORMATIONAL exchange. The Notification Data contains the SPI
   of the invalid packet. The recipient of this notification cannot
   tell whether the SPI is for AH or ESP, but this is not important
   because the SPIs are supposed to be different for the two.

   If no suitable IKE SA exists, the node MAY send an INFORMATIONAL
   message without cryptographic protection to the source IP address.
   In this case, it should only be used by the recipient as a "hint"
   that something might be wrong (because it could easily be forged).
   This message is not part of an INFORMATIONAL exchange, and the
   receiving node MUST NOT respond to it (doing so could cause a
   message loop). The message is constructed as follows: There are no
   IKE SPI values that would be meaningful to the recipient of such a
   notification; using zero values or random values are both
   acceptable, this being the exception to the rule in [section 3.1]
   that prohibits zero IKE SPIs.  The Initiator flag is set, the
   Response bit is set to 0, and the version flags are set in the normal
   fashion.

   In the second and third cases, the message is always sent without
   cryptographic protection (outside of an IKE SA), and includes
   either INVALID_IKE_SPI or INVALID_MAJOR_VERSION notification (with
   no notification data).  The message is a response message, and thus
   it is sent to the IP address and port from whence it came with the
   same IKE SPIs and the Message ID is copied.  The Response bit is
   set to 1, and the version flags are set in the normal fashion. The
   responder SHOULD copy the Exchange Type from the request.



--_000_006FEB08D9C6444AB014105C9AEB133FB36A511145ilex01adcheck_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















Hi all.



 



Combining Pasi’s proposed text with Tero’s c=
omments I came
up with this version.



 



Is this acceptable to everyone?=




 



Yoav



 



   There are couple of cases when a node recei=
ves a packet
it cannot



   process, but may want to notify the sender =
about this
situation:



 



   o  If an ESP or AH packet arrives with=
 an unrecognized
SPI, it



      could be because the rece=
iving node has recently
crashed and



      lost state or because of =
some other system malfunction
or



      attack.=




 



   o  If an encrypted IKE request packet =
arrives on port 500
or 4500



      with an unrecognized IKE =
SPI, it could be because the
receiving node



      has recently crashed and =
lost state, or because of
some other



      system malfunction or att=
ack.



 



   o If an IKE request packet arrives with a h=
igher major
version



     number than the implementation =
supports.



 



   (Note that the second and third cases apply=
 only to IKE
request



   packets, not response packets.)<=
/span>



 



   In the first case, if the receiving node ha=
s an active
IKE SA to



   the IP address from whence the packet came,=
 it MAY send
an



   INVALID_SPI notification of the wayward pac=
ket over that
IKE SA in



   an INFORMATIONAL exchange. The Notification=
 Data contains
the SPI



   of the invalid packet. The recipient of thi=
s notification
cannot



   tell whether the SPI is for AH or ESP, but =
this is not
important



   because the SPIs are supposed to be differe=
nt for the two.



 



   If no suitable IKE SA exists, the node MAY =
send an
INFORMATIONAL



   message without cryptographic protection to=
 the source IP
address.



   In this case, it should only be used by the=
 recipient as
a "hint"



   that something might be wrong (because it c=
ould easily be
forged).



   This message is not part of an INFORMATIONA=
L exchange, and
the



   receiving node MUST NOT respond to it (doin=
g so could
cause a



   message loop). The message is constructed a=
s follows: There
are no



   IKE SPI values that would be meaningful to =
the recipient
of such a



   notification; using zero values or random v=
alues are both



   acceptable, this being the exception to the=
 rule in [section
3.1]



   that prohibits zero IKE SPIs.  The Ini=
tiator flag is set,
the 



   Response bit is set to 0, and the version f=
lags are set
in the normal 



   fashion.



 



   In the second and third cases, the message =
is always sent
without



   cryptographic protection (outside of an IKE=
 SA), and
includes



   either INVALID_IKE_SPI or INVALID_MAJOR_VER=
SION
notification (with



   no notification data).  The message is=
 a response message,
and thus



   it is sent to the IP address and port from =
whence it came
with the



   same IKE SPIs and the Message ID is copied.=
  The Response
bit is



   set to 1, and the version flags are set in =
the normal
fashion. The



   responder SHOULD copy the Exchange Type fro=
m the request.



 



 









--_000_006FEB08D9C6444AB014105C9AEB133FB36A511145ilex01adcheck_--

From ynir@checkpoint.com  Thu Jan 28 04:50:31 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD53D3A6855 for ; Thu, 28 Jan 2010 04:50:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.01
X-Spam-Level: 
X-Spam-Status: No, score=-3.01 tagged_above=-999 required=5 tests=[AWL=0.588,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWTZ0SHAsN8I for ; Thu, 28 Jan 2010 04:50:27 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 6426E3A6405 for ; Thu, 28 Jan 2010 04:50:27 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0SCoiT7003140 for ; Thu, 28 Jan 2010 14:50:44 +0200 (IST)
X-CheckPoint: {4B61883A-0-1B201DC2-5FFFF}
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 28 Jan 2010 14:51:05 +0200
From: Yoav Nir 
To: "ipsec@ietf.org" 
Date: Thu, 28 Jan 2010 14:51:03 +0200
Thread-Topic: Closing Issue #146 - Encapsulation wording
Thread-Index: AcqgGISEYG40FK8ZQnerZsmu+hQMmg==
Message-ID: <006FEB08D9C6444AB014105C9AEB133FB36A511146@il-ex01.ad.checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_006FEB08D9C6444AB014105C9AEB133FB36A511146ilex01adcheck_"
MIME-Version: 1.0
Subject: [IPsec] Closing Issue #146 - Encapsulation wording
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2010 12:50:31 -0000

--_000_006FEB08D9C6444AB014105C9AEB133FB36A511146ilex01adcheck_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all

The "offending" paragraph is the following;

   An initiator can use port 4500, regardless whether or not there is
   NAT, even at the beginning of IKE.  When either side is using port
   4500, sending with UDP encapsulation is not required, but
   understanding received packets with UDP encapsulation is required.
   UDP encapsulation MUST NOT be done on port 500.  If NAT-T is
   supported (that is, if NAT_DETECTION_*_IP payloads were exchanged
   during IKE_SA_INIT), all devices MUST be able to receive and process
   both UDP encapsulated and non-UDP encapsulated packets at any time.
   Either side can decide whether or not to use UDP encapsulation
   irrespective of the choice made by the other side.  However, if a NAT
   is detected, both devices MUST send UDP encapsulated packets.

If we change it as follows, would that be OK?

   An initiator can use port 4500 for both IKE and ESP, regardless of
   whether or not there is NAT, even at the beginning of IKE.  When
   either side is using port 4500, sending with UDP encapsulation is
   not required, but understanding received IKE and ESP packets with
   UDP encapsulation is required. UDP encapsulation MUST NOT be done
   on port 500.  If NAT-T is supported (that is, if NAT_DETECTION_*_IP
   payloads were exchanged during IKE_SA_INIT), all devices MUST be able
   to receive and process both UDP encapsulated and non-UDP encapsulated
   packets at any time. Either side can decide whether or not to use UDP
   encapsulation irrespective of the choice made by the other side.
   However, if a NAT is detected, both devices MUST send UDP encapsulated
   packets.


I think this clarifies that we're talking about both IKE and IPsec.

Yoav


--_000_006FEB08D9C6444AB014105C9AEB133FB36A511146ilex01adcheck_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















Hi all



 



The “offending” paragraph is the following;<=
o:p>



 



   An initiator can use port 4500, regardless =
whether or not
there is



   NAT, even at the beginning of IKE.  Wh=
en either side is
using port



   4500, sending with UDP encapsulation is not=
 required, but



   understanding received packets with UDP enc=
apsulation is
required.



   UDP encapsulation MUST NOT be done on port =
500.  If NAT-T
is



   supported (that is, if NAT_DETECTION_*_IP p=
ayloads were
exchanged



   during IKE_SA_INIT), all devices MUST be ab=
le to receive
and process



   both UDP encapsulated and non-UDP encapsula=
ted packets at
any time.



   Either side can decide whether or not to us=
e UDP
encapsulation



   irrespective of the choice made by the othe=
r side.  However,
if a NAT



   is detected, both devices MUST send UDP enc=
apsulated
packets.



 



If we change it as follows, would that be OK?=




 



   An initiator can use port 4500 for both IKE=
 and ESP, regardless
of



   whether or not there is NAT, even at the be=
ginning of IKE. 
When 



   either side is using port 4500, sending wit=
h UDP
encapsulation is 



   not required, but understanding received IK=
E and ESP
packets with 



   UDP encapsulation is required. UDP encapsul=
ation MUST NOT
be done 



   on port 500.  If NAT-T is supported (t=
hat is, if NAT_DETECTION_*_IP




   payloads were exchanged during IKE_SA_INIT)=
, all devices
MUST be able 



   to receive and process both UDP encapsulate=
d and non-UDP
encapsulated 



   packets at any time. Either side can decide=
 whether or
not to use UDP 



   encapsulation irrespective of the choice ma=
de by the
other side.  



   However, if a NAT is detected, both devices=
 MUST send UDP
encapsulated 



   packets.



 



 



I think this clarifies that we’re talking about bo=
th IKE and
IPsec.



 



Yoav



 









--_000_006FEB08D9C6444AB014105C9AEB133FB36A511146ilex01adcheck_--

From Pasi.Eronen@nokia.com  Thu Jan 28 04:55:00 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DC073A6405 for ; Thu, 28 Jan 2010 04:55:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.266
X-Spam-Level: 
X-Spam-Status: No, score=-6.266 tagged_above=-999 required=5 tests=[AWL=0.333,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BV-h29EsL0P for ; Thu, 28 Jan 2010 04:54:59 -0800 (PST)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 3F9A43A6811 for ; Thu, 28 Jan 2010 04:54:59 -0800 (PST)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0SCsobH028940; Thu, 28 Jan 2010 14:55:14 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 28 Jan 2010 14:54:54 +0200
Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 28 Jan 2010 14:54:54 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 28 Jan 2010 14:54:49 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Thu, 28 Jan 2010 13:54:48 +0100
From: 
To: 
Date: Thu, 28 Jan 2010 13:54:46 +0100
Thread-Topic: [IPsec] AD review of draft-ietf-ipsecme-esp-null-heuristics-03
Thread-Index: AcqgFqUlBK6WNOQVQl+CLaVaMb8hNgAAWUtg
Message-ID: <808FD6E27AD4884E94820BC333B2DB775841227086@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB7758411DDBBD@NOK-EUMSG-01.mgdnok.nokia.com> <19296.19901.825611.27758@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB775841227024@NOK-EUMSG-01.mgdnok.nokia.com> <19297.34042.656951.508655@fireball.kivinen.iki.fi>
In-Reply-To: <19297.34042.656951.508655@fireball.kivinen.iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 28 Jan 2010 12:54:49.0516 (UTC) FILETIME=[137E6EC0:01CAA019]
X-Nokia-AV: Clean
Cc: ipsec@ietf.org
Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-esp-null-heuristics-03
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2010 12:55:00 -0000

Tero Kivinen wrote:

> > > > - Section 2.1, suggesting that AH might have more bugs doesn't
> > > > sound
> > > > like an argument that belongs in this document.
> > >
> > > It was one of the arguments which was given when people said why
> > > they do not want to use AH.
> >
> > Nevertheless, as it's currently written, it sounds more like FUD
> > than a reasonable argument. Let's just delete it.
>=20
> Ok, removed the ", meaning it might have more bugs than ESP
> implementations" part. Would this text be ok:
>=20
>     AH has also quite complex processing rules compared to ESP when
>     calculating the ICV, including things like zeroing out mutable
>     fields, also as AH is not as widely used than ESP, the AH support
>     is not as well tested in the interoperability events.
>=20
> or do you think we should leave only the complexcity issue:
>=20
>     AH has also quite complex processing rules compared to ESP when
>     calculating the ICV, including things like zeroing out mutable
>     fields.

I'm OK with either one (but AH is a very stable and mature protocol,
so while it's not as widely used, I would expect the level of testing
has been quite substantial...).

> > But the comparison to IPv6 is very misleading here -- I think many
> > folks would argue that for IPv6 it's been easier to update the end
> > nodes (many of which do support IPv6 today) than the intermediate
> > nodes (when e.g. travelling, how often do you find that the
> > routers/whatever in the access network actually provide v6?). And
> > probably some folks would say this argument is too simplistic and
> > wrong, too -- either way, it's not a discussion for this document.
>=20
> Hmm... true... Ok. I removed the IPv6 vs NAT text so the pragraph
> looks like this:
>=20
>     All of the aforementioned drafts require modification to ESP,
>     which requires that all end nodes need to be modified before
>     intermediate devices can assume that this new ESP format is in
>     use. Updating end nodes will require lots of time. An example of
>     slow end-node deployment is IKEv2. Considering an implementation
>     that requires both IKEv2 and a new ESP format, it would take
>     several years, possibly as long as a decade, before widespread
>     deployment.

OK.

> I will submit new draft tomorrow (before I leave for one week long
> vacation).

I'm leaving for one-week-long trip tomorrow (Friday), so if there's
any chance you could get an update in today, I could ask the
secretariat to start IETF last call :-)

Best regards,
Pasi

From kivinen@iki.fi  Thu Jan 28 04:55:39 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2065F3A6782 for ; Thu, 28 Jan 2010 04:55:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.375
X-Spam-Level: 
X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkXF7kZvLDu6 for ; Thu, 28 Jan 2010 04:55:38 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 1A41E3A672E for ; Thu, 28 Jan 2010 04:55:37 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0SCtp79015282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jan 2010 14:55:51 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0SCtpAm029793; Thu, 28 Jan 2010 14:55:51 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19297.35159.27046.795144@fireball.kivinen.iki.fi>
Date: Thu, 28 Jan 2010 14:55:51 +0200
From: Tero Kivinen 
To: Alfred =?hp-roman8?B?SM5uZXM=?= 
In-Reply-To: <201001271638.RAA08437@TR-Sys.de>
References: <201001271638.RAA08437@TR-Sys.de>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 2 min
X-Total-Time: 3 min
Cc: ipsec@ietf.org
Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-esp-null-heuristics-03	-- TCP flags
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2010 12:55:39 -0000

Alfred =?hp-roman8?B?SM5uZXM=?= writes:
> and later:
> 
>                                        [...]   Routers MUST NOT drop
>      packets merely because one or more of these reserved bits has a
>      non-zero value.

This and Pasi's comments were strong enough, so I removed offending
check of reserved bits in the pseudocode (and updated also section
8.3.1).
-- 
kivinen@iki.fi

From kivinen@iki.fi  Thu Jan 28 05:21:02 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1BB93A6405 for ; Thu, 28 Jan 2010 05:21:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.221
X-Spam-Level: 
X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkWmcjKbKVrt for ; Thu, 28 Jan 2010 05:21:02 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 562753A63D3 for ; Thu, 28 Jan 2010 05:21:00 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0SDLG6f017904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jan 2010 15:21:16 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0SDLGHf027367; Thu, 28 Jan 2010 15:21:16 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19297.36684.441872.922413@fireball.kivinen.iki.fi>
Date: Thu, 28 Jan 2010 15:21:16 +0200
From: Tero Kivinen 
To: 
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB775841227086@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB7758411DDBBD@NOK-EUMSG-01.mgdnok.nokia.com> <19296.19901.825611.27758@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB775841227024@NOK-EUMSG-01.mgdnok.nokia.com> <19297.34042.656951.508655@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB775841227086@NOK-EUMSG-01.mgdnok.nokia.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 5 min
X-Total-Time: 7 min
Cc: ipsec@ietf.org
Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-esp-null-heuristics-03
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2010 13:21:02 -0000

Pasi.Eronen@nokia.com writes:
> I'm OK with either one (but AH is a very stable and mature protocol,
> so while it's not as widely used, I would expect the level of testing
> has been quite substantial...).

I think I last tested AH in interop events in San-Diego interop 2000
or so. We might have done some testing also in 2001 Espoo interop. And
some of that testing was for IPv6 conformance testing, and others were
those implementations which didn't support authentication in ESP, so
AH+ESP was only way to get authentication for ESP with them.

I do not think any of the IKEv2 interops tested anything with AH.

So stable and mature yes, not so sure about level of testing, as even
those ikev1 ah-tests was just basic ping tests, without any IP-options
or similar. 

> > I will submit new draft tomorrow (before I leave for one week long
> > vacation).
> 
> I'm leaving for one-week-long trip tomorrow (Friday), so if there's
> any chance you could get an update in today, I could ask the
> secretariat to start IETF last call :-)

Ok, I will send new one now (hopefully I do not need to update xml2rfc
again this time, I did it already yesterday :-)
-- 
kivinen@iki.fi

From root@core3.amsl.com  Thu Jan 28 05:30:01 2010
Return-Path: 
X-Original-To: ipsec@ietf.org
Delivered-To: ipsec@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 5A33F3A6849; Thu, 28 Jan 2010 05:30:00 -0800 (PST)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20100128133001.5A33F3A6849@core3.amsl.com>
Date: Thu, 28 Jan 2010 05:30:01 -0800 (PST)
Cc: ipsec@ietf.org
Subject: [IPsec] I-D Action:draft-ietf-ipsecme-esp-null-heuristics-05.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2010 13:30:01 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF.


	Title           : Heuristics for Detecting ESP-NULL packets
	Author(s)       : T. Kivinen, D. McDonald
	Filename        : draft-ietf-ipsecme-esp-null-heuristics-05.txt
	Pages           : 37
	Date            : 2010-01-28

This document describes a set of heuristics for distinguishing IPsec
ESP-NULL (Encapsulating Security Payload without encryption) packets
from encrypted ESP packets.  These heuristics can be used on
intermediate devices, like traffic analyzers, and deep inspection
engines, to quickly decide whether given packet flow is interesting
or not.  Use of these heuristics does not require any changes made on
existing RFC4303 compliant IPsec hosts.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-esp-null-heuristics-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ipsecme-esp-null-heuristics-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-01-28052538.I-D@ietf.org>


--NextPart--

From Pasi.Eronen@nokia.com  Thu Jan 28 05:33:59 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4458F3A68E4 for ; Thu, 28 Jan 2010 05:33:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.284
X-Spam-Level: 
X-Spam-Status: No, score=-6.284 tagged_above=-999 required=5 tests=[AWL=0.315,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QXDdyEMF41q for ; Thu, 28 Jan 2010 05:33:58 -0800 (PST)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 3AF8E3A67CF for ; Thu, 28 Jan 2010 05:33:58 -0800 (PST)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0SDXwQZ017521; Thu, 28 Jan 2010 15:34:13 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 28 Jan 2010 15:33:20 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.5]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 28 Jan 2010 15:33:19 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Thu, 28 Jan 2010 14:33:19 +0100
From: 
To: 
Date: Thu, 28 Jan 2010 14:33:18 +0100
Thread-Topic: [IPsec] AD review of draft-ietf-ipsecme-esp-null-heuristics-03
Thread-Index: AcqgHM+2KF0a4jFyQ/Whd/PIi5TeyAAAYXhQ
Message-ID: <808FD6E27AD4884E94820BC333B2DB7758412270E6@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB7758411DDBBD@NOK-EUMSG-01.mgdnok.nokia.com> <19296.19901.825611.27758@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB775841227024@NOK-EUMSG-01.mgdnok.nokia.com> <19297.34042.656951.508655@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB775841227086@NOK-EUMSG-01.mgdnok.nokia.com> <19297.36684.441872.922413@fireball.kivinen.iki.fi>
In-Reply-To: <19297.36684.441872.922413@fireball.kivinen.iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 28 Jan 2010 13:33:19.0919 (UTC) FILETIME=[7499F3F0:01CAA01E]
X-Nokia-AV: Clean
Cc: ipsec@ietf.org
Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-esp-null-heuristics-03
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2010 13:33:59 -0000

> Ok, I will send new one now (hopefully I do not need to update xml2rfc
> again this time, I did it already yesterday :-)

Thanks -- I've now asked the secretariat to start the IETF Last Call.

Best regards,
Pasi

From kivinen@iki.fi  Thu Jan 28 06:39:24 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83F1E3A67D1 for ; Thu, 28 Jan 2010 06:39:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.511
X-Spam-Level: 
X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bT1k4lgpbBRp for ; Thu, 28 Jan 2010 06:39:23 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 123D53A67AC for ; Thu, 28 Jan 2010 06:39:22 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o0SEdXMY023212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jan 2010 16:39:33 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o0SEdW8j018280; Thu, 28 Jan 2010 16:39:32 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19297.41380.590263.645880@fireball.kivinen.iki.fi>
Date: Thu, 28 Jan 2010 16:39:32 +0200
From: Tero Kivinen 
To: Yoav Nir 
In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB36A511145@il-ex01.ad.checkpoint.com>
References: <006FEB08D9C6444AB014105C9AEB133FB36A511145@il-ex01.ad.checkpoint.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 11 min
X-Total-Time: 11 min
Cc: "ipsec@ietf.org" 
Subject: [IPsec]  Closing issue #143 (rewrite of section 1.5)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2010 14:39:24 -0000

Yoav Nir writes:
> Is this acceptable to everyone?

Couple of comments. 

>    There are couple of cases when a node receives a packet it cannot
>    process, but may want to notify the sender about this situation:
> 
>    o  If an ESP or AH packet arrives with an unrecognized SPI, it
>       could be because the receiving node has recently crashed and
>       lost state or because of some other system malfunction or
>       attack.
> 
>    o  If an encrypted IKE request packet arrives on port 500 or 4500
>       with an unrecognized IKE SPI, it could be because the receiving node
>       has recently crashed and lost state, or because of some other
>       system malfunction or attack.
> 
>    o If an IKE request packet arrives with a higher major version
>      number than the implementation supports.
> 
>    (Note that the second and third cases apply only to IKE request
>    packets, not response packets.)
> 
>    In the first case, if the receiving node has an active IKE SA to
>    the IP address from whence the packet came, it MAY send an
>    INVALID_SPI notification of the wayward packet over that IKE SA in
>    an INFORMATIONAL exchange. The Notification Data contains the SPI
>    of the invalid packet. The recipient of this notification cannot
>    tell whether the SPI is for AH or ESP, but this is not important
>    because the SPIs are supposed to be different for the two.
> 
>    If no suitable IKE SA exists, the node MAY send an INFORMATIONAL
>    message without cryptographic protection to the source IP address.

We should also note that it should use the same port number that was
used for sending this unknown ESP packet was UDP encapsulated when it
came in.

I.e. if it receives raw ESP or AH, it knows there cannot be NAT, thus
port 500 is ok.

If it receives UDP encapsulateed ESP packet with unknow SPI then it
knows there most likely is a NAT (or firewall) which requires UDP
encapsulation, thus the informational message should also be sent
using UDP encapsulation format (i.e. use the IP addresses and ports in
the incoming UDP encapsulated packet and just swap source and
destination, and the IKE packet also needs to have four octets of zero
prepended to it).

>    In this case, it should only be used by the recipient as a "hint"
>    that something might be wrong (because it could easily be forged).
>    This message is not part of an INFORMATIONAL exchange, and the
>    receiving node MUST NOT respond to it (doing so could cause a
>    message loop). The message is constructed as follows: There are no
>    IKE SPI values that would be meaningful to the recipient of such a
>    notification; using zero values or random values are both
>    acceptable, this being the exception to the rule in [section 3.1]
>    that prohibits zero IKE SPIs.  The Initiator flag is set, the

s/prohibits zero IKE SPIs/prohibits zero IKE Initiator's SPI./

>    Response bit is set to 0, and the version flags are set in the normal
>    fashion.
> 
>    In the second and third cases, the message is always sent without
>    cryptographic protection (outside of an IKE SA), and includes
>    either INVALID_IKE_SPI or INVALID_MAJOR_VERSION notification (with
>    no notification data).  The message is a response message, and thus
>    it is sent to the IP address and port from whence it came with the
>    same IKE SPIs and the Message ID is copied.  The Response bit is
>    set to 1, and the version flags are set in the normal fashion. The
>    responder SHOULD copy the Exchange Type from the request.

I would move the exchange type to the same list with IKE SPIs and
Message ID, ie.. change the text to be:

			The message is a response message, and thus
     it is sent to the IP address and port from whence it came with the
     same IKE SPIs and the Message ID and Exchange Type are copied
     from the request. The Response bit is set to 1, and the version
     flags are set in the normal fashion.  
-- 
kivinen@iki.fi

From wwwrun@core3.amsl.com  Thu Jan 28 07:22:29 2010
Return-Path: 
X-Original-To: ipsec@ietf.org
Delivered-To: ipsec@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id 539903A6A16; Thu, 28 Jan 2010 07:22:29 -0800 (PST)
X-idtracker: yes
To: IETF-Announce  
From: The IESG 
Message-Id: <20100128152229.539903A6A16@core3.amsl.com>
Date: Thu, 28 Jan 2010 07:22:29 -0800 (PST)
Cc: ipsec@ietf.org
Subject: [IPsec] Last Call: draft-ietf-ipsecme-esp-null-heuristics (Heuristics for Detecting ESP-NULL packets) to Informational RFC
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: ietf@ietf.org
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2010 15:22:29 -0000

The IESG has received a request from the IP Security Maintenance and 
Extensions WG (ipsecme) to consider the following document:

- 'Heuristics for Detecting ESP-NULL packets '
    as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@ietf.org mailing lists by 2010-02-11. Exceptionally, 
comments may be sent to iesg@ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-esp-null-heuristics-05.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18498&rfc_flag=0


From suneelnalluri@gmail.com  Thu Jan 28 20:40:36 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BB3B3A6821 for ; Thu, 28 Jan 2010 20:40:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level: 
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, J_CHICKENPOX_53=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LB2Ve-FOT4ft for ; Thu, 28 Jan 2010 20:40:35 -0800 (PST)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 475B33A67AA for ; Thu, 28 Jan 2010 20:40:35 -0800 (PST)
Received: by vws1 with SMTP id 1so414688vws.31 for ; Thu, 28 Jan 2010 20:40:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=KURv8P2KPHVH0eLgItHFF7yK/lID4kvqqMLPh7y6IVY=; b=uIA5H79JVSQYXnWHU4KmzqnnlwPt0Ag5S8RI7mg7SIaF0PMkkTdwT9Xd95ITwDbA1S xAvBxEl9erKL97GmmAkN1HSBf6xY7tZpzIMu+uVQgVbr4XtUOz0XKvLZOQRu4CzdZdos 6uuLiXjRE5Gg6Ksb0i5BPs+8reY749aj7yS/c=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=NCl+GLIVPI1kJxDefomsQP33Yb5hwd/xUXOGNvyyNFjqJbL/KVbb3/3GFbQViMQwjw MRyl8oYSu5ks+SVLmqHlbQlXyqLC5e+Zkkwbn+9b98j4LF+qzyfu8pT+cpIqf5MGenBW KjKeZeuDNl25rSeaFgy7wbXJweSS1LCusMLEY=
MIME-Version: 1.0
Received: by 10.220.125.103 with SMTP id x39mr222248vcr.70.1264740053015; Thu,  28 Jan 2010 20:40:53 -0800 (PST)
Date: Fri, 29 Jan 2010 10:10:52 +0530
Message-ID: <3b231eca1001282040t5f5a73f7q429a85108b7bb0c@mail.gmail.com>
From: suni kumar 
To: ipsec@ietf.org
Content-Type: multipart/alternative; boundary=001636d34b6797dbe7047e463d77
Subject: [IPsec] DHCP over IPSEC
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jan 2010 04:42:48 -0000

--001636d34b6797dbe7047e463d77
Content-Type: text/plain; charset=ISO-8859-1

hello
       My name is suneel kumar,i want some information regarding dhcp over
ipsec,and functionality dhcp relay in a gateway

--001636d34b6797dbe7047e463d77
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

hello
=A0=A0=A0=A0=A0=A0 My name is suneel kumar,i want some information=
 regarding dhcp over ipsec,and functionality dhcp relay in a gateway


--001636d34b6797dbe7047e463d77--

From suneelnalluri@gmail.com  Thu Jan 28 20:44:32 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 216DA3A67EA for ; Thu, 28 Jan 2010 20:44:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Level: 
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZS7KgInSz095 for ; Thu, 28 Jan 2010 20:44:31 -0800 (PST)
Received: from mail-vw0-f53.google.com (mail-vw0-f53.google.com [209.85.212.53]) by core3.amsl.com (Postfix) with ESMTP id 40C0E3A67AA for ; Thu, 28 Jan 2010 20:44:31 -0800 (PST)
Received: by vws6 with SMTP id 6so349371vws.40 for ; Thu, 28 Jan 2010 20:44:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=BWr8Z8ZktrNhR6CIMrarqCMvUv/7Gh/t9+R0jI7ecCs=; b=wCkKzaVnlKjo/1wDFCyLzvh4irTQtgsZXc4CWzxAMBxgDY16SAEZDhTrpDtVy5h3RV 4hWMwZ55rj92DpSwqMd/AuPkbgLv1B6ojLtXqsgP3owumguMUv9G1zi4Tue5Qo9XMsCo z89DOqGd7h0CpXDC5Tym+8pYDLhmd6VJtnC/Q=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=mHANgg1lUIYCkDeDW3C74B6NrQueMhoAbcPWboXmU5aC/7zt5+GUfxPSXTz7etKudp rbUvTJRznjZ1h76DxgmGn4zswWUdRdjmkL7S8Ye5KcX/SwW9mc98OEjnlKcTy/3r3XrP RqnG+I9u5jw5SHti95RomtDlMwZIctVbcAKXA=
MIME-Version: 1.0
Received: by 10.220.124.170 with SMTP id u42mr190116vcr.110.1264740291738;  Thu, 28 Jan 2010 20:44:51 -0800 (PST)
Date: Fri, 29 Jan 2010 10:14:51 +0530
Message-ID: <3b231eca1001282044y4fdbf83ei96728171c092ddd0@mail.gmail.com>
From: suni kumar 
To: ipsec@core3.amsl.com
Content-Type: multipart/alternative; boundary=005045016bedd280d5047e464b18
Subject: [IPsec] DHCP over IPSEC
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jan 2010 04:44:32 -0000

--005045016bedd280d5047e464b18
Content-Type: text/plain; charset=ISO-8859-1

As the sender address isn't subscribed to the list, and has not been
confirmed earlier, we have to request a confirmation of the address.
To confirm the address, send a message to ipsec@core3.amsl.com,
with the same subject line as this message.

--005045016bedd280d5047e464b18
Content-Type: text/html; charset=ISO-8859-1

As the sender address isn't subscribed to the list, and has not been

confirmed earlier, we have to request a confirmation of the address.

To confirm the address, send a message to ipsec@core3.amsl.com,

with the same subject line as this message.

--005045016bedd280d5047e464b18--

From ynir@checkpoint.com  Sun Jan 31 00:29:06 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DA7828C0ED for ; Sun, 31 Jan 2010 00:29:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.069
X-Spam-Level: 
X-Spam-Status: No, score=-3.069 tagged_above=-999 required=5 tests=[AWL=0.530,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeYhmVLKujlE for ; Sun, 31 Jan 2010 00:29:05 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id CE68428C0EA for ; Sun, 31 Jan 2010 00:29:04 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0V8TWT7025473; Sun, 31 Jan 2010 10:29:32 +0200 (IST)
X-CheckPoint: {4B653F5D-0-1B201DC2-5FFFF}
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 31 Jan 2010 10:29:52 +0200
From: Yoav Nir 
To: "'Tero Kivinen'" 
Date: Sun, 31 Jan 2010 10:29:51 +0200
Thread-Topic: [IPsec] Closing issue #143 (rewrite of section 1.5)
Thread-Index: AcqgJ8TOQ+TVetpLScWlfE2JRC/iAwCJ69Gw
Message-ID: <006FEB08D9C6444AB014105C9AEB133FB36A511148@il-ex01.ad.checkpoint.com>
References: <006FEB08D9C6444AB014105C9AEB133FB36A511145@il-ex01.ad.checkpoint.com> <19297.41380.590263.645880@fireball.kivinen.iki.fi>
In-Reply-To: <19297.41380.590263.645880@fireball.kivinen.iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ipsec@ietf.org" 
Subject: Re: [IPsec] Closing issue #143 (rewrite of section 1.5)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 Jan 2010 08:29:06 -0000

Fixed.  Is this OK?

   There are couple of cases when a node receives a packet it cannot
   process, but may want to notify the sender about this situation:
=20
   o  If an ESP or AH packet arrives with an unrecognized SPI, it
      could be because the receiving node has recently crashed and
      lost state or because of some other system malfunction or
      attack.
=20
   o  If an encrypted IKE request packet arrives on port 500 or 4500
      with an unrecognized IKE SPI, it could be because the receiving node
      has recently crashed and lost state, or because of some other
      system malfunction or attack.
=20
   o If an IKE request packet arrives with a higher major version
     number than the implementation supports.
=20
   (Note that the second and third cases apply only to IKE request
   packets, not response packets.)
=20
   In the first case, if the receiving node has an active IKE SA to
   the IP address from whence the packet came, it MAY send an
   INVALID_SPI notification of the wayward packet over that IKE SA in
   an INFORMATIONAL exchange. The Notification Data contains the SPI
   of the invalid packet. The recipient of this notification cannot
   tell whether the SPI is for AH or ESP, but this is not important
   because the SPIs are supposed to be different for the two.
=20
   If no suitable IKE SA exists, the node MAY send an INFORMATIONAL
   message without cryptographic protection to the source IP address,
   using the source UDP port as the destination port if the packet was
   UDP (IKE or UDP-encapsulated ESP or AH). In this case, it should only=20
   be used by the recipient as a "hint" that something might be wrong=20
   (because it could easily be forged). This message is not part of an=20
   INFORMATIONAL exchange, and the receiving node MUST NOT respond to it=20
   (doing so could cause a message loop). The message is constructed as=20
   follows: There are no IKE SPI values that would be meaningful to the=20
   recipient of such a notification; using zero values or random values=20
   are both acceptable, this being the exception to the rule in=20
   [section 3.1] that prohibits zero IKE Initiator SPIs.  The Initiator=20
   flag is set, the Response bit is set to 0, and the version flags are=20
   set in the normal fashion.
=20
   In the second and third cases, the message is always sent without
   cryptographic protection (outside of an IKE SA), and includes
   either INVALID_IKE_SPI or INVALID_MAJOR_VERSION notification (with
   no notification data).  The message is a response message, and thus
   it is sent to the IP address and port from whence it came with the
   same IKE SPIs and the Message ID and Exchange Type are copied
   from the request. The Response bit is set to 1, and the version
   flags are set in the normal fashion. =20





-----Original Message-----
From: Tero Kivinen [mailto:kivinen@iki.fi]=20
Sent: Thursday, January 28, 2010 4:40 PM
To: Yoav Nir
Cc: ipsec@ietf.org
Subject: [IPsec] Closing issue #143 (rewrite of section 1.5)

Yoav Nir writes:
> Is this acceptable to everyone?

Couple of comments.=20

>    There are couple of cases when a node receives a packet it cannot
>    process, but may want to notify the sender about this situation:
>=20
>    o  If an ESP or AH packet arrives with an unrecognized SPI, it
>       could be because the receiving node has recently crashed and
>       lost state or because of some other system malfunction or
>       attack.
>=20
>    o  If an encrypted IKE request packet arrives on port 500 or 4500
>       with an unrecognized IKE SPI, it could be because the receiving nod=
e
>       has recently crashed and lost state, or because of some other
>       system malfunction or attack.
>=20
>    o If an IKE request packet arrives with a higher major version
>      number than the implementation supports.
>=20
>    (Note that the second and third cases apply only to IKE request
>    packets, not response packets.)
>=20
>    In the first case, if the receiving node has an active IKE SA to
>    the IP address from whence the packet came, it MAY send an
>    INVALID_SPI notification of the wayward packet over that IKE SA in
>    an INFORMATIONAL exchange. The Notification Data contains the SPI
>    of the invalid packet. The recipient of this notification cannot
>    tell whether the SPI is for AH or ESP, but this is not important
>    because the SPIs are supposed to be different for the two.
>=20
>    If no suitable IKE SA exists, the node MAY send an INFORMATIONAL
>    message without cryptographic protection to the source IP address.

We should also note that it should use the same port number that was
used for sending this unknown ESP packet was UDP encapsulated when it
came in.

I.e. if it receives raw ESP or AH, it knows there cannot be NAT, thus
port 500 is ok.

If it receives UDP encapsulateed ESP packet with unknow SPI then it
knows there most likely is a NAT (or firewall) which requires UDP
encapsulation, thus the informational message should also be sent
using UDP encapsulation format (i.e. use the IP addresses and ports in
the incoming UDP encapsulated packet and just swap source and
destination, and the IKE packet also needs to have four octets of zero
prepended to it).

>    In this case, it should only be used by the recipient as a "hint"
>    that something might be wrong (because it could easily be forged).
>    This message is not part of an INFORMATIONAL exchange, and the
>    receiving node MUST NOT respond to it (doing so could cause a
>    message loop). The message is constructed as follows: There are no
>    IKE SPI values that would be meaningful to the recipient of such a
>    notification; using zero values or random values are both
>    acceptable, this being the exception to the rule in [section 3.1]
>    that prohibits zero IKE SPIs.  The Initiator flag is set, the

s/prohibits zero IKE SPIs/prohibits zero IKE Initiator's SPI./

>    Response bit is set to 0, and the version flags are set in the normal
>    fashion.
>=20
>    In the second and third cases, the message is always sent without
>    cryptographic protection (outside of an IKE SA), and includes
>    either INVALID_IKE_SPI or INVALID_MAJOR_VERSION notification (with
>    no notification data).  The message is a response message, and thus
>    it is sent to the IP address and port from whence it came with the
>    same IKE SPIs and the Message ID is copied.  The Response bit is
>    set to 1, and the version flags are set in the normal fashion. The
>    responder SHOULD copy the Exchange Type from the request.

I would move the exchange type to the same list with IKE SPIs and
Message ID, ie.. change the text to be:

			The message is a response message, and thus
     it is sent to the IP address and port from whence it came with the
     same IKE SPIs and the Message ID and Exchange Type are copied
     from the request. The Response bit is set to 1, and the version
     flags are set in the normal fashion. =20
--=20
kivinen@iki.fi

Scanned by Check Point Total Security Gateway.

From ynir@checkpoint.com  Sun Jan 31 01:36:39 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7596528C0F8 for ; Sun, 31 Jan 2010 01:36:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.517
X-Spam-Level: 
X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVotCAbQyLlP for ; Sun, 31 Jan 2010 01:36:38 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 51E6D28C0E9 for ; Sun, 31 Jan 2010 01:36:38 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0V9b5T7002597; Sun, 31 Jan 2010 11:37:05 +0200 (IST)
X-CheckPoint: {4B654F31-0-1B201DC2-5FFFF}
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 31 Jan 2010 11:37:25 +0200
From: Yoav Nir 
To: "'suni kumar'" , "ipsec@ietf.org" 
Date: Sun, 31 Jan 2010 11:37:24 +0200
Thread-Topic: [IPsec] DHCP over IPSEC
Thread-Index: AcqgnZ3QYVBpUcTOTRyG2J91v3LMpgBusB3g
Message-ID: <006FEB08D9C6444AB014105C9AEB133FB36A51114A@il-ex01.ad.checkpoint.com>
References: <3b231eca1001282040t5f5a73f7q429a85108b7bb0c@mail.gmail.com>
In-Reply-To: <3b231eca1001282040t5f5a73f7q429a85108b7bb0c@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_006FEB08D9C6444AB014105C9AEB133FB36A51114Ailex01adcheck_"
MIME-Version: 1.0
Subject: Re: [IPsec] DHCP over IPSEC
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 Jan 2010 09:36:39 -0000

--_000_006FEB08D9C6444AB014105C9AEB133FB36A51114Ailex01adcheck_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

IKE & IPsec treat DHCP like any other protocol.

The selectors for DHCP traffic are a little strange, because the DHCP clien=
t begins by using IP address 0.0.0.0.

Please have a look at http://tools.ietf.org/html/rfc3456

In IKEv2, the CP payload takes over the function of DHCP over IPsec.

Hope this helps

Yoav

________________________________
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of s=
uni kumar
Sent: Friday, January 29, 2010 6:41 AM
To: ipsec@ietf.org
Subject: [IPsec] DHCP over IPSEC

hello
       My name is suneel kumar,i want some information regarding dhcp over =
ipsec,and functionality dhcp relay in a gateway

--_000_006FEB08D9C6444AB014105C9AEB133FB36A51114Ailex01adcheck_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


















IKE & IPsec treat DHCP like any ot=
her
protocol.



 



The selectors for DHCP traffic are a
little strange, because the DHCP client begins by using IP address 0.0.0.0.=




 



Please have a look at http://tools.ietf.org/html/rfc3=
456



 



In IKEv2, the CP payload takes over th=
e
function of DHCP over IPsec.



 



Hope this helps



 



Yoav



 















From:
ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of suni kumar

Sent: Friday, January 29, 20=
10
6:41 AM

To: ipsec@ietf.org

Subject: [IPsec] DHCP over I=
PSEC






 



hello

       My name is suneel kumar,i want some
information regarding dhcp over ipsec,and functionality dhcp relay in a gat=
eway









--_000_006FEB08D9C6444AB014105C9AEB133FB36A51114Ailex01adcheck_--

From kohn.jack@gmail.com  Sun Jan 31 09:54:59 2010
Return-Path: 
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B6463A67EB for ; Sun, 31 Jan 2010 09:54:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ru86yOoqxOYS for ; Sun, 31 Jan 2010 09:54:58 -0800 (PST)
Received: from mail-yx0-f194.google.com (mail-yx0-f194.google.com [209.85.210.194]) by core3.amsl.com (Postfix) with ESMTP id 690533A689D for ; Sun, 31 Jan 2010 09:54:58 -0800 (PST)
Received: by yxe32 with SMTP id 32so358581yxe.5 for ; Sun, 31 Jan 2010 09:55:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=rqaGIa/WH4/q67NEc6HWcTR44g1FIUy2E8GumeShT8o=; b=wLTDW8yq5BltNw5ymEuHSQ5CA1T+vSIoy/JjkvGLOlnjr+Zr2vcLC+V45dKZgMQD0E +WrSjRrPOxtCDFJUtJsCa3Q6zQ4znPKQPLhw+GQtRmaGqIS78T3U3G9uyUSH5FlbIyCM XnnV0yy7py2YJz9TGwSvjnh4efJiMV/aaqq/w=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ImJuEUmC2GNwThyIYOLYGT++OeO4mC7XNlRsPg23HvtEI3mY/Xzwm9C7x+WWXe2uGt s5Q8RFIArSIuxZYXzOWDBhJRBqs1wj5emWL1jM7TY0sLsVMrs1unChaWEJQDYBjNNKDN 7rPHe0bFH9T7Hr6AUEAFnzO0fb4y9ERa0p3cs=
MIME-Version: 1.0
Received: by 10.90.246.19 with SMTP id t19mr2916036agh.119.1264960522894; Sun,  31 Jan 2010 09:55:22 -0800 (PST)
In-Reply-To: <19297.29051.606291.367732@fireball.kivinen.iki.fi>
References: <20100127144502.9AEBF3A6AA0@core3.amsl.com>  <19297.29051.606291.367732@fireball.kivinen.iki.fi>
Date: Sun, 31 Jan 2010 23:25:22 +0530
Message-ID: 
From: Jack Kohn 
To: Tero Kivinen 
Content-Type: text/plain; charset=ISO-8859-1
Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com
Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-esp-null-heuristics-04.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 Jan 2010 17:54:59 -0000

>
>> I also think that we need to mention that this does open up a window
>> for DoS attacks as explained in the above post in the Security
>> Considerations section.
>
> What DoS attack you are talking. If you can provide me some text I can
> put to draft, I am happy to do so, but anyways I would first need to
> know which DoS attack you are talking about.

I think there is some text wrt "cache trashing" which will require
re-execution of the heuristics engine. An attack exploiting this can
result in a DoS attack.

Jack

> --
> kivinen@iki.fi
>