Re: [Ipsec] Number of SPD Policies

10.1.5.x-------66.80.90.10----66.80.10.2----192.168.1.x

10.1.6.x--------66.80.90.10----66.80.10.2----192.168.2.x<= /DIV>

As per RFC 2401, we could = define two=20 SPD Policies for each of them,

especially AH strength can be different for both of them.

for 10.1.5.x = to=20 192.168.1.x.We could define AH=3D = MD5 and=20 ESP=3DDES.

for 10.1.6.x to 192.168.2.x We = could define=20 AH=3DSHA and ESP=3D3DES.

But with 2401bis, we can define = only one AH=20 encryption strength

for both the = policies.

i.e.for SPD1 10.1.5.x to = 192.168.1.x ESP =3D=20 DES -ReturntoIpsec

i.e.for SPD2 10.1.6.x to = 192.168.2.x ESP =3D=20 3DES -ReturntoIpsec

i.e for SPD3 66.80.90.10 = to 66.80.10.2=20 AH =3D MD5 -ForwardOut

We can no longer specify = service based=20 cryptographic strength,

if the Service = is ESP between the two tunnel = endpoints.

Is this = understanding=20 correct ?

To overcome this limitation, a=20 configuration can allow

Administrator to enter ESP and = AH transform=20 in the same policy.

If the Policy is 2401bis, the=20 implementation can negotiate

using IKEv2 with the peer, for = 2 sets of=20 traffic selectors,

one with Plain Taffic selectors = and the=20 other with Tunnel header

IPs + ESP traffic = selector. By this=20 mechanism, the AH = Algorithm=20

applied to a given packet will = depend on=20 the selectors of the =

clear text = packet. Of-course, there=20 may be implications on

IKEv2 also based on this. But = this is one=20 mechanism that can

be = considered to=20 provide service level = cryptography=20 strength.

Also, in the above example, if = the=20 forwarding entries such

as ReturntoIpsec was not = present for SPD1, rather

ForwardOut was configured, the = encrypted=20 ESP packet would =

be directly sent out. Is = this a=20 correct understanding=20 ?

Thanks,

Subha

----- Original Message ----- =

From: "Tero Kivinen" <kivinen@iki.fi>

To: "Subha" <subhaav@intoto.com>

Cc: "Stephen Kent" <kent@bbn.com>; <ipsec@ietf.org>

Sent: Monday, April 04, 2005 4:55 = AM

Subject: Re: [Ipsec] Number of SPD=20 Policies

> Subha writes:
>> 1) When IKEv2 is used with = RFC2401=20 compliant implementation, can a
>> single IKEv2 CREATE_CHILD_SA = negotiate IPcomp, ESP and AH SAs for
>> the given traffic=20 selector?
>
> Trying to use IKEv2 and RFC2401 is not very = good=20 idea, as some of the
> features of the IKEv2 cannot be expressed = in the=20 RFC2401 policy. Also
> the same thing applies to other way around, = meaning=20 that IKEv2 is
> mostly matching RFC2401bis. This means that = especially=20 implementations
> will only support IKEv2 for the features = required for=20 the RFC2401bis.
> As RFC2401bis does NOT require ESP and AH to be=20 negotiated
> simultaenously, I guess most of the implementations = WILL NOT=20 support
> it.
>
> IPcomp can be negotiated in = addition to the=20 ESP or AH in the IKEv2
> too, but the negotiation is quite = different than=20 what was for IKEv1
> (or RFC2401).
>
> Also note, = that IKEv2=20 draft explicitly mandates RFC2401bis handling of
> the ECN flag, = i.e.=20 meaning that you cannot use base RFC2401 with
> IKEv2, you need to = extend=20 your RFC2401 implementation to include
> RFC2401bis ECN handling = if you=20 want to use IKEv2.
>
>> 2) When IKEv2 is used with = RFC2401-bis=20 compliant implementation,
>> there has to be theee IKEv2=20 CREATE_CHILD_SA Exchanges.
>
> No. IKEv2 allows IPcomp to = be=20 negotiated only when some other child SA
> is negotiated. IPComp = is mostly=20 outside the scope of IPsec,and
> RFC2401bis does not really cover = that at=20 all (it just mentions that it
> can be negotiated).
> =
> You=20 do 2 CREATE_CHILD_SA exchanges.
>
>> (1) Plain Traffic = selectors=20 for IPcomp SA
>
> There is no way to do that in IKEv2, you = MUST=20 have either ESP or AH.
>
>> (2) Same Source IP, = Destination IP=20 and IPComp for Protocol -
>> = Traffic=20 Selectors for ESP SA
>
> No, Plain traffic selectors for = ESP SA,=20 and include IPCOMP_SUPPORTED
> notify to mention that you want to = do ip=20 compression.
>
>
>> (3) Tunnel Outer Header = Source IP,=20 Tunnel Outer Header Destination
>> IP = and=20 Protocol=3DESP for AH SA.
>
> Yes, this is the second one. =
>=20 --
> kivinen@safenet-inc.com
> ------=_NextPart_000_002E_01C53917.5B86A930-- --===============1033506679== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1033506679==-- From ipsec-bounces@ietf.org Tue Apr 5 05:23:08 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27845 for ; Tue, 5 Apr 2005 05:23:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIk9P-00068B-TI; Tue, 05 Apr 2005 05:15:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIk9L-00064U-1d for ipsec@megatron.ietf.org; Tue, 05 Apr 2005 05:15:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26591 for ; Tue, 5 Apr 2005 05:15:00 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIkHN-0000Av-3w for ipsec@ietf.org; Tue, 05 Apr 2005 05:23:26 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j359EovZ006628 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 5 Apr 2005 12:14:50 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j359EmJj006625; Tue, 5 Apr 2005 12:14:48 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16978.22280.545861.239449@fireball.kivinen.iki.fi> Date: Tue, 5 Apr 2005 12:14:48 +0300 From: Tero Kivinen To: "Subha" Subject: Re: [Ipsec] Number of SPD Policies In-Reply-To: <003701c53952$0aabf430$4205010a@subha> References: <00e801c536f8$531e4850$4205010a@subha> <015701c5371b$f3885510$4205010a@subha> <16977.11042.656521.73950@fireball.kivinen.iki.fi> <003701c53952$0aabf430$4205010a@subha> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 4 min X-Total-Time: 4 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Stephen Kent X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Subha writes: > It looks like 2401bis brings up a limitation that we cannot > define different AH strength for ESP encrypted packets > between the same two security gateways. Yes, I think you are right. The question is: Is there any reason to really do that? Why are you doing AH+ESP between the local GW and Remote GW in any case, why are you not simply using ESP with suitable auth algorithm? As you are using tunnel mode there AH does not offer anything more compared to the ESP. The only case where I can see there would be use for AH+ESP is when the AH and ESP are terminated by different hosts, i.e. AH goes to from host to firewall, and the ESP goes from host through the firewall to the other end host. As there EVER any valid scenario where you would need to use AH+ESP where both of those are terminated by same peers? -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Apr 5 08:20:00 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13638 for ; Tue, 5 Apr 2005 08:20:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DImsm-0003ya-4d; Tue, 05 Apr 2005 08:10:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DImsj-0003yA-PQ for ipsec@megatron.ietf.org; Tue, 05 Apr 2005 08:10:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12079 for ; Tue, 5 Apr 2005 08:10:08 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIn0s-0006j3-Cb for ipsec@ietf.org; Tue, 05 Apr 2005 08:18:34 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j35C9xZB008379 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 5 Apr 2005 15:10:00 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j35C9wN5008376; Tue, 5 Apr 2005 15:09:58 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16978.32790.327313.883104@fireball.kivinen.iki.fi> Date: Tue, 5 Apr 2005 15:09:58 +0300 From: Tero Kivinen To: Charlie Kaufman X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 3 min X-Total-Time: 3 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: [Ipsec] Error in draft-ietf-ipsec-ikev2-17.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit I found error (or typo) in the draft-ietf-ipsec-ikev2-17.txt that probably should be fixed in the author 48 hours period. The section 2.6 still refers to the SPIr when it should say "Cookie". I.e. CHANGE If it matches, the responder knows that SPIr was generated since the last change to and that IPi must be the same as the source address it saw the first time. to If it matches, the responder knows that Cookie was generated since the last change to and that IPi must be the same as the source address it saw the first time. (This typo is left over from the times we didn't have N(COOKIE) notify, but instead generated SPIr and used it as a COOKIE). -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Apr 5 08:20:00 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13637 for ; Tue, 5 Apr 2005 08:20:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DImyd-0005yt-HW; Tue, 05 Apr 2005 08:16:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DImyZ-0005yU-P1 for ipsec@megatron.ietf.org; Tue, 05 Apr 2005 08:16:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13020 for ; Tue, 5 Apr 2005 08:16:10 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIn6h-00076g-W6 for ipsec@ietf.org; Tue, 05 Apr 2005 08:24:37 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j35CG6PD008416 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 5 Apr 2005 15:16:06 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j35CG2oj008411; Tue, 5 Apr 2005 15:16:02 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16978.33154.351915.320602@fireball.kivinen.iki.fi> Date: Tue, 5 Apr 2005 15:16:02 +0300 From: Tero Kivinen To: pasi.eronen@nokia.com, paul.hoffman@vpnc.org X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 2 min X-Total-Time: 2 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: [Ipsec] Comments of draft-eronen-ipsec-ikev2-clarifications-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit > 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 MUST be an element of the group the > initiator expects the responder to accept (additional > Diffie-Hellman groups can be proposed). I think the above sentece is missing some things: "... include the Diffie-Hellman group of the KEi MUST be an ..." Perhaps it should be: "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)." Also if we think more about the IKE SA rekeying, I do not think there is any reason to do that unless you also do new Diffie-Hellman there too. Rekeying IKE SA because of the IKE message ID wrapping is not common. The current IKEv2 text is not clear wheather the intension was that IKE SA rekey MUST have KE payloads, but I think we should mandate them, i.e. say in the NEW-1.3.2 that KE payloads are not optional there. The section 5 should also point out that INTERNAL_ADDRESS_EXPIRY is not mandatory in the IKEv2, and in most cases it would be best not to use it at all. Most of the clients will not tolerate the server not to give the same address back when the address lease expires. This means that only reason to do address expiry is to know when the client stops using the address. In IKEv2 this time is very clear as it is also tied to the IKE SA. If the IKE SA is deleted then the client cannot use the address anymore, and when he recretes the IKE SA he need to get the address again using configuration payloads (he also need to recreate all IPsec SAs and change the traffic selectors to match new addresses etc). Because of that I would recommend that INTERNAL_ADDRESS_EXPIRY SHOULD NOT be used in the IKEv2. > 6.1 Diffie-Hellman for first CHILD_SA > > Section 1.2 shows that IKE_AUTH messages do not contain KEi/KEr or > Ni/Nr payloads. This implies that the SA payload in IKE_AUTH > exchange cannot contain Transform Type 4 (Diffie-Hellman Group) with > any other value than NONE. And most commonly that should be coded as leaving out transform type 4 completely. > 6.5 Reducing the window size > > In IKEv2, the window size is assumed to be a (possibly configurable) > property of a particular implementation, and is not related to > congestion control (unlike the window size in TCP, for instance). > > In particular, there is no way to reduce the window size of an > existing IKE_SA. However, when rekeying an IKE_SA, the new IKE_SA > starts with window size 1 until it is explicitly increased by sending > a new SET_WINDOW_SIZE notification. More precisely, you could send SET_WINDOW_SIZE notification with smaller window than before, but it is not defined what responder should do in that case. He might have more request than allowed by the new window size already out, thus he cannot reduce the window size. Because of this the reduction of window size cannot be done before the responder processing rules have been define, i.e. currently reducing window size is forbidden. > 6.9 SPI values for messages outside of an IKE_SA > > The IKEv2 specification does not say what SPI values should be used > for Informational requests sent outside of an IKE_SA. > > There seem to be two cases when such a message can be sent: > INVALID_IKE_SPI and INVALID_SPI notifications. Especially in the > latter case, no meaningful IKE SPI values are available. > > 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. I think whole section should be clarified. There cannot be any informational exchanges outside the IKE SA, thus there will always be IKE SPIs for that packet. IKEv2 DOES NOT have non-authenticated notifications that the IKEv1 had. The section 1.5 describes about case where the responder of packet could send out packet looking like informational exchange as a response to the packet it receives, but that is not part of an informational exchange, and responder should not act based on the received packet, except it might start DPD because of the packet (i.e. it is treader similarly than ICMP host unreachable etc are treated). In that case using all zero SPI fields is acceptable. > 6.11 INVALID_IKE_SPI ... > Since the INVALID_IKE_SPI notification is sent outside of an IKE_SA, > and it is not about an existing SA, it seems that using Notification > Data would be the logical choice. However, this issue needs more > discussion and we do not yet propose any solution in this document. The INVALID_IKE_SPI can also be sent inside the existing IKE SA. See section 1.5 of IKEv2 draft for more details. As the description of the INVALID_IKE_SPI says that unrecognized destination SPI, which would indicate that destination SPI was the one we didn't know anything about. So my interpretation would be to use SPI field of the notification payload (as it does not say put it in the data field), and only put destination SPI there, with protocol ID of IKE. On the other hand section 3.10 says sthat SPI size for the notification concerning MUST be zero, so I agree this is not really consistent. > 6.12 Which message should contain INITIAL_CONTACT ... > The text does talk about authenticated identities, so it seems the > notification cannot be sent before both endpoints have been > authenticated. Thus, the possible places are the last IKE_AUTH > response message and a separate Informational exchange. Initiator usually knows to whom is is supposed to talk to and he knows weather he has SA with him before or not (if he had IKE SA he would have used it, or he had some other reason not to use it). So it means that initiator can send INITIAL_CONTACT in IKE_AUTH and responder can respond to that in the same packet. I would actually prefer that instead of using separate informational exchange. > Based on how this was implemented in IKEv1, it seems the intent was > to use a separate Informational exchange. In IKEv1 it was supposed to be sent inside the main mode, but as the extra payloads are not authenticated there, some implementations use separate informational exchange for it. For IKEv1 it was actually very bad idea to use separate informational exchange as they were not reliable. > o The message IDs of IKE_SA_INIT messages is unclear if there are > cookies followed by INVALID_KE_PAYLOAD. See "Question about > N(COOKIE) and N(INVALID_KE_PAYLOAD) combination" thread, Oct 2004. > This definitely needs to be clarified. I do not think this is unclear. When you create state in the responder you allocate IKE SPI and start using message IDs. If you return N(COOKIE), you do not allocate anything, thus you do not allocate IKE SA SPI, and as message ID is property of IKE SA, you do not use it yet. If you return N(INVALID_KE_PAYLOAD) that is fatal error, and again you do not need to allocate IKE SA nor the SPI, thus no message ID can be stored. When the initiator retries with both N(COOKIE) and with proper group, then you finally allocate IKE SA and the SPI, and start using message IDs. Thus message id of IKE_SA_INIT should always be zero. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Apr 5 09:38:20 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20405 for ; Tue, 5 Apr 2005 09:38:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIoAD-0002Nb-Gx; Tue, 05 Apr 2005 09:32:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIoAB-0002KN-Pg for ipsec@megatron.ietf.org; Tue, 05 Apr 2005 09:32:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19958 for ; Tue, 5 Apr 2005 09:32:13 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=smtp.intoto.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DIoIK-0001Y2-Cl for ipsec@ietf.org; Tue, 05 Apr 2005 09:40:41 -0400 Received: from brahma.intotoind.com ([172.16.1.10]) by smtp.intoto.com (SMSSMTP 4.0.0.59) with SMTP id M2005040506313209848 for ; Tue, 05 Apr 2005 06:31:32 -0700 Received: from SriRam.intoto.com (2mc54.intotoind.com [172.16.2.54]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id j35DW1fO020015 for ; Tue, 5 Apr 2005 19:02:01 +0530 Message-Id: <5.1.0.14.0.20050405190205.02bb8b48@172.16.1.10> X-Sender: tosri@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 05 Apr 2005 19:08:48 +0530 To: ipsec@ietf.org From: Tatineni SriRama Kumar Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Ipsec] Blocking traffic using opaque X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi All, As per point C and D in section 4.4.1.3 of 2401bis, traffic will be passed in only one direction. Based on this I have following questions. 1. How configuration specified in point B of same section allows traffic in both directions. 2. If configuration specified in points B,C and D allows traffic in one direction only, what should be the configuration to allow traffic in both directions. --SriRam/Vineet _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Apr 5 09:55:01 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21690 for ; Tue, 5 Apr 2005 09:55:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIoUz-0005N1-2t; Tue, 05 Apr 2005 09:53:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIoUw-0005JT-Dl for ipsec@megatron.ietf.org; Tue, 05 Apr 2005 09:53:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21534 for ; Tue, 5 Apr 2005 09:53:40 -0400 (EDT) Received: from nav2.lgsoftindia.com ([203.200.13.13] helo=nav2) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIod4-0002DH-4x for ipsec@ietf.org; Tue, 05 Apr 2005 10:02:08 -0400 Received: from appolo.lgdomain.com ([192.168.1.22]) by nav2 with InterScan Messaging Security Suite; Tue, 05 Apr 2005 19:26:22 +0530 x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Apr 2005 19:28:02 +0530 Message-ID: Thread-Topic: doubts about IKEv2 implementation Thread-Index: AcU553uwqd1f/s/VQICX+aTqZs+V+w== From: "Soumya Sen" To: X-Spam-Score: 0.5 (/) X-Scan-Signature: 2b428fb4265163ba7f2ac2af0ebfcf00 Subject: [Ipsec] doubts about IKEv2 implementation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0820247764==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0820247764== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C539E7.7B9E4388" This is a multi-part message in MIME format. ------_=_NextPart_001_01C539E7.7B9E4388 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =0D I am a senior undergraduate student, presently undergoing industrial project training. I am trying to understand the IKEv2 protocol and went through the draft. However, I got certain doubts and interpreted certain things in my own way, but I am not sure whether the understanding is correct or flawed. I will be very grateful if you kindly take out some time to clear the doubts that I have listed below. Please explain the relevant concepts if my interpretation is wrong. Thanking you very much in advance, Best regards,=0D Soumya Sen. India. =0D =0D NOTE: Here the SA payload contents have been shown in "(...)" and the contents are separated by ";", while the payloads are separated by "," and proposal structures are separated by "[" or "]". =0D IKE_INIT_SA request: HDR("A",0), SAi1([proposal#1; protocol ID:1 (for IKE); SPI size:0; ..., ], [proposal #2; protocol ID:1; SPI size:0; ..., ]), KEi, Ni. =0D Let the IKE is assigned the SPI of value "A" from the sender's side. Let us assume only two proposals were made initially. No SPI field is present within the proposal substructures.=0D =0D IKE_INIT_SA response: HDR("A", "B"), SAr1([proposal#1; protocol ID:1; SPI size:0; ...; <1 transforms chosen from each transform type requested >]), KEr, Nr. =0D Proposal number 1 was chosen and one transform of each transform type under that proposal is returned. No SPI field is present within the proposal substructures.=0D =0D Q1: Am I correct to believe that *always* in the response *only one* chosen proposal is present i.e. the chosen proposal mentioning one transforms of each transform type required?=0D =0D Q2: In the case, that the responder chooses a proposal that had the proposal number #3, will the Proposal number mentioned in the responder's SA payload be 3(i.e. mention the chosen proposal number) or mentions the proposal no. as #1 always (*because only one proposal can be selected*). =0D IKE_AUTH request: HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,],AUTH, SAi2([proposal#1; protocol ID:2 (for AH); SPI size:4; ...,SPI value: "C"; ], [proposal #2; protocol ID:3 (for ESP); SPI size:4; ...,SPI value: "D"; ]), TSi, TSr} =0D SPIs for the SAs are proposed in the SPI fields in the Proposal Substructure. The initiator chooses the SPI values of "C" and "D" for the two proposals.=0D Q3: Is it that the values chosen for "C" and "D" *must* be different always?=0D =0D Q4: In the case where we want to propose that both AH and ESP are to be used for the traffic stream, we mark both the proposals as #1. In this case will the SPI value mentioned in the proposal substructure be different for the two proposals even though the Proposal no. is 1 for both the substructure?=0D =0D =0D IKE_AUTH response: HDR, SK {IDr, [CERT,] AUTH, SAr2([proposal#1; protocol ID:2 (for AH); SPI size:4; ...,SPI value: "E"; <1 transforms chosen from each transform type requested>]), TSi, TSr} =0D Proposal no.1 was chosen, the SPI value associated by the responder is "E" for this SA chosen from the offered set of SAs. =0D =0D Q5: Am I correct to believe that the SPI value chosen by the responder for the chosen proposal is randomly chosen to be "E". Can it also happen to choose the same value "C"?=0D =0D Q6: Am I correct to believe that the values chosen for this SA (here "C" on sender's side and "E" on receiver's side) are different and two distinct SA are existing in the two directions with *same* keys and *same* agreed upon set of algorithms?=0D =0D Q7: To REKEY this SA, will the sender send a CREATE_CHILD_SA request mentioning the SPI value as "E"(its inbound value) in the 'N' payload and the if successful both of them delete the SA corresponding to "C" on sender's side and "E" on responder's side?=0D =0D Q8: This CHILD created from the initial exchange may follow the protocol types of ESP, AH, both ESP & AH etc. But they can never support the option for a DH group transform type in the proposal since no KE payload can be sent along with the AUTH exchange messages.=0D So Perfect forward secrecy(PSF) cannot be supported in this child created through initial exchange? =0D Q9: While "Rekeying" it is being said that the CHILD_SA creates an equivalent SA to the one to be replaced. Does it mean that in the SA payload we send the *only* the same proposal which is the *presently existing* suite for the SA?=0D =0D Q10: Am I correct to think that the outer header(HDR) in the CREATE_CHILD_SA has the SPIs corresponding to the parent IKE? =0D Q11: When we Rekey an existing IKE_SA, in the CREATE_CHILD_SA do we need to mark the protocol ID as 3 (corresponding to IKE protocol value)? If we are creating an IKE then there should be no SPI value field mentioned in the SA structure, but again it is said that "the new initiator and responder SPIs are supplied in the SPI fields in the Proposal structure in the SA payload". I am getting confused here. Does it mean that the SA that is being created to rplace the parent IKE by using CREATE_CHILD_SA has to be AH or ESP and not an IKE protocol?=0D =0D =0D I will be glad to have your response to my doubts. Thanking you in advance, Soumya. =0D =0D =0D ***************************************************************************= ***************************************************************************= **** This email message is for the sole use of the intended recipient(s)and may= contain CONFIDENTIAL and PRIVILEGED information. LG Soft India will not be responsible for any viruses or defects or any= forwarded attachments emanating either from within=0D LG Soft India or outside. Any unauthorized review, use, disclosure or= distribution is prohibited. If you are not the intended=0D recipient, please contact the sender By reply email and destroy all copies= of the original message. ***************************************************************************= ***************************************************************************= **** ------_=_NextPart_001_01C539E7.7B9E4388 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

I am a senior undergraduate student, presently undergoing= industrial project training. I am trying to understand the IKEv2 protocol and went= through the draft. However, I got certain doubts and interpreted certain things in= my own way, but I am not sure whether the understanding is correct or flawed.= I will be very grateful if you kindly take out some time to clear the doubts= that I have listed below. Please explain the relevant concepts if my= interpretation is wrong. Thanking you very much in advance,

Best regards,

Soumya Sen.

India<= font size=3D2>.

NOTE: Here the SA payload contents have been shown in “(…)” and the contents are separated by “;”, while the payloads are separated by “,” and proposal structures= are separated by “[“ or= “]”.

IKE_INIT_SA= request:

HDR(“A”,0), SAi1([proposal#1; protocol ID:1 (for IKE);= SPI size:0; …, <transforms>], [proposal #2; protocol ID:1; SPI= size:0; …, <transforms>]), KEi, Ni.

Let the IKE is assigned the SPI of value “A” from the sender’s side. Let us assume only two proposals were made initially.= No SPI field is present within the proposal substructures.=

IKE_INIT_SA= response:

HDR(“A”, “B”), SAr1([proposal#1; protocol= ID:1; SPI size:0; …; <1 transforms chosen from each transform type= requested >]), KEr, Nr.

Proposal number 1 was chosen and one transform of each transform= type under that proposal is returned. No SPI field is present within the= proposal substructures.

Q1: Am I correct to believe that *always* in the response *only= one* chosen proposal is present i.e. the chosen proposal mentioning one= transforms of each transform type required?

Q2: In the case, that the responder chooses a proposal that had the proposal number #3, will the Proposal number mentioned in the= responder’s SA payload be 3(i.e. mention the chosen proposal number) or mentions the proposal no. as #1 always (*because only one proposal can be= selected*).

IKE_AUTH=
 request:

HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,],AUTH, SAi2([proposal#1;=
 protocol ID:2 (for AH); SPI size:4; …,SPI value: “C”;=
 <transforms>], [proposal #2; protocol ID:3 (for ESP); SPI size:4;=
 …,SPI value: “D”; <transforms>]), TSi,=
 TSr}

SPIs for the SAs are=
 proposed in the SPI fields in the Proposal Substructure. The initiator=
 chooses the SPI values of “C” and “D” for the two=
 proposals.

Q3: Is it that the=
 values chosen for “C” and “D” *must* be different=
 always?

Q4: In the case where=
 we want to propose that both AH and ESP are to be used for the traffic=
 stream, we mark both the proposals as #1. In this case will the SPI value=
 mentioned in the proposal substructure be different for the two proposals=
 even though the Proposal no. is 1 for both the substructure?=

IKE_AUTH=
 response:

HDR, SK {IDr, [CERT,] AUTH, SAr2([proposal#1; protocol ID:2 (for AH);=
 SPI size:4; …,SPI value: “E”; <1 transforms chosen=
 from each transform type requested>]), TSi,=
 TSr}

Proposal no.1 was=
 chosen, the SPI value associated by the responder is “E” for=
 this SA chosen from the offered set of SAs.=

Q5: Am I correct to=
 believe that the SPI value chosen by the responder for the chosen proposal=
 is randomly chosen to be “E”. Can it also happen to choose the=
 same value “C”?

Q6: Am I correct to=
 believe that the values chosen for this SA (here “C” on=
 sender’s side and “E” on receiver’s side) are=
 different and two distinct SA are existing in the two directions with=
 *same* keys and *same* agreed upon set of algorithms?=

Q7: To REKEY this SA,=
 will the sender send a CREATE_CHILD_SA request mentioning the SPI value as=
 “E”(its inbound value) in the ‘N’ payload and the=
 if successful both of them delete the SA corresponding to “C”=
 on sender’s side and “E” on responder’s side?=

Q8: This CHILD created=
 from the initial exchange may follow the protocol types of ESP, AH, both=
 ESP & AH etc. But they can never support the option for a DH group=
 transform type in the proposal since no KE payload can be sent along with=
 the AUTH exchange messages.

So Perfect forward=
 secrecy(PSF) cannot be supported in this child created through initial=
 exchange?

Q9: While=
 “Rekeying” it is being said that the CHILD_SA creates an=
 equivalent SA to the one to be replaced. Does it mean that in the SA=
 payload we send the *only* the same proposal which is the *presently=
 existing* suite for the SA?

Q10: Am I correct to=
 think that the outer header(HDR) in the CREATE_CHILD_SA has the SPIs=
 corresponding to the parent IKE?

Q11: When we Rekey an=
 existing IKE_SA, in the CREATE_CHILD_SA do we need to mark the protocol ID=
 as 3 (corresponding to IKE protocol value)? If we are creating an IKE then=
 there should be no SPI value field mentioned in the SA structure, but=
 again it is said that “the new initiator and responder SPIs are=
 supplied in the SPI fields in the Proposal structure in the SA=
 payload”. I am getting confused here. Does it mean that the SA that=
 is being created to rplace the parent IKE by using CREATE_CHILD_SA has to=
 be AH or ESP and not an IKE protocol?

I will be glad to have your response to my= doubts.

Thanking you in advance,

Soumya.

****************************************************************= ***************************************************************************= ***************

This email message is for the sole use of the= intended recipient(s)and may contain CONFIDENTIAL and PRIVILEGED= information.
LG Soft India will not be responsible for any viruses or= defects or any forwarded attachments emanating either from within
LG= Soft India or outside. Any unauthorized review, use, disclosure or= distribution is prohibited. If you are not the intended
recipient,= please contact the sender By reply email and destroy all copies of the= original= message.

**********************************************************= ***************************************************************************= *********************

------_=_NextPart_001_01C539E7.7B9E4388-- --===============0820247764== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0820247764==-- From ipsec-bounces@ietf.org Tue Apr 5 20:56:50 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06855 for ; Tue, 5 Apr 2005 20:56:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIypR-0005rU-Lm; Tue, 05 Apr 2005 20:55:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIypP-0005rN-CJ for ipsec@megatron.ietf.org; Tue, 05 Apr 2005 20:55:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06747 for ; Tue, 5 Apr 2005 20:55:29 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIyxb-0006ES-Uf for ipsec@ietf.org; Tue, 05 Apr 2005 21:04:03 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Tue, 5 Apr 2005 17:55:16 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Tue, 5 Apr 2005 17:55:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ipsec] doubts about IKEv2 implementation Date: Tue, 5 Apr 2005 17:55:17 -0700 Message-ID: Thread-Topic: RE: [Ipsec] doubts about IKEv2 implementation thread-index: AcU5257WT/ttHH7YRciiy/YnXZqKaQAJ1+SQAA/xiaA= From: "Charlie Kaufman" To: X-OriginalArrivalTime: 06 Apr 2005 00:55:17.0729 (UTC) FILETIME=[4CE60510:01C53A43] X-Spam-Score: 1.7 (+) X-Scan-Signature: 9a0a5b57b7540919633bb8f7cd3cb4bd X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1043468027==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1043468027== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C53A43.48DBCDE6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C53A43.48DBCDE6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I got this same question privately, and responded (see below). I'm forwarding this to the list to make sure no one else takes the time to respond. (Unless of course they have a different answer, in which case that should be on the list too!). =20 --Charlie =20 ________________________________ From: Charlie Kaufman=20 Sent: Tuesday, April 05, 2005 5:48 PM To: 'Soumya Sen' Subject: RE: doubts about the IKEv2 implementation =20 I've embedded comments below... Charlie =20 ________________________________ From: Soumya Sen [mailto:soumya.sen@lgsoftindia.com]=20 Sent: Tuesday, April 05, 2005 5:33 AM To: Charlie Kaufman Subject: doubts about the IKEv2 implementation =20 Dear Sir, =20 I am a senior undergraduate student, presently undergoing industrial project training. I am trying to understand the IKEv2 protocol and went through the draft. However, I got certain doubts and interpreted certain things in my own way, but I am not sure whether the understanding is correct or flawed. I will be very grateful if you kindly take out some time to clear the doubts that I have listed below. Please explain the relevant concepts if my interpretation is wrong. Thanking you very much in advance, Best regards,=20 Soumya Sen. India. =20 =20 NOTE: Here the SA payload contents have been shown in "(...)" and the contents are separated by ";", while the payloads are separated by "," and proposal structures are separated by "[" or "]". =20 IKE_INIT_SA request: HDR("A",0), SAi1([proposal#1; protocol ID:1 (for IKE); SPI size:0; ..., ], [proposal #2; protocol ID:1; SPI size:0; ..., ]), KEi, Ni. =20 Let the IKE is assigned the SPI of value "A" from the sender's side. Let us assume only two proposals were made initially. No SPI field is present within the proposal substructures.=20 =20 IKE_INIT_SA response: HDR("A", "B"), SAr1([proposal#1; protocol ID:1; SPI size:0; ...; <1 transforms chosen from each transform type requested >]), KEr, Nr. =20 Proposal number 1 was chosen and one transform of each transform type under that proposal is returned. No SPI field is present within the proposal substructures.=20 =20 Q1: Am I correct to believe that *always* in the response *only one* chosen proposal is present i.e. the chosen proposal mentioning one transforms of each transform type required?=20 > Yes. =20 Q2: In the case, that the responder chooses a proposal that had the proposal number #3, will the Proposal number mentioned in the responder's SA payload be 3(i.e. mention the chosen proposal number) or mentions the proposal no. as #1 always (*because only one proposal can be selected*). > In your example, the responder's SA proposal number would be 3. It is used to help the initiator > figure out which of his proposals was accepted. IKE_AUTH request: HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,],AUTH, SAi2([proposal#1; protocol ID:2 (for AH); SPI size:4; ...,SPI value: "C"; ], [proposal #2; protocol ID:3 (for ESP); SPI size:4; ...,SPI value: "D"; ]), TSi, TSr} =20 SPIs for the SAs are proposed in the SPI fields in the Proposal Substructure. The initiator chooses the SPI values of "C" and "D" for the two proposals.=20 Q3: Is it that the values chosen for "C" and "D" *must* be different always?=20 > No. I would expect that in most cases C and D would not be different. > The purpose of this SPI is to allow the initiator to identify the SA in the > processing of incoming ESP or AH packets, so if the initiator sets up > multiple SAs to the same IP address it would need for the SPIs to be > different. In expected implementations, a node would use different SPIs > for each of its open SAs even to different IP addresses. The only time > the initiator would put different SPIs in proposals for the same SA would > be if it wanted to use different SPIs depending on which of the proposals > the responder accepted. =20 Q4: In the case where we want to propose that both AH and ESP are to be used for the traffic stream, we mark both the proposals as #1. In this case will the SPI value mentioned in the proposal substructure be different for the two proposals even though the Proposal no. is 1 for both the substructure?=20 > Probably. When using both ESP and AH, the data packets have an ESP header > encapsulated in the AH data, so there are two SPIs. I would expect these two > SPIs would be different, though IKEv2 does not require that they be. =20 IKE_AUTH response: HDR, SK {IDr, [CERT,] AUTH, SAr2([proposal#1; protocol ID:2 (for AH); SPI size:4; ...,SPI value: "E"; <1 transforms chosen from each transform type requested>]), TSi, TSr} =20 Proposal no.1 was chosen, the SPI value associated by the responder is "E" for this SA chosen from the offered set of SAs. =20 =20 Q5: Am I correct to believe that the SPI value chosen by the responder for the chosen proposal is randomly chosen to be "E". Can it also happen to choose the same value "C"?=20 > The responder may choose E randomly or may choose it to index > some table in the responder's memory. E could be the same as C. =20 Q6: Am I correct to believe that the values chosen for this SA (here "C" on sender's side and "E" on receiver's side) are different and two distinct SA are existing in the two directions with *same* keys and *same* agreed upon set of algorithms?=20 > Almost. The specification is awkward because ESP and AH insist on considering > the two directions of communication to be separate SAs, but the IKE SA is > bidirectional. So IKEv2 always creates and deletes ESP and AH SAs in pairs, > and I would expect implementations to treat them as a single entity, but the > spec has to say that they are separate SAs. The algorithms must be the same > in both directions, but the keys are different. The keys for both directions are > derived from a common base key as specified in the spec. Q7: To REKEY this SA, will the sender send a CREATE_CHILD_SA request mentioning the SPI value as "E"(its inbound value) in the 'N' payload and the if successful both of them delete the SA corresponding to "C" on sender's side and "E" on responder's side? > Yes, except that technically it's a pair of SAs being rekeyed, so your sentence > should say "...deleted the SAs corresponding...". =20 =20 Q8: This CHILD created from the initial exchange may follow the protocol types of ESP, AH, both ESP & AH etc. But they can never support the option for a DH group transform type in the proposal since no KE payload can be sent along with the AUTH exchange messages.=20 So Perfect forward secrecy(PSF) cannot be supported in this child created through initial exchange? > Perfect forward secrecy comes from forgetting the DH private key (and SK_d) no later > than when the child SA is closed. To get PFS for the initial pair of child SAs, it is > necessary to first rekey the IKE SA, forget the keying material associated with it, > and then rekey the child SA. By design, PFS does not require an additional DH > exchange, though it is allowed because some crypto people don't believe it. =20 Q9: While "Rekeying" it is being said that the CHILD_SA creates an equivalent SA to the one to be replaced. Does it mean that in the SA payload we send the *only* the same proposal which is the *presently existing* suite for the SA? > People have debated what the phrase means. What you describe is the normal case. > Some people read the spec as saying that you can't change cryptographic algorithms > or traffic selectors, while others think you can. This may be clarified in a future > revision of the spec. A conservative implementation would only propose the > presently existing suite but would accept changes if requested from the other side > (because then they would interoperate with anyone). =20 =20 Q10: Am I correct to think that the outer header(HDR) in the CREATE_CHILD_SA has the SPIs corresponding to the parent IKE? > Yes. All IKE messages have the SPIs corresponding to the outer IKE. =20 Q11: When we Rekey an existing IKE_SA, in the CREATE_CHILD_SA do we need to mark the protocol ID as 3 (corresponding to IKE protocol value)? If we are creating an IKE then there should be no SPI value field mentioned in the SA structure, but again it is said that "the new initiator and responder SPIs are supplied in the SPI fields in the Proposal structure in the SA payload". I am getting confused here. Does it mean that the SA that is being created to rplace the parent IKE by using CREATE_CHILD_SA has to be AH or ESP and not an IKE protocol?=20 > In the initial exchange setting up an IKE_SA, the proposals contain no SPIs > because the SPIs implicitly are the values in the header of the messages > negotiating the IKE_SA. When a new IKE_SA is created within a > CREATE_CHILD_SA exchange, the eight byte SPIs are included in the > SA payloads. The new SPIs will be used in messages that are cryptographically > protected with the new keys (so an implementation can know which key to use > by looking at the SPI). =20 =20 I will be glad to have your response to my doubts. Thanking you in advance, Soumya. =20 ************************************************************************ ************************************************************************ ********** This email message is for the sole use of the intended recipient(s)and may contain CONFIDENTIAL and PRIVILEGED information. LG Soft India will not be responsible for any viruses or defects or any forwarded attachments emanating either from within=20 LG Soft India or outside. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended=20 recipient, please contact the sender By reply email and destroy all copies of the original message. ************************************************************************ ************************************************************************ ********** =09 ------_=_NextPart_001_01C53A43.48DBCDE6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I got this same question privately, = and responded (see below). I’m forwarding this to the list to make = sure no one else takes the time to respond. (Unless of course they have a = different answer, in which case that should be on the list = too!).

= --Charlie

From: = Charlie Kaufman
Sent: Tuesday, April 05, = 2005 5:48 PM
To: 'Soumya Sen'
Subject: RE: doubts about = the IKEv2 implementation

I’ve embedded comments = below… Charlie

From: = Soumya Sen [mailto:soumya.sen@lgsoftindia.com]
Sent: Tuesday, April 05, = 2005 5:33 AM
To: Charlie Kaufman
Subject: doubts about the = IKEv2 implementation

Dear Sir,

I am a senior undergraduate student, presently undergoing = industrial project training. I am trying to understand the IKEv2 protocol and went = through the draft. However, I got certain doubts and interpreted certain things = in my own way, but I am not sure whether the understanding is correct or = flawed. I will be very grateful if you kindly take out some time to clear the = doubts that I have listed below. Please explain the relevant concepts if my = interpretation is wrong. Thanking you very much in advance,

Best regards,

Soumya Sen.

India.

NOTE: Here the SA payload contents have been shown in “(…)” and the contents are separated by = “;”, while the payloads are separated by “,” and proposal = structures are separated by “[“ or “]”.

IKE_INIT_SA request:

HDR(“A”,0), SAi1([proposal#1; protocol ID:1 (for = IKE); SPI size:0; …, <transforms>], [proposal #2; protocol ID:1; SPI = size:0; …, <transforms>]), KEi, Ni.

Let the IKE is assigned the SPI of value “A” from = the sender’s side. Let us assume only two proposals were made initially. No SPI field = is present within the proposal substructures.

IKE_INIT_SA response:

HDR(“A”, “B”), SAr1([proposal#1; = protocol ID:1; SPI size:0; …; <1 transforms chosen from each transform type = requested >]), KEr, Nr.

Proposal number 1 was chosen and one transform of each transform = type under that proposal is returned. No SPI field is present within the = proposal substructures.

Q1: Am I correct to believe that *always* in the response *only = one* chosen proposal is present i.e. the chosen proposal mentioning one = transforms of each transform type required?

> Yes.

Q2: In the case, that the responder chooses a proposal that had = the proposal number #3, will the Proposal number mentioned in the = responder’s SA payload be 3(i.e. mention the chosen proposal number) or mentions the proposal no. as #1 always (*because only one proposal can be = selected*).

> In your example, the = responder’s SA proposal number would be 3. It is used to help the = initiator

> figure out which of his = proposals was accepted.

IKE_AUTH =
request:

HDR, =
SK {IDi, [CERT,] [CERTREQ,] [IDr,],AUTH, =
SAi2([proposal#1; protocol ID:2 (for AH); SPI size:4; …,SPI value: =
“C”; <transforms>], [proposal #2; protocol ID:3 (for =
ESP); SPI size:4; …,SPI value: “D”; =
<transforms>]), TSi, TSr}

SPIs for the =
SAs are proposed in the SPI fields in the Proposal Substructure. The =
initiator chooses the SPI values of “C” and “D” =
for the two proposals.

Q3: Is it that =
the values chosen for “C” and “D” *must* be =
different always?

> No. I would expect that in most cases C and D would not =
be different.

> The purpose of this SPI is to allow the initiator to =
identify the SA in the

> processing of incoming ESP or AH packets, so if the =
initiator sets up

> multiple SAs to the same IP address it would need for =
the SPIs to be

> different. In expected implementations, a node would =
use different SPIs

> for each of its open SAs even to different IP =
addresses. The only time

> the initiator would put different SPIs in proposals for =
the same SA would

> be if it wanted to use different SPIs depending on =
which of the proposals

> the responder accepted.

Q4: In the case =
where we want to propose that both AH and ESP are to be used for the =
traffic stream, we mark both the proposals as #1. In this case will the =
SPI value mentioned in the proposal substructure be different for the =
two proposals even though the Proposal no. is 1 for both the =
substructure?

> Probably. When using both =
ESP and AH, the data packets have an ESP =
header

> encapsulated in the AH =
data, so there are two SPIs. I would expect these =
two

> SPIs would be different, =
though IKEv2 does not require that they be.

IKE_AUTH =
response:

HDR, =
SK {IDr, [CERT,] AUTH, SAr2([proposal#1; =
protocol ID:2 (for AH); SPI size:4; …,SPI value: “E”; =
<1 transforms chosen from each transform type requested>]), TSi, =
TSr}

Proposal no.1 =
was chosen, the SPI value associated by the responder is “E” =
for this SA chosen from the offered set of SAs. =

Q5: Am I =
correct to believe that the SPI value chosen by the responder for the =
chosen proposal is randomly chosen to be “E”. Can it also =
happen to choose the same value “C”? =

> The responder may choose =
E randomly or may choose it to index

> some table in the =
responder’s memory. E could be the same as =
C.

Q6: Am I =
correct to believe that the values chosen for this SA (here =
“C” on sender’s side and “E” on =
receiver’s side) are different and two distinct SA are existing in =
the two directions with *same* keys and *same* agreed upon set of =
algorithms?

> Almost. The specification =
is awkward because ESP and AH insist on =
considering

> the two directions of =
communication to be separate SAs, but the IKE SA =
is

> bidirectional. So IKEv2 always creates and deletes ESP =
and AH SAs in pairs,

> and I would expect implementations to treat them as a =
single entity, but the

> spec has to say that they are separate SAs. The =
algorithms must be the same

> in both directions, but the keys are different. The =
keys for both directions are

> derived from a common base key as specified in the =
spec.

Q7: To REKEY =
this SA, will the sender send a CREATE_CHILD_SA request mentioning the =
SPI value as “E”(its inbound value) in the ‘N’ =
payload and the if successful both of them delete the SA corresponding =
to “C” on sender’s side and “E” on =
responder’s side?

> Yes, except that technically it’s a pair of SAs =
being rekeyed, so your sentence

> should say “…deleted the SAs =
corresponding…”.

Q8: This CHILD =
created from the initial exchange may follow the protocol types of ESP, =
AH, both ESP & AH etc. But they can never support the option for a =
DH group transform type in the proposal since no KE payload can be sent =
along with the AUTH exchange messages.

So Perfect =
forward secrecy(PSF) cannot be supported in this child created through =
initial exchange?

> Perfect forward secrecy comes from forgetting the DH =
private key (and SK_d) no later

> than when the child SA is closed. To get PFS for the =
initial pair of child SAs, it is

> necessary to first rekey the IKE SA, forget the keying =
material associated with it,

> and then rekey the child SA. By design, PFS does not =
require an additional DH

> exchange, though it is allowed because some crypto =
people don’t believe it.

Q9: While =
“Rekeying” it is being said that the CHILD_SA creates an =
equivalent SA to the one to be replaced. Does it mean that in the SA =
payload we send the *only* the same proposal which is the *presently =
existing* suite for the SA?

> People have debated what the phrase means. What you =
describe is the normal case.

> Some people read the spec as saying that you =
can’t change cryptographic =
algorithms

> or traffic selectors, while others think you can. This =
may be clarified in a future

> revision of the spec. A conservative implementation =
would only propose the

> presently existing suite but would accept changes if =
requested from the other side

> (because then they would interoperate with =
anyone).

Q10: Am I =
correct to think that the outer header(HDR) in the CREATE_CHILD_SA has =
the SPIs corresponding to the parent IKE?

> Yes. All IKE messages have the SPIs corresponding to =
the outer IKE.

Q11: When we =
Rekey an existing IKE_SA, in the CREATE_CHILD_SA do we need to mark the =
protocol ID as 3 (corresponding to IKE protocol value)? If we are =
creating an IKE then there should be no SPI value field mentioned in the =
SA structure, but again it is said that “the new initiator and =
responder SPIs are supplied in the SPI fields in the Proposal structure =
in the SA payload”. I am getting confused here. Does it mean that =
the SA that is being created to rplace the parent IKE by using =
CREATE_CHILD_SA has to be AH or ESP and not an IKE protocol? =

> In the initial exchange setting up an IKE_SA, the =
proposals contain no SPIs

> because the SPIs implicitly are the values in the =
header of the messages

> negotiating the IKE_SA. When a new IKE_SA is created =
within a

> CREATE_CHILD_SA exchange, the eight byte SPIs are =
included in the

> SA payloads. The new SPIs will be used in messages that =
are cryptographically

> protected with the new keys (so an implementation can =
know which key to use

> by looking at the SPI).

I will be glad to have your response to my = doubts.

Thanking you in advance,

Soumya.

*********************************************************= *************************************************************************= ************************

This email message is for the sole use = of the intended recipient(s)and may contain CONFIDENTIAL and PRIVILEGED = information.
LG Soft India will not be responsible for any viruses or = defects or any forwarded attachments emanating either from within
LG = Soft India or outside. Any unauthorized review, use, disclosure or = distribution is prohibited. If you are not the intended
recipient, = please contact the sender By reply email and destroy all copies of the = original = message.

*********************************************************= *************************************************************************= ************************

------_=_NextPart_001_01C53A43.48DBCDE6-- --===============1043468027== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1043468027==-- From ipsec-bounces@ietf.org Wed Apr 6 05:36:51 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19586 for ; Wed, 6 Apr 2005 05:36:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ6wa-0005kt-Ov; Wed, 06 Apr 2005 05:35:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ6wZ-0005ko-4w for ipsec@megatron.ietf.org; Wed, 06 Apr 2005 05:35:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19503 for ; Wed, 6 Apr 2005 05:35:24 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ74t-0006fl-C7 for ipsec@ietf.org; Wed, 06 Apr 2005 05:44:03 -0400 Received: from [192.168.50.62] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j369ZDvF024519; Wed, 6 Apr 2005 05:35:15 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <015701c5371b$f3885510$4205010a@subha> References: <00e801c536f8$531e4850$4205010a@subha> <015701c5371b$f3885510$4205010a@subha> Date: Wed, 6 Apr 2005 04:44:52 -0400 To: "Subha" From: Stephen Kent Subject: Re: [Ipsec] Number of SPD Policies X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.8 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1807409259==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1807409259== Content-Type: multipart/alternative; boundary="============_-1099342371==_ma============" --============_-1099342371==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 4:35 PM -0800 4/1/05, Subha wrote: >Hi Steve, > >I have some follow-up questions. > >In the following questions I have assumed that 3 IPsec Protocols >shall be applied >on a given traffic stream. > >1) When IKEv2 is used with RFC2401 compliant implementation, can a >single IKEv2 >CREATE_CHILD_SA negotiate IPcomp, ESP and AH SAs for the given traffic >selector? yes, but as Tero noted, it would be a mistake, in general, to use IKEv2 with 2401. >2) When IKEv2 is used with RFC2401-bis compliant implementation, there has to >be theee IKEv2 CREATE_CHILD_SA Exchanges. > >(1) Plain Traffic selectors for IPcomp SA >(2) Same Source IP, Destination IP and IPComp for Protocol - >Traffic Selectors for ESP SA >(3) Tunnel Outer Header Source IP, Tunnel Outer Header Destination >IP and Protocol=ESP > for AH SA. yes, one needs to negotiate all three, if you did all three. Again, there seems to be very little motivation for using BOTH AH and ESP, vs. just using ESP with an appropriate integrity algorithm. > 3) An implementation needs to know through some other means, >whether the peer supports RFC2401 or 2401-bis. I would generally expect an implementation that supports IKEv2 to implement 2401-bis, given certain defaults adopted by IKEv2, e.g., ESN for AH or ESP. Steve --============_-1099342371==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Ipsec] Number of SPD Policies

At 4:35 PM -0800 4/1/05, Subha wrote:

Hi Steve,

I have some follow-up questions.

In the following questions I have assumed that 3 IPsec Protocols shall be applied

on a given traffic stream.

1) When IKEv2 is used with RFC2401 compliant implementation, can a single IKEv2

CREATE_CHILD_SA negotiate IPcomp, ESP and AH SAs for the given traffic

selector?

yes, but as Tero noted, it would be a mistake, in general, to use IKEv2 with 2401.

2) When IKEv2 is used with RFC2401-bis compliant implementation, there has to

be theee IKEv2 CREATE_CHILD_SA Exchanges.

(1) Plain Traffic selectors for IPcomp SA

(2) Same Source IP, Destination IP and IPComp for Protocol - Traffic Selectors for ESP SA

(3) Tunnel Outer Header Source IP, Tunnel Outer Header Destination IP and Protocol=ESP

for AH SA.

yes, one needs to negotiate all three, if you did all three. Again, there seems to be very little motivation for using BOTH AH and ESP, vs. just using ESP with an appropriate integrity algorithm.

3) An implementation needs to know through some other means,

whether the peer supports RFC2401 or 2401-bis.

I would generally expect an implementation that supports IKEv2 to implement 2401-bis, given certain defaults adopted by IKEv2, e.g., ESN for AH or ESP.

Steve

--============_-1099342371==_ma============-- --===============1807409259== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1807409259==-- From ipsec-bounces@ietf.org Wed Apr 6 08:42:43 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07130 for ; Wed, 6 Apr 2005 08:42:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ9nH-0000pT-S6; Wed, 06 Apr 2005 08:38:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ9nG-0000p7-98 for ipsec@megatron.ietf.org; Wed, 06 Apr 2005 08:38:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06712 for ; Wed, 6 Apr 2005 08:38:00 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ9va-000673-JS for ipsec@ietf.org; Wed, 06 Apr 2005 08:46:39 -0400 Received: from [192.168.50.62] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j36CblvF029790; Wed, 6 Apr 2005 08:37:49 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <5.1.0.14.0.20050405190205.02bb8b48@172.16.1.10> References: <5.1.0.14.0.20050405190205.02bb8b48@172.16.1.10> Date: Wed, 6 Apr 2005 08:25:35 -0400 To: Tatineni SriRama Kumar From: Stephen Kent Subject: Re: [Ipsec] Blocking traffic using opaque Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 7:08 PM +0530 4/5/05, Tatineni SriRama Kumar wrote: >Hi All, > As per point C and D in section 4.4.1.3 of 2401bis, traffic will >be passed in only one direction. Based on this I have following >questions. > >1. How configuration specified in point B of same section allows >traffic in both directions. Item B in 4.4.1.3 addresses the case where there is only 1 selector corresponding to the port field. Te use of OPAQUE here is just a convention for IKE negotiation re such protocols. This does not affect the S/D address aspect of SPD entry symmetry. So, an entry of the sort described in B enables bidirectional traffic flows for a protocol such as the Mobility Header, IF there are corresponding SPD entries at each end. >2. If configuration specified in points B,C and D allows traffic in >one direction only, what should be the configuration to allow >traffic in both directions. Items C + D in 4.4.1.3 explicitly are intended to NOT allow bidirectional traffic flow for a protocol that is NOT bidirectional, so your question is not meaningful in these cases. If you did not use the conventions described here, then bidirectional flows will be enabled, by default. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Apr 6 10:58:34 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20159 for ; Wed, 6 Apr 2005 10:58:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJBxu-0007kn-BG; Wed, 06 Apr 2005 10:57:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJBxs-0007kd-Rq for ipsec@megatron.ietf.org; Wed, 06 Apr 2005 10:57:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20013 for ; Wed, 6 Apr 2005 10:57:06 -0400 (EDT) Received: from thunk.org ([69.25.196.29] helo=thunker.thunk.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJC6D-0001sY-LZ for ipsec@ietf.org; Wed, 06 Apr 2005 11:05:47 -0400 Received: from root (helo=thunk.org) by thunker.thunk.org with local-esmtp (Exim 3.35 #1 (Debian)) id 1DJBxk-0005ql-00; Wed, 06 Apr 2005 10:57:00 -0400 Received: from tytso by thunk.org with local (Exim 4.50) id 1DJBxj-0005GM-Gb; Wed, 06 Apr 2005 10:56:59 -0400 Date: Wed, 6 Apr 2005 10:56:59 -0400 From: "Theodore Ts'o" To: Russ Housley Message-ID: <20050406145659.GA20093@thunk.org> References: <6.2.0.14.2.20050315100106.0624c8e0@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.0.14.2.20050315100106.0624c8e0@mail.binhost.com> User-Agent: Mutt/1.5.8i X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: ipsec@ietf.org, Charlie Kaufman , Barbara Fraser Subject: [Ipsec] Re: Results of straw poll regarding: IKEv2 interoperability issue X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Russ, My apologies for not getting back to you earlier. A combination of killer travel commitments, fairly nasty bouts of the flu (for both Barbara and myself, at different times), and the desire to touch base with all of the members of the ipsec wg management team slowed down my response. We agree that the relatively few number of people who responded to the straw poll was certainly not ideal. However, it is it is true the number of people who have been actively participating in the ipsec has been declining over time, and the people who responded were people who have had a history of participating in the ipsec working group. So we feel that we should consider the approach of changing IKEv2 to make transform type 5 (extended sequence number) working group consensus. As far as the technical aspect of the decision, the fact that many people at the interop meeting failed to achieve interoperability simply by reading the document troubles us, and trying to fix this in a clarification document that will be published separately, and later, seems to be simply asking for interoperability problems. Changing transform type 5 to be mandatory does not require a significant change to the document, nor to existing implementations that have already implemented extended sequence numbers. Furthermore, requiring implementations to support ESN does not appear to be overly burdensome. - Ted On Tue, Mar 15, 2005 at 10:13:27AM -0500, Russ Housley wrote: > Ted: > > The fact that so few people responded to the straw poll causes alarm. The > issue was raised at a bake-off, and some of the implementations represented > at the bake-off are not represented in the straw poll responses. > > I have a question: Do you believe that this response represents WG > consensus? If so, then please prepare an RFC Editor note that describes > the change that needs to be made, send it to me, and I will work with the > IESG to get it approved. If not, then we should not make any changes. > > The WG chairs must judge consensus. In this case, it is a subjective > decision, and you may want to consult with WG participants that did not > respond to the straw poll to figure it out. At least one person that was > at the bake-off has told me that they had come up with a way to achieve > interoperability without making changes. I think Paul Hoffman made a > posting to the mail list about that approach half way through the straw > poll. This is just one more dimension of your consensus decision. > > Russ > > > At 07:50 PM 3/14/2005, Theodore Ts'o wrote: > > >Two weeks ago, there was a discussion about an interoperability problem > >in IKEv2 that was turned up during interoperability testing. A week > >ago, I called for a straw poll; based on the fact that the number of > >responses was a little sparse, and last week was the Minneapolis IETF, I > >let the straw poll go on all last week. > > > >The straw poll indicated a majority (although certainly not unanimity) > >preference for proposal C: > > > > PROPOSAL C: > > ----------- > > > > Change the places that says Transform Type 5 is optional to say > > it is mandatory. > > > >This choice unfortunately would require making changes to the IKEv2 RFC > >before it is published, and since it has already been through the IESG > >approval process and almost through the entire RFC editor process, > >presumably we would need to make a new I-D and then take it through most > >of this process all over again --- although hopefully it would take much > >less time the second time around. > > > >Russ, would you comment if there is anything special we need to do at > >this point? Many thanks, > > > > - Ted > > > > > >Proposal A: > > Kevin Li > > Timothy Liu > > > >Proposal C: > > Srinivasa Rao Addepalli > > Geoffrey Huang > > Michael Roe > > Grubmair Peter > > Tero Kivinen > > Geoffrey Huang > > > >Proposal D: > > Paul Hoffman > > Pasi.Eronen@nokia.com > > Yoav Nir > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Apr 6 11:44:59 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28167 for ; Wed, 6 Apr 2005 11:44:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJCg1-0005AO-FI; Wed, 06 Apr 2005 11:42:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJCfz-00055l-9B for ipsec@megatron.ietf.org; Wed, 06 Apr 2005 11:42:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27863 for ; Wed, 6 Apr 2005 11:42:40 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DJCoM-0004Fr-Fx for ipsec@ietf.org; Wed, 06 Apr 2005 11:51:23 -0400 Received: (qmail 4120 invoked by uid 0); 6 Apr 2005 15:31:24 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.42.55) by woodstock.binhost.com with SMTP; 6 Apr 2005 15:31:24 -0000 Message-Id: <6.2.0.14.2.20050406112358.04690910@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 06 Apr 2005 11:31:13 -0400 To: "Theodore Ts'o" From: Russ Housley In-Reply-To: <20050406145659.GA20093@thunk.org> References: <6.2.0.14.2.20050315100106.0624c8e0@mail.binhost.com> <20050406145659.GA20093@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: ipsec@ietf.org, Charlie Kaufman , Barbara Fraser Subject: [Ipsec] Re: Results of straw poll regarding: IKEv2 interoperability issue X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Ted: I know about travel schedules, mine has been hectic too. I hope you and Barbara are well. As WG chair, the consensus call is yours to make. If the change is small, I suggest that we do it with an RFC Editor note. First, the content of the note needs to be approved by the WG and then by the IESG. However, we do need to hurry. ESP v3 is now in the RFC Editor queue, and 2401bis only has one open IESG issue. Once 2401bis gets to the RFC Editor queue, the updated document series will be complete. Russ At 10:56 AM 4/6/2005, Theodore Ts'o wrote: >Hi Russ, > >My apologies for not getting back to you earlier. A combination of >killer travel commitments, fairly nasty bouts of the flu (for both >Barbara and myself, at different times), and the desire to touch base >with all of the members of the ipsec wg management team slowed down my >response. > >We agree that the relatively few number of people who responded to the >straw poll was certainly not ideal. However, it is it is true the >number of people who have been actively participating in the ipsec has >been declining over time, and the people who responded were people who >have had a history of participating in the ipsec working group. So we >feel that we should consider the approach of changing IKEv2 to make >transform type 5 (extended sequence number) working group consensus. > >As far as the technical aspect of the decision, the fact that many >people at the interop meeting failed to achieve interoperability >simply by reading the document troubles us, and trying to fix this in >a clarification document that will be published separately, and later, >seems to be simply asking for interoperability problems. > >Changing transform type 5 to be mandatory does not require a >significant change to the document, nor to existing implementations >that have already implemented extended sequence numbers. Furthermore, >requiring implementations to support ESN does not appear to be overly >burdensome. > > - Ted > > >On Tue, Mar 15, 2005 at 10:13:27AM -0500, Russ Housley wrote: > > Ted: > > > > The fact that so few people responded to the straw poll causes alarm. The > > issue was raised at a bake-off, and some of the implementations > represented > > at the bake-off are not represented in the straw poll responses. > > > > I have a question: Do you believe that this response represents WG > > consensus? If so, then please prepare an RFC Editor note that describes > > the change that needs to be made, send it to me, and I will work with the > > IESG to get it approved. If not, then we should not make any changes. > > > > The WG chairs must judge consensus. In this case, it is a subjective > > decision, and you may want to consult with WG participants that did not > > respond to the straw poll to figure it out. At least one person that was > > at the bake-off has told me that they had come up with a way to achieve > > interoperability without making changes. I think Paul Hoffman made a > > posting to the mail list about that approach half way through the straw > > poll. This is just one more dimension of your consensus decision. > > > > Russ > > > > > > At 07:50 PM 3/14/2005, Theodore Ts'o wrote: > > > > >Two weeks ago, there was a discussion about an interoperability problem > > >in IKEv2 that was turned up during interoperability testing. A week > > >ago, I called for a straw poll; based on the fact that the number of > > >responses was a little sparse, and last week was the Minneapolis IETF, I > > >let the straw poll go on all last week. > > > > > >The straw poll indicated a majority (although certainly not unanimity) > > >preference for proposal C: > > > > > > PROPOSAL C: > > > ----------- > > > > > > Change the places that says Transform Type 5 is optional to say > > > it is mandatory. > > > > > >This choice unfortunately would require making changes to the IKEv2 RFC > > >before it is published, and since it has already been through the IESG > > >approval process and almost through the entire RFC editor process, > > >presumably we would need to make a new I-D and then take it through most > > >of this process all over again --- although hopefully it would take much > > >less time the second time around. > > > > > >Russ, would you comment if there is anything special we need to do at > > >this point? Many thanks, > > > > > > - Ted > > > > > > > > >Proposal A: > > > Kevin Li > > > Timothy Liu > > > > > >Proposal C: > > > Srinivasa Rao Addepalli > > > Geoffrey Huang > > > Michael Roe > > > Grubmair Peter > > > Tero Kivinen > > > Geoffrey Huang > > > > > >Proposal D: > > > Paul Hoffman > > > Pasi.Eronen@nokia.com > > > Yoav Nir > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Apr 6 13:10:11 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06322 for ; Wed, 6 Apr 2005 13:10:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJE1g-0005eB-Ju; Wed, 06 Apr 2005 13:09:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJE1e-0005Zu-RH for ipsec@megatron.ietf.org; Wed, 06 Apr 2005 13:09:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06199 for ; Wed, 6 Apr 2005 13:09:07 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJEA2-0006ar-2n for ipsec@ietf.org; Wed, 06 Apr 2005 13:17:51 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Apr 2005 10:09:00 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Wed, 6 Apr 2005 10:09:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] doubts about IKEv2 implementation Date: Wed, 6 Apr 2005 10:08:58 -0700 Message-ID: Thread-Topic: [Ipsec] doubts about IKEv2 implementation thread-index: AcU5257WT/ttHH7YRciiy/YnXZqKaQAJ1+SQAA/xiaAAIZlV8A== From: "Charlie Kaufman" To: "Charlie Kaufman" , X-OriginalArrivalTime: 06 Apr 2005 17:09:00.0613 (UTC) FILETIME=[53A6A750:01C53ACB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hilarie Orman pointed out to me that part of my posting was tantalizingly glib (my characterization, not hers). What I said was: > Perfect forward secrecy comes from forgetting the DH private key (and > SK_d) no later > than when the child SA is closed. To get PFS for the initial pair of > child SAs, it is necessary to first rekey the IKE SA, forget the keying > material associated with it, and then rekey the child SA. By design, > PFS does not require an additional DH exchange, though it is allowed > because some crypto people don't believe it. What I meant was that there is disagreement over the exact definition of perfect forward secrecy. IKEv2 key rollover meets some definitions even without additional D-H exchanges, but some people don't believe those definitions are sufficiently constraining. I define PFS as the property that once a session has ended neither endpoint holds any information that would be helpful in decrypting a recorded conversation. The process of rekeying an IKE SA generates new keying material by taking what is effectively a one way hash of the previous keying material (and the previous keying material cannot be derived from any long lived state), so by my definition that exchange provides PFS even without an additional D-H exchange. A tighter definition of PFS is that no information stored on either endpoint before a conversation begins is useful in decrypting a subsequent conversation except by means of a man-in-the-middle attack. The process of rekeying an IKE SA without D-H does not meet that bar. I claim that tighter constraint provides no practical additional security, but this would be a philosophical debate rather than a technical one. --Charlie _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Apr 6 16:51:00 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03081 for ; Wed, 6 Apr 2005 16:51:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJHPG-0002TI-Ey; Wed, 06 Apr 2005 16:45:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJHP8-0002T9-Ho for ipsec@megatron.ietf.org; Wed, 06 Apr 2005 16:45:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02612 for ; Wed, 6 Apr 2005 16:45:35 -0400 (EDT) Received: from fmr13.intel.com ([192.55.52.67] helo=fmsfmr001.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJHXX-0006LU-A8 for ipsec@ietf.org; Wed, 06 Apr 2005 16:54:20 -0400 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc, v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j36KjRxv022899 for ; Wed, 6 Apr 2005 20:45:27 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc, v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j36KjI2o026962 for ; Wed, 6 Apr 2005 20:45:27 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005040613302530271 for ; Wed, 06 Apr 2005 13:30:25 -0700 Received: from fmsmsx407.amr.corp.intel.com ([132.233.42.217]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Apr 2005 13:30:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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 Apr 2005 13:30:24 -0700 Message-ID: Thread-Topic: CCM: AAD construction Thread-Index: AcU653YNjZEox9K1QzSLw6pl2tD1FA== From: "Bansal, Yogesh" To: X-OriginalArrivalTime: 06 Apr 2005 20:30:25.0448 (UTC) FILETIME=[76C62280:01C53AE7] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Cc: "Raghunandan, Makaram" Subject: [Ipsec] CCM: AAD construction X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Group -=20 I have few questions on CCM & it's use in IPSec ESP mode. The questions are related to construction of AAD blocks required for authentication purposes. 1) Construction of AAD blocks in CCM in general RFC 3610 specifies construction of B_0, B_1 blocks=20 The construction of B_0 has been clearly defined. This block is followed by length encoding of "a" followed by "a" itself, as per the following paragraph in the spec: =20 Blocks encoding a are formed by concatenating this string that encodes l(a) with a itself, and splitting the result into 16-octet blocks, and then padding the last block with zeros if necessary. These blocks are appended to the first block B_0. Does this mean the following: B_1 =3D encoding(l(a)) || a || pad (to the next 16 octet block ) Hence, the AAD block stream then consists of=20 B_0 || B_1 || m_0 || m_1 ... || m_n (padding, if required)=20 [Q] Please confirm whether the interpretation of B_1 construction is correct.=20 2) Construction of AAD blocks in IPSec ESP mode=20 Does B_1 definition mean the following in IPSec ESP mode=20 AAD_IPSec =3D SPI || SEQ_Num B_1 =3D encoding (l (AAD_IPSec)) || AAD_IPsec || pad (to the next 16 octet block)=20 [Q] Please confirm construction of B_1 block in IPSec mode is correct. 3) Computing CBC-MAC in CCM Mode With IPsec ESP CCM spec (RFC 3610) implies that authentication is done on the plain text (and not the cipher text).=20 However, IPSec ESP mode states that encryption is done prior to authentication. Does this order change in the draft-ietf-ipsec-ciph-aes-ccm-05.txt, meaning that authentication is done after CTR-encryption? If so, is the CBC-MAC encrypted again.=20 My interpretation is that the order still remains the same as specified in RFC 3610, i.e. authentication is on plain text and not cipher text.=20 [Q] Please indicate what is the correct order of processing on the outbound side. Thanks for your time.=20 Regards, Yogesh=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Apr 6 18:50:49 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14362 for ; Wed, 6 Apr 2005 18:50:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJJK0-0001zO-53; Wed, 06 Apr 2005 18:48:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJJJy-0001xz-Bh for ipsec@megatron.ietf.org; Wed, 06 Apr 2005 18:48:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14165 for ; Wed, 6 Apr 2005 18:48:23 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=guri.intoto.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DJJSO-0000zT-Jw for ipsec@ietf.org; Wed, 06 Apr 2005 18:57:09 -0400 Received: from not-angel.intoto.com ([10.1.5.11]) by guri.intoto.com (SMSSMTP 4.0.0.59) with SMTP id M2005040615474601331 ; Wed, 06 Apr 2005 15:47:46 -0700 Received: from subha (dhcp-66.intoto.com [10.1.5.66]) (authenticated bits=0) by not-angel.intoto.com (8.13.1/8.13.1) with ESMTP id j36MmDRJ007681; Wed, 6 Apr 2005 15:48:18 -0700 Message-ID: <011501c53afa$b91fc830$4205010a@subha> From: "Subha" To: "Tero Kivinen" References: <00e801c536f8$531e4850$4205010a@subha><015701c5371b$f3885510$4205010a@subha><16977.11042.656521.73950@fireball.kivinen.iki.fi><003701c53952$0aabf430$4205010a@subha> <16978.22280.545861.239449@fireball.kivinen.iki.fi> Subject: Re: [Ipsec] Number of SPD Policies Date: Wed, 6 Apr 2005 15:48:12 -0700 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.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Stephen Kent X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi , If AH+ESP between the same two gateway devices is not actually providing any extra crypographic protection, why have it at all. 2401bis could have simply removed that combination. Also, my understanding is that having AH over ESP provides additional protection on the tunnel header, which is otherwise not handled by ESP with Auth. Thanks, Subha > Subha writes: >> It looks like 2401bis brings up a limitation that we cannot >> define different AH strength for ESP encrypted packets >> between the same two security gateways. > > Yes, I think you are right. > > The question is: Is there any reason to really do that? Why are you > doing AH+ESP between the local GW and Remote GW in any case, why are > you not simply using ESP with suitable auth algorithm? > > As you are using tunnel mode there AH does not offer anything more > compared to the ESP. > > The only case where I can see there would be use for AH+ESP is when > the AH and ESP are terminated by different hosts, i.e. AH goes to from > host to firewall, and the ESP goes from host through the firewall to > the other end host. > > As there EVER any valid scenario where you would need to use AH+ESP > where both of those are terminated by same peers? > -- > kivinen@safenet-inc.com > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Apr 7 04:06:44 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25181 for ; Thu, 7 Apr 2005 04:06:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJRxV-0006f3-JX; Thu, 07 Apr 2005 04:01:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJRxQ-0006dU-GJ for ipsec@megatron.ietf.org; Thu, 07 Apr 2005 04:01:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24818 for ; Thu, 7 Apr 2005 04:01:39 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJS5s-0007Zq-D4 for ipsec@ietf.org; Thu, 07 Apr 2005 04:10:29 -0400 Received: from [192.168.50.62] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j3781PvJ018178; Thu, 7 Apr 2005 04:01:29 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <011501c53afa$b91fc830$4205010a@subha> References: <00e801c536f8$531e4850$4205010a@subha><015701c5371b$f3885510$4205010a@subha><16977.11042.656521.73950@firebal l.kivinen.iki.fi><003701c53952$0aabf430$4205010a@subha> <16978.22280.545861.239449@fireball.kivinen.iki.fi> <011501c53afa$b91fc830$4205010a@subha> Date: Thu, 7 Apr 2005 03:58:22 -0400 To: "Subha" From: Stephen Kent Subject: Re: [Ipsec] Number of SPD Policies Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ipsec@ietf.org, Tero Kivinen X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 3:48 PM -0700 4/6/05, Subha wrote: >Hi , > >If AH+ESP between the same two gateway devices is not actually >providing any extra crypographic protection, >why have it at all. it is largely a holdover from the early days. Note that we do not mandate support for AH any more, so there is no mandate to support the combination of AH+ESP. >2401bis could have simply removed that combination. we DID remove mandatory support for this combination. > Also, my understanding is that having AH over ESP provides >additional protection on the tunnel header, which is otherwise >not handled by ESP with Auth. yes, it does provide protection for the tunnel header, but as we have discussed on this list in the past, this protection is only rarely of use. Remember, in most cases, the tunnel header is discarded upon arrival, so its integrity is is little importance in most cases. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Apr 7 04:14:00 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25921 for ; Thu, 7 Apr 2005 04:14:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJS00-0006z8-8t; Thu, 07 Apr 2005 04:04:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJRzb-0006uN-0n for ipsec@megatron.ietf.org; Thu, 07 Apr 2005 04:03:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24946 for ; Thu, 7 Apr 2005 04:03:56 -0400 (EDT) Received: from michael.checkpoint.com ([194.29.32.68] helo=michael2.checkpoint.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJS86-0007fq-Rm for ipsec@ietf.org; Thu, 07 Apr 2005 04:12:47 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael2.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id j3783Swx002345 for ; Thu, 7 Apr 2005 11:03:28 +0300 (IDT) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Yoav Nir Date: Thu, 7 Apr 2005 11:03:46 +0300 To: IPsec WG X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Subject: [Ipsec] Questions about internal address X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi. I've read sections 2.19 and 4, and I still have two questions about internal addressing: 1. The initiator may send a CFG_REQUEST during the AUTH exchange. There are several cases for the responder: (A) - the responder does not support CFG (B) - the responder supports CFG, but policy says that this user does not get it. (C) - the responder supports CFG, but not only for IPv4 addresses, and the client asked for IPv6 (or vice versa) (D) - the responder supports CFG, but its pool is exhausted (or the external server is down) If my understanding is correct, in case (A) the responder will not send a CFG_REPLY. It makes sense that in case (B) the responder will do the same. The question is about cases (C) and (D). I'm assuming that internal addresses are not mandatory. Is there a way to indicate the failure to the initiator so that the initiator can decide whether to tear down the connection? Would it be appropriate to send a CFG_REPLY with the internal address equal to zero as an indication of failure, or MUST the gateway simply not send a CFG_REPLY? 2. Section 4 refers to renewal before the ADDRESS_EXPIRY elapses. How is this renewal performed? MUST it be done with a CCSA exchange even if the SA is not expired? Can it be done in an informational exchange like the APPLICATION_VERSION query? Thanks, and maybe the answers should go in the clarifications draft. Yoav _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Apr 7 04:34:51 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27501 for ; Thu, 7 Apr 2005 04:34:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJSQw-0005Fg-0x; Thu, 07 Apr 2005 04:32:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJSQu-0005FF-0H for ipsec@megatron.ietf.org; Thu, 07 Apr 2005 04:32:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27301 for ; Thu, 7 Apr 2005 04:32:09 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJSZP-0000Hk-FC for ipsec@ietf.org; Thu, 07 Apr 2005 04:41:00 -0400 Received: from [192.168.50.62] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j378VwvF019124; Thu, 7 Apr 2005 04:32:00 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 7 Apr 2005 04:07:33 -0400 To: "Bansal, Yogesh" From: Stephen Kent Subject: Re: [Ipsec] CCM: AAD construction Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ipsec@ietf.org, "Raghunandan, Makaram" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 1:30 PM -0700 4/6/05, Bansal, Yogesh wrote: > > >However, IPSec ESP mode states that encryption is done prior to >authentication. Does this order change in the >draft-ietf-ipsec-ciph-aes-ccm-05.txt, meaning that authentication is >done after CTR-encryption? If so, is the CBC-MAC encrypted again. look at ESP v3. drafts of this document have been around for quite a while. it has just been approved by the IESG and is now in the RFC Editor's hands. It has an explicit discussion of how to process packets when a combined mode algorithm (confidentiality and integrity) is employed. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Apr 7 06:44:06 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06857 for ; Thu, 7 Apr 2005 06:44:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJURQ-0007Lj-Q8; Thu, 07 Apr 2005 06:40:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJURP-0007Lb-2D for ipsec@megatron.ietf.org; Thu, 07 Apr 2005 06:40:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06594 for ; Thu, 7 Apr 2005 06:40:47 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJUZv-0004Kn-8d for ipsec@ietf.org; Thu, 07 Apr 2005 06:49:40 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j37AehIu003027 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 7 Apr 2005 13:40:44 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j37AegX1003024; Thu, 7 Apr 2005 13:40:42 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16981.3625.976427.270687@fireball.kivinen.iki.fi> Date: Thu, 7 Apr 2005 13:40:41 +0300 From: Tero Kivinen To: Russ Housley Subject: [Ipsec] Re: Results of straw poll regarding: IKEv2 interoperability issue In-Reply-To: <6.2.0.14.2.20050406112358.04690910@mail.binhost.com> References: <6.2.0.14.2.20050315100106.0624c8e0@mail.binhost.com> <20050406145659.GA20093@thunk.org> <6.2.0.14.2.20050406112358.04690910@mail.binhost.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 6 min X-Total-Time: 5 min X-Spam-Score: 0.3 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Barbara Fraser , Charlie Kaufman , "Theodore Ts'o" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Russ Housley writes: > If the change is small, I suggest that we do it with an RFC Editor > note. First, the content of the note needs to be approved by the WG and The change would be (I include the whole tables so the formatting will be done correctly): ---------------------------------------------------------------------- In section 3.3.2 remove "optional in" from the ESN line, i.e. change Transform Type Values Transform Used In Type RESERVED 0 Encryption Algorithm (ENCR) 1 (IKE and ESP) Pseudo-random Function (PRF) 2 (IKE) Integrity Algorithm (INTEG) 3 (IKE, AH, optional in ESP) Diffie-Hellman Group (D-H) 4 (IKE, optional in AH & ESP) Extended Sequence Numbers (ESN) 5 (Optional in AH and ESP) RESERVED TO IANA 6-240 PRIVATE USE 241-255 to Transform Type Values Transform Used In Type RESERVED 0 Encryption Algorithm (ENCR) 1 (IKE and ESP) Pseudo-random Function (PRF) 2 (IKE) Integrity Algorithm (INTEG) 3 (IKE, AH, optional in ESP) Diffie-Hellman Group (D-H) 4 (IKE, optional in AH & ESP) Extended Sequence Numbers (ESN) 5 (AH and ESP) RESERVED TO IANA 6-240 PRIVATE USE 241-255 ---------------------------------------------------------------------- In section 3.3.2 remove last paragraph from the description of the Transform Type 5, i.e. change: For Transform Type 5 (Extended Sequence Numbers), defined Transform IDs are: Name Number No Extended Sequence Numbers 0 Extended Sequence Numbers 1 RESERVED 2 - 65535 If Transform Type 5 is not included in a proposal, use of Extended Sequence Numbers is assumed. to For Transform Type 5 (Extended Sequence Numbers), defined Transform IDs are: Name Number No Extended Sequence Numbers 0 Extended Sequence Numbers 1 RESERVED 2 - 65535 ---------------------------------------------------------------------- In section 3.3.3 move ESN to mandatory types of the ESN an AH, i.e. change: Protocol Mandatory Types Optional Types IKE ENCR, PRF, INTEG, D-H ESP ENCR INTEG, D-H, ESN AH INTEG D-H, ESN to Protocol Mandatory Types Optional Types IKE ENCR, PRF, INTEG, D-H ESP ENCR, ESN INTEG, D-H AH INTEG, ESN D-H -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Apr 7 06:54:26 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07549 for ; Thu, 7 Apr 2005 06:54:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJUdV-0002JL-4N; Thu, 07 Apr 2005 06:53:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJUdS-0002Ho-Mj for ipsec@megatron.ietf.org; Thu, 07 Apr 2005 06:53:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07504 for ; Thu, 7 Apr 2005 06:53:15 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJUm0-0004nm-06 for ipsec@ietf.org; Thu, 07 Apr 2005 07:02:08 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j37Ar8YX003101 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 7 Apr 2005 13:53:09 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j37Ar3T4003098; Thu, 7 Apr 2005 13:53:04 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16981.4367.870344.876190@fireball.kivinen.iki.fi> Date: Thu, 7 Apr 2005 13:53:03 +0300 From: Tero Kivinen To: "Subha" Subject: Re: [Ipsec] Number of SPD Policies In-Reply-To: <011501c53afa$b91fc830$4205010a@subha> References: <00e801c536f8$531e4850$4205010a@subha> <015701c5371b$f3885510$4205010a@subha> <16977.11042.656521.73950@fireball.kivinen.iki.fi> <003701c53952$0aabf430$4205010a@subha> <16978.22280.545861.239449@fireball.kivinen.iki.fi> <011501c53afa$b91fc830$4205010a@subha> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 10 min X-Total-Time: 9 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Stephen Kent X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Subha writes: > If AH+ESP between the same two gateway devices is not > actually providing any extra crypographic protection, > why have it at all. True. > 2401bis could have simply removed that combination. 2401bis did remove it as a single concept. The reason there is still the forwarding step is when you have following case: Host A <-------> SGW <-----> Host B and where Host A needs to authenticate all his packets with tunnel mode AH to the SGW before it can get through it (i.e. the Host A might be somewhere inside the internet, and the SGW is the corporate firewall, requiring authentication before letting any traffic in, but as all traffic is also protected by ESP end to end, AH is enough for the SGW). In addition to that Host A needs to create transport mode ESP to connect to the Host B (lets say financial server or something). Now the Host A do need to have both AH and ESP applied to the packet, and his policy would be: Host A, Host B, ESP or IKE use tunnel mode AH to SGW Host A, Host B, any traffic use transport mode ESP, reforward to IPsec > Also, my understanding is that having AH over ESP provides > additional protection on the tunnel header, which is otherwise > not handled by ESP with Auth. If the ESP is in tunnel mode the external header is thrown away, so the protection AH offers to it is not useful. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Apr 7 07:00:12 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07994 for ; Thu, 7 Apr 2005 07:00:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJUh7-0003GW-6J; Thu, 07 Apr 2005 06:57:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJUh0-0003Eh-Kl for ipsec@megatron.ietf.org; Thu, 07 Apr 2005 06:57:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07787 for ; Thu, 7 Apr 2005 06:56:55 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJUpX-0004s2-Us for ipsec@ietf.org; Thu, 07 Apr 2005 07:05:48 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j37Ausd7003129 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 7 Apr 2005 13:56:55 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j37AumEo003126; Thu, 7 Apr 2005 13:56:48 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16981.4592.603521.64579@fireball.kivinen.iki.fi> Date: Thu, 7 Apr 2005 13:56:48 +0300 From: Tero Kivinen To: pasi.eronen@nokia.com, paul.hoffman@vpnc.org, ipsec@ietf.org Subject: [Ipsec] Comments of draft-eronen-ipsec-ikev2-clarifications-02.txt In-Reply-To: <16978.33154.351915.320602@fireball.kivinen.iki.fi> References: <16978.33154.351915.320602@fireball.kivinen.iki.fi> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 2 min X-Total-Time: 2 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Tero Kivinen writes: > Also if we think more about the IKE SA rekeying, I do not think there > is any reason to do that unless you also do new Diffie-Hellman there > too. Rekeying IKE SA because of the IKE message ID wrapping is not > common. The current IKEv2 text is not clear wheather the intension was > that IKE SA rekey MUST have KE payloads, but I think we should mandate > them, i.e. say in the NEW-1.3.2 that KE payloads are not optional > there. Actually it is clear from the draft-ietf-ipsec-ikev2-17.txt that Diffie-Hellman parameter is NOT optional when rekeying IKE. The 3.3.3 lists D-H as mandatory type if the protocol is IKE, and the 3.3.2 does the same in the Transform Type Values table. So KE payloads are not optional in the NEW-1.3.2. ----------------------------------------------------------------------- 3.3.2 Transform Substructure ... Transform Type Values ... Diffie-Hellman Group (D-H) 4 (IKE, optional in AH & ESP) ... 3.3.3 Valid Transform Types by Protocol ... Protocol Mandatory Types Optional Types IKE ENCR, PRF, INTEG, D-H ... -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Apr 7 07:33:55 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10862 for ; Thu, 7 Apr 2005 07:33:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJVAI-0001O1-NV; Thu, 07 Apr 2005 07:27:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJVAI-0001Nw-0h for ipsec@megatron.ietf.org; Thu, 07 Apr 2005 07:27:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09927 for ; Thu, 7 Apr 2005 07:27:10 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJVIp-0005qn-Lx for ipsec@ietf.org; Thu, 07 Apr 2005 07:36:04 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j37BR7bY003422 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 7 Apr 2005 14:27:07 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j37BR7gC003419; Thu, 7 Apr 2005 14:27:07 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16981.6410.971961.170256@fireball.kivinen.iki.fi> Date: Thu, 7 Apr 2005 14:27:06 +0300 From: Tero Kivinen To: Yoav Nir Subject: [Ipsec] Questions about internal address In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 1 min X-Total-Time: 1 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: IPsec WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Yoav Nir writes: > 2. Section 4 refers to renewal before the ADDRESS_EXPIRY elapses. How And note also that ADDRESS_EXPIRY is optional to implement for the server, server can simply refuse to give them out, and client can simply not request it. Clients MUST understand if it replied to them, but that is all. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Apr 7 07:34:47 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11041 for ; Thu, 7 Apr 2005 07:34:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJV8k-00018d-CK; Thu, 07 Apr 2005 07:25:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJV8j-00018Y-Hz for ipsec@megatron.ietf.org; Thu, 07 Apr 2005 07:25:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09770 for ; Thu, 7 Apr 2005 07:25:34 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJVHH-0005oX-0Q for ipsec@ietf.org; Thu, 07 Apr 2005 07:34:27 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j37BPStA003406 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 7 Apr 2005 14:25:29 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j37BPR7p003403; Thu, 7 Apr 2005 14:25:27 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16981.6311.477874.783828@fireball.kivinen.iki.fi> Date: Thu, 7 Apr 2005 14:25:27 +0300 From: Tero Kivinen To: Yoav Nir Subject: [Ipsec] Questions about internal address In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 14 min X-Total-Time: 15 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: IPsec WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Yoav Nir writes: > 1. The initiator may send a CFG_REQUEST during the AUTH exchange. > There are several cases for the responder: > (A) - the responder does not support CFG > (B) - the responder supports CFG, but policy says that this user > does not get it. Yes, simply do not send CFG_REPLY at all. > (C) - the responder supports CFG, but not only for IPv4 addresses, > and the client asked for IPv6 (or vice versa) > (D) - the responder supports CFG, but its pool is exhausted (or the > external server is down) Send CFG_REPLY, with other parameters, but leave out the INTERNAL_IP{4,6}_ADDRESS parameters, as you do not have address for him. This is suitable if he asked both IPv4 and IPv6 and you only had one of those addresses. Then you probably also fail the IPsec SA exchange (if this was part of the IKE_AUTH) with INTERNAL_ADDRESS_FAILURE error, as you cannot narrow down the traffic selectors if you do not have address where to narrow. You could also fail the whoe CFG_REQUEST exchange with INTERNAL_ADDRESS_FAILURE. > 2. Section 4 refers to renewal before the ADDRESS_EXPIRY elapses. How > is this renewal performed? This whole thing is leftover from the IKEv1, and I think it SHOULD NOT be used at all. The address is valid as long as the IKE SA is valid, thus if server wants to free unused addresses, he can simply delete IKE SAs to free the addresses. In the IKEv2 all information related to the IKE SA goes away when it is deleted, and I see no reason why the paramters allocated with configuration payload would be exception to this. Renewals are only needed when the communication channel is not reliable, i.e. the server does not have a way to know if the client is still there and using the address. In IKEv2 we do know when the client disappears, so we can free the addresses at that point, at the same time we delete the IKE SA and IPsec SAs tied to it (using that address). > MUST it be done with a CCSA exchange even if the SA is not expired? CREATE_CHILD_SA exchange cannot have CP payloads, so it must be done as separate informational exchange. > Can it be done in an informational exchange like the > APPLICATION_VERSION query? > > Thanks, and maybe the answers should go in the clarifications draft. The whole configuration payload thing is quite badly defined as it is taken directly from the mode config of IKEv1, and nobody wanted to modify things from there. The problem is that IKEv2 and IKEv1 do have different ways of doing that, and for example that ADDRESS_EXPIRY should have been removed completely when the text was taken to IKEv2 draft etc. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Apr 7 09:11:11 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19692 for ; Thu, 7 Apr 2005 09:11:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJWkX-0003xi-QJ; Thu, 07 Apr 2005 09:08:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJWkU-0003vr-6T for ipsec@megatron.ietf.org; Thu, 07 Apr 2005 09:08:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19278 for ; Thu, 7 Apr 2005 09:08:39 -0400 (EDT) Received: from michael.checkpoint.com ([194.29.32.68] helo=michael2.checkpoint.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJWt0-0001ML-25 for ipsec@ietf.org; Thu, 07 Apr 2005 09:17:32 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael2.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id j37D89wx011564; Thu, 7 Apr 2005 16:08:09 +0300 (IDT) In-Reply-To: <16981.6311.477874.783828@fireball.kivinen.iki.fi> References: <16981.6311.477874.783828@fireball.kivinen.iki.fi> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0d4118737c07947571b7d301dac293f3@checkpoint.com> Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] Questions about internal address Date: Thu, 7 Apr 2005 16:08:26 +0300 To: Tero Kivinen X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: IPsec WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit On Apr 7, 2005, at 2:25 PM, Tero Kivinen wrote: >> (C) - the responder supports CFG, but not only for IPv4 addresses, >> and the client asked for IPv6 (or vice versa) >> (D) - the responder supports CFG, but its pool is exhausted (or >> the >> external server is down) > > Send CFG_REPLY, with other parameters, but leave out the > INTERNAL_IP{4,6}_ADDRESS parameters, as you do not have address for > him. This is suitable if he asked both IPv4 and IPv6 and you only had > one of those addresses. Then you probably also fail the IPsec SA > exchange (if this was part of the IKE_AUTH) with > INTERNAL_ADDRESS_FAILURE error, as you cannot narrow down the traffic > selectors if you do not have address where to narrow. > > You could also fail the whoe CFG_REQUEST exchange with > INTERNAL_ADDRESS_FAILURE. How can you ever avoid this, even with cases (A) and (B) ? Suppose the initiator sends message #3 as in section 2.19: CP(CFG_REQUEST)= INTERNAL_ADDRESS(0.0.0.0) INTERNAL_NETMASK(0.0.0.0) INTERNAL_DNS(0.0.0.0) TSi = (0, 0-65536,0.0.0.0-255.255.255.255) TSr = (0, 0-65536,0.0.0.0-255.255.255.255) If the responder is not configured to support CP it cannot narrow the selectors and will have to fail anyway. But it gets weirder still. In the description of the INTERNAL_ADDRESS_FAILURE notification it says this: INTERNAL_ADDRESS_FAILURE 36 Indicates an error assigning an internal address (i.e., INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS) during the processing of a Configuration Payload by a responder. If this error is generated within an IKE_AUTH exchange no CHILD_SA will be created. This says that no CHILD_SA is created, but it does not say that no IKE_SA is created. Does this mean that we have an exchange that creates an IKE_SA but not a CHILD_SA? If I understand this correctly, at this point the client is supposed to start a new CCSA exchange with its own IP address. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Apr 7 09:26:46 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21728 for ; Thu, 7 Apr 2005 09:26:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJWlZ-00049E-9p; Thu, 07 Apr 2005 09:09:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJWlX-000480-6G for ipsec@megatron.ietf.org; Thu, 07 Apr 2005 09:09:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19480 for ; Thu, 7 Apr 2005 09:09:45 -0400 (EDT) Received: from michael.checkpoint.com ([194.29.32.68] helo=michael2.checkpoint.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJWu4-0001TT-RR for ipsec@ietf.org; Thu, 07 Apr 2005 09:18:38 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael2.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id j37D9Hwx011977; Thu, 7 Apr 2005 16:09:17 +0300 (IDT) In-Reply-To: <16981.6410.971961.170256@fireball.kivinen.iki.fi> References: <16981.6410.971961.170256@fireball.kivinen.iki.fi> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <33f25effb8f689c83ffd238a35f90555@checkpoint.com> Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] Questions about internal address Date: Thu, 7 Apr 2005 16:09:35 +0300 To: Tero Kivinen X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: IPsec WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit I guess this parameter originated from expecting to have the IP addresses assigned by a DHCP server and not wanting the server to have to keep track of DHCP leases. On Apr 7, 2005, at 2:27 PM, Tero Kivinen wrote: > Yoav Nir writes: >> 2. Section 4 refers to renewal before the ADDRESS_EXPIRY elapses. How > > And note also that ADDRESS_EXPIRY is optional to implement for the > server, server can simply refuse to give them out, and client can > simply not request it. Clients MUST understand if it replied to them, > but that is all. > -- > kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Apr 7 09:43:13 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23184 for ; Thu, 7 Apr 2005 09:43:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJXDo-0006bw-FE; Thu, 07 Apr 2005 09:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJXDn-0006br-4E for ipsec@megatron.ietf.org; Thu, 07 Apr 2005 09:38:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22770 for ; Thu, 7 Apr 2005 09:38:56 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJXML-0002jX-KI for ipsec@ietf.org; Thu, 07 Apr 2005 09:47:50 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j37DclsY004734 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 7 Apr 2005 16:38:48 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j37Dcl6O004731; Thu, 7 Apr 2005 16:38:47 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16981.14311.761760.602438@fireball.kivinen.iki.fi> Date: Thu, 7 Apr 2005 16:38:47 +0300 From: Tero Kivinen To: Yoav Nir Subject: Re: [Ipsec] Questions about internal address In-Reply-To: <0d4118737c07947571b7d301dac293f3@checkpoint.com> References: <16981.6311.477874.783828@fireball.kivinen.iki.fi> <0d4118737c07947571b7d301dac293f3@checkpoint.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 7 min X-Total-Time: 6 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: IPsec WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Yoav Nir writes: > On Apr 7, 2005, at 2:25 PM, Tero Kivinen wrote: > > >> (C) - the responder supports CFG, but not only for IPv4 addresses, > >> and the client asked for IPv6 (or vice versa) > >> (D) - the responder supports CFG, but its pool is exhausted (or > >> the > >> external server is down) > > > > Send CFG_REPLY, with other parameters, but leave out the > > INTERNAL_IP{4,6}_ADDRESS parameters, as you do not have address for > > him. This is suitable if he asked both IPv4 and IPv6 and you only had > > one of those addresses. Then you probably also fail the IPsec SA > > exchange (if this was part of the IKE_AUTH) with > > INTERNAL_ADDRESS_FAILURE error, as you cannot narrow down the traffic > > selectors if you do not have address where to narrow. > > > > You could also fail the whoe CFG_REQUEST exchange with > > INTERNAL_ADDRESS_FAILURE. > > How can you ever avoid this, even with cases (A) and (B) ? In case the traffic selectors have something else than any to any, i.e. if the client already has a IP-address, but only tries to get additional IP-address allocated from the internal pool. But, yes I agree that in most cases you simply return INTERNAL_ADDRESS_FAILURE. > This says that no CHILD_SA is created, but it does not say that no > IKE_SA is created. Yes, that is right. If there is any problems with the IPsec SA if the IKE_AUTH, you still do create the IKE SA, but simply fail the IPsec SA with error code. This applies to the NO_PROSAL_CHOSEN, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, FAILED_CP_REQUIRED, and TS_UNACCEPTALBE. The idea is that we have all the information needed to create the IKE SA, and we have already done the Diffie-Hellman, signature verification etc, so it would be wasting resources to throw all that away, just because there was something wrong with the IPsec SA. If the initiator knows how to fix the situation (add CP, change traffic selectors, modify algorithms etc) he can do that and initiate CREATE_CHILD_SA to create new SAs. If he cannot do anything, he can simply delete the IKE SA if he does not wnat to have it. > Does this mean that we have an exchange that creates an IKE_SA but > not a CHILD_SA? Yes. > If I understand this correctly, at this point the client is supposed > to start a new CCSA exchange with its own IP address. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Apr 7 10:01:26 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25188 for ; Thu, 7 Apr 2005 10:01:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJXJK-0007A0-Pk; Thu, 07 Apr 2005 09:44:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJXJI-00079p-F5 for ipsec@megatron.ietf.org; Thu, 07 Apr 2005 09:44:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23296 for ; Thu, 7 Apr 2005 09:44:38 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJXRr-0002wc-2f for ipsec@ietf.org; Thu, 07 Apr 2005 09:53:31 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j37DiXTO004761 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 7 Apr 2005 16:44:33 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j37DiWiD004758; Thu, 7 Apr 2005 16:44:32 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16981.14656.859805.458166@fireball.kivinen.iki.fi> Date: Thu, 7 Apr 2005 16:44:32 +0300 From: Tero Kivinen To: Yoav Nir Subject: Re: [Ipsec] Questions about internal address In-Reply-To: <33f25effb8f689c83ffd238a35f90555@checkpoint.com> References: <16981.6410.971961.170256@fireball.kivinen.iki.fi> <33f25effb8f689c83ffd238a35f90555@checkpoint.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 3 min X-Total-Time: 5 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: IPsec WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Yoav Nir writes: > I guess this parameter originated from expecting to have the IP > addresses assigned by a DHCP server and not wanting the server to have > to keep track of DHCP leases. Hmm.... probably true, but the server still needs to keep track of the IP-addresses assigned to each client and so on, soaddding the lease time there does not cause that much more bookkeeping. But perhaps this current way is the best, server can simply leave it out if he allocates addresses from internal pool and send it if it is using DHCP server. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Apr 7 11:17:05 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03711 for ; Thu, 7 Apr 2005 11:17:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJYgt-00038K-Rl; Thu, 07 Apr 2005 11:13:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJYgr-00036E-Nb for ipsec@megatron.ietf.org; Thu, 07 Apr 2005 11:13:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03160 for ; Thu, 7 Apr 2005 11:13:02 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJYpR-0006cO-HQ for ipsec@ietf.org; Thu, 07 Apr 2005 11:21:57 -0400 Received: from [192.168.50.44] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j37FCqvF003727; Thu, 7 Apr 2005 11:12:55 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050318023302.85893.qmail@web52604.mail.yahoo.com> References: <20050318023302.85893.qmail@web52604.mail.yahoo.com> Date: Thu, 7 Apr 2005 11:12:59 -0400 To: Subha Venkataramanan From: Stephen Kent Subject: Re: [Ipsec] Next Layer Protocol (Ref: 2401-bis draft) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 2.0 (++) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 6:33 PM -0800 3/17/05, Subha Venkataramanan wrote: >Hi , > >I have a follow-up question. > >If an implementation understands says hop-to-hop, >routing, fragmentation and Destination Options, it >can parse these extension headers and look for the >next protocol information. When it parses each >extension header, it knows the length of bytes it >needs to skip to reach the next extension header. > >If there are any new extension headers and the >implemenation cannot interpret these extension >headers, it cannot process the packet. In which >case, it may choose to send an ICMP Error message. > >What additional help is given to the implementation, >by configuring the extension headers that it needs >to ignore while parsing the IPv6 header. this is a feature designed to help support IPsec, in the IPv6 context. after inbound processing, IPsec access controls are applied based on the SAD entry for the SA via which the traffic arrived. thus it is important to know what constitutes the "next layer protocol" to which these access controls are to be applied. The use of a list enables a receiver to accommodate new IPv6 headers in the future. The list is configured with default entries for the header types that are defined now and that make sense to skip. similarly, for outbound processing, this list indicates where to look to find the protocol that is used for outbound access control, SA selection. This is mostly an AH issue, because there is more flexibility in where AH can be placed relative to IPv6 headers, vs. ESP. >1) Does this kind of configuration in the >implementation advise the user, that it has >capabilities skip A,B,C extension headers ? that is a local implementation issue, not dictated by the standards, but I would expect this info to be viewable as part of the configuration data. >2) Does this kind of configuration mean, that if the >implementation comes across any other extension >headers which it can interpret but is not in the >configured list, it should drop the packet ? As soon as one encounters a header that is not on the list, then that header is the one that will be examined against the SAD entry. if there is an extension header present that is not on the skip list, and it is not the one you listed in the SPD (and now in the SAD entry for the SA), then the packet will be dropped. >3) Does this kind of configuration mean, that when the >user tries to add some extension header values, that >the implementation does not support, it can throw an >error indicating the same ? If you add a header not on the list, AND if the intent was to skip the header, then the packet will be dropped. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Apr 7 14:42:19 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25272 for ; Thu, 7 Apr 2005 14:42:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJbwA-0005p0-I7; Thu, 07 Apr 2005 14:41:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJbw8-0005ov-LX for ipsec@megatron.ietf.org; Thu, 07 Apr 2005 14:41:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25192 for ; Thu, 7 Apr 2005 14:41:02 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DJc4k-0006A7-AU for ipsec@ietf.org; Thu, 07 Apr 2005 14:49:58 -0400 Received: (qmail 12700 invoked by uid 0); 7 Apr 2005 18:40:11 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.14.68) by woodstock.binhost.com with SMTP; 7 Apr 2005 18:40:11 -0000 Message-Id: <6.2.0.14.2.20050407140202.05092490@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 07 Apr 2005 14:39:59 -0400 To: "Bansal, Yogesh" From: Russ Housley Subject: Re: [Ipsec] CCM: AAD construction In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: ipsec@ietf.org, makaram.raghunandan@intel.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Yogesh: >I have few questions on CCM & it's use in IPSec ESP mode. The questions >are related to construction of AAD blocks required for authentication >purposes. > >1) Construction of AAD blocks in CCM in general > >RFC 3610 specifies construction of B_0, B_1 blocks >The construction of B_0 has been clearly defined. This block is followed >by length encoding of "a" followed by "a" itself, as per the following >paragraph in the spec: > >Blocks encoding a are formed by concatenating this string that encodes >l(a) with a itself, and splitting the result into 16-octet blocks, and >then padding the last block with zeros if necessary. These blocks are >appended to the first block B_0. > >Does this mean the following: > >B_1 = encoding(l(a)) || a || pad (to the next 16 octet block ) > >Hence, the AAD block stream then consists of >B_0 || B_1 || m_0 || m_1 ... || m_n (padding, if required) > > >[Q] Please confirm whether the interpretation of B_1 construction is >correct. Sometimes. When 0 < l(a) < (2^16 - 2^8), then B0 includes l(a). In this case, B1 begins with a. >2) Construction of AAD blocks in IPSec ESP mode > >Does B_1 definition mean the following in IPSec ESP mode >AAD_IPSec = SPI || SEQ_Num > >B_1 = encoding (l (AAD_IPSec)) || AAD_IPsec || pad (to the next 16 >octet block) > >[Q] Please confirm construction of B_1 block in IPSec mode is correct. The answer to this is found in draft-ietf-ipsec-ciph-aes-ccm-05.txt, which is in the RFC Editor queue. Section 5 shows the two cases for AAD construction. In both cases, l(a) is less than (2^16 - 2^8), so l(a) is encoded as part of B0. Thus, B1 contains only the SPI and the sequence number. The two cases are the traditional sequence number, which is 32 bits, and the extended sequence number, which is 64 bits. In either case, the total length of the AAD is less than one block, and padding is needed. >3) Computing CBC-MAC in CCM Mode With IPsec ESP >CCM spec (RFC 3610) implies that authentication is done on the plain >text (and not the cipher text). > >However, IPSec ESP mode states that encryption is done prior to >authentication. Does this order change in the >draft-ietf-ipsec-ciph-aes-ccm-05.txt, meaning that authentication is >done after CTR-encryption? If so, is the CBC-MAC encrypted again. > >My interpretation is that the order still remains the same as specified >in RFC 3610, i.e. authentication is on plain text and not cipher text. > >[Q] Please indicate what is the correct order of processing on the >outbound side. Authentication is done first. Please make sure that you are following draft-ietf-ipsec-esp-v3-10.txt, which is also in the RFC Editor queue. This document includes support for authenticated encryption modes like CCM. This support is not available in ESP v2 (RFC 2406). Russ _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Apr 7 15:08:09 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28097 for ; Thu, 7 Apr 2005 15:08:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJcLD-0002Vx-Jr; Thu, 07 Apr 2005 15:06:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJcLB-0002Vn-I2 for ipsec@megatron.ietf.org; Thu, 07 Apr 2005 15:06:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27986 for ; Thu, 7 Apr 2005 15:06:55 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DJcTl-00073k-RW for ipsec@ietf.org; Thu, 07 Apr 2005 15:15:51 -0400 Received: (qmail 2987 invoked by uid 0); 7 Apr 2005 19:06:48 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.167.14) by woodstock.binhost.com with SMTP; 7 Apr 2005 19:06:48 -0000 Message-Id: <6.2.0.14.2.20050407150511.06108900@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 07 Apr 2005 15:06:49 -0400 To: Tero Kivinen From: Russ Housley Subject: Re: [Ipsec] Re: Results of straw poll regarding: IKEv2 interoperability issue In-Reply-To: <16981.3625.976427.270687@fireball.kivinen.iki.fi> References: <6.2.0.14.2.20050315100106.0624c8e0@mail.binhost.com> <20050406145659.GA20093@thunk.org> <6.2.0.14.2.20050406112358.04690910@mail.binhost.com> <16981.3625.976427.270687@fireball.kivinen.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: ipsec@ietf.org, Barbara Fraser , Charlie Kaufman