From kivinen@iki.fi Tue Sep 1 07:07:44 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B3B63A6E03 for ; Tue, 1 Sep 2009 07:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XO3-9k7jQaAT for ; Tue, 1 Sep 2009 07:07:43 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 8A25C3A6943 for ; Tue, 1 Sep 2009 07:07:41 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n81E7l1Y020603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Sep 2009 17:07:47 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n81E7jvo002569; Tue, 1 Sep 2009 17:07:45 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19101.10929.181733.7940@fireball.kivinen.iki.fi> Date: Tue, 1 Sep 2009 17:07:45 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 40 min X-Total-Time: 61 min Cc: "ipsec@ietf.org WG" Subject: [IPsec] Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 14:07:44 -0000 Yoav Nir writes: > Following is our suggested new text. Please let us know what you > think. Also, please take a look at the description of > "AUTHENTICATION_FAILED" in section 3.10.1. "response to an IKE_AUTH > message" means either an IKE_AUTH response to an IKE_AUTH request, or > an INFORMATIONAL request that describes an error in the IKE_AUTH > response. Do you think this phrasing is clear enough? Yes, altought I think most of the implementations do not bother sending INFORMATIONAL requests when IKE_AUTH response has errors. I think most implementations will then simply remove the IKE SA as failed without any further communications to the other end (I do not know any implementation sending that kind of INFORMATIONAL requests, but I expect that almost all implementations will act correctly if someone happen to send them (i.e. they will delete the IKE SA as failed and send empty reply back)). > All errors that occur in an IKE_AUTH exchange, causing the > authentication to fail for whatever reason (invalid shared secret, > unrecognized ID, untrusted certificate issuer, revoked or expired > certificate, etc.) MUST result in an AUTHENTICATION_FAILED > notification. This MUST there is too strong, especially for the "unrecognized ID" part. For example our implementation send AUTHENTICATION_FAILED return only if processing of AUTH Payload faiiled (i.e. signature check failed (for RSA/DSA), mac failed for shared keys authentication, or no valid public key / shared key found for the ID). In cases where the other end is unknown (i.e. ID is not configured to the policy) it will return NO_PROPOSAL_CHOSEN as it does not find valid policy to accept the other ends proposal when looking it based on the ID. So at least remove the "unrecognized ID" from the list, as it does not belong there, and change the "MUST" to "SHOULD" as specifying exactly one error code in such situations will make lots of implementations non-conforming. I know that people writing conformance tests are going to test this kind of things, and I have already several times explained them that the exact error codes returned by different implementations can differ depending what checks they do and in which order. > If the error occurred on the responder, the > notification MUST be returned in the protected response, and MUST be > the only payload in that response. Again the two MUSTs there will make some implementations non-conforming. We had discussion about this earlier, and in general it is good idea to send them encrypted and MACed, but as that was not required before this is real protocol change. For such I think it requires more explantion. Also I want to have warning here saying that even if it is encrypted and MACed, that does not mean it is authentic from the real recipient. It is coming from the recipient you talked to, but if there is man-in-the-middle he can also generate such messages, meaning the initiator should still continue trying with this peer (he can immediately delete the current IKE SA exchange, as it cannot succeed after this, but next try might get to the real end node instead of man-in-the-middle and succeed). > If the error occurs on the > initiator, the notification MUST be returned in a separate > INFORMATIONAL exchange, with no other payloads. This MUST there is way too strong, as there is no implementations I know that implements that. For example our implementation simply consides the IKE SA failed in such case and removes the IKE SA, and then when next triggering packet comes it will try again. I would say "MAY" would be correct in this case. > Note, however, that > messages that contain an unsupported critical payload, or that are > otherwise malformed, MUST be rejected in their entirety, and only > lead to an UNSUPPORTED_CRITICAL_PAYLOAD or INVALID_SYNTAX > Notification. The receiver MUST NOT verify the payloads related to > authentication in this case. This "MUST NOT" is again too strong, as in some implementations they might process payloads in order and depending how deep in which place, they might for example process AUTH payload before noticing that the SA payload of the IPsec SA is malformed in its transform substructure. This "MOST NOT" would make such implementations non-conforming, meaning every single implementation must do full parsing of the payloads first and only after that do second phase when it processes the payloads. > If authentication has succeeded in the IKE_AUTH exchange, the IKE SA > is established, provided that there are no unsupported critical > payloads. The "provide that there are no unsupported critical payloads" is not really needed, as the first part asked to check those first, thus authentication cannot succeed (it is not even tried) if there is unsupported critical payload. Even if we allow parsing AUTH payloads before checking all critical bits, then I do not think that text is needed, it just confuses people. This next text should be in its own paragraph as it is not related to the authentication failures: > Establishing the child SA, or requesting configuration > information may still fail, but they do not automatically cause the > IKE SA to be deleted. Specifically, a responder may include all the > payloads associated with authentication (IDr, Cert and AUTH) while > sending error notifications for the piggybacked exchanges > (FAILED_CP_REQUIRED, INVALID_SELECTORS, NO_PROPOSAL_CHOSEN, etc.), > and the initiator MUST NOT fail the authentication because of this. > The initiator MAY, of course, for reasons of policy later delete > such > an IKE SA. > > Only authentication failures and malformed packets lead to a > deletion > of the IKE SA without requiring an explicit DELETE payload. Other > error conditions require such a payload. It would be better to talk about "INFORMATIONAL exchange having DELETE payload for IKE SA" instead of "DELETE payload", as that is the common way of doing things. Otherwise some implementation might start adding DELETE payloads to other requests / replies too, and I don't expect all imlementations to act on them in all cases. Currently we do not have any limitiations where DELETE payload can be, but I would expect most implemenations would ignore it if it is sent inside the response packet of the CREATE_CHILD_SA exchange. Even if we do not forbid DELETE payloads in other places, we can use examples and language that indicate the "normal" place for it. This following covering IKE_SA_INIT should again be in separate paragraph: > In an IKE_SA_INIT > exchange, > any error notification causes the exchange to fail. Not completely true. Even when the exchange fails the creation of the IKE SA might still continue, for example in cases where INVALID_MAJOR_VERSION (the initiator can fall back to IKEv1), INVALID_KE_PAYLOAD (the initiator can change to correct group), or COOKIE (the initiator tries again with COOKIE payload included (COOKIE is not really error notification)). Currently exchange is defined so that this statement is true as in those cases we start new exchange with same peer. > In an IKE_AUTH > exchange, or in the subsequent INFORMATIONAL exchnage, only the > following notifications cause the IKE SA to be deleted or not > created, without a DELETE payload: > o UNSUPPORTED_CRITICAL_PAYLOAD > o INVALID_SYNTAX > o AUTHENTICATION_FAILED > > Extension documents may define new error notifications with these > semantics, but MUST NOT use them unless the peer is known to > understand them. In subsequent INFORMATIONAL exchanges the UNSUPPORTED_CRITICAL_PAYLOAD should not be fatal. It only means that the responder ignored the whole message and replied with UNSUPPORTED_CRITICAL_PAYLOAD. That does not delete IKE SA. For the IKE_AUTH the UNSUPPORTED_CRITICAL_PAYLOAD can delete the IKE SA as IKE SA is not yet ready. -- kivinen@iki.fi From ynir@checkpoint.com Tue Sep 1 07:51:10 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 068DF28C76A for ; Tue, 1 Sep 2009 07:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.037 X-Spam-Level: X-Spam-Status: No, score=-3.037 tagged_above=-999 required=5 tests=[AWL=0.562, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KhSjw1rvUzH for ; Tue, 1 Sep 2009 07:51:08 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 51D3F28C771 for ; Tue, 1 Sep 2009 07:51:08 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n81EoS3d004039; Tue, 1 Sep 2009 17:50:29 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 1 Sep 2009 17:50:26 +0300 From: Yoav Nir To: Tero Kivinen Date: Tue, 1 Sep 2009 17:50:27 +0300 Thread-Topic: [IPsec] Issue #26: Missing treatment of error cases Thread-Index: AcorE4qR8gYj9ir5SvucFFkD1luO1g== Message-ID: References: <19101.10929.181733.7940@fireball.kivinen.iki.fi> In-Reply-To: <19101.10929.181733.7940@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 14:51:10 -0000 On Sep 1, 2009, at 5:07 PM, Tero Kivinen wrote: > Yoav Nir writes: >> Following is our suggested new text. Please let us know what you >> think. Also, please take a look at the description of >> "AUTHENTICATION_FAILED" in section 3.10.1. "response to an IKE_AUTH >> message" means either an IKE_AUTH response to an IKE_AUTH request, or >> an INFORMATIONAL request that describes an error in the IKE_AUTH >> response. Do you think this phrasing is clear enough? > > Yes, altought I think most of the implementations do not bother > sending INFORMATIONAL requests when IKE_AUTH response has errors. I > think most implementations will then simply remove the IKE SA as > failed without any further communications to the other end But wouldn't this cause a state de-synchronization? If the responder =20 sends a revoked certificate, the initiator will have no IKE SA, but =20 the responder would have an IKE SA, which it thinks is valid. Wouldn't =20 this necessarily later lead to requests that time out? > (I do not > know any implementation sending that kind of INFORMATIONAL requests, > but I expect that almost all implementations will act correctly if > someone happen to send them (i.e. they will delete the IKE SA as > failed and send empty reply back)). > >> All errors that occur in an IKE_AUTH exchange, causing the >> authentication to fail for whatever reason (invalid shared secret, >> unrecognized ID, untrusted certificate issuer, revoked or expired >> certificate, etc.) MUST result in an AUTHENTICATION_FAILED >> notification. > > This MUST there is too strong, especially for the "unrecognized ID" > part. For example our implementation send AUTHENTICATION_FAILED return > only if processing of AUTH Payload faiiled (i.e. signature check > failed (for RSA/DSA), mac failed for shared keys authentication, or no > valid public key / shared key found for the ID). > > In cases where the other end is unknown (i.e. ID is not configured to > the policy) it will return NO_PROPOSAL_CHOSEN as it does not find > valid policy to accept the other ends proposal when looking it based > on the ID. That allows for ID enumeration. It's similar to a password entry form, =20 that says "wrong user" or "wrong password". An attacker would be able =20 to verify whether a particular ID (say, user name) exists on a system. > So at least remove the "unrecognized ID" from the list, as it does not > belong there, and change the "MUST" to "SHOULD" as specifying exactly > one error code in such situations will make lots of implementations > non-conforming. I know that people writing conformance tests are going > to test this kind of things, and I have already several times > explained them that the exact error codes returned by different > implementations can differ depending what checks they do and in which > order. > >> If the error occurred on the responder, the >> notification MUST be returned in the protected response, and =20 >> MUST be >> the only payload in that response. > > Again the two MUSTs there will make some implementations > non-conforming. We had discussion about this earlier, and in general > it is good idea to send them encrypted and MACed, but as that was not > required before this is real protocol change. For such I think it > requires more explantion. Also I want to have warning here saying that > even if it is encrypted and MACed, that does not mean it is authentic > from the real recipient. It is coming from the recipient you talked > to, but if there is man-in-the-middle he can also generate such > messages, meaning the initiator should still continue trying with this > peer (he can immediately delete the current IKE SA exchange, as it > cannot succeed after this, but next try might get to the real end node > instead of man-in-the-middle and succeed). Agree. Will fix tomorrow or Thursday. >> If the error occurs on the >> initiator, the notification MUST be returned in a separate >> INFORMATIONAL exchange, with no other payloads. > > This MUST there is way too strong, as there is no implementations I > know that implements that. For example our implementation simply > considers the IKE SA failed in such case and removes the IKE SA, and > then when next triggering packet comes it will try again. > > I would say "MAY" would be correct in this case. OK. >> Note, however, that >> messages that contain an unsupported critical payload, or that are >> otherwise malformed, MUST be rejected in their entirety, and only >> lead to an UNSUPPORTED_CRITICAL_PAYLOAD or INVALID_SYNTAX >> Notification. The receiver MUST NOT verify the payloads related =20 >> to >> authentication in this case. > > This "MUST NOT" is again too strong, as in some implementations they > might process payloads in order and depending how deep in which place, > they might for example process AUTH payload before noticing that the > SA payload of the IPsec SA is malformed in its transform substructure. > > This "MOST NOT" would make such implementations non-conforming, > meaning every single implementation must do full parsing of the > payloads first and only after that do second phase when it processes > the payloads. How about if we limit this to packets that are malformed in their =20 entirety, rather than some particular payload (and packets that have =20 unrecognized critical payloads) ? >> If authentication has succeeded in the IKE_AUTH exchange, the =20 >> IKE SA >> is established, provided that there are no unsupported critical >> payloads. > > The "provide that there are no unsupported critical payloads" is > not really needed, as the first part asked to check those first, thus > authentication cannot succeed (it is not even tried) if there is > unsupported critical payload. Even if we allow parsing AUTH payloads > before checking all critical bits, then I do not think that text is > needed, it just confuses people. OK > This next text should be in its own paragraph as it is not related to > the authentication failures: > >> Establishing the child SA, or requesting configuration >> information may still fail, but they do not automatically cause =20 >> the >> IKE SA to be deleted. Specifically, a responder may include all =20 >> the >> payloads associated with authentication (IDr, Cert and AUTH) while >> sending error notifications for the piggybacked exchanges >> (FAILED_CP_REQUIRED, INVALID_SELECTORS, NO_PROPOSAL_CHOSEN, etc.), >> and the initiator MUST NOT fail the authentication because of =20 >> this. >> The initiator MAY, of course, for reasons of policy later delete >> such >> an IKE SA. >> >> Only authentication failures and malformed packets lead to a >> deletion >> of the IKE SA without requiring an explicit DELETE payload. Other >> error conditions require such a payload. > > It would be better to talk about "INFORMATIONAL exchange having DELETE > payload for IKE SA" instead of "DELETE payload", as that is the common > way of doing things. Otherwise some implementation might start adding > DELETE payloads to other requests / replies too, and I don't expect > all imlementations to act on them in all cases. > > Currently we do not have any limitiations where DELETE payload can be, > but I would expect most implemenations would ignore it if it is sent > inside the response packet of the CREATE_CHILD_SA exchange. > > Even if we do not forbid DELETE payloads in other places, we can use > examples and language that indicate the "normal" place for it. OK > This following covering IKE_SA_INIT should again be in separate > paragraph: > >> In an IKE_SA_INIT >> exchange, >> any error notification causes the exchange to fail. > > Not completely true. Even when the exchange fails the creation of the > IKE SA might still continue, for example in cases where > INVALID_MAJOR_VERSION (the initiator can fall back to IKEv1), > INVALID_KE_PAYLOAD (the initiator can change to correct group), or > COOKIE (the initiator tries again with COOKIE payload included (COOKIE > is not really error notification)). > > Currently exchange is defined so that this statement is true as in > those cases we start new exchange with same peer. > >> In an IKE_AUTH >> exchange, or in the subsequent INFORMATIONAL exchnage, only the >> following notifications cause the IKE SA to be deleted or not >> created, without a DELETE payload: >> o UNSUPPORTED_CRITICAL_PAYLOAD >> o INVALID_SYNTAX >> o AUTHENTICATION_FAILED >> >> Extension documents may define new error notifications with these >> semantics, but MUST NOT use them unless the peer is known to >> understand them. > > In subsequent INFORMATIONAL exchanges the UNSUPPORTED_CRITICAL_PAYLOAD > should not be fatal. It only means that the responder ignored the > whole message and replied with UNSUPPORTED_CRITICAL_PAYLOAD. That does > not delete IKE SA. > > For the IKE_AUTH the UNSUPPORTED_CRITICAL_PAYLOAD can delete the IKE > SA as IKE SA is not yet ready. That's what I meant. I will clarify this. > --=20 > kivinen@iki.fi From piyomaru3141@gmail.com Tue Sep 1 01:24:04 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FB3A3A6F5B for ; Tue, 1 Sep 2009 01:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMt29mt8PXQ4 for ; Tue, 1 Sep 2009 01:24:03 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by core3.amsl.com (Postfix) with ESMTP id B72063A67D2 for ; Tue, 1 Sep 2009 01:24:03 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c5so1703961anc.4 for ; Tue, 01 Sep 2009 01:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=OWFG0IG8rcuEIaFc4v1Ic4f3/sJM1OUOuAOompRBzzY=; b=jtiEDrXpZ5DnPVsFR2uNrLVdjpcXsoC75l4crB8lPxNu2ZiIWkO55tKzF1TgtiG3Y5 bJ62y4eDIIHazeXYUEllbhs9dWT06NlIUf/cnacGHtNwagFC3ml+28kzhe0JSiXenzy5 EOQxE+iHvVVfEGN2OjZgyIaC4sdZHvPny924E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=PvpJpb+UpH3xoJgRHIQTQgwh8K0qHdLYTFqYbot4LAjirj447T04lEmkyxJmt0GrNc +RZxeS8xj5Y+vHjzYvc1RCGzb7y8IGgFoH5rNBG9ospgQakJaIFnJ+jIfsLoWCRXp8Sz 38ODrKSkLdLqBJPnxmp7rQaHjQKwO3eH5G28o= MIME-Version: 1.0 Received: by 10.101.59.5 with SMTP id m5mr7128745ank.67.1251793454053; Tue, 01 Sep 2009 01:24:14 -0700 (PDT) Date: Tue, 1 Sep 2009 17:24:14 +0900 Message-ID: From: naoyoshi ueda To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Tue, 01 Sep 2009 08:11:48 -0700 Subject: [IPsec] Questions to IKEv2bis draft: IVs of retransmitted packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 08:27:29 -0000 Hi All, I have a question about IVs of retransmitted packets. According to ikev2bis-04 section 2.1: > A retransmission from the initiator > MUST be bitwise identical to the original request. That is, > everything starting from the IKE Header (the IKE SA Initiator's SPI > onwards) must be bitwise identical; items before it (such as the IP > and UDP headers, and the zero non-ESP marker) do not have to be > identical. So, IV of retransmitted request must be the same as that of original request. Meanwhile, ikev2bis-04 section 3.14 says > o Initialization Vector - For CBC mode ciphers, the length of the > initialization vector (IV) is equal to the block length of the > underlying encryption algorithm. Senders MUST select a new > unpredictable IV for every message; recipients MUST accept any > value. Question 1: Does the statement "recipients MUST accept any value." stay true even if retransmitted IV differs from that of original request? Question 2: If the answer to Question 1 is no, what should the recipient do? Just ignore it? Abandon the IKE_SA? Or send some Notify? Question 3: How about IV of retransmitted RESPONSE? Does it need to be identical to the original one too? It seems to me that the following statement in section 2.1 implicitly requires that. But I'm not sure. Actually, I'm now involved in a IKEv2 implementation that sends retransmitted response with different IV from original one and I cannot tell if the behavior is allowed or not. ikev2bis-04 section 2.1: > The responder MUST remember each > response until it receives a request whose sequence number is larger > than or equal to the sequence number in the response plus its window > size (see Section 2.3). Thanks in advance, Naoyoshi Ueda From root@core3.amsl.com Tue Sep 1 09:00:02 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0A34B3A7003; Tue, 1 Sep 2009 09:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090901160002.0A34B3A7003@core3.amsl.com> Date: Tue, 1 Sep 2009 09:00:02 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-traffic-visibility-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 16:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Wrapped ESP for Traffic Visibility Author(s) : K. Grewal, et al. Filename : draft-ietf-ipsecme-traffic-visibility-08.txt Pages : 15 Date : 2009-09-01 This document describes the Wrapped Encapsulating Security Payload (WESP) protocol, which builds on top of Encapsulating Security Payload (ESP) [RFC4303] and is designed to allow intermediate devices to ascertain if ESP-NULL [RFC2410] is being employed and hence inspect the IPsec packets for network monitoring and access control functions. Currently in the IPsec standard, there is no way to differentiate between ESP encryption and ESP NULL encryption by simply examining a packet. This poses certain challenges to the intermediate devices that need to deep inspect the packet before making a decision on what should be done with that packet (Inspect and/or Allow/Drop). The mechanism described in this document can be used to easily disambiguate ESP-NULL from ESP encrypted packets, without compromising on the security provided by ESP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-traffic-visibility-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-traffic-visibility-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-01084622.I-D@ietf.org> --NextPart-- From yaronf@checkpoint.com Tue Sep 1 09:19:45 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B8333A7025 for ; Tue, 1 Sep 2009 09:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.308 X-Spam-Level: X-Spam-Status: No, score=-2.308 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCGzKVQ8PESc for ; Tue, 1 Sep 2009 09:19:43 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 83D373A702B for ; Tue, 1 Sep 2009 09:16:47 -0700 (PDT) X-CheckPoint: {4A9D4893-3-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 00E2729C005; Tue, 1 Sep 2009 19:16:59 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id D4FAA29C002 for ; Tue, 1 Sep 2009 19:16:59 +0300 (IDT) X-CheckPoint: {4A9D4893-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n81GGw3f027891 for ; Tue, 1 Sep 2009 19:16:59 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 1 Sep 2009 19:15:52 +0300 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Tue, 1 Sep 2009 19:15:54 +0300 Thread-Topic: PROTO write up for draft-ietf-ipsecme-traffic-visibility-08 Thread-Index: AcorH3rPOLYsyYgvQMm7wb4qtQxlug== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190A978EE2C@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_022C_01CA2B38.A036F680" MIME-Version: 1.0 Subject: [IPsec] PROTO write up for draft-ietf-ipsecme-traffic-visibility-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 16:19:45 -0000 ------=_NextPart_000_022C_01CA2B38.A036F680 Content-Type: multipart/alternative; boundary="----=_NextPart_001_022D_01CA2B38.A036F680" ------=_NextPart_001_022D_01CA2B38.A036F680 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I believe the draft is ready for AD review now. Below is my shepherd write-up, for your comments. Thanks, Yaron Document name: Wrapped ESP for Traffic Visibility, draft-ietf-ipsecme-traffic-visibility-08.txt (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The document shepherd is Yaron Sheffer, co-chair of the ipsecme WG. I have reviewed it and believe it is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has had in-depth review within the ipsecme WG. I am not aware of any non-WG reviews. I do not have any concerns about these reviews. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No concerns, the document lies fully within the ipsecme WG's area of expertise. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. I have no such concerns. There have been no IPR disclosures. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is wide WG consensus. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No, there were no such conflicts. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes, I have personally verified that. No formal review criteria are applicable. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. No issues identified. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The document defines a new IP Protocol Number. In addition, it defines a new IKEv2 notification, and one new IANA registry. There are no issues with any of them. I expect the Responsible AD to request the existing IKE/IPsec IANA expert to extend his services to the current draft. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? There are no such sections. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document describes the Wrapped Encapsulating Security Payload (WESP) protocol, which is based on the Encapsulating Security Payload (ESP) protocol and is designed to allow intermediate devices to ascertain if ESP with null encryption is being employed and if so, inspect the IPsec packets for network monitoring and access control functions. The mechanism described in this document can be used to easily disambiguate ESP-NULL from encrypted ESP packets, without compromising on the security provided by ESP. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Early on there was prolonged WG discussion about the relative merits of the Wrapped ESP solution for identifying ESP-null traffic, compared to heuristic methods for traffic inspection. Eventually the WG reached consensus on the usefulness of having both solutions published, with the heuristics solution targeted for the interim period until WESP is widely deployed. This consensus is documented in both protocol documents. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? We are not aware of any implementations. Neither do we know of any concrete vendor plans to implement this specification. (end) ------=_NextPart_001_022D_01CA2B38.A036F680 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I believe the draft is ready for AD review now. Below = is my shepherd write-up, for your comments.

 

Thanks,

         =    Yaron

 

 

Document name: Wrapped ESP for Traffic Visibility, = draft-ietf-ipsecme-traffic-visibility-08.txt

=

 

    (1.a) Who is the Document Shepherd = for this document? Has the

         = Document Shepherd personally reviewed this version of the

         = document and, in particular, does he or she believe this

         = version is ready for forwarding to the IESG for publication?

 

The document shepherd is Yaron Sheffer, co-chair of the ipsecme WG. I have reviewed = it and believe it is ready for publication.

 

    (1.b) Has the document had = adequate review both from key WG members

         = and from key non-WG members? Does the Document Shepherd have

         = any concerns about the depth or breadth of the reviews that

         = have been performed?

 

The document has had in-depth review within the = ipsecme WG. I am not aware of any non-WG reviews. I do not have any concerns about = these reviews.

 

    (1.c) Does the Document Shepherd = have concerns that the document

         = needs more review from a particular or broader perspective,

         = e.g., security, operational complexity, someone familiar with

         = AAA, internationalization or XML?

 

No concerns, the document lies fully within the = ipsecme WG's area of expertise.

 

    (1.d) Does the Document Shepherd = have any specific concerns or

         = issues with this document that the Responsible Area Director

         = and/or the IESG should be aware of? For example, perhaps he

         = or she is uncomfortable with certain parts of the document, or

  =         has concerns whether = there really is a need for it. In any

         = event, if the WG has discussed those issues and has indicated

         = that it still wishes to advance the document, detail those

         = concerns here. Has an IPR disclosure related to this document

         = been filed? If so, please include a reference to the

         = disclosure and summarize the WG discussion and conclusion on

         = this issue.

 

I have no such concerns. There have been no IPR = disclosures.

 

    (1.e) How solid is the WG = consensus behind this document? Does it

         = represent the strong concurrence of a few individuals, with

         = others being silent, or does the WG as a whole understand and

         = agree with it?

 

There is wide WG = consensus.

 

    (1.f) Has anyone threatened an = appeal or otherwise indicated extreme

         = discontent? If so, please summarise the areas of conflict in

         = separate email messages to the Responsible Area Director. (It

         = should be in a separate email because this questionnaire is

         = entered into the ID Tracker.)

 

No, there were no such = conflicts.

 

    (1.g) Has the Document Shepherd = personally verified that the

         = document satisfies all ID nits? (See

         = http://www.ietf.org/ID-Checklist.html and

         = http://tools.ietf.org/tools/idnits/). Boilerplate checks are

         = not enough; this check needs to be thorough. Has the document

         = met all formal review criteria it needs to, such as the MIB

         = Doctor, media type and URI type reviews?

 

Yes, I have personally verified that. No formal = review criteria are applicable.

 

    (1.h) Has the document split its = references into normative and

         = informative? Are there normative references to documents that

         = are not ready for advancement or are otherwise in an unclear

         = state? If such normative references exist, what is the

         = strategy for their completion? Are there normative references

         = that are downward references, as described in [RFC3967]? If

         = so, list these downward references to support the Area

         = Director in the Last Call procedure for them = [RFC3967].

 

No issues identified.

 

    (1.i) Has the Document Shepherd = verified that the document IANA

         = consideration section exists and is consistent with the body

         = of the document? If the document specifies protocol

         = extensions, are reservations requested in appropriate IANA

         = registries? Are the IANA registries clearly identified? If

         = the document creates a new registry, does it define the

         = proposed initial contents of the registry and an allocation

         = procedure for future registrations? Does it suggest a

         = reasonable name for the new registry? See [RFC5226]. If the

         = document describes an Expert Review process has Shepherd

         = conferred with the Responsible Area Director so that the IESG

         = can appoint the needed Expert during the IESG Evaluation?

 

The document defines a new IP Protocol Number. In = addition, it defines a new IKEv2 notification, and one new IANA registry. There are = no issues with any of them. I expect the Responsible AD to request the = existing IKE/IPsec IANA expert to extend his services to the current = draft.

 

    (1.j) Has the Document Shepherd = verified that sections of the

         = document that are written in a formal language, such as XML

         = code, BNF rules, MIB definitions, etc., validate correctly in

         = an automated checker?

 

There are no such = sections.

 

    (1.k) The IESG approval = announcement includes a Document

         = Announcement Write-Up. Please provide such a Document

         = Announcement Write-Up? Recent examples can be found in the

         = "Action" announcements for approved documents. The approval

         = announcement contains the following = sections:

 

         = Technical Summary

         =     Relevant content can frequently be found in the abstract

         =     and/or introduction of the document. If not, this may be

         =     an indication that there are deficiencies in the abstract

         =     or introduction.

 

This document describes the Wrapped Encapsulating = Security Payload (WESP) protocol, which is based on the Encapsulating Security = Payload (ESP) protocol and is designed to allow intermediate devices to ascertain if = ESP with null encryption is being employed and if so, inspect the IPsec packets = for network monitoring and access control functions. The mechanism described = in this document can be used to easily disambiguate ESP-NULL from encrypted = ESP packets, without compromising on the security provided by = ESP.

 

         = Working Group Summary

         =     Was there anything in WG process that is worth noting? For

         =     example, was there controversy about particular points or

         =     were there decisions where the consensus was particularly

         =     rough?

 

Early on there was prolonged WG discussion about the relative merits of the Wrapped ESP solution for identifying ESP-null = traffic, compared to heuristic methods for traffic inspection. Eventually the WG reached consensus on the usefulness of having both solutions published, with the heuristics solution targeted for the interim period until WESP is widely deployed. This consensus is documented in both protocol = documents.

 

         = Document Quality

         =     Are there existing implementations of the protocol? Have a

         =     significant number of vendors indicated their plan to

         =     implement the specification? Are there any reviewers that

         =     merit special mention as having done a thorough review,

         =     e.g., one that resulted in important changes or a

         =     conclusion that the document had no substantive issues? If

         =     there was a MIB Doctor, Media Type or other expert review,

         =     what was its course (briefly)? In the case of a Media Type

         =     review, on what date was the request = posted?

 

We are not aware of any implementations. Neither do = we know of any concrete vendor plans to implement this = specification.

 

(end)

------=_NextPart_001_022D_01CA2B38.A036F680-- ------=_NextPart_000_022C_01CA2B38.A036F680 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDkwMTE2MTU1M1owIwYJKoZIhvcNAQkEMRYEFPoK5JLRv8ac /TU2MH11br8a2xsYMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA pYeFKovucPkPMeqVk90Cclv4urBiZtUzDVQrSMDOaHTb/BL/w8dlDxuArNG4v6R0QTmu6hVgUgDj +z1Jp5pd9odafXu3zwFnnNsNm5tDQH9M5xpLStjn+rh5PsCw1YEVA5mtSEvOs2TZ1JNJLT93dajC JmpNIG/LCFhtEZj+22ztErbGYXqtbOSM7LZrd6sPVt1TyJbYcYp5OBVQjKz7WSq/uN0Jw3y9OtiS wFQ7DQdA55ofbAmiHmsrpG8cD/YIed2zyY0J5SQpXUFxJFU6p9yiU5jvsMswwUbJDcIjjLS8ZYxu Tgj840F3gFplwYNfbft9tV5w4sLTETQPuoDNggAAAAAAAA== ------=_NextPart_000_022C_01CA2B38.A036F680-- From kivinen@iki.fi Wed Sep 2 06:05:46 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2727B3A6BBA for ; Wed, 2 Sep 2009 06:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8UmPRIqfR2x for ; Wed, 2 Sep 2009 06:05:45 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id CD0E93A6BA7 for ; Wed, 2 Sep 2009 06:05:44 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n82ChudS002368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Sep 2009 15:43:56 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n82Chtv1002039; Wed, 2 Sep 2009 15:43:55 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19102.26763.522570.187181@fireball.kivinen.iki.fi> Date: Wed, 2 Sep 2009 15:43:55 +0300 From: Tero Kivinen To: naoyoshi ueda In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 13 min X-Total-Time: 13 min Cc: ipsec@ietf.org Subject: [IPsec] Questions to IKEv2bis draft: IVs of retransmitted packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 13:05:46 -0000 naoyoshi ueda writes: > According to ikev2bis-04 section 2.1: > > A retransmission from the initiator > > MUST be bitwise identical to the original request. That is, > > everything starting from the IKE Header (the IKE SA Initiator's SPI > > onwards) must be bitwise identical; items before it (such as the IP > > and UDP headers, and the zero non-ESP marker) do not have to be > > identical. > > So, IV of retransmitted request must be the same as that of original > request. Yes. > Meanwhile, ikev2bis-04 section 3.14 says > > o Initialization Vector - For CBC mode ciphers, the length of the > > initialization vector (IV) is equal to the block length of the > > underlying encryption algorithm. Senders MUST select a new > > unpredictable IV for every message; recipients MUST accept any > > value. > > Question 1: > Does the statement "recipients MUST accept any value." stay true > even if retransmitted IV differs from that of original request? Most likely, but it does not matter as the packet will fail window check, thus will be considered as retransmission or old packet, and thrown away (it might trigger retransmission of responders reply in case it was packet in the window). Note, that this can only happen if the other is non-conforming, or there is attacker between which modifies the IV. Conforming implementation will use same IV all time. > Question 2: > If the answer to Question 1 is no, what should the recipient do? > Just ignore it? Abandon the IKE_SA? Or send some Notify? If recipient has already seen the message before (i.e it has already processed it), it can resend its reply. It can also notice that the packet is not bitwise-same as previously and the message id is old, and silently ignore it. So this is implementation depended what will happen. If it has not seen the message before, then it does not know the IV has changed, thus will process the packet normally. > Question 3: > How about IV of retransmitted RESPONSE? > Does it need to be identical to the original one too? The retransmitted response should also be bitwise identical to original one. > It seems to me that the following statement in section 2.1 > implicitly requires that. But I'm not sure. I would agree you that it implicitly requires that. > Actually, I'm now involved in a IKEv2 implementation that > sends retransmitted response with different IV from original one > and I cannot tell if the behavior is allowed or not. I would say it is not allowed, but on the other hand, the other end should not ever notice this, as it only process one of the responses (the first to reach him), and then ignores rest even before decrypting them (when it checks its message id). I.e. it ignores further responses to requests it has already received response. > ikev2bis-04 section 2.1: > > The responder MUST remember each > > response until it receives a request whose sequence number is larger > > than or equal to the sequence number in the response plus its window > > size (see Section 2.3). -- kivinen@iki.fi From kivinen@iki.fi Wed Sep 2 06:05:47 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 539E23A6BA7 for ; Wed, 2 Sep 2009 06:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2M5Tdu0uAi3B for ; Wed, 2 Sep 2009 06:05:46 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id F06723A6BB9 for ; Wed, 2 Sep 2009 06:05:45 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n82CSnFd002454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Sep 2009 15:28:49 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n82CSmi5002655; Wed, 2 Sep 2009 15:28:48 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19102.25856.800410.560288@fireball.kivinen.iki.fi> Date: Wed, 2 Sep 2009 15:28:48 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: <19101.10929.181733.7940@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 13 min X-Total-Time: 88 min Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 13:05:47 -0000 Yoav Nir writes: > > Yes, altought I think most of the implementations do not bother > > sending INFORMATIONAL requests when IKE_AUTH response has errors. I > > think most implementations will then simply remove the IKE SA as > > failed without any further communications to the other end > > But wouldn't this cause a state de-synchronization? Yes, but not in normal case. > If the responder > sends a revoked certificate, the initiator will have no IKE SA, but > the responder would have an IKE SA, which it thinks is valid. Wouldn't > this necessarily later lead to requests that time out? Then the responder is already going against the RFC4306 which says "Certificate revocation checking must be considered during the chaining process used to select a certificate. " meaning the responder cannot send certifiate which itself considers revoced. Only case when this can happen is when responder thinks he has valid certificate but initiator then checks it against certificate authority's system (for example OCSP) and finds out it is not valid anymore. This is not common case, thus it can lead to timeouts. > > In cases where the other end is unknown (i.e. ID is not configured to > > the policy) it will return NO_PROPOSAL_CHOSEN as it does not find > > valid policy to accept the other ends proposal when looking it based > > on the ID. > > That allows for ID enumeration. It's similar to a password entry form, > that says "wrong user" or "wrong password". An attacker would be able > to verify whether a particular ID (say, user name) exists on a system. If the other ends source IP-address is not configured to system (and no wildcard entry found) then it will always return NO_PROPOSAL_CHOSEN regardless of the ID or AUTH payloads. Anyways active attacker can always find out the used IDs anyways. Also from timing it is easy to see whether other end actually did only database lookup for the ID, or whether he actually verified the RSA signature. If you consider ID enumeration a problem that needs to be added to the Security Considerations section (regardless whether we return AUTHENTICATION_FAILED or NO_PROPOSAL_CHOSEN in this case). > > This "MOST NOT" would make such implementations non-conforming, > > meaning every single implementation must do full parsing of the > > payloads first and only after that do second phase when it processes > > the payloads. > > How about if we limit this to packets that are malformed in their > entirety, rather than some particular payload (and packets that have > unrecognized critical payloads) ? If you say MUST in any of these error cases you need to be very specific which cases are covered, most likely giving similar pseudo code saying you first check this, and if it fails, return this error code, then you check this and so on... Similar than RFC2408 Section 5 did, but even then you most likely get implementations which do things differently because they just happen to use some external library or other thing that does parts of the checks in different order than what is listed in the RFC. I have been explaining this to several customers when they have run some external tester which required specific error code to be reported in specific case, and we returned some other error code because we checked things in different order. Thats why it is bad idea to specify MUSTs (or even SHOULDs) when taking which error to return. It is ok to say this check MUST be done (especially if it is security related), but there is no point of listing the order or specific error codes in all possible places. -- kivinen@iki.fi From peng.yang.chn@gmail.com Wed Sep 2 07:18:04 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00B9E28C730; Wed, 2 Sep 2009 07:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMU5WccFjyrT; Wed, 2 Sep 2009 07:18:03 -0700 (PDT) Received: from mail-pz0-f173.google.com (mail-pz0-f173.google.com [209.85.222.173]) by core3.amsl.com (Postfix) with ESMTP id B848A3A6864; Wed, 2 Sep 2009 07:17:16 -0700 (PDT) Received: by mail-pz0-f173.google.com with SMTP id 3so849471pzk.20 for ; Wed, 02 Sep 2009 07:17:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fYDZFsWOdcrYpUCWBB2BA8Qszqo7I79dssuXY4AXvGo=; b=cabwTs2nSSb5rY15yjnTvuxNrlnwDdGGHGIL57+/4bDRO/Klu+GZe7/WzrkacmmG0S MN+reE/poKAN26N1NLb9OYpLRU7tMDfsUM8m3sVw6oG2mw8ZRZuN3nTaokg0Jk8j/pDO VNrgM/ql4ZECJWoPFNoReMD2Ux1JU0IvnZS6Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=m6DD7dDx4rknl30neaT4258Ew4gDau11gc3pVRieV4bA3qu52etrPmriBCd5UFOE5z RhlWYCjDlsyXhGNVKMKn7V6dR/3byuuWtscvwUesqCC+jlmGyfznuBr9i3KzNKy6vnc7 2PbEBbiiuRkiEexvsqgfwXnjLPuA5ZmXk585g= MIME-Version: 1.0 Received: by 10.140.141.2 with SMTP id o2mr2374701rvd.204.1251901052629; Wed, 02 Sep 2009 07:17:32 -0700 (PDT) In-Reply-To: <4c5c7a6d0909011932g74decc2dq1ae2cb61b78b2b0a@mail.gmail.com> References: <20090831140935.4752B3A6E46@core3.amsl.com> <4c5c7a6d0909011932g74decc2dq1ae2cb61b78b2b0a@mail.gmail.com> Date: Wed, 2 Sep 2009 22:17:32 +0800 Message-ID: <4c5c7a6d0909020717r72ee57btaaa9bdafd39a12cd@mail.gmail.com> From: Peny Yang To: ietf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPsecme WG Subject: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 14:18:04 -0000 Sorry, I should cc IPsec mail list. Comments are sent again. Hi, floks: I have two comments on the draft of IKEv2 Session Resumption: 1) Sorry, I have to talk about my concern on the new IKE_SESSION_RESUME. In WG last call, actually I made this comment. However, no feedback was given, maybe because my comment was a little late for WG last call. So, I just copy it here again as a comment for IESG last call. Well, =A0we've discussed pros and cons of IKE_SA_INIT and IKE_SESSION_RESUME for quite a long time. However, IMHO, the consensus is still not fully achieved on this item. So far, I still prefer to choosing extended IKE_SA_INIT for ticket presenting. This solution is specified in http://tools.ietf.org/html/draft-xu-ike-sa-sync-01 As a summary, the virtues are as follows: - RFC5077 (TLS session resumption) also uses the similar scheme, which extends the message of clienthello with session ticket extension. The extended IKE_SA_INIT solution has the similar way. It's easy to extend the base IKEv2 protocol stack to support session resumption. - Considering the case of failing session resumption, the extended IKE_SA_INIT solution can save one round trip. - As indicated in 4.3.3 IKE_AUTH exchange, IKE_AUTH must be initiated after IKE_SESSION_RESUME. In this sense, the extended IKE_SA_INIT way need less code to be supported compared with IKE_SESSION_RESUME. The down side: - some people thought the way of extended IKE_SA_INIT will make the base IKEv2 protocol stack more complex. IMHO, it's an issue of implementation. Again, I still support to use extended IKE_SA_INIT for ticket presenting instead of IKE_SESSION_RESUME. 2) Maybe I missed some discussions. There is the case: responder may receives a ticket for an IKE SA that is still active and if the responder accepts it. In one of previous versions of this draft, there once was some description on this case. I know that how a client detects the need for resumption is out of the scope of this draft. But, there is the possibility that IPsec client may be continuously deceived and believe the fail of IPsec gateway. It may continuously present the ticket and update the ticket. In this sense, IMHO, this draft should take care of this case. BRG Peny On Mon, Aug 31, 2009 at 10:09 PM, The IESG wrote: > The IESG has received a request from the IP Security Maintenance and > Extensions WG (ipsecme) to consider the following document: > > - 'IKEv2 Session Resumption ' > =A0 as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. =A0Please send substantive comments to the > ietf@ietf.org mailing lists by 2009-09-14. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-resumption-0= 7.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D17990&rfc_flag=3D0 > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From wierbows@us.ibm.com Wed Sep 2 09:04:13 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 807E63A683B for ; Wed, 2 Sep 2009 09:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.844 X-Spam-Level: X-Spam-Status: No, score=-3.844 tagged_above=-999 required=5 tests=[AWL=-1.246, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDXOOqf2eZSA for ; Wed, 2 Sep 2009 09:04:12 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by core3.amsl.com (Postfix) with ESMTP id 75E9F3A67B0 for ; Wed, 2 Sep 2009 09:04:12 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e9.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n82FVfhn020820 for ; Wed, 2 Sep 2009 11:31:41 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n82FXTEO238708 for ; Wed, 2 Sep 2009 11:33:29 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n82FXP9U006689 for ; Wed, 2 Sep 2009 11:33:26 -0400 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n82FXKWW006412 for ; Wed, 2 Sep 2009 11:33:20 -0400 In-Reply-To: <19102.25856.800410.560288@fireball.kivinen.iki.fi> References: <19101.10929.181733.7940@fireball.kivinen.iki.fi> <19102.25856.800410.560288@fireball.kivinen.iki.fi> X-KeepSent: 9DF42776:45D16AA5-85257625:00541DFA; type=4; name=$KeepSent To: "ipsec@ietf.org WG" X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: David Wierbowski Date: Wed, 2 Sep 2009 11:33:18 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 09/02/2009 11:33:20 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBFCB6DFC79B6A8f9e8a93df938690918c0ABBFCB6DFC79B6A" Content-Disposition: inline Subject: [IPsec] CRL checking when selecting a certifcate X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 16:04:13 -0000 --0__=0ABBFCB6DFC79B6A8f9e8a93df938690918c0ABBFCB6DFC79B6A Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable In a recent append Tero said: >Then the responder is already going against the RFC4306 which says >"Certificate revocation checking must be considered during the >chaining process used to select a certificate. " meaning the responder= >cannot send certifiate which itself considers revoced. Only case when >this can happen is when responder thinks he has valid certificate but >initiator then checks it against certificate authority's system (for >example OCSP) and finds out it is not valid anymore. This is not >common case, thus it can lead to timeouts. This is a lower case must. I'm not sure it is safe to assume that implementations adhere to a lower case must. CRL checking is not cheap= and performing CRL checking when selecting a certificate seems like an opti= onal usability feature to me. From the sender's point of view the worst thi= ng that is going to happen is the receiver will fail the authentication because the certificate is revoked. The only advantage to doing the ch= eck on the sender's side is there is a chance the sender can find a non-rev= oked certificate, but I think the decision to perform that optimization is implementation specific. Dave Wierbowski = --0__=0ABBFCB6DFC79B6A8f9e8a93df938690918c0ABBFCB6DFC79B6A Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

In a recent append Tero said:

>Then the responder is already going against the RFC4306 which says<= br> >"Certificate revocation checking must be considered during the=
>chaining process used to select a certificate. " meaning the r= esponder
>cannot send certifiate which itself considers revoced. Only case wh= en
>this can happen is when responder thinks he has valid certificate b= ut
>initiator then checks it against certificate authority's system (fo= r
>example OCSP) and finds out it is not valid anymore. This is not >common case, thus it can lead to timeouts.

This is a lower case must. I'm not sure it is safe to assume that impl= ementations adhere to a lower case must. CRL checking is not cheap and= performing CRL checking when selecting a certificate seems like an opt= ional usability feature to me. From the sender's point of view the wor= st thing that is going to happen is the receiver will fail the authenti= cation because the certificate is revoked. The only advantage to doing= the check on the sender's side is there is a chance the sender can fin= d a non-revoked certificate, but I think the decision to perform that o= ptimization is implementation specific.


Dave Wierbowski

= --0__=0ABBFCB6DFC79B6A8f9e8a93df938690918c0ABBFCB6DFC79B6A-- From yaronf@checkpoint.com Wed Sep 2 14:17:36 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFD583A6EC5; Wed, 2 Sep 2009 14:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2M-q5wILpHIO; Wed, 2 Sep 2009 14:17:35 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id D549528C18D; Wed, 2 Sep 2009 14:16:35 -0700 (PDT) X-CheckPoint: {4A9EE00F-0-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 0783729C004; Thu, 3 Sep 2009 00:15:45 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id D339629C002; Thu, 3 Sep 2009 00:15:44 +0300 (IDT) X-CheckPoint: {4A9EE00B-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n82LFi3d029756; Thu, 3 Sep 2009 00:15:44 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 3 Sep 2009 00:15:41 +0300 From: Yaron Sheffer To: Peny Yang , "ietf@ietf.org" Date: Thu, 3 Sep 2009 00:15:40 +0300 Thread-Topic: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard Thread-Index: Acor2EPuK6LMhLzmTx6HwtJbVSewPwANiDqw Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190A978EFBE@il-ex01.ad.checkpoint.com> References: <20090831140935.4752B3A6E46@core3.amsl.com> <4c5c7a6d0909011932g74decc2dq1ae2cb61b78b2b0a@mail.gmail.com> <4c5c7a6d0909020717r72ee57btaaa9bdafd39a12cd@mail.gmail.com> In-Reply-To: <4c5c7a6d0909020717r72ee57btaaa9bdafd39a12cd@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_03A1_01CA2C2B.AB55C020" MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 21:17:37 -0000 ------=_NextPart_000_03A1_01CA2C2B.AB55C020 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi Peny, Thank you for reviewing this draft. Please see my comments below. Regards, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf = Of > Peny Yang > Sent: Wednesday, September 02, 2009 17:18 > To: ietf@ietf.org > Cc: IPsecme WG > Subject: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption > (IKEv2 Session Resumption) to Proposed Standard >=20 > Sorry, I should cc IPsec mail list. Comments are sent again. >=20 > Hi, floks: >=20 > I have two comments on the draft of IKEv2 Session Resumption: >=20 > 1) Sorry, I have to talk about my concern on the new > IKE_SESSION_RESUME. In WG last call, actually I made this comment. > However, no feedback was given, maybe because my comment was a little > late for WG last call. So, I just copy it here again as a comment for > IESG last call. >=20 > Well, =A0we've discussed pros and cons of IKE_SA_INIT and > IKE_SESSION_RESUME for quite a long time. However, IMHO, the consensus > is still not fully achieved on this item. So far, I still prefer to > choosing extended IKE_SA_INIT for ticket presenting. This solution is > specified in http://tools.ietf.org/html/draft-xu-ike-sa-sync-01 >=20 > As a summary, the virtues are as follows: > - RFC5077 (TLS session resumption) also uses the similar scheme, which > extends the message of clienthello with session ticket extension. The > extended IKE_SA_INIT solution has the similar way. It's easy to extend > the base IKEv2 protocol stack to support session resumption. > - Considering the case of failing session resumption, the extended > IKE_SA_INIT solution can save one round trip. > - As indicated in 4.3.3 IKE_AUTH exchange, IKE_AUTH must be initiated > after IKE_SESSION_RESUME. In this sense, the extended IKE_SA_INIT way > need less code to be supported compared with IKE_SESSION_RESUME. >=20 > The down side: > - some people thought the way of extended IKE_SA_INIT will make the > base IKEv2 protocol stack more complex. IMHO, it's an issue of > implementation. > Again, I still support to use extended IKE_SA_INIT for ticket > presenting instead of IKE_SESSION_RESUME. >=20 [YS] I see the merits of extending IKE_SA_INIT to support resumption, = and in fact an early version of our work did exactly that. But the working = group gave us a clear direction to use a separate exchange, and this is where = we disagree: I believe we did have a strong WG consensus that the implementation benefits of having a separate exchange (i.e. not = overloading even more the non-trivial IKE_SA_INIT exchange) outweigh the benefits of = the alternative. > 2) Maybe I missed some discussions. > There is the case: responder may receives a ticket for an IKE SA that > is still active and if the responder accepts it. In one of previous > versions of this draft, there once was some description on this case. [YS] I believe you are referring to the text now in Sec. 4.3.4. > I know that how a client detects the need for resumption is out of the > scope of this draft. But, there is the possibility that IPsec client > may be continuously deceived and believe the fail of IPsec gateway. It > may continuously present the ticket and update the ticket. In this > sense, IMHO, this draft should take care of this case. >=20 [YS] If I understand the scenario correctly, it is similar to an = attacker repeatedly sending notifications to an IKE client, making it believe = that the IKE exchange has failed and needs to be reinitiated. This attack = against plain-vanilla IKE would be much more CPU-intensive to the client and to = the (real) gateway, compared to repeated session resumption. Even when you factor in the cost of generating a new ticket. Moreover, the regular = IKEv2 anti-DOS cookie mechanism is supported by IKE_SESSION_RESUME as well. > BRG > Peny >=20 > On Mon, Aug 31, 2009 at 10:09 PM, The IESG = wrote: > > The IESG has received a request from the IP Security Maintenance and > > Extensions WG (ipsecme) to consider the following document: > > > > - 'IKEv2 Session Resumption ' > > =A0 as a Proposed = Standard > > > > The IESG plans to make a decision in the next few weeks, and = solicits > > final comments on this action. =A0Please send substantive comments = to the > > ietf@ietf.org mailing lists by 2009-09-14. Exceptionally, > > comments may be sent to iesg@ietf.org instead. In either case, = please > > retain the beginning of the Subject line to allow automated sorting. > > > > The file can be obtained via > > = http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-resumption- > 07.txt > > > > > > IESG discussion can be tracked via > > > = https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D17 > 990&rfc_flag=3D0 > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_03A1_01CA2C2B.AB55C020 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDkwMjIxMTU0MFowIwYJKoZIhvcNAQkEMRYEFHKjvmmVEG2O K5q6hylgwkofozqeMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA tb7z8f6X92Ro4JxdUVDOzDr3Rlu7AiRwaMECfVhR+jCPSDeBG6Qdw4Xu0MAgPn3DQQPDG57KQqc2 3CNn+CrN4cG+5ACiuvUfIgr2vSRx9n1gUkxIwdIOesnr9mi9jsQI0whSnzDKPxZHDK0m5v2AQl/3 tZnsZx310gzo9Y+4R72nPc/E+P/lBwb1JPPu7awkpEqZ1p4uhmHbLJa1nBwbznH7GWK/2D/c7wKv PVT0aeW05TmWRHHOccBjyrgQ+cxYCNKVGed9C3qNnm0bowf8DQHPTuzbsdGqqeIv5Jqx5sZsIkMx 2TJ8Skl9tYZ8WyBmP7JDRz5o1pTWhxSDi+X3agAAAAAAAA== ------=_NextPart_000_03A1_01CA2C2B.AB55C020-- From kivinen@iki.fi Thu Sep 3 02:03:32 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A35A53A6984 for ; Thu, 3 Sep 2009 02:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 481nXtI+RIt5 for ; Thu, 3 Sep 2009 02:03:31 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 1362A3A6B11 for ; Thu, 3 Sep 2009 02:03:07 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n8391T1o021195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Sep 2009 12:01:29 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n8391R4G020321; Thu, 3 Sep 2009 12:01:27 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19103.34279.253359.922428@fireball.kivinen.iki.fi> Date: Thu, 3 Sep 2009 12:01:27 +0300 From: Tero Kivinen To: David Wierbowski In-Reply-To: References: <19101.10929.181733.7940@fireball.kivinen.iki.fi> <19102.25856.800410.560288@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 10 min Cc: "ipsec@ietf.org WG" Subject: [IPsec] CRL checking when selecting a certifcate X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 09:03:32 -0000 David Wierbowski writes: > > In a recent append Tero said: > > >Then the responder is already going against the RFC4306 which says > >"Certificate revocation checking must be considered during the > >chaining process used to select a certificate. " meaning the responder > >cannot send certifiate which itself considers revoced. Only case when > >this can happen is when responder thinks he has valid certificate but > >initiator then checks it against certificate authority's system (for > >example OCSP) and finds out it is not valid anymore. This is not > >common case, thus it can lead to timeouts. > > This is a lower case must. Which does not say you can ignore it. It just says it is not protocol specific "MUST" which affect interoperability, it is behavior "must" meaning you still need to do that, but even if you don't you will most likely are still interoperable (altought the connection will/can fail). > I'm not sure it is safe to assume that > implementations adhere to a lower case must. I expect that that implementations do follow such text. If implementations ignore this kind of text with no upper case MUST then I am sure the implementation doing that is completely broken. If we take other example from section 1.2 which says: ---------------------------------------------------------------------- The initial exchanges are as follows: Initiator Responder ------------------------------------------------------------------- HDR, SAi1, KEi, Ni --> HDR contains the Security Parameter Indexes (SPIs), version numbers, and flags of various sorts. The SAi1 payload states the cryptographic algorithms the initiator supports for the IKE SA. The KE payload sends the initiator's Diffie-Hellman value. Ni is the initiator's nonce. ---------------------------------------------------------------------- There is no "MUST/SHOULD/MAY"s in there but if implementation does not follow the text explaining how initial exchange packet is generated the implementation does not work. So implementations cannot just search uppercase "MUST/SHOULD/MAY" texts and assume it is enough to make sure those are correct. It also needs to do what the text says... > CRL checking is not cheap and > performing CRL checking when selecting a certificate seems like an optional > usability feature to me. The you probably want to make change to the current text which says you must do it... On the other hand usually you are using certificates from the same CA, thus when you checking other ends certificate you already fetch the CRL from the CA and revoke those certificates which are revoked by it. If that happens yo revoke your own certificate you should notice that too. That means in normal case the CRL checking is free operation as you need to do it anyways for the other ends certificate (the most expensive operation usually is the fetching of the CRL and verifying its signature, looping through the revoked certificates after that is very cheap). Only case where it actually do cost you extra is when you are using different CRL for your own certificate than what the other end is using. > From the sender's point of view the worst thing > that is going to happen is the receiver will fail the authentication > because the certificate is revoked. The only advantage to doing the check > on the sender's side is there is a chance the sender can find a non-revoked > certificate, but I think the decision to perform that optimization is > implementation specific. Partially agree on that. Especially as the recipient of your certificate might have information that you do not (for example the garage door opener remote controller might not have connection to the CA to fetch CRLs, but the server to which it connects to can have, and can check CRLs and can also send CRLs inband to the remote). But with current text that is not possible. -- kivinen@iki.fi From kivinen@iki.fi Thu Sep 3 02:38:34 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B5333A6816 for ; Thu, 3 Sep 2009 02:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71EOIVLssRir for ; Thu, 3 Sep 2009 02:38:33 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id B31BE28C107 for ; Thu, 3 Sep 2009 02:36:40 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n839P8DR019296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 3 Sep 2009 12:25:08 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n839P8T3021579; Thu, 3 Sep 2009 12:25:08 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19103.35700.506013.687392@fireball.kivinen.iki.fi> Date: Thu, 3 Sep 2009 12:25:08 +0300 From: Tero Kivinen To: ipsec@ietf.org In-Reply-To: <20090901160002.0A34B3A7003@core3.amsl.com> References: <20090901160002.0A34B3A7003@core3.amsl.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 13 min Subject: [IPsec] I-D Action:draft-ietf-ipsecme-traffic-visibility-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 09:38:34 -0000 Internet-Drafts@ietf.org writes: > Title : Wrapped ESP for Traffic Visibility > Author(s) : K. Grewal, et al. > Filename : draft-ietf-ipsecme-traffic-visibility-08.txt > Pages : 15 > Date : 2009-09-01 Found out one more nit in the WESP draft. It now says: Flags, 8 bits: The bits are defined LSB first, so bit 0 would be the least significant bit of the flags octet. and then defines flags from MSB first without specifying bit numbers and those bit numbers based on the picture are 5-7. This is bit confusing. So I propose that you add the explicit bit numbers to the descriptions i.e. add "bits 6-7" to version and "bit 5" to description. On the other hand your picture is using MSB order, i.e. bit number 0 is the most significant bit, and flags is bits 24-31, so it would make sense to define bits inside the flags also in MSB order, i.e. change the text to: ---------------------------------------------------------------------- Flags, 8 bits: The bits are defined MSB first, so bit 0 would be the most significant bit of the flags octet. 2 bits (bits 0-1): Version (V). MUST be sent as 0 and checked by the receiver. If the version is different than an expected version number (e.g. negotiated via the control channel), then the packet must be dropped by the receiver. Future modifications to the WESP header may require a new version number. Intermediate nodes dealing with unknown versions are not necessarily able to parse the packet correctly. Intermediate treatment of such packets is policy-dependent (e.g., it may dictate dropping such packets). 1 bit (bit 2): Encrypted Payload (E). Setting the Encrypted Payload bit to 1 indicates that the WESP (and therefore ESP) payload is protected with encryption. If this bit is set to 0, then the payload is using ESP-NULL cipher. Setting or clearing this bit also impacts the value in the WESP Next Header field, as described above. The recipient MUST ensure consistency of this flag with the negotiated policy and MUST drop the incoming packet otherwise. 5 bits (bits 3-7): Flags, reserved for future use. The flags MUST be sent as 0, and ignored by the receiver. Future documents defining any of these flags MUST NOT affect the distinction between encrypted and unencrypted packets. Intermediate nodes dealing with unknown flags are not necessarily able to parse the packet correctly. Intermediate treatment of such packets is policy-dependent (e.g., it may dictate dropping such packets). ---------------------------------------------------------------------- I am actually not sure if we have properly defined bit order for IETF use. In pictures we use MSB bit first numbering, but in some other places we have used LSB bit numbering (like RFC4306 uses for its flags). If you want to keep LSB bit ordering inside the flags then text would be: ---------------------------------------------------------------------- Flags, 8 bits: The bits are defined LSB first, so bit 0 would be the least significant bit of the flags octet. 2 bits (bits 6-7): Version (V). MUST be sent as 0 and checked by the receiver. If the version is different than an expected version number (e.g. negotiated via the control channel), then the packet must be dropped by the receiver. Future modifications to the WESP header may require a new version number. Intermediate nodes dealing with unknown versions are not necessarily able to parse the packet correctly. Intermediate treatment of such packets is policy-dependent (e.g., it may dictate dropping such packets). 1 bit (bit 5): Encrypted Payload (E). Setting the Encrypted Payload bit to 1 indicates that the WESP (and therefore ESP) payload is protected with encryption. If this bit is set to 0, then the payload is using ESP-NULL cipher. Setting or clearing this bit also impacts the value in the WESP Next Header field, as described above. The recipient MUST ensure consistency of this flag with the negotiated policy and MUST drop the incoming packet otherwise. 5 bits (bits 0-4): Flags, reserved for future use. The flags MUST be sent as 0, and ignored by the receiver. Future documents defining any of these flags MUST NOT affect the distinction between encrypted and unencrypted packets. Intermediate nodes dealing with unknown flags are not necessarily able to parse the packet correctly. Intermediate treatment of such packets is policy-dependent (e.g., it may dictate dropping such packets). -- kivinen@iki.fi From kivinen@iki.fi Thu Sep 3 02:38:34 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6219F3A6816; Thu, 3 Sep 2009 02:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWErLGkemBhN; Thu, 3 Sep 2009 02:38:33 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 55ABD28C125; Thu, 3 Sep 2009 02:36:42 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n839BgWp019520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Sep 2009 12:11:42 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n839BfcR018241; Thu, 3 Sep 2009 12:11:41 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19103.34893.896574.218235@fireball.kivinen.iki.fi> Date: Thu, 3 Sep 2009 12:11:41 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190A978EFBE@il-ex01.ad.checkpoint.com> References: <20090831140935.4752B3A6E46@core3.amsl.com> <4c5c7a6d0909011932g74decc2dq1ae2cb61b78b2b0a@mail.gmail.com> <4c5c7a6d0909020717r72ee57btaaa9bdafd39a12cd@mail.gmail.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80190A978EFBE@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 9 min Cc: IPsecme WG , "ietf@ietf.org" , Peny Yang Subject: Re: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 09:38:34 -0000 Yaron Sheffer writes: > [YS] I see the merits of extending IKE_SA_INIT to support resumption, and in > fact an early version of our work did exactly that. But the working group > gave us a clear direction to use a separate exchange, and this is where we > disagree: I believe we did have a strong WG consensus that the > implementation benefits of having a separate exchange (i.e. not overloading > even more the non-trivial IKE_SA_INIT exchange) outweigh the benefits of the > alternative. I agree on that (both to the WG having consensus and also that using separate exchange is better). > > I know that how a client detects the need for resumption is out of the > > scope of this draft. But, there is the possibility that IPsec client > > may be continuously deceived and believe the fail of IPsec gateway. It > > may continuously present the ticket and update the ticket. In this > > sense, IMHO, this draft should take care of this case. > > > [YS] If I understand the scenario correctly, it is similar to an attacker > repeatedly sending notifications to an IKE client, making it believe that > the IKE exchange has failed and needs to be reinitiated. This attack against > plain-vanilla IKE would be much more CPU-intensive to the client and to the > (real) gateway, compared to repeated session resumption. Even when you > factor in the cost of generating a new ticket. Moreover, the regular IKEv2 > anti-DOS cookie mechanism is supported by IKE_SESSION_RESUME as well. Regardless what notifications or ICMP messages you send to any of the IKE end points that MUST NOT cause them to consider IKE SA failed. It "MUST conclude that the other endpoind has failed only when repeated attemtps to contact it have gone unanswered for timeout period or when a cryptographically protected INITIAL_CONTACT notification is received on a different IKE SA to the same authenticated identity." (RFC 4306 section 2.4) Notifications and ICMP messages may trigger other end to send empty INFORMATIONAL message to check whether the other end is alive or not and only if that times out then the other end is considered dead. This means this kind of attack is not possible with notifications and ICMP. On the other hand I do agree with Peny that, as resumption draft makes it out of scope for this draft, how a client detects the need of resumption, we might need more text explaining this attack. I.e. we might need to add text to security considerations which says that the client implementations should not trust any untrusted source when they are trying to detect whether the resumption is needed. -- kivinen@iki.fi From root@core3.amsl.com Thu Sep 3 04:45:01 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C43543A69A7; Thu, 3 Sep 2009 04:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090903114501.C43543A69A7@core3.amsl.com> Date: Thu, 3 Sep 2009 04:45:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-esp-null-heuristics-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 11:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Heuristics for Detecting ESP-NULL packets Author(s) : T. Kivinen, D. McDonald Filename : draft-ietf-ipsecme-esp-null-heuristics-01.txt Pages : 33 Date : 2009-09-03 This document describes a heuristic approach for distinguishing ESP- NULL (Encapsulating Security Payload without encryption) packets from encrypted ESP packets. The reason for using heuristics instead of modifying ESP is to provide a solution that can be used now without updating all end nodes. With heuristic methods, only the intermediate devices wanting to find ESP-NULL packets need to be updated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-esp-null-heuristics-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-esp-null-heuristics-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-03043855.I-D@ietf.org> --NextPart-- From kivinen@iki.fi Thu Sep 3 04:52:20 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3CA53A68DD for ; Thu, 3 Sep 2009 04:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWtJM3u301Dw for ; Thu, 3 Sep 2009 04:52:20 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 22B803A6A60 for ; Thu, 3 Sep 2009 04:51:45 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n83BomhK027981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Sep 2009 14:50:48 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n83BolSq028593; Thu, 3 Sep 2009 14:50:47 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19103.44439.557575.669236@fireball.kivinen.iki.fi> Date: Thu, 3 Sep 2009 14:50:47 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120A922@il-ex01.ad.checkpoint.com> <19090.36016.734818.51208@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 10 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Relating the two ESP-null documents X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 11:52:20 -0000 Paul Hoffman writes: > At 3:50 PM +0300 8/24/09, Tero Kivinen wrote: > >So would this text be added to both documents or what? > > It should go in both. That way, an implementer a year from now who > comes across one of the RFCs will both find out about the other and > be clear on the relationship. > > >If so where > >(between section 2 and 3 in esp-null-heuristics and after or replacing > >section 1.2 of traffic-visibility draft)? > > My preference for esp-null-heuristics is that this applicability > statement be section 1.1, and that what is now section 2 (the 2119 > language) become section 1.2. Posted new version of the draft now to the repository. Changes are: - Added applicability statement - Processed comments from Yaron - Added comment about UDP-encapsulated ESP and IPsec flows to new section 7. - Fixed typos - Added text to security considerations section that attacker can bypass inspection by other encapsulation methods too. - Processed comments from David McGrew - Added text about IV not necessarely being random - Added text about minimal padding - Removed the "XXX TBA -- including possible chunk-specific checking" from SCTP section (if someone will provide me text about that I will add it). - Added some more comments to the pseudocode -- kivinen@iki.fi From kagarigi@cisco.com Thu Sep 3 06:09:00 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A99928C144 for ; Thu, 3 Sep 2009 06:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7F9fP0GBXFKj for ; Thu, 3 Sep 2009 06:08:51 -0700 (PDT) Received: from syd-iport-1.cisco.com (syd-iport-1.cisco.com [64.104.193.196]) by core3.amsl.com (Postfix) with ESMTP id 54AA828C17E for ; Thu, 3 Sep 2009 06:08:50 -0700 (PDT) X-Files: ikev2-ha-messageid-sync.txt : 9440 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFANVcn0oKS+eh/2dsb2JhbACCKiy/IIhBAZAyBYQbgVxj X-IronPort-AV: E=Sophos;i="4.44,325,1249257600"; d="txt'?scan'208,217";a="60169296" Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by syd-iport-1.cisco.com with ESMTP; 03 Sep 2009 13:07:35 +0000 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n83D7YUW026226 for ; Thu, 3 Sep 2009 21:07:34 +0800 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n83D7X3h010187 for ; Thu, 3 Sep 2009 13:07:33 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 18:36:53 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CA2C97.67E29C21" Date: Thu, 3 Sep 2009 18:36:58 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ikev2 HA message Id Issue Thread-Index: Acosl2r1O/31ap0+S7iBnpuoe98dvg== From: "Kalyani Garigipati (kagarigi)" To: X-OriginalArrivalTime: 03 Sep 2009 13:06:53.0027 (UTC) FILETIME=[68043330:01CA2C97] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=20951; t=1251983255; x=1252847255; c=relaxed/simple; s=hkgdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kagarigi@cisco.com; z=From:=20=22Kalyani=20Garigipati=20(kagarigi)=22=20 |Subject:=20Ikev2=20HA=20message=20Id=20Issue |Sender:=20; bh=wtAFhAZFpj8f7xFIHz5+c0FB/WF9+mYXjsdRk/pLAkw=; b=URJpk63QRU8HffK62wh22JqAdQmbLzDtYE1/AGVBUp4ZdNRETyMSRlvtai iVgNeALxxBovUiqgym/7IbeAHm+vLZGuAqBFen5O1ezwcNbNayjTC7tIA4Tp 8Rg1SVbEOHicvZbFh+RCZhFwhSGxxhilbluzkZMUuCxRCOK0YoTvk=; Authentication-Results: hkg-dkim-1; header.From=kagarigi@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim1002 verified; ); Subject: [IPsec] Ikev2 HA message Id Issue X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 13:09:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA2C97.67E29C21 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA2C97.67E29C21" ------_=_NextPart_002_01CA2C97.67E29C21 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi , =20 In Ikev2 HA, there is an issue with the message Id and window size. =20 Standby device-----------------------active device----------------------------------Peer device =20 The active device participating in the exchange with the peer will update its message id counters as per the exchanges done. This info cannot be synced to the stand-by device for every exchange done since that would take up all the bandwidth and is not an efficient way. =20 The stand-by device when it becomes active will start with the message Id as 1 and this will not be accepted by the peer, since its message Id counters are different. Hence a solution is required to sync the message Id counters to the standby device. =20 1. A solution for this is to get the required info from the peer device since it maintains all these counters. The abstract details of how this can be done are given in the attached document. =20 2. An alternative solution for this could be to send a new notify called (RESET_MESSAGE_ID) to the peer device as soon as the standby comes up. But this may lead to=20 Reuse of message Id's within the same SA which is not desirable. =20 I think solution 1 should be implemented with Ikev2. Please give your comments =20 Regards, Kalyani =20 =20 =20 =20 ------_=_NextPart_002_01CA2C97.67E29C21 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi ,

 

In Ikev2 HA, there is an issue with the message Id = and window size.

 

Standby device-----------------------active device----------------------------------Peer = device

 

The active device participating in the exchange with = the peer will update its message id counters as per the exchanges = done.

This info cannot be synced to the stand-by device for = every exchange done since that would take up all the bandwidth and is not an efficient way.

 

The stand-by device when it becomes active will start = with the message Id as 1 and this will not be accepted by the peer, since its message Id counters are different.

Hence a solution is required to sync the message Id = counters to the standby device.

 

1. A solution for this is to get the required info = from the peer device since it maintains all these = counters.

The abstract details of how this can be done are = given in the attached document.

 

2. An alternative solution for this could be to send = a new notify called (RESET_MESSAGE_ID) to the peer device as soon as the = standby comes up. But this may lead to

Reuse of message Id’s within the same SA which = is not desirable.

 

I think solution 1 should be implemented with Ikev2. = Please give your comments

 

Regards,

Kalyani

 

 

 

 

------_=_NextPart_002_01CA2C97.67E29C21-- ------_=_NextPart_001_01CA2C97.67E29C21 Content-Type: text/plain; name="ikev2-ha-messageid-sync.txt" Content-Transfer-Encoding: base64 Content-Description: ikev2-ha-messageid-sync.txt Content-Disposition: attachment; filename="ikev2-ha-messageid-sync.txt" MS4gIEludHJvZHVjdGlvbg0KPT09PT09PT09PT09PT09PT09PT09PQ0KDQpIQSBmb3IgaWtldjIg c2Vzc2lvbnMgaXMgcmVxdWlyZWQgdG8gZW5zdXJlIHRoYXQgaW4gY2FzZSBvZiBjcmFzaCBvZiBh Y3RpdmUgZGV2aWNlICwgdGhlIHN0YW5kIGJ5IGRldmljZSBiZWNvbWVzIGFjdGl2ZSBpbW1lZGlh dGVseS4NClRoZSBzdGFuZCBieSBkZXZpY2UgaXMgZXhwZWN0ZWQgdG8gaGF2ZSB0aGUgc3luYyBv ZiBtZXNzYWdlIGlkJ3Mgb2YgYWN0aXZlIGRldmljZSBhdCB0aGUgdGltZSBvZiBjcmFzaC4NCg0K SWYgd2UgZG9uknQgc3luYyB1cCB0aGVzZSBmaWVsZHMgYXQgdGhlIHN0YW5kLWJ5IGRldmljZSB0 aGVuIHdoZW4gdGhlIHNlc3Npb24gY29tZXMgdXAgb24gdGhlIHN0YW5kYnkgZGV2aWNlLCANCml0 IHdvdWxkIHN0YXJ0IHRoZSBtZXNzYWdlIGlkIGZyb20gMS4gVGhpcyB3b3VsZCBtYWtlIGl0IHJl amVjdCBhbGwgdGhlIHJlcXVldHMgZnJvbSB0aGUgcGVlciBzaW5jZSBwZWVyIHdpbmRvdyB3b3Vs ZCBoYXZlIA0KYWR2YW5jZWQgdG8gc29tZSBvdGhlciByYW5nZS4gDQoNCkFuZCBhbHNvIGFsbCB0 aGUgcmVxdWVzdHMgZnJvbSBzdGFuZC1ieSBkZXZpY2UgdG8gdGhlIHBlZXIgd291bGQgYmUgcmVq ZWN0ZWQuDQpUaGUgcGVlciB3b3VsZCB0aGVuIGJyaW5nIGRvd24gdGhlIGNvbm5lY3Rpb24gYW5k IHRoZW4gYSBuZXcgc2Vzc2lvbiBoYXMgdG8gYmUgZXN0YWJsaXNoZWQgYXQgdGhlIHN0YW5kYnlk ZXZpY2UuIA0KVGhpcyBpcyBub3QgYSBkZXNpcmFibGUgZmVhdHVyZSBvZiBIQS4NCg0KT25lIHNv bHV0aW9uIGZvciB0aGlzIGlzIHRvIHN5bmMgdGhlIHN0YW5kLWJ5IGRldmljZSB3aXRoIHRoZSBt ZXNzYWdlIGlkIGZvciBldmVyeSBtZXNzYWdlIGV4Y2hhbmdlIHRoYXQgaGFwcGVucw0KYmV0d2Vl biBzdGFuZGJ5IGFuZCB0aGUgYWN0aXZlIGRldmljZS5CdXQgdGhpcyBzb2x1dGlvbiBpcyBub3Qg ZWZmaWNpZW50IHNpbmNlIHRoaXMgd291bGQgdGFrZSBhbGwgdGhlIGJhbmR3aWR0aCBiZXR3ZWVu IHRoZSANCnN0YW5kYnkgYW5kIGFjdGl2ZSBkZXZpY2UgaWYgdGhlcmUgYXJlIG1hbnkgc2Vzc2lv bnMgaW4gdGhlIGFjdGl2ZSBkZXZpY2UgLg0KDQpIZW5jZSBhIG1lY2hhbmlzbSBpcyBuZWVkZWQg dG8gc3luYyB0aGUgbWVzc2FnZSBpZCBmaWVsZHMgZnJvbSBhY3RpdmUgZGV2aWNlIHRvIHN0YW5k IGJ5IGRldmljZSBlZmZpY2llbnRseS4NClRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgYSBzb2x1dGlv biBmb3IgdGhpcyBjYXNlDQogDQoNCjIuICBVc2FnZSBTY2VuYXJpb3MNCj09PT09PT09PT09PT09 PT09PT09PT09PQ0KDQogMS4gIFRoaXMgc29sdXRpb24gaXMgcmVxdWlyZWQgaW4gY2FzZSBvZiBI QSBvZiBpa2V2Mi4NCiAyLiAgVGhpcyBpcyBhbHNvIHJlcXVpcmVkIGZvciB0aGUgZGV2aWNlcyB3 aGVuIHRoZXkgYXJlIG91dCBvZiBzeW5jIGFuZCB3aXNoIHRvIGJlIGluIHN5bmMgd2l0aCB0aGUg cGVlci4NCg0KMy4gRGVzY3JpcHRpb24gb2YgdGhlIHNvbHV0aW9uLg0KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KDQoNCkluZm9ybWF0aW9uIHRvIGJlIHN5bmNlZA0KPT09PT09 PT09PT09PT09PT09PT09PT09PT0NCg0KRXZlcnkgZGV2aWNlIHBhcnRpY2lwYXRpbmcgaW4gdGhl IGlrZXYyIGV4Y2hhbmdlIG1haW50YWlucyB0aGUgZm9sbG93aW5nIGluZm9ybWF0aW9uDQoNCjEu IENVUlJfUkVRX01FU1NBR0VfSUQtLSBUaGUgbWVzc2FnZSBpZCBvZiB0aGUgZmlyc3QgcmVxdWVz dCBpbiB0aGUgcGVlciB3aW5kb3cgLCB0aGF0IHRoaXMgZGV2aWNlIHNob3VsZCBzZW5kLiAgDQoy LiBORVhUX1JFUV9NRVNTQUdFX0lELS1UaGUgbWVzc2FnZSBpZCwgIHRoaXMgZGV2aWNlIHdpbGwg dXNlIGluIHRoZSBwYWNrZXQgd2hpbGUgc2VuZGluZyB0aGUgbmV4dCByZXF1ZXN0IHRvIHRoZSBw ZWVyLg0KMy4gUEVFUl9DVVJSX1JFUV9NRVNTQUdFX0lELS1UaGUgbWVzc2FnZSBpZCBvZiB0aGUg Zmlyc3QgcmVxdWVzdCBpbiB0aGUgbXkgd2luZG93LCB3aGljaCBwZWVyIGlzIGV4cGVjdGVkIHRv IHNlbmQgdG8gdGhpcyBkZXZpY2UuDQo0LiBQRUVSX05FWFRfUkVRX01FU1NBR0VfSUQtLVRoZSBt ZXNzYWdlIGlkIHBlZXIgd2lsbCB1c2Ugd2hpbGUgc2VuZGluZyB0aGUgbmV4dCByZXF1ZXN0IHRv IHRoaXMgZGV2aWNlDQo1LiBNWV9XSU5ET1dfU0laRS0tLWxvY2FsIHdpbmRvdyBzaXplLiANCjYu IFBFRVJfV0lORE9XX1NJWkUtLVdpbmRvdyBzaXplIG9mIHRoZSBwZWVyDQoNCkEgcmVxdWVzdCB3 aXRoIG1lc3NhZ2UgaWQgWCAgaXMgbm90IHNlbnQgdG8gdGhlIHBlZXIgd2hlbiBYIGlzIG91dHNp ZGUgdGhlIHJhbmdlIG9mICAoQ1VSUl9SRVFfTUVTU0FHRV9JRCwgQ1VSUl9SRVFfTUVTU0FHRV9J RCArIFBFRVJfV0lORE9XIC0gMSkNCkEgcmVxdWVzdCB3aXRoIG1lc3NhZ2UgSWQgWCAgZnJvbSBw ZWVyIGlzIG5vdCBhY2NlcHRlZCB3aGVuIFggaXMgb3V0c2lkZSB0aGUgcmFuZ2Ugb2YgKFBFRVJf Q1VSUl9SRVFfTUVTU0FHRV9JRCwgUEVFUl9DVVJSX1JFUV9NRVNTQUdFX0lEICsgTVlfV0lORE9X IC0xKQ0KDQooRXhhbXBsZSwgSWYgcGVlciB3aW5kb3cgc2l6ZSBpcyA1IGFuZCBpZiB0aGlzIGRl dmljZSBoYXMgc2VudCByZXF1ZXN0cyAzLCA0LCA1IGFuZCByZWNlaXZlZCByZXNwb25zZXMgb25s eSBmb3IgNCw1ICwgDQpDVVJSX1JFUV9NRVNTQUdFX0lEIHdpbGwgYmUgMyBhbmQgTkVYVF9SRVFf TUVTU0FHRV9JRCB3aWxsIGJlIDYgYW5kIGl0IGNhbiBzZW5kIHJlcXVlc3RzIHdpdGggbWVzc2Fn ZSBpZCdzIHJhbmdpbmcgZnJvbSAzIHRvIDcuIFVwb24gcmVjZWl2aW5nIHRoZQ0KcmVzcG9uc2Ug Zm9yIG1lc3NhZ2UgaWQgMyB0aGUgd2luZG93IHdpbGwgYWR2YW5jZSB0byAgNiAgd2hpY2ggbWVh bnMgaXQgY2FuIHNlbmQgdGhlIHJlcXVlc3Qgd2l0aCBtZXNzYWdlIGlkJ3MgcmFuZ2luZyBmcm9t IDYgdG8gMTAuDQoNCnNpbWlsYXJseSBpZiBsb2NhbCB3aW5kb3cgc2l6ZSBpcyAzLCBhbmQgaWYg cmVxdWVzdCBpcyByZWNlaXZlZCBmcm9tIHBlZXIgd2l0aCBtZXNzYWdlIGlkIGFzIDQgKGFzc3Vt ZSBwZWVyIGhhcyBzZW50IDMgYnV0IHdhcyBsb3N0KSAsIHRoZW4gICwgDQp0aGVuIFBFRVJfQ1VS X1JFUV9NRVNTQUdFX0lEIGlzIDMgYW5kIFBFRVJfTkVYVF9SRVFfTUVTU0FHRV9JRCBpcyA1LCBh bmQgdGhpcyBkZXZpY2UgY2FuIHJlY2VpdmUgcmVxdWVzdHMgZnJvbSAzIHRvIDUuKQ0KDQp3aGVu IHRoZSBhY3RpdmUgc3lzdGVtIGNyYXNoZXMsIHRoZSBzdGFuZCBieSBkZXZpY2UgY2FuIHJlcXVl dHMgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHRoZSBwZWVyIGRldmljZSBhbmQgdXBkYXRlIHRoZSBh Ym92ZSBmaWVsZHMuDQoNClRoZSBpbmZvcm1hdGlvbiBhYm91dCBNWV9XSU5ET1dfU0laRSBhbmQg UEVFUl9XSU5ET1dfU0laRSBuZWVkIG5vdCBiZSBzeW5jZWQgc2luY2UgaXQgaXMgYWxyZWFkeSBw YXNzZWQgdG8gdGhlIHN0YW5kIGJ5IGRldmljZSBhdCB0aGUgdGltZSBvZiANCnN0YW5kLWJ5IGNy ZWF0aW9uIG9mIGluYWN0aXZlIHNhJ3Mgb3IgZHVyaW5nIHJla2V5IHVwZGF0ZXMgZnJvbSBhY3Rp dmUgdG8gc3RhbmRieSBkZXZpY2UuDQoNCg0KU3RhdGVzIG9mIHRoZSBhY3RpdmUgZGV2aWNlIGR1 cmluZyBjcmFzaA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNClRo ZSBDVVJSX1JFUV9NRVNTQUdFX0lEIGFuZCBORVhUX1JFUV9NRVNTQUdFX0lEIG9uIGFjdGl2ZSBk ZXZpY2Ugd291bGQgYmUgUEVFUl9DVVJSX1JFUV9NRVNTQUdFX0lEIGFuZCBQRUVSX05FWFRfUkVR X01FU1NBR0VfSUQNCnJlc3BlY3RpdmVseSBvbiBwZWVyIGFuZCB2aWNlLXZlcnNhIC4gU28gdGhl IHN0YW5kIGJ5IGRldmljZSBmaWVsZHMgYXJlIHVwZGF0ZWQgYWNjb3JkaW5nbHkgYW5kIHRoZW4g dGhlIHN0YXRlIG9mIHRoZSBhY3RpdmUgZGV2aWNlIGF0IA0KdGhlIHRpbWUgb2YgY3Jhc2ggY2Fu IGJlIGVzdGltYXRlZCBhcyBmb2xsb3dzLg0KDQogIDEuIEFmdGVyIHVwZGF0aW9uIE9uIHN0YW5k IGJ5IGRldmljZSAsIGlmIENVUlJfUkVRX01FU1NBR0VfSUQgaXMgZXF1YWwgdG8gTkVYVF9SRVFf TUVTU0FHRV9JRCB0aGVuIG5vIHJlcXVlc3RzIHNlbnQgYnkgdGhlIGFjdGl2ZSBkZXZpY2UgaXMg DQpsb3N0IGFuZCB0aGUgc3RhbmRieSBkZXZpY2UgY2FuIHN0YXJ0IHNlbmRpbmcgcmVxdWVzdHMg d2l0aCBtZXNzYWdlIGlkIENVUlJfUkVRX01FU1NBR0VfSUQuDQoNCiAgMi4gQWZ0ZXIgdXBkYXRp b24gT24gc3RhbmQgYnkgZGV2aWNlICwgSWYgQ1VSUl9SRVFfTUVTU0FHRV9JRCBpcyBub3QgZXF1 YWwgdG8gTkVYVF9SRVFfTUVTU0FHRV9JRCwgdGhlIHBlZXIgZGV2aWNlIGhhcyByZWNlaXZlZA0K IHNvbWUgcmVxdWVzdHMgZnJvbSBhY3RpdmUgZGV2aWNlIGFmdGVyIENVUlJfUkVRX01FU1NBR0Vf SUQsICBidXQgbm90IHdpdGggbWVzc2FnZSBJZCBhcyBDVVJSX1JFUV9NRVNTQUdFX0lELiANCklu IHN1Y2ggY2FzZXMgLCB0aGUgc3RhbmQtYnkgZGV2aWNlIHNob3VsZCBzZW5kIG5leHQgcmVxdWVz dCB3aXRoIENVUlJfUkVRX01FU1NBR0VfSUQgLA0KIGFuZCBzdGFydCBzZW5kaW5nIHRoZSBjb25z ZXF1ZW50IHJlcXVldHMgdG8gdGhlIHBlZXIgd2l0aCBORVhUX0NVUlJfUkVRX01FU1NBR0VfSUQu DQoNCiAgMy4gQWZ0ZXIgdXBkYXRpb24gT24gc3RhbmQgYnkgZGV2aWNlICwgSWYgUEVFUl9DVVJS X1JFUV9NRVNTQUdFX0lEIGlzIGVxdWFsIHRvIFBFRVJfTkVYVF9SRVFfTUVTU0FHRV9JRCB0aGVu ICwgbm8gcmVxdWVzdCBzZW50IGZyb20gdGhlIHBlZXIgaXMgbG9zdC4gDQpzbyB0aGUgc3RhbmQg YnkgZGV2aWNlIGNhbiBhY2NlcHQgdGhlIHJlcXVlc3QgZnJvbSB0aGUgcGVlciBzdGFydGluZyB3 aXRoIG1lc3NhZ2UgaWQgUEVFUl9DVVJSX1JFUV9NRVNTQUdFX0lEIC4NCg0KICA0LiBBZnRlciB1 cGRhdGlvbiBPbiBzdGFuZCBieSBkZXZpY2UgLCBJZiBQRUVSX0NVUlJfUkVRX01FU1NBR0VfSUQg aXMgbm90IGVxdWFsIHRvIFBFRVJfTkVYVF9SRVFfTUVTU0FHRV9JRCwgdGhlbiBwZWVyIGhhcyBz ZW50IGEgDQpyZXF1ZXN0IHRvIHRoZSBhY3RpdmUgZGV2aWNlIHdoaWNoIHdhcyBsb3N0IG9yIHRo ZSByZXNwb25zZSBzZW50IGZyb20gYWN0aXZlIHRvIHRoZSBwZWVyIGRldmljZSB3YXMgbG9zdC4g DQpJbiBlaXRoZXIgY2FzZSBubyBzcGVjaWZpYyBhY3Rpb24gaXMgcmVxdWlyZWQgc2luY2UgcGVl ciB3aWxsIHJldHJhbnNtaXQuDQoNCiAgDQo0LiBFeGNoYW5nZSBmbG93DQo9PT09PT09PT09PT09 PT09PT09PT09PQ0KDQpVcG9uIGNvbmZpZ3VyYXRpb24gdGhlIHJlc3BvbmRlciB3b3VsZCBhbm5v dW5jZSBpdHMgY2FwYWJpbGl0eSBvZiBwcm92aWRpbmcgdGhlIG1lc3NhZ2UgSWQgaW5mbyBhbnl0 aW1lDQpieSBzZW5kaW5nIGEgVklEIHBheWxvYWQgaW4gdGhlIElOSVQgcmVzcG9uc2UuDQoNClRo ZSBpbml0aWF0b3Igd2hpY2ggaGFzIHJlY2VpdmVkIHRoaXMgVklEIHBheWxvYWQgc2hvdWxkIHNl bmQgdGhlIGJlbG93IHJlcXVlc3QgdG8gZ2V0IHRoZSBtZXNzYWdlIA0KSWQgaW5mb3JtYXRpb24g d2hlbiBuZWVkZWQuIFdpdGhvdXQgcmVjZWl2aW5nIHRoaXMgVklEIHBheWxvYWQgaW4gSU5JVCBy ZXNwb25zZSwgDQp0aGUgaW5pdGlhdG9yIE1VU1Qgbm90IHNlbmQgdGhpcyBtZXNzYWdlLiBJZiBh IHJlc3BvbmRlciBnZXRzIHRoaXMgdHlwZSBvZiBleGNoYW5nZSBldmVuIHRob3VnaCBpdCBkaWQg bm90IHNlbmQgdGhlIFZJRCBwYXlsb2FkLA0KdGhlbiBpdCBNVVNUIGRyb3AgdGhpcyBwYWNrZXQg d2l0aCBlcnJvciBJTlZBTElEX1NZTlRBWC4NCg0KSWYgcmVzcG9uZGVyIGRvZXMgbm90IHJlcGx5 IHRvIHRoZSBOb3RpZnkgR0VUX01FU1NBR0VfSURfSU5GTywgZXZlbiB0aG91Z2ggcmVzcG9uZGVy IGhhcyBhbm5vdW5jZWQgaXRzIGNhcGFiaWxpdHkgaW4gVklEIHBheWxvYWQuDQogICB0aGVuIHRo ZSBpbml0aWF0b3IgaW4gdGhpcyBjYXNlIHNob3VsZCByZXRyYW5zbWl0IHRoZSBleGNoYW5nZSBh bmQgZGVsZXRlIHRoZSBTQS4NCg0KSERSLCBTSyB7Tk9USUZZW0dFVF9NRVNTQUdFX0lEX0lORk9d fSAgLS0tLS0tLS0tLS0+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDwtLS0tLS0tLS0tLS0t LS0tLS0tLS1IRFIsIFNLIHsgTk9USUZZW1NFVF9NRVNTQUdFX0lEX0lORk9dfQ0KDQpUaGUgZXhj aGFuZ2UgdHlwZSBmb3IgdGhpcyBtZXNzYWdlIGV4Y2hhbmdlIGlzIFNZTkNfRVhDSEFOR0UuVGhl IHJlYXNvbiBmb3IgdGhlIG5ldyB0eXBlIG9mIGV4Y2hhbmdlIGlzIHRvIGluZGljYXRlIHRvIHRo ZQ0KcmVzcG9uZGVyIHRvIGlnbm9yZSB0aGUgbWVzc2FnZSBJZC4NClRoZSBtZXNzYWdlIGlkIGZv ciB0aGlzIGlzIHplcm8uDQoNClRoZSBpbml0aWF0b3Igb2YgdGhpcyBleGNoYW5nZSBjYW4gdHJp Z2dlciB0aGlzIGFueSB0aW1lIGFmdGVyIHRoZSBTQSBtYXR1cmVzLCB3aGVuIGl0IHdhbnRzIHRv IHN5bmMgdXAgdGhlIG1lc3NhZ2UgSWQgaW5mb3JtYXRpb24gZnJvbSB0aGUgcGVlci4NClRoZSBy ZXNwb25kZXIgdXBvbiByZWNlaXZpbmcgdGhpcyB0eXBlIG9mIGV4Y2hhbmdlIHNob3VsZCBwcm9j ZXNzIHRoZSBtZXNzYWdlIGFuZCBpZ25vcmUgdGhlIG1lc3NhZ2UgaWQgaW4gDQppdHMgd2luZG93 IChiYXNlZCBvbiB0aGUgZXhjaGFuZ2UgdHlwZSkgYW5kIHByb3ZpZGUgdGhlIHJlbGV2YW50IGlu Zm8gdG8gdGhlIHBlZXIuDQoNClRoZSBpbml0aWF0b3IgdXBvbiBnZXRpbmcgdGhlIFNFVF9NRVNT QUdFX0lEX0lORk8gTk9USUZZIHNob3VsZCB1cGRhdGUgdGhlIGZpZWxkcw0KDQo1LiBOZXcgTm90 aWZ5IFR5cGVzDQo9PT09PT09PT09PT09PT09PT09PT09PT0NCg0KMS4gR0VUX01FU1NBR0VfSURf SU5GTy0tIFRoaXMgbm90aWZ5IHdvdWxkIGJlIHNpbWlsYXIgdG8gdGhhdCBvZiBJTklUSUFMX0NP TlRBQ1QgYnV0IHdpdGggTm90aWZ5IG1lc3NhZ2UgdHlwZSBiZWluZyBHRVRfTUVTU0FHRV9JRF9J TkZPDQoNCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rDQogICB8IE5leHQgUGF5bG9hZCAgfEN8ICBSRVNFUlZFRCAgIHwgICAg ICAgICBQYXlsb2FkIExlbmd0aCAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgIFByb3RvY29s IElEICB8ICAgU1BJIFNpemUgICAgfCAgICAgIE5vdGlmeSBNZXNzYWdlIFR5cGUgICAgICB8DQog ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KDQoyLiBTRVRfTUVTU0FHRV9JRF9JTkZPDQoNCistKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8IE5l eHQgUGF5bG9hZCAgfEN8ICBSRVNFUlZFRCAgIHwgICAgICAgICBQYXlsb2FkIExlbmd0aCAgICAg ICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsNCiAgIHwgIFByb3RvY29sIElEICB8ICAgU1BJIFNpemUgICAgfCAg ICAgIE5vdGlmeSBNZXNzYWdlIFR5cGUgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgICAgQ1VS Ul9SRVFfTUVTU0FHRV9JRCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwN CiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8DQogICAgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKw0KICAgfCAgICAgTkVYVF9SRVFfTUVTU0FHRV9JRCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAg KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKw0KICAgfFBFRVJfQ1VSUl9SRVFfTUVTU0FHRV9JRCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKw0KICAgfCAgICAg UEVFUl9ORVhfUkVRX01FU1NBR0VfSUQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8DQogICAgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKw0KDQpDVVJSX1JFUV9NRVNTQUdFX0lEIC0taXMg dGhlIENVUlJfUkVRX01FU1NBR0VfSUQgb24gcGVlciBkZXZpY2UuDQpORVhUX1JFUV9NRVNTQUdF X0lEICAtLSBpcyB0aGUgTkVYVF9SRVFfTUVTU0FHRV9JRCAgIG9uIHBlZXIgZGV2aWNlDQpQRUVS X0NVUlJfUkVRX01FU1NBR0VfSUQgLS1pcyB0aGUgUEVFUl9DVVJSX1JFUV9NRVNTQUdFX0lEIG9u IHBlZXIgZGV2aWNlLg0KUEVFUl9ORVhUX1JFUV9NRVNTQUdFX0lEICAtLSBpcyB0aGUgUEVFUl9O RVhUX1JFUV9NRVNTQUdFX0lEICAgb24gcGVlciBkZXZpY2UNCg0KDQozLiBWZW5kb3IgSWQgUGF5 bG9hZA0KDQpUaGUgVklEIHBheWxvYWQgaXMgYXMgZGVzY3JpYmVkIGluIFtSRkM0MzA2XSB3aXRo IGEgMTYtb2N0ZXRzIGRhdGENCiAgIGZpZWxkIGFzIGZvbGxvd3M6DQoNCiAgICAgICAgICAgICBl MjEzNmU3Y2ZlYzA5ZTFkZGVjODNmODExMzc4YzFhYg0KDQogICBUaGlzIHZhbHVlIHdhcyBvYnRh aW5lZCBieSBoYXNoaW5nIHRoZSBzdHJpbmcgInN5bmMgbWVzc2FnZSBJZCBpbmZvcm1hdGlvbiIg dXNpbmcgdGhlIE1ENSBhbGdvcml0aG1zLg0KDQo2LiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0K PT09PT09PT09PT09PT09PT09PT09PT09PT0NClRoaXMgbWF5IGxlYWQgdG8gRE9TIGF0dGFjayAs IElmIHNvbWUgaGFja2VyIGluIGJldHdlZW4gcmVwbGF5cyB0aGUgc2FtZSBOT1RJRlkgdG8gZ2V0 IHRoZSBpbmZvLg0KSW4gb3JkZXIgdG8gYXZvaWQgdGhpcyB0aGUgcmVzcG9uZGVyIHNpZGUgY2Fu IGJlIGNvbmZpZ3VyZWQgd2l0aCB0aGUgbnVtYmVyIG9mIHRpbWVzIGl0IGNhbiBhY2NlcHQNCiB0 aGlzIHR5cGUgb2YgZXhjaGFuZ2UgZm9yIGFuIFNBLg0KDQo= ------_=_NextPart_001_01CA2C97.67E29C21-- From yaronf@checkpoint.com Thu Sep 3 06:52:18 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D22493A6CC1 for ; Thu, 3 Sep 2009 06:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.342 X-Spam-Level: X-Spam-Status: No, score=-2.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ltD+yWUTTKx for ; Thu, 3 Sep 2009 06:52:15 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 1BE823A6ADF for ; Thu, 3 Sep 2009 06:52:11 -0700 (PDT) X-CheckPoint: {4A9FC948-2-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 9CB3729C004; Thu, 3 Sep 2009 16:51:05 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 869D329C002 for ; Thu, 3 Sep 2009 16:51:05 +0300 (IDT) X-CheckPoint: {4A9FC948-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n83Dp43Q005403 for ; Thu, 3 Sep 2009 16:51:04 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 3 Sep 2009 16:51:02 +0300 From: Yaron Sheffer To: IPsecme WG Date: Thu, 3 Sep 2009 16:51:02 +0300 Thread-Topic: Last Call: draft-ietf-rohc-hcoipsec (Integration of Robust Header Compression (ROHC) over IPsec Security Associations) to Informational RFC Thread-Index: AcosnTMJGQKtVrMTQ5i1Q93runZR+wAADf6w Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190A978F0E8@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_010D_01CA2CB6.B8583920" MIME-Version: 1.0 Subject: [IPsec] FW: Last Call: draft-ietf-rohc-hcoipsec (Integration of Robust Header Compression (ROHC) over IPsec Security Associations) to Informational RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 13:52:18 -0000 ------=_NextPart_000_010D_01CA2CB6.B8583920 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: Thursday, September 03, 2009 16:47 To: IETF-Announce Cc: rohc@ietf.org Subject: Last Call: draft-ietf-rohc-hcoipsec (Integration of Robust Header Compression (ROHC) over IPsec Security Associations) to Informational RFC The IESG has received a request from the Robust Header Compression WG (rohc) to consider the following document: - 'Integration of Robust Header Compression (ROHC) over IPsec Security Associations ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-09-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-rohc-hcoipsec-11.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=1400 2&rfc_flag=0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce Scanned by Check Point Total Security Gateway. ------=_NextPart_000_010D_01CA2CB6.B8583920 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDkwMzEzNTEwMlowIwYJKoZIhvcNAQkEMRYEFAs+++W+pqBu YErsvPiK8KIf979tMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA tupyq3IvReXnJgE3u8s3u2AvFlS2d2PmkJ08cGdX5xfeHQPwKW/o3N0A/gc7p5+fFhSV+iDqzIe2 3FGYft5+wpX5S7rWf9t9Q6U4+6cNV+RkizN8RM0gfBeQTdsfvthaz2BYCLNkk8QV2e9NB76oVZxQ 2Kd6EuDZG8Sh025DDcpHT8uDvt59HACaSYzK+bex1M9uvBy5DEOKNJc9trlruwZYlny5iw0y+OfD h1YBbUIIF9AY3oWXjUWAZfOssbvZeBmEBi0d0WAPKwbzaFl/yZeXqgIO9/5ydzM2GLfernAfw8Db SYSELArzol5UpAi3Z1PGTU+ynmWJcsLxyIh63wAAAAAAAA== ------=_NextPart_000_010D_01CA2CB6.B8583920-- From jsun2501@gmail.com Thu Sep 3 06:53:33 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EAAE28C107 for ; Thu, 3 Sep 2009 06:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9oOSJ7gzqh9 for ; Thu, 3 Sep 2009 06:53:32 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 2C6803A6A46 for ; Thu, 3 Sep 2009 06:53:30 -0700 (PDT) Received: by ewy3 with SMTP id 3so341574ewy.42 for ; Thu, 03 Sep 2009 06:52:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=OZNg+M5eoxJJ8aGtYnBFJH4UCcYiG1AEIgZIduGt0Jc=; b=HKQdwYjxF2VgbH5Jk1BLpeS4NQ24Fc7UiLp93z4UL2RChZRuoLoKkKe+SgDDa5aUta LmkLGdoCtD0726JQbRGSy1f4pGN9LCYHaH847tULnbOOQIZ1uGfOjxgdtzlZxAowChlN OKlOg8HkDjACpEiYpExiFO4mXTEQ3nb9QmDhs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=GBjLonPAEsSnwnPb+hq60HPr0oFmmdN28Sa3mC8B73+cYS/pNmmeGDTMTE/BH68LP3 +JUqHJfXgwWhOldZIKTHDpkuWya+JwdTr+NyCzXf7teZB6YyytbEaWdKNy9zWDhk/mcs LpWz42iY89uYbJIjkQpv+V/l7MqVTw8351xoc= MIME-Version: 1.0 Received: by 10.211.152.15 with SMTP id e15mr9731895ebo.30.1251985618666; Thu, 03 Sep 2009 06:46:58 -0700 (PDT) In-Reply-To: <19102.26763.522570.187181@fireball.kivinen.iki.fi> References: <19102.26763.522570.187181@fireball.kivinen.iki.fi> Date: Thu, 3 Sep 2009 06:46:58 -0700 Message-ID: <7d660a970909030646s3946490eu7add089cf7dae87b@mail.gmail.com> From: Jeff Sun To: Tero Kivinen Content-Type: multipart/alternative; boundary=0015174c3c921086610472ac9e90 Cc: ipsec@ietf.org, naoyoshi ueda Subject: Re: [IPsec] Questions to IKEv2bis draft: IVs of retransmitted packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 13:53:33 -0000 --0015174c3c921086610472ac9e90 Content-Type: text/plain; charset=ISO-8859-1 All in all, the qualifications of being a true retransmitted IKE request/response message is dependent on the* post-encrypted* IKE request/response message being bitwise identical. Naoyoshi, if you don't mind me asking, which implementation are observing this behavior from (I'm not sure if this breaks any rules of engagement of mailing list, so please respond privately to me if possible)? - Jeff Sun On Wed, Sep 2, 2009 at 5:43 AM, Tero Kivinen wrote: > naoyoshi ueda writes: > > According to ikev2bis-04 section 2.1: > > > A retransmission from the initiator > > > MUST be bitwise identical to the original request. That is, > > > everything starting from the IKE Header (the IKE SA Initiator's SPI > > > onwards) must be bitwise identical; items before it (such as the IP > > > and UDP headers, and the zero non-ESP marker) do not have to be > > > identical. > > > > So, IV of retransmitted request must be the same as that of original > > request. > > Yes. > > > Meanwhile, ikev2bis-04 section 3.14 says > > > o Initialization Vector - For CBC mode ciphers, the length of the > > > initialization vector (IV) is equal to the block length of the > > > underlying encryption algorithm. Senders MUST select a new > > > unpredictable IV for every message; recipients MUST accept any > > > value. > > > > Question 1: > > Does the statement "recipients MUST accept any value." stay true > > even if retransmitted IV differs from that of original request? > > Most likely, but it does not matter as the packet will fail window > check, thus will be considered as retransmission or old packet, and > thrown away (it might trigger retransmission of responders reply in > case it was packet in the window). > > Note, that this can only happen if the other is non-conforming, or > there is attacker between which modifies the IV. Conforming > implementation will use same IV all time. > > > Question 2: > > If the answer to Question 1 is no, what should the recipient do? > > Just ignore it? Abandon the IKE_SA? Or send some Notify? > > If recipient has already seen the message before (i.e it has already > processed it), it can resend its reply. It can also notice that the > packet is not bitwise-same as previously and the message id is old, > and silently ignore it. So this is implementation depended what will > happen. > > If it has not seen the message before, then it does not know the IV > has changed, thus will process the packet normally. > > > Question 3: > > How about IV of retransmitted RESPONSE? > > Does it need to be identical to the original one too? > > The retransmitted response should also be bitwise identical to > original one. > > > It seems to me that the following statement in section 2.1 > > implicitly requires that. But I'm not sure. > > I would agree you that it implicitly requires that. > > > Actually, I'm now involved in a IKEv2 implementation that > > sends retransmitted response with different IV from original one > > and I cannot tell if the behavior is allowed or not. > > I would say it is not allowed, but on the other hand, the other end > should not ever notice this, as it only process one of the responses > (the first to reach him), and then ignores rest even before decrypting > them (when it checks its message id). I.e. it ignores further > responses to requests it has already received response. > > > ikev2bis-04 section 2.1: > > > The responder MUST remember each > > > response until it receives a request whose sequence number is larger > > > than or equal to the sequence number in the response plus its window > > > size (see Section 2.3). > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- For relaxing times, make it Suntory time. - Bob Harris, Lost in Translation --0015174c3c921086610472ac9e90 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All in all, the qualifications of being a true retransmitted IKE request/re= sponse message is dependent on the post-encrypted IKE request/respon= se message being bitwise identical.=A0 Naoyoshi, if you don't mind me a= sking, which implementation are observing this behavior from (I'm not s= ure if this breaks any rules of engagement of mailing list, so please respo= nd privately to me if possible)?

- Jeff Sun

On Wed, Sep 2, 2009 at 5:4= 3 AM, Tero Kivinen <= kivinen@iki.fi> wrote:
naoyoshi ueda writes:
> According to ikev2bis-04 section 2.1:
> > =A0 A retransmission from the initiator
> > =A0 MUST be bitwise identical to the original request. =A0That is= ,
> > =A0 everything starting from the IKE Header (the IKE SA Initiator= 's SPI
> > =A0 onwards) must be bitwise identical; items before it (such as = the IP
> > =A0 and UDP headers, and the zero non-ESP marker) do not have to = be
> > =A0 identical.
>
> So, IV of retransmitted request must be the same as that of original > request.

Yes.

> Meanwhile, =A0ikev2bis-04 section 3.14 says
> > =A0 o =A0Initialization Vector - For CBC mode ciphers, the length= of the
> > =A0 =A0 =A0initialization vector (IV) is equal to the block lengt= h of the
> > =A0 =A0 =A0underlying encryption algorithm. =A0Senders MUST selec= t a new
> > =A0 =A0 =A0unpredictable IV for every message; recipients MUST ac= cept any
> > =A0 =A0 =A0value.
>
> Question 1:
> Does the statement "recipients MUST accept any value." stay = true
> even if retransmitted IV differs from that of original request?

Most likely, but it does not matter as the packet will fail window check, thus will be considered as retransmission or old packet, and
thrown away (it might trigger retransmission of responders reply in
case it was packet in the window).

Note, that this can only happen if the other is non-conforming, or
there is attacker between which modifies the IV. Conforming
implementation will use same IV all time.

> Question 2:
> If the answer to Question 1 is no, what should the recipient do?
> Just ignore it? Abandon the IKE_SA? Or send some Notify?

If recipient has already seen the message before (i.e it has already<= br> processed it), it can resend its reply. It can also notice that the
packet is not bitwise-same as previously and the message id is old,
and silently ignore it. So this is implementation depended what will
happen.

If it has not seen the message before, then it does not know the IV
has changed, thus will process the packet normally.

> Question 3:
> How about IV of retransmitted RESPONSE?
> Does it need to be identical to the original one too?

The retransmitted response should also be bitwise identical to
original one.

> It seems to me that the following statement in section 2.1
> implicitly requires that. But I'm not sure.

I would agree you that it implicitly requires that.

> Actually, I'm now involved in a IKEv2 implementation that
> sends retransmitted response with different IV from original one
> and I cannot tell if the behavior is allowed or not.

I would say it is not allowed, but on the other hand, the other end should not ever notice this, as it only process one of the responses
(the first to reach him), and then ignores rest even before decrypting
them (when it checks its message id). I.e. it ignores further
responses to requests it has already received response.

> ikev2bis-04 section 2.1:
> > =A0 The responder MUST remember each
> > =A0 response until it receives a request whose sequence number is= larger
> > =A0 than or equal to the sequence number in the response plus its= window
> > =A0 size (see Section 2.3).
--
kivinen@iki.fi
__________________________________= _____________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec



--
For relaxin= g times, make it Suntory time. - Bob Harris, Lost in Translation
--0015174c3c921086610472ac9e90-- From peng.yang.chn@gmail.com Thu Sep 3 06:57:41 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEE2A3A6C61; Thu, 3 Sep 2009 06:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mntx1hvWKd0b; Thu, 3 Sep 2009 06:57:40 -0700 (PDT) Received: from mail-px0-f185.google.com (mail-px0-f185.google.com [209.85.216.185]) by core3.amsl.com (Postfix) with ESMTP id 6E3DF3A67D3; Thu, 3 Sep 2009 06:57:40 -0700 (PDT) Received: by pxi15 with SMTP id 15so1642882pxi.23 for ; Thu, 03 Sep 2009 06:57:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XuCl+ujuEEQn4peD5HVV+vqyKQ4Jt4ItkokXZH5E7bk=; b=Tz4/k7zvJHXWQIjWvRCUfMTogrcoA979/PRstG0IL5zcowiqG+MosVc33VfwcCbDU0 2CsDxD6nyBp4dtTu/c/ruFH7l6biNpqmLghBEwhmHGsNmXOVKfNTFUeQfwBGBEYwGNUl AeaDIYoiEd4raqA2fv9nFK2ZpmTsDMIeOsTAU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=bbNsvowjWyt5+r0kkGKlA4G06AFP9zbDWVTFL75PCsGP/Vi7sNDR/Pv5/33BDd7Vjh bzRC3rSFCqz2Mc+79lODc6ir1V86RZe92XlkAgF7k3XNf/d5qVPZHm50r8oPkD16lvs5 2jh4RW11iHWtdwii+VXxF7PKueglzNjVja0hY= MIME-Version: 1.0 Received: by 10.141.37.10 with SMTP id p10mr2843438rvj.284.1251986251084; Thu, 03 Sep 2009 06:57:31 -0700 (PDT) In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190A978EFBE@il-ex01.ad.checkpoint.com> References: <20090831140935.4752B3A6E46@core3.amsl.com> <4c5c7a6d0909011932g74decc2dq1ae2cb61b78b2b0a@mail.gmail.com> <4c5c7a6d0909020717r72ee57btaaa9bdafd39a12cd@mail.gmail.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80190A978EFBE@il-ex01.ad.checkpoint.com> Date: Thu, 3 Sep 2009 21:57:31 +0800 Message-ID: <4c5c7a6d0909030657m3ed1586fw509e029c650e3574@mail.gmail.com> From: Peny Yang To: Yaron Sheffer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPsecme WG , "ietf@ietf.org" Subject: Re: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 13:57:41 -0000 Hi, Yaron: Please check my response inlines: BRG Peny 2009/9/3 Yaron Sheffer : > Hi Peny, > > Thank you for reviewing this draft. Please see my comments below. > > Regards, > =A0 =A0 =A0 =A0Yaron > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf O= f >> Peny Yang >> Sent: Wednesday, September 02, 2009 17:18 >> To: ietf@ietf.org >> Cc: IPsecme WG >> Subject: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption >> (IKEv2 Session Resumption) to Proposed Standard >> >> Sorry, I should cc IPsec mail list. Comments are sent again. >> >> Hi, floks: >> >> I have two comments on the draft of IKEv2 Session Resumption: >> >> 1) Sorry, I have to talk about my concern on the new >> IKE_SESSION_RESUME. In WG last call, actually I made this comment. >> However, no feedback was given, maybe because my comment was a little >> late for WG last call. So, I just copy it here again as a comment for >> IESG last call. >> >> Well, =A0we've discussed pros and cons of IKE_SA_INIT and >> IKE_SESSION_RESUME for quite a long time. However, IMHO, the consensus >> is still not fully achieved on this item. So far, I still prefer to >> choosing extended IKE_SA_INIT for ticket presenting. This solution is >> specified in http://tools.ietf.org/html/draft-xu-ike-sa-sync-01 >> >> As a summary, the virtues are as follows: >> - RFC5077 (TLS session resumption) also uses the similar scheme, which >> extends the message of clienthello with session ticket extension. The >> extended IKE_SA_INIT solution has the similar way. It's easy to extend >> the base IKEv2 protocol stack to support session resumption. >> - Considering the case of failing session resumption, the extended >> IKE_SA_INIT solution can save one round trip. >> - As indicated in 4.3.3 IKE_AUTH exchange, IKE_AUTH must be initiated >> after IKE_SESSION_RESUME. In this sense, the extended IKE_SA_INIT way >> need less code to be supported compared with IKE_SESSION_RESUME. >> >> The down side: >> - some people thought the way of extended IKE_SA_INIT will make the >> base IKEv2 protocol stack more complex. IMHO, it's an issue of >> implementation. >> Again, I still support to use extended IKE_SA_INIT for ticket >> presenting instead of IKE_SESSION_RESUME. > [YS] I see the merits of extending IKE_SA_INIT to support resumption, and= in > fact an early version of our work did exactly that. But the working group > gave us a clear direction to use a separate exchange >, and this is where we > disagree: I believe we did have a strong WG consensus that the > implementation benefits of having a separate exchange (i.e.) outweigh the= benefits of the > alternative. [Peny] I know WG chair have the right to judge "rough consensus". However, I can't agree that IPsecme WG has achieved the so called "strong consensus" on this issue. Maybe IESG can further judge it. I also can't agree "benefits of having a separate exchange outweigh the benefits of the alternative". Actually, we didn't achieve consensus on it yet. > not overloading even more the non-trivial IKE_SA_INIT exchange [Peny] I am sorry. I just can't see any evidence that the solution of extending IKE_SA_INIT extension will *OVERLOAD* current IKE_SA_INIT exchange? Or I missed something? > >> 2) Maybe I missed some discussions. >> There is the case: responder may receives a ticket for an IKE SA that >> is still active and if the responder accepts it. In one of previous >> versions of this draft, there once was some description on this case. > > [YS] I believe you are referring to the text now in Sec. 4.3.4. [Peny] OK. This is the part I referred to. But, it can't deal with the issue when IPsec client *continuously* believes failure of gateway. > >> I know that how a client detects the need for resumption is out of the >> scope of this draft. But, there is the possibility that IPsec client >> may be continuously deceived and believe the fail of IPsec gateway. It >> may continuously present the ticket and update the ticket. In this >> sense, IMHO, this draft should take care of this case. >> > [YS] If I understand the scenario correctly, it is similar to an attacker > repeatedly sending notifications to an IKE client, making it believe that > the IKE exchange has failed and needs to be reinitiated. [Peny] Well, this case may not cause this problem. If attacker has IPsec connection with the client, the client will only believe the attacker fails, not Gateway. Here is one of the cases. Sometimes, temporary unavailability of network access may also cause this problem. For example, in mobile network, mobile terminals may lose radio resources in some time. In this situation, all the packets outward of client will be timeout. Then IKEv2 protocol stack has the possibility to believe failure of gateway. It will send one or more message to initiate the session resumption. However, as far as I know, many cellular card now will not discard the packets when radio resources lose for a while. It will buffer the packets and send them out when radio resources are available. > This attack against > plain-vanilla IKE would be much more CPU-intensive to the client and to t= he > (real) gateway, compared to repeated session resumption. [Peny] Well, I see your logic. Basically, even if gateway may not be overloaded, it does not mean gateway will do something in vain. > Even when you > factor in the cost of generating a new ticket. Moreover, the regular IKEv= 2 > anti-DOS cookie mechanism is supported by IKE_SESSION_RESUME as well. [Peny] I did not mean this. Sorry for some confusing. >> >> On Mon, Aug 31, 2009 at 10:09 PM, The IESG wrot= e: >> > The IESG has received a request from the IP Security Maintenance and >> > Extensions WG (ipsecme) to consider the following document: >> > >> > - 'IKEv2 Session Resumption ' >> > =A0 as a Proposed Standar= d >> > >> > The IESG plans to make a decision in the next few weeks, and solicits >> > final comments on this action. =A0Please send substantive comments to = the >> > ietf@ietf.org mailing lists by 2009-09-14. Exceptionally, >> > comments may be sent to iesg@ietf.org instead. In either case, please >> > retain the beginning of the Subject line to allow automated sorting. >> > >> > The file can be obtained via >> > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-resumptio= n- >> 07.txt >> > >> > >> > IESG discussion can be tracked via >> > >> https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTa= g=3D17 >> 990&rfc_flag=3D0 >> > >> > _______________________________________________ >> > IPsec mailing list >> > IPsec@ietf.org >> > https://www.ietf.org/mailman/listinfo/ipsec >> > >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> Scanned by Check Point Total Security Gateway. > From yaronf@checkpoint.com Thu Sep 3 06:57:49 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D8F828C17E for ; Thu, 3 Sep 2009 06:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8eFvIvdHqCb for ; Thu, 3 Sep 2009 06:57:48 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id EDA1328C1B4 for ; Thu, 3 Sep 2009 06:57:47 -0700 (PDT) X-CheckPoint: {4A9FCAD4-2-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 151C029C004; Thu, 3 Sep 2009 16:57:42 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 0075029C002 for ; Thu, 3 Sep 2009 16:57:41 +0300 (IDT) X-CheckPoint: {4A9FCAD4-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n83Dvf3P007250 for ; Thu, 3 Sep 2009 16:57:41 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 3 Sep 2009 16:57:39 +0300 From: Yaron Sheffer To: IPsecme WG Date: Thu, 3 Sep 2009 16:57:39 +0300 Thread-Topic: Last Call: draft-ietf-rohc-ikev2-extensions-hcoipsec (IKEv2 Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec)) to Proposed Standard Thread-Index: AcosnZYNc/6FW4JqQQOkQyAMKcOjXwAAOV+A Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190A978F0EB@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0117_01CA2CB7.A529AE50" MIME-Version: 1.0 Subject: [IPsec] FW: Last Call: draft-ietf-rohc-ikev2-extensions-hcoipsec (IKEv2 Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec)) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 13:57:49 -0000 ------=_NextPart_000_0117_01CA2CB7.A529AE50 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: Thursday, September 03, 2009 16:47 To: IETF-Announce Cc: rohc@ietf.org Subject: Last Call: draft-ietf-rohc-ikev2-extensions-hcoipsec (IKEv2 Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec)) to Proposed Standard The IESG has received a request from the Robust Header Compression WG (rohc) to consider the following document: - 'IKEv2 Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-09-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-rohc-ikev2-extensions-hcoipse c-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=1520 6&rfc_flag=0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0117_01CA2CB7.A529AE50 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDkwMzEzNTczOVowIwYJKoZIhvcNAQkEMRYEFNuR4a/19J8Z Zqs//h71L9EdOCc7MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA jJf4jXlCVyzxokyHjX4VmLiNwfVBKAjiRyWwFbCGPEgBT8TFmmbgaidBNHlB0bVM9BeYY15mvTnL IrUolGIgEcFbrTrkSsC1fPN7Vjnb5wUIKXI1vC5cEyK1Iz3JVUpCAQbwuOQVN30Q1VWLDAvUlZ1x hi4G/gMXyvOtUZ/5QEE89PzBxUvEXH914/WvYTP0HCGVqt5LnZWLo4RPHbfjZAa4aqOTDPN07DXS 1B/Gvxd1LvJ4HWyHcfyt8GgBAkhdmH2mkPiS9aVQI19eWY5zJnwl5QFxtBAtx1aPb8vXAgftrqoP WakBt2xXRDmriP7STQKsxfon1o3fBKQSzgmpJwAAAAAAAA== ------=_NextPart_000_0117_01CA2CB7.A529AE50-- From yaronf@checkpoint.com Thu Sep 3 06:57:59 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DED433A67F7 for ; Thu, 3 Sep 2009 06:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lu0kMqcok1v0 for ; Thu, 3 Sep 2009 06:57:59 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 40BF23A6895 for ; Thu, 3 Sep 2009 06:57:58 -0700 (PDT) X-CheckPoint: {4A9FCAE0-2-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 0FBB029C005; Thu, 3 Sep 2009 16:57:54 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id EEEC329C002 for ; Thu, 3 Sep 2009 16:57:53 +0300 (IDT) X-CheckPoint: {4A9FCAE0-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n83Dvr3P007293 for ; Thu, 3 Sep 2009 16:57:53 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 3 Sep 2009 16:57:51 +0300 From: Yaron Sheffer To: IPsecme WG Date: Thu, 3 Sep 2009 16:57:51 +0300 Thread-Topic: Last Call: draft-ietf-rohc-ipsec-extensions-hcoipsec (IPsec Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec)) to Proposed Standard Thread-Index: AcosnlcetDlLrMBBQCKaYp4tPqyrNgAACsfg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190A978F0EC@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_011C_01CA2CB7.AC7952F0" MIME-Version: 1.0 Subject: [IPsec] FW: Last Call: draft-ietf-rohc-ipsec-extensions-hcoipsec (IPsec Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec)) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 13:58:00 -0000 ------=_NextPart_000_011C_01CA2CB7.AC7952F0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: Thursday, September 03, 2009 16:48 To: IETF-Announce Cc: rohc@ietf.org Subject: Last Call: draft-ietf-rohc-ipsec-extensions-hcoipsec (IPsec Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec)) to Proposed Standard The IESG has received a request from the Robust Header Compression WG (rohc) to consider the following document: - 'IPsec Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-09-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-rohc-ipsec-extensions-hcoipse c-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=1640 9&rfc_flag=0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce Scanned by Check Point Total Security Gateway. ------=_NextPart_000_011C_01CA2CB7.AC7952F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDkwMzEzNTc1MVowIwYJKoZIhvcNAQkEMRYEFJozM5LEEZCL PHVOZVxK69LKnrKcMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA dzWXPinEj2nHF8pAmnKi0c6fB76aOUhqSDysl4OcqmttrZsacOUtliQ+ZN+PBtzaYT0GX13/7qJp E73dMZ6WedwCfBU+4tt4SEWH9CM7XrOANHxxjyNjxMvgzOkgbciJwFQwl+k4rEeBfyCeEK3rpyQV 4YRSXZTl6XEJs6H2r5qJpUOwfQQT+AkX7UU4W3LOgnzMq1znps20M5qEf2W2Vki77Ni60NzsBI/x WicNk8l0MUmR5QbgpKQTIBkcWVncpn4xi8slPPJsq/sc9vPUMde3EXqUewqBhjSoCwc+ZxE1G1ho FtsQsWYV7hRheWRIIat34lzENFsaQG3G/Pl/OwAAAAAAAA== ------=_NextPart_000_011C_01CA2CB7.AC7952F0-- From paul.hoffman@vpnc.org Thu Sep 3 07:02:01 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D14D03A69B5 for ; Thu, 3 Sep 2009 07:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.046 X-Spam-Level: X-Spam-Status: No, score=-106.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vrZQKfHta+T for ; Thu, 3 Sep 2009 07:02:01 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 954B83A6D17 for ; Thu, 3 Sep 2009 07:01:50 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n83E0tLp098413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 3 Sep 2009 07:00:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 3 Sep 2009 07:00:41 -0700 To: IPsecme WG From: The IESG (by way of Paul Hoffman) Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Last Call: draft-ietf-rohc-hcoipsec (Integration of Robust Header Compression (ROHC) over IPsec Security Associations) to Informational RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 14:02:02 -0000 The IESG has received a request from the Robust Header Compression WG (rohc) to consider the following document: - 'Integration of Robust Header Compression (ROHC) over IPsec Security Associations ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-09-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-rohc-hcoipsec-11.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14002&rfc_flag=0 From paul.hoffman@vpnc.org Thu Sep 3 07:02:01 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8C603A6B8A for ; Thu, 3 Sep 2009 07:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.046 X-Spam-Level: X-Spam-Status: No, score=-106.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xZdZoBnXcxA for ; Thu, 3 Sep 2009 07:02:01 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id B6D693A6D15 for ; Thu, 3 Sep 2009 07:01:46 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n83E0tLr098413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 3 Sep 2009 07:00:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 3 Sep 2009 07:00:53 -0700 To: IPsecme WG From: The IESG (by way of Paul Hoffman) Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Last Call: draft-ietf-rohc-ikev2-extensions-hcoipsec (IKEv2 Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec)) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 14:02:02 -0000 The IESG has received a request from the Robust Header Compression WG (rohc) to consider the following document: - 'IKEv2 Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-09-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-rohc-ikev2-extensions-hcoipsec-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15206&rfc_flag=0 From wierbows@us.ibm.com Thu Sep 3 07:14:17 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15D3A28C213 for ; Thu, 3 Sep 2009 07:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=-0.934, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByvLasB49abr for ; Thu, 3 Sep 2009 07:14:16 -0700 (PDT) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by core3.amsl.com (Postfix) with ESMTP id 1EA9D28C210 for ; Thu, 3 Sep 2009 07:14:16 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e7.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n83E0Fmd005969 for ; Thu, 3 Sep 2009 10:00:15 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n83E1jet168434 for ; Thu, 3 Sep 2009 10:01:46 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n83E1hWg029062 for ; Thu, 3 Sep 2009 10:01:44 -0400 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n83E1eZR028645 for ; Thu, 3 Sep 2009 10:01:42 -0400 In-Reply-To: <19103.34279.253359.922428@fireball.kivinen.iki.fi> References: <19101.10929.181733.7940@fireball.kivinen.iki.fi> <19102.25856.800410.560288@fireball.kivinen.iki.fi> <19103.34279.253359.922428@fireball.kivinen.iki.fi> X-KeepSent: 43F6E242:E99F2744-85257626:004B158E; type=4; name=$KeepSent To: "ipsec@ietf.org WG" X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: David Wierbowski Date: Thu, 3 Sep 2009 10:01:25 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 09/03/2009 10:01:41 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBFCB5DFD8931E8f9e8a93df938690918c0ABBFCB5DFD8931E" Content-Disposition: inline Subject: Re: [IPsec] CRL checking when selecting a certifcate X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 14:14:17 -0000 --0__=0ABBFCB5DFD8931E8f9e8a93df938690918c0ABBFCB5DFD8931E Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Tero, thanks for the comments and the clarification on how to read a lo= wer case must. I do have a few more comments. >So implementations cannot just search uppercase "MUST/SHOULD/MAY" >texts and assume it is enough to make sure those are correct. It also >needs to do what the text says... > I think most implementers focus on the MUST and SHOULDs and then apply common sense to the remaining text. >> CRL checking is not cheap and >> performing CRL checking when selecting a certificate seems like an optional >> usability feature to me. > >The you probably want to make change to the current text which says >you must do it... Correct. I think when selecting a certificate that consulting revocati= on information is a lower case should or could at best. I agree that on t= he accepting side a lower case must is appropriate for revocation checking= from an interoperability perspective. By that I mean the failure to do= so will not hinder interoperability, but from a security perspective it re= ally should be done. Dave Wierbowski z/OS Comm Server Developer Phone: Tie line: 620-4055 External: 607-429-4055 = --0__=0ABBFCB5DFD8931E8f9e8a93df938690918c0ABBFCB5DFD8931E Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Tero, thanks for the comments and the clarification on how to re= ad a lower case must.  I do have a few more comments.

>So implementations cannot just search uppercase "MUST/SHOU= LD/MAY"
>texts and assume it is enough to make sure those are correct. It al= so
>needs to do what the text says...
>
I think most implementers focus on the MUST and SHOULDs and then ap= ply common sense to the remaining text.

>> CRL checking is not cheap and
>> performing CRL checking when selecting a certificate seems lik= e an optional
>> usability feature to me.
>
>The you probably want to make change to the current text which says=
>you must do it...
Correct.  I think when selecting a certificate that consulting= revocation information is a lower case should or could at best.  = I agree that on the accepting side a lower case must is appropriate for= revocation checking from an interoperability perspective. &nb= sp;By that I mean the failure to do so will not hinder interoperability= , but from a security perspective it really should be done.


Dave Wierbowski


z/OS Comm Server Developer

Phone:
Tie line: 620-4055
External: 607-429-4055

= --0__=0ABBFCB5DFD8931E8f9e8a93df938690918c0ABBFCB5DFD8931E-- From peng.yang.chn@gmail.com Thu Sep 3 07:41:14 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C6983A6D3F; Thu, 3 Sep 2009 07:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5P00Sa3LIo3; Thu, 3 Sep 2009 07:41:12 -0700 (PDT) Received: from mail-pz0-f194.google.com (mail-pz0-f194.google.com [209.85.222.194]) by core3.amsl.com (Postfix) with ESMTP id 56CE03A6D30; Thu, 3 Sep 2009 07:41:12 -0700 (PDT) Received: by pzk32 with SMTP id 32so1744802pzk.33 for ; Thu, 03 Sep 2009 07:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=n3EPug0oB+ojd+lp9/eFiPKvEgGFxfWPxuc25zUek1I=; b=STQ8PzHJPmjVU1VchPumCb3Pyi/6/5r0jT4+YvlwUC5db/n/N41S0oBoldBHCLj3/V rjQDue9WVddAzepi4CfW2qREoaToVE8Zg6dUqn1QLO6iN6xFy2edbRi2N3esYS4YeqtJ P8YKmugIv2iz9cwbbDZ8WKmj7sgYaT28aV5T8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dhA2jPsJk7RU/ZeVSEnW47adGODtMM9tMxDTU9btURJdIWLQo3NicAuPT65DgD0PQV 1ocKByTmzv1Xk031OsqPUk8pJQiven4ds5yDUSB2E4dPkdO4UdK/+letnVmW8ej6IjAu 6J2Ojvxy5BJPu6TwVabYWpfIveKm6DlJr+vn0= MIME-Version: 1.0 Received: by 10.141.34.9 with SMTP id m9mr2891211rvj.84.1251986900311; Thu, 03 Sep 2009 07:08:20 -0700 (PDT) In-Reply-To: <19103.34893.896574.218235@fireball.kivinen.iki.fi> References: <20090831140935.4752B3A6E46@core3.amsl.com> <4c5c7a6d0909011932g74decc2dq1ae2cb61b78b2b0a@mail.gmail.com> <4c5c7a6d0909020717r72ee57btaaa9bdafd39a12cd@mail.gmail.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80190A978EFBE@il-ex01.ad.checkpoint.com> <19103.34893.896574.218235@fireball.kivinen.iki.fi> Date: Thu, 3 Sep 2009 22:08:20 +0800 Message-ID: <4c5c7a6d0909030708x6c77845fj57bd740f332c3b06@mail.gmail.com> From: Peny Yang To: Tero Kivinen Content-Type: text/plain; charset=ISO-8859-1 Cc: IPsecme WG , "ietf@ietf.org" Subject: Re: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 14:41:14 -0000 On Thu, Sep 3, 2009 at 5:11 PM, Tero Kivinen wrote: > Yaron Sheffer writes: >> [YS] I see the merits of extending IKE_SA_INIT to support resumption, and in >> fact an early version of our work did exactly that. But the working group >> gave us a clear direction to use a separate exchange, and this is where we >> disagree: I believe we did have a strong WG consensus that the >> implementation benefits of having a separate exchange (i.e. not overloading >> even more the non-trivial IKE_SA_INIT exchange) outweigh the benefits of the >> alternative. > > I agree on that (both to the WG having consensus and also that using > separate exchange is better). >> > I know that how a client detects the need for resumption is out of the >> > scope of this draft. But, there is the possibility that IPsec client >> > may be continuously deceived and believe the fail of IPsec gateway. It >> > may continuously present the ticket and update the ticket. In this >> > sense, IMHO, this draft should take care of this case. >> > >> [YS] If I understand the scenario correctly, it is similar to an attacker >> repeatedly sending notifications to an IKE client, making it believe that >> the IKE exchange has failed and needs to be reinitiated. This attack against >> plain-vanilla IKE would be much more CPU-intensive to the client and to the >> (real) gateway, compared to repeated session resumption. Even when you >> factor in the cost of generating a new ticket. Moreover, the regular IKEv2 >> anti-DOS cookie mechanism is supported by IKE_SESSION_RESUME as well. > > Regardless what notifications or ICMP messages you send to any of the > IKE end points that MUST NOT cause them to consider IKE SA failed. It > "MUST conclude that the other endpoind has failed only when repeated > attemtps to contact it have gone unanswered for timeout period or when > a cryptographically protected INITIAL_CONTACT notification is received > on a different IKE SA to the same authenticated identity." (RFC 4306 > section 2.4) > > Notifications and ICMP messages may trigger other end to send empty > INFORMATIONAL message to check whether the other end is alive or not > and only if that times out then the other end is considered dead. > > This means this kind of attack is not possible with notifications and > ICMP. [Peny] Agree. I did not mean this kind of attacking originally. > > On the other hand I do agree with Peny that, as resumption draft makes > it out of scope for this draft, how a client detects the need of > resumption, we might need more text explaining this attack. I.e. we > might need to add text to security considerations which says that the > client implementations should not trust any untrusted source when they > are trying to detect whether the resumption is needed. [Peny] Agree. I also think we need more text to clarify this issue. In this meanwhile, I think the way in section 4.3.4 is not appropriate. Gateway should not silently delete the related SAs in this case. One possible solution is to use the anti-DOS cookie mechanism of IKEv2 to handle this issue. > -- > kivinen@iki.fi > From ynir@checkpoint.com Thu Sep 3 08:08:24 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4077F28C282 for ; Thu, 3 Sep 2009 08:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.107 X-Spam-Level: X-Spam-Status: No, score=-3.107 tagged_above=-999 required=5 tests=[AWL=0.491, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lin5N9c9lbGR for ; Thu, 3 Sep 2009 08:08:23 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 64F9228C271 for ; Thu, 3 Sep 2009 08:08:22 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n83F6s3P026147; Thu, 3 Sep 2009 18:06:54 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 3 Sep 2009 18:06:52 +0300 From: Yoav Nir To: "Kalyani Garigipati (kagarigi)" Date: Thu, 3 Sep 2009 18:06:52 +0300 Thread-Topic: [IPsec] Ikev2 HA message Id Issue Thread-Index: AcosqCrQpmu2ilaiT2mKBmw0A/9WBQ== Message-ID: <05D66A4A-C017-44B8-88E1-E82FF14B8653@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_05D66A4AC01744B888E1E82FF14B8653checkpointcom_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Ikev2 HA message Id Issue X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 15:08:24 -0000 --_000_05D66A4AC01744B888E1E82FF14B8653checkpointcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Kalyani Of the two, I prefer the 2nd solution, as it is simpler. Reusing message ID= s is not that bad, and you can decrease the change by including (in the RES= ET_MESSAGE_ID notification) a random number as the starting message ID. What I'm not so sure, is that there is a real problem here that needs to be= solved now. The IKEv2 documents totally ignore both high-availability solutions and loa= d-sharing solutions. They are just out of scope. So the documents don't s= pecify what data needs to be synched, or how is failover detected and accom= plished on the LAN or the WAN. To get there, you'd need to address issues of routing, signaling (between t= he peers) and AAA for both IKE and IPsec traffic. That's a tall order that= you probably don't want to tackle just now (maybe the WG would want this a= s the next "big" document) So to have a high-availability or load-sharing solution that participates i= n IKE/IPsec, an implementation needs to somehow pretend that both of these = are actually one gateway. This can be done with smart switches, multicast = addresses and synchronization links, which are out of scope for the WG (for= now) I can think of three levels of synchronizing IKE data between the peers. 1. Synchronize just the IKE SA at creating and deletion 2. Synchronize the IKE SA whenever the counters are updated 3. Synchronize both IKE and Child SAs whenever a packet is sent. #3 is obviously impractical. #1 doesn't work, because after fail-over, the= redundant gateway cannot take over the IKE SA, because it doesn't know the= message ID counters. #2 can be made to work, although you need to either i= mmediately rekey all the child SAs, or else skip ahead in the IPsec retrans= counters. This solution is practical enough, because most gateways have v= ery few Child SAs per IKE SA. With IKEv2 you can have complex traffic selec= tors that allow one SA to cover all the domain protected by a gateway. So y= ou might have a few SAs because of different QoS classes, and maybe a few i= f your implementation prefers to deal with whole ranges or subnets, but rea= lly, a single IKE SA with thousands of concurrent Child SAs is more of a la= b thing than a practical thing. Both your solutions ask peer gateways to assist the HA pair with their fail= -over process. To the other gateway it seems as if the (single) peer is req= uesting information about current message ID numbers (and windows) or else = for a reset. It seems strange that the first thing we would do for HA suppo= rt is to help a private extension to the architecture work better, when tha= t private extension is not really documented. What do you plan to do in your cluster, if the peer does not support this e= xtension? You might also want to ask Paul and Yaron to present this on the Interim me= eting on 22-Sep. Yoav On Sep 3, 2009, at 4:06 PM, Kalyani Garigipati (kagarigi) wrote: Hi , In Ikev2 HA, there is an issue with the message Id and window size. Standby device-----------------------active device-------------------------= ---------Peer device The active device participating in the exchange with the peer will update i= ts message id counters as per the exchanges done. This info cannot be synced to the stand-by device for every exchange done s= ince that would take up all the bandwidth and is not an efficient way. The stand-by device when it becomes active will start with the message Id a= s 1 and this will not be accepted by the peer, since its message Id counter= s are different. Hence a solution is required to sync the message Id counters to the standby= device. 1. A solution for this is to get the required info from the peer device sin= ce it maintains all these counters. The abstract details of how this can be done are given in the attached docu= ment. 2. An alternative solution for this could be to send a new notify called (R= ESET_MESSAGE_ID) to the peer device as soon as the standby comes up. But th= is may lead to Reuse of message Id=92s within the same SA which is not desirable. I think solution 1 should be implemented with Ikev2. Please give your comme= nts Regards, Kalyani --_000_05D66A4AC01744B888E1E82FF14B8653checkpointcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


So t= o have a high-availability or load-sharing solution that participates in IK= E/IPsec, an implementation needs to somehow pretend that both of these are = actually one gateway.  This can be done with smart switches, multicast= addresses and synchronization links, which are out of scope for the WG (fo= r now)

I can think of three levels of synchronizin= g IKE data between the peers.
 1. Synchronize just the IKE S= A at creating and deletion
 2. Synchronize the IKE SA whenev= er the counters are updated
 3. Synchronize both IKE and Chi= ld SAs whenever a packet is sent.

#3 is obviously = impractical.  #1 doesn't work, because after fail-over, the redundant = gateway cannot take over the IKE SA, because it doesn't know the message ID= counters. #2 can be made to work, although you need to either immediately = rekey all the child SAs, or else skip ahead in the IPsec retrans counters. =  This solution is practical enough, because most gateways have very fe= w Child SAs per IKE SA. With IKEv2 you can have complex traffic selectors t= hat allow one SA to cover all the domain protected by a gateway. So you mig= ht have a few SAs because of different QoS classes, and maybe a few if your= implementation prefers to deal with whole ranges or subnets, but really, a= single IKE SA with thousands of concurrent Child SAs is more of a lab thin= g than a practical thing.

Both your solutions ask = peer gateways to assist the HA pair with their fail-over process. To the ot= her gateway it seems as if the (single) peer is requesting information abou= t current message ID numbers (and windows) or else for a reset. It seems st= range that the first thing we would do for HA support is to help a private = extension to the architecture work better, when that private extension is n= ot really documented.

What do you plan to do in yo= ur cluster, if the peer does not support this extension?

You might also want to ask Paul and Yaron to present this on the Int= erim meeting on 22-Sep.

Yoav

On Sep 3, 2009, at 4:06 PM, Kalyani Garigipati (kagarigi) wrote:
Hi ,
 
In Ikev2 HA, there = is an issue with the message Id and window size.
 
Standby device----------= -------------active device----------------------------------Peer device
 
The active device participating in the exchange with the peer will update = its message id counters as per the exchanges done.=
= This info cannot be synced to the stand-by device for every exch= ange done since that would take up all the bandwidth and is not an efficien= t way.
 <= /div>
<= font size=3D"2" face=3D"Arial">The stand-by device when it becomes active will start with the me= ssage Id as 1 and this will not be accepted by the peer, since its message = Id counters are different.
Hence a solut= ion is required to sync the message Id counters to the standby device.=
 
1.= A solution for this is to get the required info from the peer device since= it maintains all these counters.
The a= bstract details of how this can be done are given in the attached document.=
 
<= span style=3D"font-size: 10pt; font-family: Arial; ">Reuse of message Id=92= s within the same SA which is not desirable.
=
 
I think solution 1 should be= implemented with Ikev2. Please give your comments=
=  
<= span style=3D"font-size: 10pt; font-family: Arial; ">Regards,
Kalyani
 = ;

= = --_000_05D66A4AC01744B888E1E82FF14B8653checkpointcom_-- From Pasi.Eronen@nokia.com Thu Sep 3 09:29:17 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A1D828C34A for ; Thu, 3 Sep 2009 09:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.365 X-Spam-Level: X-Spam-Status: No, score=-6.365 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjRj-CY5UaUI for ; Thu, 3 Sep 2009 09:29:12 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 1B8A828C349 for ; Thu, 3 Sep 2009 09:29:11 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n83GRFCj022394; Thu, 3 Sep 2009 11:27:53 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 19:28:24 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 19:28:19 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 19:28:15 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Thu, 3 Sep 2009 18:28:04 +0200 From: To: , Date: Thu, 3 Sep 2009 18:28:02 +0200 Thread-Topic: Ikev2 HA message Id Issue Thread-Index: Acosl2r1O/31ap0+S7iBnpuoe98dvgAGpN0w Message-ID: <808FD6E27AD4884E94820BC333B2DB773C0160C363@NOK-EUMSG-01.mgdnok.nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_808FD6E27AD4884E94820BC333B2DB773C0160C363NOKEUMSG01mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 03 Sep 2009 16:28:15.0713 (UTC) FILETIME=[89DBC510:01CA2CB3] Subject: Re: [IPsec] Ikev2 HA message Id Issue X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 16:29:17 -0000 --_000_808FD6E27AD4884E94820BC333B2DB773C0160C363NOKEUMSG01mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One obvious approach would be not to sync after every exchange (that could = be a lot of messages), but sync, say, every N seconds (say, N=3D5) in one = big batch (for all IKE_SAs that changed in the last N seconds). Most of the= time, almost all IKE_SAs are just sitting there idle (so IKEv2 message ID = counters don't change). In case of failure, the stand-by device would have = out-of-date information for some small percentage of IKE_SAs (those whose c= ounters changed since last sync) , but that's always going to be the case (= for exchanges where something more happened just before/during the failure)= . I haven't done the math, though, so I don't know what value of N would resu= lt in both acceptable bandwidth and acceptable failure rate for the stand-b= y (depends on how many messages your typical IKE_SAs have per hour on avera= ge)... Best regards, Pasi From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of e= xt Kalyani Garigipati (kagarigi) Sent: 03 September, 2009 16:07 To: ipsec@ietf.org Subject: [IPsec] Ikev2 HA message Id Issue Hi , In Ikev2 HA, there is an issue with the message Id and window size. Standby device-----------------------active device-------------------------= ---------Peer device The active device participating in the exchange with the peer will update i= ts message id counters as per the exchanges done. This info cannot be synced to the stand-by device for every exchange done s= ince that would take up all the bandwidth and is not an efficient way. The stand-by device when it becomes active will start with the message Id a= s 1 and this will not be accepted by the peer, since its message Id counter= s are different. Hence a solution is required to sync the message Id counters to the standby= device. 1. A solution for this is to get the required info from the peer device sin= ce it maintains all these counters. The abstract details of how this can be done are given in the attached docu= ment. 2. An alternative solution for this could be to send a new notify called (R= ESET_MESSAGE_ID) to the peer device as soon as the standby comes up. But th= is may lead to Reuse of message Id's within the same SA which is not desirable. I think solution 1 should be implemented with Ikev2. Please give your comme= nts Regards, Kalyani --_000_808FD6E27AD4884E94820BC333B2DB773C0160C363NOKEUMSG01mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

One obvious approach would be not to sync after every exchan= ge (that could be a lot of messages), but sync, say, every N seconds (say, N= =3D5)  in one big batch (for all IKE_SAs that changed in the last N seconds). Most= of the time, almost all IKE_SAs are just sitting there idle (so IKEv2 message = ID counters don't change). In case of failure, the stand-by device would have out-of-date information for some small percentage of IKE_SAs (those whose counters changed since last sync) , but that's always going to be the case = (for exchanges where something more happened just before/during the failure).

 

I haven't done the math, though, so I don't know what value = of N would result in both acceptable bandwidth and acceptable failure rate for t= he stand-by (depends on how many messages your typical IKE_SAs have per hour o= n average)...


Best regards,

Pasi

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = ext Kalyani Garigipati (kagarigi)
Sent: 03 September, 2009 16:07
To: ipsec@ietf.org
Subject: [IPsec] Ikev2 HA message Id Issue

 

Hi ,

 

In Ikev2 HA, there is an issue with the message Id and window size.=

 

Standby device-----------------------active device---------------------------------= -Peer device

 

The active device participating in the exchange with the peer will update its message id counters as per the exchanges done.

This info cannot be synced to the stand-by device for every exchange done since = that would take up all the bandwidth and is not an efficient way.

 

The stand-by device when it becomes active will start with the message Id as 1 = and this will not be accepted by the peer, since its message Id counters are different.

Hence a solution is required to sync the message Id counters to the standby devic= e.

 

1. A solution for this is to get the required info from the peer device since = it maintains all these counters.

The abstract details of how this can be done are given in the attached document= .

 

2. An alternative solution for this could be to send a new notify called (RESET_MESSAGE_ID) to the peer device as soon as the standby comes up. But = this may lead to

Reuse of message Id’s within the same SA which is not desirable.=

 

I think solution 1 should be implemented with Ikev2. Please give your comment= s

 

Regards,

Kalyani

 

 

 

 

--_000_808FD6E27AD4884E94820BC333B2DB773C0160C363NOKEUMSG01mgd_-- From kagarigi@cisco.com Thu Sep 3 10:23:30 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F45B28C16E for ; Thu, 3 Sep 2009 10:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqnjZkveUahS for ; Thu, 3 Sep 2009 10:23:23 -0700 (PDT) Received: from syd-iport-1.cisco.com (syd-iport-1.cisco.com [64.104.193.196]) by core3.amsl.com (Postfix) with ESMTP id C881528C11F for ; Thu, 3 Sep 2009 10:23:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugEAGOXn0oKS+ej/2dsb2JhbACCKizANohBAZAuBYQbgV1j X-IronPort-AV: E=Sophos;i="4.44,326,1249257600"; d="scan'208,217";a="60176373" Received: from hkg-dkim-2.cisco.com ([10.75.231.163]) by syd-iport-1.cisco.com with ESMTP; 03 Sep 2009 17:21:31 +0000 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n83HLUcU032232; Fri, 4 Sep 2009 01:21:30 +0800 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n83HLTU6018358; Thu, 3 Sep 2009 17:21:30 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 22:51:29 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA2CBA.F962E3DD" Date: Thu, 3 Sep 2009 22:51:27 +0530 Message-ID: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773C0160C363@NOK-EUMSG-01.mgdnok.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ikev2 HA message Id Issue Thread-Index: Acosl2r1O/31ap0+S7iBnpuoe98dvgAGpN0wAAEG7+A= References: <808FD6E27AD4884E94820BC333B2DB773C0160C363@NOK-EUMSG-01.mgdnok.nokia.com> From: "Kalyani Garigipati (kagarigi)" To: , X-OriginalArrivalTime: 03 Sep 2009 17:21:29.0429 (UTC) FILETIME=[F9762850:01CA2CBA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=18900; t=1251998490; x=1252862490; c=relaxed/simple; s=hkgdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kagarigi@cisco.com; z=From:=20=22Kalyani=20Garigipati=20(kagarigi)=22=20 |Subject:=20RE=3A=20Ikev2=20HA=20message=20Id=20Issue |Sender:=20; bh=N8w1ogAZ2g7INMOQ2teA+aMc1dopewUlagJgFy3gxJU=; b=QEkG6UOqff4gzs0t1E0SOX4+GEbGLy5v7keX6WxEYyVYC3AuNAGwuhMKiX qt8CThslqkLglYqhOSU7h9NfkM/isPCZgPMFzeDX6UOSMud+BuS56WGy210q 16a+RbQYEyu0z9xu/fx+e/zbbTP0FF8SeVUNpBlt2XjuLEGpbeaKQ=; Authentication-Results: hkg-dkim-2; header.From=kagarigi@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim2001 verified; ); Subject: Re: [IPsec] Ikev2 HA message Id Issue X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 17:23:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA2CBA.F962E3DD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Pasi, =20 Please find replies inline. =20 Regards, Kalyani =20 ________________________________ From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20 Sent: Thursday, September 03, 2009 9:58 PM To: Kalyani Garigipati (kagarigi); ipsec@ietf.org Subject: RE: Ikev2 HA message Id Issue =20 One obvious approach would be not to sync after every exchange (that could be a lot of messages), but sync, say, every N seconds (say, N=3D5) in one big batch (for all IKE_SAs that changed in the last N seconds).=20 =20 If sync is done in batches and if active device crashes between the interval sync of the batches, then we again see the same message Id issue. =20 If dpd is enabled then ikev2 counters keep updated frequently. Hence we cannot rule out the possibility of out of sync between stand by and active device with the above approach. =20 Most of the time, almost all IKE_SAs are just sitting there idle (so IKEv2 message ID counters don't change). In case of failure, the stand-by device would have out-of-date information for some small percentage of IKE_SAs (those whose counters changed since last sync) , but that's always going to be the case (for exchanges where something more happened just before/during the failure). =20 With HA, we want to ensure the maximum avoidance of out of sync. In any case of out of sync , the retransmission of messages should take care of the exchanges.=20 In the worst case the SA will have to deleted (which is the case Currently now for IKEV2 when windowing is used and some requests are lost ) =20 I haven't done the math, though, so I don't know what value of N would result in both acceptable bandwidth and acceptable failure rate for the stand-by (depends on how many messages your typical IKE_SAs have per hour on average)... =20 we might like the solution to work in all cases of exchange frequency, hence I think we cannot fix N. Best regards, Pasi =20 From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of ext Kalyani Garigipati (kagarigi) Sent: 03 September, 2009 16:07 To: ipsec@ietf.org Subject: [IPsec] Ikev2 HA message Id Issue =20 Hi , =20 In Ikev2 HA, there is an issue with the message Id and window size. =20 Standby device-----------------------active device----------------------------------Peer device =20 The active device participating in the exchange with the peer will update its message id counters as per the exchanges done. This info cannot be synced to the stand-by device for every exchange done since that would take up all the bandwidth and is not an efficient way. =20 The stand-by device when it becomes active will start with the message Id as 1 and this will not be accepted by the peer, since its message Id counters are different. Hence a solution is required to sync the message Id counters to the standby device. =20 1. A solution for this is to get the required info from the peer device since it maintains all these counters. The abstract details of how this can be done are given in the attached document. =20 2. An alternative solution for this could be to send a new notify called (RESET_MESSAGE_ID) to the peer device as soon as the standby comes up. But this may lead to=20 Reuse of message Id's within the same SA which is not desirable. =20 I think solution 1 should be implemented with Ikev2. Please give your comments =20 Regards, Kalyani =20 =20 =20 =20 ------_=_NextPart_001_01CA2CBA.F962E3DD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Pasi,

 

Please find replies = inline.

 

Regards,

Kalyani

=

 

From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]
Sent: Thursday, September = 03, 2009 9:58 PM
To: Kalyani Garigipati = (kagarigi); ipsec@ietf.org
Subject: RE: Ikev2 HA = message Id Issue

 

One obvious = approach would be not to sync after every exchange (that could be a lot of = messages), but sync, say, every N seconds (say, N=3D5)  in one big batch (for = all IKE_SAs that changed in the last N seconds).

 

=

<Kalyani> If  sync is = done in batches and if active device crashes  between the interval sync of = the batches, then we again see the same message Id = issue.      

If dpd is enabled then ikev2 = counters keep updated frequently. Hence we cannot rule out the possibility of out = of sync between stand by and active device with the above = approach.

 

Most of the = time, almost all IKE_SAs are just sitting there idle (so IKEv2 message ID = counters don't change). In case of failure, the stand-by device would have = out-of-date information for some small percentage of IKE_SAs (those whose counters = changed since last sync) , but that's always going to be the case (for exchanges = where something more happened just before/during the = failure).

 

<Kalyani> With HA,  we = want to ensure the maximum avoidance of out of sync. In any case of out of sync = , the retransmission of messages should take care of the exchanges. =

In the worst case the SA will have = to deleted (which is the case Currently now for IKEV2 when windowing is = used and some requests are lost )

 <= /o:p>

I haven't = done the math, though, so I don't know what value of N would result in both = acceptable bandwidth and acceptable failure rate for the stand-by (depends on how = many messages your typical IKE_SAs have per hour on = average)...

 

<Kalyani > we might like the solution to work in all cases of exchange frequency, hence I think we = cannot fix N.


Best regards,

Pasi

 <= /o:p>

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of ext Kalyani = Garigipati (kagarigi)
Sent: 03 September, 2009 = 16:07
To: ipsec@ietf.org
Subject: [IPsec] Ikev2 HA = message Id Issue

 

Hi ,

 

In Ikev2 HA, there is an issue with the message Id = and window size.

 

Standby device-----------------------active device----------------------------------Peer = device

 

The active device participating in the exchange with = the peer will update its message id counters as per the exchanges = done.

This info cannot be synced to the stand-by device for = every exchange done since that would take up all the bandwidth and is not an efficient way.

 

The stand-by device when it becomes active will start = with the message Id as 1 and this will not be accepted by the peer, since its message Id counters are different.

Hence a solution is required to sync the message Id = counters to the standby device.

 

1. A solution for this is to get the required info = from the peer device since it maintains all these = counters.

The abstract details of how this can be done are = given in the attached document.

 

2. An alternative solution for this could be to send = a new notify called (RESET_MESSAGE_ID) to the peer device as soon as the = standby comes up. But this may lead to

Reuse of message Id’s within the same SA which = is not desirable.

 

I think solution 1 should be implemented with Ikev2. = Please give your comments

 

Regards,

Kalyani

 

 

 

 

------_=_NextPart_001_01CA2CBA.F962E3DD-- From kagarigi@cisco.com Thu Sep 3 10:23:30 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD7DE3A635F for ; Thu, 3 Sep 2009 10:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7bK9TnRxXg0 for ; Thu, 3 Sep 2009 10:23:21 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id B2FA83A6784 for ; Thu, 3 Sep 2009 10:23:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcEAKSXn0qrR7PE/2dsb2JhbACCKS3AN4hBAZAuBYQbgV1j X-IronPort-AV: E=Sophos;i="4.44,326,1249257600"; d="scan'208,217";a="201606454" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 03 Sep 2009 17:21:36 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n83HLaa6028991; Thu, 3 Sep 2009 10:21:36 -0700 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n83HLXIH014176; Thu, 3 Sep 2009 17:21:35 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 22:51:34 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA2CBA.FC5910E7" Date: Thu, 3 Sep 2009 22:51:32 +0530 Message-ID: In-Reply-To: <05D66A4A-C017-44B8-88E1-E82FF14B8653@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Ikev2 HA message Id Issue Thread-Index: AcosqCrQpmu2ilaiT2mKBmw0A/9WBQAD5eSA References: <05D66A4A-C017-44B8-88E1-E82FF14B8653@checkpoint.com> From: "Kalyani Garigipati (kagarigi)" To: "Yoav Nir" X-OriginalArrivalTime: 03 Sep 2009 17:21:34.0673 (UTC) FILETIME=[FC965410:01CA2CBA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=26976; t=1251998496; x=1252862496; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kagarigi@cisco.com; z=From:=20=22Kalyani=20Garigipati=20(kagarigi)=22=20 |Subject:=20RE=3A=20[IPsec]=20Ikev2=20HA=20message=20Id=20I ssue |Sender:=20; bh=0ZfCpTWDuAvEGk7VzqJk9wXeyEhdRPaL/0M5/LXz+0E=; b=GIosItnDPBe4NwrguZSj9OwQwXyXqEGOZjyDMTs+whW9d/2NCmRMb5mwDX 9chknT9f2bzFvthjYwo6qC1ijaJtCbOxA236GV2c59KyaJE1BoUT12ALF+Pm mguaKM9TFv; Authentication-Results: sj-dkim-4; header.From=kagarigi@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: ipsec@ietf.org Subject: Re: [IPsec] Ikev2 HA message Id Issue X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 17:23:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA2CBA.FC5910E7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yoav, =20 I agree that 2nd solution is easier to implement, but the peer will have to delete the impending requests it might retransmit to the standby device.=20 This will also not catch the message replay attacks which is the major advantage of using message Id's (once the window is reset, earlier windows messages might be replayed which will fall in this window at some point of time).=20 Using a random number as starting message Id after reset, may also cause the same issue =20 with 1st solution we can start from the requests where the active device has stopped . This would ensure a smooth continuation of message Id's . =20 If the peer participating in the HA does not support this extension, then the ordinary method of updating the counters for every exchange has to be followed even though its inefficient. I don't see any other solution with the current ikev2 protocol for this message Id problem. Hence I feel that for efficient updation of counters, this extension should be supported . =20 In case of site to site there will be some cases of single IKE SA and multiple IPSEC SA's but we cannot rule out the case of multiple IKE SA's depending on the deployment. In addition , in case of remote access there might be many . In such cases if dpd is also enabled then solution #2 would create lots of message updations from=20 Active to standbydevice. The concern is not only abt the bandwidth between stand by and active , but the active device would be involved in only doing these updations to the stand-by device. =20 Regards, kalyani =20 ________________________________ From: Yoav Nir [mailto:ynir@checkpoint.com]=20 Sent: Thursday, September 03, 2009 8:37 PM To: Kalyani Garigipati (kagarigi) Cc: ipsec@ietf.org Subject: Re: [IPsec] Ikev2 HA message Id Issue =20 Hi Kalyani =20 Of the two, I prefer the 2nd solution, as it is simpler. Reusing message IDs is not that bad, and you can decrease the change by including (in the RESET_MESSAGE_ID notification) a random number as the starting message ID. =20 What I'm not so sure, is that there is a real problem here that needs to be solved now. =20 The IKEv2 documents totally ignore both high-availability solutions and load-sharing solutions. They are just out of scope. So the documents don't specify what data needs to be synched, or how is failover detected and accomplished on the LAN or the WAN. =20 To get there, you'd need to address issues of routing, signaling (between the peers) and AAA for both IKE and IPsec traffic. That's a tall order that you probably don't want to tackle just now (maybe the WG would want this as the next "big" document) =20 So to have a high-availability or load-sharing solution that participates in IKE/IPsec, an implementation needs to somehow pretend that both of these are actually one gateway. This can be done with smart switches, multicast addresses and synchronization links, which are out of scope for the WG (for now) =20 I can think of three levels of synchronizing IKE data between the peers. 1. Synchronize just the IKE SA at creating and deletion 2. Synchronize the IKE SA whenever the counters are updated 3. Synchronize both IKE and Child SAs whenever a packet is sent. =20 #3 is obviously impractical. #1 doesn't work, because after fail-over, the redundant gateway cannot take over the IKE SA, because it doesn't know the message ID counters. #2 can be made to work, although you need to either immediately rekey all the child SAs, or else skip ahead in the IPsec retrans counters. This solution is practical enough, because most gateways have very few Child SAs per IKE SA. With IKEv2 you can have complex traffic selectors that allow one SA to cover all the domain protected by a gateway. So you might have a few SAs because of different QoS classes, and maybe a few if your implementation prefers to deal with whole ranges or subnets, but really, a single IKE SA with thousands of concurrent Child SAs is more of a lab thing than a practical thing. =20 Both your solutions ask peer gateways to assist the HA pair with their fail-over process. To the other gateway it seems as if the (single) peer is requesting information about current message ID numbers (and windows) or else for a reset. It seems strange that the first thing we would do for HA support is to help a private extension to the architecture work better, when that private extension is not really documented. =20 What do you plan to do in your cluster, if the peer does not support this extension? =20 You might also want to ask Paul and Yaron to present this on the Interim meeting on 22-Sep. =20 Yoav =20 On Sep 3, 2009, at 4:06 PM, Kalyani Garigipati (kagarigi) wrote: Hi , =20 In Ikev2 HA, there is an issue with the message Id and window size. =20 Standby device-----------------------active device----------------------------------Peer device =20 The active device participating in the exchange with the peer will update its message id counters as per the exchanges done. This info cannot be synced to the stand-by device for every exchange done since that would take up all the bandwidth and is not an efficient way. =20 The stand-by device when it becomes active will start with the message Id as 1 and this will not be accepted by the peer, since its message Id counters are different. Hence a solution is required to sync the message Id counters to the standby device. =20 1. A solution for this is to get the required info from the peer device since it maintains all these counters. The abstract details of how this can be done are given in the attached document. =20 2. An alternative solution for this could be to send a new notify called (RESET_MESSAGE_ID) to the peer device as soon as the standby comes up. But this may lead to Reuse of message Id's within the same SA which is not desirable. =20 I think solution 1 should be implemented with Ikev2. Please give your comments =20 Regards, Kalyani =20 =20 ------_=_NextPart_001_01CA2CBA.FC5910E7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Yoav,

 

I agree that 2nd = solution is easier to implement, but the peer will have to delete the impending = requests it might retransmit to the standby device.

 This will also not catch the = message replay attacks which is the major advantage of using message = Id’s

 (once the window is reset, = earlier windows messages might be replayed which will fall in this window at = some point of time).

Using a random number as starting = message Id after reset, may also cause the same = issue

 

with 1st solution we can = start from the requests where the active device has stopped . This would = ensure a smooth continuation of message Id’s .

 

If the peer participating in the HA = does not support this extension, then the ordinary method of updating the = counters for every exchange has to be followed even though its = inefficient.

I don’t see any other = solution with the current ikev2 protocol for this message Id problem. Hence I feel = that for efficient updation of counters, this extension should be supported = .

 

In case of site to site there will = be some cases of single IKE SA and multiple IPSEC SA’s but we cannot rule = out the case of multiple IKE SA’s depending on the = deployment.

In addition , in case of remote = access there might be many . In such cases if dpd is also enabled then solution = #2 would create lots of message updations from =

Active to standbydevice. The = concern is not only abt the bandwidth between stand by and active , but the active = device would be involved in only doing these updations to the stand-by = device.

 

Regards,

kalyani

=

 

From: Yoav = Nir [mailto:ynir@checkpoint.com]
Sent: Thursday, September = 03, 2009 8:37 PM
To: Kalyani Garigipati = (kagarigi)
Cc: ipsec@ietf.org
Subject: Re: [IPsec] = Ikev2 HA message Id Issue

 

Hi  Kalyani

 

Of the two, I prefer the 2nd solution, as it is simpler. Reusing message IDs is not that bad, and you can decrease the change by = including (in the RESET_MESSAGE_ID notification) a random number as the starting = message ID.

 

What I'm not so sure, is that there is a real problem here that = needs to be solved now.

 

The IKEv2 documents totally ignore both high-availability = solutions and load-sharing solutions.  They are just out of scope.  So the documents don't specify what data needs to be synched, or how is = failover detected and accomplished on the LAN or the = WAN.

 

To get there, you'd need to address issues of routing, signaling (between the peers) and AAA for both IKE and IPsec traffic.  That's = a tall order that you probably don't want to tackle just now (maybe the WG = would want this as the next "big" document)

 

So to have a high-availability or load-sharing solution that participates in IKE/IPsec, an implementation needs to somehow pretend = that both of these are actually one gateway.  This can be done with smart = switches, multicast addresses and synchronization links, which are out of scope = for the WG (for now)

 

I can think of three levels of synchronizing IKE data between = the peers.

 1. Synchronize just the IKE SA at creating and = deletion

 2. Synchronize the IKE SA whenever the counters are = updated

 3. Synchronize both IKE and Child SAs whenever a packet is = sent.

 

#3 is obviously impractical.  #1 doesn't work, because = after fail-over, the redundant gateway cannot take over the IKE SA, because it doesn't know the message ID counters. #2 can be made to work, although = you need to either immediately rekey all the child SAs, or else skip ahead in the = IPsec retrans counters.  This solution is practical enough, because most = gateways have very few Child SAs per IKE SA. With IKEv2 you can have complex = traffic selectors that allow one SA to cover all the domain protected by a = gateway. So you might have a few SAs because of different QoS classes, and maybe a = few if your implementation prefers to deal with whole ranges or subnets, but = really, a single IKE SA with thousands of concurrent Child SAs is more of a lab = thing than a practical thing.

 

Both your solutions ask peer gateways to assist the HA pair with = their fail-over process. To the other gateway it seems as if the (single) peer = is requesting information about current message ID numbers (and windows) or = else for a reset. It seems strange that the first thing we would do for HA = support is to help a private extension to the architecture work better, when = that private extension is not really documented.

 

What do you plan to do in your cluster, if the peer does not = support this extension?

 

You might also want to ask Paul and Yaron to present this on the Interim meeting on 22-Sep.

 

Yoav

 

On Sep 3, 2009, at 4:06 PM, Kalyani Garigipati (kagarigi) = wrote:



Hi ,

 

In Ikev2 HA, there is an issue with the message Id = and window size.

 

Standby device-----------------------active device----------------------------------Peer = device

 

The active device participating in the exchange with = the peer will update its message id counters as per the exchanges = done.

This info cannot be synced to the stand-by device for = every exchange done since that would take up all the bandwidth and is not an efficient way.

 

The stand-by device when it becomes active will start = with the message Id as 1 and this will not be accepted by the peer, since its message Id counters are = different.

Hence a solution is required to sync the message Id = counters to the standby device.

 

1. A solution for this is to get the required info = from the peer device since it maintains all these = counters.

The abstract details of how this can be done are = given in the attached document.

 

2. An alternative solution for this could be to send = a new notify called (RESET_MESSAGE_ID) to the peer device as soon as the = standby comes up. But this may lead to

Reuse of message Id’s within the same SA which = is not desirable.

 

I think solution 1 should be implemented with Ikev2. = Please give your comments

 

Regards,

Kalyani

 

 

------_=_NextPart_001_01CA2CBA.FC5910E7-- From Pasi.Eronen@nokia.com Thu Sep 3 11:15:54 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C3AE3A6826 for ; Thu, 3 Sep 2009 11:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.369 X-Spam-Level: X-Spam-Status: No, score=-6.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id es4g13yIu47m for ; Thu, 3 Sep 2009 11:15:53 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 464CA3A67B6 for ; Thu, 3 Sep 2009 11:15:50 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n83IBRJZ008854; Thu, 3 Sep 2009 13:12:07 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 21:12:33 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 21:12:33 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Thu, 3 Sep 2009 20:12:33 +0200 From: To: , Date: Thu, 3 Sep 2009 20:12:32 +0200 Thread-Topic: Ikev2 HA message Id Issue Thread-Index: Acosl2r1O/31ap0+S7iBnpuoe98dvgAGpN0wAAEG7+AAAq8CcA== Message-ID: <808FD6E27AD4884E94820BC333B2DB773C0160C39E@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB773C0160C363@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Sep 2009 18:12:33.0682 (UTC) FILETIME=[1BE60F20:01CA2CC2] Subject: Re: [IPsec] Ikev2 HA message Id Issue X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 18:15:54 -0000 Kalyani Garigipati wrote: >> One obvious approach would be not to sync after every exchange >> (that could be a lot of messages), but sync, say, every N seconds >> (say, N=3D5)=A0 in one big batch (for all IKE_SAs that changed in the >> last N seconds). > > If=A0 sync is done in batches and if active device crashes=A0 > between the interval sync of the batches, then we again see the same > message Id issue.=A0=A0=A0=A0=A0=A0 Yes; so N can't be very large. > If dpd is enabled then ikev2 counters keep updated frequently.=20 This depends on how often you do DPD... Obviously, you want dead IKE_SAs to go away eventually, but e.g. 30 minute DPD interval would be sufficient for that. If your DPD interval was close to the value=20 of N, that would not work well... but on the other hand, if you have=20 lot of traffic going back and forth, IKEv2 DPD won't get triggered.. > Hence we cannot rule out the possibility of out of sync between > stand by and active device with the above approach. We cannot rule out this possibility with any approach, I think. >> Most of the time, almost all IKE_SAs are just sitting there idle >> (so IKEv2 message ID counters don't change). In case of failure, >> the stand-by device would have out-of-date information for some >> small percentage of IKE_SAs (those whose counters changed since >> last sync) , but that's always going to be the case (for exchanges >> where something more happened just before/during the failure). > > With HA, =A0we want to ensure the maximum avoidance of out > of sync. In any case of out of sync, the retransmission of messages > should take care of the exchanges. In the worst case the SA will > have to deleted (which is the case Currently now for IKEV2 when > windowing is used and some requests are lost ) Yes. But this worst case cannot be avoided (since the worst case can occur due to other reasons than message IDs) -- it can be=20 just made less likely to happen. =20 >> I haven't done the math, though, so I don't know what value of N >> would result in both acceptable bandwidth and acceptable failure >> rate for the stand-by (depends on how many messages your typical >> IKE_SAs have per hour on average)... > > we might like the solution to work in all cases of > exchange frequency, hence I think we cannot fix N. I agree; clearly N would be a configurable parameter, not something fixed in some spec. Best regards, Pasi From welterk@us.ibm.com Thu Sep 3 13:53:11 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE5D83A6957 for ; Thu, 3 Sep 2009 13:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rY++aLQsEUm for ; Thu, 3 Sep 2009 13:53:11 -0700 (PDT) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by core3.amsl.com (Postfix) with ESMTP id 230593A6872 for ; Thu, 3 Sep 2009 13:53:11 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e36.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n83KojQn027745 for ; Thu, 3 Sep 2009 14:50:45 -0600 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n83KqXd2157996 for ; Thu, 3 Sep 2009 14:52:33 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n83KqXQY027414 for ; Thu, 3 Sep 2009 14:52:33 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n83KqXFi027409 for ; Thu, 3 Sep 2009 14:52:33 -0600 To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: 8D5D39BA:90319879-88257626:005BF9D2; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Keith Welter X-MIMETrack: S/MIME Sign by Notes Client on Keith Welter/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 09/03/2009 01:52:28 PM, Serialize by Notes Client on Keith Welter/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 09/03/2009 01:52:28 PM, Serialize complete at 09/03/2009 01:52:28 PM, S/MIME Sign failed at 09/03/2009 01:52:28 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V851_08302009|August 30, 2009) at 09/03/2009 14:52:32, Serialize complete at 09/03/2009 14:52:32 Message-ID: Date: Thu, 3 Sep 2009 13:52:31 -0700 Content-Type: multipart/alternative; boundary="=_alternative 0072AADB88257626_=" Subject: Re: [IPsec] Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 20:53:12 -0000 This is a multipart message in MIME format. --=_alternative 0072AADB88257626_= Content-Type: text/plain; charset="US-ASCII" > If the error occurs on the > initiator, the notification MUST be returned in a separate > INFORMATIONAL exchange, with no other payloads. Should an implementation be prohibited from sending an empty delete payload in this case? I would prefer wording like the following: "with no other payloads except an optional empty delete payload". Keith Welter IBM z/OS Communications Server Developer 1-415-545-2694 (T/L: 473-2694) --=_alternative 0072AADB88257626_= Content-Type: text/html; charset="US-ASCII"
>    If the error occurs on the
>    initiator, the notification MUST be returned in a separate
>    INFORMATIONAL exchange, with no other payloads.
Should an implementation be prohibited from sending an empty delete payload
in this case?  I would prefer wording like the following:
"with no other payloads except an optional empty delete payload".


Keith Welter
IBM z/OS Communications Server Developer
1-415-545-2694 (T/L: 473-2694)
 --=_alternative 0072AADB88257626_=-- From ynir@checkpoint.com Thu Sep 3 14:16:26 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3FAF3A68B4 for ; Thu, 3 Sep 2009 14:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.162 X-Spam-Level: X-Spam-Status: No, score=-3.162 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VARqhfRKZ64I for ; Thu, 3 Sep 2009 14:16:26 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id BDD513A6834 for ; Thu, 3 Sep 2009 14:16:25 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n83LEn3P022473; Fri, 4 Sep 2009 00:14:49 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 4 Sep 2009 00:14:47 +0300 From: Yoav Nir To: Keith Welter Date: Fri, 4 Sep 2009 00:14:46 +0300 Thread-Topic: [IPsec] Issue #26: Missing treatment of error cases Thread-Index: Acos25AsiU+/52cwSPqOmTMhl7VV+w== Message-ID: <97EF486C-AECE-4A5F-9D15-0A3D554AD4BA@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_97EF486CAECE4A5F9D150A3D554AD4BAcheckpointcom_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 21:16:26 -0000 --_000_97EF486CAECE4A5F9D150A3D554AD4BAcheckpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, I will soften the language a bit, but I won't mention a DELETE payload= . If some implementations do it. others may come to expect it. We don't wan= t to encourage that by suggesting that it's a good idea. On Sep 3, 2009, at 11:52 PM, Keith Welter wrote: > If the error occurs on the > initiator, the notification MUST be returned in a separate > INFORMATIONAL exchange, with no other payloads. Should an implementation be prohibited from sending an empty delete payload in this case? I would prefer wording like the following: "with no other payloads except an optional empty delete payload". Keith Welter IBM z/OS Communications Server Developer 1-415-545-2694 (T/L: 473-2694) --_000_97EF486CAECE4A5F9D150A3D554AD4BAcheckpointcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, I will soften the lan= guage a bit, but I won't mention a DELETE payload. If some implementations = do it. others may come to expect it. We don't want to encourage that by sug= gesting that it's a good idea.

On Sep 3, 2009, at 11:52 P= M, Keith Welter wrote:


>    If the error occurs on the
>    initiator, the notification MUST be returned in a separat= e
>    INFORMATIONAL exchange, with no other payloads.
Should an implementation be prohibited from sendin= g an empty delete payload
in this case?  I would prefer wording like th= e following:
"with no other payloads except an optional empty delete payload".


Keith Welter
IBM z/OS Communications Server Developer
1-415-545-2694 (T/L: 473-2694)

= --_000_97EF486CAECE4A5F9D150A3D554AD4BAcheckpointcom_-- From suresh.krishnan@ericsson.com Thu Sep 3 14:34:43 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56A4C3A6970 for ; Thu, 3 Sep 2009 14:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qarPThlDC0ya for ; Thu, 3 Sep 2009 14:34:42 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id A761B3A6947 for ; Thu, 3 Sep 2009 14:34:42 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n83LWrfi028025 for ; Thu, 3 Sep 2009 16:32:56 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 16:32:55 -0500 Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 16:32:55 -0500 Received: from [142.133.10.113] (147.117.20.212) by eusaamw0711.eamcs.ericsson.se (147.117.20.179) with Microsoft SMTP Server id 8.1.375.2; Thu, 3 Sep 2009 17:32:54 -0400 Message-ID: <4AA0356D.4070706@ericsson.com> Date: Thu, 3 Sep 2009 17:30:21 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "ipsec@ietf.org" References: <006FEB08D9C6444AB014105C9AEB133F906D312AD8@il-ex01.ad.checkpoint.com> In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F906D312AD8@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Sep 2009 21:32:55.0609 (UTC) FILETIME=[19868A90:01CA2CDE] Subject: [IPsec] Comments on draft-ietf-ipsecme-roadmap-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 21:34:43 -0000 Hi Yaron/Sean/Julien/Greg/Scott/Yoav, Thank you very much for your comments. We are working on them and we hope to have a new revision out soon. Thanks Sheila and Suresh From kivinen@iki.fi Fri Sep 4 02:08:54 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EB623A69CC for ; Fri, 4 Sep 2009 02:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jisFWnC6SleC for ; Fri, 4 Sep 2009 02:08:53 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id F34DE3A6843 for ; Fri, 4 Sep 2009 02:08:52 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n848sIOu013813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Sep 2009 11:54:18 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n848sH9S014881; Fri, 4 Sep 2009 11:54:17 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19104.54713.252583.456015@fireball.kivinen.iki.fi> Date: Fri, 4 Sep 2009 11:54:17 +0300 From: Tero Kivinen To: David Wierbowski In-Reply-To: References: <19101.10929.181733.7940@fireball.kivinen.iki.fi> <19102.25856.800410.560288@fireball.kivinen.iki.fi> <19103.34279.253359.922428@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 17 min Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] CRL checking when selecting a certifcate X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 09:08:54 -0000 David Wierbowski writes: > > Tero, thanks for the comments and the clarification on how to read a lower > case must. I do have a few more comments. > > >So implementations cannot just search uppercase "MUST/SHOULD/MAY" > >texts and assume it is enough to make sure those are correct. It also > >needs to do what the text says... > I think most implementers focus on the MUST and SHOULDs and then apply > common sense to the remaining text. I agree. I have done that myself too, and only noticed that this does not really help when the latest version of ikev2bis had following change (this is unrelated to current case, but it is more generic case): Old text: ---------------------------------------------------------------------- The responder can be assured that the initiator is prepared to receive messages on an SA if either (1) it has received a cryptographically valid message on the new SA, or (2) the new SA rekeys an existing SA and it receives an IKE request to close the replaced SA. When rekeying an SA, the responder SHOULD continue to send messages on the old SA until one of those events occurs. ---------------------------------------------------------------------- New text: ---------------------------------------------------------------------- The responder can be assured that the initiator is prepared to receive messages on an SA if either (1) it has received a cryptographically valid message on the new SA, or (2) the new SA rekeys an existing SA and it receives an IKE request to close the replaced SA. When rekeying an SA, the responder continues to send traffic on the old SA until one of those events occurs. ---------------------------------------------------------------------- Earlier we knew that we didn't follow that SHOULD exactly, as we moved to use new SA either if old one was deleted or after short timeout. We knew this was against the SHOULD and changing it was on our todo list. Now the new text does not say "SHOULD" anymore (it was removed, not lowercased), it just says you "continue to send traffic on the old SA" so effectually now it is MUST as it says you do that, you are not allowed to do anything else. So when the text removed "SHOULD" it actually made the required behavior much stricter, and made our old implementations so they do not follow the given behavior (as this was in our todo list, we have already changed the code). This is more generic thing than just CRLs (or rekey behavior), i.e. what does non-lowercase "do this" statement in the RFC really mean. -- kivinen@iki.fi From kivinen@iki.fi Fri Sep 4 02:41:39 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5C713A688D for ; Fri, 4 Sep 2009 02:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giCSsaZzPpME for ; Fri, 4 Sep 2009 02:41:36 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id D52523A69C2 for ; Fri, 4 Sep 2009 02:41:34 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n849eB7i015921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Sep 2009 12:40:11 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n849eAJq013567; Fri, 4 Sep 2009 12:40:10 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19104.57466.546995.955611@fireball.kivinen.iki.fi> Date: Fri, 4 Sep 2009 12:40:10 +0300 From: Tero Kivinen To: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773C0160C39E@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB773C0160C363@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB773C0160C39E@NOK-EUMSG-01.mgdnok.nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 13 min X-Total-Time: 13 min Cc: ipsec@ietf.org, kagarigi@cisco.com Subject: Re: [IPsec] Ikev2 HA message Id Issue X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 09:41:40 -0000 Pasi.Eronen@nokia.com writes: > > If dpd is enabled then ikev2 counters keep updated frequently. > > This depends on how often you do DPD... Obviously, you want dead > IKE_SAs to go away eventually, but e.g. 30 minute DPD interval would > be sufficient for that. If your DPD interval was close to the value > of N, that would not work well... but on the other hand, if you have > lot of traffic going back and forth, IKEv2 DPD won't get triggered.. You should not really have fixed timer for DPD. You should base your DPD interval depending on the other things, i.e. if there is ESP traffic coming from the other end to your site, there is no point of doing DPD based on timer unless something else says otherwise. If you start suspecting there might be something wrong with IKEv2 SA (i.e. you receive ICMP or network goes down and comes up again etc), then you might trigger DPD once to see if the other end is still there. If you only trigger timer based DPD when there is no ESP traffic at all (i.e. the both IKEv2 SA and IPsec SA are completely idle) then there is no point of trying to use too short DPD timers as the SA is idle anyways, and in such cases you do not need very fast recovery from other ends crashes... Only case where you might need more frequent timer based DPD is when your traffic is unidirectional, i.e. you are sending ESP traffic to other end but other end is not sending anything back. As this is not a common case in normal operation, that is good indication there might be something wrong and in such cases you should trigger DPD to verify it the other end is up. In general I consider syncing HA boxes after each IKEv2 Message (or once per second etc) not too big problem. HA boxes are usually directly connected with fast network cable (usually at least as fast as their traffic in), and every single IKEv2 message requires some cryptographic operations anyways, and is bigger than what it would be to send short cleartext message to other HA telling "I finished processing my request message id XXX at IKE SA YYY" or "I finished processing my reply to message id XXX at IKE SA YYY and packet sent was ZZZ" (you need to sync the reply packet data you sent to other end just in case the packet was lost and other end didn't get it, so you can retransmit it from HA pair). In any case you will loose all IKE SA which are in the middle of exchanges when one of the devices goes down, as syncing intermediate state from one device to other would be way too complex. -- kivinen@iki.fi From wierbows@us.ibm.com Fri Sep 4 07:54:40 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5DAC3A6A26 for ; Fri, 4 Sep 2009 07:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.345 X-Spam-Level: X-Spam-Status: No, score=-5.345 tagged_above=-999 required=5 tests=[AWL=1.253, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2GBex46FeFc for ; Fri, 4 Sep 2009 07:54:40 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by core3.amsl.com (Postfix) with ESMTP id 0329E3A67EB for ; Fri, 4 Sep 2009 07:54:39 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n84EwHRA014507 for ; Fri, 4 Sep 2009 10:58:17 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n84Erwjj222734 for ; Fri, 4 Sep 2009 10:53:58 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n84Erwjw005033 for ; Fri, 4 Sep 2009 10:53:58 -0400 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n84ErwDN005025; Fri, 4 Sep 2009 10:53:58 -0400 In-Reply-To: <97EF486C-AECE-4A5F-9D15-0A3D554AD4BA@checkpoint.com> References: <97EF486C-AECE-4A5F-9D15-0A3D554AD4BA@checkpoint.com> X-KeepSent: DEDDC1CD:F31C9C51-85257627:00518EE1; type=4; name=$KeepSent To: Yoav Nir X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: David Wierbowski Date: Fri, 4 Sep 2009 10:53:57 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 09/04/2009 10:53:57 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBFCB4DFC208718f9e8a93df938690918c0ABBFCB4DFC20871" Content-Disposition: inline Cc: "ipsec@ietf.org" , Keith Welter Subject: Re: [IPsec] Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 14:54:40 -0000 --0__=0ABBFCB4DFC208718f9e8a93df938690918c0ABBFCB4DFC20871 Content-type: text/plain; charset=US-ASCII >Yes, I will soften the language a bit, but I won't mention a DELETE payload. If some implementations do it. >others may come to expect it. We don't want to encourage that by suggesting that it's a good idea. Yoav, Why is it a a bad idea to include a DELETE payload in this case? Dave Wierbowski --0__=0ABBFCB4DFC208718f9e8a93df938690918c0ABBFCB4DFC20871 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

>Yes, I will soften the language a bit, but I won't mention a DELETE payload. If some implementations do it.
>others may come to expect it. We don't want to encourage that by suggesting that it's a good idea.

Yoav, Why is it a a bad idea to include a DELETE payload in this case?


    Dave Wierbowski --0__=0ABBFCB4DFC208718f9e8a93df938690918c0ABBFCB4DFC20871-- From piyomaru3141@gmail.com Fri Sep 4 02:33:29 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E57D3A69BE for ; Fri, 4 Sep 2009 02:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5s+mhyVCR4s for ; Fri, 4 Sep 2009 02:33:28 -0700 (PDT) Received: from mail-yx0-f190.google.com (mail-yx0-f190.google.com [209.85.210.190]) by core3.amsl.com (Postfix) with ESMTP id 196D13A69E4 for ; Fri, 4 Sep 2009 02:33:28 -0700 (PDT) Received: by yxe28 with SMTP id 28so459415yxe.19 for ; Fri, 04 Sep 2009 02:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4R2dsHtJ7UWf6vBhDe6As6hGUPZXqQvvuqQZ1+SqobQ=; b=eNv1YGMFz5ubV+f9TyWeZficUl1ahXSJ99j7U1Zq5yjhCwnnSI6tWgkjQy+SZJvZdl NSuLrw03ibz3AXWLVfn7+C5Uu4Cuhp+s8JROxtLD1EvLm8u6nsHuN0cFPOl9Nuhptgws 7nwrg9Y1priWuuyd+1cRzLr3mVGNj6nVHnROE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GANM6oZEiCglYtmEEsjVUiOHpIsLm6t3CYiatplvFa5BueuzzfCL/KiYwP56FFwrCO 059Ak+XTGobvkDcEbhffO5ghZpFVJMqAhpcJkRfLxuDxIblopgSAYAu1uWdDJKMSJ+6Q KcshHZ94e3YBPxcHy4ftt6SroI2Pa9Rh51hSo= MIME-Version: 1.0 Received: by 10.101.209.23 with SMTP id l23mr6731585anq.173.1252056738644; Fri, 04 Sep 2009 02:32:18 -0700 (PDT) In-Reply-To: <19102.26763.522570.187181@fireball.kivinen.iki.fi> References: <19102.26763.522570.187181@fireball.kivinen.iki.fi> Date: Fri, 4 Sep 2009 18:32:18 +0900 Message-ID: From: naoyoshi ueda To: Tero Kivinen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 04 Sep 2009 08:38:25 -0700 Cc: ipsec@ietf.org Subject: Re: [IPsec] Questions to IKEv2bis draft: IVs of retransmitted packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 09:33:29 -0000 Hello Tero, Thank you for your clear answer. It cleared up my questions. Thanks, Naoyoshi Ueda 2009/9/2 Tero Kivinen : > naoyoshi ueda writes: >> According to ikev2bis-04 section 2.1: >> > =A0 A retransmission from the initiator >> > =A0 MUST be bitwise identical to the original request. =A0That is, >> > =A0 everything starting from the IKE Header (the IKE SA Initiator's SP= I >> > =A0 onwards) must be bitwise identical; items before it (such as the I= P >> > =A0 and UDP headers, and the zero non-ESP marker) do not have to be >> > =A0 identical. >> >> So, IV of retransmitted request must be the same as that of original >> request. > > Yes. > >> Meanwhile, =A0ikev2bis-04 section 3.14 says >> > =A0 o =A0Initialization Vector - For CBC mode ciphers, the length of t= he >> > =A0 =A0 =A0initialization vector (IV) is equal to the block length of = the >> > =A0 =A0 =A0underlying encryption algorithm. =A0Senders MUST select a n= ew >> > =A0 =A0 =A0unpredictable IV for every message; recipients MUST accept = any >> > =A0 =A0 =A0value. >> >> Question 1: >> Does the statement "recipients MUST accept any value." stay true >> even if retransmitted IV differs from that of original request? > > Most likely, but it does not matter as the packet will fail window > check, thus will be considered as retransmission or old packet, and > thrown away (it might trigger retransmission of responders reply in > case it was packet in the window). > > Note, that this can only happen if the other is non-conforming, or > there is attacker between which modifies the IV. Conforming > implementation will use same IV all time. > >> Question 2: >> If the answer to Question 1 is no, what should the recipient do? >> Just ignore it? Abandon the IKE_SA? Or send some Notify? > > If recipient has already seen the message before (i.e it has already > processed it), it can resend its reply. It can also notice that the > packet is not bitwise-same as previously and the message id is old, > and silently ignore it. So this is implementation depended what will > happen. > > If it has not seen the message before, then it does not know the IV > has changed, thus will process the packet normally. > >> Question 3: >> How about IV of retransmitted RESPONSE? >> Does it need to be identical to the original one too? > > The retransmitted response should also be bitwise identical to > original one. > >> It seems to me that the following statement in section 2.1 >> implicitly requires that. But I'm not sure. > > I would agree you that it implicitly requires that. > >> Actually, I'm now involved in a IKEv2 implementation that >> sends retransmitted response with different IV from original one >> and I cannot tell if the behavior is allowed or not. > > I would say it is not allowed, but on the other hand, the other end > should not ever notice this, as it only process one of the responses > (the first to reach him), and then ignores rest even before decrypting > them (when it checks its message id). I.e. it ignores further > responses to requests it has already received response. > >> ikev2bis-04 section 2.1: >> > =A0 The responder MUST remember each >> > =A0 response until it receives a request whose sequence number is larg= er >> > =A0 than or equal to the sequence number in the response plus its wind= ow >> > =A0 size (see Section 2.3). > -- > kivinen@iki.fi > From piyomaru3141@gmail.com Fri Sep 4 03:22:28 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB2C13A69DC for ; Fri, 4 Sep 2009 03:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nxyUcHve7+3 for ; Fri, 4 Sep 2009 03:22:27 -0700 (PDT) Received: from mail-yx0-f190.google.com (mail-yx0-f190.google.com [209.85.210.190]) by core3.amsl.com (Postfix) with ESMTP id 8E8923A68F1 for ; Fri, 4 Sep 2009 03:22:27 -0700 (PDT) Received: by yxe28 with SMTP id 28so488927yxe.19 for ; Fri, 04 Sep 2009 03:21:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wJ5YboehRwUBS2cQscvb4rNbFUjf8ELgt9/9FMPtmnc=; b=MCSiWqWt0LJmUK4ealOKQmNEwf0MiR0ipUWK4Mxh0QJ23ZwQs+bvH1xb3atAcJzYmH HmDm++ytWl+rW20TSfWrA5vb+0551FjC2yjcu4G8FsLxJzZjmYXk9VPJNFaYhlY6zaIW rbhDGOrGfpF7XFhLe9qvDOkLyVAcdzYs7m6rg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=sbKevevRvqlBB0x4aM7d9MFD0INqG9lXoub+JISW3s5q2rH9oBYBHK218IoGTlVkxT d9Dr+gDPHAlqeKkqPh2ysX7o9z1+TfeK3C4+C6DE7usKH11X0S0EAdhu6l4mG+XGWZZN VuXt3RXCvojMZSYZR4xn+w5dwqgDaz3EpWzkA= MIME-Version: 1.0 Received: by 10.101.20.3 with SMTP id x3mr12238540ani.31.1252059383118; Fri, 04 Sep 2009 03:16:23 -0700 (PDT) In-Reply-To: <7d660a970909030646s3946490eu7add089cf7dae87b@mail.gmail.com> References: <19102.26763.522570.187181@fireball.kivinen.iki.fi> <7d660a970909030646s3946490eu7add089cf7dae87b@mail.gmail.com> Date: Fri, 4 Sep 2009 19:16:23 +0900 Message-ID: From: naoyoshi ueda To: Jeff Sun Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 04 Sep 2009 08:38:25 -0700 Cc: ipsec@ietf.org Subject: Re: [IPsec] Questions to IKEv2bis draft: IVs of retransmitted packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 10:22:28 -0000 Hello Jeff, Sorry, I withhold the product's name because of my business commitments. However, I just say that it is not an ordinary network device like VPN gate= way. Regards, Naoyoshi Ueda 2009/9/3 Jeff Sun : > All in all, the qualifications of being a true retransmitted IKE > request/response message is dependent on the post-encrypted IKE > request/response message being bitwise identical.=A0 Naoyoshi, if you don= 't > mind me asking, which implementation are observing this behavior from (I'= m > not sure if this breaks any rules of engagement of mailing list, so pleas= e > respond privately to me if possible)? > > - Jeff Sun > > On Wed, Sep 2, 2009 at 5:43 AM, Tero Kivinen wrote: >> >> naoyoshi ueda writes: >> > According to ikev2bis-04 section 2.1: >> > > =A0 A retransmission from the initiator >> > > =A0 MUST be bitwise identical to the original request. =A0That is, >> > > =A0 everything starting from the IKE Header (the IKE SA Initiator's = SPI >> > > =A0 onwards) must be bitwise identical; items before it (such as the= IP >> > > =A0 and UDP headers, and the zero non-ESP marker) do not have to be >> > > =A0 identical. >> > >> > So, IV of retransmitted request must be the same as that of original >> > request. >> >> Yes. >> >> > Meanwhile, =A0ikev2bis-04 section 3.14 says >> > > =A0 o =A0Initialization Vector - For CBC mode ciphers, the length of= the >> > > =A0 =A0 =A0initialization vector (IV) is equal to the block length o= f the >> > > =A0 =A0 =A0underlying encryption algorithm. =A0Senders MUST select a= new >> > > =A0 =A0 =A0unpredictable IV for every message; recipients MUST accep= t any >> > > =A0 =A0 =A0value. >> > >> > Question 1: >> > Does the statement "recipients MUST accept any value." stay true >> > even if retransmitted IV differs from that of original request? >> >> Most likely, but it does not matter as the packet will fail window >> check, thus will be considered as retransmission or old packet, and >> thrown away (it might trigger retransmission of responders reply in >> case it was packet in the window). >> >> Note, that this can only happen if the other is non-conforming, or >> there is attacker between which modifies the IV. Conforming >> implementation will use same IV all time. >> >> > Question 2: >> > If the answer to Question 1 is no, what should the recipient do? >> > Just ignore it? Abandon the IKE_SA? Or send some Notify? >> >> If recipient has already seen the message before (i.e it has already >> processed it), it can resend its reply. It can also notice that the >> packet is not bitwise-same as previously and the message id is old, >> and silently ignore it. So this is implementation depended what will >> happen. >> >> If it has not seen the message before, then it does not know the IV >> has changed, thus will process the packet normally. >> >> > Question 3: >> > How about IV of retransmitted RESPONSE? >> > Does it need to be identical to the original one too? >> >> The retransmitted response should also be bitwise identical to >> original one. >> >> > It seems to me that the following statement in section 2.1 >> > implicitly requires that. But I'm not sure. >> >> I would agree you that it implicitly requires that. >> >> > Actually, I'm now involved in a IKEv2 implementation that >> > sends retransmitted response with different IV from original one >> > and I cannot tell if the behavior is allowed or not. >> >> I would say it is not allowed, but on the other hand, the other end >> should not ever notice this, as it only process one of the responses >> (the first to reach him), and then ignores rest even before decrypting >> them (when it checks its message id). I.e. it ignores further >> responses to requests it has already received response. >> >> > ikev2bis-04 section 2.1: >> > > =A0 The responder MUST remember each >> > > =A0 response until it receives a request whose sequence number is la= rger >> > > =A0 than or equal to the sequence number in the response plus its wi= ndow >> > > =A0 size (see Section 2.3). >> -- >> kivinen@iki.fi >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > > > -- > For relaxing times, make it Suntory time. - Bob Harris, Lost in Translati= on > From welterk@us.ibm.com Fri Sep 4 09:05:50 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DF9F3A6853 for ; Fri, 4 Sep 2009 09:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkdGlSJXZycA for ; Fri, 4 Sep 2009 09:05:49 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by core3.amsl.com (Postfix) with ESMTP id 891173A6403 for ; Fri, 4 Sep 2009 09:05:49 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e34.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n84G0gwO009236 for ; Fri, 4 Sep 2009 10:00:42 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n84G4nP9244416 for ; Fri, 4 Sep 2009 10:04:49 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n84G4ndu004068 for ; Fri, 4 Sep 2009 10:04:49 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n84G4mgl004062 for ; Fri, 4 Sep 2009 10:04:48 -0600 To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: 10DACF7D:54809C2B-88257627:00574F28; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Keith Welter X-MIMETrack: S/MIME Sign by Notes Client on Keith Welter/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 09/04/2009 09:04:42 AM, Serialize by Notes Client on Keith Welter/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 09/04/2009 09:04:42 AM, Serialize complete at 09/04/2009 09:04:42 AM, S/MIME Sign failed at 09/04/2009 09:04:42 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V851_08302009|August 30, 2009) at 09/04/2009 10:04:48, Serialize complete at 09/04/2009 10:04:48 Message-ID: Date: Fri, 4 Sep 2009 09:04:46 -0700 Content-Type: multipart/alternative; boundary="=_alternative 0058527588257627_=" Subject: Re: [IPsec] Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 16:05:50 -0000 This is a multipart message in MIME format. --=_alternative 0058527588257627_= Content-Type: text/plain; charset="US-ASCII" >>> In an IKE_AUTH >>> exchange, or in the subsequent INFORMATIONAL exchnage, only the >>> following notifications cause the IKE SA to be deleted or not >>> created, without a DELETE payload: >>> o UNSUPPORTED_CRITICAL_PAYLOAD >>> o INVALID_SYNTAX >>> o AUTHENTICATION_FAILED >>> >>> Extension documents may define new error notifications with these >>> semantics, but MUST NOT use them unless the peer is known to >>> understand them. >> >> In subsequent INFORMATIONAL exchanges the UNSUPPORTED_CRITICAL_PAYLOAD >> should not be fatal. It only means that the responder ignored the >> whole message and replied with UNSUPPORTED_CRITICAL_PAYLOAD. That does >> not delete IKE SA. >> >> For the IKE_AUTH the UNSUPPORTED_CRITICAL_PAYLOAD can delete the IKE >> SA as IKE SA is not yet ready. > >That's what I meant. I will clarify this. I would not expect INVALID_SYNTAX to cause the IKE SA to be deleted either. Keith Welter IBM z/OS Communications Server Developer 1-415-545-2694 (T/L: 473-2694) --=_alternative 0058527588257627_= Content-Type: text/html; charset="US-ASCII"
    >>> In an IKE_AUTH
    >>>    exchange, or in the subsequent INFORMATIONAL exchnage, only the
    >>>    following notifications cause the IKE SA to be deleted or not
    >>>    created, without a DELETE payload:
    >>>    o  UNSUPPORTED_CRITICAL_PAYLOAD
    >>>    o  INVALID_SYNTAX
    >>>    o  AUTHENTICATION_FAILED
    >>>
    >>>    Extension documents may define new error notifications with these
    >>>    semantics, but MUST NOT use them unless the peer is known to
    >>>    understand them.
    >>
    >> In subsequent INFORMATIONAL exchanges the UNSUPPORTED_CRITICAL_PAYLOAD
    >> should not be fatal. It only means that the responder ignored the
    >> whole message and replied with UNSUPPORTED_CRITICAL_PAYLOAD. That does
    >> not delete IKE SA.
    >>
    >> For the IKE_AUTH the UNSUPPORTED_CRITICAL_PAYLOAD can delete the IKE
    >> SA as IKE SA is not yet ready.
    >
    >That's what I meant. I will clarify this.
    I would not expect INVALID_SYNTAX to cause the IKE SA to be deleted either.

    Keith Welter
    IBM z/OS Communications Server Developer
    1-415-545-2694 (T/L: 473-2694)
     --=_alternative 0058527588257627_=-- From welterk@us.ibm.com Fri Sep 4 09:54:14 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B36B3A6947 for ; Fri, 4 Sep 2009 09:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VP9FTxZ9QxI2 for ; Fri, 4 Sep 2009 09:54:13 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by core3.amsl.com (Postfix) with ESMTP id 8645F3A69AF for ; Fri, 4 Sep 2009 09:54:13 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e33.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n84GOD93029545 for ; Fri, 4 Sep 2009 10:24:13 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n84GQBGZ128328 for ; Fri, 4 Sep 2009 10:26:14 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n84GQA1b024452 for ; Fri, 4 Sep 2009 10:26:10 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n84GQAM7024447 for ; Fri, 4 Sep 2009 10:26:10 -0600 To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: 12189896:84473BA6-88257627:0059886F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Keith Welter X-MIMETrack: S/MIME Sign by Notes Client on Keith Welter/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 09/04/2009 09:26:06 AM, Serialize by Notes Client on Keith Welter/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 09/04/2009 09:26:06 AM, Serialize complete at 09/04/2009 09:26:06 AM, S/MIME Sign failed at 09/04/2009 09:26:06 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V851_08302009|August 30, 2009) at 09/04/2009 10:26:10, Serialize complete at 09/04/2009 10:26:10 Message-ID: Date: Fri, 4 Sep 2009 09:26:10 -0700 Content-Type: multipart/alternative; boundary="=_alternative 005A47FF88257627_=" Subject: [IPsec] Fw: Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 16:54:14 -0000 This is a multipart message in MIME format. --=_alternative 005A47FF88257627_= Content-Type: text/plain; charset="US-ASCII" > >>> In an IKE_AUTH > >>> exchange, or in the subsequent INFORMATIONAL exchnage, only the > >>> following notifications cause the IKE SA to be deleted or not > >>> created, without a DELETE payload: > >>> o UNSUPPORTED_CRITICAL_PAYLOAD > >>> o INVALID_SYNTAX > >>> o AUTHENTICATION_FAILED > >>> > >>> Extension documents may define new error notifications with these > >>> semantics, but MUST NOT use them unless the peer is known to > >>> understand them. > >> > >> In subsequent INFORMATIONAL exchanges the UNSUPPORTED_CRITICAL_PAYLOAD > >> should not be fatal. It only means that the responder ignored the > >> whole message and replied with UNSUPPORTED_CRITICAL_PAYLOAD. That does > >> not delete IKE SA. > >> > >> For the IKE_AUTH the UNSUPPORTED_CRITICAL_PAYLOAD can delete the IKE > >> SA as IKE SA is not yet ready. > > > >That's what I meant. I will clarify this. > I would not expect INVALID_SYNTAX to cause the IKE SA to be deleted either. Actually, my last statement was overly simplistic. I should have said that there is at least one case when I would not expect INVALID_SYNTAX to cause the IKE SA to be deleted; specifically, when it is included in a CREATE_CHILD_SA exchange. However, I wonder if it is sufficient for an INVALID_SYNTAX in an INFORMATIONAL exchange to cause an IKE SA to be deleted without including a delete payload for the IKE SA. It seems potentially ambiguous what an implementation should do if an INFORMATIONAL message contains only INVALID_SYNTAX whereas the addition of a delete payload for the IKE SA makes the situation clear. Keith Welter IBM z/OS Communications Server Developer 1-415-545-2694 (T/L: 473-2694) --=_alternative 005A47FF88257627_= Content-Type: text/html; charset="US-ASCII"
    > >>> In an IKE_AUTH
    > >>>    exchange, or in the subsequent INFORMATIONAL exchnage, only the
    > >>>    following notifications cause the IKE SA to be deleted or not
    > >>>    created, without a DELETE payload:
    > >>>    o  UNSUPPORTED_CRITICAL_PAYLOAD
    > >>>    o  INVALID_SYNTAX
    > >>>    o  AUTHENTICATION_FAILED
    > >>>
    > >>>    Extension documents may define new error notifications with these
    > >>>    semantics, but MUST NOT use them unless the peer is known to
    > >>>    understand them.
    > >>
    > >> In subsequent INFORMATIONAL exchanges the UNSUPPORTED_CRITICAL_PAYLOAD
    > >> should not be fatal. It only means that the responder ignored the
    > >> whole message and replied with UNSUPPORTED_CRITICAL_PAYLOAD. That does
    > >> not delete IKE SA.
    > >>
    > >> For the IKE_AUTH the UNSUPPORTED_CRITICAL_PAYLOAD can delete the IKE
    > >> SA as IKE SA is not yet ready.
    > >
    > >That's what I meant. I will clarify this.
    > I would not expect INVALID_SYNTAX to cause the IKE SA to be deleted either.
    Actually, my last statement was overly simplistic.  I should have said that
    there is at least one case when I would not expect INVALID_SYNTAX to cause
    the IKE SA to be deleted; specifically, when it is included in a
    CREATE_CHILD_SA exchange.  However, I wonder if it is sufficient for an
    INVALID_SYNTAX in an INFORMATIONAL exchange to cause an IKE SA to be deleted
    without including a delete payload for the IKE SA.  It seems potentially
    ambiguous what an implementation should do if an INFORMATIONAL message
    contains only INVALID_SYNTAX whereas the addition of a delete payload for
    the IKE SA makes the situation clear.

    Keith Welter
    IBM z/OS Communications Server Developer
    1-415-545-2694 (T/L: 473-2694)
     --=_alternative 005A47FF88257627_=-- From ynir@checkpoint.com Fri Sep 4 12:12:15 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32C543A679F for ; Fri, 4 Sep 2009 12:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.205 X-Spam-Level: X-Spam-Status: No, score=-3.205 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEM9zY0L3X9A for ; Fri, 4 Sep 2009 12:12:13 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 34F2A3A672E for ; Fri, 4 Sep 2009 12:12:12 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n84J9K3P012648; Fri, 4 Sep 2009 22:09:20 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 4 Sep 2009 22:09:17 +0300 From: Yoav Nir To: Keith Welter Date: Fri, 4 Sep 2009 22:09:17 +0300 Thread-Topic: [IPsec] Fw: Issue #26: Missing treatment of error cases Thread-Index: AcotkzNJSMzW/jsPRlmIEP9wIy548w== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B0720312CA144800843A4C66B3EDBB61checkpointcom_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Fw: Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 19:12:15 -0000 --_000_B0720312CA144800843A4C66B3EDBB61checkpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Then I should have explained better. If an initiator sees an error in the response, the exchange is already over= , so the only way it can notify the responder of the error, is to create a = new INFORMATIONAL exchange with an error notification. All the text here discusses the one INFORMATIONAL exchange that immediately= follows the IKE_AUTH exchange. If that contains an INVALID_SYNTAX, it rela= tes to the response to the IKE_AUTH exchange, and it means that the creatio= n of the IKE SA failed. In any other place, such as a CCSA or an INFORMATIONAL, or in an INFORMATI= ONAL that follows one of those exchanges, an INVALID_SYNTAX just means that= the previous message was ignored. On Sep 4, 2009, at 7:26 PM, Keith Welter wrote: > >>> In an IKE_AUTH > >>> exchange, or in the subsequent INFORMATIONAL exchnage, only the > >>> following notifications cause the IKE SA to be deleted or not > >>> created, without a DELETE payload: > >>> o UNSUPPORTED_CRITICAL_PAYLOAD > >>> o INVALID_SYNTAX > >>> o AUTHENTICATION_FAILED > >>> > >>> Extension documents may define new error notifications with these > >>> semantics, but MUST NOT use them unless the peer is known to > >>> understand them. > >> > >> In subsequent INFORMATIONAL exchanges the UNSUPPORTED_CRITICAL_PAYLOAD > >> should not be fatal. It only means that the responder ignored the > >> whole message and replied with UNSUPPORTED_CRITICAL_PAYLOAD. That does > >> not delete IKE SA. > >> > >> For the IKE_AUTH the UNSUPPORTED_CRITICAL_PAYLOAD can delete the IKE > >> SA as IKE SA is not yet ready. > > > >That's what I meant. I will clarify this. > I would not expect INVALID_SYNTAX to cause the IKE SA to be deleted eithe= r. Actually, my last statement was overly simplistic. I should have said that there is at least one case when I would not expect INVALID_SYNTAX to cause the IKE SA to be deleted; specifically, when it is included in a CREATE_CHILD_SA exchange. However, I wonder if it is sufficient for an INVALID_SYNTAX in an INFORMATIONAL exchange to cause an IKE SA to be delete= d without including a delete payload for the IKE SA. It seems potentially ambiguous what an implementation should do if an INFORMATIONAL message contains only INVALID_SYNTAX whereas the addition of a delete payload for the IKE SA makes the situation clear. Keith Welter IBM z/OS Communications Server Developer 1-415-545-2694 (T/L: 473-2694) Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_B0720312CA144800843A4C66B3EDBB61checkpointcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Then I should have explain= ed better.

    If an initiator sees an error in the response= , the exchange is already over, so the only way it can notify the responder= of the error, is to create a new INFORMATIONAL exchange with an error noti= fication.

    All the text here discusses the one INFO= RMATIONAL exchange that immediately follows the IKE_AUTH exchange. If that = contains an INVALID_SYNTAX, it relates to the response to the IKE_AUTH exch= ange, and it means that the creation of the IKE SA failed.

    In any other place, such as a CCSA or an INFORMATIONAL,  or i= n an INFORMATIONAL that follows one of those exchanges, an INVALID_SYNTAX j= ust means that the previous message was ignored.

    <= br>
    On Sep 4, 2009, at 7:26 PM, Keith Welter wrote:


    > >>> In an IKE_AUTH
    > >>>    exchange, or in the subsequent INFORMATIONAL exchnage, only the
    > >>>    following notificat= ions cause the IKE SA to be deleted or not
    > >>>    created, without a DELETE payload:
    > >>>    o  UNSUPPORTED= _CRITICAL_PAYLOAD
    > >>>    o  INVALID_SYN= TAX
    > >>>    o  AUTHENTICAT= ION_FAILED
    > >>>
    > >>>    Extension documents may define new error notifications with these
    > >>>    semantics, but MUST NOT use them unless the peer is known to
    > >>>    understand them.
    > >>
    > >> In subsequent INFORMATIONAL exchange= s the UNSUPPORTED_CRITICAL_PAYLOAD
    > >> should not be fatal. It only means t= hat the responder ignored the
    > >> whole message and replied with UNSUP= PORTED_CRITICAL_PAYLOAD. That does
    > >> not delete IKE SA.
    > >>
    > >> For the IKE_AUTH the UNSUPPORTED_CRI= TICAL_PAYLOAD can delete the IKE
    > >> SA as IKE SA is not yet ready.
    > >
    > >That's what I meant. I will clarify this.=
    > I would not expect INVALID_SYNTAX to cause th= e IKE SA to be deleted either.
    Actually, my last statement was overly simplistic.  I should have said that
    there is at least one case when I would not expect INVALID_SYNTAX to cause
    the IKE SA to be deleted; specifically, when it is included in a
    CREATE_CHILD_SA exchange.  However, I wonder if it is sufficient for an
    INVALID_SYNTAX in an INFORMATIONAL exchange to cau= se an IKE SA to be deleted
    without including a delete payload for the IKE SA.  It seems potentially
    ambiguous what an implementation should do if an I= NFORMATIONAL message
    contains only INVALID_SYNTAX whereas the addition of a delete payload for
    the IKE SA makes the situation clear.

    Keith Welter
    IBM z/OS Communications Server Developer
    1-415-545-2694 (T/L: 473-2694)

    Scanned by Check Point Total Security Gateway.

    _______________________________________________
    IPsec mailing li= st
    IPsec@ietf.org
    https://www.i= etf.org/mailman/listinfo/ipsec

    = --_000_B0720312CA144800843A4C66B3EDBB61checkpointcom_-- From ynir@checkpoint.com Fri Sep 4 12:24:41 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FBAA3A685F for ; Fri, 4 Sep 2009 12:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.241 X-Spam-Level: X-Spam-Status: No, score=-3.241 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ugd9HpfdvPBv for ; Fri, 4 Sep 2009 12:24:40 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 5B4183A681B for ; Fri, 4 Sep 2009 12:24:40 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n84JAL3P012850; Fri, 4 Sep 2009 22:10:22 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 4 Sep 2009 22:10:19 +0300 From: Yoav Nir To: David Wierbowski Date: Fri, 4 Sep 2009 22:10:19 +0300 Thread-Topic: [IPsec] Issue #26: Missing treatment of error cases Thread-Index: Acotk1gZlfUsiCfhTyuuZo99zf0dDA== Message-ID: <439E12F5-F278-40AB-8C47-76FC88C47EFA@checkpoint.com> References: <97EF486C-AECE-4A5F-9D15-0A3D554AD4BA@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_439E12F5F27840AB8C4776FC88C47EFAcheckpointcom_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Keith Welter Subject: Re: [IPsec] Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 19:24:41 -0000 --_000_439E12F5F27840AB8C4776FC88C47EFAcheckpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Sep 4, 2009, at 5:53 PM, David Wierbowski wrote: >Yes, I will soften the language a bit, but I won't mention a DELETE payloa= d. If some implementations do it. >others may come to expect it. We don't want to encourage that by suggestin= g that it's a good idea. Yoav, Why is it a a bad idea to include a DELETE payload in this case? Because the IKE SA was not really created, so there is no IKE SA to delete.= It's a bad idea because it is superfluous, and we don't want to risk anyon= e relying on this. --_000_439E12F5F27840AB8C4776FC88C47EFAcheckpointcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    On Sep 4, 20= 09, at 5:53 PM, David Wierbowski wrote:

    >Yes, I wil= l soften the language a bit, but I won't mention a DELETE payload. If some = implementations do it.
    >others may come to expect it. We don't want to encoura= ge that by suggesting that it's a good idea.

    Yoav, Why is it a a bad idea to include a DELETE payload i= n this case?


      Because the IKE SA was not really created= , so there is no IKE SA to delete. It's a bad idea because it is superfluou= s, and we don't want to risk anyone relying on this.
      = --_000_439E12F5F27840AB8C4776FC88C47EFAcheckpointcom_-- From welterk@us.ibm.com Fri Sep 4 12:25:10 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4E433A6877 for ; Fri, 4 Sep 2009 12:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3kzgFVKGbXz for ; Fri, 4 Sep 2009 12:25:09 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by core3.amsl.com (Postfix) with ESMTP id 979F93A6826 for ; Fri, 4 Sep 2009 12:25:09 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n84JKGY7003878 for ; Fri, 4 Sep 2009 13:20:16 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n84JOw2Z174194 for ; Fri, 4 Sep 2009 13:24:59 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n84JOwdq030449 for ; Fri, 4 Sep 2009 13:24:58 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n84JOwc5030422; Fri, 4 Sep 2009 13:24:58 -0600 In-Reply-To: References: To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: BF05C2C9:73D42576-88257627:006A366B; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Keith Welter X-MIMETrack: S/MIME Sign by Notes Client on Keith Welter/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 09/04/2009 12:24:55 PM, Serialize by Notes Client on Keith Welter/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 09/04/2009 12:24:55 PM, Serialize complete at 09/04/2009 12:24:55 PM, S/MIME Sign failed at 09/04/2009 12:24:55 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V851_08302009|August 30, 2009) at 09/04/2009 13:24:58, Serialize complete at 09/04/2009 13:24:58 Message-ID: Date: Fri, 4 Sep 2009 12:24:56 -0700 Content-Type: multipart/alternative; boundary="=_alternative 006AA6CB88257627_=" Cc: Yoav Nir Subject: Re: [IPsec] Fw: Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 19:25:11 -0000 This is a multipart message in MIME format. --=_alternative 006AA6CB88257627_= Content-Type: text/plain; charset="US-ASCII" > Re: [IPsec] Fw: Issue #26: Missing treatment of error cases > > Then I should have explained better. > > If an initiator sees an error in the response, the exchange is already over, so the > only way it can notify the responder of the error, is to create a new INFORMATIONAL > exchange with an error notification. > > All the text here discusses the one INFORMATIONAL exchange that immediately follows > the IKE_AUTH exchange. If that contains an INVALID_SYNTAX, it relates to the > response to the IKE_AUTH exchange, and it means that the creation of the IKE SA failed. In this case, the INVALID_SYNTAX could relate to the SA, TSi or TSr payload in the IKE_AUTH response which would would mean that creation of the CHILD SA failed, not the IKE SA. I think INVALID_SYNTAX is ambiguous here without an explicit delete payload for either the IKE SA or the CHILD SA. > > In any other place, such as a CCSA or an INFORMATIONAL, or in an INFORMATIONAL > that follows one of those exchanges, an INVALID_SYNTAX just means that the previous > message was ignored. > > On Sep 4, 2009, at 7:26 PM, Keith Welter wrote: > > > > >>> In an IKE_AUTH > > >>> exchange, or in the subsequent INFORMATIONAL exchnage, only the > > >>> following notifications cause the IKE SA to be deleted or not > > >>> created, without a DELETE payload: > > >>> o UNSUPPORTED_CRITICAL_PAYLOAD > > >>> o INVALID_SYNTAX > > >>> o AUTHENTICATION_FAILED > > >>> > > >>> Extension documents may define new error notifications with these > > >>> semantics, but MUST NOT use them unless the peer is known to > > >>> understand them. > > >> > > >> In subsequent INFORMATIONAL exchanges the UNSUPPORTED_CRITICAL_PAYLOAD > > >> should not be fatal. It only means that the responder ignored the > > >> whole message and replied with UNSUPPORTED_CRITICAL_PAYLOAD. That does > > >> not delete IKE SA. > > >> > > >> For the IKE_AUTH the UNSUPPORTED_CRITICAL_PAYLOAD can delete the IKE > > >> SA as IKE SA is not yet ready. > > > > > >That's what I meant. I will clarify this. > > I would not expect INVALID_SYNTAX to cause the IKE SA to be deleted either. > Actually, my last statement was overly simplistic. I should have said that > there is at least one case when I would not expect INVALID_SYNTAX to cause > the IKE SA to be deleted; specifically, when it is included in a > CREATE_CHILD_SA exchange. However, I wonder if it is sufficient for an > INVALID_SYNTAX in an INFORMATIONAL exchange to cause an IKE SA to be deleted > without including a delete payload for the IKE SA. It seems potentially > ambiguous what an implementation should do if an INFORMATIONAL message > contains only INVALID_SYNTAX whereas the addition of a delete payload for > the IKE SA makes the situation clear. > > Keith Welter > IBM z/OS Communications Server Developer > 1-415-545-2694 (T/L: 473-2694) > > > Scanned by Check Point Total Security Gateway. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 006AA6CB88257627_= Content-Type: text/html; charset="US-ASCII"
      > Re: [IPsec] Fw:  Issue #26: Missing treatment of error cases
      >
      > Then I should have explained better.
      >
      > If an initiator sees an error in the response, the exchange is already over, so the
      > only way it can notify the responder of the error, is to create a new INFORMATIONAL
      > exchange with an error notification.
      >
      > All the text here discusses the one INFORMATIONAL exchange that immediately follows
      > the IKE_AUTH exchange. If that contains an INVALID_SYNTAX, it relates to the
      > response to the IKE_AUTH exchange, and it means that the creation of the IKE SA failed.
      In this case, the INVALID_SYNTAX could relate to the SA, TSi or TSr payload in the
      IKE_AUTH response which would would mean that creation of the CHILD SA failed,
      not the IKE SA.  I think INVALID_SYNTAX is ambiguous here without an explicit delete
      payload for either the IKE SA or the CHILD SA.

      >
      > In any other place, such as a CCSA or an INFORMATIONAL,  or in an INFORMATIONAL
      > that follows one of those exchanges, an INVALID_SYNTAX just means that the previous
      > message was ignored.
      >
      > On Sep 4, 2009, at 7:26 PM, Keith Welter wrote:
      >
      >
      > > >>> In an IKE_AUTH
      > > >>>    exchange, or in the subsequent INFORMATIONAL exchnage, only the
      > > >>>    following notifications cause the IKE SA to be deleted or not
      > > >>>    created, without a DELETE payload:
      > > >>>    o  UNSUPPORTED_CRITICAL_PAYLOAD
      > > >>>    o  INVALID_SYNTAX
      > > >>>    o  AUTHENTICATION_FAILED
      > > >>>
      > > >>>    Extension documents may define new error notifications with these
      > > >>>    semantics, but MUST NOT use them unless the peer is known to
      > > >>>    understand them.
      > > >>
      > > >> In subsequent INFORMATIONAL exchanges the UNSUPPORTED_CRITICAL_PAYLOAD
      > > >> should not be fatal. It only means that the responder ignored the
      > > >> whole message and replied with UNSUPPORTED_CRITICAL_PAYLOAD. That does
      > > >> not delete IKE SA.
      > > >>
      > > >> For the IKE_AUTH the UNSUPPORTED_CRITICAL_PAYLOAD can delete the IKE
      > > >> SA as IKE SA is not yet ready.
      > > >
      > > >That's what I meant. I will clarify this.
      > > I would not expect INVALID_SYNTAX to cause the IKE SA to be deleted either.
      > Actually, my last statement was overly simplistic.  I should have said that
      > there is at least one case when I would not expect INVALID_SYNTAX to cause
      > the IKE SA to be deleted; specifically, when it is included in a
      > CREATE_CHILD_SA exchange.  However, I wonder if it is sufficient for an
      > INVALID_SYNTAX in an INFORMATIONAL exchange to cause an IKE SA to be deleted
      > without including a delete payload for the IKE SA.  It seems potentially
      > ambiguous what an implementation should do if an INFORMATIONAL message
      > contains only INVALID_SYNTAX whereas the addition of a delete payload for
      > the IKE SA makes the situation clear.
      >
      > Keith Welter
      > IBM z/OS Communications Server Developer
      > 1-415-545-2694 (T/L: 473-2694)
      >
      >
      > Scanned by Check Point Total Security Gateway.
      >
      > _______________________________________________
      > IPsec mailing list
      > IPsec@ietf.org
      >       https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 006AA6CB88257627_=-- From charliek@microsoft.com Fri Sep 4 18:13:06 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F2D13A6803; Fri, 4 Sep 2009 18:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fN1k7gqlUqzF; Fri, 4 Sep 2009 18:12:56 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id A4F383A67BE; Fri, 4 Sep 2009 18:12:56 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 4 Sep 2009 18:13:18 -0700 Received: from TK5EX14MBXC119.redmond.corp.microsoft.com ([169.254.10.174]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi; Fri, 4 Sep 2009 18:13:17 -0700 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "vijay@wichorus.com" , "kilian.weniger@googlemail.com" , "paul.hoffman@vpnc.org" , "yaronf@checkpoint.com" Thread-Topic: Secdir review of draft-ietf-ipsecme-ikev2-redirect-13.txt Thread-Index: AcotxgwTdsxHGi2mR0iwfcuQom5JTg== Date: Sat, 5 Sep 2009 01:13:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_D80EDFF2AD83E648BD1164257B9B09121C4201TK5EX14MBXC119red_" MIME-Version: 1.0 X-Mailman-Approved-At: Sat, 05 Sep 2009 08:23:48 -0700 Cc: "ipsec@ietf.org" Subject: [IPsec] Secdir review of draft-ietf-ipsecme-ikev2-redirect-13.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2009 01:13:06 -0000 --_000_D80EDFF2AD83E648BD1164257B9B09121C4201TK5EX14MBXC119red_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am reviewing this document as part of the security directorate's ongoing = effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the security area directors= . Document editors and WG chairs should treat these comments just like any= other last call comments. Feel free to forward to any appropriate forum. This document specifies an extension to IKEv2 supporting the case where the= accepting end of an IPsec Security Association wants to redirect the initi= ating end to connect to a different address than the one it tried first. Us= es include connections to a server or gateway that wants to balance the loa= d among several equivalent instances, finding the closest instance with Any= cast addresses and then redirecting the a fixed address, dealing with the o= rderly shutdown of a replicated service or gateway, and supporting IPv6 mob= ility. The document specifies how to do the redirection at three different = protocol stages: during connection establishment before the client authenti= cates to the server, during connection establishment after authentication b= ut before an ESP or AH security association is established, or after protec= ted traffic has already started flowing. I found no security problems with the protocol. There does appear to be one critical missing piece of functionality, howeve= r. I would expect that any protocol that has clients connecting to gateways= should work through NATs. The protocol specified in this document does not= say how to do that, though the changes would be fairly simple and (I would= think) non-controversial. It's possible that they are considered "obvious"= and that this protocol is intended to be used with NATs, but I doubt it. T= here may have been some previous discussion of this on the IPsec list that = I missed. Had I been involved with the design, there are some other suggestions I wou= ld have made. It's late in the process now, so feel free to rule them out o= f order for lateness, but I can't resist stating them: 1) If the initiator of the connection requests and obtains an "inner" = IP address from the gateway, then in order to switch to a different gateway= without tearing down existing TCP connections it would need to get that sa= me IP address assigned by the new gateway. For a graceful transition from o= ld to new, the initiator would want to make the new IKE connection before b= reaking the old one. But the new gateway cannot safely allocate the same IP= address while the old connection is still open unless it somehow knows tha= t it is talking to the same client and that a transition is in progress. It= would seem desirable to put some indicator in the protocol to signal that = case. Otherwise, IPv6 mobility and any other gateway move is going to be ve= ry disruptive for clients. 2) To deal with gateways that are behind NATs, it would seem helpful f= or redirection to be able to specify not just the new IP address but also t= he new port. If the port were other than 500, the initiator should assume i= t should use the UDP encapsulation protocol rather than ESP or AH directly. 3) The cookie and alternate Diffie-Hellman group negotiations are desi= gned to take place in parallel to avoid extra round trips. It might be desi= rable to integrate IP redirection into the same exchange for the same reaso= n. That way the initial message pair could do any subset of the three funct= ions. 4) This document creates a new IANA registry for "GW Ident Type" (gate= way identifier type) with three values: IPv4 address, IPv6 address, and DNS= name. I would have instead reused the existing registry "ID type" and rest= rict the value to one of those three values in this context. I also would h= ave had a two byte length for the gateway identifier. There may already be = some architectural limit of 255 octets for a DNS name, but what with intern= ationalization and other such things, I wouldn't wire it into a new protoco= l. 5) The spec seems a little squishy on the question of whether redirect= ion only changes the address at which to find the gateway or whether it als= o affects the authenticated name (in other words, whether a redirection fro= m gateway1.example.com to gateway27.example.com means that the client shoul= d now accept a certificate containing the name gateway27.example.com. It is= pretty clear that in the first (unauthenticated) redirection type, accepti= ng a new name would clearly be unacceptable because it would trivially allo= w gateway spoofing. But when it occurs after the first gateway has authenti= cated, the appropriate policy is less clear. I couldn't figure out whether = it was disallowed in all cases or not. Some more minor issues: 1) First line of abstract: "IKEv2 is a protocol for setting..." -> "IK= Ev2 is a protocol that can be used for setting..." 2) Last two lines of page 2: "The gateway MUST keep track of those cli= ents that indicated support..." This statement is only true for gateways t= hat themselves support redirection. If they don't, they can ignore such ind= icators. 3) Middle of page 6: "one of the VPN gateway." -> "one of the VPN gate= ways." 4) Section 7 (Handling Redirect Loops): This section mandates a defaul= t maximum number of redirects and a default time limit over which that defa= ult applies. The IKEv2 spec goes out of its way to never specify such count= s and timeouts, because the appropriate values are scenario dependent and t= he protocol is designed so that the values never affect interoperability. I= n this case, the values chosen still do not affect interoperability. I woul= d recommend that the spec recommend these values rather than mandate them a= s defaults. 5) This document defines some new IANA code points but calls for other= s to be assigned by IANA. Unless there is some convention to the contrary o= r other good reason, I'd propose values for all of the code points rather t= han expecting the RFC editor to do it as the document is made into an RFC. = This makes life simpler for the RFC editor and makes it possible to impleme= nt prototypes before the spec is advanced. 6) Middle of page 5: "cannot also" -> "also cannot" 7) Last sentence of section 11: "and should be done" -> "and redirecti= on should be done" --_000_D80EDFF2AD83E648BD1164257B9B09121C4201TK5EX14MBXC119red_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

      I am reviewing this document as part of t= he security directorate's ongoing effort to review all IETF documents being= processed by the IESG.  These comments were written primarily for the= benefit of the security area directors.  Document editors and WG chai= rs should treat these comments just like any other last call comments. Feel= free to forward to any appropriate forum.

       

      This document specifies= an extension to IKEv2 supporting the case where the accepting end of an IP= sec Security Association wants to redirect the initiating end to connect to= a different address than the one it tried first. Uses include connections = to a server or gateway that wants to balance the load among several equival= ent instances, finding the closest instance with Anycast addresses and then= redirecting the a fixed address, dealing with the orderly shutdown of a re= plicated service or gateway, and supporting IPv6 mobility. The document spe= cifies how to do the redirection at three different protocol stages: during= connection establishment before the client authenticates to the server, du= ring connection establishment after authentication but before an ESP or AH = security association is established, or after protected traffic has already= started flowing.

       

      <= p class=3DMsoNormal>I found no security problems with the protocol.

       

      There= does appear to be one critical missing piece of functionality, however. I = would expect that any protocol that has clients connecting to gateways shou= ld work through NATs. The protocol specified in this document does not say = how to do that, though the changes would be fairly simple and (I would thin= k) non-controversial. It’s possible that they are considered “o= bvious” and that this protocol is intended to be used with NATs, but = I doubt it. There may have been some previous discussion of this on the IPs= ec list that I missed.

       =

      Had I been involved with the design, there are som= e other suggestions I would have made. It’s late in the process now, = so feel free to rule them out of order for lateness, but I can’t resi= st stating them:

       

      1)      <= ![endif]>If the initiator of the connection requests and obtains an “= inner” IP address from the gateway, then in order to switch to a diff= erent gateway without tearing down existing TCP connections it would need t= o get that same IP address assigned by the new gateway. For a graceful tran= sition from old to new, the initiator would want to make the new IKE connec= tion before breaking the old one. But the new gateway cannot safely allocat= e the same IP address while the old connection is still open unless it some= how knows that it is talking to the same client and that a transition is in= progress. It would seem desirable to put some indicator in the protocol to= signal that case. Otherwise, IPv6 mobility and any other gateway move is g= oing to be very disruptive for clients.

      2)      To deal wi= th gateways that are behind NATs, it would seem helpful for redirection to = be able to specify not just the new IP address but also the new port. If th= e port were other than 500, the initiator should assume it should use the U= DP encapsulation protocol rather than ESP or AH directly.

      3)      The cookie and alternate Diffie-Hellman group negotiations are desi= gned to take place in parallel to avoid extra round trips. It might be desi= rable to integrate IP redirection into the same exchange for the same reaso= n. That way the initial message pair could do any subset of the three funct= ions.

      4)    =   This document creates a new IANA registry fo= r “GW Ident Type” (gateway identifier type) with three values: = IPv4 address, IPv6 address, and DNS name. I would have instead reused the e= xisting registry “ID type” and restrict the value to one of tho= se three values in this context. I also would have had a two byte length fo= r the gateway identifier. There may already be some architectural limit of = 255 octets for a DNS name, but what with internationalization and other suc= h things, I wouldn’t wire it into a new protocol.

      5)      The spec seems a little squishy on the question of whether redirectio= n only changes the address at which to find the gateway or whether it also = affects the authenticated name (in other words, whether a redirection from = gateway1.example.com to gateway27.example.com means that the client should = now accept a certificate containing the name gateway27.example.com. It is p= retty clear that in the first (unauthenticated) redirection type, accepting= a new name would clearly be unacceptable because it would trivially allow = gateway spoofing. But when it occurs after the first gateway has authentica= ted, the appropriate policy is less clear. I couldn’t figure out whet= her it was disallowed in all cases or not.

       

      Some more minor issues:

       

      1)      First line of = abstract: “IKEv2 is a protocol for setting…” -> “= ;IKEv2 is a protocol that can be used for setting…”<= /p>

      2)      Last two lines of page 2: “The gateway MUST keep track = of those clients that indicated support…”  This statement = is only true for gateways that themselves support redirection. If they don&= #8217;t, they can ignore such indicators.

      3)      Middle o= f page 6: “one of the VPN gateway.” -> “one of the VPN= gateways.”

      4)  =     Section 7 (Handling Redirect Loo= ps): This section mandates a default maximum number of redirects and a defa= ult time limit over which that default applies. The IKEv2 spec goes out of = its way to never specify such counts and timeouts, because the appropriate = values are scenario dependent and the protocol is designed so that the valu= es never affect interoperability. In this case, the values chosen still do = not affect interoperability. I would recommend that the spec recommend thes= e values rather than mandate them as defaults.

      5)      Thi= s document defines some new IANA code points but calls for others to be ass= igned by IANA. Unless there is some convention to the contrary or other goo= d reason, I’d propose values for all of the code points rather than e= xpecting the RFC editor to do it as the document is made into an RFC. This = makes life simpler for the RFC editor and makes it possible to implement pr= ototypes before the spec is advanced.

      6)      Middle of pa= ge 5: “cannot also” -> “also cannot”<= /p>

      7)      Last sentence of section 11: “and should be done”= -> “and redirection should be done”

      = --_000_D80EDFF2AD83E648BD1164257B9B09121C4201TK5EX14MBXC119red_-- From rsjenwar@gmail.com Sat Sep 5 18:08:40 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06BD83A6858 for ; Sat, 5 Sep 2009 18:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVujFLEgjqVj for ; Sat, 5 Sep 2009 18:08:38 -0700 (PDT) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id C95D43A6910 for ; Sat, 5 Sep 2009 18:08:38 -0700 (PDT) Received: by pzk42 with SMTP id 42so258259pzk.31 for ; Sat, 05 Sep 2009 18:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=4YdsIYEoAEQidvPVQ7mFg9dWjF75ozBHM5IW/g+/Jus=; b=mFukfb7tLjC1QL6eaOmBh29wJiJ1P3/mKnoY3JA8FcMt27Sr5R4rhiZPc8uDvjCPDP OCD/Es6eMXjEePwtmG85tz/eBiYb4wXfvTTK9u5lIPA+j6/xctBvUHx9qP7AHcEftIkT jc9uzJ3ArSkqg5vH6OMNZFzodXbVxjyGJ0o8Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZmtJeoRSypFbWwckKNP/bklccNOXoXLeyRn73I8tjs5Fd4HuPEU9l4pcr4QS3TXoZ3 OYVrzo6x7EsukNGeqDUxHD3oe3/Wi2MgDQUDB5FU9s4Z6mpD8Nv7xm1TQL3zgGH7K1Jl VIeO3nKkAtgZ1jXSchAuMFV5iB/k3nnNhdZVI= MIME-Version: 1.0 Received: by 10.143.25.38 with SMTP id c38mr431375wfj.11.1252199340282; Sat, 05 Sep 2009 18:09:00 -0700 (PDT) In-Reply-To: References: Date: Sun, 6 Sep 2009 06:39:00 +0530 Message-ID: <7ccecf670909051809k1910936dn8e70d849ba5e9a12@mail.gmail.com> From: Raj Singh To: Keith Welter Content-Type: multipart/alternative; boundary=001636e1f938dd93b20472de605c Cc: ipsec@ietf.org, Yoav Nir Subject: Re: [IPsec] Fw: Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 01:08:40 -0000 --001636e1f938dd93b20472de605c Content-Type: text/plain; charset=UTF-8 Hi Keith, It has been already discussed on the list that each exchange has some mandatory payload types. Firstly, the exchange packet should be checked that it contains all mandatory payload for that exchnage then it should check each payload before actually processing the packet. In your example of is because of SA2, TSi or TSr, then IKE SA should be processed and INVALID_SYNTAX notify should be send. Thanks & Regards, Raj On Sat, Sep 5, 2009 at 12:54 AM, Keith Welter wrote: > > > Re: [IPsec] Fw: Issue #26: Missing treatment of error cases > > > > Then I should have explained better. > > > > If an initiator sees an error in the response, the exchange is already > over, so the > > only way it can notify the responder of the error, is to create a new > INFORMATIONAL > > exchange with an error notification. > > > > All the text here discusses the one INFORMATIONAL exchange that > immediately follows > > the IKE_AUTH exchange. If that contains an INVALID_SYNTAX, it relates to > the > > response to the IKE_AUTH exchange, and it means that the creation of the > IKE SA failed. > In this case, the INVALID_SYNTAX could relate to the SA, TSi or TSr payload > in the > IKE_AUTH response which would would mean that creation of the CHILD SA > failed, > not the IKE SA. I think INVALID_SYNTAX is ambiguous here without an > explicit delete > payload for either the IKE SA or the CHILD SA. > > > > > In any other place, such as a CCSA or an INFORMATIONAL, or in an > INFORMATIONAL > > that follows one of those exchanges, an INVALID_SYNTAX just means that > the previous > > message was ignored. > > > > On Sep 4, 2009, at 7:26 PM, Keith Welter wrote: > > > > > > > >>> In an IKE_AUTH > > > >>> exchange, or in the subsequent INFORMATIONAL exchnage, only the > > > >>> following notifications cause the IKE SA to be deleted or not > > > >>> created, without a DELETE payload: > > > >>> o UNSUPPORTED_CRITICAL_PAYLOAD > > > >>> o INVALID_SYNTAX > > > >>> o AUTHENTICATION_FAILED > > > >>> > > > >>> Extension documents may define new error notifications with > these > > > >>> semantics, but MUST NOT use them unless the peer is known to > > > >>> understand them. > > > >> > > > >> In subsequent INFORMATIONAL exchanges the > UNSUPPORTED_CRITICAL_PAYLOAD > > > >> should not be fatal. It only means that the responder ignored the > > > >> whole message and replied with UNSUPPORTED_CRITICAL_PAYLOAD. That > does > > > >> not delete IKE SA. > > > >> > > > >> For the IKE_AUTH the UNSUPPORTED_CRITICAL_PAYLOAD can delete the IKE > > > > >> SA as IKE SA is not yet ready. > > > > > > > >That's what I meant. I will clarify this. > > > I would not expect INVALID_SYNTAX to cause the IKE SA to be deleted > either. > > Actually, my last statement was overly simplistic. I should have said > that > > there is at least one case when I would not expect INVALID_SYNTAX to > cause > > the IKE SA to be deleted; specifically, when it is included in a > > CREATE_CHILD_SA exchange. However, I wonder if it is sufficient for an > > INVALID_SYNTAX in an INFORMATIONAL exchange to cause an IKE SA to be > deleted > > without including a delete payload for the IKE SA. It seems potentially > > ambiguous what an implementation should do if an INFORMATIONAL message > > contains only INVALID_SYNTAX whereas the addition of a delete payload for > > > the IKE SA makes the situation clear. > > > > Keith Welter > > IBM z/OS Communications Server Developer > > 1-415-545-2694 (T/L: 473-2694) > > > > > > Scanned by Check Point Total Security Gateway. > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --001636e1f938dd93b20472de605c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Keith,

      It has been already discussed on the list that each exchan= ge has some mandatory payload types.
      Firstly, the exchange packet should= be checked that it contains all mandatory payload for that exchnage
      then it should check each payload before actually processing the packet.
      In your example of is because of SA2, TSi or TSr, then IKE SA should b= e processed and INVALID_SYNTAX notify should be send.

      Thanks & R= egards,
      Raj

      On Sat, Sep 5, 2009 at 12:54 AM, Kei= th Welter <welte= rk@us.ibm.com> wrote:

      > Re: [IPsec] Fw: =C2=A0Issue #26: Missing trea= tment of error cases
      >
      > Then I should have explained better.
      >
      > If an initiator sees an error in the response, the exchange is already over, so the
      > only way it can notify the responder of the error, is to create a new INFORMATIONAL
      > exchange with an error notification.
      >
      > All the text here discusses the one INFORMATIONAL exchange that immedi= ately follows
      > the IKE_AUTH exchange. If that contains an INVALID_SYNTAX, it relates to the
      > response to the IKE_AUTH exchange, and it means that the creation of the IKE SA failed.
      In this case, the INVALID_SYNTAX could relat= e to the SA, TSi or TSr payload in the
      IKE_AUTH response which would would mean that crea= tion of the CHILD SA failed,
      not the IKE SA. =C2=A0I think INVALID_SYNTAX is am= biguous here without an explicit delete
      payload for either the IKE SA or the CHILD SA.

      >
      > In any other place, such as a CCSA or an INFORMATIONAL, =C2=A0or in an INFORMATIONAL
      > that follows one of those exchanges, an INVALID_SYNTAX just means that the previous
      > message was ignored.
      >
      > On Sep 4, 2009, at 7:26 PM, Keith Welter wrote:
      >
      >
      > > >>> In an IKE_AUTH
      > > >>> =C2=A0 =C2=A0exchange, or in the subsequent INFORMAT= IONAL exchnage, only the
      > > >>> =C2=A0 =C2=A0following notifications cause the IKE SA to be deleted or not
      > > >>> =C2=A0 =C2=A0created, without a DELETE payload:
      > > >>> =C2=A0 =C2=A0o =C2=A0UNSUPPORTED_CRITICAL_PAYLOAD
      > > >>> =C2=A0 =C2=A0o =C2=A0INVALID_SYNTAX
      > > >>> =C2=A0 =C2=A0o =C2=A0AUTHENTICATION_FAILED
      > > >>>
      > > >>> =C2=A0 =C2=A0Extension documents may define new error notifications with these
      > > >>> =C2=A0 =C2=A0semantics, but MUST NOT use them unless the peer is known to
      > > >>> =C2=A0 =C2=A0understand them.
      > > >>
      > > >> In subsequent INFORMATIONAL exchanges the UNSUPPORTED_CR= ITICAL_PAYLOAD
      > > >> should not be fatal. It only means that the responder ignored the
      > > >> whole message and replied with UNSUPPORTED_CRITICAL_PAYL= OAD. That does
      > > >> not delete IKE SA.
      > > >>
      > > >> For the IKE_AUTH the UNSUPPORTED_CRITICAL_PAYLOAD can delete the IKE
      > > >> SA as IKE SA is not yet ready.
      > > >
      > > >That's what I meant. I will clarify this.
      > > I would not expect INVALID_SYNTAX to cause the IKE SA to be delet= ed either.
      > Actually, my last statement was overly simplistic. =C2=A0I should have said that
      > there is at least one case when I would not expect INVALID_SYNTAX to cause
      > the IKE SA to be deleted; specifically, when it is included in a
      > CREATE_CHILD_SA exchange. =C2=A0However, I wonder if it is sufficient for an
      > INVALID_SYNTAX in an INFORMATIONAL exchange to cause an IKE SA to be deleted
      > without including a delete payload for the IKE SA. =C2=A0It seems potentially
      > ambiguous what an implementation should do if an INFORMATIONAL message
      > contains only INVALID_SYNTAX whereas the addition of a delete payload for
      > the IKE SA makes the situation clear.
      >
      > Keith Welter
      > IBM z/OS Communications Server Developer
      > 1-415-545-2694 (T/L: 473-2694)
      >
      >
      > Scanned by Check Point Total Security Gateway.
      >
      > _______________________________________________
      > IPsec mailing list
      > IPsec@ietf.org=
      >       https://www.ietf.org/mailman/listinfo/= ipsec

      ______________________________________= _________
      IPsec mailing list
      IPsec@ietf.org
      h= ttps://www.ietf.org/mailman/listinfo/ipsec


      --001636e1f938dd93b20472de605c-- From ynir@checkpoint.com Sun Sep 6 00:14:59 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A95423A691A for ; Sun, 6 Sep 2009 00:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.271 X-Spam-Level: X-Spam-Status: No, score=-3.271 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvvS-Yg5kSYn for ; Sun, 6 Sep 2009 00:14:58 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 3FC163A682A for ; Sun, 6 Sep 2009 00:14:57 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n867FK3P014825; Sun, 6 Sep 2009 10:15:20 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 6 Sep 2009 10:15:18 +0300 From: Yoav Nir To: "ipsec@ietf.org WG" , Tero Kivinen Date: Sun, 6 Sep 2009 10:15:17 +0300 Thread-Topic: [IPsec] Issue #26: Missing treatment of error cases Thread-Index: Acouwcljk5l0vgrAQXO6JKXCjMloSw== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 07:14:59 -0000 OK. Let's try this again. Is this acceptable? 2.21. Error Handling There are many kinds of errors that can occur during IKE processing. If a request is received that is badly formatted, or unacceptable =20 for reasons of policy (e.g., no matching cryptographic algorithms), the response MUST contain a Notify payload indicating the error. If an error occurs in the processing of a response, then the initiator SHOULD initiate an INFORMATIONAL exchange with a Notify payload describing the problem. If an error occurs outside the context of =20 an IKE request (e.g., the node is getting ESP messages on a nonexistent SPI), the node SHOULD initiate an INFORMATIONAL exchange with a Notify payload describing the problem. Errors that occur before a cryptographically protected IKE SA is established must be handled very carefully. There is a trade-off between wanting to be helpful in diagnosing a problem and responding to it and wanting to avoid being a dupe in a denial of service =20 attack based on forged messages. If a node receives a message on UDP port 500 or 4500 outside the context of an IKE SA known to it (and not a request to start one), =20 it may be the result of a recent crash of the node. If the message is marked as a response, the node MAY audit the suspicious event but MUST NOT respond. If the message is marked as a request, the node MAY audit the suspicious event and MAY send a response. If a response is sent, the response MUST be sent to the IP address and port from whence it came with the same IKE SPIs and the Message ID copied. The response MUST NOT be cryptographically protected and MUST contain a Notify payload indicating INVALID_IKE_SPI. The INVALID_IKE_SPI notification indicates an IKE message was received with an unrecognized destination SPI; this usually indicates that =20 the recipient has rebooted and forgotten the existence of an IKE SA. A node receiving such an unprotected Notify payload MUST NOT respond and MUST NOT change the state of any existing SAs. The message =20 might be a forgery or might be a response, the genuine correspondent was tricked into sending. A node should treat such a message (and =20 also a network message like ICMP destination unreachable) as a hint that there might be problems with SAs to that IP address and should initiate a liveness check for any such IKE SA. An implementation SHOULD limit the frequency of such tests to avoid being tricked into participating in a denial of service attack. A node receiving a suspicious message from an IP address (and port, if NAT traversal is used) with which it has an IKE SA SHOULD send an IKE Notify payload in an IKE INFORMATIONAL exchange over that SA. The recipient MUST NOT change the state of any SAs as a result, but may wish to audit the event to aid in diagnosing malfunctions. A node MUST limit the rate at which it will send messages in response to unprotected messages. All errors that occur in an IKE_AUTH exchange, causing the authentication to fail for whatever reason (invalid shared secret, invalid ID, untrusted certificate issuer, revoked or expired certificate, etc.) SHOULD result in an AUTHENTICATION_FAILED notification. If the error occurred on the responder, the notification is returned in the protected response, and should be =20 the only payload in that response. If the error occurs on the =20 initiator, the notification MAY be returned in a separate INFORMATIONAL exchange, usually with no other payloads. Note, however, that messages that contain an unsupported critical payload, or where the whole message is malformed (rather than just bad payload contents), MUST be rejected in their entirety, and only lead to an UNSUPPORTED_CRITICAL_PAYLOAD or INVALID_SYNTAX Notification. The receiver should not verify the payloads related to authentication in this case. If authentication has succeeded in the IKE_AUTH exchange, the IKE SA is established, but establishing the child SA, or requesting configuration information may still fail. This failure does not automatically cause the IKE SA to be deleted. Specifically, a responder may include all the payloads associated with =20 authentication (IDr, Cert and AUTH) while sending error notifications for the piggybacked exchanges (FAILED_CP_REQUIRED, INVALID_SELECTORS, NO_PROPOSAL_CHOSEN, etc.), and the initiator MUST NOT fail the authentication because of this. The initiator MAY, of course, for reasons of policy later delete such an IKE SA. Only authentication failures and malformed messages lead to a deletion of the IKE SA without requiring an explicit INFORMATIONAL exchange carrying a DELETE payload. Other error conditions require such an exchange, if policy dictates that this is needed. In an IKE_SA_INIT exchange, any error notification causes the exchange to fail, although some, like COOKIE, INVALID_KE_PAYLOAD or INVALID_MAJOR_VERSION may lead to a subsequent successful exchange. In an IKE_AUTH exchange, or in the INFORMATIONAL exchnage =20 immediately following it, only the following notifications cause the IKE SA to =20 be deleted or not created, without a DELETE payload: o UNSUPPORTED_CRITICAL_PAYLOAD o INVALID_SYNTAX o AUTHENTICATION_FAILED Extension documents may define new error notifications with these semantics, but MUST NOT use them unless the peer is known to understand them. From rsjenwar@gmail.com Sun Sep 6 00:46:42 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62F3028C0F5 for ; Sun, 6 Sep 2009 00:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qkUEYcA4viO for ; Sun, 6 Sep 2009 00:46:41 -0700 (PDT) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id 164B228C0F6 for ; Sun, 6 Sep 2009 00:46:41 -0700 (PDT) Received: by pzk42 with SMTP id 42so372422pzk.31 for ; Sun, 06 Sep 2009 00:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=KH2qiKRb+DnMufXEKDBaURAeNmhLI7i1KZl+Vsk3X2E=; b=gHX+rMasEHhK4LsRx073x7lKfqjsFnzkMbh5NTXVWsqOPe22kvMRRqk9gxP+V6K2Lo 9NNUmzBzp8gTA9hLKbcpOEWjckGCsLDy6gmdmmHf1Jfa8gIA45zFzjyhwww1m93EOGz4 s4f0B7wotROtOCm+9+hE3JcYMsNM+jz1U8CWc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Up5og/cSrUWvhDkz8GbAANez7+8Ca64mVLiT9VAOd7jf2NO7A8mi3YgG8aFPLKceab GCHM3tt9CNosfXgloFjfdazKfJMwhYVk28wHMHT5iqiwMSEF0Di5eXvgrEnZk625ZGWo UY6ydMMOjXwS5YCTSCjV5AADXI1l+tX3slOXc= MIME-Version: 1.0 Received: by 10.142.248.4 with SMTP id v4mr429864wfh.180.1252223221577; Sun, 06 Sep 2009 00:47:01 -0700 (PDT) In-Reply-To: <7ccecf670909051809k1910936dn8e70d849ba5e9a12@mail.gmail.com> References: <7ccecf670909051809k1910936dn8e70d849ba5e9a12@mail.gmail.com> Date: Sun, 6 Sep 2009 13:17:01 +0530 Message-ID: <7ccecf670909060047q5aed19e7o31a6c75c673d4b6@mail.gmail.com> From: Raj Singh To: Keith Welter Content-Type: multipart/alternative; boundary=00504502c9fd4d38b60472e3f04e Cc: ipsec@ietf.org, Yoav Nir Subject: Re: [IPsec] Fw: Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 07:46:42 -0000 --00504502c9fd4d38b60472e3f04e Content-Type: text/plain; charset=UTF-8 Sorry for typos. Please find re-phrased sentance below: In your example, there is error in construction of SA2, TSi or TSr payloads in IKE_AUTH response. Which also means either the implementation is not RFC compliant or system in bad state at responder. As explained below, in this case mandatory payload check for IKE_AUTH will pass, but individual payload verification check will fail. So IKE SA should *NOT* be processed and INVALID_SYNTAX notify should be send. The responder which is not RFC compliant will DELETE its IKE SA, after it's lifetimes expiry or liveness check. Thanks & Regards, Raj On Sun, Sep 6, 2009 at 6:39 AM, Raj Singh wrote: > Hi Keith, > > It has been already discussed on the list that each exchange has some > mandatory payload types. > Firstly, the exchange packet should be checked that it contains all > mandatory payload for that exchnage > then it should check each payload before actually processing the packet. > > In your example of is because of SA2, TSi or TSr, then IKE SA should be > processed and INVALID_SYNTAX notify should be send. > > Thanks & Regards, > Raj > > On Sat, Sep 5, 2009 at 12:54 AM, Keith Welter wrote: > >> >> > Re: [IPsec] Fw: Issue #26: Missing treatment of error cases >> > >> > Then I should have explained better. >> > >> > If an initiator sees an error in the response, the exchange is already >> over, so the >> > only way it can notify the responder of the error, is to create a new >> INFORMATIONAL >> > exchange with an error notification. >> > >> > All the text here discusses the one INFORMATIONAL exchange that >> immediately follows >> > the IKE_AUTH exchange. If that contains an INVALID_SYNTAX, it relates to >> the >> > response to the IKE_AUTH exchange, and it means that the creation of the >> IKE SA failed. >> In this case, the INVALID_SYNTAX could relate to the SA, TSi or TSr >> payload in the >> IKE_AUTH response which would would mean that creation of the CHILD SA >> failed, >> not the IKE SA. I think INVALID_SYNTAX is ambiguous here without an >> explicit delete >> payload for either the IKE SA or the CHILD SA. >> >> > >> > In any other place, such as a CCSA or an INFORMATIONAL, or in an >> INFORMATIONAL >> > that follows one of those exchanges, an INVALID_SYNTAX just means that >> the previous >> > message was ignored. >> > >> > On Sep 4, 2009, at 7:26 PM, Keith Welter wrote: >> > >> > >> > > >>> In an IKE_AUTH >> > > >>> exchange, or in the subsequent INFORMATIONAL exchnage, only the >> >> > > >>> following notifications cause the IKE SA to be deleted or not >> > > >>> created, without a DELETE payload: >> > > >>> o UNSUPPORTED_CRITICAL_PAYLOAD >> > > >>> o INVALID_SYNTAX >> > > >>> o AUTHENTICATION_FAILED >> > > >>> >> > > >>> Extension documents may define new error notifications with >> these >> > > >>> semantics, but MUST NOT use them unless the peer is known to >> > > >>> understand them. >> > > >> >> > > >> In subsequent INFORMATIONAL exchanges the >> UNSUPPORTED_CRITICAL_PAYLOAD >> > > >> should not be fatal. It only means that the responder ignored the >> > > >> whole message and replied with UNSUPPORTED_CRITICAL_PAYLOAD. That >> does >> > > >> not delete IKE SA. >> > > >> >> > > >> For the IKE_AUTH the UNSUPPORTED_CRITICAL_PAYLOAD can delete the >> IKE >> > > >> SA as IKE SA is not yet ready. >> > > > >> > > >That's what I meant. I will clarify this. >> > > I would not expect INVALID_SYNTAX to cause the IKE SA to be deleted >> either. >> > Actually, my last statement was overly simplistic. I should have said >> that >> > there is at least one case when I would not expect INVALID_SYNTAX to >> cause >> > the IKE SA to be deleted; specifically, when it is included in a >> > CREATE_CHILD_SA exchange. However, I wonder if it is sufficient for an >> > INVALID_SYNTAX in an INFORMATIONAL exchange to cause an IKE SA to be >> deleted >> > without including a delete payload for the IKE SA. It seems potentially >> >> > ambiguous what an implementation should do if an INFORMATIONAL message >> > contains only INVALID_SYNTAX whereas the addition of a delete payload >> for >> > the IKE SA makes the situation clear. >> > >> > Keith Welter >> > IBM z/OS Communications Server Developer >> > 1-415-545-2694 (T/L: 473-2694) >> > >> > >> > Scanned by Check Point Total Security Gateway. >> > >> > _______________________________________________ >> > IPsec mailing list >> > IPsec@ietf.org >> > https://www.ietf.org/mailman/listinfo/ipsec >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> > --00504502c9fd4d38b60472e3f04e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry for typos.
      Please find re-phrased sentance below:

      In your e= xample, there is error in construction of SA2, TSi or TSr payloads in IKE_= AUTH response.
      Which also means either the implementation is not RFC com= pliant or system in bad state at responder.
      As explained below, in this case mandatory payload check for IKE_AUTH will = pass, but individual payload verification check will fail.
      So IKE SA sho= uld *NOT* be processed and INVALID_SYNTAX notify should be send.
      The res= ponder which is not RFC compliant will DELETE its IKE SA, after it's li= fetimes expiry or liveness check.

      Thanks & Regards,
      Raj

      On Sun, = Sep 6, 2009 at 6:39 AM, Raj Singh <rsjenwar@gmail.com> wrote:
      Hi Keith,

      It has been already discussed on the list that each exchan= ge has some mandatory payload types.
      Firstly, the exchange packet should= be checked that it contains all mandatory payload for that exchnage
      then it should check each payload before actually processing the packet.
      In your example of is because of SA2, TSi or TSr, then IKE SA should b= e processed and INVALID_SYNTAX notify should be send.

      Thanks & R= egards,
      Raj

      On Sat, Sep 5, 2009 at 12:54 AM, Keith Welter <welterk@us.ibm.com> wrote:

      > Re: [IPsec] Fw: =C2=A0Issue #26: Missing trea= tment of error cases
      >
      > Then I should have explained better.
      >
      > If an initiator sees an error in the response, the exchange is already over, so the
      > only way it can notify the responder of the error, is to create a new INFORMATIONAL
      > exchange with an error notification.
      >
      > All the text here discusses the one INFORMATIONAL exchange that immedi= ately follows
      > the IKE_AUTH exchange. If that contains an INVALID_SYNTAX, it relates to the
      > response to the IKE_AUTH exchange, and it means that the creation of the IKE SA failed.
      In this case, the INVALID_SYNTAX could relat= e to the SA, TSi or TSr payload in the
      IKE_AUTH response which would would mean that crea= tion of the CHILD SA failed,
      not the IKE SA. =C2=A0I think INVALID_SYNTAX is am= biguous here without an explicit delete
      payload for either the IKE SA or the CHILD SA.

      >
      > In any other place, such as a CCSA or an INFORMATIONAL, =C2=A0or in an INFORMATIONAL
      > that follows one of those exchanges, an INVALID_SYNTAX just means that the previous
      > message was ignored.
      >
      > On Sep 4, 2009, at 7:26 PM, Keith Welter wrote:
      >
      >
      > > >>> In an IKE_AUTH
      > > >>> =C2=A0 =C2=A0exchange, or in the subsequent INFORMAT= IONAL exchnage, only the
      > > >>> =C2=A0 =C2=A0following notifications cause the IKE SA to be deleted or not
      > > >>> =C2=A0 =C2=A0created, without a DELETE payload:
      > > >>> =C2=A0 =C2=A0o =C2=A0UNSUPPORTED_CRITICAL_PAYLOAD
      > > >>> =C2=A0 =C2=A0o =C2=A0INVALID_SYNTAX
      > > >>> =C2=A0 =C2=A0o =C2=A0AUTHENTICATION_FAILED
      > > >>>
      > > >>> =C2=A0 =C2=A0Extension documents may define new error notifications with these
      > > >>> =C2=A0 =C2=A0semantics, but MUST NOT use them unless the peer is known to
      > > >>> =C2=A0 =C2=A0understand them.
      > > >>
      > > >> In subsequent INFORMATIONAL exchanges the UNSUPPORTED_CR= ITICAL_PAYLOAD
      > > >> should not be fatal. It only means that the responder ignored the
      > > >> whole message and replied with UNSUPPORTED_CRITICAL_PAYL= OAD. That does
      > > >> not delete IKE SA.
      > > >>
      > > >> For the IKE_AUTH the UNSUPPORTED_CRITICAL_PAYLOAD can delete the IKE
      > > >> SA as IKE SA is not yet ready.
      > > >
      > > >That's what I meant. I will clarify this.
      > > I would not expect INVALID_SYNTAX to cause the IKE SA to be delet= ed either.
      > Actually, my last statement was overly simplistic. =C2=A0I should have said that
      > there is at least one case when I would not expect INVALID_SYNTAX to cause
      > the IKE SA to be deleted; specifically, when it is included in a
      > CREATE_CHILD_SA exchange. =C2=A0However, I wonder if it is sufficient for an
      > INVALID_SYNTAX in an INFORMATIONAL exchange to cause an IKE SA to be deleted
      > without including a delete payload for the IKE SA. =C2=A0It seems potentially
      > ambiguous what an implementation should do if an INFORMATIONAL message
      > contains only INVALID_SYNTAX whereas the addition of a delete payload for
      > the IKE SA makes the situation clear.
      >
      > Keith Welter
      > IBM z/OS Communications Server Developer
      > 1-415-545-2694 (T/L: 473-2694)
      >
      >
      > Scanned by Check Point Total Security Gateway.
      >
      > _______________________________________________
      > IPsec mailing list
      > IPsec@ietf.org=
      >       https://www.ietf.org/mailman/listinfo/= ipsec

      ______________________________________= _________
      IPsec mailing list
      IPsec@ietf.org
      h= ttps://www.ietf.org/mailman/listinfo/ipsec



      --00504502c9fd4d38b60472e3f04e-- From kivinen@iki.fi Mon Sep 7 05:48:08 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E51E63A683C for ; Mon, 7 Sep 2009 05:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFRWZ8G5w2uk for ; Mon, 7 Sep 2009 05:48:08 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id C4C583A694F for ; Mon, 7 Sep 2009 05:48:07 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n87CmVP0028212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Sep 2009 15:48:31 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n87CmUil006029; Mon, 7 Sep 2009 15:48:30 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19109.286.34505.162897@fireball.kivinen.iki.fi> Date: Mon, 7 Sep 2009 15:48:30 +0300 From: Tero Kivinen To: Keith Welter In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 10 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 12:48:09 -0000 Keith Welter writes: > I would not expect INVALID_SYNTAX to cause the IKE SA to be deleted > either. I do consider INVALID_SYNTAX fatal error, meaning the IKE SA will be deleted immediately after sending that response containing INVALID_SYNTAX and if I receive INVALID_SYNTAX notification I will immediately silently delete the IKE SA. INVALID_SYNTAX can only happen in if there bugs in implementations. There is no way it could happen during normal operation, and it is also error which does NOT go way. I.e. if other end has bug that it sends payload whose for example payload length exceeds the packet length, that error will not go away even if we ignore the exchange. Usually receiving INVALID_SYNTAX means there is something seriously wrong in the either implementation, and there is no point of trying to continue connection with it, as future attemtps to communicate will most likely result in same error (or at least cause peers to get out of sync (for example if delete payload had incorrect length and was ignored, then peers do not agree on which SAs are up after that)). As this is only error code that can be fixed by the programmers fixing bugs in implementations, there is no point of writing code to cope with such cases. If such code is written it is most likely be completely untested, thus it most likely have even more bugs (in worst case it can have security bugs), thus it is better to take the simple and easy solution instead, and simply delete the IKE SA immediately. As this cannot ever happen with conforming implementations there is no need for conforming implementations to agree on what they do on this error... If this error is ever seen that means either implementation is not conforming the specification. -- kivinen@iki.fi From kivinen@iki.fi Mon Sep 7 05:58:36 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A34893A6A80 for ; Mon, 7 Sep 2009 05:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SztEG2muvexw for ; Mon, 7 Sep 2009 05:58:35 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 74E203A6A7E for ; Mon, 7 Sep 2009 05:58:35 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n87CwwtY007655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Sep 2009 15:58:58 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n87Cwwge006373; Mon, 7 Sep 2009 15:58:58 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19109.914.88005.38893@fireball.kivinen.iki.fi> Date: Mon, 7 Sep 2009 15:58:58 +0300 From: Tero Kivinen To: Keith Welter In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 10 min Cc: ipsec@ietf.org, Yoav Nir Subject: Re: [IPsec] Fw: Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 12:58:36 -0000 Keith Welter writes: > In this case, the INVALID_SYNTAX could relate to the SA, TSi or TSr > payload in the > IKE_AUTH response which would would mean that creation of the CHILD SA > failed, > not the IKE SA. I think INVALID_SYNTAX is ambiguous here without an > explicit delete > payload for either the IKE SA or the CHILD SA. For normal errors in the SA payload there is NO_PROPOSAL_CHOSEN error and for TSi and TSr there is TS_UNACCEPTABLE error. If INVALID_SYNTAX is generated from for example SA payload because the payload lengths inside the SA / Proposal / Transform payload substructure is wrong (or there is other payload type inside SA payload than what is allowed) then that again means the one end is broken and there is no point of continuing creating the IKE SA as most likely all future exchanges will fail in similar way. It is clear for me that if INVALID_SYNTAX is ever returned to IKE_AUTH exchange, that means the IKE SA was not successfully created (as we do now know whether the other end for example verified the AUTH payload). In that case when IKE SA was not created there is no IKE SA to send delete payload to. If INVALID_SYNTAX is returned after that as response to INFORMATIONAL or CREATE_CHILD exchange, then it is not clear whether other deleted the SA or not, but as I said earlier that can only happen if there is bugs in implementations, so better to cut the discussion short to limit attack options. -- kivinen@iki.fi From ynir@checkpoint.com Mon Sep 7 06:38:10 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A7393A6889 for ; Mon, 7 Sep 2009 06:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.296 X-Spam-Level: X-Spam-Status: No, score=-3.296 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1PAjgM2oYKB for ; Mon, 7 Sep 2009 06:38:09 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 1743F28C0FF for ; Mon, 7 Sep 2009 06:38:08 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n87DcY3P020048; Mon, 7 Sep 2009 16:38:35 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 7 Sep 2009 16:38:33 +0300 From: Yoav Nir To: Tero Kivinen Date: Mon, 7 Sep 2009 16:38:30 +0300 Thread-Topic: [IPsec] Issue #26: Missing treatment of error cases Thread-Index: AcovwH2f5LiomnqkQXeFbTTs84EOQg== Message-ID: <73BF7996-C4FA-4442-B49D-DDD710CACA87@checkpoint.com> References: <19109.286.34505.162897@fireball.kivinen.iki.fi> In-Reply-To: <19109.286.34505.162897@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Keith Welter Subject: Re: [IPsec] Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 13:38:10 -0000 On Sep 7, 2009, at 3:48 PM, Tero Kivinen wrote: > Keith Welter writes: >> I would not expect INVALID_SYNTAX to cause the IKE SA to be deleted >> either. > > I do consider INVALID_SYNTAX fatal error, meaning the IKE SA will be > deleted immediately after sending that response containing > INVALID_SYNTAX and if I receive INVALID_SYNTAX notification I will > immediately silently delete the IKE SA. > > INVALID_SYNTAX can only happen in if there bugs in implementations. > There is no way it could happen during normal operation, and it is > also error which does NOT go way. I.e. if other end has bug that it > sends payload whose for example payload length exceeds the packet > length, that error will not go away even if we ignore the exchange. I wish that were true, but here's what the draft says about =20 INVALID_SYNTAX INVALID_SYNTAX 7 Indicates the IKE message that was received was invalid because some type, length, or value was out of range or because the request was rejected for policy reasons. To avoid a denial of service attack using forged messages, this status may only be returned for and in an encrypted packet if the message ID and cryptographic checksum were valid. This "or because the request was rejected for policy reasons means =20 that even perfectly good implementations might get an INVALID_SYNTAX. =20 I don't know why this is so, but that's the way it is in RFC 4306 as =20 well. From kivinen@iki.fi Mon Sep 7 06:40:52 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65E8E3A67F7 for ; Mon, 7 Sep 2009 06:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZQtoq6CyTVP for ; Mon, 7 Sep 2009 06:40:51 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 7C50728C121 for ; Mon, 7 Sep 2009 06:40:50 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n87DfBRC006849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Sep 2009 16:41:11 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n87DfBCT008447; Mon, 7 Sep 2009 16:41:11 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19109.3447.759418.124836@fireball.kivinen.iki.fi> Date: Mon, 7 Sep 2009 16:41:11 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 33 min X-Total-Time: 41 min Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 13:40:52 -0000 Yoav Nir writes: > OK. Let's try this again. Is this acceptable? > > 2.21. Error Handling > > There are many kinds of errors that can occur during IKE processing. > If a request is received that is badly formatted, or unacceptable > for > reasons of policy (e.g., no matching cryptographic algorithms), the > response MUST contain a Notify payload indicating the error. If an > error occurs in the processing of a response, then the initiator > SHOULD initiate an INFORMATIONAL exchange with a Notify payload > describing the problem. I think MAY is better than SHOULD there, or even forbidding this completely. As said before I do not know any implementation which does this now, and there is also problem that there is no way to correlate the INFORMATIONAL exchange to the exchange which caused this problem. I.e. if you have window size 5, and you have 3 CREATE_CHILD_SA exchanges going, and then you get response to second of them that is invalid and you send INFORMATIONAL exchange out saying there was something wrong with the response, then there is no way for the other end to know to which of those exchanges that INFORMATIONAL related. Also I do not know any normal cases where it would be useful to send error message to the response. In some cases it may possible that initiator will process the response packet, and notice there is something wrong and do actions. One of the cases is for example when initiator asked for transport mode, but responder selected tunnel mode and initiator's policy does not allow tunnel mode. In this example the current RFC4306 text already says initiator deletes the SA. Can you give me any example when it would be possible to use this feature? Note, that this is new requirement that was not in the RFC4306. Note, that this also goes against the rule that no response never generates new requests (it is not explictly mentioned in the IKEv2, but is still there). This means that if either end has bug that cases for example the response packet of the INFORMATIONAL exchange causes other end to send error notification to the other end (using same broken INFORMATIONAL exchange) then the peers will go to INFORMATIONAL exchange loop. Because of the looping problem, and the problem there is no way to relate new INFORMATIONAL exchange request to the response which triggered it, I would actually suggest we forbid this situation and say that errors in response must be handled otherwise (most likely by deleting the IPsec SA or IKE SA or simply ignoring the error case (if it does not affect the state of the SAs)). > All errors that occur in an IKE_AUTH exchange, causing the > authentication to fail for whatever reason (invalid shared secret, > invalid ID, untrusted certificate issuer, revoked or expired > certificate, etc.) SHOULD result in an AUTHENTICATION_FAILED > notification. If the error occurred on the responder, the > notification is returned in the protected response, and should be > the > only payload in that response. When we discussed about the ticket #9 Pasi proposed a text that explains this case better, i.e. specifying that the "although the IKE_AUTH messages are encrypted and integrity protected, if the peer receiving this notification has not authenticated the other end yet, the information needs to be treated with caution." http://www.ietf.org/mail-archive/web/ipsec/current/msg04096.html This was supposed to be added to section 1.2, but it is not there. Perhaps we should add it here instead of 1.2 then (or at least add it to 1.2 if not here). > If the error occurs on the > initiator, > the notification MAY be returned in a separate INFORMATIONAL > exchange, usually with no other payloads. Here creating new INFORMATIONAL exchanges based on the errors in response may be allowed as there is no problems with correlating the message (no other exchanges is allowed before IKE_AUTH finishes), and there should not problems with loops, as the error notification was related to the IKE_AUTH not generic stuff. Also if there was problem when processing IKE_AUTH response, I would indicate that then the IKE_AUTH didn't finishs, thus we do not have IKE SA. If the problem was only in the Chid / IPsec SA part of the exchange then that can be fixed by deleting the IPsec SA. > Note, however, that > messages that contain an unsupported critical payload, or where the > whole message is malformed (rather than just bad payload contents), > MUST be rejected in their entirety, and only lead to an > UNSUPPORTED_CRITICAL_PAYLOAD or INVALID_SYNTAX Notification. The > receiver should not verify the payloads related to authentication in > this case. > > If authentication has succeeded in the IKE_AUTH exchange, the IKE SA > is established, but establishing the child SA, or requesting > configuration information may still fail. This failure does not > automatically cause the IKE SA to be deleted. Specifically, a > responder may include all the payloads associated with > authentication > (IDr, Cert and AUTH) while sending error notifications for the > piggybacked exchanges (FAILED_CP_REQUIRED, INVALID_SELECTORS, > NO_PROPOSAL_CHOSEN, etc.), and the initiator MUST NOT fail the > authentication because of this. The initiator MAY, of course, for > reasons of policy later delete such an IKE SA. > > Only authentication failures and malformed messages lead to a > deletion of the IKE SA without requiring an explicit INFORMATIONAL > exchange carrying a DELETE payload. Other error conditions require > such an exchange, if policy dictates that this is needed. > > In an IKE_SA_INIT exchange, any error notification causes the > exchange to fail, although some, like COOKIE, INVALID_KE_PAYLOAD or > INVALID_MAJOR_VERSION may lead to a subsequent successful exchange. > In an IKE_AUTH exchange, or in the INFORMATIONAL exchnage ^^^^^^ Typo. > immediately > following it, only the following notifications cause the IKE SA to > be > deleted or not created, without a DELETE payload: > o UNSUPPORTED_CRITICAL_PAYLOAD > o INVALID_SYNTAX > o AUTHENTICATION_FAILED > > Extension documents may define new error notifications with these > semantics, but MUST NOT use them unless the peer is known to > understand them. This still leaves it bit open what happens if "malformed messages" are received later for example in CREATE_CHILD_SA exchange, and responder of the exchange detects that payload is malformed and returns INVALID_SYNTAX error notification. The last part says that in IKE_AUTH it will cause sa not to be created, but it does not talk about future exchanges. On the other hand earlier it says "Only ... malformed messages lead to a deletion of the IKE SA withotu requiring an explicit INFORMATIONAL exchange carrying a DELETE payload". For me that would also indicate that if I get INVALID_SYNTAX (which is returned if you send malformed messages) then you can silently delete the IKE SA. Perhaps we should add new paragraph about that too. -- kivinen@iki.fi From ynir@checkpoint.com Mon Sep 7 06:55:27 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EEE23A687E for ; Mon, 7 Sep 2009 06:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.318 X-Spam-Level: X-Spam-Status: No, score=-3.318 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOmsr14dpIGm for ; Mon, 7 Sep 2009 06:55:26 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 96B963A67CF for ; Mon, 7 Sep 2009 06:55:25 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n87Dtp3P024565; Mon, 7 Sep 2009 16:55:52 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 7 Sep 2009 16:55:50 +0300 From: Yoav Nir To: Tero Kivinen Date: Mon, 7 Sep 2009 16:55:48 +0300 Thread-Topic: [IPsec] Issue #26: Missing treatment of error cases Thread-Index: Acovwugr7amyBwcSQR+8w6A9qVL/ww== Message-ID: <12149567-D48D-4423-9452-C646BC7AC24F@checkpoint.com> References: <19109.3447.759418.124836@fireball.kivinen.iki.fi> In-Reply-To: <19109.3447.759418.124836@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 13:55:27 -0000 On Sep 7, 2009, at 4:41 PM, Tero Kivinen wrote: > Yoav Nir writes: >> OK. Let's try this again. Is this acceptable? >> >> 2.21. Error Handling >> >> There are many kinds of errors that can occur during IKE =20 >> processing. >> If a request is received that is badly formatted, or unacceptable >> for >> reasons of policy (e.g., no matching cryptographic algorithms), =20 >> the >> response MUST contain a Notify payload indicating the error. If =20 >> an >> error occurs in the processing of a response, then the initiator >> SHOULD initiate an INFORMATIONAL exchange with a Notify payload >> describing the problem. > > I think MAY is better than SHOULD there, or even forbidding this > completely. > > As said before I do not know any implementation which does this now, > and there is also problem that there is no way to correlate the > INFORMATIONAL exchange to the exchange which caused this problem. I.e. > if you have window size 5, and you have 3 CREATE_CHILD_SA exchanges > going, and then you get response to second of them that is invalid and > you send INFORMATIONAL exchange out saying there was something wrong > with the response, then there is no way for the other end to know to > which of those exchanges that INFORMATIONAL related. > Agreed. How about SHOULD, but adding "if the error occurred in the =20 response to an IKE_AUTH exchange, and in payloads related to =20 authentication. A new exchange SHOULD NOT be triggered for reporting =20 errors in child SAs, CFG, or notifications." >> All errors that occur in an IKE_AUTH exchange, causing the >> authentication to fail for whatever reason (invalid shared secret, >> invalid ID, untrusted certificate issuer, revoked or expired >> certificate, etc.) SHOULD result in an AUTHENTICATION_FAILED >> notification. If the error occurred on the responder, the >> notification is returned in the protected response, and should be >> the >> only payload in that response. > > When we discussed about the ticket #9 Pasi proposed a text that > explains this case better, i.e. specifying that the "although the > IKE_AUTH messages are encrypted and integrity protected, if the peer > receiving this notification has not authenticated the other end yet, > the information needs to be treated with caution." > > http://www.ietf.org/mail-archive/web/ipsec/current/msg04096.html > > This was supposed to be added to section 1.2, but it is not there. > Perhaps we should add it here instead of 1.2 then (or at least add it > to 1.2 if not here). > >> If the error occurs on the >> initiator, >> the notification MAY be returned in a separate INFORMATIONAL >> exchange, usually with no other payloads. > > Here creating new INFORMATIONAL exchanges based on the errors in > response may be allowed as there is no problems with correlating the > message (no other exchanges is allowed before IKE_AUTH finishes), and > there should not problems with loops, as the error notification was > related to the IKE_AUTH not generic stuff. > > Also if there was problem when processing IKE_AUTH response, I would > indicate that then the IKE_AUTH didn't finishs, thus we do not have > IKE SA. If the problem was only in the Chid / IPsec SA part of the > exchange then that can be fixed by deleting the IPsec SA. > >> Note, however, that >> messages that contain an unsupported critical payload, or where =20 >> the >> whole message is malformed (rather than just bad payload =20 >> contents), >> MUST be rejected in their entirety, and only lead to an >> UNSUPPORTED_CRITICAL_PAYLOAD or INVALID_SYNTAX Notification. The >> receiver should not verify the payloads related to =20 >> authentication in >> this case. >> >> If authentication has succeeded in the IKE_AUTH exchange, the =20 >> IKE SA >> is established, but establishing the child SA, or requesting >> configuration information may still fail. This failure does not >> automatically cause the IKE SA to be deleted. Specifically, a >> responder may include all the payloads associated with >> authentication >> (IDr, Cert and AUTH) while sending error notifications for the >> piggybacked exchanges (FAILED_CP_REQUIRED, INVALID_SELECTORS, >> NO_PROPOSAL_CHOSEN, etc.), and the initiator MUST NOT fail the >> authentication because of this. The initiator MAY, of course, for >> reasons of policy later delete such an IKE SA. >> >> Only authentication failures and malformed messages lead to a >> deletion of the IKE SA without requiring an explicit INFORMATIONAL >> exchange carrying a DELETE payload. Other error conditions =20 >> require >> such an exchange, if policy dictates that this is needed. >> >> In an IKE_SA_INIT exchange, any error notification causes the >> exchange to fail, although some, like COOKIE, INVALID_KE_PAYLOAD =20 >> or >> INVALID_MAJOR_VERSION may lead to a subsequent successful =20 >> exchange. >> In an IKE_AUTH exchange, or in the INFORMATIONAL exchnage > ^^^^^^ > > Typo. > >> immediately >> following it, only the following notifications cause the IKE SA to >> be >> deleted or not created, without a DELETE payload: >> o UNSUPPORTED_CRITICAL_PAYLOAD >> o INVALID_SYNTAX >> o AUTHENTICATION_FAILED >> >> Extension documents may define new error notifications with these >> semantics, but MUST NOT use them unless the peer is known to >> understand them. > > This still leaves it bit open what happens if "malformed messages" are > received later for example in CREATE_CHILD_SA exchange, and responder > of the exchange detects that payload is malformed and returns > INVALID_SYNTAX error notification. The last part says that in IKE_AUTH > it will cause sa not to be created, but it does not talk about future > exchanges. On the other hand earlier it says "Only ... malformed > messages lead to a deletion of the IKE SA withotu requiring an > explicit INFORMATIONAL exchange carrying a DELETE payload". > > For me that would also indicate that if I get INVALID_SYNTAX (which is > returned if you send malformed messages) then you can silently delete > the IKE SA. > > Perhaps we should add new paragraph about that too. I think that any of these would be fatal to the particular exchange, =20 but will not cause a silent discard of the IKE SA. You might have a =20 policy that tells you to delete any IKE SA where you got or sent an =20 INVALID_SYNTAX, but because it can also be a policy matter, we =20 shouldn't really mandate it. > --=20 > kivinen@iki.fi > > Scanned by Check Point Total Security Gateway. From kivinen@iki.fi Mon Sep 7 08:56:32 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0766828C18E for ; Mon, 7 Sep 2009 08:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BgmpLdD8GRI for ; Mon, 7 Sep 2009 08:56:31 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id D1E1A28C107 for ; Mon, 7 Sep 2009 08:56:30 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n87Fup4v007912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Sep 2009 18:56:51 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n87Ful8t009219; Mon, 7 Sep 2009 18:56:47 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19109.11583.348236.158555@fireball.kivinen.iki.fi> Date: Mon, 7 Sep 2009 18:56:47 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <73BF7996-C4FA-4442-B49D-DDD710CACA87@checkpoint.com> References: <19109.286.34505.162897@fireball.kivinen.iki.fi> <73BF7996-C4FA-4442-B49D-DDD710CACA87@checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 2 min Cc: "ipsec@ietf.org" , Keith Welter Subject: Re: [IPsec] Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 15:56:32 -0000 Yoav Nir writes: > I wish that were true, but here's what the draft says about > INVALID_SYNTAX > > INVALID_SYNTAX 7 > Indicates the IKE message that was received was invalid because > some type, length, or value was out of range or because the > request was rejected for policy reasons. To avoid a denial of > service attack using forged messages, this status may only be > returned for and in an encrypted packet if the message ID and > cryptographic checksum were valid. > > This "or because the request was rejected for policy reasons means > that even perfectly good implementations might get an INVALID_SYNTAX. > I don't know why this is so, but that's the way it is in RFC 4306 as > well. I do not think it should be sent because of policy reasons, as we do have specific errors (authentication failed, no proposal chosen and ts unacceptable etc). I have not seen anybody sending this because of policy reasons, only case where I have seen this was in interops when someone send some broken packets to other end. I think we should remove the "for policy reasons" part and specify that this is only used in protocol error situations. -- kivinen@iki.fi From kivinen@iki.fi Mon Sep 7 09:17:53 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3C023A69DB for ; Mon, 7 Sep 2009 09:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bi9yFVYqsEEF for ; Mon, 7 Sep 2009 09:17:52 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id A8F903A6808 for ; Mon, 7 Sep 2009 09:17:51 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n87GDDIe009845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Sep 2009 19:13:14 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n87GDDxl010137; Mon, 7 Sep 2009 19:13:13 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19109.12569.935159.880239@fireball.kivinen.iki.fi> Date: Mon, 7 Sep 2009 19:13:13 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <12149567-D48D-4423-9452-C646BC7AC24F@checkpoint.com> References: <19109.3447.759418.124836@fireball.kivinen.iki.fi> <12149567-D48D-4423-9452-C646BC7AC24F@checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 14 min X-Total-Time: 14 min Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 16:17:53 -0000 Yoav Nir writes: > > I think MAY is better than SHOULD there, or even forbidding this > > completely. > > > > As said before I do not know any implementation which does this now, > > and there is also problem that there is no way to correlate the > > INFORMATIONAL exchange to the exchange which caused this problem. I.e. > > if you have window size 5, and you have 3 CREATE_CHILD_SA exchanges > > going, and then you get response to second of them that is invalid and > > you send INFORMATIONAL exchange out saying there was something wrong > > with the response, then there is no way for the other end to know to > > which of those exchanges that INFORMATIONAL related. > > > > Agreed. How about SHOULD, but adding "if the error occurred in the > response to an IKE_AUTH exchange, and in payloads related to > authentication. A new exchange SHOULD NOT be triggered for reporting > errors in child SAs, CFG, or notifications." If that error occurred during IKE_AUTH because of authentication failure or INVALID_SYNTAX or similar then there is no way to start new INFORMATIONAL exchange as for the initiators part the IKE SA wasn't finished, thus he DOES NOT have IKE SA to start INFORMATIONAL on. So only place where IKE_AUTH could fail so that you have IKE SA but you would want to send notification back is that there was something wrong with the configuration payload or Child SA processing. If there is something wrong with Child SA processing, then correct way is not to install the SA, and send delete for the Child SA. If there was something wrong with the configuration payload processing, then depending on the situation you might want to delete the IKE SA (if you didn't get the IP-address at all or similar) or just ignore the error. I really DO NOT like the idea of triggering new exchanges based on the failures when parsing the response. In general IKEv2 has been written so there cannot really be errors on the responder (i.e. traffic selectors are narrowed based on the initiators proposal, so responder cannot select something that is not allowed by initiator, and same is for SAs proposals etc). Can you give me example where this would be used? I.e. situation where IKE_AUTH response packet caused error which needs to be communicated to the other end and which is not related to IKE SA authentication. > I think that any of these would be fatal to the particular exchange, > but will not cause a silent discard of the IKE SA. You might have a > policy that tells you to delete any IKE SA where you got or sent an > INVALID_SYNTAX, but because it can also be a policy matter, we > shouldn't really mandate it. Our implementation will silently delete IKE SA (i.e do not send DELETE notification as if state is so messed up that you get INVALID_SYNTAX errors, then DELETE notification will mostly generate same response) when it receives INVALID_SYNTAX or after it has sent out INVALID_SYNTAX as it assumes there is something badly wrong with either implementation and there is no point of continuing at that situation. I do not have any plans of changing that, and I think other implementations do something similar (i.e if you start sending them properly encrypted and authenticated random garbage they will tear down the IKE SA). -- kivinen@iki.fi From wierbows@us.ibm.com Tue Sep 8 09:22:38 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 176BB28C1D6 for ; Tue, 8 Sep 2009 09:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.573 X-Spam-Level: X-Spam-Status: No, score=-4.573 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzqXvzit+n8G for ; Tue, 8 Sep 2009 09:22:37 -0700 (PDT) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by core3.amsl.com (Postfix) with ESMTP id E73B228C1CD for ; Tue, 8 Sep 2009 09:22:35 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e8.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n88GMTmu026858 for ; Tue, 8 Sep 2009 12:22:29 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n88GMxDF222666 for ; Tue, 8 Sep 2009 12:22:59 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n88GMwiR003133 for ; Tue, 8 Sep 2009 12:22:59 -0400 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n88GMwhU003130; Tue, 8 Sep 2009 12:22:58 -0400 In-Reply-To: <439E12F5-F278-40AB-8C47-76FC88C47EFA@checkpoint.com> References: <97EF486C-AECE-4A5F-9D15-0A3D554AD4BA@checkpoint.com> <439E12F5-F278-40AB-8C47-76FC88C47EFA@checkpoint.com> X-KeepSent: BD09FD6E:4D227A54-8525762B:00588D66; type=4; name=$KeepSent To: Yoav Nir X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: David Wierbowski Date: Tue, 8 Sep 2009 12:22:51 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 09/08/2009 12:22:58 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBFCB8DFCB0BF68f9e8a93df938690918c0ABBFCB8DFCB0BF6" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 16:22:38 -0000 --0__=0ABBFCB8DFCB0BF68f9e8a93df938690918c0ABBFCB8DFCB0BF6 Content-type: multipart/alternative; Boundary="1__=0ABBFCB8DFCB0BF68f9e8a93df938690918c0ABBFCB8DFCB0BF6" --1__=0ABBFCB8DFCB0BF68f9e8a93df938690918c0ABBFCB8DFCB0BF6 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Yoav, You are sending an informational notification, so how could you say the= SA does not exist and no delete should be sent? If an authentication error is discovered when processing the IKE_AUTH response then responder thinks an IKE SA exists and the initiator inten= ds to delete that SA. In this case it seems clean for the initiator to se= nd an INFORMATIONAL exchange containing AUTHENTICATION_FAILED and treating= the SA as being deleted. I do not see the harm in including a DELETE in th= is case and it seems to be a more appropriate action than sending the AUTHENTICATION_FAILED. I'm fine with not requiring the DELETE, but I don't think including the= DELETE is bad and should be discouraged. I think it reinforces the initiator's intentions and is unambiguous. Dave Wierbowski = From: Yoav Nir = = To: David Wierbowski/Endicott/IBM@IBMUS = = Cc: "ipsec@ietf.org" , Keith Welter/Raleigh/I= BM@IBMUS = Date: 09/04/2009 03:25 PM = = Subject: Re: [IPsec] Issue #26: Missing treatment of error cases = = Sent by: ipsec-bounces@ietf.org = = On Sep 4, 2009, at 5:53 PM, David Wierbowski wrote: >Yes, I will soften the language a bit, but I won't mention a DEL= ETE payload. If some implementations do it. >others may come to expect it. We don't want to encourage that by= suggesting that it's a good idea. Yoav, Why is it a a bad idea to include a DELETE payload in this case? Because the IKE SA was not really created, so there is no IKE SA to del= ete. It's a bad idea because it is superfluous, and we don't want to risk an= yone relying on this._______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec = --1__=0ABBFCB8DFCB0BF68f9e8a93df938690918c0ABBFCB8DFCB0BF6 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

      Yoav,

      You are sending an informational notification, so how could you say the= SA does not exist and no delete should be sent?

      If an authentication error is discovered when processing the IKE_AUTH = response then responder thinks an IKE SA exists and the initiator inten= ds to delete that SA. In this case it seems clean for the initiator to= send an INFORMATIONAL exchange containing AUTHENTICATION_FAILED and tr= eating the SA as being deleted. I do not see the harm in including a D= ELETE in this case and it seems to be a more appropriate action than se= nding the AUTHENTICATION_FAILED.

      I'm fine with not requiring the DELETE, but I don't think including the= DELETE is bad and should be discouraged. I think it reinforces the in= itiator's intentions and is unambiguous.

      Dave Wierbowski


      3D"InactiveYoav Nir ---09/04= /2009 03:25:20 PM---On Sep 4, 2009, at 5:53 PM, David Wierbowski wrote:= >Yes, I will soften the language a bit, but I wo

      =
      3D=
      From:      		= 3D""
      Yoav Nir <ynir@checkpoint.com>
      3D=
      To:
      David Wierbowski/Endicott/IBM@IBMUS
      3D=
      Cc:      		3D""
      "ipsec@ietf.org" <ipsec@ietf.org>, Kei= th Welter/Raleigh/IBM@IBMUS
      3D=
      Date:      		= 3D""
      09/04/2009 03:25 PM
      3D=
      Subject:      		3D""
      Re: [IPsec] Issue #26: Missing treatment of error case= s
      3D=
      Sent by:      		3D""
      ipsec-bounces@ietf.org





      On Sep 4, 2009, at 5:53 PM, David Wierbowski wrote:
          >Yes, I will soften the language a bit, but I w= on't mention a DELETE payload. If some implementations do it.
          >others may come to expect it. We don't want to encourage that by su= ggesting that it's a good idea.

          Yoav, Why is it a a bad idea to include a DELETE payload in this case?<= /font>

      Because the IKE SA was not really created, so there is= no IKE SA to delete. It's a bad idea because it is superfluous, and we= don't want to risk anyone relying on this._________________= ______________________________
      IPsec mailing list
      IPsec@ietf.org
      https:= //www.ietf.org/mailman/listinfo/ipsec


      = --1__=0ABBFCB8DFCB0BF68f9e8a93df938690918c0ABBFCB8DFCB0BF6-- --0__=0ABBFCB8DFCB0BF68f9e8a93df938690918c0ABBFCB8DFCB0BF6 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBFCB8DFCB0BF68f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBFCB8DFCB0BF68f9e8a93df938690918c0ABBFCB8DFCB0BF6 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <2__=0ABBFCB8DFCB0BF68f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBFCB8DFCB0BF68f9e8a93df938690918c0ABBFCB8DFCB0BF6-- From smoonen@us.ibm.com Tue Sep 8 09:47:44 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F99528C14C; Tue, 8 Sep 2009 09:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHJp2lC+kORa; Tue, 8 Sep 2009 09:47:42 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by core3.amsl.com (Postfix) with ESMTP id 9488328C174; Tue, 8 Sep 2009 09:47:42 -0700 (PDT) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e35.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n88GcV3T023115; Tue, 8 Sep 2009 10:38:31 -0600 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n88Gm1va048588; Tue, 8 Sep 2009 10:48:02 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n88Gm0RJ029476; Tue, 8 Sep 2009 10:48:01 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av05.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n88Gm05C029467; Tue, 8 Sep 2009 10:48:00 -0600 In-Reply-To: <19109.12569.935159.880239@fireball.kivinen.iki.fi> References: <19109.3447.759418.124836@fireball.kivinen.iki.fi> <12149567-D48D-4423-9452-C646BC7AC24F@checkpoint.com> <19109.12569.935159.880239@fireball.kivinen.iki.fi> To: Tero Kivinen MIME-Version: 1.0 X-KeepSent: 4B45D9E0:6326B5D9-8525762B:005B409D; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 09/08/2009 12:47:39 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 09/08/2009 12:47:39 PM, Serialize complete at 09/08/2009 12:47:39 PM, S/MIME Sign failed at 09/08/2009 12:47:39 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V851_08302009|August 30, 2009) at 09/08/2009 10:48:00, Serialize complete at 09/08/2009 10:48:00 Message-ID: Date: Tue, 8 Sep 2009 12:48:00 -0400 Content-Type: multipart/alternative; boundary="=_alternative 005C41138525762B_=" Cc: "ipsec@ietf.org WG" , ipsec-bounces@ietf.org, Yoav Nir Subject: Re: [IPsec] Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 16:47:44 -0000 This is a multipart message in MIME format. --=_alternative 005C41138525762B_= Content-Type: text/plain; charset="US-ASCII" Tero, > > Agreed. How about SHOULD, but adding "if the error occurred in the > > response to an IKE_AUTH exchange, and in payloads related to > > authentication. A new exchange SHOULD NOT be triggered for reporting > > errors in child SAs, CFG, or notifications." > > If that error occurred during IKE_AUTH because of authentication > failure or INVALID_SYNTAX or similar then there is no way to start new > INFORMATIONAL exchange as for the initiators part the IKE SA wasn't > finished, thus he DOES NOT have IKE SA to start INFORMATIONAL on. We've already bent this rule a little bit if the responder detects an authentication failure. I.e., we've documented that the responder should encrypt&MAC his N(AUTHENTICATION_FAILED) response even though from his perspective he doesn't have a valid IKE SA. It seems reasonable to do something similar in this case. I.e., if the initiator detects an authentication failure (say, the responder's certificate has expired), it is reasonable for him to 1) send a protected INFORMATIONAL request over the unauthenticated SA with the error notify, and 2) disallow any other possible activity on that invalid SA except for retransmitting the request and waiting on the response. In our own case, if this happens as initiator, we will do this, sending a protected INFORMATIONAL request containing both N(AUTHENTICATION_FAILED) and also a DELETE for the IKE SA. In my view the DELETE is actually the more crucial payload here, and the Notify payload is primarily a courtesy to hint to the responder why the delete is being sent (since there is really no way to assert that a Notify in an INFORMATIONAL request relates to some other particular exchange). Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Tero Kivinen To: Yoav Nir Cc: "ipsec@ietf.org WG" Date: 09/07/2009 12:18 PM Subject: Re: [IPsec] Issue #26: Missing treatment of error cases Yoav Nir writes: > > I think MAY is better than SHOULD there, or even forbidding this > > completely. > > > > As said before I do not know any implementation which does this now, > > and there is also problem that there is no way to correlate the > > INFORMATIONAL exchange to the exchange which caused this problem. I.e. > > if you have window size 5, and you have 3 CREATE_CHILD_SA exchanges > > going, and then you get response to second of them that is invalid and > > you send INFORMATIONAL exchange out saying there was something wrong > > with the response, then there is no way for the other end to know to > > which of those exchanges that INFORMATIONAL related. > > > > Agreed. How about SHOULD, but adding "if the error occurred in the > response to an IKE_AUTH exchange, and in payloads related to > authentication. A new exchange SHOULD NOT be triggered for reporting > errors in child SAs, CFG, or notifications." If that error occurred during IKE_AUTH because of authentication failure or INVALID_SYNTAX or similar then there is no way to start new INFORMATIONAL exchange as for the initiators part the IKE SA wasn't finished, thus he DOES NOT have IKE SA to start INFORMATIONAL on. So only place where IKE_AUTH could fail so that you have IKE SA but you would want to send notification back is that there was something wrong with the configuration payload or Child SA processing. If there is something wrong with Child SA processing, then correct way is not to install the SA, and send delete for the Child SA. If there was something wrong with the configuration payload processing, then depending on the situation you might want to delete the IKE SA (if you didn't get the IP-address at all or similar) or just ignore the error. I really DO NOT like the idea of triggering new exchanges based on the failures when parsing the response. In general IKEv2 has been written so there cannot really be errors on the responder (i.e. traffic selectors are narrowed based on the initiators proposal, so responder cannot select something that is not allowed by initiator, and same is for SAs proposals etc). Can you give me example where this would be used? I.e. situation where IKE_AUTH response packet caused error which needs to be communicated to the other end and which is not related to IKE SA authentication. > I think that any of these would be fatal to the particular exchange, > but will not cause a silent discard of the IKE SA. You might have a > policy that tells you to delete any IKE SA where you got or sent an > INVALID_SYNTAX, but because it can also be a policy matter, we > shouldn't really mandate it. Our implementation will silently delete IKE SA (i.e do not send DELETE notification as if state is so messed up that you get INVALID_SYNTAX errors, then DELETE notification will mostly generate same response) when it receives INVALID_SYNTAX or after it has sent out INVALID_SYNTAX as it assumes there is something badly wrong with either implementation and there is no point of continuing at that situation. I do not have any plans of changing that, and I think other implementations do something similar (i.e if you start sending them properly encrypted and authenticated random garbage they will tear down the IKE SA). -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 005C41138525762B_= Content-Type: text/html; charset="US-ASCII"
      Tero,

      > > Agreed. How about SHOULD, but adding "if the error occurred in the  
      > > response to an IKE_AUTH exchange, and in payloads related to  
      > > authentication. A new exchange SHOULD NOT be triggered for reporting  
      > > errors in child SAs, CFG, or notifications."
      >
      > If that error occurred during IKE_AUTH because of authentication
      > failure or INVALID_SYNTAX or similar then there is no way to start new
      > INFORMATIONAL exchange as for the initiators part the IKE SA wasn't
      > finished, thus he DOES NOT have IKE SA to start INFORMATIONAL on.

      We've already bent this rule a little bit if the responder detects an authentication failure.  I.e., we've documented that the responder should encrypt&MAC his N(AUTHENTICATION_FAILED) response even though from his perspective he doesn't have a valid IKE SA.

      It seems reasonable to do something similar in this case.  I.e., if the initiator detects an authentication failure (say, the responder's certificate has expired), it is reasonable for him to 1) send a protected INFORMATIONAL request over the unauthenticated SA with the error notify, and 2) disallow any other possible activity on that invalid SA except for retransmitting the request and waiting on the response.

      In our own case, if this happens as initiator, we will do this, sending a protected INFORMATIONAL request containing both N(AUTHENTICATION_FAILED) and also a DELETE for the IKE SA.  In my view the DELETE is actually the more crucial payload here, and the Notify payload is primarily a courtesy to hint to the responder why the delete is being sent (since there is really no way to assert that a Notify in an INFORMATIONAL request relates to some other particular exchange).


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


      From: Tero Kivinen <kivinen@iki.fi>
      To: Yoav Nir <ynir@checkpoint.com>
      Cc: "ipsec@ietf.org WG" <ipsec@ietf.org>
      Date: 09/07/2009 12:18 PM
      Subject: Re: [IPsec] Issue #26: Missing treatment of error cases




      Yoav Nir writes:
      > > I think MAY is better than SHOULD there, or even forbidding this
      > > completely.
      > >
      > > As said before I do not know any implementation which does this now,
      > > and there is also problem that there is no way to correlate the
      > > INFORMATIONAL exchange to the exchange which caused this problem. I.e.
      > > if you have window size 5, and you have 3 CREATE_CHILD_SA exchanges
      > > going, and then you get response to second of them that is invalid and
      > > you send INFORMATIONAL exchange out saying there was something wrong
      > > with the response, then there is no way for the other end to know to
      > > which of those exchanges that INFORMATIONAL related.
      > >
      >
      > Agreed. How about SHOULD, but adding "if the error occurred in the  
      > response to an IKE_AUTH exchange, and in payloads related to  
      > authentication. A new exchange SHOULD NOT be triggered for reporting  
      > errors in child SAs, CFG, or notifications."

      If that error occurred during IKE_AUTH because of authentication
      failure or INVALID_SYNTAX or similar then there is no way to start new
      INFORMATIONAL exchange as for the initiators part the IKE SA wasn't
      finished, thus he DOES NOT have IKE SA to start INFORMATIONAL on.

      So only place where IKE_AUTH could fail so that you have IKE SA but
      you would want to send notification back is that there was something
      wrong with the configuration payload or Child SA processing. If there
      is something wrong with Child SA processing, then correct way is not
      to install the SA, and send delete for the Child SA. If there was
      something wrong with the configuration payload processing, then
      depending on the situation you might want to delete the IKE SA (if you
      didn't get the IP-address at all or similar) or just ignore the error.

      I really DO NOT like the idea of triggering new exchanges based on the
      failures when parsing the response. In general IKEv2 has been written
      so there cannot really be errors on the responder (i.e. traffic
      selectors are narrowed based on the initiators proposal, so responder
      cannot select something that is not allowed by initiator, and same is
      for SAs proposals etc).

      Can you give me example where this would be used? I.e. situation where
      IKE_AUTH response packet caused error which needs to be communicated
      to the other end and which is not related to IKE SA authentication.

      > I think that any of these would be fatal to the particular exchange,  
      > but will not cause a silent discard of the IKE SA.  You might have a  
      > policy that tells you to delete any IKE SA where you got or sent an  
      > INVALID_SYNTAX, but because it can also be a policy matter, we  
      > shouldn't really mandate it.

      Our implementation will silently delete IKE SA (i.e do not send DELETE
      notification as if state is so messed up that you get INVALID_SYNTAX
      errors, then DELETE notification will mostly generate same response)
      when it receives INVALID_SYNTAX or after it has sent out
      INVALID_SYNTAX as it assumes there is something badly wrong with
      either implementation and there is no point of continuing at that
      situation. I do not have any plans of changing that, and I think other
      implementations do something similar (i.e if you start sending them
      properly encrypted and authenticated random garbage they will tear
      down the IKE SA).  
      --
      kivinen@iki.fi
      _______________________________________________
      IPsec mailing list
      IPsec@ietf.org
      https://www.ietf.org/mailman/listinfo/ipsec

      --=_alternative 005C41138525762B_=-- From kivinen@iki.fi Tue Sep 8 13:26:05 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0D4E28C1A3 for ; Tue, 8 Sep 2009 13:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHeygbiBxGe2 for ; Tue, 8 Sep 2009 13:26:05 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 8D0B23A687F for ; Tue, 8 Sep 2009 13:26:04 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n88KQRVA019144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Sep 2009 23:26:27 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n88KQQLM014759; Tue, 8 Sep 2009 23:26:26 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19110.48626.213823.680497@fireball.kivinen.iki.fi> Date: Tue, 8 Sep 2009 23:26:26 +0300 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: <19109.3447.759418.124836@fireball.kivinen.iki.fi> <12149567-D48D-4423-9452-C646BC7AC24F@checkpoint.com> <19109.12569.935159.880239@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 18 min X-Total-Time: 41 min Cc: "ipsec@ietf.org WG" , Yoav Nir Subject: Re: [IPsec] Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 20:26:06 -0000 Scott C Moonen writes: > Tero, > > > > Agreed. How about SHOULD, but adding "if the error occurred in the > > > response to an IKE_AUTH exchange, and in payloads related to > > > authentication. A new exchange SHOULD NOT be triggered for reporting > > > errors in child SAs, CFG, or notifications." > > > > If that error occurred during IKE_AUTH because of authentication > > failure or INVALID_SYNTAX or similar then there is no way to start new > > INFORMATIONAL exchange as for the initiators part the IKE SA wasn't > > finished, thus he DOES NOT have IKE SA to start INFORMATIONAL on. > > We've already bent this rule a little bit if the responder detects an > authentication failure. I.e., we've documented that the responder should > encrypt&MAC his N(AUTHENTICATION_FAILED) response even though from his > perspective he doesn't have a valid IKE SA. True, but that does not mean the IKE SA is valid, it just means they do have shared unauthenticated keys for encryption and MAC. I.e that encrypt & MAC proves that the reply comes back from the same server who did Diffie-Hellman, but it does not mean it came back from the correct intended responder. The reply could be generated also by man in the middle. > It seems reasonable to do something similar in this case. I.e., if the > initiator detects an authentication failure (say, the responder's > certificate has expired), it is reasonable for him to 1) send a protected > INFORMATIONAL request over the unauthenticated SA with the error notify, > and 2) disallow any other possible activity on that invalid SA except for > retransmitting the request and waiting on the response. That adds quite of lot of special code (i.e you need to make sure that IKE SA is not used for anything else while you are waiting for reply), and does not really help that much. This will cause server to clean up the IKE SA faster than it normally would, but as client initiated this there is most likely no data coming from the server to client anyways thus no traffic is really lost. The client will still fail the IKE SA and as client was the one who initiated it, it will most likely try again and the user noticing things does not work tries to fix things. This kind of authentication failures usually do not go away without user intervention anyways. >From the responders point of view the IKE SA is there, so he does not care which way the initiator does, so this is not something that needs to be defined at all (i.e. there is no need to define whether it is allowed, recommended or forbidden). Whether implementation does this can be completely left to as local matter. > In our own case, if this happens as initiator, we will do this, sending a > protected INFORMATIONAL request containing both N(AUTHENTICATION_FAILED) > and also a DELETE for the IKE SA. In my view the DELETE is actually the > more crucial payload here, and the Notify payload is primarily a courtesy > to hint to the responder why the delete is being sent (since there is > really no way to assert that a Notify in an INFORMATIONAL request relates > to some other particular exchange). You are free to do that. It will gain you so that server will delete the IKE SA bit earlier than it would otherwise (i.e. otherwise it would need to wait for the DPD to kick in (which would most likely happen quite soon, as there is completely idle IKE and IPsec SA there) and that would then delete the IKE SA). For the original users point of view (i.e. the initiator / client) this does not matter, as he still cannot get connection... I myself as implementor writing code do not want to add such code to our product as it is just adding code that is very seldomly run and even less seldomly tested, and which can contain security bugs, thus the product is safer and better without such code. But this is just my own opinion, and other implementors might have different opinions, and I am ok with text which says you MAY do it. I would object against SHOULD, and object very strongly against MUST. -- kivinen@iki.fi From kivinen@iki.fi Tue Sep 8 13:30:19 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E528528C333 for ; Tue, 8 Sep 2009 13:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAmLorKF0pW4 for ; Tue, 8 Sep 2009 13:30:19 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id AE1CA28C334 for ; Tue, 8 Sep 2009 13:30:18 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n88KUklE019246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Sep 2009 23:30:46 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n88KUkqn019104; Tue, 8 Sep 2009 23:30:46 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19110.48886.596603.380247@fireball.kivinen.iki.fi> Date: Tue, 8 Sep 2009 23:30:46 +0300 From: Tero Kivinen To: David Wierbowski In-Reply-To: References: <97EF486C-AECE-4A5F-9D15-0A3D554AD4BA@checkpoint.com> <439E12F5-F278-40AB-8C47-76FC88C47EFA@checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 3 min Cc: "ipsec@ietf.org" , Yoav Nir Subject: Re: [IPsec] Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 20:30:20 -0000 David Wierbowski writes: > You are sending an informational notification, so how could you say the SA > does not exist and no delete should be sent? The IKE SA is NOT up and valid in the initiator. It is halfway up as the other end has not been authenticated, and that IKE SA cannot be used in general. > If an authentication error is discovered when processing the IKE_AUTH > response then responder thinks an IKE SA exists and the initiator intends > to delete that SA. In this case it seems clean for the initiator to send > an INFORMATIONAL exchange containing AUTHENTICATION_FAILED and treating the > SA as being deleted. I do not see the harm in including a DELETE in this > case and it seems to be a more appropriate action than sending the > AUTHENTICATION_FAILED. > > I'm fine with not requiring the DELETE, but I don't think including the > DELETE is bad and should be discouraged. I think it reinforces the > initiator's intentions and is unambiguous. If you use that kind of halfway up IKE SA for sending INFORMATIONAL message to other end (who thinks the IKE SA is up and valid), then I agree that sending both N(AUTHENTICATION_FAILED) and DELETE would be the correct way to do it. DELETE only would also be ok. Sending only N(AUTHENTICATION_FAILED) would be bit ambiquous, and I would not recommend that, but as initiator still do not have IKE SA up but has only halfway up SA, for initiator it does not matter what other end does for the INFORMATIONAL exchange anyways... -- kivinen@iki.fi From welterk@us.ibm.com Tue Sep 8 20:00:06 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5F7528C1C5 for ; Tue, 8 Sep 2009 20:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkvXxofikHvW for ; Tue, 8 Sep 2009 20:00:05 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by core3.amsl.com (Postfix) with ESMTP id 079293A684C for ; Tue, 8 Sep 2009 20:00:04 -0700 (PDT) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e31.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n892sb5K022938 for ; Tue, 8 Sep 2009 20:54:37 -0600 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8930UX7187202 for ; Tue, 8 Sep 2009 21:00:30 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n8930TNB013471 for ; Tue, 8 Sep 2009 21:00:29 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av05.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n8930TXp013468 for ; Tue, 8 Sep 2009 21:00:29 -0600 In-Reply-To: References: To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: 974A235C:C043A23F-8825762B:00826C1A; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Keith Welter X-MIMETrack: S/MIME Sign by Notes Client on Keith Welter/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 09/08/2009 08:00:24 PM, Serialize by Notes Client on Keith Welter/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 09/08/2009 08:00:25 PM, Serialize complete at 09/08/2009 08:00:25 PM, S/MIME Sign failed at 09/08/2009 08:00:25 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V851_08302009|August 30, 2009) at 09/08/2009 21:00:29, Serialize complete at 09/08/2009 21:00:29 Message-ID: Date: Tue, 8 Sep 2009 20:00:29 -0700 Content-Type: multipart/alternative; boundary="=_alternative 0010847E8825762C_=" Subject: Re: [IPsec] IPsec Digest, Vol 65, Issue 14 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 03:00:06 -0000 This is a multipart message in MIME format. --=_alternative 0010847E8825762C_= Content-Type: text/plain; charset="US-ASCII" > Message: 2 > Date: Sun, 6 Sep 2009 10:15:17 +0300 > From: Yoav Nir > Subject: Re: [IPsec] Issue #26: Missing treatment of error cases > To: "ipsec@ietf.org WG" , Tero Kivinen > > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > OK. Let's try this again. Is this acceptable? > > 2.21. Error Handling > > There are many kinds of errors that can occur during IKE processing. > If a request is received that is badly formatted, or unacceptable > for > reasons of policy (e.g., no matching cryptographic algorithms), the > response MUST contain a Notify payload indicating the error. If an > error occurs in the processing of a response, then the initiator > SHOULD initiate an INFORMATIONAL exchange with a Notify payload > describing the problem. If an error occurs outside the context of > an > IKE request (e.g., the node is getting ESP messages on a nonexistent > SPI), the node SHOULD initiate an INFORMATIONAL exchange with a > Notify payload describing the problem. > > Errors that occur before a cryptographically protected IKE SA is > established must be handled very carefully. There is a trade-off > between wanting to be helpful in diagnosing a problem and responding > to it and wanting to avoid being a dupe in a denial of service > attack > based on forged messages. > > If a node receives a message on UDP port 500 or 4500 outside the > context of an IKE SA known to it (and not a request to start one), > it > may be the result of a recent crash of the node. If the message is > marked as a response, the node MAY audit the suspicious event but > MUST NOT respond. If the message is marked as a request, the node > MAY audit the suspicious event and MAY send a response. If a > response is sent, the response MUST be sent to the IP address and > port from whence it came with the same IKE SPIs and the Message ID > copied. The response MUST NOT be cryptographically protected and > MUST contain a Notify payload indicating INVALID_IKE_SPI. The > INVALID_IKE_SPI notification indicates an IKE message was received > with an unrecognized destination SPI; this usually indicates that > the > recipient has rebooted and forgotten the existence of an IKE SA. > > A node receiving such an unprotected Notify payload MUST NOT respond > and MUST NOT change the state of any existing SAs. The message > might > be a forgery or might be a response, the genuine correspondent was > tricked into sending. A node should treat such a message (and > also a > network message like ICMP destination unreachable) as a hint that > there might be problems with SAs to that IP address and should > initiate a liveness check for any such IKE SA. An implementation > SHOULD limit the frequency of such tests to avoid being tricked into > participating in a denial of service attack. > > A node receiving a suspicious message from an IP address (and port, > if NAT traversal is used) with which it has an IKE SA SHOULD send an > IKE Notify payload in an IKE INFORMATIONAL exchange over that SA. > The recipient MUST NOT change the state of any SAs as a result, but > may wish to audit the event to aid in diagnosing malfunctions. A > node MUST limit the rate at which it will send messages in response > to unprotected messages. > > All errors that occur in an IKE_AUTH exchange, causing the > authentication to fail for whatever reason (invalid shared secret, > invalid ID, untrusted certificate issuer, revoked or expired > certificate, etc.) SHOULD result in an AUTHENTICATION_FAILED > notification. If the error occurred on the responder, the > notification is returned in the protected response, and should be > the > only payload in that response. If the error occurs on the > initiator, > the notification MAY be returned in a separate INFORMATIONAL > exchange, usually with no other payloads. I appreciate the softer wording here. However, I find the wording "usually with no other payloads" unduly mysterious. If the concern is that mentioning the DELETE payload may cause implementors to rely on the DELETE payload in this case then words could be added to alleviate that concern. For example, the words... "usually with no other payloads." ...could be replaced with: "with no other payloads except an optional DELETE payload. As stated, the DELETE payload is optional in this case and should not be relied upon to cause deletion of the IKE SA." > Note, however, that > messages that contain an unsupported critical payload, or where the > whole message is malformed (rather than just bad payload contents), > MUST be rejected in their entirety, and only lead to an > UNSUPPORTED_CRITICAL_PAYLOAD or INVALID_SYNTAX Notification. The > receiver should not verify the payloads related to authentication in > this case. > > If authentication has succeeded in the IKE_AUTH exchange, the IKE SA > is established, but establishing the child SA, or requesting > configuration information may still fail. This failure does not > automatically cause the IKE SA to be deleted. Specifically, a > responder may include all the payloads associated with > authentication > (IDr, Cert and AUTH) while sending error notifications for the > piggybacked exchanges (FAILED_CP_REQUIRED, INVALID_SELECTORS, > NO_PROPOSAL_CHOSEN, etc.), and the initiator MUST NOT fail the > authentication because of this. The initiator MAY, of course, for > reasons of policy later delete such an IKE SA. > > Only authentication failures and malformed messages lead to a > deletion of the IKE SA without requiring an explicit INFORMATIONAL > exchange carrying a DELETE payload. Other error conditions require > such an exchange, if policy dictates that this is needed. > > In an IKE_SA_INIT exchange, any error notification causes the > exchange to fail, although some, like COOKIE, INVALID_KE_PAYLOAD or > INVALID_MAJOR_VERSION may lead to a subsequent successful exchange. > In an IKE_AUTH exchange, or in the INFORMATIONAL exchnage > immediately > following it, only the following notifications cause the IKE SA to > be > deleted or not created, without a DELETE payload: > o UNSUPPORTED_CRITICAL_PAYLOAD > o INVALID_SYNTAX > o AUTHENTICATION_FAILED I find the clause, "or in the INFORMATIONAL exchnage immediately following it" to be troublesome. I presume that this text is talking only about the INFORMATIONAL exchange immediately following the IKE_AUTH exchange, if any, started by the original initiator (i.e. an INFORMATIONAL exchange with message ID of 2) but that is not explicitly stated here and may be worth clarifying. I think that having to interpret the notify type differently depending on the INFORMATIONAL message ID is inelegant but given that the silent delete described here may be a common practice it seems that documenting it is goodness. I think that the description of the handling of the notify types here begs the question of how they should be handled in exchanges other than the initial exchanges or the INFORMATIONAL exchange with message ID 2. > > Extension documents may define new error notifications with these > semantics, but MUST NOT use them unless the peer is known to > understand them. Keith Welter IBM z/OS Communications Server Developer 1-415-545-2694 (T/L: 473-2694) --=_alternative 0010847E8825762C_= Content-Type: text/html; charset="US-ASCII"
      > Message: 2
      > Date: Sun, 6 Sep 2009 10:15:17 +0300
      > From: Yoav Nir <ynir@checkpoint.com>
      > Subject: Re: [IPsec] Issue #26: Missing treatment of error cases
      > To: "ipsec@ietf.org WG" <ipsec@ietf.org>, Tero Kivinen
      >    <kivinen@iki.fi>
      > Message-ID: <E71A2F1D-63AD-4890-9B74-32D2CB5EB33F@checkpoint.com>
      > Content-Type: text/plain; charset="us-ascii"
      >
      > OK. Let's try this again. Is this acceptable?
      >
      > 2.21.  Error Handling
      >
      >     There are many kinds of errors that can occur during IKE processing.
      >     If a request is received that is badly formatted, or unacceptable  
      > for
      >     reasons of policy (e.g., no matching cryptographic algorithms), the
      >     response MUST contain a Notify payload indicating the error.  If an
      >     error occurs in the processing of a response, then the initiator
      >     SHOULD initiate an INFORMATIONAL exchange with a Notify payload
      >     describing the problem.  If an error occurs outside the context of  
      > an
      >     IKE request (e.g., the node is getting ESP messages on a nonexistent
      >     SPI), the node SHOULD initiate an INFORMATIONAL exchange with a
      >     Notify payload describing the problem.
      >
      >     Errors that occur before a cryptographically protected IKE SA is
      >     established must be handled very carefully.  There is a trade-off
      >     between wanting to be helpful in diagnosing a problem and responding
      >     to it and wanting to avoid being a dupe in a denial of service  
      > attack
      >     based on forged messages.
      >
      >     If a node receives a message on UDP port 500 or 4500 outside the
      >     context of an IKE SA known to it (and not a request to start one),  
      > it
      >     may be the result of a recent crash of the node.  If the message is
      >     marked as a response, the node MAY audit the suspicious event but
      >     MUST NOT respond.  If the message is marked as a request, the node
      >     MAY audit the suspicious event and MAY send a response.  If a
      >     response is sent, the response MUST be sent to the IP address and
      >     port from whence it came with the same IKE SPIs and the Message ID
      >     copied.  The response MUST NOT be cryptographically protected and
      >     MUST contain a Notify payload indicating INVALID_IKE_SPI.  The
      >     INVALID_IKE_SPI notification indicates an IKE message was received
      >     with an unrecognized destination SPI; this usually indicates that  
      > the
      >     recipient has rebooted and forgotten the existence of an IKE SA.
      >
      >     A node receiving such an unprotected Notify payload MUST NOT respond
      >     and MUST NOT change the state of any existing SAs.  The message  
      > might
      >     be a forgery or might be a response, the genuine correspondent was
      >     tricked into sending.  A node should treat such a message (and  
      > also a
      >     network message like ICMP destination unreachable) as a hint that
      >     there might be problems with SAs to that IP address and should
      >     initiate a liveness check for any such IKE SA.  An implementation
      >     SHOULD limit the frequency of such tests to avoid being tricked into
      >     participating in a denial of service attack.
      >
      >     A node receiving a suspicious message from an IP address (and port,
      >     if NAT traversal is used) with which it has an IKE SA SHOULD send an
      >     IKE Notify payload in an IKE INFORMATIONAL exchange over that SA.
      >     The recipient MUST NOT change the state of any SAs as a result, but
      >     may wish to audit the event to aid in diagnosing malfunctions.  A
      >     node MUST limit the rate at which it will send messages in response
      >     to unprotected messages.
      >
      >     All errors that occur in an IKE_AUTH exchange, causing the
      >     authentication to fail for whatever reason (invalid shared secret,
      >     invalid ID, untrusted certificate issuer, revoked or expired
      >     certificate, etc.)  SHOULD result in an AUTHENTICATION_FAILED
      >     notification.  If the error occurred on the responder, the
      >     notification is returned in the protected response, and should be  
      > the
      >     only payload in that response.  If the error occurs on the  
      > initiator,
      >     the notification MAY be returned in a separate INFORMATIONAL
      >     exchange, usually with no other payloads.  
      I appreciate the softer wording here.  However, I find the
      wording "usually with no other payloads" unduly mysterious.  
      If the concern is that mentioning the DELETE payload may
      cause implementors to rely on the DELETE payload in this
      case then words could be added to alleviate that concern.  

      For example, the words...
      "usually with no other payloads."

      ...could be replaced with:
      "with no other payloads except an optional DELETE payload.
      As stated, the DELETE payload is optional in this case
      and should not be relied upon to cause deletion of the IKE SA."

      >     Note, however, that
      >     messages that contain an unsupported critical payload, or where the
      >     whole message is malformed (rather than just bad payload contents),
      >     MUST be rejected in their entirety, and only lead to an
      >     UNSUPPORTED_CRITICAL_PAYLOAD or INVALID_SYNTAX Notification.  The
      >     receiver should not verify the payloads related to authentication in
      >     this case.
      >
      >     If authentication has succeeded in the IKE_AUTH exchange, the IKE SA
      >     is established, but establishing the child SA, or requesting
      >     configuration information may still fail.  This failure does not
      >     automatically cause the IKE SA to be deleted.  Specifically, a
      >     responder may include all the payloads associated with  
      > authentication
      >     (IDr, Cert and AUTH) while sending error notifications for the
      >     piggybacked exchanges (FAILED_CP_REQUIRED, INVALID_SELECTORS,
      >     NO_PROPOSAL_CHOSEN, etc.), and the initiator MUST NOT fail the
      >     authentication because of this.  The initiator MAY, of course, for
      >     reasons of policy later delete such an IKE SA.
      >
      >     Only authentication failures and malformed messages lead to a
      >     deletion of the IKE SA without requiring an explicit INFORMATIONAL
      >     exchange carrying a DELETE payload.  Other error conditions require
      >     such an exchange, if policy dictates that this is needed.
      >
      >     In an IKE_SA_INIT exchange, any error notification causes the
      >     exchange to fail, although some, like COOKIE, INVALID_KE_PAYLOAD or
      >     INVALID_MAJOR_VERSION may lead to a subsequent successful exchange.
      >     In an IKE_AUTH exchange, or in the INFORMATIONAL exchnage  
      > immediately
      >     following it, only the following notifications cause the IKE SA to  
      > be
      >     deleted or not created, without a DELETE payload:
      >     o  UNSUPPORTED_CRITICAL_PAYLOAD
      >     o  INVALID_SYNTAX
      >     o  AUTHENTICATION_FAILED
      I find the clause, "or in the INFORMATIONAL exchnage immediately following it"
      to be troublesome.  I presume that this text is talking only about the INFORMATIONAL
      exchange immediately following the IKE_AUTH exchange, if any, started by the original
      initiator (i.e. an INFORMATIONAL exchange with message ID of 2) but that is not
      explicitly stated here and may be worth clarifying.  I think that having to interpret
      the notify type differently depending on the INFORMATIONAL message ID is inelegant but
      given that the silent delete described here may be a common practice it seems that
      documenting it is goodness.  I think that the description of the handling of the notify
      types here begs the question of how they should be handled in exchanges other than the
      initial exchanges or the INFORMATIONAL exchange with message ID 2.

      >
      >     Extension documents may define new error notifications with these
      >     semantics, but MUST NOT use them unless the peer is known to
      >     understand them.

      Keith Welter
      IBM z/OS Communications Server Developer
      1-415-545-2694 (T/L: 473-2694)
       --=_alternative 0010847E8825762C_=-- From mwong@huawei.com Fri Sep 11 08:45:05 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82E0428C195 for ; Fri, 11 Sep 2009 08:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKUdj0tNI+-t for ; Fri, 11 Sep 2009 08:45:04 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 1575328C186 for ; Fri, 11 Sep 2009 08:45:04 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPT001BWD3XPL@usaga02-in.huawei.com> for ipsec@ietf.org; Fri, 11 Sep 2009 08:45:33 -0700 (PDT) Received: from W73811 ([10.193.125.82]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KPT0084SD3S3C@usaga02-in.huawei.com> for ipsec@ietf.org; Fri, 11 Sep 2009 08:45:32 -0700 (PDT) Date: Fri, 11 Sep 2009 11:46:51 -0400 From: Marcus Wong In-reply-to: <002601ca1fb8$6ba9bcd0$800c6f0a@china.huawei.com> To: ipsec@ietf.org Message-id: <99E2C4D8C30749A9A7B2A31CC2F434F9@china.huawei.com> Organization: Huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcofsAYR4y8WM88yQZqijcr+2Cpv4gABc5oABM/88wA= References: <002601ca1fb8$6ba9bcd0$800c6f0a@china.huawei.com> Subject: [IPsec] draft-wong-ipsecme-ikev2-integrity-data-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mwong@huawei.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 15:45:05 -0000 Hi Everyone, I'm new to the working group. I've uploaded a draft on the use of notify payload for integrity data exchanges in IKEv2 for your comments and review. All comments are highly appreciated. Thanks everyone. A new version of I-D, draft-wong-ipsecme-ikev2-integrity-data-00.txt has been successfuly submitted by Marcus Wong and posted to the IETF repository. Filename: draft-wong-ipsecme-ikev2-integrity-data Revision: 00 Title: Integrity Data Exchanges in IKEv2 Creation_date: 2009-09-11 WG ID: Independent Submission Number_of_pages: 9 Abstract: IKEv2 supports mutual authentication of the peers but does not support platform integrity validation of the peers nor does it support the exchange of data related to the platform integrity validation. This extension allows platform integrity validation data to be exchanged from one peer (initiator) to another (respondent), allowing the other peer to either use the data for statistical analysis, pass it along to a validation entity for validation or pass it along to a Fraud Information Gathering System for fraud detection or analysis. A URL for this Internet-Draft is: http://www.ietf.org/id/draft-wong-ipsecme-ikev2-integrity-data-00.txt Regards, Marcus Wong Huawei Technologies Co.,Ltd. 400 Somerset Corp Blvd., Suite 602 Bridgewater, NJ 08812 (908)541-3505 From wwwrun@core3.amsl.com Fri Sep 11 10:38:20 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 6BDDD28C1FC; Fri, 11 Sep 2009 10:38:19 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090911173820.6BDDD28C1FC@core3.amsl.com> Date: Fri, 11 Sep 2009 10:38:20 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] Last Call: draft-ietf-ipsecme-ikev2-ipv6-config (IPv6 Configuration in IKEv2) to Experimental RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 17:38:20 -0000 The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'IPv6 Configuration in IKEv2 ' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-09-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-ipv6-config-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18004&rfc_flag=0 From kent@bbn.com Fri Sep 11 12:22:21 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9173C3A6AF3 for ; Fri, 11 Sep 2009 12:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nqw-hHoP4+o for ; Fri, 11 Sep 2009 12:22:20 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id C5F9F3A6AB4 for ; Fri, 11 Sep 2009 12:22:20 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.59.1.235]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1MmAlp-00028c-Da; Fri, 11 Sep 2009 14:22:53 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <99E2C4D8C30749A9A7B2A31CC2F434F9@china.huawei.com> References: <002601ca1fb8$6ba9bcd0$800c6f0a@china.huawei.com> <99E2C4D8C30749A9A7B2A31CC2F434F9@china.huawei.com> Date: Fri, 11 Sep 2009 15:22:49 -0400 To: mwong@huawei.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-wong-ipsecme-ikev2-integrity-data-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 19:22:21 -0000 At 11:46 AM -0400 9/11/09, Marcus Wong wrote: >Hi Everyone, > >I'm new to the working group. I've uploaded a draft on the use of notify >payload for integrity data exchanges in IKEv2 for your comments and review. >All comments are highly appreciated. Thanks everyone. > > >A new version of I-D, draft-wong-ipsecme-ikev2-integrity-data-00.txt has >been successfuly submitted by Marcus Wong and posted to the IETF repository. > >Filename: draft-wong-ipsecme-ikev2-integrity-data >Revision: 00 >Title: Integrity Data Exchanges in IKEv2 >Creation_date: 2009-09-11 >WG ID: Independent Submission >Number_of_pages: 9 > >Abstract: >IKEv2 supports mutual authentication of the peers but does not support >platform integrity validation of the peers nor does it support the exchange >of data related to the platform integrity validation. This extension allows >platform integrity validation data to be exchanged from one peer (initiator) >to another (respondent), allowing the other peer to either use the data for >statistical analysis, pass it along to a validation entity for validation or >pass it along to a Fraud Information Gathering System for fraud detection or >analysis. > I have mot read you I-D, but this sounds like a NEA issue being pushed into an IPsec protocol. Am I wrong? Steve From mwong@huawei.com Fri Sep 11 13:04:21 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F1893A68A7 for ; Fri, 11 Sep 2009 13:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-gKDtsm-dhD for ; Fri, 11 Sep 2009 13:04:17 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 47BB33A6864 for ; Fri, 11 Sep 2009 13:04:17 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPT00JUMP46FC@usaga02-in.huawei.com> for ipsec@ietf.org; Fri, 11 Sep 2009 13:04:54 -0700 (PDT) Received: from W73811 ([10.193.125.82]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KPT0065XP411H@usaga02-in.huawei.com> for ipsec@ietf.org; Fri, 11 Sep 2009 13:04:53 -0700 (PDT) Date: Fri, 11 Sep 2009 16:06:24 -0400 From: Marcus Wong In-reply-to: To: ipsec@ietf.org Message-id: <92E104320BB54EC5B8D3804FA61C8390@china.huawei.com> Organization: Huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcozGGdfGNGB25/USvORetarE8BO9AAAkAaA References: <002601ca1fb8$6ba9bcd0$800c6f0a@china.huawei.com> <99E2C4D8C30749A9A7B2A31CC2F434F9@china.huawei.com> Subject: Re: [IPsec] draft-wong-ipsecme-ikev2-integrity-data-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mwong@huawei.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 20:04:21 -0000 Steve, you are mostly right, but this I-D only deals with the integrity data exchange using the notify payload. Thanks. Marcus -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Friday, September 11, 2009 3:23 PM To: mwong@huawei.com Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-wong-ipsecme-ikev2-integrity-data-00.txt At 11:46 AM -0400 9/11/09, Marcus Wong wrote: >Hi Everyone, > >I'm new to the working group. I've uploaded a draft on the use of notify >payload for integrity data exchanges in IKEv2 for your comments and review. >All comments are highly appreciated. Thanks everyone. > > >A new version of I-D, draft-wong-ipsecme-ikev2-integrity-data-00.txt has >been successfuly submitted by Marcus Wong and posted to the IETF repository. > >Filename: draft-wong-ipsecme-ikev2-integrity-data >Revision: 00 >Title: Integrity Data Exchanges in IKEv2 >Creation_date: 2009-09-11 >WG ID: Independent Submission >Number_of_pages: 9 > >Abstract: >IKEv2 supports mutual authentication of the peers but does not support >platform integrity validation of the peers nor does it support the exchange >of data related to the platform integrity validation. This extension allows >platform integrity validation data to be exchanged from one peer (initiator) >to another (respondent), allowing the other peer to either use the data for >statistical analysis, pass it along to a validation entity for validation or >pass it along to a Fraud Information Gathering System for fraud detection or >analysis. > I have mot read you I-D, but this sounds like a NEA issue being pushed into an IPsec protocol. Am I wrong? Steve From kent@bbn.com Sat Sep 12 00:52:26 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CB0B3A682A for ; Sat, 12 Sep 2009 00:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70HMrKcOyhoD for ; Sat, 12 Sep 2009 00:52:25 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 863A23A6783 for ; Sat, 12 Sep 2009 00:52:25 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.59.1.235]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1MmMTl-0005Bs-EN; Sat, 12 Sep 2009 02:53:01 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <92E104320BB54EC5B8D3804FA61C8390@china.huawei.com> References: <002601ca1fb8$6ba9bcd0$800c6f0a@china.huawei.com> <99E2C4D8C30749A9A7B2A31CC2F434F9@china.huawei.com> <92E104320BB54EC5B8D3804FA61C8390@china.huawei.com> Date: Sat, 12 Sep 2009 03:47:35 -0400 To: mwong@huawei.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-wong-ipsecme-ikev2-integrity-data-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 07:52:26 -0000 At 4:06 PM -0400 9/11/09, Marcus Wong wrote: >Steve, you are mostly right, but this I-D only deals with the integrity data >exchange using the notify payload. Thanks. > >Marcus > Thanks for the clarification. That still raises the question of why we ought to duplicate this NEA functionality in IKE. Does the I-D provide suitable motivation for that, and has the idea been passed by the NEA WG folks? Steve From kato.akihiro@po.ntts.co.jp Thu Sep 10 22:13:17 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C9DD3A68C1 for ; Thu, 10 Sep 2009 22:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.399 X-Spam-Level: * X-Spam-Status: No, score=1.399 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Rg4OTFQHNoj for ; Thu, 10 Sep 2009 22:13:16 -0700 (PDT) Received: from mail2.ics.ntts.co.jp (mail2.ics.ntts.co.jp [202.32.24.42]) by core3.amsl.com (Postfix) with ESMTP id 911203A6817 for ; Thu, 10 Sep 2009 22:13:16 -0700 (PDT) Received: from sadoku34.silk.ntts.co.jp (sadoku34 [10.7.18.34]) by mail2.ics.ntts.co.jp (8.13.8/NTTSOFT) with ESMTP id n8B5DXnJ008598; Fri, 11 Sep 2009 14:13:33 +0900 (JST) Received: (from root@localhost) by sadoku34.silk.ntts.co.jp (8.13.8/NTTSOFT) id n8B5DX9t002095; Fri, 11 Sep 2009 14:13:33 +0900 (JST) Received: from ccm18.silk.ntts.co.jp [10.7.18.18] by sadoku34.silk.ntts.co.jp with SMTP id QAA02094; Fri, 11 Sep 2009 14:13:33 +0900 Received: from mail115.silk.ntts.co.jp (localhost [127.0.0.1]) by ccm18.silk.ntts.co.jp (8.14.3/NTTSOFT) with ESMTP id n8B5DXXU008490; Fri, 11 Sep 2009 14:13:33 +0900 (JST) Received: from mail115.silk.ntts.co.jp (localhost [127.0.0.1]) by mail115.silk.ntts.co.jp (8.14.3/NTTSOFT) with ESMTP id n8B5DXSY024773; Fri, 11 Sep 2009 14:13:33 +0900 (JST) Received: from [127.0.0.1] (helene.ms.ntts.co.jp [10.7.205.33]) by mail115.silk.ntts.co.jp (8.14.3/NTTSOFT) with ESMTP id n8B5DR8q024758; Fri, 11 Sep 2009 14:13:33 +0900 (JST) Message-ID: <4AA9DC78.1020403@po.ntts.co.jp> Date: Fri, 11 Sep 2009 14:13:28 +0900 From: KATO Akihiro User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "ipsec@ietf.org" Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-CC-Mail-RelayStamp: CC-Mail-V4-Client X-CC-Mail-RelayStamp: CC-Mail-V4-Server X-Mailman-Approved-At: Sat, 12 Sep 2009 01:54:21 -0700 Subject: [IPsec] Call for Review on draft-kanno-ipsecme-camellia-xcbc X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 05:20:35 -0000 Hi all, I've posted new revision of draft-kanno-ipsecme-camellia-xcbc. I summarize modifications. 1. Added TVs. Comments about our document would be welcome. We plan to make this draft to next step 'Publication Request' within two weeks. Regards. ------------------ new version of I-D, draft-kanno-ipsecme-camellia-xcbc-01.txt has been successfuly submitted by Akihiro Kato and posted to the IETF repository. Filename: draft-kanno-ipsecme-camellia-xcbc Revision: 01 Title: The Camellia-XCBC-96 and Camellia-XCBC-PRF-128 Algorithms and Its Use with IPsec Creation_date: 2009-09-09 WG ID: Independent Submission Number_of_pages: 11 Abstract: This memo specifies two new algorithms. One is the usage of XCBC mode with Camellia block cipher on the authentication mechanism of the IPsec Encapsulating Security Payload and Authentication Header protocols. This algorithm is called Camellia-XCBC-96. Latter is pseudo-random function based on XCBC with Camellia block cipher for Internet Key Exchange. This algorithm is called Camellia-XCBC-PRF- 128. The IETF Secretariat. ------------------ -- - KATO Akihiro + NTT Software Corporation akato (at) po (dot) ntts (d0t) co (dot) jp move to kato (d0t) akihiro (at) po (dot) ntts (d0t) co (dot) jp at July 1,2009 From yaronf@checkpoint.com Sat Sep 12 05:29:14 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51FD93A689C for ; Sat, 12 Sep 2009 05:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.869 X-Spam-Level: X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[AWL=0.730, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBlrVh3xat8f for ; Sat, 12 Sep 2009 05:29:13 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 23CF33A6882 for ; Sat, 12 Sep 2009 05:29:12 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n8CCTLSr022680; Sat, 12 Sep 2009 15:29:21 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sat, 12 Sep 2009 15:29:20 +0300 From: Yaron Sheffer To: Stephen Kent , "mwong@huawei.com" Date: Sat, 12 Sep 2009 15:29:19 +0300 Thread-Topic: [IPsec] draft-wong-ipsecme-ikev2-integrity-data-00.txt Thread-Index: AcozfhTRTGu62M82RpCDgCxzrIgYYQAJhZCg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190A978F8E7@il-ex01.ad.checkpoint.com> References: <002601ca1fb8$6ba9bcd0$800c6f0a@china.huawei.com> <99E2C4D8C30749A9A7B2A31CC2F434F9@china.huawei.com> <92E104320BB54EC5B8D3804FA61C8390@china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] draft-wong-ipsecme-ikev2-integrity-data-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 12:29:14 -0000 I completely agree that we shouldn't be duplicating the NEA protocols. OTOH= , I'm willing to consider transport of NEA information within IKE/IPsec if = people are interested. Note that NEA has just only started to look at their= own mainstream transport protocol (NEA-PT). This is very likely to end up = being EAP. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Stephen Kent > Sent: Saturday, September 12, 2009 10:48 > To: mwong@huawei.com > Cc: ipsec@ietf.org > Subject: Re: [IPsec] draft-wong-ipsecme-ikev2-integrity-data-00.txt > > At 4:06 PM -0400 9/11/09, Marcus Wong wrote: > >Steve, you are mostly right, but this I-D only deals with the integrity > data > >exchange using the notify payload. Thanks. > > > >Marcus > > > > Thanks for the clarification. That still raises the question of why > we ought to duplicate this NEA functionality in IKE. Does the I-D > provide suitable motivation for that, and has the idea been passed by > the NEA WG folks? > > Steve > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. From taddyhatty@nifty.com Sat Sep 12 09:29:27 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E84DA3A6928 for ; Sat, 12 Sep 2009 09:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_20=-0.74, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrKrQZdPsjyz for ; Sat, 12 Sep 2009 09:29:27 -0700 (PDT) Received: from userg501.nifty.com (userg501.nifty.com [202.248.238.81]) by core3.amsl.com (Postfix) with ESMTP id BBE973A68F9 for ; Sat, 12 Sep 2009 09:29:26 -0700 (PDT) Received: from GATEWAY (nttkyo397250.tkyo.nt.ftth.ppp.infoweb.ne.jp [125.2.62.250])by userg501.nifty.com with SMTP id n8CGTxE9003066; Sun, 13 Sep 2009 01:29:59 +0900 DomainKey-Signature: a=rsa-sha1; s=userg501; d=nifty.com; c=nofws; q=dns; h=message-id:reply-to:from:to:references:subject:date: organization:mime-version:content-type: content-transfer-encoding:x-priority:x-msmail-priority:x-mailer:x-mimeole; b=EseTEK9B9aO5hgw0aQpmtvqqMr20SDQhH9b9cxLxDv0xPtvKDdPDQxdCFha5h3LBw sJhaIGJOQ2PHmCHlmirFA== X-Nifty-SrcIP: [125.2.62.250] Message-ID: From: "Tadayuki Abraham HATTORI" To: "KATO Akihiro" , References: <4AA9DC78.1020403@po.ntts.co.jp> Date: Sun, 13 Sep 2009 01:29:59 +0900 Organization: TaddyHatty MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [IPsec] Call for Review on draft-kanno-ipsecme-camellia-xcbc X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Tadayuki Abraham HATTORI List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 16:29:28 -0000 What is randomness? The answer is this. The series that is difficult to be found out characteristics and trends and for observer of series, it have to be difficult to predict. Without mathematical definition of recognizing process of randomness by a humanity, anywork may be a kind of waste of generation. If IT engineers adopted the kind of waste to the life of citizens directly, it could be called as a kind of criminal. > > Hi all, > > I've posted new revision of draft-kanno-ipsecme-camellia-xcbc. > > I summarize modifications. > > 1. Added TVs. > > Comments about our document would be welcome. > > We plan to make this draft to next step 'Publication Request' within two > weeks. > > Regards. > ------------------ > new version of I-D, draft-kanno-ipsecme-camellia-xcbc-01.txt has been > successfuly submitted by Akihiro Kato and posted to the IETF repository. > > Filename: draft-kanno-ipsecme-camellia-xcbc > Revision: 01 > Title: The Camellia-XCBC-96 and Camellia-XCBC-PRF-128 Algorithms and Its > Use with IPsec > Creation_date: 2009-09-09 > WG ID: Independent Submission > Number_of_pages: 11 > > Abstract: > This memo specifies two new algorithms. One is the usage of XCBC > mode with Camellia block cipher on the authentication mechanism of > the IPsec Encapsulating Security Payload and Authentication Header > protocols. This algorithm is called Camellia-XCBC-96. Latter is > pseudo-random function based on XCBC with Camellia block cipher for > Internet Key Exchange. This algorithm is called Camellia-XCBC-PRF- > 128. > > > > > The IETF Secretariat. > > ------------------ > > > -- > - KATO Akihiro > + NTT Software Corporation > akato (at) po (dot) ntts (d0t) co (dot) jp move to > kato (d0t) akihiro (at) po (dot) ntts (d0t) co (dot) jp > at July 1,2009 > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From yaronf@checkpoint.com Sat Sep 12 12:03:07 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F0063A6405 for ; Sat, 12 Sep 2009 12:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.893 X-Spam-Level: X-Spam-Status: No, score=-2.893 tagged_above=-999 required=5 tests=[AWL=0.706, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HVU3qmNJHD6 for ; Sat, 12 Sep 2009 12:03:06 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id BC9873A6877 for ; Sat, 12 Sep 2009 12:03:05 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n8CJ3iSr001915 for ; Sat, 12 Sep 2009 22:03:44 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sat, 12 Sep 2009 22:03:43 +0300 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Sat, 12 Sep 2009 22:03:41 +0300 Thread-Topic: [IPsec] IPSECME Virtual Interim Meeting Thread-Index: AcomczSstU9uhrDZQveQwv78GDNZbANZl9Sw Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190A978F8F9@il-ex01.ad.checkpoint.com> References: <20090826173221.F14CB28C4C5@core3.amsl.com> In-Reply-To: <20090826173221.F14CB28C4C5@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] IPSECME Virtual Interim Meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 19:03:07 -0000 Here's another quick reminder of the upcoming virtual interim meeting. Note= that the meeting agenda is still open. If you have items you'd want to dis= cuss, please raise them with Paul and myself. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > IESG Secretary > Sent: Wednesday, August 26, 2009 20:32 > To: IETF Announcement list > Cc: ipsec@ietf.org > Subject: [IPsec] IPSECME Virtual Interim Meeting >=20 > The ipsecme WG will have a virtual interim WG meeting in about a month. W= e > will have a conference call on Tuesday September 22, 15:00 GMT (18:00 > Israel, 17:00 CET, 11:00 EDT, 8:00 PDT), for 2 hours. We are planning on > the same format as the previous time: a VoIP conference bridge and posted > slides. Technical details are available here: >=20 > http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/ConferenceCalls >=20 > A detailed agenda will be posted to the ipsec@ietf.org mailing list > closer to the meeting. >=20 > Thanks, > Yaron Sheffer and Paul Hoffman From taddyhatty@nifty.com Sat Sep 12 19:09:38 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48F803A685D for ; Sat, 12 Sep 2009 19:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwVyc+1e3dBH for ; Sat, 12 Sep 2009 19:09:37 -0700 (PDT) Received: from userg502.nifty.com (userg502.nifty.com [202.248.238.82]) by core3.amsl.com (Postfix) with ESMTP id 2EEA73A6855 for ; Sat, 12 Sep 2009 19:09:36 -0700 (PDT) Received: from GATEWAY (nttkyo397250.tkyo.nt.ftth.ppp.infoweb.ne.jp [125.2.62.250])by userg502.nifty.com with SMTP id n8D2A0CS029223; Sun, 13 Sep 2009 11:10:00 +0900 DomainKey-Signature: a=rsa-sha1; s=userg502; d=nifty.com; c=nofws; q=dns; h=message-id:reply-to:from:to:references:subject:date: organization:mime-version:content-type: content-transfer-encoding:x-priority:x-msmail-priority:x-mailer:x-mimeole; b=HQY6tBXmTjzL3gQiPEy5IO23J4ELDdyZR0i3ziVvV9H4ThrqyIj5qtf0ljzXz01f5 JtPU9uuH7UJ9EbEe7Qsew== X-Nifty-SrcIP: [125.2.62.250] Message-ID: <9A9F31528C0442439EF6A78A1D00209F@GATEWAY> From: "Tadayuki Abraham HATTORI" To: "KATO Akihiro" , References: <4AA9DC78.1020403@po.ntts.co.jp> Date: Sun, 13 Sep 2009 11:10:00 +0900 Organization: TaddyHatty MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [IPsec] Call for Review on draft-kanno-ipsecme-camellia-xcbc X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Tadayuki Abraham HATTORI List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2009 02:09:38 -0000 Without a proof or defitnion of "randomness", why can so many Japanese IT engineers proceed works? Basically, Japanese IT engineers should obey "idea of genious" rather than implicit habits or culture or a kind of religion. If Japanese IT engineers adopted the imported technology to the life of Japanese citizens directly, it could be called as a kind of criminal. Do you recognize that? The method to realize "randomness" is the method to generate unpredictable series that is difficult to be found out characteristics or trends. The mathematical proof have not been provided yet. A definition of randomness is a definition of a humanity. taddyhatty@acm.org > >> >> Hi all, >> >> I've posted new revision of draft-kanno-ipsecme-camellia-xcbc. >> >> I summarize modifications. >> >> 1. Added TVs. >> >> Comments about our document would be welcome. >> >> We plan to make this draft to next step 'Publication Request' within two >> weeks. >> >> Regards. >> ------------------ >> new version of I-D, draft-kanno-ipsecme-camellia-xcbc-01.txt has been >> successfuly submitted by Akihiro Kato and posted to the IETF repository. >> >> Filename: draft-kanno-ipsecme-camellia-xcbc >> Revision: 01 >> Title: The Camellia-XCBC-96 and Camellia-XCBC-PRF-128 Algorithms and Its >> Use with IPsec >> Creation_date: 2009-09-09 >> WG ID: Independent Submission >> Number_of_pages: 11 >> >> Abstract: >> This memo specifies two new algorithms. One is the usage of XCBC >> mode with Camellia block cipher on the authentication mechanism of >> the IPsec Encapsulating Security Payload and Authentication Header >> protocols. This algorithm is called Camellia-XCBC-96. Latter is >> pseudo-random function based on XCBC with Camellia block cipher for >> Internet Key Exchange. This algorithm is called Camellia-XCBC-PRF- >> 128. >> >> >> >> >> The IETF Secretariat. >> >> ------------------ >> >> >> -- >> - KATO Akihiro >> + NTT Software Corporation >> akato (at) po (dot) ntts (d0t) co (dot) jp move to >> kato (d0t) akihiro (at) po (dot) ntts (d0t) co (dot) jp >> at July 1,2009 >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Mon Sep 14 12:01:33 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92BEE3A6A8A for ; Mon, 14 Sep 2009 12:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.337 X-Spam-Level: X-Spam-Status: No, score=-3.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjHqSxAjR2wV for ; Mon, 14 Sep 2009 12:01:32 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 92F543A6A86 for ; Mon, 14 Sep 2009 12:01:24 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n8EJ27Sr004734; Mon, 14 Sep 2009 22:02:07 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 14 Sep 2009 22:02:06 +0300 From: Yoav Nir To: "ipsec@ietf.org WG" Date: Mon, 14 Sep 2009 22:02:06 +0300 Thread-Topic: [IPsec] Issue #26: Missing treatment of error cases Thread-Index: Aco1bdpa4bJW9ASVQ9eQpmeRfOS3tQ== Message-ID: References: <19109.286.34505.162897@fireball.kivinen.iki.fi> <73BF7996-C4FA-4442-B49D-DDD710CACA87@checkpoint.com> <19109.11583.348236.158555@fireball.kivinen.iki.fi> In-Reply-To: <19109.11583.348236.158555@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Tero Kivinen Subject: Re: [IPsec] Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 19:01:33 -0000 OK. One more try: 2.21. Error Handling There are many kinds of errors that can occur during IKE processing. If a request is received that is badly formatted, or unacceptable =20 for reasons of policy (e.g., no matching cryptographic algorithms), the response MUST contain a Notify payload indicating the error. If an error occurs in the processing of an IKE_AUTH response, and leads to an authentication failure, then the initiator MAY initiate an INFORMATIONAL exchange with a Notify payload describing the problem. For other invalid responses, it is not a good idea to initiate an exchange for carrying a Notify payload, but the node should take =20 care to clean up the state (for example, by sending DELETEs for bad SAs). If an error occurs outside the context of an IKE request (e.g., the node is getting ESP messages on a nonexistent SPI), the node SHOULD initiate an INFORMATIONAL exchange with a Notify payload describing the problem. Errors that occur before a cryptographically protected IKE SA is established must be handled very carefully. There is a trade-off between wanting to be helpful in diagnosing a problem and responding to it and wanting to avoid being a dupe in a denial of service =20 attack based on forged messages. If a node receives a message on UDP port 500 or 4500 outside the context of an IKE SA known to it (and not a request to start one), =20 it may be the result of a recent crash of the node. If the message is marked as a response, the node MAY audit the suspicious event but MUST NOT respond. If the message is marked as a request, the node MAY audit the suspicious event and MAY send a response. If a response is sent, the response MUST be sent to the IP address and port from whence it came with the same IKE SPIs and the Message ID copied. The response MUST NOT be cryptographically protected and MUST contain a Notify payload indicating INVALID_IKE_SPI. The INVALID_IKE_SPI notification indicates an IKE message was received with an unrecognized destination SPI; this usually indicates that =20 the recipient has rebooted and forgotten the existence of an IKE SA. A node receiving such an unprotected Notify payload MUST NOT respond and MUST NOT change the state of any existing SAs. The message =20 might be a forgery or might be a response, the genuine correspondent was tricked into sending. A node should treat such a message (and =20 also a network message like ICMP destination unreachable) as a hint that there might be problems with SAs to that IP address and should initiate a liveness check for any such IKE SA. An implementation SHOULD limit the frequency of such tests to avoid being tricked into participating in a denial of service attack. A node receiving a suspicious message from an IP address (and port, if NAT traversal is used) with which it has an IKE SA SHOULD send an IKE Notify payload in an IKE INFORMATIONAL exchange over that SA. The recipient MUST NOT change the state of any SAs as a result, but may wish to audit the event to aid in diagnosing malfunctions. A node MUST limit the rate at which it will send messages in response to unprotected messages. All errors that occur in an IKE_AUTH exchange, causing the authentication to fail for whatever reason (invalid shared secret, invalid ID, untrusted certificate issuer, revoked or expired certificate, etc.) SHOULD result in an AUTHENTICATION_FAILED notification. If the error occurred on the responder, the notification is returned in the protected response, and is usually the only payload in that response. If the error occurs on the initiator, the notification MAY be returned in a separate INFORMATIONAL exchange, usually with no other payloads. Note, however, that messages that contain an unsupported critical payload, or where the whole message is malformed (rather than just bad =20 payload contents), MUST be rejected in their entirety, and only lead to an UNSUPPORTED_CRITICAL_PAYLOAD or INVALID_SYNTAX Notification. The receiver should not verify the payloads related to authentication in this case. If authentication has succeeded in the IKE_AUTH exchange, the IKE SA is established, but establishing the child SA, or requesting configuration information may still fail. This failure does not automatically cause the IKE SA to be deleted. Specifically, a responder may include all the payloads associated with =20 authentication (IDr, Cert and AUTH) while sending error notifications for the piggybacked exchanges (FAILED_CP_REQUIRED, INVALID_SELECTORS, NO_PROPOSAL_CHOSEN, etc.), and the initiator MUST NOT fail the authentication because of this. The initiator MAY, of course, for reasons of policy later delete such an IKE SA. Only authentication failures and malformed messages lead to a deletion of the IKE SA without requiring an explicit INFORMATIONAL exchange carrying a DELETE payload. Other error conditions require such an exchange, if policy dictates that this is needed. In an IKE_SA_INIT exchange, any error notification causes the exchange to fail, although some, like COOKIE, INVALID_KE_PAYLOAD or INVALID_MAJOR_VERSION may lead to a subsequent successful exchange. In an IKE_AUTH exchange, or in the INFORMATIONAL exchange =20 immediately following it, only the following notifications cause the IKE SA to =20 be deleted or not created, without a DELETE payload: o UNSUPPORTED_CRITICAL_PAYLOAD o INVALID_SYNTAX o AUTHENTICATION_FAILED Extension documents may define new error notifications with these semantics, but MUST NOT use them unless the peer is known to understand them. From ynir@checkpoint.com Mon Sep 14 12:02:51 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D3173A67F6 for ; Mon, 14 Sep 2009 12:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.337 X-Spam-Level: X-Spam-Status: No, score=-3.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ivU53aXyuqh for ; Mon, 14 Sep 2009 12:02:50 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id EE36128C160 for ; Mon, 14 Sep 2009 12:02:46 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n8EJ3USr005015; Mon, 14 Sep 2009 22:03:30 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 14 Sep 2009 22:03:29 +0300 From: Yoav Nir To: "ipsec@ietf.org WG" Date: Mon, 14 Sep 2009 22:03:28 +0300 Thread-Topic: [IPsec] Issue #26: Missing treatment of error cases Thread-Index: Aco1bgsqhKrow+SzRlWwgtQitTl8EA== Message-ID: References: <19109.286.34505.162897@fireball.kivinen.iki.fi> <73BF7996-C4FA-4442-B49D-DDD710CACA87@checkpoint.com> <19109.11583.348236.158555@fireball.kivinen.iki.fi> In-Reply-To: <19109.11583.348236.158555@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Tero Kivinen Subject: Re: [IPsec] Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 19:02:51 -0000 OK. One more try: 2.21. Error Handling There are many kinds of errors that can occur during IKE processing. If a request is received that is badly formatted, or unacceptable =20 for reasons of policy (e.g., no matching cryptographic algorithms), the response MUST contain a Notify payload indicating the error. If an error occurs in the processing of an IKE_AUTH response, and leads to an authentication failure, then the initiator MAY initiate an INFORMATIONAL exchange with a Notify payload describing the problem. For other invalid responses, it is not a good idea to initiate an exchange for carrying a Notify payload, but the node should take =20 care to clean up the state (for example, by sending DELETEs for bad SAs). If an error occurs outside the context of an IKE request (e.g., the node is getting ESP messages on a nonexistent SPI), the node SHOULD initiate an INFORMATIONAL exchange with a Notify payload describing the problem. Errors that occur before a cryptographically protected IKE SA is established must be handled very carefully. There is a trade-off between wanting to be helpful in diagnosing a problem and responding to it and wanting to avoid being a dupe in a denial of service =20 attack based on forged messages. If a node receives a message on UDP port 500 or 4500 outside the context of an IKE SA known to it (and not a request to start one), =20 it may be the result of a recent crash of the node. If the message is marked as a response, the node MAY audit the suspicious event but MUST NOT respond. If the message is marked as a request, the node MAY audit the suspicious event and MAY send a response. If a response is sent, the response MUST be sent to the IP address and port from whence it came with the same IKE SPIs and the Message ID copied. The response MUST NOT be cryptographically protected and MUST contain a Notify payload indicating INVALID_IKE_SPI. The INVALID_IKE_SPI notification indicates an IKE message was received with an unrecognized destination SPI; this usually indicates that =20 the recipient has rebooted and forgotten the existence of an IKE SA. A node receiving such an unprotected Notify payload MUST NOT respond and MUST NOT change the state of any existing SAs. The message =20 might be a forgery or might be a response, the genuine correspondent was tricked into sending. A node should treat such a message (and =20 also a network message like ICMP destination unreachable) as a hint that there might be problems with SAs to that IP address and should initiate a liveness check for any such IKE SA. An implementation SHOULD limit the frequency of such tests to avoid being tricked into participating in a denial of service attack. A node receiving a suspicious message from an IP address (and port, if NAT traversal is used) with which it has an IKE SA SHOULD send an IKE Notify payload in an IKE INFORMATIONAL exchange over that SA. The recipient MUST NOT change the state of any SAs as a result, but may wish to audit the event to aid in diagnosing malfunctions. A node MUST limit the rate at which it will send messages in response to unprotected messages. All errors that occur in an IKE_AUTH exchange, causing the authentication to fail for whatever reason (invalid shared secret, invalid ID, untrusted certificate issuer, revoked or expired certificate, etc.) SHOULD result in an AUTHENTICATION_FAILED notification. If the error occurred on the responder, the notification is returned in the protected response, and is usually the only payload in that response. If the error occurs on the initiator, the notification MAY be returned in a separate INFORMATIONAL exchange, usually with no other payloads. Note, however, that messages that contain an unsupported critical payload, or where the whole message is malformed (rather than just bad =20 payload contents), MUST be rejected in their entirety, and only lead to an UNSUPPORTED_CRITICAL_PAYLOAD or INVALID_SYNTAX Notification. The receiver should not verify the payloads related to authentication in this case. If authentication has succeeded in the IKE_AUTH exchange, the IKE SA is established, but establishing the child SA, or requesting configuration information may still fail. This failure does not automatically cause the IKE SA to be deleted. Specifically, a responder may include all the payloads associated with =20 authentication (IDr, Cert and AUTH) while sending error notifications for the piggybacked exchanges (FAILED_CP_REQUIRED, INVALID_SELECTORS, NO_PROPOSAL_CHOSEN, etc.), and the initiator MUST NOT fail the authentication because of this. The initiator MAY, of course, for reasons of policy later delete such an IKE SA. Only authentication failures and malformed messages lead to a deletion of the IKE SA without requiring an explicit INFORMATIONAL exchange carrying a DELETE payload. Other error conditions require such an exchange, if policy dictates that this is needed. In an IKE_SA_INIT exchange, any error notification causes the exchange to fail, although some, like COOKIE, INVALID_KE_PAYLOAD or INVALID_MAJOR_VERSION may lead to a subsequent successful exchange. In an IKE_AUTH exchange, or in the INFORMATIONAL exchange =20 immediately following it, only the following notifications cause the IKE SA to =20 be deleted or not created, without a DELETE payload: o UNSUPPORTED_CRITICAL_PAYLOAD o INVALID_SYNTAX o AUTHENTICATION_FAILED Extension documents may define new error notifications with these semantics, but MUST NOT use them unless the peer is known to understand them. From akisada@tahi.org Mon Sep 14 21:56:46 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C262A3A6994 for ; Mon, 14 Sep 2009 21:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.495 X-Spam-Level: *** X-Spam-Status: No, score=3.495 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rm15bsaI-5D for ; Mon, 14 Sep 2009 21:56:45 -0700 (PDT) Received: from ns.64translator.com (70.145.221.202.bf.2iij.net [202.221.145.70]) by core3.amsl.com (Postfix) with ESMTP id 2069D3A698C for ; Mon, 14 Sep 2009 21:56:45 -0700 (PDT) Received: from bahamas.64translator.com (bahamas.64translator.com [10.21.32.3]) by ns.64translator.com (8.14.3/8.14.3) with ESMTP id n8F4NVDM028393 for ; Tue, 15 Sep 2009 13:23:31 +0900 (JST) (envelope-from akisada@tahi.org) Received: from localhost (dhcp163.64translator.com [10.21.32.163]) by bahamas.64translator.com (8.13.6/8.13.6) with SMTP id n8F4u9XK079831 for ; Tue, 15 Sep 2009 13:56:09 +0900 (JST) (envelope-from akisada@tahi.org) Date: Tue, 15 Sep 2009 13:56:09 +0900 From: Yukiyo Akisada To: ipsec@ietf.org Message-Id: <20090915135609.4110885a.akisada@tahi.org> Organization: TAHI Project X-Mailer: Sylpheed version 2.3.0beta5 (GTK+ 2.8.12; i386-portbld-freebsd4.11) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [IPsec] [IKEv2] the newest tester is available now X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 04:56:46 -0000 Hi, all. IPv6 Ready Logo Committee published the newest test specification (v1.0.3). Major changes are - Fixed test procedure to invoke INVALID_KE_PAYLOAD - Permitted to omit INTEG transform when the integrity algorithm is NONE Then TAHI Project also released the conformance test tool -- IKEv2_Self_Test v1.0.3 supporting this test specification. Since this version of IKEv2_Self_Test strongly requires to use koi v2.1.6, please replace your koi when you update IKEv2_Self_Test to v1.0.3. You can get them from the following URLs. - Test script: IKEv2_Self_Test - Test platform: koi Thanks, -- Yukiyo Akisada From Pasi.Eronen@nokia.com Tue Sep 15 11:03:25 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 359253A6B68 for ; Tue, 15 Sep 2009 11:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.404 X-Spam-Level: X-Spam-Status: No, score=-6.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRGRuBuo7xs0 for ; Tue, 15 Sep 2009 11:03:24 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id DCC7128C182 for ; Tue, 15 Sep 2009 11:03:20 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n8FI3krH018418 for ; Tue, 15 Sep 2009 21:03:51 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Sep 2009 21:03:57 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Sep 2009 21:03:57 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 15 Sep 2009 20:03:56 +0200 From: To: Date: Tue, 15 Sep 2009 20:03:54 +0200 Thread-Topic: Last call comments for ROHCoIPsec: draft-ietf-rohc-hcoipsec, draft-ietf-rohc-ikev2-extensions-hcoipsec, draft-ietf-rohc-ipsec-extensions-hcoipsec Thread-Index: Aco1G5qqJqKO/v8QRPqhZwuWkWpUvwBExmOA Message-ID: <808FD6E27AD4884E94820BC333B2DB773C06A830B7@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 15 Sep 2009 18:03:57.0039 (UTC) FILETIME=[E4E997F0:01CA362E] X-Nokia-AV: Clean Subject: [IPsec] FW: Last call comments for ROHCoIPsec: draft-ietf-rohc-hcoipsec, draft-ietf-rohc-ikev2-extensions-hcoipsec, draft-ietf-rohc-ipsec-extensions-hcoipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 18:03:25 -0000 (Forwarding to IPSECME list, too. I would encourage other WG members to review these drafts and comment, too. -Pasi) > -----Original Message----- > From: Eronen Pasi (Nokia-NRC/Helsinki) > Sent: 14 September, 2009 12:13 > To: ietf@ietf.org; 'rohc@ietf.org' > Cc: 'ertekin_emre@bah.com' > Subject: Last call comments for ROHCoIPsec: draft-ietf-rohc-hcoipsec, > draft-ietf-rohc-ikev2-extensions-hcoipsec, draft-ietf-rohc-ipsec- > extensions-hcoipsec >=20 > I've reviewed the ROHCoIPsec draft set (not wearing any hats), and > have couple of comments. Most important first: >=20 > 1) None of the drafts really describe the reason why the ROHC ICV is > included. It was not present in the early drafts, and was added after > long and complex discussions. I would strongly encourage summarizing > those discussions in one of the drafts -- otherwise, the reader cannot > really figure out why the ROHC ICV is included (since the packets are > already protected by the AH/ESP ICV), and what risks omitting the ROHC > ICV might have. >=20 > 2) ipsec-extensions, Section 3.3, doesn't really correctly describe > the MTU-related processing in RFC 4301. The three cases refer to IPsec > implementations that both process unprotected ICMP messages and > actually receive them (they're often filtered in the network), and > thus have a Path MTU estimate value. But an IPsec implementation that > doesn't process (or receive) unprotected ICMP messages does not even > have a Path MTU estimate value... >=20 > 3) According to RFC 4224, ROHC segmentation does not work over > reordering channels. Thus, it seems suggesting that ROHC segmentation > could be used instead of pre-encryption fragmentation (e.g. > ipsec-extensions, Section 3.3) -- and in general, allowing > segmentation at all -- seems misguided (it's unnecessary complexity > that would be IMHO best left out). >=20 > 4) None of the drafts have any RFC 2119 keywords (MUST/SHOULD/etc). > They SHOULD use those to make it less ambiguous what is the required > behavior (and what is optional) to claim compliance with these drafts. >=20 > 5) In ikev2-extensions, Section 2.1.2 it is not very clear which of > the attributes are just one-way notifications (the sender of the > attribute tells the other end what it can handle), and which are > negotiated (the initiator tells the other end what it supports; the > responder then selects one, and tells what it selected). >=20 > I would suggest adding text like "Note that different ATTRIBUTE_NAME > value can be used in each direction" for those attributes that are > just one-way (I think at least MAX_CID, ROHC_PROFILE -- for MRRU and > ROHC_ICV_LEN, I don't know which way they're supposed to work). >=20 > 6) ikev2-extensions, Section 2.1.2, says "The key for this Integrity > Algorithm is computed using the same method as is used to compute > IPsec's Integrity Algorithm key ([IKEV2], Section 2.17)." I don't > think this is sufficient to get interoperable implementations; more > details are needed. >=20 > In addition, there's couple of places that probably need some > clarifications and/or minor fixes: >=20 > 7) ikev2-extensions, Section 2.1.2, ROHC_ICV_LEN: The text talks about > "announcing their preference"; how is the actual ICV length determined > from these preferences? >=20 > 8) ikev2-extensions, Section 2.1.2, ROHC_INTEG: Should also describe > what happens if the responder doesn't accept any of the algorithms > proposed by the initiator (not doing ROHC at all would be one obvious > alternative; NO_PROPOSAL_CHOSEN another). >=20 > 9) ikev2-extensions, Section 2.1.1, says "The most significant bit in > the > field is the Attribute Format (AF) bit." No, according to Figure 2 > "AF" is a separate field, not part of the "ROHC Attribute Type" field. >=20 > 10) ipsec-extensions, Section 3.2, says "The authentication data must > not be included in the calculation of the ICV." This is very vague, > considering that we have several different authentication data/ICVs > here. Is the intent to say "The ROHC ICV field is not included in the > calculation of the ROHC ICV", or something else? >=20 > 11) ikev2-extensions, Section 4: "6-65536 Unassigned" should be > "6-32767 Unassigned". >=20 > Best regards, > Pasi From root@core3.amsl.com Tue Sep 15 18:00:02 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1A65C3A67A2; Tue, 15 Sep 2009 18:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090916010002.1A65C3A67A2@core3.amsl.com> Date: Tue, 15 Sep 2009 18:00:02 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-aes-ctr-ikev2-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 01:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Using Advanced Encryption Standard (AES) Counter Mode with IKEv2 Author(s) : S. Shen, et al. Filename : draft-ietf-ipsecme-aes-ctr-ikev2-02.txt Pages : 18 Date : 2009-09-15 This document describes the usage of Advanced Encryption Standard Counter Mode (AES_CTR), with an explicit initialization vector, by IKEv2 for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT exchange. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-aes-ctr-ikev2-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-aes-ctr-ikev2-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-15174652.I-D@ietf.org> --NextPart-- From seye586@hotmail.com Tue Sep 15 18:54:08 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAAC13A659A for ; Tue, 15 Sep 2009 18:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.451 X-Spam-Level: **** X-Spam-Status: No, score=4.451 tagged_above=-999 required=5 tests=[BAYES_80=2, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFUBV-IlReaW for ; Tue, 15 Sep 2009 18:54:07 -0700 (PDT) Received: from blu0-omc2-s13.blu0.hotmail.com (blu0-omc2-s13.blu0.hotmail.com [65.55.111.88]) by core3.amsl.com (Postfix) with ESMTP id 3285C28C110 for ; Tue, 15 Sep 2009 18:54:07 -0700 (PDT) Received: from BLU102-W21 ([65.55.111.73]) by blu0-omc2-s13.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Sep 2009 18:54:55 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_cc2212bf-d522-40c3-b5ba-8eb44a46e9ac_" X-Originating-IP: [218.211.253.68] From: shih luke To: Date: Wed, 16 Sep 2009 09:54:55 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 16 Sep 2009 01:54:55.0722 (UTC) FILETIME=[B0666CA0:01CA3670] Subject: [IPsec] GRE over IPsec....... Any help would be appreciated X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 02:28:04 -0000 --_cc2212bf-d522-40c3-b5ba-8eb44a46e9ac_ Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 8bit hello everybody GRE over IPsec i follow this ducument to implement GRE over IPsec http://www.lipasys.de/download/ospfipsec pc pc eth1 eth0 eth0 eth1 subnet A------------------ |route A|-----------------| internet |-------------|goute b|------------------subnet B 172.1.1.0/24 172.1.1.2 10.120.10.10 10.120.11.11 192.168.200.3 192.168.200.0/24 ------------------------------------------------------------------- route A eth0 public ip 10.120.10.10 eth1 private ip 172.1.1.2 subnet 172.1.1.0/24 route b eth0 public ip 10.120.11.11 eth1 private ip 192.168.200.254 subnet 192.168.200.0/24 ftp b in subnet b ip address is 192.168.200.3 ------------------------------------------------------------ gre1 route a ip tunnel add gre1 mode gre local 172.1.1.2 remote 192.168.200.254 route b ip tunnel add gre1 mode gre local 192.168.200.254 remote 172.1.1.2 ----------------------------------------------------------------- when host a download data from ftp b when i tcpdump -i th0 13:03:34.883617 IP 10.120.11.11 > 10.120.10.10: ah 13:03:34.883617 IP 10.120.11.11 > 10.120.10.10: ESP(spi=0x031fd4bb,seq=0xace7), length 1532 13:03:34.883617 IP 192.168.200.3.20582 > 172.1.1.2.49475: P 62886173:62887633(1460) ack 1 win 32768 13:03:34.884161 IP 10.120.10.10 > 10.120.11.11: AH(spi=0x0f06b57c,seq=0x587c): IP 10.120.10.10 > 10.120.11.11: ESP(spi=0x075f9137,seq=0x587c), length 76 (ipip-proto-4) 13:03:34.884341 IP 10.120.11.11 > 10.120.10.10: AH(spi=0x0c6212d3,seq=0xace8): IP truncated-ip - 96 bytes missing! 10.120.11.11 > 10.120.10.10: ESP(spi=0x031fd4bb,seq=0xace8), length 1532 (ipip-proto-4) 13:03:34.884355 IP 10.120.11.11 > 10.120.10.10: ah 13:03:35.132418 IP 10.120.11.11 > 10.120.10.10: AH(spi=0x0c6212d3,seq=0xae5c): IP truncated-ip - 96 bytes missing! 10.120.11.11 > 10.120.10.10: ESP(spi=0x031fd4bb,seq=0xae5c), length 1532 (ipip-proto-4) 13:03:35.132441 IP 10.120.11.11 > 10.120.10.10: ah 13:03:35.132958 IP 10.120.11.11 > 10.120.10.10: ah 13:03:35.134900 IP 10.120.11.11 > 10.120.10.10: AH(spi=0x0c6212d3,seq=0xae61): IP truncated-ip - 96 bytes missing! 10.120.11.11 > 10.120.10.10: ESP(spi=0x031fd4bb,seq=0xae61), length 1532 (ipip-proto-4) 13:03:35.134915 IP 10.120.11.11 > 10.120.10.10: ah 13:03:35.134915 IP 10.120.11.11 > 10.120.10.10: ESP(spi=0x031fd4bb,seq=0xae61), length 1532 13:03:35.137374 IP 10.120.11.11 > 10.120.10.10: AH(spi=0x0c6212d3,seq=0xae66): IP truncated-ip - 96 bytes missing! 10.120.11.11 > 10.120.10.10: ESP(spi=0x031fd4bb,seq=0xae66), length 1532 (ipip-proto-4) 13:03:35.137386 IP 10.120.11.11 > 10.120.10.10: ah 13:03:35.137386 IP 10.120.11.11 > 10.120.10.10: ESP(spi=0x031fd4bb,seq=0xae66), length 1532 13:03:35.145620 IP 10.120.10.10 > 10.120.11.11: AH(spi=0x0f06b57c,seq=0x5934): IP 10.120.10.10 > 10.120.11.11: ESP(spi=0x075f9137,seq=0x5934), length 76 (ipip-proto-4) 13:03:35.145689 IP 10.120.10.10 > 10.120.11.11: AH(spi=0x0f06b57c,seq=0x5935): IP 10.120.10.10 > 10.120.11.11: ESP(spi=0x075f9137,seq=0x5935), length 76 (ipip-proto-4) 13:03:35.145736 IP 10.120.10.10 > 10.120.11.11: AH(spi=0x0f06b57c,seq=0x5936): IP 10.120.10.10 > 10.120.11.11: ESP(spi=0x075f9137,seq=0x5936), length 76 (ipip-proto-4) 13:03:35.145782 IP 10.120.10.10 > 10.120.11.11: AH(spi=0x0f06b57c,seq=0x5937): IP 10.120.10.10 > 10.120.11.11: ESP(spi=0x075f9137,seq=0x5937), length 76 (ipip-proto-4) 13:03:35.145828 IP 10.120.10.10 > 10.120.11.11: AH(spi=0x0f06b57c,seq=0x5938): IP 10.120.10.10 > 10.120.11.11: ESP(spi=0x075f9137,seq=0x5938), length 76 (ipip-proto-4) 13:03:35.145872 IP 10.120.10.10 > 10.120.11.11: AH(spi=0x0f06b57c,seq=0x5939): IP 10.120.10.10 > 10.120.11.11: ESP i dont see the gre packet at eth0 tcpdump -i gre1 there is no packets or messages is it right???? Any help would be appreciated thank you _________________________________________________________________ ¥Î³¡¸¨®æ¤À¨É·Ó¤ù¡B¼v­µ¡B½ì¨ý¤p¤u¨ã©M³Ì·R²M³æ¡AºÉ±¡¨q¥X§A¦Û¤v ¡X Windows Live Spaces http://home.spaces.live.com/?showUnauth=1&lc=1028 --_cc2212bf-d522-40c3-b5ba-8eb44a46e9ac_ Content-Type: text/html; charset="big5" Content-Transfer-Encoding: 8bit hello everybody
       
      GRE over IPsec
       
      i follow this ducument to implement GRE over IPsec
       
      http://www.lipasys.de/download/ospfipsec
                                                           
                                                    &nbs p;         pc                                                              pc
                                       eth1           eth0                                          eth0        eth1
      subnet A------------------ |route A|-----------------| internet |-------------|goute b|------------------subnet B
      172.1.1.0/24         172.1.1.2     10.120.10.10                  10.120.11.11      192.168.200.3         192.168.200.0/24
       
      ------------------------------------------------------------------- 
      route A
       
      eth0  public ip 10.120.10.10

      eth1  private ip 172.1.1.2

      subnet 172.1.1.0/24

      route b

      eth0 public ip 10.120.11.11

      eth1 private ip 192.168.200.254

      subnet 192. 168.200.0/24

      ftp b in subnet b ip address is 192.168.200.3
      ------------------------------------------------------------
      gre1
       
      route a
       
      ip tunnel add gre1 mode gre local 172.1.1.2 remote 192.168.200.254
       
      route b
       
      ip tunnel add gre1 mode gre local 192.168.200.254 remote 172.1.1.2
       
      -----------------------------------------------------------------
      when host a download data from ftp b
       
      when i tcpdump -i th0
       
       
      13:03:34.883617 IP 10.120.11.11 > 10.120.10.10: ah
      13:03:34.883617 IP 10.120.11.11 > 10.120.10.10: ESP(spi= 0x031fd4bb,seq=0xace7), length 1532
      13:03:34.883617 IP 192.168.200.3.20582 > 172.1.1.2.49475: P 62886173:62887633(1460) ack 1 win 32768
      13:03:34.884161 IP 10.120.10.10 > 10.120.11.11: AH(spi=0x0f06b57c,seq=0x587c): IP 10.120.10.10 > 10.120.11.11: ESP(spi=0x075f9137,seq=0x587c), length 76 (ipip-proto-4)
      13:03:34.884341 IP 10.120.11.11 > 10.120.10.10: AH(spi=0x0c6212d3,seq=0xace8): IP truncated-ip - 96 bytes missing! 10.120.11.11 > 10.120.10.10: ESP(spi=0x031fd4bb,seq=0xace8), length 1532 (ipip-proto-4)
      13:03:34.884355 IP 10.120.11.11 > 10.120.10.10: ah
      13:03:35.132418 IP 10.120.11.11 > 10.120.10.10: AH(spi=0x0c6212d3,seq=0xae5c): IP truncated-ip - 96 bytes missing! 10.120.11.11 > 10.120.10.10: ESP(spi=0x031fd4bb,seq=0xae5c), length 1532 (ipip-proto-4)
      13:03:35.132441 IP 10.120.11.11 > 10.120.10.10: ah
      13:03:35.132958 IP 10.120.11.11 > 10.120.10.10: ah
      13:03:35.134900 IP 10.120.11.11 > 10.120.10.10: AH(spi=0x0c6212d3,seq =0xae61): IP truncated-ip - 96 bytes missing! 10.120.11.11 > 10.120.10.10: ESP(spi=0x031fd4bb,seq=0xae61), length 1532 (ipip-proto-4)
      13:03:35.134915 IP 10.120.11.11 > 10.120.10.10: ah
      13:03:35.134915 IP 10.120.11.11 > 10.120.10.10: ESP(spi=0x031fd4bb,seq=0xae61), length 1532
      13:03:35.137374 IP 10.120.11.11 > 10.120.10.10: AH(spi=0x0c6212d3,seq=0xae66): IP truncated-ip - 96 bytes missing! 10.120.11.11 > 10.120.10.10: ESP(spi=0x031fd4bb,seq=0xae66), length 1532 (ipip-proto-4)
      13:03:35.137386 IP 10.120.11.11 > 10.120.10.10: ah
      13:03:35.137386 IP 10.120.11.11 > 10.120.10.10: ESP(spi=0x031fd4bb,seq=0xae66), length 1532
      13:03:35.145620 IP 10.120.10.10 > 10.120.11.11: AH(spi=0x0f06b57c,seq=0x5934): IP 10.120.10.10 > 10.120.11.11: ESP(spi=0x075f9137,seq=0x5934), length 76 (ipip-proto-4)
      13:03:35.145689 IP 10.120.10.10 > 10.120.11.11: AH(spi=0x0f06b57c,seq=0x5935): IP 10.120.10.10 > 10.120.11.11: ESP(spi=0x075f9137,seq=0x5935), l ength 76 (ipip-proto-4)
      13:03:35.145736 IP 10.120.10.10 > 10.120.11.11: AH(spi=0x0f06b57c,seq=0x5936): IP 10.120.10.10 > 10.120.11.11: ESP(spi=0x075f9137,seq=0x5936), length 76 (ipip-proto-4)
      13:03:35.145782 IP 10.120.10.10 > 10.120.11.11: AH(spi=0x0f06b57c,seq=0x5937): IP 10.120.10.10 > 10.120.11.11: ESP(spi=0x075f9137,seq=0x5937), length 76 (ipip-proto-4)
      13:03:35.145828 IP 10.120.10.10 > 10.120.11.11: AH(spi=0x0f06b57c,seq=0x5938): IP 10.120.10.10 > 10.120.11.11: ESP(spi=0x075f9137,seq=0x5938), length 76 (ipip-proto-4)
      13:03:35.145872 IP 10.120.10.10 > 10.120.11.11: AH(spi=0x0f06b57c,seq=0x5939): IP 10.120.10.10 > 10.120.11.11: ESP 
       
      i dont see the gre packet at eth0
       
      tcpdump -i gre1
      there is no packets or messages
       
      is it right????
       
      Any help would be appreciated
       
      thank you
       
       


      ¥Î³¡¸¨®æ¤À¨É·Ó¤ù¡B¼v­µ¡B½ì¨ý¤p¤u¨ã©M³Ì·R²M³æ¡AºÉ±¡¨q¥X§A¦Û¤v ¡X Windows Live Spaces --_cc2212bf-d522-40c3-b5ba-8eb44a46e9ac_-- From taddyhatty@nifty.com Tue Sep 15 22:48:06 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BAA93A6954 for ; Tue, 15 Sep 2009 22:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.741 X-Spam-Level: X-Spam-Status: No, score=-0.741 tagged_above=-999 required=5 tests=[AWL=-0.742, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMawshRGAmKG for ; Tue, 15 Sep 2009 22:48:05 -0700 (PDT) Received: from userg502.nifty.com (userg502.nifty.com [202.248.238.82]) by core3.amsl.com (Postfix) with ESMTP id 3E1683A690E for ; Tue, 15 Sep 2009 22:48:05 -0700 (PDT) Received: from GATEWAY (nttkyo397250.tkyo.nt.ftth.ppp.infoweb.ne.jp [125.2.62.250])by userg502.nifty.com with SMTP id n8G5moT2008486; Wed, 16 Sep 2009 14:48:50 +0900 DomainKey-Signature: a=rsa-sha1; s=userg502; d=nifty.com; c=nofws; q=dns; h=message-id:reply-to:from:to:references:subject:date: organization:mime-version:content-type: content-transfer-encoding:x-priority:x-msmail-priority:x-mailer:x-mimeole; b=wHgvqkBRVhUqEi3rR0yeV5VfRhy9XQYTJYj2pkb6Q6WQhPj7icOFHIkJU0JBe3j+V asMJUhcqgZTNWMAypiLjw== X-Nifty-SrcIP: [125.2.62.250] Message-ID: From: "Tadayuki Abraham HATTORI" To: "KATO Akihiro" , References: <4AA9DC78.1020403@po.ntts.co.jp> <9A9F31528C0442439EF6A78A1D00209F@GATEWAY> Date: Wed, 16 Sep 2009 14:48:50 +0900 Organization: TaddyHatty MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [IPsec] Call for Review on draft-kanno-ipsecme-camellia-xcbc X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Tadayuki Abraham HATTORI List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 05:48:06 -0000 > A definition of randomness is a definition of a humanity. Indeed, the matter is strongly related with theoretical proof of evolution of human intelligence. It is evolved from "gambling" to "investment or speculation".The matter is an ability of foreseeing. In order to define "randomness", let's consider the difference of investment, speculation and gambling. What is investment? Everyone can do investment. It can be automatically done according to some kinds of cost accounting theorem. CVP analysis are useful. Break even point can be automatically calculated. What is speculation? Speculation can be done by specific people. It will create "randomness" in our economiy. It can be explained by a kind of mathematical theorem of the "dirrerences of estimations of people". Speculation of human being is the origin of "randomness". What is gambling? Gambling can be done by even monkeys. With gambling, people, dolphins and monkeys could share fun. That's kind of my hypothesis about evolution of intelligence. It is beneficial to plain "public gambling spaces" with people, dolphins and monkeys. We can communicate each other through gambling. The "jongengine" which is a kind of lab. http://www.jongengine.net/ The concept of GPL looks like a kind of socialism or communism, However if they respect to "invent" not "inventory", they may be a kind of democrats. This was originally planned by MEEEEEEEEEEEEE as a kind of Volunteer, when I was an emplyee of Hewlett-Packard. At that time, the CEO of HP was Mrs.Carly Fiorina. At that time, I recommend local managers the fundamental concept of unconditional obeying to "idea of genious" rather than implicit habits or culture or a kind of religion. However many Japanese sales representatives and IT engineer couldn't understand the fundamental theorem of "evolution of intelligenc. Everybody couldn't emotionally recognize "genious" because everyone didn't know how to define a humanity. After that, I resigned from HP, and joined Sony Corporation. However, many IT engineers of sony were also. Nowadays, I resigned from Sony Corporation too. Japanese IT consultants or sales representatives should be fired, I think. They don't have "thought", so they can't promote the evolution of civilization. taddyhatty@acm.org > > > Without a proof or defitnion of "randomness", why can so many > Japanese IT engineers proceed works? > > Basically, Japanese IT engineers should obey "idea of genious" rather > than implicit habits or culture or a kind of religion. > > If Japanese IT engineers adopted the imported technology to the life of > Japanese citizens directly, it could be called as a kind of criminal. > Do you recognize that? > > The method to realize "randomness" is the method to generate > unpredictable series that is difficult to be found out characteristics > or trends. The mathematical proof have not been provided yet. > > A definition of randomness is a definition of a humanity. > > taddyhatty@acm.org > > >> >>> >>> Hi all, >>> >>> I've posted new revision of draft-kanno-ipsecme-camellia-xcbc. >>> >>> I summarize modifications. >>> >>> 1. Added TVs. >>> >>> Comments about our document would be welcome. >>> >>> We plan to make this draft to next step 'Publication Request' within >>> two >>> weeks. >>> >>> Regards. >>> ------------------ >>> new version of I-D, draft-kanno-ipsecme-camellia-xcbc-01.txt has been >>> successfuly submitted by Akihiro Kato and posted to the IETF repository. >>> >>> Filename: draft-kanno-ipsecme-camellia-xcbc >>> Revision: 01 >>> Title: The Camellia-XCBC-96 and Camellia-XCBC-PRF-128 Algorithms and Its >>> Use with IPsec >>> Creation_date: 2009-09-09 >>> WG ID: Independent Submission >>> Number_of_pages: 11 >>> >>> Abstract: >>> This memo specifies two new algorithms. One is the usage of XCBC >>> mode with Camellia block cipher on the authentication mechanism of >>> the IPsec Encapsulating Security Payload and Authentication Header >>> protocols. This algorithm is called Camellia-XCBC-96. Latter is >>> pseudo-random function based on XCBC with Camellia block cipher for >>> Internet Key Exchange. This algorithm is called Camellia-XCBC-PRF- >>> 128. >>> >>> >>> >>> >>> The IETF Secretariat. >>> >>> ------------------ >>> >>> >>> -- >>> - KATO Akihiro >>> + NTT Software Corporation >>> akato (at) po (dot) ntts (d0t) co (dot) jp move to >>> kato (d0t) akihiro (at) po (dot) ntts (d0t) co (dot) jp >>> at July 1,2009 >>> >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From kivinen@iki.fi Wed Sep 16 05:50:49 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AD4C3A67A4 for ; Wed, 16 Sep 2009 05:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4eDyDwNatrh for ; Wed, 16 Sep 2009 05:50:47 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 3041E3A659C for ; Wed, 16 Sep 2009 05:50:46 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n8GCpRMc011137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Sep 2009 15:51:27 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n8GCpPcw006887; Wed, 16 Sep 2009 15:51:25 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19120.57165.424835.989773@fireball.kivinen.iki.fi> Date: Wed, 16 Sep 2009 15:51:25 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: <19109.286.34505.162897@fireball.kivinen.iki.fi> <73BF7996-C4FA-4442-B49D-DDD710CACA87@checkpoint.com> <19109.11583.348236.158555@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 51 min X-Total-Time: 59 min Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 12:50:49 -0000 Yoav Nir writes: > OK. One more try: I think this is still bit confusing. How about splitting it to few subsections, i.e. 2.21. Error Handling 2.21.1 Error Handling in IKE_SA_INIT 2.21.2 Error Handling in IKE_AUTH 2.21.3 Error Handling after IKE SA is Authenticated 2.21.4 Error Handling Outside IKE SA or something. Now you need to be very careful when reading the text to understand when it is taking about IKE_AUTH or some other exchange and whether it is talking about errors in request and replies. For example the text could look something like this: ---------------------------------------------------------------------- 2.21. Error Handling There are many kinds of errors that can occur during IKE processing. The general rule is that if a request is received that is badly formatted, or unacceptable for reasons of policy (e.g., no matching cryptographic algorithms), the response contains a Notify payload indicating the error. Whether to send such response depends whether the there is authenticated IKE SA or not. If there is an error parsing or processing response packet, then generic rule is not to send any error back, as responses should not generate new requests (which would be the only way to send error message back). Such errors in parsing or processing response packets should still take care to clean up the state (for example, by sending DELETEs for bad SAs). Only authentication failures (AUTHENTICATION_FAILED) and malformed messages (INVALID_SYNTAX) lead to a deletion of the IKE SA without requiring an explicit INFORMATIONAL exchange carrying a DELETE payload. Other error conditions require such an exchange, if policy dictates that this is needed. 2.21.1 Error Handling in IKE_SA_INIT Errors that occur before a cryptographically protected IKE SA is established must be handled very carefully. There is a trade-off between wanting to be helpful in diagnosing a problem and responding to it and wanting to avoid being a dupe in a denial of service attack based on forged messages. In an IKE_SA_INIT exchange, any error notification causes the exchange to fail, although some, like COOKIE, INVALID_KE_PAYLOAD or INVALID_MAJOR_VERSION may lead to a subsequent successful exchange. Note, as all error notifications are completely unauthenticated, the recipient should not immediately act based on them (unless corrective actions are known like COOKIE, INVALID_KE_PAYLOAD etc), but continue trying for some time before giving up. 2.21.2 Error Handling in IKE_AUTH All errors that occur in an IKE_AUTH exchange, causing the authentication to fail for whatever reason (invalid shared secret, invalid ID, untrusted certificate issuer, revoked or expired certificate, etc.) SHOULD result in an AUTHENTICATION_FAILED notification. If the error occurred on the responder, the notification is returned in the protected response, and is usually the only payload in that response. Note, that although the IKE_AUTH messages are encrypted and integrity protected, if the peer receiving this notification has not authenticated the other end yet, the information needs to be treated with caution. If the error occurs on the initiator, the notification MAY be returned in a separate INFORMATIONAL exchange, usually with no other payloads. This is exception for the general rule of not starting new exchanges based on errors in responses. Note, however, that request messages that contain an unsupported critical payload, or where the whole message is malformed (rather than just bad payload contents), MUST be rejected in their entirety, and only lead to an UNSUPPORTED_CRITICAL_PAYLOAD or INVALID_SYNTAX Notification sent as response. The receiver should not verify the payloads related to authentication in this case. If authentication has succeeded in the IKE_AUTH exchange, the IKE SA is established, but establishing the child SA, or requesting configuration information may still fail. This failure does not automatically cause the IKE SA to be deleted. Specifically, a responder may include all the payloads associated with authentication (IDr, Cert and AUTH) while sending error notifications for the piggybacked exchanges (FAILED_CP_REQUIRED, INVALID_SELECTORS, NO_PROPOSAL_CHOSEN, etc.), and the initiator MUST NOT fail the authentication because of this. The initiator MAY, of course, for reasons of policy later delete such an IKE SA. In an IKE_AUTH exchange, or in the INFORMATIONAL exchange immediately following it (in case error happened in when processing response to IKE_AUTH), only the following notifications cause the IKE SA to be deleted or not created, without a DELETE payload: o UNSUPPORTED_CRITICAL_PAYLOAD o INVALID_SYNTAX o AUTHENTICATION_FAILED Extension documents may define new error notifications with these semantics, but MUST NOT use them unless the peer is known to understand them. 2.21.3 Error Handling after IKE SA is Authenticated After the IKE SA is authenticated all requests having errors MUST result in response notifying about the error. In normal situation there should not be cases where valid response from other end results in error situation in the initiator, so there should not be any reason for initiator to send error messages to the other end. Because sending such error messages as INFORMATIONAL exchange might lead to further errors causing loops such errors SHOULD NOT be sent. If such errors are seen that might mean that the peers do not have same state, thus it might be good to delete the IKE SA to clean up state and start over from the beginning. Similarly if the responder parsing the request notices it is badly formatted (after it has passed the message authentication code checks and window checks) and it sends INVALID_SYNTAX notification back, then this error notification is considered fatal in both ends meaning that IKE SA is deleted without explicit delete payload. 2.21.4 Error Handling Outside IKE SA A node MUST limit the rate at which it will send messages in response to unprotected messages. If a node receives a message on UDP port 500 or 4500 outside the context of an IKE SA known to it (and not a request to start one), it may be the result of a recent crash of the node. If the message is marked as a response, the node MAY audit the suspicious event but MUST NOT respond. If the message is marked as a request, the node MAY audit the suspicious event and MAY send a response. If a response is sent, the response MUST be sent to the IP address and port from whence it came with the same IKE SPIs and the Message ID copied. The response MUST NOT be cryptographically protected and MUST contain a Notify payload indicating INVALID_IKE_SPI. The INVALID_IKE_SPI notification indicates an IKE message was received with an unrecognized destination SPI; this usually indicates that the recipient has rebooted and forgotten the existence of an IKE SA. A node receiving such an unprotected Notify payload MUST NOT respond and MUST NOT change the state of any existing SAs. The message might be a forgery or might be a response, the genuine correspondent was tricked into sending. A node should treat such a message (and also a network message like ICMP destination unreachable) as a hint that there might be problems with SAs to that IP address and should initiate a liveness check for any such IKE SA. An implementation SHOULD limit the frequency of such tests to avoid being tricked into participating in a denial of service attack. If an error occurs outside the context of an IKE request (e.g., the node is getting ESP messages on a nonexistent SPI), the node SHOULD initiate an INFORMATIONAL exchange with a Notify payload describing the problem. A node receiving a suspicious message from an IP address (and port, if NAT traversal is used) with which it has an IKE SA SHOULD send an IKE Notify payload in an IKE INFORMATIONAL exchange over that SA. The recipient MUST NOT change the state of any SAs as a result, but may wish to audit the event to aid in diagnosing malfunctions. -- kivinen@iki.fi From kivinen@iki.fi Wed Sep 16 06:59:58 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B32DB28C0F9 for ; Wed, 16 Sep 2009 06:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zd7+DpRpgbYz for ; Wed, 16 Sep 2009 06:59:57 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 5BFF328C0E4 for ; Wed, 16 Sep 2009 06:59:56 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n8GE0YUV011933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Sep 2009 17:00:34 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n8GE0Y1I015475; Wed, 16 Sep 2009 17:00:34 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19120.61314.149411.212452@fireball.kivinen.iki.fi> Date: Wed, 16 Sep 2009 17:00:34 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B618@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B618@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 30 min X-Total-Time: 34 min Cc: "ipsec@ietf.org" Subject: [IPsec] Comments on draft-ietf-ipsecme-roadmap-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 13:59:58 -0000 Yaron Sheffer writes: > - I would have liked to see ESP BEET mode referenced, since it's more widely > implemented than other docs that we do mention. But as far as I know it is > not on track to becoming an RFC. I agree on that, and I think it might also be good to mention other very widely implemented (expired) drafts which will never come out as RFCs, namely IKEv1 configuration mode (draft-dukes-ike-mode-cfg-02) and IKEv1 xauth (draft-beaulieu-ike-xauth-02). > - 4.1.1: if RFC 2409 is N/A for IPsec-v3, how come RFC 4304 defines the use > of ESN in IKEv1? But you can't expect a Roadmap document to resolve all > issues. As RFC4303 says ESP does not have version number, thus version is only known by the signaling methods or out of band configuration. Use of IKEv2 automatically implies ESP-v3. If IKEv1 is used then that would imply ESP-v2, but RFC4304 explictly defines method of negotiating ESP-v3 feature in IKEv1, thus if that feature is used, then ESP-v3 is also assumed. That is at least my interpretation of the situation... Of course everybody should stop using already obsoleted IKEv1 protocol :-) > - 7.5: I would describe the history differently (I was there...). IPSRA > attempted to tack user authentication onto IKEv1 with no change to IKE. This > indeed proved cumbersome, and the result was the brand new IKEv2, which in > fact adopted some of the IPSRA ideas, primarily the use of EAP. Agree... > - Table 1: There is nothing that limits the Heuristics draft to ipsec-v3. In > facts legacy devices are a major reason for publishing these heuristics. True, altough in IPsec-v2 things are bit easier, as there is no combined mode ciphers i.e. no GMAC, thus no need to detect IV. The draft does not limit itself to either version. BTW, the latest draft is draft-ietf-ipsecme-esp-null-heuristics-01.txt not draft-kivinen-ipsecme-esp-null-heuristics. Other comments: -- It would be much easier to read the document if each document would be easier to detect from each other. Now when moving from one document to next is indicated by even more indented bulletpoint text than the actual text it does not provide good visual feedback to search documents. It might be better to change all document headers to sections (and perhaps exclude them from toc (i.e. add toc="exclude" to them if using xml to rfc)). -- In section 5.2 covering RFC3686 document says: ... AES-CTR is a stream cipher with a 32-bit random nonce (1/SA) and a 64-bit IV, both of which are sent in the packet along with the encrypted data. The description of the random noise and 64-bit IV is correct, but only the 64-bit IV is sent along the packet. The nonce is provided by the IKE with the keying material. There is also draft-ietf-ipsecme-aes-ctr-ikev2-02 to define how that is used in IKEv2 (and as IKEv2 and ESP-v3 share same iana registry there is already number for it). -- For RFC5529 I do not think we need separate RFC to use Camellia-CBC in IKEv2. It is just normal CBC mode algorithm and the generic rules in RFC4306 covers it. As it also already has IANA number I do not see any reason why it cannot be used in IKEv2 too. For the Camellia-CTR the situation is different as generic RFC4306 text only covers CBC mode ciphers, not counter mode ciphers. Perhaps the draft-ietf-ipsecme-aes-ctr-ikev2-02 should be expanded to include more of the counter mode ciphers (i.e. provide generic rules how counter mode ciphers are used in IKEv2)? For the Camellia-CCM there is the RFC5282 which describes how combined mode ciphers are used in the IKEv2. I think that document along with RFC5529 should be enough to specify how Camellia-CCM is used in IKEv2. -- kivinen@iki.fi From paul.hoffman@vpnc.org Wed Sep 16 08:02:59 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86D2228C164 for ; Wed, 16 Sep 2009 08:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.893 X-Spam-Level: X-Spam-Status: No, score=-4.893 tagged_above=-999 required=5 tests=[AWL=1.153, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksqZ0b0wFZ55 for ; Wed, 16 Sep 2009 08:02:58 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id B9DE628C148 for ; Wed, 16 Sep 2009 08:02:58 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n8GEcIUs001440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 16 Sep 2009 07:38:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 16 Sep 2009 07:38:17 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Working Group Last Call: draft-ietf-ipsecme-aes-ctr-ikev2-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 15:02:59 -0000 Greetings again. This message starts the WG Last Call on draft-ietf-ipsecme-aes-ctr-ikev2-02.txt. Please read the draft and comment on the list whether or not you think it is ready for standardization. We are particularly interested in hearing from implementers who have carefully read the details to be sure they are implementable and seem correct. Of course, we want to hear from everyone as well. This Last Call should end around October 1. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Wed Sep 16 08:03:00 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 327DB3A6AC4 for ; Wed, 16 Sep 2009 08:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.914 X-Spam-Level: X-Spam-Status: No, score=-4.914 tagged_above=-999 required=5 tests=[AWL=1.132, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43QgEfroBY-q for ; Wed, 16 Sep 2009 08:02:59 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 18C9828C156 for ; Wed, 16 Sep 2009 08:02:59 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n8GEZWCO001246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Sep 2009 07:35:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 16 Sep 2009 07:35:02 -0700 To: shih luke , From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] GRE over IPsec....... Any help would be appreciated X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 15:03:00 -0000 This is the wrong mailing list for your request. You need to go to the vendor of the software you are using. This mailing list is for talking about the protocols themselves, not how to use a particular implementation. --Paul Hoffman, Director --VPN Consortium From mwong@huawei.com Wed Sep 16 12:27:03 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E2233A6861 for ; Wed, 16 Sep 2009 12:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpvV9ae9Vzai for ; Wed, 16 Sep 2009 12:27:02 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 9AF9E3A6827 for ; Wed, 16 Sep 2009 12:27:02 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ2005ERWQFLT@usaga04-in.huawei.com> for ipsec@ietf.org; Wed, 16 Sep 2009 14:27:52 -0500 (CDT) Received: from w73811A ([10.193.125.82]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPSA id <0KQ200LWWWQ594@usaga04-in.huawei.com> for ipsec@ietf.org; Wed, 16 Sep 2009 14:27:51 -0500 (CDT) Date: Wed, 16 Sep 2009 15:27:40 -0400 From: Marcus Wong In-reply-to: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190A978F8E7@il-ex01.ad.checkpoint.com> To: ipsec@ietf.org Message-id: <45AC445F471B40ADAD5479DE965CB910@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcozfhTRTGu62M82RpCDgCxzrIgYYQAJhZCgANboe2A= References: <002601ca1fb8$6ba9bcd0$800c6f0a@china.huawei.com> <99E2C4D8C30749A9A7B2A31CC2F434F9@china.huawei.com> <92E104320BB54EC5B8D3804FA61C8390@china.huawei.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80190A978F8E7@il-ex01.ad.checkpoint.com> Subject: Re: [IPsec] draft-wong-ipsecme-ikev2-integrity-data-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 19:27:03 -0000 Thanks for the initial feedback. I certainly agree with the view that we shouldn't duplicate the NEA protocols and I couldn't emphasize enough that the intent of the ID is purely from transport's perspective. I am grateful that you can view the ID with an open mind. Perhaps a little background could stir up people's interest. I have drafted this ID with initial 3GPP femto application in mind. In 3GPP femto case, there are some very specific security requirements that the device authentication and device integrity validation be bound together due to the fact that the femto AP will be deployed in environments that is not very well controlled by the network operators (e.g. semi-hostile environment) Part of the device integrity validation necessitates transporting NEA information to the network for validation. 3GPP working group SA3 has chosen IKEv2 as the authentication protocol with certificate-based credentials for the femto devices. The working group has also agreed in principle that the Notify payload within IKEv2 can be used for transporting the integrity information. Please see the latest draft of the 3GPP standards for additional information. The latest draft is here: ftp://ftp.3gpp.org/TSG_SA/WG3_Security/TSGS3_56_Seattle/Docs/S3-091491.zip , which is also one of the references in the ID. Please note that I'm also the editor of this 3GPP document. We have looked at what other groups have done and it looks like that with minimal extension to IKEv2 we could piggyback the NEA transport part using the Notify payload with relative simplicity and least amount of interoperability issues, especially since IKEv2 is widely used as the de facto standard protocol for authentication and key exchange. Thanks, Marcus -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer Sent: Saturday, September 12, 2009 8:29 AM To: Stephen Kent; mwong@huawei.com Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-wong-ipsecme-ikev2-integrity-data-00.txt I completely agree that we shouldn't be duplicating the NEA protocols. OTOH, I'm willing to consider transport of NEA information within IKE/IPsec if people are interested. Note that NEA has just only started to look at their own mainstream transport protocol (NEA-PT). This is very likely to end up being EAP. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Stephen Kent > Sent: Saturday, September 12, 2009 10:48 > To: mwong@huawei.com > Cc: ipsec@ietf.org > Subject: Re: [IPsec] draft-wong-ipsecme-ikev2-integrity-data-00.txt > > At 4:06 PM -0400 9/11/09, Marcus Wong wrote: > >Steve, you are mostly right, but this I-D only deals with the integrity > data > >exchange using the notify payload. Thanks. > > > >Marcus > > > > Thanks for the clarification. That still raises the question of why > we ought to duplicate this NEA functionality in IKE. Does the I-D > provide suitable motivation for that, and has the idea been passed by > the NEA WG folks? > > Steve > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From yaronf@checkpoint.com Wed Sep 16 13:29:19 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCD493A69E0 for ; Wed, 16 Sep 2009 13:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.937 X-Spam-Level: X-Spam-Status: No, score=-2.937 tagged_above=-999 required=5 tests=[AWL=0.662, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42NqhrjE8HQZ for ; Wed, 16 Sep 2009 13:29:18 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 123303A6857 for ; Wed, 16 Sep 2009 13:29:17 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n8GKTxSr011042; Wed, 16 Sep 2009 23:29:59 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 16 Sep 2009 23:29:58 +0300 From: Yaron Sheffer To: Marcus Wong , "ipsec@ietf.org" Date: Wed, 16 Sep 2009 23:29:58 +0300 Thread-Topic: [IPsec] draft-wong-ipsecme-ikev2-integrity-data-00.txt Thread-Index: AcozfhTRTGu62M82RpCDgCxzrIgYYQAJhZCgANboe2AAAuYc1Q== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD3E2149@il-ex01.ad.checkpoint.com> References: <002601ca1fb8$6ba9bcd0$800c6f0a@china.huawei.com> <99E2C4D8C30749A9A7B2A31CC2F434F9@china.huawei.com> <92E104320BB54EC5B8D3804FA61C8390@china.huawei.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80190A978F8E7@il-ex01.ad.checkpoint.com>, <45AC445F471B40ADAD5479DE965CB910@china.huawei.com> In-Reply-To: <45AC445F471B40ADAD5479DE965CB910@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] draft-wong-ipsecme-ikev2-integrity-data-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 20:29:19 -0000 Hi Marcus, reading your 3GPP document, I think you have something else in mind, not ex= actly what NEA is planning on doing. NEA posture information may be very la= rge, containing data about many components of the OS and applications. I be= lieve what you are looking for is a much more limited set of hash values, s= imilar to what you'd measure as part of TPM validation of a system. This is= a very unique reqiurement right now, probably a few years ahead of NEA (th= eir origins are with TCPA, but they're far from the Trusted Computing parad= igm now). So I am not sure there is value today in integrating your require= ments (and the related IKE-based solution) with NEA or even in standardizin= g this solution within ipsecme. You are still free to request a notification type, so there's nothing block= ing your 3GPP work from moving forward. And I am open to be convinced other= wise. Also, I suggest that you talk to the NEA chairs. And a related technical issue: IKE is not good as a transport for large pie= ces of information, because everything needs to fit into a UDP packet. Your= lightweight notification will not be a problem. But large NEA posture blob= s will be. Thanks, Yaron ________________________________________ From: ipsec-bounces@ietf.org [ipsec-bounces@ietf.org] On Behalf Of Marcus W= ong [mwong@huawei.com] Sent: Wednesday, September 16, 2009 10:27 PM To: ipsec@ietf.org Subject: Re: [IPsec] draft-wong-ipsecme-ikev2-integrity-data-00.txt Thanks for the initial feedback. I certainly agree with the view that we shouldn't duplicate the NEA protocols and I couldn't emphasize enough that the intent of the ID is purely from transport's perspective. I am grateful that you can view the ID with an open mind. Perhaps a little background could stir up people's interest. I have drafte= d this ID with initial 3GPP femto application in mind. In 3GPP femto case, there are some very specific security requirements that the device authentication and device integrity validation be bound together due to the fact that the femto AP will be deployed in environments that is not very well controlled by the network operators (e.g. semi-hostile environment) Part of the device integrity validation necessitates transporting NEA information to the network for validation. 3GPP working group SA3 has chosen IKEv2 as the authentication protocol with certificate-based credentials for the femto devices. The working group has also agreed in principle that the Notify payload within IKEv2 can be used for transporting the integrity information. Please see the latest draft of the 3GPP standards for additional information. The latest draft is here: ftp://ftp.3gpp.org/TSG_SA/WG3_Security/TSGS3_56_Seattle/Docs/S3-091491.zip = , which is also one of the references in the ID. Please note that I'm also th= e editor of this 3GPP document. We have looked at what other groups have don= e and it looks like that with minimal extension to IKEv2 we could piggyback the NEA transport part using the Notify payload with relative simplicity an= d least amount of interoperability issues, especially since IKEv2 is widely used as the de facto standard protocol for authentication and key exchange. Thanks, Marcus -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer Sent: Saturday, September 12, 2009 8:29 AM To: Stephen Kent; mwong@huawei.com Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-wong-ipsecme-ikev2-integrity-data-00.txt I completely agree that we shouldn't be duplicating the NEA protocols. OTOH= , I'm willing to consider transport of NEA information within IKE/IPsec if people are interested. Note that NEA has just only started to look at their own mainstream transport protocol (NEA-PT). This is very likely to end up being EAP. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Stephen Kent > Sent: Saturday, September 12, 2009 10:48 > To: mwong@huawei.com > Cc: ipsec@ietf.org > Subject: Re: [IPsec] draft-wong-ipsecme-ikev2-integrity-data-00.txt > > At 4:06 PM -0400 9/11/09, Marcus Wong wrote: > >Steve, you are mostly right, but this I-D only deals with the integrity > data > >exchange using the notify payload. Thanks. > > > >Marcus > > > > Thanks for the clarification. That still raises the question of why > we ought to duplicate this NEA functionality in IKE. Does the I-D > provide suitable motivation for that, and has the idea been passed by > the NEA WG folks? > > Steve > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway.= From wierbows@us.ibm.com Wed Sep 16 13:57:04 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7475E28C159 for ; Wed, 16 Sep 2009 13:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.563 X-Spam-Level: X-Spam-Status: No, score=-5.563 tagged_above=-999 required=5 tests=[AWL=1.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5HH5YlzmoSo for ; Wed, 16 Sep 2009 13:57:03 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by core3.amsl.com (Postfix) with ESMTP id 6E52528C170 for ; Wed, 16 Sep 2009 13:57:03 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n8GKv1D9029629 for ; Wed, 16 Sep 2009 16:57:01 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8GKvkQq239048 for ; Wed, 16 Sep 2009 16:57:46 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n8GKvk56010203 for ; Wed, 16 Sep 2009 16:57:46 -0400 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n8GKvkkd010192 for ; Wed, 16 Sep 2009 16:57:46 -0400 X-KeepSent: 31F0889F:DBFCBB57-85257633:00715F87; type=4; name=$KeepSent To: ipsec@ietf.org X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: David Wierbowski Date: Wed, 16 Sep 2009 16:57:44 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 09/16/2009 16:57:46 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBFCA0DFE2D9178f9e8a93df938690918c0ABBFCA0DFE2D917" Content-Disposition: inline Subject: [IPsec] HTTP_CERT_LOOKUP_SUPPORTED notify text X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 20:57:04 -0000 --0__=0ABBFCA0DFE2D9178f9e8a93df938690918c0ABBFCA0DFE2D917 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Section 3.6 of ikev2bis-04 says, "Certificate payloads SHOULD be includ= ed in an exchange if certificates are available to the sender unless the p= eer has indicated an ability to retrieve this information from elsewhere u= sing an HTTP_CERT_LOOKUP_SUPPORTED Notify payload." Section 3.7 of ikev2bis-04, says "The HTTP_CERT_LOOKUP_SUPPORTED notification MAY be included in any message that can include a CERTREQ payload and indicates that the sender is capable of looking up certific= ates based on an HTTP-based URL (and hence presumably would prefer to receiv= e certificate specifications in that format)." Section 3.10.1 of ikev2bis-04 indicates that section 3.6 should be consulted for an explanation of the HTTP_CERT_LOOKUP_SUPPORTED notification. I think section 3.10.1 should say "see section 3.7" as the text that wa= s associated with the HTTP_CERT_LOOKUP_SUPPORTED notify in RFC 4306 is no= w in Section 3.7. I also question the accuracy of the statement in Section 3.6. Section = 3.7 implies that certificate payloads should still be sent when an HTTP_CERT_LOOKUP_SUPPORTED notify is received; however, an encoding typ= e of 12 or 13 should be used if possible as the peer has indicated a prefere= nce to receive certificate specifications in that format. Dave Wierbowski= --0__=0ABBFCA0DFE2D9178f9e8a93df938690918c0ABBFCA0DFE2D917 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

      Section 3.6 of ikev2bis-04 says, "Certificate payloads SHOULD b= e included in an exchange if certificates are available to the sender u= nless the peer has indicated an ability to retrieve this information fr= om elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload."=

      Section 3.7 of ikev2bis-04, says "The HTTP_CERT_LOOKUP_SUPPORTED = notification MAY be included in any message that can include a CERTREQ = payload and indicates that the sender is capable of looking up certific= ates based on an HTTP-based URL (and hence presumably would prefer to r= eceive certificate specifications in that format)."

      Section 3.10.1 of ikev2bis-04 indicates that section 3.6 should be con= sulted for an explanation of the HTTP_CERT_LOOKUP_SUPPORTED notificatio= n.

      I think section 3.10.1 should say "see section 3.7" as the te= xt that was associated with the HTTP_CERT_LOOKUP_SUPPORTED notify in RF= C 4306 is now in Section 3.7.

      I also question the accuracy of the statement in Section 3.6. Section = 3.7 implies that certificate payloads should still be sent when an HTTP= _CERT_LOOKUP_SUPPORTED notify is received; however, an encoding type of= 12 or 13 should be used if possible as the peer has indicated a prefer= ence to receive certificate specifications in that format.

      Dave Wierbowski
      = --0__=0ABBFCA0DFE2D9178f9e8a93df938690918c0ABBFCA0DFE2D917-- From kent@bbn.com Wed Sep 16 14:25:01 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CC7328C19E for ; Wed, 16 Sep 2009 14:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3c8s9yjT3NOj for ; Wed, 16 Sep 2009 14:25:00 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id D098128C19B for ; Wed, 16 Sep 2009 14:25:00 -0700 (PDT) Received: from dhcp89-089-182.bbn.com ([128.89.89.182]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Mo14V-0001Xb-F3; Wed, 16 Sep 2009 16:25:47 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <45AC445F471B40ADAD5479DE965CB910@china.huawei.com> References: <002601ca1fb8$6ba9bcd0$800c6f0a@china.huawei.com> <99E2C4D8C30749A9A7B2A31CC2F434F9@china.huawei.com> <92E104320BB54EC5B8D3804FA61C8390@china.huawei.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80190A978F8E7@il-ex01.ad.checkpoint.com> <45AC445F471B40ADAD5479DE965CB910@china.huawei.com> Date: Wed, 16 Sep 2009 17:24:01 -0400 To: Marcus Wong From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-wong-ipsecme-ikev2-integrity-data-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 21:25:01 -0000 Marcus, Thanks for the additional background. I am not an expert on 3GPP. Do you know if there an IETF liaison to the 3GPP? If so, the right approach is to have that individual coordinate an action like this between the SDOs, i.e., when SDO-A wants SDO-B to modify/extend a protocol to accommodate a function that SDO-A wants to implement using SDO-B's protocol. Steve From wierbows@us.ibm.com Wed Sep 16 19:32:34 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B2AF3A6A1E for ; Wed, 16 Sep 2009 19:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.692 X-Spam-Level: X-Spam-Status: No, score=-5.692 tagged_above=-999 required=5 tests=[AWL=0.906, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fsT9yCrStux for ; Wed, 16 Sep 2009 19:32:33 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by core3.amsl.com (Postfix) with ESMTP id 09B4F3A6900 for ; Wed, 16 Sep 2009 19:32:32 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n8H2WVIY025143 for ; Wed, 16 Sep 2009 22:32:31 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8H2XG0S214546 for ; Wed, 16 Sep 2009 22:33:17 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n8H2XGRc031475 for ; Wed, 16 Sep 2009 22:33:16 -0400 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n8H2XGcT031469 for ; Wed, 16 Sep 2009 22:33:16 -0400 X-KeepSent: D4A5DB2F:BDD2E710-85257634:000AE8AB; type=4; name=$KeepSent To: ipsec@ietf.org X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: David Wierbowski Date: Wed, 16 Sep 2009 22:33:14 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 09/16/2009 22:33:16 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBFCA7DF996E3B8f9e8a93df938690918c0ABBFCA7DF996E3B" Content-Disposition: inline Subject: [IPsec] Populating ID_DER_ASN1_DN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 02:32:34 -0000 --0__=0ABBFCA7DF996E3B8f9e8a93df938690918c0ABBFCA7DF996E3B Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Section 3.1.5 of RFC 4945 states that when generating an ID type of ID_DER_ASN1_DN that "implementations MUST populate the contents of ID w= ith the Subject field from the end-entity certificate, and MUST do so such = that a binary comparison of the two will succeed." Section 3.1.5 is specifi= c to IKEv1. There is no such requirement listed in Section 4 which is applicable to IKEv2. What is the purpose of this requirement and why is it only applicable t= o IKEv1? I believe in the past it has been said that the requirement exists beca= use smaller devices may not be capable of performing DN matching. If that'= s the case it seems the issue would be applicable to IKEv2 as well. Section Section 3.1.5 also states, "Regarding SPD matching, implementat= ions MUST be able to perform matching based on a bitwise comparison of the entire DN in ID to its entry in the SPD. However, operational experien= ce has shown that using the entire DN in local configuration is difficult,= especially in large-scale deployments. Therefore, implementations also= MUST be able to perform SPD matches of any combination of one or more o= f the C, CN, O, OU attributes within Subject DN in the ID to the same in = the SPD." What is the purpose of requiring the ability to match on a bitwise comparison of the entire DN if it is also acceptable to match any combination of one or more of the C, CN, O, OU attributes? It seems th= at only implementing the second MUST would be sufficient. If the ID match= es a bitwise comparison of the entire DN it will also match a combination of= one or more of the C, CN, O, OU attributes. Dave Wierbowski = --0__=0ABBFCA7DF996E3B8f9e8a93df938690918c0ABBFCA7DF996E3B Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

      Section 3.1.5 of RFC 4945 states that when generating an ID type of = ID_DER_ASN1_DN that "implementations MUST populate the contents of= ID with the Subject field from the end-entity certificate, and MUST do= so such that a binary comparison of the two will succeed." Secti= on 3.1.5 is specific to IKEv1. There is no such requirement listed in = Section 4 which is applicable to IKEv2.

      What is the purpose of this requirement and why is it only applicable t= o IKEv1?

      I believe in the past it has been said that the requirement exists beca= use smaller devices may not be capable of performing DN matching. If t= hat's the case it seems the issue would be applicable to IKEv2 as well.=

      Section Section 3.1.5 also states, "Regarding SPD matching, implem= entations MUST be able to perform matching based on a bitwise comparis= on of the entire DN in ID to its entry in the SPD. However, operationa= l experience has shown that using the entire DN in local configuration = is difficult, especially in large-scale deployments. Therefore, implem= entations also MUST be able to perform SPD matches of any combination o= f one or more of the C, CN, O, OU attributes within Subject DN in the I= D to the same in the SPD."

      What is the purpose of requiring the ability to match on a bitwise com= parison of the entire DN if it is also acceptable to match any combinat= ion of one or more of the C, CN, O, OU attributes? It seems that only = implementing the second MUST would be sufficient. If the ID matches a = bitwise comparison of the entire DN it will also match a combination of= one or more of the C, CN, O, OU attributes.


      Dave Wierbowski




      = --0__=0ABBFCA7DF996E3B8f9e8a93df938690918c0ABBFCA7DF996E3B-- From rsjenwar@gmail.com Wed Sep 16 19:44:03 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30B383A689B for ; Wed, 16 Sep 2009 19:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tq0IROPY8bYr for ; Wed, 16 Sep 2009 19:44:02 -0700 (PDT) Received: from mail-px0-f173.google.com (mail-px0-f173.google.com [209.85.216.173]) by core3.amsl.com (Postfix) with ESMTP id 2CD033A6405 for ; Wed, 16 Sep 2009 19:44:02 -0700 (PDT) Received: by pxi3 with SMTP id 3so4588152pxi.31 for ; Wed, 16 Sep 2009 19:44:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=M0FBtReCIs42f5fZEsCP+LOxzFoukMGaAS8UoLKAcXM=; b=DZ9fJHFCZ//VBKX1apys5p9rL4Zz/goFXZ9pObw4eek9Km+AG3NGw1xT5t3s9V0/3v 6XPmqaNWiShTpjAQi9WruzuH1FygJx4WbXI/uoGp7lgqYRgUx6jv2qHed2FvteWEU6xd 8/VmBnp0aPiUQ2RjpiiQSPkRxQqhp2LJfDrgM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UMQcN0mMPH1WD6NBKJau1JIek6GHUOGfUNevfG3RYSXfDGEyWSJMR2BjQE6DIX3aV6 y8RHzNF13Wwy2XmzBazML2v6U+uSRkTev7mlJU94v1vBBEwF+0LdxAape2VjtybVXgqQ mHvFp3RFfR9PVAOUGIHmBhzNvycI9n8uyb4oE= MIME-Version: 1.0 Received: by 10.143.27.38 with SMTP id e38mr752729wfj.221.1253155489223; Wed, 16 Sep 2009 19:44:49 -0700 (PDT) In-Reply-To: References: Date: Thu, 17 Sep 2009 08:14:49 +0530 Message-ID: <7ccecf670909161944l2526afa5l3bdf3b68098f7d38@mail.gmail.com> From: Raj Singh To: David Wierbowski Content-Type: multipart/alternative; boundary=001636e0b66ac8956d0473bcffe8 Cc: ipsec@ietf.org Subject: Re: [IPsec] Populating ID_DER_ASN1_DN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 02:44:03 -0000 --001636e0b66ac8956d0473bcffe8 Content-Type: text/plain; charset=UTF-8 Hi David, On Thu, Sep 17, 2009 at 8:03 AM, David Wierbowski wrote: > Section 3.1.5 of RFC 4945 states that when generating an ID type of > ID_DER_ASN1_DN that "implementations MUST populate the contents of ID with > the Subject field from the end-entity certificate, and MUST do so such that > a binary comparison of the two will succeed." Section 3.1.5 is specific to > IKEv1. There is no such requirement listed in Section 4 which is applicable > to IKEv2. > > What is the purpose of this requirement and why is it only applicable to > IKEv1? > > I believe in the past it has been said that the requirement exists because > smaller devices may not be capable of performing DN matching. If that's the > case it seems the issue would be applicable to IKEv2 as well. > > Section Section 3.1.5 also states, "Regarding SPD matching, implementations > MUST be able to perform matching based on a bitwise comparison of the entire > DN in ID to its entry in the SPD. However, operational experience has shown > that using the entire DN in local configuration is difficult, especially in > large-scale deployments. Therefore, implementations also MUST be able to > perform SPD matches of any combination of one or more of the C, CN, O, OU > attributes within Subject DN in the ID to the same in the SPD." > > What is the purpose of requiring the ability to match on a bitwise > comparison of the entire DN if it is also acceptable to match any > combination of one or more of the C, CN, O, OU attributes? It seems that > only implementing the second MUST would be sufficient. If the ID matches a > bitwise comparison of the entire DN it will also match a combination of one > or more of the C, CN, O, OU attributes. > > > The entire match is required for tighter security and one certificate not being used by many users (if they have exportable private keys). Normally, CN contains info which is specific to the certificate users. If we match only O, OU that will be same for whole organization. In this case User A who has exportable private key can share it's certificate with User B and authentication will be successful. This is just one of case. > Dave Wierbowski > > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Thanks, Raj --001636e0b66ac8956d0473bcffe8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi David,

      On Thu, Sep 17, 2009 at 8:03 AM= , David Wierbowski <wierbows@us.ibm.com> wrote:

      Section 3.1.5 of RFC 4945 states that when generating an ID type of ID_D= ER_ASN1_DN that "implementations MUST populate the contents of ID with= the Subject field from the end-entity certificate, and MUST do so such tha= t a binary comparison of the two will succeed." Section 3.1.5 is spec= ific to IKEv1. There is no such requirement listed in Section 4 which is a= pplicable to IKEv2.

      What is the purpose of this requirement and why is it only applicable to IK= Ev1?

      I believe in the past it has been said that the requirement exists because = smaller devices may not be capable of performing DN matching. If that'= s the case it seems the issue would be applicable to IKEv2 as well.

      Section Section 3.1.5 also states, "Regarding SPD matching, implementa= tions MUST be able to perform matching based on a bitwise comparison of th= e entire DN in ID to its entry in the SPD. However, operational experience= has shown that using the entire DN in local configuration is difficult, es= pecially in large-scale deployments. Therefore, implementations also MUST = be able to perform SPD matches of any combination of one or more of the C, = CN, O, OU attributes within Subject DN in the ID to the same in the SPD.&qu= ot;

      What is the purpose of requiring the ability to match on a bitwise compari= son of the entire DN if it is also acceptable to match any combination of o= ne or more of the C, CN, O, OU attributes? It seems that only implementing= the second MUST would be sufficient. If the ID matches a bitwise comparis= on of the entire DN it will also match a combination of one or more of the = C, CN, O, OU attributes.


      The entire match is required for tighter se= curity and one certificate not being used by many users (if they have expor= table private keys). Normally, CN contains info which is specific to the ce= rtificate users. If we match only O, OU that will be same for whole organiz= ation. In this case User A who has exportable private key can share it'= s certificate with User B and authentication will be successful.

      This is just one of case.
      =C2=A0

      Dave Wierbowski





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


      Thanks,
      Raj
      --001636e0b66ac8956d0473bcffe8-- From ynir@checkpoint.com Wed Sep 16 23:49:27 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56C8E3A68DB for ; Wed, 16 Sep 2009 23:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.353 X-Spam-Level: X-Spam-Status: No, score=-3.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InELITkjNAy9 for ; Wed, 16 Sep 2009 23:49:26 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 1273628C0F1 for ; Wed, 16 Sep 2009 23:49:25 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n8H6oBSr029234; Thu, 17 Sep 2009 09:50:11 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 17 Sep 2009 09:50:10 +0300 From: Yoav Nir To: David Wierbowski Date: Thu, 17 Sep 2009 09:50:09 +0300 Thread-Topic: [IPsec] Populating ID_DER_ASN1_DN Thread-Index: Aco3YxmNan0q+RO3TAyO1aHWV964RQ== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Populating ID_DER_ASN1_DN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 06:49:27 -0000 On Sep 17, 2009, at 5:33 AM, David Wierbowski wrote: > Section 3.1.5 of RFC 4945 states that when generating an ID type of =20 > ID_DER_ASN1_DN that "implementations MUST populate the contents of =20 > ID with the Subject field from the end-entity certificate, and MUST =20 > do so such that a binary comparison of the two will succeed." =20 > Section 3.1.5 is specific to IKEv1. There is no such requirement =20 > listed in Section 4 which is applicable to IKEv2. > > What is the purpose of this requirement and why is it only =20 > applicable to IKEv1? > > I believe in the past it has been said that the requirement exists =20 > because smaller devices may not be capable of performing DN =20 > matching. If that's the case it seems the issue would be applicable =20 > to IKEv2 as well. > > Section Section 3.1.5 also states, "Regarding SPD matching, =20 > implementations MUST be able to perform matching based on a bitwise =20 > comparison of the entire DN in ID to its entry in the SPD. However, =20 > operational experience has shown that using the entire DN in local =20 > configuration is difficult, especially in large-scale deployments. =20 > Therefore, implementations also MUST be able to perform SPD matches =20 > of any combination of one or more of the C, CN, O, OU attributes =20 > within Subject DN in the ID to the same in the SPD." > > What is the purpose of requiring the ability to match on a bitwise =20 > comparison of the entire DN if it is also acceptable to match any =20 > combination of one or more of the C, CN, O, OU attributes? It seems =20 > that only implementing the second MUST would be sufficient. If the =20 > ID matches a bitwise comparison of the entire DN it will also match =20 > a combination of one or more of the C, CN, O, OU attributes. > > > Dave Wierbowski > > Hi Dave. The difference here is not between IKEv1 and IKEv2, but with the =20 difference between the two versions of IPsec, as in RFC 2401 vs 4301. RFC 4301 did a far better job of specifying the relationship between =20 PAD entries and the IKE IDs, so it was not necessary for RFC 4945 to =20 specify this. Section 4.4.3 discusses this thoroughly, especially this paragraph =20 from 4.4.3.2: This document does not require that the IKE ID asserted by a peer be syntactically related to a specific field in an end entity certificate that is employed to authenticate the identity of that peer. However, it often will be appropriate to impose such a requirement, e.g., when a single entry represents a set of peers =20 each of whom may have a distinct SPD entry. Thus, implementations MUST provide a means for an administrator to require a match between an asserted IKE ID and the subject name or subject alt name in a certificate. The former is applicable to IKE IDs expressed as distinguished names; the latter is appropriate for DNS names, RFC =20 822 e-mail addresses, and IP addresses. So it looks like RFC 4301 has pretty much said this already. From taddyhatty@nifty.com Thu Sep 17 01:33:05 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E03B3A6A9F; Thu, 17 Sep 2009 01:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.686 X-Spam-Level: X-Spam-Status: No, score=-0.686 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Im4HhUWgLN8i; Thu, 17 Sep 2009 01:33:04 -0700 (PDT) Received: from userg502.nifty.com (userg502.nifty.com [202.248.238.82]) by core3.amsl.com (Postfix) with ESMTP id D8A483A6A22; Thu, 17 Sep 2009 01:33:03 -0700 (PDT) Received: from GATEWAY (nttkyo397250.tkyo.nt.ftth.ppp.infoweb.ne.jp [125.2.62.250])by userg502.nifty.com with SMTP id n8H8XcFq023776; Thu, 17 Sep 2009 17:33:38 +0900 DomainKey-Signature: a=rsa-sha1; s=userg502; d=nifty.com; c=nofws; q=dns; h=message-id:reply-to:from:to:references:subject:date: organization:mime-version:content-type: content-transfer-encoding:x-priority:x-msmail-priority:x-mailer:x-mimeole; b=RGS12eRFEjqlBX8rxeCohe7T8neciElGpnO42hirfwce4+aMQFPC8sgP4hHdqWBSM 10xPhhhjPDawhIRq40QgQ== X-Nifty-SrcIP: [125.2.62.250] Message-ID: <9A72673A96B74350B46A3AC49355666D@GATEWAY> From: "Tadayuki Abraham HATTORI" To: "KATO Akihiro" , , References: <4AA9DC78.1020403@po.ntts.co.jp><9A9F31528C0442439EF6A78A1D00209F@GATEWAY> Date: Thu, 17 Sep 2009 17:33:39 +0900 Organization: TaddyHatty MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [IPsec] Call for Review on draft-kanno-ipsecme-camellia-xcbc X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Tadayuki Abraham HATTORI List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 08:33:05 -0000 > Indeed, the matter is strongly related with theoretical proof of evolution > of human intelligence. Discussion of "evolution of human intelligence" is indeed a disucussion about THE NEXT OF COPENHAGEN INTERPRETATION. // We should NOT let "WIDE" steal "ideas". :-) Indeed, it may be possible to combine Accounting with Physics. Let's consider about "cost of gravity". In modern physics, Electricity and Magnetism are strongly combined as Electromagnetism. However, Gravity and Electromagnetism have NOT been combined yet. Why couldn't people theoretically combine Gravity with Electromagnetism? Because the way of recognition of "cost" behind Gravity is different from Electricity or Magnetism. It depends upon the history of evolution of intelligence. For a humanity, the phenomenon reminding us some kind of effort can be recognized as "cost". In other words, any phenomenon reminding us energy consumption can be recognized as "cost". Usually, people don't recognize a kind of "cost" about phenomenon brought out by Gravity on Earth. In other words, cost of gravity is always considered as "zero", because any energy consumption can't be recognized. In our world wide history, Kings, Emperors, Generals and Governments had NOT been charging or taxing on gravity. If the way of recognition is different, they can't be theoretically combined. In other words, the way of recognition is same, it is possible to be theoretically combined. This could be the answer for Albert Einstein. I think. There is a kind of hypothesis by MEEEEEEEEEEEEEE, "every human being has same structure of intelligence". And more, people, dolphins and monkeys are sharing some structures of intelligence. That's why people, dolphins and monkeys could share good time/fun through gambling. Such public amusement area could be designed mathematically, I think. // We should NOT let "WIDE" steal "ideas of genious" :-) taddyhatty@acm.org > >> A definition of randomness is a definition of a humanity. > > Indeed, the matter is strongly related with theoretical proof of evolution > of human intelligence. It is evolved from "gambling" to "investment or > speculation".The matter is an ability of foreseeing. > > In order to define "randomness", let's consider the difference of > investment, > speculation and gambling. > > What is investment? > Everyone can do investment. It can be automatically done according to > some kinds of cost accounting theorem. CVP analysis are useful. > Break even point can be automatically calculated. > > What is speculation? > Speculation can be done by specific people. It will create "randomness" > in our economiy. It can be explained by a kind of mathematical theorem > of the "dirrerences of estimations of people". Speculation of human being > is the origin of "randomness". > > What is gambling? > Gambling can be done by even monkeys. > With gambling, people, dolphins and monkeys could share fun. > That's kind of my hypothesis about evolution of intelligence. > It is beneficial to plain "public gambling spaces" with people, dolphins > and monkeys. We can communicate each other through gambling. > > The "jongengine" which is a kind of lab. http://www.jongengine.net/ > The concept of GPL looks like a kind of socialism or communism, > However if they respect to "invent" not "inventory", they may be > a kind of democrats. > > This was originally planned by MEEEEEEEEEEEEE as a kind of > Volunteer, when I was an emplyee of Hewlett-Packard. At that time, > the CEO of HP was Mrs.Carly Fiorina. At that time, I recommend > local managers the fundamental concept of unconditional obeying to > "idea of genious" rather than implicit habits or culture or a kind of > religion. > > However many Japanese sales representatives and IT engineer couldn't > understand the fundamental theorem of "evolution of intelligenc. > Everybody couldn't emotionally recognize "genious" because everyone > didn't know how to define a humanity. > > After that, I resigned from HP, and joined Sony Corporation. > However, many IT engineers of sony were also. Nowadays, I resigned > from Sony Corporation too. > > Japanese IT consultants or sales representatives should be fired, I think. > They don't have "thought", so they can't promote the evolution of > civilization. > > taddyhatty@acm.org > > >> >> >> Without a proof or defitnion of "randomness", why can so many >> Japanese IT engineers proceed works? >> >> Basically, Japanese IT engineers should obey "idea of genious" rather >> than implicit habits or culture or a kind of religion. >> >> If Japanese IT engineers adopted the imported technology to the life of >> Japanese citizens directly, it could be called as a kind of criminal. >> Do you recognize that? >> >> The method to realize "randomness" is the method to generate >> unpredictable series that is difficult to be found out characteristics >> or trends. The mathematical proof have not been provided yet. >> >> A definition of randomness is a definition of a humanity. >> >> taddyhatty@acm.org >> >> >>> >>>> >>>> Hi all, >>>> >>>> I've posted new revision of draft-kanno-ipsecme-camellia-xcbc. >>>> >>>> I summarize modifications. >>>> >>>> 1. Added TVs. >>>> >>>> Comments about our document would be welcome. >>>> >>>> We plan to make this draft to next step 'Publication Request' within >>>> two >>>> weeks. >>>> >>>> Regards. >>>> ------------------ >>>> new version of I-D, draft-kanno-ipsecme-camellia-xcbc-01.txt has been >>>> successfuly submitted by Akihiro Kato and posted to the IETF >>>> repository. >>>> >>>> Filename: draft-kanno-ipsecme-camellia-xcbc >>>> Revision: 01 >>>> Title: The Camellia-XCBC-96 and Camellia-XCBC-PRF-128 Algorithms and >>>> Its >>>> Use with IPsec >>>> Creation_date: 2009-09-09 >>>> WG ID: Independent Submission >>>> Number_of_pages: 11 >>>> >>>> Abstract: >>>> This memo specifies two new algorithms. One is the usage of XCBC >>>> mode with Camellia block cipher on the authentication mechanism of >>>> the IPsec Encapsulating Security Payload and Authentication Header >>>> protocols. This algorithm is called Camellia-XCBC-96. Latter is >>>> pseudo-random function based on XCBC with Camellia block cipher for >>>> Internet Key Exchange. This algorithm is called Camellia-XCBC-PRF- >>>> 128. >>>> >>>> >>>> >>>> >>>> The IETF Secretariat. >>>> >>>> ------------------ >>>> >>>> >>>> -- >>>> - KATO Akihiro >>>> + NTT Software Corporation >>>> akato (at) po (dot) ntts (d0t) co (dot) jp move to >>>> kato (d0t) akihiro (at) po (dot) ntts (d0t) co (dot) jp >>>> at July 1,2009 >>>> >>>> >>>> _______________________________________________ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From yaronf@checkpoint.com Thu Sep 17 01:36:03 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 981343A6830 for ; Thu, 17 Sep 2009 01:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.957 X-Spam-Level: X-Spam-Status: No, score=-2.957 tagged_above=-999 required=5 tests=[AWL=0.642, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LOSc+Jxl9fu for ; Thu, 17 Sep 2009 01:36:02 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id F35253A67A2 for ; Thu, 17 Sep 2009 01:36:01 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n8H8apSr028238; Thu, 17 Sep 2009 11:36:51 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 17 Sep 2009 11:36:50 +0300 From: Yaron Sheffer To: Tadayuki Abraham HATTORI , KATO Akihiro , "ipsec@ietf.org" Date: Thu, 17 Sep 2009 11:36:49 +0300 Thread-Topic: [IPsec] Call for Review on draft-kanno-ipsecme-camellia-xcbc Thread-Index: Aco3caQNOPpAyA0nQgOEmVJSVkvbtAAABrCQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD32821D@il-ex01.ad.checkpoint.com> References: <4AA9DC78.1020403@po.ntts.co.jp><9A9F31528C0442439EF6A78A1D00209F@GATEWAY> <9A72673A96B74350B46A3AC49355666D@GATEWAY> In-Reply-To: <9A72673A96B74350B46A3AC49355666D@GATEWAY> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] Call for Review on draft-kanno-ipsecme-camellia-xcbc X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 08:36:03 -0000 Gentlemen, This is way out of scope of the IPsec mailing list. Please take this discus= sion elsewhere. Best regards, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Tadayuki Abraham HATTORI > Sent: Thursday, September 17, 2009 11:34 > To: KATO Akihiro; ipsec@ietf.org; ietf@ietf.org > Subject: Re: [IPsec] Call for Review on draft-kanno-ipsecme-camellia-xcbc >=20 > > Indeed, the matter is strongly related with theoretical proof of > evolution > > of human intelligence. >=20 > Discussion of "evolution of human intelligence" is indeed a disucussion > about > THE NEXT OF COPENHAGEN INTERPRETATION. > // We should NOT let "WIDE" steal "ideas". :-) >=20 > Indeed, it may be possible to combine Accounting with Physics. >=20 > Let's consider about "cost of gravity". >=20 > In modern physics, Electricity and Magnetism are strongly combined > as Electromagnetism. However, Gravity and Electromagnetism have > NOT been combined yet. >=20 > Why couldn't people theoretically combine Gravity with Electromagnetism? >=20 > Because the way of recognition of "cost" behind Gravity is different > from Electricity or Magnetism. It depends upon the history of evolution > of intelligence. >=20 > For a humanity, the phenomenon reminding us some kind of effort can > be recognized as "cost". In other words, any phenomenon reminding us > energy consumption can be recognized as "cost". >=20 > Usually, people don't recognize a kind of "cost" about phenomenon > brought out by Gravity on Earth. In other words, cost of gravity is alway= s > considered as "zero", because any energy consumption can't be recognized. > In our world wide history, Kings, Emperors, Generals and Governments > had NOT been charging or taxing on gravity. >=20 > If the way of recognition is different, they can't be theoretically > combined. > In other words, the way of recognition is same, it is possible to be > theoretically combined. >=20 > This could be the answer for Albert Einstein. I think. > There is a kind of hypothesis by MEEEEEEEEEEEEEE, "every human > being has same structure of intelligence". >=20 > And more, people, dolphins and monkeys are sharing some structures > of intelligence. >=20 > That's why people, dolphins and monkeys could share good time/fun > through gambling. Such public amusement area could be designed > mathematically, I think. >=20 > // We should NOT let "WIDE" steal "ideas of genious" :-) >=20 > taddyhatty@acm.org >=20 >=20 > > > >> A definition of randomness is a definition of a humanity. > > > > Indeed, the matter is strongly related with theoretical proof of > evolution > > of human intelligence. It is evolved from "gambling" to "investment or > > speculation".The matter is an ability of foreseeing. > > > > In order to define "randomness", let's consider the difference of > > investment, > > speculation and gambling. > > > > What is investment? > > Everyone can do investment. It can be automatically done according to > > some kinds of cost accounting theorem. CVP analysis are useful. > > Break even point can be automatically calculated. > > > > What is speculation? > > Speculation can be done by specific people. It will create "randomness" > > in our economiy. It can be explained by a kind of mathematical theorem > > of the "dirrerences of estimations of people". Speculation of human > being > > is the origin of "randomness". > > > > What is gambling? > > Gambling can be done by even monkeys. > > With gambling, people, dolphins and monkeys could share fun. > > That's kind of my hypothesis about evolution of intelligence. > > It is beneficial to plain "public gambling spaces" with people, dolphin= s > > and monkeys. We can communicate each other through gambling. > > > > The "jongengine" which is a kind of lab. http://www.jongengine.net/ > > The concept of GPL looks like a kind of socialism or communism, > > However if they respect to "invent" not "inventory", they may be > > a kind of democrats. > > > > This was originally planned by MEEEEEEEEEEEEE as a kind of > > Volunteer, when I was an emplyee of Hewlett-Packard. At that time, > > the CEO of HP was Mrs.Carly Fiorina. At that time, I recommend > > local managers the fundamental concept of unconditional obeying to > > "idea of genious" rather than implicit habits or culture or a kind of > > religion. > > > > However many Japanese sales representatives and IT engineer couldn't > > understand the fundamental theorem of "evolution of intelligenc. > > Everybody couldn't emotionally recognize "genious" because everyone > > didn't know how to define a humanity. > > > > After that, I resigned from HP, and joined Sony Corporation. > > However, many IT engineers of sony were also. Nowadays, I resigned > > from Sony Corporation too. > > > > Japanese IT consultants or sales representatives should be fired, I > think. > > They don't have "thought", so they can't promote the evolution of > > civilization. > > > > taddyhatty@acm.org > > > > > >> > >> > >> Without a proof or defitnion of "randomness", why can so many > >> Japanese IT engineers proceed works? > >> > >> Basically, Japanese IT engineers should obey "idea of genious" rather > >> than implicit habits or culture or a kind of religion. > >> > >> If Japanese IT engineers adopted the imported technology to the life o= f > >> Japanese citizens directly, it could be called as a kind of criminal. > >> Do you recognize that? > >> > >> The method to realize "randomness" is the method to generate > >> unpredictable series that is difficult to be found out characteristics > >> or trends. The mathematical proof have not been provided yet. > >> > >> A definition of randomness is a definition of a humanity. > >> > >> taddyhatty@acm.org > >> > >> > >>> > >>>> > >>>> Hi all, > >>>> > >>>> I've posted new revision of draft-kanno-ipsecme-camellia-xcbc. > >>>> > >>>> I summarize modifications. > >>>> > >>>> 1. Added TVs. > >>>> > >>>> Comments about our document would be welcome. > >>>> > >>>> We plan to make this draft to next step 'Publication Request' withi= n > >>>> two > >>>> weeks. > >>>> > >>>> Regards. > >>>> ------------------ > >>>> new version of I-D, draft-kanno-ipsecme-camellia-xcbc-01.txt has bee= n > >>>> successfuly submitted by Akihiro Kato and posted to the IETF > >>>> repository. > >>>> > >>>> Filename: draft-kanno-ipsecme-camellia-xcbc > >>>> Revision: 01 > >>>> Title: The Camellia-XCBC-96 and Camellia-XCBC-PRF-128 Algorithms and > >>>> Its > >>>> Use with IPsec > >>>> Creation_date: 2009-09-09 > >>>> WG ID: Independent Submission > >>>> Number_of_pages: 11 > >>>> > >>>> Abstract: > >>>> This memo specifies two new algorithms. One is the usage of XCBC > >>>> mode with Camellia block cipher on the authentication mechanism of > >>>> the IPsec Encapsulating Security Payload and Authentication Header > >>>> protocols. This algorithm is called Camellia-XCBC-96. Latter is > >>>> pseudo-random function based on XCBC with Camellia block cipher for > >>>> Internet Key Exchange. This algorithm is called Camellia-XCBC-PRF- > >>>> 128. > >>>> > >>>> > >>>> > >>>> > >>>> The IETF Secretariat. > >>>> > >>>> ------------------ > >>>> > >>>> > >>>> -- > >>>> - KATO Akihiro > >>>> + NTT Software Corporation > >>>> akato (at) po (dot) ntts (d0t) co (dot) jp move to > >>>> kato (d0t) akihiro (at) po (dot) ntts (d0t) co (dot) jp > >>>> at July 1,2009 > >>>> > >>>> > >>>> _______________________________________________ > >>>> IPsec mailing list > >>>> IPsec@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ipsec > >>> > >>> _______________________________________________ > >>> IPsec mailing list > >>> IPsec@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ipsec > >> > >> _______________________________________________ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From kivinen@iki.fi Thu Sep 17 04:23:11 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DBA23A6A89 for ; Thu, 17 Sep 2009 04:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQkQdgwEwwnw for ; Thu, 17 Sep 2009 04:23:10 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 3EA363A68B8 for ; Thu, 17 Sep 2009 04:23:09 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n8HBNuZU000352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Sep 2009 14:23:56 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n8HBNt07003474; Thu, 17 Sep 2009 14:23:55 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19122.7243.53280.198935@fireball.kivinen.iki.fi> Date: Thu, 17 Sep 2009 14:23:55 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 21 min X-Total-Time: 22 min Cc: IPsecme WG Subject: [IPsec] Working Group Last Call: draft-ietf-ipsecme-aes-ctr-ikev2-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 11:23:11 -0000 Paul Hoffman writes: > Greetings again. This message starts the WG Last Call on > draft-ietf-ipsecme-aes-ctr-ikev2-02.txt. Please read the draft and > comment on the list whether or not you think it is ready for > standardization. We are particularly interested in hearing from > implementers who have carefully read the details to be sure they are > implementable and seem correct. Of course, we want to hear from > everyone as well. When reading the roadmap I noticed that camellia-ctr is also not defined for IKEv2 SAs, so I was wondering if the text in this document could be made generic enough so any counter mode cipher could be used. There is not really anything that much different between different counter mode ciphers, they take IV, which must not be repeated for same key, I think almost all of them also take nonce which is generated when key is generated but not transmitted on the wire and they do not have padding requirements. To be able to use counter mode in IKEv2 SA the implementation needs to know the IV format, transmitted IV length and padding requirements. Usually the RFC specifying the counter mode cipher defines IV format already and also specifies the transmitted IV length, so the required information is there but as the RFC4306 talks only about CBC mode ciphers and says things like the IV is same size as block length of cipher we could not use CTR ciphers in IKEv2. Making part of the draft bit more generic so it can be used to combine any counter mode cipher document and IKEv2 document in a such way that counter mode cipher can also be used to protect IKEv2, would make things easier for the future (i.e. there is no need to create separate RFC for each counter mode cipher). Mostly the information is already there in section 3, but some text might need to talk generic case first and the add text specifically for AES_CTR. For example: Changing: ---------------------------------------------------------------------- 3.1. Initialization Vector(IV) The IV field MUST be eight octets when AES_CTR algorithm is used for encryption. The IV MUST be chosen by the encryptor in a manner that ensures that the same IV value is NOT used more than once with a given encryption key. The encryptor can generate the IV in any manner that ensures uniqueness. Common approaches to IV generation include incrementing a counter for each packet and linear feedback shift registers (LFSRs). ---------------------------------------------------------------------- to ---------------------------------------------------------------------- 3.1. Initialization Vector(IV) The IV field length used for encryption depends on the counter mode algorithm. The IV MUST be chosen by the encryptor in a manner that ensures that the same IV value is NOT used more than once with a given encryption key. The encryptor can generate the IV in any manner that ensures uniqueness. Common approaches to IV generation include incrementing a counter for each packet and linear feedback shift registers (LFSRs). For AES_CTR algorithm IV field MUST be eight octects. ---------------------------------------------------------------------- Other option is of course to include text to ikev2bis which specifies how to use counter mode ciphers when protecting IKEv2 SAs. Currently draft-ietf-ipsecme-ikev2bis-04.txt says: ... Future documents may specify the processing of Encrypted payloads for other types of transforms, such as counter mode encryption and authenticated encryption algorithms. so instead of saying that we could say that [RFC5282] specifies how to use authenticated encryption algorithms with the Encrypted Payload, and [draft-ietf-ipsecme-aes-ctr-ikev2] specifies how to use counter mode encryption algorithms with Encrypted Payload. Future documents may specify the processing of Encrypted payloads for other types of transforms. -- kivinen@iki.fi From Pasi.Eronen@nokia.com Thu Sep 17 06:04:28 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A25E73A6A00 for ; Thu, 17 Sep 2009 06:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.409 X-Spam-Level: X-Spam-Status: No, score=-6.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRp76s1QDbV4 for ; Thu, 17 Sep 2009 06:04:27 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 6F7E23A689F for ; Thu, 17 Sep 2009 06:04:27 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n8HD4q5V002126 for ; Thu, 17 Sep 2009 16:05:09 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Sep 2009 16:05:14 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Sep 2009 16:05:13 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Sep 2009 16:05:09 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Thu, 17 Sep 2009 15:05:06 +0200 From: To: Date: Thu, 17 Sep 2009 15:05:04 +0200 Thread-Topic: AD review comments for draft-ietf-ipsecme-traffic-visibility Thread-Index: Aco3l3kkjbL+0N0PT/mqG6eTSIFVVA== Message-ID: <808FD6E27AD4884E94820BC333B2DB773C06B22D72@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Sep 2009 13:05:09.0525 (UTC) FILETIME=[7C1B8C50:01CA3797] X-Nokia-AV: Clean Subject: [IPsec] AD review comments for draft-ietf-ipsecme-traffic-visibility X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 13:04:28 -0000 I've now done my AD review for draft-ietf-ipsecme-traffic-visibility-08. =20 I have two substantive comments, and a bunch of minor clarifications/nits. = =20 The substantive comments first: - A question: did the WG discuss the pros and cons of integrity protecting the WESP header? (This does make WESP more complex to implement, and currently the WESP header does not contain any data that would benefit from integrity protection in any way.) - IPv6 requires extension headers to be aligned on 8-octet boundaries, and I believe this requirement applies to ESP, too (see e.g. RFC 4303 Section 2.3, 2nd paragraph). All current ESP specs (all encryption algorithms, UDP encapsulation, etc.) meet the 8-octet alignment requirement -- but adding a new four-octet header there obviously breaks it. =20 Some minor clarifications/editorial nits: - The text currently uses "using ESP-NULL [RFC2410]" and "unencrypted" as synonyms. This was accurate before RFC4543, but is not any more. This needs some clarifying text somewhere (perhaps Section 1). - Section 1 needs a sentence or two motivating the existence of the "E" bit -- currently it comes as a surprise to the reader later. - Section 2/2.1: In Figures 1, 2, and 3, the bit numbers should be=20 shifted one character to the right. - Section 2: In some parts of the text, the last 8 bits of the WESP header are called "Flags"; in other parts, the last 5 bits are called "Flags". I'd suggest changing e.g. Figure 2 so that last 5 bits are called "Rsvd" or something. - Section 2: "The bits are defined LSB first, so bit 0 would be the least significant bit of the flags octet." This doesn't match the bit numbering in Figure 2 (where bit 0 is the most significant bit). However, the bit numbers are not really used anywhere, so I would just suggest deleting this sentence. - Section 2: It would be helpful if the text explicitly said that HdrLen values less than 12 are invalid (and probably HdrLen values that are not multiple of 4 are invalid, and multiple of 8 for IPv6 case). - Section 2: the text about TrailerLen is a bit unclearly written -- the offset from the end of the packet to the last byte of the payload would be a negative number. I'd suggest phrasing this something like the "The number of bytes following the payload data in the packet, in octets: i.e. the total length of TFC Padding (normally not present for unencrypted packets), ESP Trailer (Padding, Pad Length, Next Header), and ESP ICV." - Section 2: "the packet must be dropped" -> "the packet MUST be dropped" - The figures in 2.2.1 and 2.2.2 are very confusing, since they suggest WESP could be applied as a separate step after ESP processing (that was possible in some earlier versions of the draft, but not any more since ICV covers the WESP header). Since they don't really present much new compared to the figures in RFC 4303 Section 3.1.1/3.1.2, perhaps they could be omitted? Or if we want to keep them, they probably should show the packet before applying ESP? - Section 3: s/IPSec/IPsec/ - Section 4: this section is missing the allocation of SPI value 2=20 to indicate WESP from the "SPI Values" registry. - Section 4 should say that for the WESP Version Number, the unassigned values are 1, 2, and 3. - Section 6: [RFC4306], [RFC3948], and [RFC5226] should be normative references, not informative. Best regards, Pasi From paul.hoffman@vpnc.org Thu Sep 17 07:48:00 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A14F3A6800 for ; Thu, 17 Sep 2009 07:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.951 X-Spam-Level: X-Spam-Status: No, score=-4.951 tagged_above=-999 required=5 tests=[AWL=1.095, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnmGNjwLWRp9 for ; Thu, 17 Sep 2009 07:47:59 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 4B1353A67F2 for ; Thu, 17 Sep 2009 07:47:59 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n8HEiCOf085410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Sep 2009 07:44:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <19122.7243.53280.198935@fireball.kivinen.iki.fi> References: <19122.7243.53280.198935@fireball.kivinen.iki.fi> Date: Thu, 17 Sep 2009 07:44:11 -0700 To: Tero Kivinen From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-aes-ctr-ikev2-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 14:48:00 -0000 At 2:23 PM +0300 9/17/09, Tero Kivinen wrote: >When reading the roadmap I noticed that camellia-ctr is also not >defined for IKEv2 SAs, so I was wondering if the text in this document >could be made generic enough so any counter mode cipher could be used. It is not clear to me that future counter modes will fit today's generic definition. I don't think it is bad to require a specific definition for each application of counter mode. >Other option is of course to include text to ikev2bis which specifies >how to use counter mode ciphers when protecting IKEv2 SAs. This seems like overkill and possibly limiting to future applications of counter mode. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Thu Sep 17 09:02:29 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAEBD28C150 for ; Thu, 17 Sep 2009 09:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.969 X-Spam-Level: X-Spam-Status: No, score=-4.969 tagged_above=-999 required=5 tests=[AWL=1.077, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m93yFWdxYjHW for ; Thu, 17 Sep 2009 09:02:29 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id E5AF328C19E for ; Thu, 17 Sep 2009 09:02:28 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n8HG3A4D090014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Sep 2009 09:03:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <19120.57165.424835.989773@fireball.kivinen.iki.fi> References: <19109.286.34505.162897@fireball.kivinen.iki.fi> <73BF7996-C4FA-4442-B49D-DDD710CACA87@checkpoint.com> <19109.11583.348236.158555@fireball.kivinen.iki.fi> <19120.57165.424835.989773@fireball.kivinen.iki.fi> Date: Thu, 17 Sep 2009 09:03:08 -0700 To: Tero Kivinen , Yoav Nir From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 16:02:29 -0000 At 3:51 PM +0300 9/16/09, Tero Kivinen wrote: >For example the text could look something like this: >---------------------------------------------------------------------- Yoav, does Tero's proposed new text work for you? --Paul Hoffman, Director --VPN Consortium From wwwrun@core3.amsl.com Thu Sep 17 09:23:20 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 15EF228C29E; Thu, 17 Sep 2009 09:23:19 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090917162320.15EF228C29E@core3.amsl.com> Date: Thu, 17 Sep 2009 09:23:20 -0700 (PDT) Cc: ipsecme mailing list , ipsecme chair , Internet Architecture Board , RFC Editor Subject: [IPsec] Protocol Action: 'Redirect Mechanism for IKEv2' to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 16:23:20 -0000 The IESG has approved the following document: - 'Redirect Mechanism for IKEv2 ' as a Proposed Standard This document is the product of the IP Security Maintenance and Extensions Working Group. The IESG contact persons are Tim Polk and Pasi Eronen. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-redirect-13.txt Technical Summary This document defines a redirect mechanism for IKEv2. The main use case is scalability of large deployments of remote access VPN gateways. The proposed mechanism can also be used in Mobile IPv6, where signaling is protected by IKE/IPsec, to support the home agent in redirecting the mobile node to another home agent. Working Group Summary The document represents the consensus opinion of the ipsecme WG. Document Quality We are not aware of any implementations, and no vendors have announced implementation plans. Personnel Yaron Sheffer is the Document Shepherd for this document. Tim Polk is the Responsible Area Director. The IANA Expert for the Gateway Identity Type registry (created by this document) is Tero Kivinen. RFC Editor Note Please append the following text as a new paragraph at the end of Section 3: This document allows the client to be redirected in several protocol states. In some of them the gateway is already authenticated at the point of redirect, and in others it is not. We emphasize that the above rules regarding the identity of the new gateway and the PAD and SPD entries apply equally to all these scenarios. From yaronf@checkpoint.com Thu Sep 17 09:32:43 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 396AA3A6B75 for ; Thu, 17 Sep 2009 09:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okAkn5SoX++1 for ; Thu, 17 Sep 2009 09:32:42 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id D3ACC3A6B84 for ; Thu, 17 Sep 2009 09:32:40 -0700 (PDT) X-CheckPoint: {4AB26426-0-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 1C98029C007; Thu, 17 Sep 2009 19:33:28 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id F2DA129C002 for ; Thu, 17 Sep 2009 19:33:27 +0300 (IDT) X-CheckPoint: {4AB26422-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n8HGXRSr000396 for ; Thu, 17 Sep 2009 19:33:27 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 17 Sep 2009 19:33:26 +0300 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Thu, 17 Sep 2009 19:33:25 +0300 Thread-Topic: IPSECME Virtual Interim Meeting - agenda Thread-Index: AcomczSstU9uhrDZQveQwv78GDNZbANZl9SwAPYh4AA= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328317@il-ex01.ad.checkpoint.com> References: <20090826173221.F14CB28C4C5@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] IPSECME Virtual Interim Meeting - agenda X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 16:32:43 -0000 We are having a conference call next Tuesday, September 22, 15:00 GMT (18:0= 0 Israel, 17:00 CET, 11:00 EDT, 8:00 PDT), for 2 hours. It will have the sa= me format as the previous time: a VoIP conference bridge and posted slides.= Paul will post details separately about the TeamSpeak server. The planned agenda is as follows: 1. WG Status (Paul/Yaron) 2. Short reports (10 minutes max) on the following documents: - AES-CTR - ESP-null Heuristics - Roadmap - Resumption - WESP 3. Proposed recharter items (20 min. each): - IPsec/IKE High Availability (Yoav Nir, http://tools.ietf.org/id/draft-nir= -ipsecme-ipsecha-00.txt) 4. IKEv2-bis open issues: - #22, simultaneous IKE SA rekey - #26, error cases - #107 and possible related issues on certificate handling Draft authors, please prepare a slide or two and send them to us ahead of t= he meeting. We will post them to the wiki. Everyone, let us know if you want to add anything to the agenda, in particu= lar to the "recharter" slot. Thanks, Paul and Yaron Email secured by Check Point Email secured by Check Point From yaronf@checkpoint.com Thu Sep 17 13:27:25 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12AF13A67AB for ; Thu, 17 Sep 2009 13:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6cl-+W2m6n1 for ; Thu, 17 Sep 2009 13:27:24 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id E8CA83A67F9 for ; Thu, 17 Sep 2009 13:27:23 -0700 (PDT) X-CheckPoint: {4AB29B27-3-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 49C3629C008; Thu, 17 Sep 2009 23:28:15 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 295BB29C007 for ; Thu, 17 Sep 2009 23:28:15 +0300 (IDT) X-CheckPoint: {4AB29B27-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n8HKSESr003794 for ; Thu, 17 Sep 2009 23:28:14 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 17 Sep 2009 23:28:14 +0300 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Thu, 17 Sep 2009 23:28:12 +0300 Thread-Topic: WG last call: draft-ietf-ipsecme-esp-null-heuristics-01 Thread-Index: Aco3tm1PwjhKz10dR12UPAjGGViKfwAHoecg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328329@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] WG last call: draft-ietf-ipsecme-esp-null-heuristics-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 20:27:25 -0000 This is to begin a 2 week working group last call for draft-ietf-ipsecme-es= p-null-heuristics-01. The target status for this document is Informational. Please send your comments to the ipsec list by Oct. 1, 2009, as follow-ups = to this message. Note that this document has had very little review until now. We will only = progress it as a WG document if we have at least 3 non-editor, non-WG chair= reviewers who have read it and approve of it. And yes, this means the pseu= docode, too. There has been strong support of ESP-null detection, so this d= ocument is likely to be widely implemented. Your review will mean a lot to = the technical quality of this document. Please clearly indicate the position of any issue in the Internet Draft, an= d if possible provide alternative text. Please also indicate the nature or = severity of the error or correction, e.g. major technical, minor technical,= nit, so that we can quickly judge the extent of problems with the document= . The document can be accessed here: http://tools.ietf.org/html/draft-ietf-ipsecme-esp-null-heuristics-01 Thanks, =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Yaron Email secured by Check Point Email secured by Check Point From wierbows@us.ibm.com Thu Sep 17 13:47:32 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E46F3A6AFD for ; Thu, 17 Sep 2009 13:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.812 X-Spam-Level: X-Spam-Status: No, score=-4.812 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzijLKAByZiE for ; Thu, 17 Sep 2009 13:47:31 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by core3.amsl.com (Postfix) with ESMTP id 8AF4E3A6ACD for ; Thu, 17 Sep 2009 13:47:30 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n8HKdFX9007715 for ; Thu, 17 Sep 2009 16:39:15 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8HKm7UB237620 for ; Thu, 17 Sep 2009 16:48:07 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n8HKm7uo007110 for ; Thu, 17 Sep 2009 16:48:07 -0400 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n8HKm7Wu007103 for ; Thu, 17 Sep 2009 16:48:07 -0400 In-Reply-To: References: X-KeepSent: F4401AE1:D947E32A-85257634:006F3E20; type=4; name=$KeepSent To: "ipsec@ietf.org" X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: David Wierbowski Date: Thu, 17 Sep 2009 16:48:05 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 09/17/2009 16:48:07 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBFCA7DFFCB8B08f9e8a93df938690918c0ABBFCA7DFFCB8B0" Subject: Re: [IPsec] Populating ID_DER_ASN1_DN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 20:47:32 -0000 --0__=0ABBFCA7DFFCB8B08f9e8a93df938690918c0ABBFCA7DFFCB8B0 Content-type: multipart/alternative; Boundary="1__=0ABBFCA7DFFCB8B08f9e8a93df938690918c0ABBFCA7DFFCB8B0" --1__=0ABBFCA7DFFCB8B08f9e8a93df938690918c0ABBFCA7DFFCB8B0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Yoav (and also Raj), Thanks for the clarification. The text in 4301 makes sense. What I do= not agree with is the text in 4945 that requires implementations MUST be ab= le to perform matching based on a bitwise comparison of the entire DN in I= D to its entry in the SPD. I can agree with saying that implementations MUS= T be able to perform matching of the entire DN in ID to its entry in the SPD= . It's the "based on a bitwise comparison" that I do not agree with. It should be up to the implementation to decide if it wants to do a bitwis= e match or use normal x.500 DN matching rules. It's certainly not an interoperability issue if I decide to use x.500 = DN matching rules to do the lookup. Anything that's a binary match will b= e a match using x.500 DN matching rules. There's no security issue using x= 500 matching rules. Since we aren't doing a revision of RFC 4945 it's a moot point. If we = ever do re-spin 4945 then it's a requirement that I think could be relaxed. Dave Wierbowski z/OS Comm Server Developer Phone: Tie line: 620-4055 External: 607-429-4055 = From: Yoav Nir = = To: David Wierbowski/Endicott/IBM@IBMUS = = Cc: "ipsec@ietf.org" = = Date: 09/17/2009 02:50 AM = = Subject: Re: [IPsec] Populating ID_DER_ASN1_DN = = Sent by: ipsec-bounces@ietf.org = = On Sep 17, 2009, at 5:33 AM, David Wierbowski wrote: > Section 3.1.5 of RFC 4945 states that when generating an ID type of > ID_DER_ASN1_DN that "implementations MUST populate the contents of > ID with the Subject field from the end-entity certificate, and MUST > do so such that a binary comparison of the two will succeed." > Section 3.1.5 is specific to IKEv1. There is no such requirement > listed in Section 4 which is applicable to IKEv2. > > What is the purpose of this requirement and why is it only > applicable to IKEv1? > > I believe in the past it has been said that the requirement exists > because smaller devices may not be capable of performing DN > matching. If that's the case it seems the issue would be applicable > to IKEv2 as well. > > Section Section 3.1.5 also states, "Regarding SPD matching, > implementations MUST be able to perform matching based on a bitwise > comparison of the entire DN in ID to its entry in the SPD. However, > operational experience has shown that using the entire DN in local > configuration is difficult, especially in large-scale deployments. > Therefore, implementations also MUST be able to perform SPD matches > of any combination of one or more of the C, CN, O, OU attributes > within Subject DN in the ID to the same in the SPD." > > What is the purpose of requiring the ability to match on a bitwise > comparison of the entire DN if it is also acceptable to match any > combination of one or more of the C, CN, O, OU attributes? It seems > that only implementing the second MUST would be sufficient. If the > ID matches a bitwise comparison of the entire DN it will also match > a combination of one or more of the C, CN, O, OU attributes. > > > Dave Wierbowski > > Hi Dave. The difference here is not between IKEv1 and IKEv2, but with the difference between the two versions of IPsec, as in RFC 2401 vs 4301. RFC 4301 did a far better job of specifying the relationship between PAD entries and the IKE IDs, so it was not necessary for RFC 4945 to specify this. Section 4.4.3 discusses this thoroughly, especially this paragraph from 4.4.3.2: This document does not require that the IKE ID asserted by a peer b= e syntactically related to a specific field in an end entity certificate that is employed to authenticate the identity of that peer. However, it often will be appropriate to impose such a requirement, e.g., when a single entry represents a set of peers each of whom may have a distinct SPD entry. Thus, implementations MUST provide a means for an administrator to require a match between an asserted IKE ID and the subject name or subject alt name in a certificate. The former is applicable to IKE IDs expressed as distinguished names; the latter is appropriate for DNS names, RFC 822 e-mail addresses, and IP addresses. So it looks like RFC 4301 has pretty much said this already. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec = --1__=0ABBFCA7DFFCB8B08f9e8a93df938690918c0ABBFCA7DFFCB8B0 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

      Yoav (and also Raj),

      Thanks for the clarification. The text in 4301 makes sense. What I do= not agree with is the text in 4945 that requires implementations MUST = be able to perform matching based on a bitwise comparison of the entire= DN in ID to its entry in the SPD. I can agree with saying that implem= entations MUST be able to perform matching of the entire DN in ID to it= s entry in the SPD. It's the "based on a bitwise comparison"= that I do not agree with. It should be up to the implementation to de= cide if it wants to do a bitwise match or use normal x.500 DN matching = rules.

      It's certainly not an interoperability issue if I decide to use x.500 = DN matching rules to do the lookup. Anything that's a binary match wil= l be a match using x.500 DN matching rules. There's no security issue = using x500 matching rules.

      Since we aren't doing a revision of RFC 4945 it's a moot point. If we = ever do re-spin 4945 then it's a requirement that I think could be rela= xed.

      Dave Wierbowski


      z/OS Comm Server Developer

      Phone:
      Tie line: 620-4055
      External: 607-429-4055




      3D"InactiveYoav Nir ---09/17= /2009 02:50:34 AM---On Sep 17, 2009, at 5:33 AM, David Wierbowski wrote= : > Section 3.1.5 of RFC 4945 states that when ge

      = =
      3D=
      From:      		= 3D""
      Yoav Nir <ynir@checkpoint.com>
      3D=
      To:
      David Wierbowski/Endicott/IBM@IBMUS
      3D=
      Cc:      		3D""
      "ipsec@ietf.org" <ipsec@ietf.org>
      3D=
      Date:      		= 3D""
      09/17/2009 02:50 AM
      3D=
      Subject:      		3D""
      Re: [IPsec] Populating ID_DER_ASN1_DN
      3D=
      Sent by:      		3D""
      ipsec-bounces@ietf.org




      On Sep 17, 2009, at 5:33 AM, David Wierbowski wrote:

      > Section 3.1.5 of RFC 4945 states that when generating an ID type o= f  
      > ID_DER_ASN1_DN that "implementations MUST populate the conten= ts of  
      > ID with the Subject field from the end-entity certificate, and MUS= T  
      > do so such that a binary comparison of the two will succeed."=  
      > Section 3.1.5 is specific to IKEv1. There is no such requirement &= nbsp;
      > listed in Section 4 which is applicable to IKEv2.
      >
      > What is the purpose of this requirement and why is it only  <= br> > applicable to IKEv1?
      >
      > I believe in the past it has been said that the requirement exists=  
      > because smaller devices may not be capable of performing DN  =
      > matching. If that's the case it seems the issue would be applicabl= e  
      > to IKEv2 as well.
      >
      > Section Section 3.1.5 also states, "Regarding SPD matching, &= nbsp;
      > implementations MUST be able to perform matching based on a bitwis= e  
      > comparison of the entire DN in ID to its entry in the SPD. However= ,  
      > operational experience has shown that using the entire DN in local=  
      > configuration is difficult, especially in large-scale deployments.=  
      > Therefore, implementations also MUST be able to perform SPD matche= s  
      > of any combination of one or more of the C, CN, O, OU attributes &= nbsp;
      > within Subject DN in the ID to the same in the SPD."
      >
      > What is the purpose of requiring the ability to match on a bitwise=  
      > comparison of the entire DN if it is also acceptable to match any =  
      > combination of one or more of the C, CN, O, OU attributes? It seem= s  
      > that only implementing the second MUST would be sufficient. If the=  
      > ID matches a bitwise comparison of the entire DN it will also matc= h  
      > a combination of one or more of the C, CN, O, OU attributes.
      >
      >
      > Dave Wierbowski
      >
      >
      Hi Dave.

      The difference here is not between IKEv1 and IKEv2, but with the  =
      difference between the two versions of IPsec, as in RFC 2401 vs 4301.
      RFC 4301 did a far better job of specifying the relationship between &n= bsp;
      PAD entries and the IKE IDs, so it was not necessary for RFC 4945 to &n= bsp;
      specify this.

      Section 4.4.3 discusses this thoroughly, especially this paragraph &nbs= p;
      from 4.4.3.2:

         This document does not require that the IKE ID asserted b= y a peer be
         syntactically related to a specific field in an end entit= y
         certificate that is employed to authenticate the identity= of that
         peer.  However, it often will be appropriate to impo= se such a
         requirement, e.g., when a single entry represents a set o= f peers  
      each
         of whom may have a distinct SPD entry.  Thus, implem= entations MUST
         provide a means for an administrator to require a match b= etween an
         asserted IKE ID and the subject name or subject alt name = in a
         certificate.  The former is applicable to IKE IDs ex= pressed as
         distinguished names; the latter is appropriate for DNS na= mes, RFC  
      822
         e-mail addresses, and IP addresses.

      So it looks like RFC 4301 has pretty much said this already.


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


      = --1__=0ABBFCA7DFFCB8B08f9e8a93df938690918c0ABBFCA7DFFCB8B0-- --0__=0ABBFCA7DFFCB8B08f9e8a93df938690918c0ABBFCA7DFFCB8B0 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBFCA7DFFCB8B08f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBFCA7DFFCB8B08f9e8a93df938690918c0ABBFCA7DFFCB8B0 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <2__=0ABBFCA7DFFCB8B08f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBFCA7DFFCB8B08f9e8a93df938690918c0ABBFCA7DFFCB8B0-- From ynir@checkpoint.com Thu Sep 17 14:35:24 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 563C93A69B4 for ; Thu, 17 Sep 2009 14:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.367 X-Spam-Level: X-Spam-Status: No, score=-3.367 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+646EwvWKeI for ; Thu, 17 Sep 2009 14:35:22 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 4F1DC3A69FD for ; Thu, 17 Sep 2009 14:35:22 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n8HLaCSr021801; Fri, 18 Sep 2009 00:36:13 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 18 Sep 2009 00:36:12 +0300 From: Yoav Nir To: David Wierbowski Date: Fri, 18 Sep 2009 00:36:09 +0300 Thread-Topic: [IPsec] Populating ID_DER_ASN1_DN Thread-Index: Aco33uAy/uHxS5LFRoyoLKiAAHEvnQ== Message-ID: <66DD858D-49BD-4F8F-955D-B7964EEDB444@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_66DD858D49BD4F8F955DB7964EEDB444checkpointcom_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Populating ID_DER_ASN1_DN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 21:35:24 -0000 --_000_66DD858D49BD4F8F955DB7964EEDB444checkpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable By the time we re-spin RFC 4945, and I'm not saying that we will, it will l= ook silly specifying stuff for IKEv1, so that section will probably be omit= ted. On Sep 17, 2009, at 11:48 PM, David Wierbowski wrote: Yoav (and also Raj), Thanks for the clarification. The text in 4301 makes sense. What I do not a= gree with is the text in 4945 that requires implementations MUST be able to= perform matching based on a bitwise comparison of the entire DN in ID to i= ts entry in the SPD. I can agree with saying that implementations MUST be a= ble to perform matching of the entire DN in ID to its entry in the SPD. It'= s the "based on a bitwise comparison" that I do not agree with. It should b= e up to the implementation to decide if it wants to do a bitwise match or u= se normal x.500 DN matching rules. It's certainly not an interoperability issue if I decide to use x.500 DN ma= tching rules to do the lookup. Anything that's a binary match will be a mat= ch using x.500 DN matching rules. There's no security issue using x500 matc= hing rules. Since we aren't doing a revision of RFC 4945 it's a moot point. If we ever = do re-spin 4945 then it's a requirement that I think could be relaxed. Dave Wierbowski z/OS Comm Server Developer Phone: Tie line: 620-4055 External: 607-429-4055 Yoav Nir ---09/17/2009 02:50:34 AM---On Sep 17, 2009, at 5:33 = AM, David Wierbowski wrote: > Section 3.1.5 of RFC 4945 states that when ge From: Yoav Nir > To: David Wierbowski/Endicott/IBM@IBMUS Cc: "ipsec@ietf.org" > Date: 09/17/2009 02:50 AM Subject: Re: [IPsec] Populating ID_DER_ASN1_DN Sent by: ipsec-bounces@ietf.org ________________________________ On Sep 17, 2009, at 5:33 AM, David Wierbowski wrote: > Section 3.1.5 of RFC 4945 states that when generating an ID type of > ID_DER_ASN1_DN that "implementations MUST populate the contents of > ID with the Subject field from the end-entity certificate, and MUST > do so such that a binary comparison of the two will succeed." > Section 3.1.5 is specific to IKEv1. There is no such requirement > listed in Section 4 which is applicable to IKEv2. > > What is the purpose of this requirement and why is it only > applicable to IKEv1? > > I believe in the past it has been said that the requirement exists > because smaller devices may not be capable of performing DN > matching. If that's the case it seems the issue would be applicable > to IKEv2 as well. > > Section Section 3.1.5 also states, "Regarding SPD matching, > implementations MUST be able to perform matching based on a bitwise > comparison of the entire DN in ID to its entry in the SPD. However, > operational experience has shown that using the entire DN in local > configuration is difficult, especially in large-scale deployments. > Therefore, implementations also MUST be able to perform SPD matches > of any combination of one or more of the C, CN, O, OU attributes > within Subject DN in the ID to the same in the SPD." > > What is the purpose of requiring the ability to match on a bitwise > comparison of the entire DN if it is also acceptable to match any > combination of one or more of the C, CN, O, OU attributes? It seems > that only implementing the second MUST would be sufficient. If the > ID matches a bitwise comparison of the entire DN it will also match > a combination of one or more of the C, CN, O, OU attributes. > > > Dave Wierbowski > > Hi Dave. The difference here is not between IKEv1 and IKEv2, but with the difference between the two versions of IPsec, as in RFC 2401 vs 4301. RFC 4301 did a far better job of specifying the relationship between PAD entries and the IKE IDs, so it was not necessary for RFC 4945 to specify this. Section 4.4.3 discusses this thoroughly, especially this paragraph from 4.4.3.2: This document does not require that the IKE ID asserted by a peer be syntactically related to a specific field in an end entity certificate that is employed to authenticate the identity of that peer. However, it often will be appropriate to impose such a requirement, e.g., when a single entry represents a set of peers each of whom may have a distinct SPD entry. Thus, implementations MUST provide a means for an administrator to require a match between an asserted IKE ID and the subject name or subject alt name in a certificate. The former is applicable to IKE IDs expressed as distinguished names; the latter is appropriate for DNS names, RFC 822 e-mail addresses, and IP addresses. So it looks like RFC 4301 has pretty much said this already. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_66DD858D49BD4F8F955DB7964EEDB444checkpointcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable By the time we re-spin RFC= 4945, and I'm not saying that we will, it will look silly specifying stuff= for IKEv1, so that section will probably be omitted.

      On = Sep 17, 2009, at 11:48 PM, David Wierbowski wrote:

      Yoav (and also Raj),=

      Thanks for the clarification. The text in 4301 makes sense. What I do not= agree with is the text in 4945 that requires implementations MUST be able = to perform matching based on a bitwise comparison of the entire DN in ID to= its entry in the SPD. I can agree with saying that implementations MUST b= e able to perform matching of the entire DN in ID to its entry in the SPD. = It's the "based on a bitwise comparison" that I do not agree with. It sho= uld be up to the implementation to decide if it wants to do a bitwise match= or use normal x.500 DN matching rules.

      It's certainly not an interoperability issue if I decide to use x.500 DN m= atching rules to do the lookup. Anything that's a binary match will be a m= atch using x.500 DN matching rules. There's no security issue using x500 m= atching rules.

      Since we aren't doing a revision of RFC 4945 it's a moot point. If we ever= do re-spin 4945 then it's a requirement that I think could be relaxed.

      Dave Wierbowski


      z/OS Comm Server Developer

      Phone:
      Tie line: 620-4055
      External: 607-429-4055




      <graycol.gif>Yoav Nir ---09/17/2= 009 02:50:34 AM---On Sep 17, 2009, at 5:33 AM, David Wierbowski wrote: >= Section 3.1.5 of RFC 4945 states that when ge

      <ecblank.gif>=
      From:      		<ecblank.gif>
      Yoav Nir <ynir@c= heckpoint.com>
      <ecblank.gif>
      To:      		= <ecblank.gif>
      David Wierbowski/Endicott/IBM@IBMUS
      <ecblank.gif>
      Cc:      		<ecblank.gif>
      "ipsec@ietf.org" <= ;ipsec@ietf.org>
      <ecblank.gif>
      Date:      		<ecblank.gif>
      09/17/2009 02:50 AM
      <ecblank.gif>
      Subject:      		<= span><ecblank.gif>
      Re: [IPsec] Populating ID_DER_ASN1_DN
      <ecblank.gif>
      Sent by:      		<= span><ecblank.gif>
      ipsec-bounces@ie= tf.org




      On Sep 17, 2009, at 5:33 AM, David Wierbowski wrote:

      > Section 3.1.5 of RFC 4945 states that when generating an ID type of &n= bsp;
      > ID_DER_ASN1_DN that "implementations MUST populate the contents of &nb= sp;
      > ID with the Subject field from the end-entity certificate, and MUST &n= bsp;
      > do so such that a binary comparison of the two will succeed."   > Section 3.1.5 is specific to IKEv1. There is no such requirement  = ;
      > listed in Section 4 which is applicable to IKEv2.
      >
      > What is the purpose of this requirement and why is it only  
      > applicable to IKEv1?
      >
      > I believe in the past it has been said that the requirement exists &nb= sp;
      > because smaller devices may not be capable of performing DN  
      > matching. If that's the case it seems the issue would be applicable &n= bsp;
      > to IKEv2 as well.
      >
      > Section Section 3.1.5 also states, "Regarding SPD matching,  
      > implementations MUST be able to perform matching based on a bitwise &n= bsp;
      > comparison of the entire DN in ID to its entry in the SPD. However, &n= bsp;
      > operational experience has shown that using the entire DN in local &nb= sp;
      > configuration is difficult, especially in large-scale deployments. &nb= sp;
      > Therefore, implementations also MUST be able to perform SPD matches &n= bsp;
      > of any combination of one or more of the C, CN, O, OU attributes  = ;
      > within Subject DN in the ID to the same in the SPD."
      >
      > What is the purpose of requiring the ability to match on a bitwise &nb= sp;
      > comparison of the entire DN if it is also acceptable to match any &nbs= p;
      > combination of one or more of the C, CN, O, OU attributes? It seems &n= bsp;
      > that only implementing the second MUST would be sufficient. If the &nb= sp;
      > ID matches a bitwise comparison of the entire DN it will also match &n= bsp;
      > a combination of one or more of the C, CN, O, OU attributes.
      >
      >
      > Dave Wierbowski
      >
      >
      Hi Dave.

      The difference here is not between IKEv1 and IKEv2, but with the  
      difference between the two versions of IPsec, as in RFC 2401 vs 4301.

      RFC 4301 did a far better job of specifying the relationship between  =
      PAD entries and the IKE IDs, so it was not necessary for RFC 4945 to  =
      specify this.

      Section 4.4.3 discusses this thoroughly, especially this paragraph   from 4.4.3.2:

         This document does not require that the IKE ID asserted by a = peer be
         syntactically related to a specific field in an end entity    certificate that is employed to authenticate the identity of = that
         peer.  However, it often will be appropriate to impose s= uch a
         requirement, e.g., when a single entry represents a set of pe= ers  
      each
         of whom may have a distinct SPD entry.  Thus, implementa= tions MUST
         provide a means for an administrator to require a match betwe= en an
         asserted IKE ID and the subject name or subject alt name in a=
         certificate.  The former is applicable to IKE IDs expres= sed as
         distinguished names; the latter is appropriate for DNS names,= RFC  
      822
         e-mail addresses, and IP addresses.

      So it looks like RFC 4301 has pretty much said this already.


      _______________________________________________
      IPsec mailing list
      IPsec@ietf.org
      https://ww= w.ietf.org/mailman/listinfo/ipsec


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

      = --_000_66DD858D49BD4F8F955DB7964EEDB444checkpointcom_-- From ynir@checkpoint.com Thu Sep 17 14:47:22 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B7F33A6821 for ; Thu, 17 Sep 2009 14:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.38 X-Spam-Level: X-Spam-Status: No, score=-3.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8Pi0ELU9LXQ for ; Thu, 17 Sep 2009 14:47:20 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id D07B93A6876 for ; Thu, 17 Sep 2009 14:47:19 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n8HLmASr024523; Fri, 18 Sep 2009 00:48:11 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 18 Sep 2009 00:48:10 +0300 From: Yoav Nir To: Paul Hoffman Date: Fri, 18 Sep 2009 00:48:08 +0300 Thread-Topic: [IPsec] Issue #26: Missing treatment of error cases Thread-Index: Aco34IxSDNUmIrZKSZuRF0IWRrbdsg== Message-ID: <837766E3-5E01-4397-A5B2-9FE4A4A03045@checkpoint.com> References: <19109.286.34505.162897@fireball.kivinen.iki.fi> <73BF7996-C4FA-4442-B49D-DDD710CACA87@checkpoint.com> <19109.11583.348236.158555@fireball.kivinen.iki.fi> <19120.57165.424835.989773@fireball.kivinen.iki.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org WG" , Keith, Tero Kivinen , Welter Subject: Re: [IPsec] Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 21:47:22 -0000 On Sep 17, 2009, at 7:03 PM, Paul Hoffman wrote: > At 3:51 PM +0300 9/16/09, Tero Kivinen wrote: >> For example the text could look something like this: >> ---------------------------------------------------------------------- > > Yoav, does Tero's proposed new text work for you? > > --Paul Hoffman, Director > --VPN Consortium It works for me. However, Keith Welter has a couple of issues with it: The part about errors in IKE_AUTH exchanges (now 2.21.2) has several =20 times the phrase "usually with no other payloads" or "and is usually =20 the only payload in that response". To me this just means that we're =20 not forbidding putting other payloads in the message, but we don't see =20 why one would need it. Keith finds it unduly mysterious, and would =20 like to mention the possibility of adding a DELETE payload when the =20 error is sent in a separate INFORMATIONAL. I don't like the idea of =20 having an optional payload with no added semantics, but I do think =20 that any implementation should be able to handle this extra payload. Also, the phrase "or the INFORMATIONAL exchange immediately following =20 it" (same section) should be clarified to state that it's an =20 INFORMATIONAL exchange initiated by the original initiator to send an =20 error message about the IKE_AUTH exchange. Other than that, yes, I think you can copy & paste it into the bis. From paul.hoffman@vpnc.org Thu Sep 17 19:52:13 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68CAA3A6A33 for ; Thu, 17 Sep 2009 19:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[AWL=1.060, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fthIEdUv-81d for ; Thu, 17 Sep 2009 19:52:12 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id A61963A6A37 for ; Thu, 17 Sep 2009 19:52:12 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n8I2r4rt029174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Sep 2009 19:53:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190A978F8F9@il-ex01.ad.checkpoint.com> References: <20090826173221.F14CB28C4C5@core3.amsl.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80190A978F8F9@il-ex01.ad.checkpoint.com> Date: Thu, 17 Sep 2009 19:53:03 -0700 To: "ipsec@ietf.org" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] IPSECME Virtual Interim Meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 02:52:13 -0000 At 10:03 PM +0300 9/12/09, Yaron Sheffer wrote: > The ipsecme WG will have a virtual interim WG meeting in about a month. We > will have a conference call on Tuesday September 22, 15:00 GMT (18:00 > Israel, 17:00 CET, 11:00 EDT, 8:00 PDT), for 2 hours. We are planning on > the same format as the previous time: a VoIP conference bridge and posted > slides. Technical details are available here: > > http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/ConferenceCalls We are using the same TeamSpeak server as before, teamspeak.vpnc.org. I have turned on that server now so people can test it before the meeting. If you want to test your TeamSpeak client before the meeting, we will have a short test-run 24 hours before the meeting (that is, the same times as above, but on Monday, September 21). --Paul Hoffman, Director --VPN Consortium From kivinen@iki.fi Fri Sep 18 01:44:28 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2219D3A67D1 for ; Fri, 18 Sep 2009 01:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kbq8m8KYCTXT for ; Fri, 18 Sep 2009 01:44:27 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id C465E3A685D for ; Fri, 18 Sep 2009 01:44:26 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n8I8jFUD015589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Sep 2009 11:45:15 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n8I8jE4n015877; Fri, 18 Sep 2009 11:45:14 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19123.18586.548989.585693@fireball.kivinen.iki.fi> Date: Fri, 18 Sep 2009 11:45:14 +0300 From: Tero Kivinen To: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773C06B22D72@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB773C06B22D72@NOK-EUMSG-01.mgdnok.nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 18 min X-Total-Time: 24 min Cc: ipsec@ietf.org Subject: [IPsec] AD review comments for draft-ietf-ipsecme-traffic-visibility X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 08:44:28 -0000 Pasi.Eronen@nokia.com writes: > - A question: did the WG discuss the pros and cons of integrity > protecting the WESP header? (This does make WESP more complex to > implement, and currently the WESP header does not contain any data > that would benefit from integrity protection in any way.) Thats is actually good question, as all of the data in the WESP header is verified by comparing it to data elsewhere (either in packet (Next Header) or data associated to SA (HdrLen, TrailerLen, flags)) already I do not think if protecting WESP header adds anything. I think that if we don't add it to ICV that could simplify implementations as the ICV calculations would be exactly same as they were before, so converting ESP -> WESP would be simple, by just insertting new header and changing protocol number. > - Section 2: "The bits are defined LSB first, so bit 0 would be the > least significant bit of the flags octet." This doesn't match the bit > numbering in Figure 2 (where bit 0 is the most significant bit). > However, the bit numbers are not really used anywhere, so I would just > suggest deleting this sentence. I earlier proposed change that would add those bit numbers to the text, so bit positions would be also given in other place than in the picture. See my earlier message http://www.ietf.org/mail-archive/web/ipsec/current/msg04761.html > - Section 2: the text about TrailerLen is a bit unclearly written -- > the offset from the end of the packet to the last byte of the payload > would be a negative number. I'd suggest phrasing this something like > the "The number of bytes following the payload data in the packet, in > octets: i.e. the total length of TFC Padding (normally not present for > unencrypted packets), ESP Trailer (Padding, Pad Length, Next Header), > and ESP ICV." TFC Padding cannot be included in the TrailerLen as it can be too large to expressed in 8 bits. Actually reading the description it would indicate that the Padding, Pad Length and Next Header at the end of packet would be included in the TrailerLen, which would mean that even that might not be expressed in 8 bits in octects. I originally only assumed it includes the ICV field length, nothing else. That is the only thing needed by the intermediate device, as it can see pad length and padding from the packet and it can also skip the TFC padding in the same way recipient will do. With the current wording the TrailerLen would be different for each packet depending how many bytes of padding there is, which will mean that final recipient needs to do some extra calculations while verifying its length is correct (i.e it cannot simply compare the TrailerLen to fixed value based on the SA (12 for HMAC-SHA1 etc), but it needs to calculate Pad Length + ICV length + 2 + TFC Padding length and see that it matches the TralerLen. -- kivinen@iki.fi From kivinen@iki.fi Fri Sep 18 01:50:24 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4579F3A681C for ; Fri, 18 Sep 2009 01:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7-dCGP+zMap for ; Fri, 18 Sep 2009 01:50:23 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 1D57F3A676A for ; Fri, 18 Sep 2009 01:50:22 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n8I8pFRI020714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Sep 2009 11:51:15 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n8I8pEeg019130; Fri, 18 Sep 2009 11:51:14 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19123.18946.498413.243413@fireball.kivinen.iki.fi> Date: Fri, 18 Sep 2009 11:51:14 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <19122.7243.53280.198935@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 5 min Cc: IPsecme WG Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-aes-ctr-ikev2-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 08:50:24 -0000 Paul Hoffman writes: > At 2:23 PM +0300 9/17/09, Tero Kivinen wrote: > >When reading the roadmap I noticed that camellia-ctr is also not > >defined for IKEv2 SAs, so I was wondering if the text in this document > >could be made generic enough so any counter mode cipher could be used. > > It is not clear to me that future counter modes will fit today's > generic definition. I don't think it is bad to require a specific > definition for each application of counter mode. The generic description would say that for counter mode there is IV that length is specified by the counter mode algorithm, and whose format and generation is specified by the counter mode algorithm, and that there usually is no padding requirements for counter mode algorithms unless otherwise specified by the counter mode algorithm. There is not really anything else that needs to be done for counter mode ciphers. > >Other option is of course to include text to ikev2bis which specifies > >how to use counter mode ciphers when protecting IKEv2 SAs. > > This seems like overkill and possibly limiting to future > applications of counter mode. We already do that for CBC, and that text is the only text which does not fit the counter mode case (i.e. the text saying the IV length is same as the block length of the cipher and text about IV generation). Actually the current ikev2bis already says: "For modes other than CBC, the IV format and processing is specified in the document specifying the encryption algorithm and mode." which is already enough for counter mode ciphers. -- kivinen@iki.fi From kivinen@iki.fi Fri Sep 18 01:56:36 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70D453A6958 for ; Fri, 18 Sep 2009 01:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpFcBANW1T3u for ; Fri, 18 Sep 2009 01:56:35 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 38D153A69B7 for ; Fri, 18 Sep 2009 01:56:35 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n8I8vNWJ019342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Sep 2009 11:57:23 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n8I8vMIP017896; Fri, 18 Sep 2009 11:57:22 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19123.19314.551755.793565@fireball.kivinen.iki.fi> Date: Fri, 18 Sep 2009 11:57:22 +0300 From: Tero Kivinen To: David Wierbowski In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 4 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Populating ID_DER_ASN1_DN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 08:56:36 -0000 David Wierbowski writes: > Thanks for the clarification. The text in 4301 makes sense. What I do not > agree with is the text in 4945 that requires implementations MUST be able > to perform matching based on a bitwise comparison of the entire DN in ID to > its entry in the SPD. I can agree with saying that implementations MUST be > able to perform matching of the entire DN in ID to its entry in the SPD. > It's the "based on a bitwise comparison" that I do not agree with. It > should be up to the implementation to decide if it wants to do a bitwise > match or use normal x.500 DN matching rules. I think one of the reasons the bitwise comparison is there, that some CA products have been known to issue certificates which are invalid by normal processing rules, for example they can use characters that are not allowed for PRINTABLE STRINGS (for example Latin1 characters for names). Depending on your matching engine it might be impossible to get those matching without bitwise comparison. I agree that it being MUST is not needed, it could be MAY or SHOULD. -- kivinen@iki.fi From kivinen@iki.fi Fri Sep 18 02:02:45 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 160593A69B7 for ; Fri, 18 Sep 2009 02:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAMQaZ0CjePQ for ; Fri, 18 Sep 2009 02:02:44 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id E609B3A67B5 for ; Fri, 18 Sep 2009 02:02:43 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n8I93YDe020192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Sep 2009 12:03:34 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n8I93Y7Y021210; Fri, 18 Sep 2009 12:03:34 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19123.19686.417472.847252@fireball.kivinen.iki.fi> Date: Fri, 18 Sep 2009 12:03:34 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <20090826173221.F14CB28C4C5@core3.amsl.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80190A978F8F9@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 5 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] IPSECME Virtual Interim Meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 09:02:45 -0000 Paul Hoffman writes: > At 10:03 PM +0300 9/12/09, Yaron Sheffer wrote: > > The ipsecme WG will have a virtual interim WG meeting in about a month. We > > will have a conference call on Tuesday September 22, 15:00 GMT (18:00 > > Israel, 17:00 CET, 11:00 EDT, 8:00 PDT), for 2 hours. We are planning on > > the same format as the previous time: a VoIP conference bridge and posted > > slides. Technical details are available here: > > > > http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/ConferenceCalls > > We are using the same TeamSpeak server as before, > teamspeak.vpnc.org. I have turned on that server now so people can > test it before the meeting. If you want to test your TeamSpeak > client before the meeting, we will have a short test-run 24 hours > before the meeting (that is, the same times as above, but on Monday, > September 21). Now it is also good idea to make sure you find and enable the "+20db gain" / "Mic Boost" or similar setting of your windows sound card (Usually it is found in the Recording Control - microphone -> Advanced -> Advanced Controls for Microphone - Other Controls - Mic Boost / +20 DB gain / 1 (Yes sometimes it is just checkbox marked with "1")). If you do not have that activated your voice will be way too weak to be heard. -- kivinen@iki.fi From maaggarwal@gmail.com Fri Sep 18 08:34:42 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 377EF3A691A for ; Fri, 18 Sep 2009 08:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-ZVh45P7kE4 for ; Fri, 18 Sep 2009 08:34:41 -0700 (PDT) Received: from mail-yw0-f192.google.com (mail-yw0-f192.google.com [209.85.211.192]) by core3.amsl.com (Postfix) with ESMTP id 5C2103A68DA for ; Fri, 18 Sep 2009 08:34:41 -0700 (PDT) Received: by ywh30 with SMTP id 30so1425107ywh.31 for ; Fri, 18 Sep 2009 08:35:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=FPjNX4HlOlnmiFQ2FV7+Vzek0El7dA4gz0eCRi4ox1M=; b=Y5KrTWs4Ue0F/SIJzUXWFNSndCN6bXA5504GY6LmsaZIc1YHLXA97Ud787aK8KwMsy 9rxuaRRc/d3c5t+4J+jEDPk/jjRkAWC6HjjFu+c/ExfOh/1AjJAImAzRRTrsfk4F0Es8 xmMEW9qqVV7eq/WGz34X35LQuHclMYhP2bVnM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=gr48OHE0p9XGT6pl/Oi0CWVUy8SPg8xGYl2ybzCqrYhryM6dPYIAdD778HYl+yKju1 pAE0twqLOn6wzolPSglObDohTG+BJN83HiiTKdvAgs9Zlj2SHFSV2Y8lLLoxT4dx7o34 wBznsi8KakejA4tDSSqIO8n21oOlp9J+Pbzpg= MIME-Version: 1.0 Received: by 10.150.55.31 with SMTP id d31mr3566829yba.147.1253288133006; Fri, 18 Sep 2009 08:35:33 -0700 (PDT) Date: Fri, 18 Sep 2009 10:35:32 -0500 Message-ID: <329767350909180835q3b6c3690g40f2e77702e992e8@mail.gmail.com> From: Manish Aggarwal To: "ipsec@ietf.org" Content-Type: multipart/alternative; boundary=000e0cd72266f8149c0473dbe171 Subject: [IPsec] Query about SEq Number X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 15:34:42 -0000 --000e0cd72266f8149c0473dbe171 Content-Type: text/plain; charset=ISO-8859-1 HI, I have a query about the Sequence number in the ESP Header. If for any packet, the receiver finds the seq number as ZERO, what is the desired behavior..? Should this result in the anti-replay check failure..? Should this be treated as a corrupted packet..? Appreciate your inputs. Thanks Manish --000e0cd72266f8149c0473dbe171 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable HI,

      I have a query about the Sequence number in the ESP = Header.
      If for any packet, the receiver finds the seq number as Z= ERO, what is the desired behavior..?

      Should this r= esult in the anti-replay check failure..?
      Should this be treated as a corrupted packet..?

      Ap= preciate your inputs.


      Thanks
      <= div>Manish
      --000e0cd72266f8149c0473dbe171-- From danmcd@sun.com Fri Sep 18 09:02:26 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EBFA3A696C for ; Fri, 18 Sep 2009 09:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaLXhfUOwcrA for ; Fri, 18 Sep 2009 09:02:25 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 503EC3A6937 for ; Fri, 18 Sep 2009 09:02:25 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8IG3Jrd023023 for ; Fri, 18 Sep 2009 16:03:19 GMT Received: from kebe.East.Sun.COM (kebe.East.Sun.COM [129.148.174.48]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n8IG3JZR049567 for ; Fri, 18 Sep 2009 12:03:19 -0400 (EDT) Received: from kebe.East.Sun.COM (localhost [127.0.0.1]) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n8IFlwIj008026; Fri, 18 Sep 2009 11:47:58 -0400 (EDT) Received: (from danmcd@localhost) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n8IFlwNp008025; Fri, 18 Sep 2009 11:47:58 -0400 (EDT) X-Authentication-Warning: kebe.East.Sun.COM: danmcd set sender to danmcd@sun.com using -f Date: Fri, 18 Sep 2009 11:47:58 -0400 From: Dan McDonald To: Manish Aggarwal Message-ID: <20090918154758.GK7579@kebe.East.Sun.COM> References: <329767350909180835q3b6c3690g40f2e77702e992e8@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <329767350909180835q3b6c3690g40f2e77702e992e8@mail.gmail.com> Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Query about SEq Number X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 16:02:26 -0000 On Fri, Sep 18, 2009 at 10:35:32AM -0500, Manish Aggarwal wrote: > HI, > I have a query about the Sequence number in the ESP Header. > If for any packet, the receiver finds the seq number as ZERO, what is the > desired behavior..? > > Should this result in the anti-replay check failure..? > Should this be treated as a corrupted packet..? Solaris/OpenSolaris treats 0-on-the-wire as an anti-replay failure. Here's the code that does early-replay-checking (i.e. replay checking so obvious you don't need to crunch the authentication algorithm): http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/inet/ip/sadb.c#6156 And here's ESP calling, and bumping the appropriate bean-counters for "early-replay drop": http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/inet/ip/ipsecesp.c#1239 Hmmm, the comment here is quite old. We *do* check for collisions in early-replay, and have since AH/ESP support arrived in Solaris. Must've been a leftover from bringup... Hope this helps, Dan From sfluhrer@cisco.com Fri Sep 18 09:33:35 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A4BE3A67E4 for ; Fri, 18 Sep 2009 09:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTnNblm7qrAl for ; Fri, 18 Sep 2009 09:33:34 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 410D73A6873 for ; Fri, 18 Sep 2009 09:33:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKdTs0qrR7PE/2dsb2JhbAC3AIhQAZAbBYQc X-IronPort-AV: E=Sophos;i="4.44,410,1249257600"; d="scan'208";a="95274842" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 18 Sep 2009 16:34:28 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n8IGYSkG031526; Fri, 18 Sep 2009 09:34:28 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n8IGYSGK025438; Fri, 18 Sep 2009 16:34:28 GMT Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Sep 2009 09:34:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Sep 2009 09:34:26 -0700 Message-ID: In-Reply-To: <20090918154758.GK7579@kebe.East.Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Query about SEq Number Thread-Index: Aco4eY15OyQjgj5mR92WSpfXhRJ7gQABB2Hw X-Priority: 5 Priority: Non-Urgent Importance: low References: <329767350909180835q3b6c3690g40f2e77702e992e8@mail.gmail.com> <20090918154758.GK7579@kebe.East.Sun.COM> From: "Scott Fluhrer (sfluhrer)" To: "Dan McDonald" , "Manish Aggarwal" X-OriginalArrivalTime: 18 Sep 2009 16:34:28.0441 (UTC) FILETIME=[E437CC90:01CA387D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1767; t=1253291668; x=1254155668; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sfluhrer@cisco.com; z=From:=20=22Scott=20Fluhrer=20(sfluhrer)=22=20 |Subject:=20RE=3A=20[IPsec]=20Query=20about=20SEq=20Number |Sender:=20; bh=08b4jcD8uWf8r8wgN4Acge60iBMtMbVtkosUDYiAgqw=; b=oUJ8XIST7K1BX5QBHpBAhORhHP86jGZiAe6WvX78PSa5f2dufoLDXUa9X6 0U4tFYNq7TEAgoLqSKucpBDHouyrup56rcCOzJx6xmieEGNoet/c2fq19y2K p0Lw6fg3Xl; Authentication-Results: sj-dkim-4; header.From=sfluhrer@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: ipsec@ietf.org Subject: Re: [IPsec] Query about SEq Number X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 16:33:35 -0000 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Dan McDonald > Sent: Friday, September 18, 2009 11:48 AM > To: Manish Aggarwal > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Query about SEq Number >=20 > On Fri, Sep 18, 2009 at 10:35:32AM -0500, Manish Aggarwal wrote: > > HI, > > I have a query about the Sequence number in the ESP Header. > > If for any packet, the receiver finds the seq number as ZERO, what is > the > > desired behavior..? > > > > Should this result in the anti-replay check failure..? > > Should this be treated as a corrupted packet..? >=20 > Solaris/OpenSolaris treats 0-on-the-wire as an anti-replay failure. That would be appropriate if: - You have antireplay checking enabled - You are not doing Extended Sequence Numbers. In both of those cases, you can legitimately have a zero sequence number in the ESP header. > Here's > the code that does early-replay-checking (i.e. replay checking so > obvious you > don't need to crunch the authentication algorithm): >=20 > http://src.opensolaris.org/source/xref/onnv/onnv- > gate/usr/src/uts/common/inet/ip/sadb.c#6156 >=20 > And here's ESP calling, and bumping the appropriate bean-counters for > "early-replay drop": >=20 > http://src.opensolaris.org/source/xref/onnv/onnv- > gate/usr/src/uts/common/inet/ip/ipsecesp.c#1239 >=20 > Hmmm, the comment here is quite old. We *do* check for collisions in > early-replay, and have since AH/ESP support arrived in Solaris. > Must've been > a leftover from bringup... >=20 > Hope this helps, > Dan > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From danmcd@sun.com Fri Sep 18 10:06:37 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1997A3A67AA for ; Fri, 18 Sep 2009 10:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRvipKBRdXW5 for ; Fri, 18 Sep 2009 10:06:36 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 545D33A6452 for ; Fri, 18 Sep 2009 10:06:36 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8IH7UIA013638 for ; Fri, 18 Sep 2009 17:07:30 GMT Received: from kebe.East.Sun.COM (kebe.East.Sun.COM [129.148.174.48]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n8IH7UiD018093 for ; Fri, 18 Sep 2009 13:07:30 -0400 (EDT) Received: from kebe.East.Sun.COM (localhost [127.0.0.1]) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n8IGiecq008158; Fri, 18 Sep 2009 12:44:40 -0400 (EDT) Received: (from danmcd@localhost) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n8IGiet5008157; Fri, 18 Sep 2009 12:44:40 -0400 (EDT) X-Authentication-Warning: kebe.East.Sun.COM: danmcd set sender to danmcd@sun.com using -f Date: Fri, 18 Sep 2009 12:44:40 -0400 From: Dan McDonald To: "Scott Fluhrer (sfluhrer)" Message-ID: <20090918164440.GM7579@kebe.East.Sun.COM> References: <329767350909180835q3b6c3690g40f2e77702e992e8@mail.gmail.com> <20090918154758.GK7579@kebe.East.Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.19 (2009-01-05) Cc: ipsec@ietf.org, Manish Aggarwal , Dan McDonald Subject: Re: [IPsec] Query about SEq Number X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 17:06:37 -0000 On Fri, Sep 18, 2009 at 09:34:26AM -0700, Scott Fluhrer (sfluhrer) wrote: > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > > Of Dan McDonald > > Sent: Friday, September 18, 2009 11:48 AM > > To: Manish Aggarwal > > Cc: ipsec@ietf.org > > Subject: Re: [IPsec] Query about SEq Number > > > > On Fri, Sep 18, 2009 at 10:35:32AM -0500, Manish Aggarwal wrote: > > > HI, > > > I have a query about the Sequence number in the ESP Header. > > > If for any packet, the receiver finds the seq number as ZERO, what > is > > the > > > desired behavior..? > > > > > > Should this result in the anti-replay check failure..? > > > Should this be treated as a corrupted packet..? > > > > Solaris/OpenSolaris treats 0-on-the-wire as an anti-replay failure. > > That would be appropriate if: > - You have antireplay checking enabled If you look at the early-replay code, we do just this. > - You are not doing Extended Sequence Numbers. > > In both of those cases, you can legitimately have a zero sequence number > in the ESP header. We don't support 64-bit sequence numbers yet, but when we do, obviously any early-replay checks would have to be more careful about a 0 on the wire. Thanks for the helpful reminders, Dan From ken.grewal@intel.com Fri Sep 18 16:06:25 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2292B3A67EE for ; Fri, 18 Sep 2009 16:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duqu6+XHnRPv for ; Fri, 18 Sep 2009 16:06:24 -0700 (PDT) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by core3.amsl.com (Postfix) with ESMTP id 44FD53A677E for ; Fri, 18 Sep 2009 16:06:23 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 18 Sep 2009 16:02:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.44,412,1249282800"; d="scan'208";a="728268162" Received: from rrsmsx603.amr.corp.intel.com ([10.31.0.57]) by fmsmga001.fm.intel.com with ESMTP; 18 Sep 2009 16:10:17 -0700 Received: from rrsmsx601.amr.corp.intel.com (10.31.0.151) by rrsmsx603.amr.corp.intel.com (10.31.0.57) with Microsoft SMTP Server (TLS) id 8.1.358.0; Fri, 18 Sep 2009 17:07:18 -0600 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Fri, 18 Sep 2009 17:07:17 -0600 From: "Grewal, Ken" To: "Pasi.Eronen@nokia.com" , "ipsec@ietf.org" Date: Fri, 18 Sep 2009 17:06:17 -0600 Thread-Topic: AD review comments for draft-ietf-ipsecme-traffic-visibility Thread-Index: Aco3l3kkjbL+0N0PT/mqG6eTSIFVVABGuivQ Message-ID: References: <808FD6E27AD4884E94820BC333B2DB773C06B22D72@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773C06B22D72@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] AD review comments for draft-ietf-ipsecme-traffic-visibility X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 23:06:25 -0000 Hi Pasi,=20 Many thanks for the great feedback. I will incorporate all these items as p= art of the WESP update during the next virtual interim meeting on Sept 22. = Furthermore, I have opened multiple tickets to ensure these are tracked and= resolved.=20 Some comments inline...and others will result from the discussion during th= e interim meeting. Thanks,=20 - Ken =20 >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >Of Pasi.Eronen@nokia.com >Sent: Thursday, September 17, 2009 6:05 AM >To: ipsec@ietf.org >Subject: [IPsec] AD review comments for draft-ietf-ipsecme-traffic- >visibility > >I've now done my AD review for draft-ietf-ipsecme-traffic-visibility-08. >I have two substantive comments, and a bunch of minor >clarifications/nits. >The substantive comments first: > >- A question: did the WG discuss the pros and cons of integrity >protecting the WESP header? (This does make WESP more complex to >implement, and currently the WESP header does not contain any data >that would benefit from integrity protection in any way.) [Ken] This change was the result of a discussion on threats posed by 'malwa= re', which could modify the WESP headers to obfuscate the payload from insp= ection by intermediate nodes such as IDS/IPS systems.=20 The issue (ticket #104) was raised and closed some time back after lengthy = discussions on the topic.=20 http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/104 > >- IPv6 requires extension headers to be aligned on 8-octet boundaries, >and I believe this requirement applies to ESP, too (see e.g. RFC 4303 >Section 2.3, 2nd paragraph). All current ESP specs (all encryption >algorithms, UDP encapsulation, etc.) meet the 8-octet alignment >requirement -- but adding a new four-octet header there obviously >breaks it. [Ken] Great point! Yes, this will need to be addressed and we do need to pr= ovide an extension of the header for alignment purposes in IPv6 usages.=20 I have opened a new ticket (#109) to track this.=20 > >Some minor clarifications/editorial nits: > >- The text currently uses "using ESP-NULL [RFC2410]" and "unencrypted" >as synonyms. This was accurate before RFC4543, but is not any more. >This needs some clarifying text somewhere (perhaps Section 1). > >- Section 1 needs a sentence or two motivating the existence of the >"E" bit -- currently it comes as a surprise to the reader later. [Ken] I have reopened the related ticket #84 and we will generate / vet add= itional text to elaborate on the motivation. [Ken] I have captured the items below in a single new ticket (#110) as most= are minor editorial changes.=20 > >- Section 2/2.1: In Figures 1, 2, and 3, the bit numbers should be >shifted one character to the right. > [Ken] OK >- Section 2: In some parts of the text, the last 8 bits of the WESP >header are called "Flags"; in other parts, the last 5 bits are called >"Flags". I'd suggest changing e.g. Figure 2 so that last 5 bits are >called "Rsvd" or something. [Ken] Agreed, using Rsvd is better than Flags.=20 > >- Section 2: "The bits are defined LSB first, so bit 0 would be the >least significant bit of the flags octet." This doesn't match the bit >numbering in Figure 2 (where bit 0 is the most significant bit). >However, the bit numbers are not really used anywhere, so I would just >suggest deleting this sentence. > [Ken] Agree. We already have new text in the next rev of the draft using MS= B, as Tero had separately raised this point.=20 >- Section 2: It would be helpful if the text explicitly said that >HdrLen values less than 12 are invalid (and probably HdrLen values >that are not multiple of 4 are invalid, and multiple of 8 for IPv6 >case). > [Ken] OK.=20 >- Section 2: the text about TrailerLen is a bit unclearly written -- >the offset from the end of the packet to the last byte of the payload >would be a negative number. I'd suggest phrasing this something like >the "The number of bytes following the payload data in the packet, in >octets: i.e. the total length of TFC Padding (normally not present for >unencrypted packets), ESP Trailer (Padding, Pad Length, Next Header), >and ESP ICV." > [Ken] Will discuss the scope of this, based on separate comment from Tero.= =20 >- Section 2: "the packet must be dropped" -> "the packet MUST be >dropped" > >- The figures in 2.2.1 and 2.2.2 are very confusing, since they >suggest WESP could be applied as a separate step after ESP processing >(that was possible in some earlier versions of the draft, but not any >more since ICV covers the WESP header). Since they don't really >present much new compared to the figures in RFC 4303 Section >3.1.1/3.1.2, perhaps they could be omitted? Or if we want to keep >them, they probably should show the packet before applying ESP? [Ken] Someone (do not recall who) had asked for these figures. But, I agree= that it is misleading. So, propose we either remove these figures or chang= e the 'before' diagrams to raw, instead of ESP. > >- Section 3: s/IPSec/IPsec/ > >- Section 4: this section is missing the allocation of SPI value 2 >to indicate WESP from the "SPI Values" registry. > >- Section 4 should say that for the WESP Version Number, the >unassigned values are 1, 2, and 3. > >- Section 6: [RFC4306], [RFC3948], and [RFC5226] should be normative >references, not informative. [Ken] OK. > >Best regards, >Pasi >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec From paul.hoffman@vpnc.org Sat Sep 19 15:47:51 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 866C63A69EA for ; Sat, 19 Sep 2009 15:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.035 X-Spam-Level: X-Spam-Status: No, score=-5.035 tagged_above=-999 required=5 tests=[AWL=1.011, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgEBSazsmOYk for ; Sat, 19 Sep 2009 15:47:50 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id B4BB43A699F for ; Sat, 19 Sep 2009 15:47:50 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n8JMdk3G081576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 19 Sep 2009 15:39:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Sat, 19 Sep 2009 15:39:44 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Resolution of the current set of open issues X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2009 22:47:51 -0000 #22 - Add section on simultaneous IKE SA rekey There was no discussion. We will bring this up one more time because it is important, but if there is not more interest and more inclination to review Tero's text, we will write a short note in the document that simultaneous IKE SA rekey is an issue but nothing else. #26 - Missing treatment of error cases Will use Tero's last wording as a proposed way forward. There is an open issue about what other payloads might or might not be in the error responses, so we will leave the issue open for discussion after the draft with the new wording is posted. I also copy editied the section, so it needs to be reviewed. #28 - Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP Added Tero's text as section 2.23.1. Changed one MUST to a MAY based on the discussion with Scott. Note that I removed any mention of RFC 3947, which is not part of IKEv2. I also heavily copy edited the section, so it needs to be reviewed. #79 - Remove CP from Create_Child_SA? There was no agreement on this. We should probably close out the issue unless those interested can agree on the semantics. #107 - Sending certificate chains in IKEv2 Fixed in -05. Added "Note that with this encoding, if a chain of certificates needs to be sent, multiple CERT payloads are used, only the first of which holds the public key used to validate the sender's AUTH payload." --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Sat Sep 19 15:47:52 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B58D3A699F for ; Sat, 19 Sep 2009 15:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.05 X-Spam-Level: X-Spam-Status: No, score=-5.05 tagged_above=-999 required=5 tests=[AWL=0.996, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OropiV8oieFt for ; Sat, 19 Sep 2009 15:47:51 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id ECF6C3A6993 for ; Sat, 19 Sep 2009 15:47:50 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n8JMdk3C081576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Sep 2009 15:39:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <19109.286.34505.162897@fireball.kivinen.iki.fi> <73BF7996-C4FA-4442-B49D-DDD710CACA87@checkpoint.com> <19109.11583.348236.158555@fireball.kivinen.iki.fi> <19120.57165.424835.989773@fireball.kivinen.iki.fi> Date: Sat, 19 Sep 2009 15:37:33 -0700 To: Tero Kivinen , Yoav Nir From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2009 22:47:52 -0000 Here is the edited text. Please make sure it still is correct.
      There are many kinds of errors that can occur during IKE processing. The general rule is that if a request is received that is badly formatted, or unacceptable for reasons of policy (such as no matching cryptographic algorithms), the response contains a Notify payload indicating the error. The decision whether or not to send such a response depends whether or not there is an authenticated IKE SA. If there is an error parsing or processing a response packet, the general rule is to not send bac any error message because responses should not generate new requests (and a new request would be the only way to send back an error message). Such errors in parsing or processing response packets should still cause the recipient to clean up the IKE state (for example, by sending a DELETE for a bad SA). Only authentication failures (AUTHENTICATION_FAILED) and malformed messages (INVALID_SYNTAX) lead to a deletion of the IKE SA without requiring an explicit INFORMATIONAL exchange carrying a DELETE payload. Other error conditions MAY require such an exchange if policy dictates that this is needed.
      Errors that occur before a cryptographically protected IKE SA is established need to be handled very carefully. There is a trade-off between wanting to help the peer to diagnose a problem and thust responding to the error, and wanting to avoid being part a denial of service attack based on forged messages. In an IKE_SA_INIT exchange, any error notification causes the exchange to fail. Note that some error notifications such as COOKIE, INVALID_KE_PAYLOAD or INVALID_MAJOR_VERSION may lead to a subsequent successful exchange. Because all error notifications are completely unauthenticated, the recipient should continue trying for some time before giving up but not immediately act based on the error notification unless corrective actions are defined in this specification, such as for COOKIE, INVALID_KE_PAYLOAD, and INVALID_MAJOR_VERSION.
      All errors that occur in an IKE_AUTH exchange, causing the authentication to fail for whatever reason (invalid shared secret, invalid ID, untrusted certificate issuer, revoked or expired certificate, etc.) SHOULD result in an AUTHENTICATION_FAILED notification. If the error occurred on the responder, the notification is returned in the protected response, and is usually the only payload in that response. Although the IKE_AUTH messages are encrypted and integrity protected, if the peer receiving this notification has not authenticated the other end yet, that peer needs to treat the information with caution. If the error occurs on the initiator, the notification MAY be returned in a separate INFORMATIONAL exchange, usually with no other payloads. This is exception for the general rule of not starting new exchanges based on errors in responses. Note, however, that request messages that contain an unsupported critical payload, or where the whole message is malformed (rather than just bad payload contents), MUST be rejected in their entirety, and MUST only lead to an UNSUPPORTED_CRITICAL_PAYLOAD or INVALID_SYNTAX Notification sent as response. The receiver should not verify the payloads related to authentication in this case. If authentication has succeeded in the IKE_AUTH exchange, the IKE SA is established; however, establishing the Child SA or requesting configuration information may still fail. This failure does not automatically cause the IKE SA to be deleted. Specifically, a responder may include all the payloads associated with authentication (IDr, Cert and AUTH) while sending error notifications for the piggybacked exchanges (FAILED_CP_REQUIRED, INVALID_SELECTORS, NO_PROPOSAL_CHOSEN, and so on), and the initiator MUST NOT fail the authentication because of this. The initiator MAY, of course, for reasons of policy later delete such an IKE SA. In an IKE_AUTH exchange, or in the INFORMATIONAL exchange immediately following it (in case an error happened in when processing response to IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and AUTHENTICATION_FAILED notifications are the only ones to cause the IKE SA to be deleted or not created, without a DELETE payload. Extension documents may define new error notifications with these semantics, but MUST NOT use them unless the peer has been shown to understand them. NOTE FOR WG DISCUSSION: Having other payloads in the message is allowed but there are none suggested. One WG member mentioned the possibility of adding a DELETE payload when the error is sent in a separate INFORMATIONAL exchange. Do we want to allow such additional payloads that have operational semantics?
      After the IKE SA is authenticated all requests having errors MUST result in response notifying about the error. In normal situations, there should not be cases where valid response from one peer results in an error situation in the other peer, so there should not be any reason for a peer to send error messages to the other end except as a response. Because sending such error messages as INFORMATIONAL exchange might lead to further errors that could cause loops, such errors SHOULD NOT be sent. If errors are seen that indicate that the peers do not have same state, it might be good to delete the IKE SA to clean up state and start over. If a peer parsing a request notices that it is badly formatted (after it has passed the message authentication code checks and window checks) and it returns an INVALID_SYNTAX notification, then this error notification is considered fatal in both peers, meaning that the IKE SA is deleted without needing an explicit DELETE payload.
      A node needs to limit the rate at which it will send messages in response to unprotected messages. If a node receives a message on UDP port 500 or 4500 outside the context of an IKE SA known to it (and the message is not a request to start an IKE SA), this may be the result of a recent crash of the node. If the message is marked as a response, the node can audit the suspicious event but MUST NOT respond. If the message is marked as a request, the node can audit the suspicious event and MAY send a response. If a response is sent, the response MUST be sent to the IP address and port from where it came with the same IKE SPIs and the Message ID copied. The response MUST NOT be cryptographically protected and MUST contain an INVALID_IKE_SPI Notify payload. The INVALID_IKE_SPI notification indicates an IKE message was received with an unrecognized destination SPI; this usually indicates that the recipient has rebooted and forgotten the existence of an IKE SA. A peer receiving such an unprotected Notify payload MUST NOT respond and MUST NOT change the state of any existing SAs. The message might be a forgery or might be a response that a genuine correspondent was tricked into sending. A node should treat such a message (and also a network message like ICMP destination unreachable) as a hint that there might be problems with SAs to that IP address and should initiate a liveness check for any such IKE SA. An implementation SHOULD limit the frequency of such tests to avoid being tricked into participating in a denial of service attack. If an error occurs outside the context of an IKE request (e.g., the node is getting ESP messages on a nonexistent SPI), the node SHOULD initiate an INFORMATIONAL exchange with a Notify payload describing the problem. A node receiving a suspicious message from an IP address (and port, if NAT traversal is used) with which it has an IKE SA SHOULD send an IKE Notify payload in an IKE INFORMATIONAL exchange over that SA. The recipient MUST NOT change the state of any SAs as a result, but may wish to audit the event to aid in diagnosing malfunctions.
      --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Sat Sep 19 15:47:52 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D24D43A6A0D for ; Sat, 19 Sep 2009 15:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.065 X-Spam-Level: X-Spam-Status: No, score=-5.065 tagged_above=-999 required=5 tests=[AWL=0.981, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukJQLo-hc16B for ; Sat, 19 Sep 2009 15:47:51 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 691BA3A67EA for ; Sat, 19 Sep 2009 15:47:51 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n8JMdk3E081576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Sep 2009 15:39:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <19095.50105.764201.796499@fireball.kivinen.iki.fi> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B2@il-ex01.ad.checkpoint.com> <19093.12283.746864.474510@fireball.kivinen.iki.fi> <19094.16504.238846.676243@fireball.kivinen.iki.fi> <19095.50105.764201.796499@fireball.kivinen.iki.fi> Date: Sat, 19 Sep 2009 15:38:51 -0700 To: Tero Kivinen , Scott C Moonen From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2009 22:47:52 -0000 Here is the edited text. Please be sure it is still correct.
      Transport mode used with NAT Traversal requires special handling of the traffic selectors used in the IKEv2. The complete scenario looks like:
      | A |<---------->| B |<------->| | +------+ +------+ +------+ +------+ ]]>
      (Other scenarios are simplications of this complex case, so this discussion uses the complete scenario.) In this scenario, there are two address translating NATs: NAT A and NAT B. NAT A is dynamic NAT that maps the clients source address IP1 to IPN1. NAT B is static NAT configured so that connections coming to IPN2 address are mapped to the gateways adddress IP2, that is, IPN2 destination address is mapped to IP2. This allows the client to connect to a server by connecting to the IPN2. NAT B does not necessarely need to be a static NAT, but the client needs to know how to connect to the server, and it can only do that if it somehow knows the outer address of the NAT B, that is, the IPN2 address. If NAT B is a static NAT, then its address can be configured to the client's configuration. Other options would be find it using some other protocol (like DNS), but those are outside of scope of IKEv2. In this scenario, both client and server are configured to use transport mode for the traffic originating from the client node and destined to the server. When the client starts creating the IKEv2 SA and Child SA for sending traffic to the server, it has a triggering packet with source IP address of IP1, and a destination IP address of IPN2. Its PAD and SPD needs to have configuration matching those addresses (or wildcard entries covering them). Because this is transport mode, it uses exactly same addresses as the traffic selectors and outer IP address of the IKE packets. For transport mode, it MUST use exactly one IP address in the TSi and TSr payloads. It can have multiple traffic selectors if it has, for example, multiple port ranges that it wants to negotiate, but all TSi entries must use IP1-IP1 range as the IP addresses, and all TSr entries must have the IPN2-IPN2 range as IP the addresses. The first traffic selector of TSi and TSr SHOULD have very specific traffic selectors including protocol and port numbers from the packet triggering the request. NAT A will then replace the source address of the IKE packet from IP1 to IPN2, and NAT B will replace the destination address of the IKE packet from IPN2 to IP2, so when the packet arrives to the server it will still have the exactly same traffic selectors which were sent by the client, but the IP address of the IKE packet has been replaced to IPN1 and IP2. When the server receives this packet, it normally looks the PAD based on the ID and then searches the SPD based on the traffic selectors. Because IP1 does not really mean anything to the server (it is the address client has behind the NAT), it is useless to do lookup based on that if transport mode is used. On the other hand, the server cannot know whether transport mode is allowed by its policy before it finds the matching SPD entry. In this case, the server should first check that as initiator requested transport mode and do address substitution on the traffic selectors. It needs to first store the old traffic selector IP addresses to be used later for the incremental checksum fixup (the IP address in the TSi can be stored as the real source address and the IP address in the TSr can be stored as the real destination address). After that, if the other end was detected as being behind a NAT, the server replaces the IP address in TSi payloads with the IP address obtained from the source address of the IKE packet received (that is, it replaces IP1 in TSi with IPN1). If the server's end was detected to be behind NAT, it replaces the IP addresses in the TSr payloads with the IP address obtained from the destination address of the IKE packet received (thta is, it replaces IPN2 in TSr with IP2). After this address substitution, both the traffic selectors and the IKE UDP source/destination addresses look the same, and the server does SPD lookup based on those new traffic selectors. If an entry is found and it allows transport mode, then that entry is used. If an entry is found but it does not allow transport mode, then the server MAY undo the address substitution and redo the SPD lookup using the original traffic selectors. If the second lookup succeeds, the server will create an SA in tunnel mode using real traffic selectors sent by the other end. This address substitution in transport mode is needed because the SPD is looked up using the addresses that will be seen by the local host. This also will make sure the SAD entries for the tunnel exit checks and return packets is added using the addresses as seen by the local operating system stack. The most common case is that the server's SPD will contain wildcard entries matching any addresses, but this allows also making different SPD entries, for example, for different known NATs outer addresses. After the SPD lookup, the server will do traffic selector narrowing based on the SPD entry it found. It will again use the already-substituted traffic selectors, and it will thus send back traffic selectors having IPN1 and IP2 as their IP addresses; it can still narrow down the protocol number or port ranges used by the traffic selectors. The SAD entry created for the Child SA will have the addresses as seen by the server, namely IPN1 and IP2. When the client receives the server's reply to the Child SA, it will do similar processing. If the transport mode SA was created, the client can store the original returned traffic selectors as real source and destination addresses. It will replace the IP addresses in the traffic selectors with the ones from the IP header of the IKE packet: it will replace IPN1 with IP1 and IP2 with IPN2. Then it will use those traffic selectors when verifying the SA against sent traffic selectors, and when installing the SAD entry. A summary of the rules for NAT-traversal in transport mode is:
      --Paul Hoffman, Director --VPN Consortium From root@core3.amsl.com Mon Sep 21 00:45:02 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id F18893A692D; Mon, 21 Sep 2009 00:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090921074501.F18893A692D@core3.amsl.com> Date: Mon, 21 Sep 2009 00:45:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-resumption-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 07:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : IKEv2 Session Resumption Author(s) : Y. Sheffer, H. Tschofenig Filename : draft-ietf-ipsecme-ikev2-resumption-08.txt Pages : 29 Date : 2009-09-21 The Internet Key Exchange version 2 (IKEv2) protocol has a certain computational and communication overhead with respect to the number of round-trips required and the cryptographic operations involved. In remote access situations, the Extensible Authentication Protocol (EAP) is used for authentication, which adds several more round trips and consequently latency. To re-establish security associations (SAs) upon a failure recovery condition is time consuming especially when an IPsec peer (such as a VPN gateway) needs to re-establish a large number of SAs with various end points. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA re-establishment. In order to avoid the need to re-run the key exchange protocol from scratch it would be useful to provide an efficient way to resume an IKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously established IKE SA. A client can reconnect to a gateway from which it was disconnected. The proposed approach encodes partial IKE state into an opaque ticket, which can be stored on the client or in a centralized store, and is later made available to the IKEv2 responder for re- authentication. We use the term ticket to refer to the opaque data that is created by the IKEv2 responder. This document does not specify the format of the ticket but examples are provided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-resumption-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-ikev2-resumption-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-21004437.I-D@ietf.org> --NextPart-- From ynir@checkpoint.com Mon Sep 21 03:01:02 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D44D3A67E3 for ; Mon, 21 Sep 2009 03:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.092 X-Spam-Level: X-Spam-Status: No, score=-3.092 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5fY3-BxoSbj for ; Mon, 21 Sep 2009 03:01:01 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id BB1BA3A6806 for ; Mon, 21 Sep 2009 03:01:00 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n8LA1vSr001882 for ; Mon, 21 Sep 2009 13:01:57 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 21 Sep 2009 13:01:57 +0300 From: Yoav Nir To: "ipsec@ietf.org WG" Date: Mon, 21 Sep 2009 13:01:55 +0300 Thread-Topic: I-D Action:draft-nir-ipsecme-ipsecha-00.txt Thread-Index: Aco6oo12bzTGzc7tQjKue12Akomsxw== Message-ID: <955506A1-FA5B-4516-BFB9-EE87F2CE4804@checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD327FBD@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] Fwd: I-D Action:draft-nir-ipsecme-ipsecha-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 10:01:02 -0000 Hi all The draft linked below is a problem statement draft about using =20 IKE&IPsec implementations in high availability and load sharing =20 configurations. I will describe this at tomorrows Interim meeting. Comments are welcome, of course, both on the list and at tomorrow's =20 session. Yoav > > > A New Internet-Draft is available from the on-line Internet-Drafts =20 > directories. > > Title : IPsec High Availability Problem Statement > Author(s) : Y. Nir > Filename : draft-nir-ipsecme-ipsecha-00.txt > Pages : 8 > Date : 2009-09-15 > > This document describes a requirement from IKE and IPsec to allow for > more scalable and available deployments for VPNs. It defines > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-nir-ipsecme-ipsecha-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From kivinen@iki.fi Mon Sep 21 04:12:51 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABE8D3A6994 for ; Mon, 21 Sep 2009 04:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwTvBSwtJQlN for ; Mon, 21 Sep 2009 04:12:50 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 6AD603A6939 for ; Mon, 21 Sep 2009 04:12:50 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n8LBDmfe024701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Sep 2009 14:13:48 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n8LBDj9g015133; Mon, 21 Sep 2009 14:13:45 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19127.24553.76610.294336@fireball.kivinen.iki.fi> Date: Mon, 21 Sep 2009 14:13:45 +0300 From: Tero Kivinen To: "Grewal, Ken" In-Reply-To: References: <808FD6E27AD4884E94820BC333B2DB773C06B22D72@NOK-EUMSG-01.mgdnok.nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 5 min Cc: "ipsec@ietf.org" , "Pasi.Eronen@nokia.com" Subject: Re: [IPsec] AD review comments for draft-ietf-ipsecme-traffic-visibility X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 11:12:51 -0000 Grewal, Ken writes: > >- A question: did the WG discuss the pros and cons of integrity > >protecting the WESP header? (This does make WESP more complex to > >implement, and currently the WESP header does not contain any data > >that would benefit from integrity protection in any way.) > [Ken] This change was the result of a discussion on threats posed by > 'malware', which could modify the WESP headers to obfuscate the > payload from inspection by intermediate nodes such as IDS/IPS > systems. > The issue (ticket #104) was raised and closed some time back after > lengthy discussions on the topic. > http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/104 As everything in the WESP header is something that can be verified by the recipient node why is the integrity protection needed? I think it would make implementation WESP much easier if it can be done as post processing step after ESP has been applied, in a similar way UDP encapsulation can be done to the ESP packet. -- kivinen@iki.fi From kivinen@iki.fi Mon Sep 21 04:48:34 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DA223A6A7A for ; Mon, 21 Sep 2009 04:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxOAXPC7Dx9j for ; Mon, 21 Sep 2009 04:48:33 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 6F4903A67E7 for ; Mon, 21 Sep 2009 04:48:33 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n8LBnTUt018809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Sep 2009 14:49:29 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n8LBnSvP024855; Mon, 21 Sep 2009 14:49:28 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19127.26696.732531.959141@fireball.kivinen.iki.fi> Date: Mon, 21 Sep 2009 14:49:28 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B2@il-ex01.ad.checkpoint.com> <19093.12283.746864.474510@fireball.kivinen.iki.fi> <19094.16504.238846.676243@fireball.kivinen.iki.fi> <19095.50105.764201.796499@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 15 min X-Total-Time: 15 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 11:48:34 -0000 Paul Hoffman writes: > Here is the edited text. Please be sure it is still correct. There is the same typo my original text had: > NAT A will then replace the source address of the IKE packet from > IP1 to IPN2, and NAT B will replace the destination address of the IKE ^^^^ This should be IPN1. > packet from IPN2 to IP2, so when the packet arrives to the server it > will still have the exactly same traffic selectors which were sent by > the client, but the IP address of the IKE packet has been replaced to > IPN1 and IP2. >
      For the responder, when transport mode is proposed by client: > > - Store the original traffic selector IP addresses as real source > and destination address in case we need to undo address > substitution. The IP addresses are also needed for the RFC 3948 incremental checksum fixup in udp encapsulation, not only for undoing the address substitution. > - If the client is behind a NAT, substitute the IP address in the > TSi entries with the remote address of the IKE SA. > > - If the server is behind a NAT substitute the IP address in the > TSr entries with the local address of the IKE SA. "Client" and "server" are ok here, but my original text used "other end" and "this end" at least in our implementation our NAT traversal detection does tests that way. I.e. it know whether this end and/or other end is behind nat and knows to enable suitable processing based on that (i.e. sending of RFC3948 keepalives etc). Client and server makes this bit more vpn roadwarrior case centric, compared to using "this end" and "other end". But either one is acceptable here. -- kivinen@iki.fi From kivinen@iki.fi Mon Sep 21 05:15:48 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED8443A67A6 for ; Mon, 21 Sep 2009 05:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kVj1zpYfZbR for ; Mon, 21 Sep 2009 05:15:48 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 8FCC43A659A for ; Mon, 21 Sep 2009 05:15:46 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n8LCGkOT015614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Sep 2009 15:16:46 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n8LCGkNG023923; Mon, 21 Sep 2009 15:16:46 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19127.28334.472030.873072@fireball.kivinen.iki.fi> Date: Mon, 21 Sep 2009 15:16:46 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 25 min X-Total-Time: 26 min Cc: IPsecme WG Subject: [IPsec] #22 Simultaneous IKE SA rekey text X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 12:15:49 -0000 Paul Hoffman writes: > #22 - Add section on simultaneous IKE SA rekey > There was no discussion. We will bring this up one more time > because it is important, but if there is not more interest and > more inclination to review Tero's text, we will write a short > note in the document that simultaneous IKE SA rekey is an issue > but nothing else. I would propose cut & pasting the simultaneous IKE SA rekey issue from the clarifications RFC 4718, and adding some more text: ---------------------------------------------------------------------- X.Y.Z Simultaneous IKE_SA Rekeying Probably the most complex case occurs when both peers try to rekey the IKE_SA at the same time. Basically, the text in Section 2.8 applies to this case, however, it is important to ensure that the CHILD_SAs are inherited by the right IKE_SA. After the CREATE_CHILD_SA exchanges, two new IKE_SAs exist between A and B; the one containing the lowest nonce inherits the CHILD_SAs. The old IKE SA is deleted by the node which created the winning IKE SA. The loosing IKE SA is deleted by the node which created it. The basic case is where both ends notice this is simultaneous rekey, and can delay moving of the CHILD_SAs until they know which one wins. The more complex case happens where there is dropped packets and one end does not detect simultaneous rekey until it has already finished its rekey and moved CHILD_SAs. As the basic case can be processed in similar way as the more complex case, this example here only covers the more complex case. In this case host A and B has IKE SA up and running and both ends decide to rekey it: Host A Host B ----------- ----------- send req1: ... Ni1 ... --> <-- send req2: ... Ni2 ... --> recv req1 Now if the req2 is dropped for some reason, the Host A does not know there is simultaneous rekey, but host B will know it when it receives the req1. It will process the req1, but it cannot yet move the CHILD_SAs as it does not know the Nr2. It postpones the CHILD_SA moving until the req2/resp2 rekey finishes. It sends resp1 back to the Host A to answer req1 IKE SA rekey: <-- send resp1: ... Nr1 ... recv resp1 <-- Now the Host A has finished the IKE SA rekey without knowing it was simultaneous rekey. It will move the CHILD_SAs from the old IKE SA to new rekeyed IKE SA A. It MUST NOT immediately delete the old IKE SA, but instead wait for some time to see in case there was simultaneous rekey ongoing or not. When Host B retransmits its req2 the Host A will notice that there was simultaneous rekey going on, and it will send normal reply to that: recv req1 <-- send resp2: ... Nr2 ... --> --> recv resp2 After sending that reply that also creates the second IKE SA B in Host A and then Host A can check all the four nonces and see which of them is lowest, and it will then move all the CHILD_SAs to that new IKE SA having lowest nonce unless they were already there (i.e. if the IKE SA A had lowest nonce, Host A has already moved the CHILD_SAs there, if IKE SA B had lowest nonce, host A needs to move CHILD_SAs from the IKE SA A to this IKE SA B, and start timer to delete IKE SA A). When Host B receives the resp2 it knows that simultaneous rekey is finished, and it can check the nonces and move CHILD_SAs from the original IKE SA to either IKE SA A or B depending which had lowest nonce. If it was IKE SA A, the host B needs to start timer to delete IKE SA B. Depending who created the winning rekeyed IKE SA decides who is going to delete the old IKE SA, i.e. the one who created the winning IKE SA also cleans up the old IKE SA. Note, that Host B processing is identical to the basic case where host notices during processing that there is simultaneous rekey ongoing. In case the Host A didn't wait for long enough before start deleting old IKE SA there can be case where host B is still trying to retransmit its req2 in the old IKE SA when it receives the delete to the old IKE SA. In that case it knows that Host A has NOT received any of its requests, thus is unaware that there is simultaneous rekey ongoing, thus it can safely stop retrasnmitting req2, and allow old IKE SA to be deleted, and move all CHILD_SAs to the IKE SA A created by Host A. -- kivinen@iki.fi From kivinen@iki.fi Mon Sep 21 05:27:21 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8988828C131 for ; Mon, 21 Sep 2009 05:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tltea2j7v3OU for ; Mon, 21 Sep 2009 05:27:20 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 724ED28C13B for ; Mon, 21 Sep 2009 05:27:20 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n8LCSEQd019105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Sep 2009 15:28:14 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n8LCSDQE029592; Mon, 21 Sep 2009 15:28:13 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19127.29021.279080.779446@fireball.kivinen.iki.fi> Date: Mon, 21 Sep 2009 15:28:13 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <19109.286.34505.162897@fireball.kivinen.iki.fi> <73BF7996-C4FA-4442-B49D-DDD710CACA87@checkpoint.com> <19109.11583.348236.158555@fireball.kivinen.iki.fi> <19120.57165.424835.989773@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 10 min Cc: "ipsec@ietf.org WG" , Yoav Nir Subject: Re: [IPsec] Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 12:27:21 -0000 Paul Hoffman writes: >
      > > If there is an error parsing or processing a response packet, the > general rule is to not send bac any error message because responses ^^^ s/bac/back/ > should not generate new requests (and a new request would be the only > way to send back an error message). Such errors in parsing or > processing response packets should still cause the recipient to clean > up the IKE state (for example, by sending a DELETE for a bad SA). > In an IKE_SA_INIT exchange, any error notification causes the > exchange to fail. Note that some error notifications such as COOKIE, > INVALID_KE_PAYLOAD or INVALID_MAJOR_VERSION may lead to a subsequent > successful exchange. Because all error notifications are completely > unauthenticated, the recipient should continue trying for some time > before giving up but not immediately act based on the error > notification unless corrective actions are defined in this > specification, such as for COOKIE, INVALID_KE_PAYLOAD, and > INVALID_MAJOR_VERSION. I think the last sentence is bit hard to parse. > NOTE FOR WG DISCUSSION: Having other payloads in the message is > allowed but there are none suggested. One WG member mentioned the > possibility of adding a DELETE payload when the error is sent in a > separate INFORMATIONAL exchange. Do we want to allow such additional > payloads that have operational semantics? As I do not see any other reason to start new informational exchange when processing IKE_AUTH reply than fatal errors when creating it (i.e. AUTHENTICATION_FAILED) which already deletes the IKE SA, I do not see any benefit from adding DELETE notification to the message. It would be saying the same thing twice: "There was fatal error delete the sa, and by the way delete the sa." -- kivinen@iki.fi From yaronf@checkpoint.com Mon Sep 21 05:39:26 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDC393A67A7 for ; Mon, 21 Sep 2009 05:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jSAm7sIOrtf for ; Mon, 21 Sep 2009 05:39:26 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 0FF6A3A6765 for ; Mon, 21 Sep 2009 05:39:25 -0700 (PDT) X-CheckPoint: {4AB77355-0-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id DCBB329C005; Mon, 21 Sep 2009 15:40:21 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id A836329C002; Mon, 21 Sep 2009 15:40:21 +0300 (IDT) X-CheckPoint: {4AB77352-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n8LCeKSr013262; Mon, 21 Sep 2009 15:40:21 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 21 Sep 2009 15:40:20 +0300 From: Yaron Sheffer To: Tero Kivinen , "Grewal, Ken" Date: Mon, 21 Sep 2009 15:40:19 +0300 Thread-Topic: [IPsec] AD review comments for draft-ietf-ipsecme-traffic-visibility Thread-Index: Aco6rJ+rooaEqEx0Q9OT1l/HPaUjqwACB6Bg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328491@il-ex01.ad.checkpoint.com> References: <808FD6E27AD4884E94820BC333B2DB773C06B22D72@NOK-EUMSG-01.mgdnok.nokia.com> <19127.24553.76610.294336@fireball.kivinen.iki.fi> In-Reply-To: <19127.24553.76610.294336@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , "Pasi.Eronen@nokia.com" Subject: Re: [IPsec] AD review comments for draft-ietf-ipsecme-traffic-visibility X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 12:39:27 -0000 Hi Tero, Given that the existing ESP header is integrity-protected, I don't see the = downside to adding the same protection for the new header. On the other han= d, this would eliminate a whole class of vulnerabilities. We still have a f= ew reserved bits in the WESP header, and you don't want to find out years d= own the road that they cannot be used because they're not protected in tran= sit. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Tero Kivinen > Sent: Monday, September 21, 2009 14:14 > To: Grewal, Ken > Cc: ipsec@ietf.org; Pasi.Eronen@nokia.com > Subject: Re: [IPsec] AD review comments for draft-ietf-ipsecme-traffic- > visibility >=20 > Grewal, Ken writes: > > >- A question: did the WG discuss the pros and cons of integrity > > >protecting the WESP header? (This does make WESP more complex to > > >implement, and currently the WESP header does not contain any data > > >that would benefit from integrity protection in any way.) > > [Ken] This change was the result of a discussion on threats posed by > > 'malware', which could modify the WESP headers to obfuscate the > > payload from inspection by intermediate nodes such as IDS/IPS > > systems. > > The issue (ticket #104) was raised and closed some time back after > > lengthy discussions on the topic. > > http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/104 >=20 > As everything in the WESP header is something that can be verified by > the recipient node why is the integrity protection needed? >=20 > I think it would make implementation WESP much easier if it can be > done as post processing step after ESP has been applied, in a similar > way UDP encapsulation can be done to the ESP packet. > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. Email secured by Check Point Email secured by Check Point From paul.hoffman@vpnc.org Mon Sep 21 07:11:38 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 246723A6A32 for ; Mon, 21 Sep 2009 07:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.08 X-Spam-Level: X-Spam-Status: No, score=-5.08 tagged_above=-999 required=5 tests=[AWL=0.966, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqaqdHkpTavG for ; Mon, 21 Sep 2009 07:11:37 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 38BB73A6A29 for ; Mon, 21 Sep 2009 07:11:37 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n8LECbE8031457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 21 Sep 2009 07:12:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20090826173221.F14CB28C4C5@core3.amsl.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80190A978F8F9@il-ex01.ad.checkpoint.com> Date: Mon, 21 Sep 2009 07:12:33 -0700 To: "ipsec@ietf.org" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] IPSECME Virtual Interim Meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 14:11:38 -0000 Just a reminder that the meeting is tomorrow, in about 24 hours. See/hear you there! At 7:53 PM -0700 9/17/09, Paul Hoffman wrote: >At 10:03 PM +0300 9/12/09, Yaron Sheffer wrote: >> The ipsecme WG will have a virtual interim WG meeting in about a month. We >> will have a conference call on Tuesday September 22, 15:00 GMT (18:00 >> Israel, 17:00 CET, 11:00 EDT, 8:00 PDT), for 2 hours. We are planning on >> the same format as the previous time: a VoIP conference bridge and posted >> slides. Technical details are available here: >> >> http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/ConferenceCalls > >We are using the same TeamSpeak server as before, teamspeak.vpnc.org. I have turned on that server now so people can test it before the meeting. If you want to test your TeamSpeak client before the meeting, we will have a short test-run 24 hours before the meeting (that is, the same times as above, but on Monday, September 21). --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Mon Sep 21 07:18:09 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 261FA3A6AA1 for ; Mon, 21 Sep 2009 07:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.094 X-Spam-Level: X-Spam-Status: No, score=-5.094 tagged_above=-999 required=5 tests=[AWL=0.952, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSdllzy4E5LH for ; Mon, 21 Sep 2009 07:18:08 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 70A933A659B for ; Mon, 21 Sep 2009 07:18:08 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n8LEJ54Q032296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Sep 2009 07:19:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <19127.29021.279080.779446@fireball.kivinen.iki.fi> References: <19109.286.34505.162897@fireball.kivinen.iki.fi> <73BF7996-C4FA-4442-B49D-DDD710CACA87@checkpoint.com> <19109.11583.348236.158555@fireball.kivinen.iki.fi> <19120.57165.424835.989773@fireball.kivinen.iki.fi> <19127.29021.279080.779446@fireball.kivinen.iki.fi> Date: Mon, 21 Sep 2009 07:19:04 -0700 To: Tero Kivinen From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "ipsec@ietf.org WG" , Yoav Nir Subject: Re: [IPsec] Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 14:18:09 -0000 Thanks for the two editorial notes; fixed. We want more input on the following: At 3:28 PM +0300 9/21/09, Tero Kivinen wrote: > > NOTE FOR WG DISCUSSION: Having other payloads in the message is >> allowed but there are none suggested. One WG member mentioned the >> possibility of adding a DELETE payload when the error is sent in a >> separate INFORMATIONAL exchange. Do we want to allow such additional >> payloads that have operational semantics? > >As I do not see any other reason to start new informational exchange >when processing IKE_AUTH reply than fatal errors when creating it >(i.e. AUTHENTICATION_FAILED) which already deletes the IKE SA, I do >not see any benefit from adding DELETE notification to the message. It >would be saying the same thing twice: "There was fatal error delete >the sa, and by the way delete the sa." --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Mon Sep 21 07:23:33 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 019D13A694E for ; Mon, 21 Sep 2009 07:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.107 X-Spam-Level: X-Spam-Status: No, score=-5.107 tagged_above=-999 required=5 tests=[AWL=0.939, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BPYuo6a6ZQ4 for ; Mon, 21 Sep 2009 07:23:32 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 2EB053A6A9E for ; Mon, 21 Sep 2009 07:23:32 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n8LEOV1G032974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Sep 2009 07:24:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <19127.26696.732531.959141@fireball.kivinen.iki.fi> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B2@il-ex01.ad.checkpoint.com> <19093.12283.746864.474510@fireball.kivinen.iki.fi> <19094.16504.238846.676243@fireball.kivinen.iki.fi> <19095.50105.764201.796499@fireball.kivinen.iki.fi> <19127.26696.732531.959141@fireball.kivinen.iki.fi> Date: Mon, 21 Sep 2009 07:24:30 -0700 To: Tero Kivinen From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 14:23:33 -0000 At 2:49 PM +0300 9/21/09, Tero Kivinen wrote: >The IP addresses are also needed for the RFC 3948 incremental checksum >fixup in udp encapsulation, not only for undoing the address >substitution. As I said in my earlier note, I have removed all discussion of RFC 3948 from this new text. RFC 3948 is for IKEv1 only, and is not relevant here. > > - If the client is behind a NAT, substitute the IP address in the >> TSi entries with the remote address of the IKE SA. >> >> - If the server is behind a NAT substitute the IP address in the >> TSr entries with the local address of the IKE SA. > >"Client" and "server" are ok here, but my original text used "other >end" and "this end" at least in our implementation our NAT traversal >detection does tests that way. I.e. it know whether this end and/or >other end is behind nat and knows to enable suitable processing based >on that (i.e. sending of RFC3948 keepalives etc). Client and server >makes this bit more vpn roadwarrior case centric, compared to using >"this end" and "other end". > >But either one is acceptable here. I changed to "client" and "server" to match the figure. Let me know if this is not OK. --Paul Hoffman, Director --VPN Consortium From smoonen@us.ibm.com Mon Sep 21 08:10:09 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 601323A6AA7; Mon, 21 Sep 2009 08:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjqypCE2DcHy; Mon, 21 Sep 2009 08:10:07 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by core3.amsl.com (Postfix) with ESMTP id C4C273A6900; Mon, 21 Sep 2009 08:10:06 -0700 (PDT) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e35.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n8LF0t2G009321; Mon, 21 Sep 2009 09:00:55 -0600 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8LFAjrO166118; Mon, 21 Sep 2009 09:10:46 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n8LFC1aR010096; Mon, 21 Sep 2009 09:12:01 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av06.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n8LFC1Xd010091; Mon, 21 Sep 2009 09:12:01 -0600 In-Reply-To: References: <19109.286.34505.162897@fireball.kivinen.iki.fi> <73BF7996-C4FA-4442-B49D-DDD710CACA87@checkpoint.com> <19109.11583.348236.158555@fireball.kivinen.iki.fi> <19120.57165.424835.989773@fireball.kivinen.iki.fi> To: Paul Hoffman MIME-Version: 1.0 X-KeepSent: D7F8317D:6872D12B-85257638:0052FD1A; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 09/21/2009 11:10:28 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 09/21/2009 11:10:29 AM, Serialize complete at 09/21/2009 11:10:29 AM, S/MIME Sign failed at 09/21/2009 11:10:29 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V851_08302009|August 30, 2009) at 09/21/2009 09:10:43, Serialize complete at 09/21/2009 09:10:43 Message-ID: Date: Mon, 21 Sep 2009 11:10:43 -0400 Content-Type: multipart/alternative; boundary="=_alternative 00535B7285257638_=" Cc: "ipsec@ietf.org WG" , ipsec-bounces@ietf.org, Yoav Nir , Tero Kivinen Subject: Re: [IPsec] Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 15:10:09 -0000 This is a multipart message in MIME format. --=_alternative 00535B7285257638_= Content-Type: text/plain; charset="US-ASCII" Paul, > between wanting to help the peer to diagnose a problem and thust s/thust/thus/ > wanting to avoid being part a denial of service attack Suggest either "being part *of* a" or "being a willing participant in a". > NOTE FOR WG DISCUSSION: Having other payloads in the message is > allowed but there are none suggested. One WG member mentioned the > possibility of adding a DELETE payload when the error is sent in a > separate INFORMATIONAL exchange. Do we want to allow such additional > payloads that have operational semantics? I think you are asking specifically about the IKE_AUTH response? If so, I agree that DELETE does not make sense in the IKE_AUTH response, and N(AUTHENTICATION_FAILED), for example, is sufficient to delete the IKE SA. I think we can forbid DELETE in the IKE_AUTH response. However, because a separate INFORMATIONAL exchange cannot be definitively correlated to the IKE_AUTH exchange, I'd like to retain the option of sending both DELETE and N(AUTHENTICATION_FAILED) (for example) in a separate INFO exchange. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Paul Hoffman To: Tero Kivinen , Yoav Nir Cc: "ipsec@ietf.org WG" Date: 09/19/2009 06:49 PM Subject: Re: [IPsec] Issue #26: Missing treatment of error cases Here is the edited text. Please make sure it still is correct.
      There are many kinds of errors that can occur during IKE processing. The general rule is that if a request is received that is badly formatted, or unacceptable for reasons of policy (such as no matching cryptographic algorithms), the response contains a Notify payload indicating the error. The decision whether or not to send such a response depends whether or not there is an authenticated IKE SA. If there is an error parsing or processing a response packet, the general rule is to not send bac any error message because responses should not generate new requests (and a new request would be the only way to send back an error message). Such errors in parsing or processing response packets should still cause the recipient to clean up the IKE state (for example, by sending a DELETE for a bad SA). Only authentication failures (AUTHENTICATION_FAILED) and malformed messages (INVALID_SYNTAX) lead to a deletion of the IKE SA without requiring an explicit INFORMATIONAL exchange carrying a DELETE payload. Other error conditions MAY require such an exchange if policy dictates that this is needed.
      Errors that occur before a cryptographically protected IKE SA is established need to be handled very carefully. There is a trade-off between wanting to help the peer to diagnose a problem and thust responding to the error, and wanting to avoid being part a denial of service attack based on forged messages. In an IKE_SA_INIT exchange, any error notification causes the exchange to fail. Note that some error notifications such as COOKIE, INVALID_KE_PAYLOAD or INVALID_MAJOR_VERSION may lead to a subsequent successful exchange. Because all error notifications are completely unauthenticated, the recipient should continue trying for some time before giving up but not immediately act based on the error notification unless corrective actions are defined in this specification, such as for COOKIE, INVALID_KE_PAYLOAD, and INVALID_MAJOR_VERSION.
      All errors that occur in an IKE_AUTH exchange, causing the authentication to fail for whatever reason (invalid shared secret, invalid ID, untrusted certificate issuer, revoked or expired certificate, etc.) SHOULD result in an AUTHENTICATION_FAILED notification. If the error occurred on the responder, the notification is returned in the protected response, and is usually the only payload in that response. Although the IKE_AUTH messages are encrypted and integrity protected, if the peer receiving this notification has not authenticated the other end yet, that peer needs to treat the information with caution. If the error occurs on the initiator, the notification MAY be returned in a separate INFORMATIONAL exchange, usually with no other payloads. This is exception for the general rule of not starting new exchanges based on errors in responses. Note, however, that request messages that contain an unsupported critical payload, or where the whole message is malformed (rather than just bad payload contents), MUST be rejected in their entirety, and MUST only lead to an UNSUPPORTED_CRITICAL_PAYLOAD or INVALID_SYNTAX Notification sent as response. The receiver should not verify the payloads related to authentication in this case. If authentication has succeeded in the IKE_AUTH exchange, the IKE SA is established; however, establishing the Child SA or requesting configuration information may still fail. This failure does not automatically cause the IKE SA to be deleted. Specifically, a responder may include all the payloads associated with authentication (IDr, Cert and AUTH) while sending error notifications for the piggybacked exchanges (FAILED_CP_REQUIRED, INVALID_SELECTORS, NO_PROPOSAL_CHOSEN, and so on), and the initiator MUST NOT fail the authentication because of this. The initiator MAY, of course, for reasons of policy later delete such an IKE SA. In an IKE_AUTH exchange, or in the INFORMATIONAL exchange immediately following it (in case an error happened in when processing response to IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and AUTHENTICATION_FAILED notifications are the only ones to cause the IKE SA to be deleted or not created, without a DELETE payload. Extension documents may define new error notifications with these semantics, but MUST NOT use them unless the peer has been shown to understand them. NOTE FOR WG DISCUSSION: Having other payloads in the message is allowed but there are none suggested. One WG member mentioned the possibility of adding a DELETE payload when the error is sent in a separate INFORMATIONAL exchange. Do we want to allow such additional payloads that have operational semantics?
      After the IKE SA is authenticated all requests having errors MUST result in response notifying about the error. In normal situations, there should not be cases where valid response from one peer results in an error situation in the other peer, so there should not be any reason for a peer to send error messages to the other end except as a response. Because sending such error messages as INFORMATIONAL exchange might lead to further errors that could cause loops, such errors SHOULD NOT be sent. If errors are seen that indicate that the peers do not have same state, it might be good to delete the IKE SA to clean up state and start over. If a peer parsing a request notices that it is badly formatted (after it has passed the message authentication code checks and window checks) and it returns an INVALID_SYNTAX notification, then this error notification is considered fatal in both peers, meaning that the IKE SA is deleted without needing an explicit DELETE payload.
      A node needs to limit the rate at which it will send messages in response to unprotected messages. If a node receives a message on UDP port 500 or 4500 outside the context of an IKE SA known to it (and the message is not a request to start an IKE SA), this may be the result of a recent crash of the node. If the message is marked as a response, the node can audit the suspicious event but MUST NOT respond. If the message is marked as a request, the node can audit the suspicious event and MAY send a response. If a response is sent, the response MUST be sent to the IP address and port from where it came with the same IKE SPIs and the Message ID copied. The response MUST NOT be cryptographically protected and MUST contain an INVALID_IKE_SPI Notify payload. The INVALID_IKE_SPI notification indicates an IKE message was received with an unrecognized destination SPI; this usually indicates that the recipient has rebooted and forgotten the existence of an IKE SA. A peer receiving such an unprotected Notify payload MUST NOT respond and MUST NOT change the state of any existing SAs. The message might be a forgery or might be a response that a genuine correspondent was tricked into sending. A node should treat such a message (and also a network message like ICMP destination unreachable) as a hint that there might be problems with SAs to that IP address and should initiate a liveness check for any such IKE SA. An implementation SHOULD limit the frequency of such tests to avoid being tricked into participating in a denial of service attack. If an error occurs outside the context of an IKE request (e.g., the node is getting ESP messages on a nonexistent SPI), the node SHOULD initiate an INFORMATIONAL exchange with a Notify payload describing the problem. A node receiving a suspicious message from an IP address (and port, if NAT traversal is used) with which it has an IKE SA SHOULD send an IKE Notify payload in an IKE INFORMATIONAL exchange over that SA. The recipient MUST NOT change the state of any SAs as a result, but may wish to audit the event to aid in diagnosing malfunctions.
      --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 00535B7285257638_= Content-Type: text/html; charset="US-ASCII"
      Paul,

      > between wanting to help the peer to diagnose a problem and thust

      s/thust/thus/

      > wanting to avoid being part a denial of service attack

      Suggest either "being part *of* a" or "being a willing participant in a".

      > <t>NOTE FOR WG DISCUSSION: Having other payloads in the message is
      > allowed but there are none suggested. One WG member mentioned the
      > possibility of adding a DELETE payload when the error is sent in a
      > separate INFORMATIONAL exchange. Do we want to allow such additional
      > payloads that have operational semantics?</t>

      I think you are asking specifically about the IKE_AUTH response?  If so, I agree that DELETE does not make sense in the IKE_AUTH response, and N(AUTHENTICATION_FAILED), for example, is sufficient to delete the IKE SA.  I think we can forbid DELETE in the IKE_AUTH response.  However, because a separate INFORMATIONAL exchange cannot be definitively correlated to the IKE_AUTH exchange, I'd like to retain the option of sending both DELETE and N(AUTHENTICATION_FAILED) (for example) in a separate INFO exchange.


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


      From: Paul Hoffman <paul.hoffman@vpnc.org>
      To: Tero Kivinen <kivinen@iki.fi>, Yoav Nir <ynir@checkpoint.com>
      Cc: "ipsec@ietf.org WG" <ipsec@ietf.org>
      Date: 09/19/2009 06:49 PM
      Subject: Re: [IPsec] Issue #26: Missing treatment of error cases




      Here is the edited text. Please make sure it still is correct.

      <section anchor='sect-2.21' title='Error Handling'>

      <t>There are many kinds of errors that can occur during IKE
      processing. The general rule is that if a request is received that is
      badly formatted, or unacceptable for reasons of policy (such as no
      matching cryptographic algorithms), the response contains a Notify
      payload indicating the error. The decision whether or not to send
      such a response depends whether or not there is an authenticated IKE
      SA.</t>

      <t>If there is an error parsing or processing a response packet, the
      general rule is to not send bac any error message because responses
      should not generate new requests (and a new request would be the only
      way to send back an error message). Such errors in parsing or
      processing response packets should still cause the recipient to clean
      up the IKE state (for example, by sending a DELETE for a bad SA).</t>

      <t>Only authentication failures (AUTHENTICATION_FAILED) and malformed
      messages (INVALID_SYNTAX) lead to a deletion of the IKE SA without
      requiring an explicit INFORMATIONAL exchange carrying a DELETE
      payload. Other error conditions MAY require such an exchange if
      policy dictates that this is needed.</t>

      <section anchor='sect-2.21.1' title='Error Handling in IKE_SA_INIT'>

      <t>Errors that occur before a cryptographically protected IKE SA is
      established need to be handled very carefully. There is a trade-off
      between wanting to help the peer to diagnose a problem and thust
      responding to the error, and wanting to avoid being part a denial of
      service attack based on forged messages.</t>

      <t>In an IKE_SA_INIT exchange, any error notification causes the
      exchange to fail. Note that some error notifications such as COOKIE,
      INVALID_KE_PAYLOAD or INVALID_MAJOR_VERSION may lead to a subsequent
      successful exchange. Because all error notifications are completely
      unauthenticated, the recipient should continue trying for some time
      before giving up but not immediately act based on the error
      notification unless corrective actions are defined in this
      specification, such as for COOKIE, INVALID_KE_PAYLOAD, and
      INVALID_MAJOR_VERSION.</t>

      </section>

      <section anchor='sect-2.21.2' title='Error Handling in IKE_AUTH'>

      <t>All errors that occur in an IKE_AUTH exchange, causing the
      authentication to fail for whatever reason (invalid shared secret,
      invalid ID, untrusted certificate issuer, revoked or expired
      certificate, etc.) SHOULD result in an AUTHENTICATION_FAILED
      notification. If the error occurred on the responder, the
      notification is returned in the protected response, and is usually
      the only payload in that response. Although the IKE_AUTH messages are
      encrypted and integrity protected, if the peer receiving this
      notification has not authenticated the other end yet, that peer needs
      to treat the information with caution.</t>

      <t>If the error occurs on the initiator, the notification MAY be
      returned in a separate INFORMATIONAL exchange, usually with no other
      payloads. This is exception for the general rule of not starting new
      exchanges based on errors in responses.</t>

      <t>Note, however, that request messages that contain an unsupported
      critical payload, or where the whole message is malformed (rather
      than just bad payload contents), MUST be rejected in their entirety,
      and MUST only lead to an UNSUPPORTED_CRITICAL_PAYLOAD or
      INVALID_SYNTAX Notification sent as response. The receiver should not
      verify the payloads related to authentication in this case.</t>

      <t>If authentication has succeeded in the IKE_AUTH exchange, the IKE
      SA is established; however, establishing the Child SA or requesting
      configuration information may still fail. This failure does not
      automatically cause the IKE SA to be deleted. Specifically, a
      responder may include all the payloads associated with authentication
      (IDr, Cert and AUTH) while sending error notifications for the
      piggybacked exchanges (FAILED_CP_REQUIRED, INVALID_SELECTORS,
      NO_PROPOSAL_CHOSEN, and so on), and the initiator MUST NOT fail the
      authentication because of this. The initiator MAY, of course, for
      reasons of policy later delete such an IKE SA.</t>

      <t>In an IKE_AUTH exchange, or in the INFORMATIONAL exchange
      immediately following it (in case an error happened in when
      processing response to IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD,
      INVALID_SYNTAX, and AUTHENTICATION_FAILED notifications are the only
      ones to cause the IKE SA to be deleted or not created, without a
      DELETE payload. Extension documents may define new error
      notifications with these semantics, but MUST NOT use them unless the
      peer has been shown to understand them.</t>

      <t>NOTE FOR WG DISCUSSION: Having other payloads in the message is
      allowed but there are none suggested. One WG member mentioned the
      possibility of adding a DELETE payload when the error is sent in a
      separate INFORMATIONAL exchange. Do we want to allow such additional
      payloads that have operational semantics?</t>

      </section>

      <section anchor='sect-2.21.3' title='Error Handling after IKE SA is Authenticated'>

      <t>After the IKE SA is authenticated all requests having errors MUST
      result in response notifying about the error.</t>

      <t>In normal situations, there should not be cases where valid
      response from one peer results in an error situation in the other
      peer, so there should not be any reason for a peer to send error
      messages to the other end except as a response. Because sending such
      error messages as INFORMATIONAL exchange might lead to further errors
      that could cause loops, such errors SHOULD NOT be sent. If errors are
      seen that indicate that the peers do not have same state, it might be
      good to delete the IKE SA to clean up state and start over.</t>

      <t>If a peer parsing a request notices that it is badly formatted
      (after it has passed the message authentication code checks and
      window checks) and it returns an INVALID_SYNTAX notification, then
      this error notification is considered fatal in both peers, meaning
      that the IKE SA is deleted without needing an explicit DELETE
      payload.</t>

      </section>

      <section anchor='sect-2.21.4' title='Error Handling Outside IKE SA'>

      <t>A node needs to limit the rate at which it will send messages in
      response to unprotected messages.</t>

      <t>If a node receives a message on UDP port 500 or 4500 outside the
      context of an IKE SA known to it (and the message is not a request to
      start an IKE SA), this may be the result of a recent crash of the
      node. If the message is marked as a response, the node can audit the
      suspicious event but MUST NOT respond. If the message is marked as a
      request, the node can audit the suspicious event and MAY send a
      response. If a response is sent, the response MUST be sent to the IP
      address and port from where it came with the same IKE SPIs and the
      Message ID copied. The response MUST NOT be cryptographically
      protected and MUST contain an INVALID_IKE_SPI Notify payload. The
      INVALID_IKE_SPI notification indicates an IKE message was received
      with an unrecognized destination SPI; this usually indicates that the
      recipient has rebooted and forgotten the existence of an IKE SA.</t>

      <t>A peer receiving such an unprotected Notify payload MUST NOT
      respond and MUST NOT change the state of any existing SAs. The
      message might be a forgery or might be a response that a genuine
      correspondent was tricked into sending. A node should treat such a
      message (and also a network message like ICMP destination
      unreachable) as a hint that there might be problems with SAs to that
      IP address and should initiate a liveness check for any such IKE SA.
      An implementation SHOULD limit the frequency of such tests to avoid
      being tricked into participating in a denial of service attack.</t>

      <t>If an error occurs outside the context of an IKE request (e.g.,
      the node is getting ESP messages on a nonexistent SPI), the node
      SHOULD initiate an INFORMATIONAL exchange with a Notify payload
      describing the problem.</t>

      <t>A node receiving a suspicious message from an IP address (and
      port, if NAT traversal is used) with which it has an IKE SA SHOULD
      send an IKE Notify payload in an IKE INFORMATIONAL exchange over that
      SA. The recipient MUST NOT change the state of any SAs as a result,
      but may wish to audit the event to aid in diagnosing
      malfunctions.</t>

      </section>

      </section>

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

      --=_alternative 00535B7285257638_=-- From smoonen@us.ibm.com Mon Sep 21 09:30:39 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CEEA3A6AC4 for ; Mon, 21 Sep 2009 09:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzYuZWJ8HVeR for ; Mon, 21 Sep 2009 09:30:37 -0700 (PDT) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by core3.amsl.com (Postfix) with ESMTP id 065F63A688A for ; Mon, 21 Sep 2009 09:30:36 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e36.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n8LGTcHH008091 for ; Mon, 21 Sep 2009 10:29:38 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8LGVTiv214990 for ; Mon, 21 Sep 2009 10:31:30 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n8LGVTYW009833 for ; Mon, 21 Sep 2009 10:31:29 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n8LGVTHf009828; Mon, 21 Sep 2009 10:31:29 -0600 In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B2@il-ex01.ad.checkpoint.com> <19093.12283.746864.474510@fireball.kivinen.iki.fi> <19094.16504.238846.676243@fireball.kivinen.iki.fi> <19095.50105.764201.796499@fireball.kivinen.iki.fi> To: Paul Hoffman MIME-Version: 1.0 X-KeepSent: 270B4A17:A9588ABF-85257638:00544B52; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 09/21/2009 12:23:04 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 09/21/2009 12:23:04 PM, Serialize complete at 09/21/2009 12:23:04 PM, S/MIME Sign failed at 09/21/2009 12:23:04 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V851_08302009|August 30, 2009) at 09/21/2009 10:31:28, Serialize complete at 09/21/2009 10:31:28 Message-ID: Date: Mon, 21 Sep 2009 12:31:27 -0400 Content-Type: multipart/alternative; boundary="=_alternative 005A00ED85257638_=" Cc: "ipsec@ietf.org" , Tero Kivinen Subject: Re: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 16:30:39 -0000 This is a multipart message in MIME format. --=_alternative 005A00ED85257638_= Content-Type: text/plain; charset="US-ASCII" Paul, > NAT B does not necessarely need s/necessarely/necessarily/ > replaces the IP address in TSi payloads . . . > replaces the IP addresses in the TSr payloads . . . > it will thus send back traffic selectors having IPN1 and IP2 as their IP addresses . . . . . . As it seems there is no support for my alternative suggestion, I'm ok with this direction. > replaces the IP addresses in the TSr payloads . . . I think it's ok to change this to singular: "the IP address in the TSr payloads". Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Paul Hoffman To: Tero Kivinen , Scott C Moonen/Raleigh/IBM@IBMUS Cc: "ipsec@ietf.org" Date: 09/19/2009 06:40 PM Subject: Re: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP Here is the edited text. Please be sure it is still correct.
      Transport mode used with NAT Traversal requires special handling of the traffic selectors used in the IKEv2. The complete scenario looks like:
      | A |<---------->| B |<------->| | +------+ +------+ +------+ +------+ ]]>
      (Other scenarios are simplications of this complex case, so this discussion uses the complete scenario.) In this scenario, there are two address translating NATs: NAT A and NAT B. NAT A is dynamic NAT that maps the clients source address IP1 to IPN1. NAT B is static NAT configured so that connections coming to IPN2 address are mapped to the gateways adddress IP2, that is, IPN2 destination address is mapped to IP2. This allows the client to connect to a server by connecting to the IPN2. NAT B does not necessarely need to be a static NAT, but the client needs to know how to connect to the server, and it can only do that if it somehow knows the outer address of the NAT B, that is, the IPN2 address. If NAT B is a static NAT, then its address can be configured to the client's configuration. Other options would be find it using some other protocol (like DNS), but those are outside of scope of IKEv2. In this scenario, both client and server are configured to use transport mode for the traffic originating from the client node and destined to the server. When the client starts creating the IKEv2 SA and Child SA for sending traffic to the server, it has a triggering packet with source IP address of IP1, and a destination IP address of IPN2. Its PAD and SPD needs to have configuration matching those addresses (or wildcard entries covering them). Because this is transport mode, it uses exactly same addresses as the traffic selectors and outer IP address of the IKE packets. For transport mode, it MUST use exactly one IP address in the TSi and TSr payloads. It can have multiple traffic selectors if it has, for example, multiple port ranges that it wants to negotiate, but all TSi entries must use IP1-IP1 range as the IP addresses, and all TSr entries must have the IPN2-IPN2 range as IP the addresses. The first traffic selector of TSi and TSr SHOULD have very specific traffic selectors including protocol and port numbers from the packet triggering the request. NAT A will then replace the source address of the IKE packet from IP1 to IPN2, and NAT B will replace the destination address of the IKE packet from IPN2 to IP2, so when the packet arrives to the server it will still have the exactly same traffic selectors which were sent by the client, but the IP address of the IKE packet has been replaced to IPN1 and IP2. When the server receives this packet, it normally looks the PAD based on the ID and then searches the SPD based on the traffic selectors. Because IP1 does not really mean anything to the server (it is the address client has behind the NAT), it is useless to do lookup based on that if transport mode is used. On the other hand, the server cannot know whether transport mode is allowed by its policy before it finds the matching SPD entry. In this case, the server should first check that as initiator requested transport mode and do address substitution on the traffic selectors. It needs to first store the old traffic selector IP addresses to be used later for the incremental checksum fixup (the IP address in the TSi can be stored as the real source address and the IP address in the TSr can be stored as the real destination address). After that, if the other end was detected as being behind a NAT, the server replaces the IP address in TSi payloads with the IP address obtained from the source address of the IKE packet received (that is, it replaces IP1 in TSi with IPN1). If the server's end was detected to be behind NAT, it replaces the IP addresses in the TSr payloads with the IP address obtained from the destination address of the IKE packet received (thta is, it replaces IPN2 in TSr with IP2). After this address substitution, both the traffic selectors and the IKE UDP source/destination addresses look the same, and the server does SPD lookup based on those new traffic selectors. If an entry is found and it allows transport mode, then that entry is used. If an entry is found but it does not allow transport mode, then the server MAY undo the address substitution and redo the SPD lookup using the original traffic selectors. If the second lookup succeeds, the server will create an SA in tunnel mode using real traffic selectors sent by the other end. This address substitution in transport mode is needed because the SPD is looked up using the addresses that will be seen by the local host. This also will make sure the SAD entries for the tunnel exit checks and return packets is added using the addresses as seen by the local operating system stack. The most common case is that the server's SPD will contain wildcard entries matching any addresses, but this allows also making different SPD entries, for example, for different known NATs outer addresses. After the SPD lookup, the server will do traffic selector narrowing based on the SPD entry it found. It will again use the already-substituted traffic selectors, and it will thus send back traffic selectors having IPN1 and IP2 as their IP addresses; it can still narrow down the protocol number or port ranges used by the traffic selectors. The SAD entry created for the Child SA will have the addresses as seen by the server, namely IPN1 and IP2. When the client receives the server's reply to the Child SA, it will do similar processing. If the transport mode SA was created, the client can store the original returned traffic selectors as real source and destination addresses. It will replace the IP addresses in the traffic selectors with the ones from the IP header of the IKE packet: it will replace IPN1 with IP1 and IP2 with IPN2. Then it will use those traffic selectors when verifying the SA against sent traffic selectors, and when installing the SAD entry. A summary of the rules for NAT-traversal in transport mode is:
      --Paul Hoffman, Director --VPN Consortium --=_alternative 005A00ED85257638_= Content-Type: text/html; charset="US-ASCII"
      Paul,

      > NAT B does not necessarely need

      s/necessarely/necessarily/

      > replaces the IP address in TSi payloads . . .
      > replaces the IP addresses in the TSr payloads . . .
      > it will thus send back traffic selectors having IPN1 and IP2 as their IP addresses . . .
      . . .
      As it seems there is no support for my alternative suggestion, I'm ok with this direction.

      > replaces the IP addresses in the TSr payloads . . .

      I think it's ok to change this to singular: "the IP address in the TSr payloads".


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


      From: Paul Hoffman <paul.hoffman@vpnc.org>
      To: Tero Kivinen <kivinen@iki.fi>, Scott C Moonen/Raleigh/IBM@IBMUS
      Cc: "ipsec@ietf.org" <ipsec@ietf.org>
      Date: 09/19/2009 06:40 PM
      Subject: Re: [IPsec] #28: Obtaining src/dest IP addresses for  UDP-encapsulated transport mode ESP




      Here is the edited text. Please be sure it is still correct.

      <section anchor='sect-2.23.1' title='Transport Mode NAT Traversal'>

      <t>Transport mode used with NAT Traversal requires special handling
      of the traffic selectors used in the IKEv2. The complete scenario
      looks like:</t>

      <figure><artwork><![CDATA[
      +------+        +------+            +------+         +------+
      |Client| IP1    | NAT  | IPN1  IPN2 | NAT  |     IP2 |Server|
      |node  |<------>|  A   |<---------->|  B   |<------->|      |
      +------+        +------+            +------+         +------+
      ]]></artwork></figure>

      <t>(Other scenarios are simplications of this complex case, so this
      discussion uses the complete scenario.)</t>

      <t>In this scenario, there are two address translating NATs: NAT A
      and NAT B. NAT A is dynamic NAT that maps the clients source address
      IP1 to IPN1. NAT B is static NAT configured so that connections
      coming to IPN2 address are mapped to the gateways adddress IP2, that
      is, IPN2 destination address is mapped to IP2. This allows the client
      to connect to a server by connecting to the IPN2. NAT B does not
      necessarely need to be a static NAT, but the client needs to know how
      to connect to the server, and it can only do that if it somehow knows
      the outer address of the NAT B, that is, the IPN2 address. If NAT B
      is a static NAT, then its address can be configured to the client's
      configuration. Other options would be find it using some other
      protocol (like DNS), but those are outside of scope of IKEv2.</t>

      <t>In this scenario, both client and server are configured to use
      transport mode for the traffic originating from the client node and
      destined to the server.<t>

      <t>When the client starts creating the IKEv2 SA and Child SA for
      sending traffic to the server, it has a triggering packet with source
      IP address of IP1, and a destination IP address of IPN2. Its PAD and
      SPD needs to have configuration matching those addresses (or wildcard
      entries covering them). Because this is transport mode, it uses
      exactly same addresses as the traffic selectors and outer IP address
      of the IKE packets. For transport mode, it MUST use exactly one IP
      address in the TSi and TSr payloads. It can have multiple traffic
      selectors if it has, for example, multiple port ranges that it wants
      to negotiate, but all TSi entries must use IP1-IP1 range as the IP
      addresses, and all TSr entries must have the IPN2-IPN2 range as IP
      the addresses. The first traffic selector of TSi and TSr SHOULD have
      very specific traffic selectors including protocol and port numbers
      from the packet triggering the request.</t>

      <t>NAT A will then replace the source address of the IKE packet from
      IP1 to IPN2, and NAT B will replace the destination address of the IKE
      packet from IPN2 to IP2, so when the packet arrives to the server it
      will still have the exactly same traffic selectors which were sent by
      the client, but the IP address of the IKE packet has been replaced to
      IPN1 and IP2.</t>

      <t>When the server receives this packet, it normally looks the PAD
      based on the ID and then searches the SPD based on the traffic
      selectors. Because IP1 does not really mean anything to the server
      (it is the address client has behind the NAT), it is useless to do
      lookup based on that if transport mode is used. On the other hand,
      the server cannot know whether transport mode is allowed by its
      policy before it finds the matching SPD entry.</t>

      <t>In this case, the server should first check that as initiator
      requested transport mode and do address substitution on the traffic
      selectors. It needs to first store the old traffic selector IP
      addresses to be used later for the incremental checksum fixup (the IP
      address in the TSi can be stored as the real source address and the
      IP address in the TSr can be stored as the real destination address).
      After that, if the other end was detected as being behind a NAT, the
      server replaces the IP address in TSi payloads with the IP address
      obtained from the source address of the IKE packet received (that is,
      it replaces IP1 in TSi with IPN1). If the server's end was detected
      to be behind NAT, it replaces the IP addresses in the TSr payloads
      with the IP address obtained from the destination address of the IKE
      packet received (thta is, it replaces IPN2 in TSr with IP2).</t>

      <t>After this address substitution, both the traffic selectors and
      the IKE UDP source/destination addresses look the same, and the
      server does SPD lookup based on those new traffic selectors. If an
      entry is found and it allows transport mode, then that entry is used.
      If an entry is found but it does not allow transport mode, then the
      server MAY undo the address substitution and redo the SPD lookup
      using the original traffic selectors. If the second lookup succeeds,
      the server will create an SA in tunnel mode using real traffic
      selectors sent by the other end.</t>

      <t>This address substitution in transport mode is needed because the
      SPD is looked up using the addresses that will be seen by the local
      host. This also will make sure the SAD entries for the tunnel exit
      checks and return packets is added using the addresses as seen by the
      local operating system stack.</t>

      <t>The most common case is that the server's SPD will contain
      wildcard entries matching any addresses, but this allows also making
      different SPD entries, for example, for different known NATs outer
      addresses.</t>

      <t>After the SPD lookup, the server will do traffic selector
      narrowing based on the SPD entry it found. It will again use the
      already-substituted traffic selectors, and it will thus send back
      traffic selectors having IPN1 and IP2 as their IP addresses; it can
      still narrow down the protocol number or port ranges used by the
      traffic selectors. The SAD entry created for the Child SA will have
      the addresses as seen by the server, namely IPN1 and IP2.</t>

      <t>When the client receives the server's reply to the Child SA, it
      will do similar processing. If the transport mode SA was created, the
      client can store the original returned traffic selectors as real
      source and destination addresses. It will replace the IP addresses in
      the traffic selectors with the ones from the IP header of the IKE
      packet: it will replace IPN1 with IP1 and IP2 with IPN2. Then it will
      use those traffic selectors when verifying the SA against sent
      traffic selectors, and when installing the SAD entry.</t>

      <t>A summary of the rules for NAT-traversal in transport mode is:</t>

      <figure><artwork><![CDATA[
      For the client proposing transport mode:

      - The TSi entries MUST have exactly one IP address, and that MUST
       match the source address of the IKE SA.

      - The TSr entries MUST have exactly one IP address, and that MUST
       match the destination address of the IKE SA.

      - The first TSi and TSr traffic selectors SHOULD have very specific
       traffic selectors including protocol and port numbers from the
       packet triggering the request.

      - There MAY be multiple TSi and TSr entries.

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

       - Store the original traffic selectors as the real source and
         destination address.

       - If the server is behind a NAT, substitute the IP address in the
         TSr  entries with the remote address of the IKE SA.

       - If the client is behind a NAT, substitute the IP address in the
          TSi entries with the local address of the IKE SA.

       - Do address substitution before using those traffic selectors
         for anything else other than storing original content of them.
         This includes verification that traffic selectors were narrowed
         correctly by other end, creation of the SAD entry, and so on.
      ]]></artwork></figure>

      <figure><artwork><![CDATA[
      For the responder, when transport mode is proposed by client:

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

      - If the client is behind a NAT, substitute the IP address in the
       TSi entries with the remote address of the IKE SA.

      - If the server is behind a NAT substitute the IP address in the
       TSr entries with the local address of the IKE SA.

      - Do PAD and SPD lookup using the ID and substituted traffic
       selectors.

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

      - However, if a transport mode SPD entry was found, do normal
       traffic selection narrowing based on the substituted traffic
       selectors and SPD entry. Use the resulting traffic selectors when
       creating SAD entries, and when sending traffic selectors back to
       the client.
      ]]></artwork></figure>

      </section>

      --Paul Hoffman, Director
      --VPN Consortium

      --=_alternative 005A00ED85257638_=-- From smoonen@us.ibm.com Mon Sep 21 13:00:45 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 771223A6B16; Mon, 21 Sep 2009 13:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ROMiA4-fhsS; Mon, 21 Sep 2009 13:00:44 -0700 (PDT) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by core3.amsl.com (Postfix) with ESMTP id A0DC93A6B25; Mon, 21 Sep 2009 13:00:42 -0700 (PDT) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e36.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n8LJxhTs004202; Mon, 21 Sep 2009 13:59:43 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8LK1NVX115594; Mon, 21 Sep 2009 14:01:34 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n8LK1Kdx005320; Mon, 21 Sep 2009 14:01:22 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n8LK1KsM005222; Mon, 21 Sep 2009 14:01:20 -0600 In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328329@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328329@il-ex01.ad.checkpoint.com> To: Yaron Sheffer MIME-Version: 1.0 X-KeepSent: A6B9384B:FC24BEF7-85257638:0060BAF7; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 09/21/2009 04:01:04 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 09/21/2009 04:01:04 PM, Serialize complete at 09/21/2009 04:01:04 PM, S/MIME Sign failed at 09/21/2009 04:01:04 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V851_08302009|August 30, 2009) at 09/21/2009 14:01:19, Serialize complete at 09/21/2009 14:01:19 Message-ID: Date: Mon, 21 Sep 2009 16:01:18 -0400 Content-Type: multipart/alternative; boundary="=_alternative 006DF62D85257638_=" Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org Subject: Re: [IPsec] WG last call: draft-ietf-ipsecme-esp-null-heuristics-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 20:00:45 -0000 This is a multipart message in MIME format. --=_alternative 006DF62D85257638_= Content-Type: text/plain; charset="US-ASCII" Here are my comments: - Is Section 1.2 necessary? None of these terms are used in this fashion in this document. - page 8, "sees an new" => "sees a new" - page 8, "in the Section 8" => "in Section 8" - page 12, excessive space in "i.e. UDP encapsulated"; perhaps replace with comma. - page 16, "with a new SA which needs heuristics" => "produces a new SA which needs heuristics and will benefit from the existing flows". - page 21, "things what needs" => "things that need" - page 21, suggest "optimize things" => "optimize steps", just to reduce repetition - page 21, "For example implementation" => "For example, implementations" - page 25, I believe that DES-MAC has a 64-bit ICV (FIPS 113) and KPDK has a 128-bit ICV (RFC 1828). - page 30, for tunnel mode checks it might be worth just mentioning that tunnel mode is inferred by protocol 4 for IPv4 and protocol 41 for IPv6. At a high level the pseudocode seems ok to me, although there is a lot of mutual interaction between these functions due to the global state, so it can certainly benefit from as much scrutiny as possible. Overall I approve of this document. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Yaron Sheffer To: "ipsec@ietf.org" Date: 09/17/2009 04:28 PM Subject: [IPsec] WG last call: draft-ietf-ipsecme-esp-null-heuristics-01 This is to begin a 2 week working group last call for draft-ietf-ipsecme-esp-null-heuristics-01. The target status for this document is Informational. Please send your comments to the ipsec list by Oct. 1, 2009, as follow-ups to this message. Note that this document has had very little review until now. We will only progress it as a WG document if we have at least 3 non-editor, non-WG chair reviewers who have read it and approve of it. And yes, this means the pseudocode, too. There has been strong support of ESP-null detection, so this document is likely to be widely implemented. Your review will mean a lot to the technical quality of this document. Please clearly indicate the position of any issue in the Internet Draft, and if possible provide alternative text. Please also indicate the nature or severity of the error or correction, e.g. major technical, minor technical, nit, so that we can quickly judge the extent of problems with the document. The document can be accessed here: http://tools.ietf.org/html/draft-ietf-ipsecme-esp-null-heuristics-01 Thanks, Yaron Email secured by Check Point Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 006DF62D85257638_= Content-Type: text/html; charset="US-ASCII"
      Here are my comments:

      - Is Section 1.2 necessary?  None of these terms are used in this fashion in this document.
      - page 8, "sees an new" => "sees a new"
      - page 8, "in the Section 8" => "in Section 8"
      - page 12, excessive space in "i.e.  UDP encapsulated"; perhaps replace with comma.
      - page 16, "with a new SA which needs heuristics" => "produces a new SA which needs heuristics and will benefit from the existing flows".
      - page 21, "things what needs" => "things that need"
      - page 21, suggest "optimize things" => "optimize steps", just to reduce repetition
      - page 21, "For example implementation" => "For example, implementations"
      - page 25, I believe that DES-MAC has a 64-bit ICV (FIPS 113) and KPDK has a 128-bit ICV (RFC 1828).
      - page 30, for tunnel mode checks it might be worth just mentioning that tunnel mode is inferred by protocol 4 for IPv4 and protocol 41 for IPv6.

      At a high level the pseudocode seems ok to me, although there is a lot of mutual interaction between these functions due to the global state, so it can certainly benefit from as much scrutiny as possible.

      Overall I approve of this document.


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


      From: Yaron Sheffer <yaronf@checkpoint.com>
      To: "ipsec@ietf.org" <ipsec@ietf.org>
      Date: 09/17/2009 04:28 PM
      Subject: [IPsec] WG last call: draft-ietf-ipsecme-esp-null-heuristics-01




      This is to begin a 2 week working group last call for draft-ietf-ipsecme-esp-null-heuristics-01. The target status for this document is Informational.

      Please send your comments to the ipsec list by Oct. 1, 2009, as follow-ups to this message.

      Note that this document has had very little review until now. We will only progress it as a WG document if we have at least 3 non-editor, non-WG chair reviewers who have read it and approve of it. And yes, this means the pseudocode, too. There has been strong support of ESP-null detection, so this document is likely to be widely implemented. Your review will mean a lot to the technical quality of this document.

      Please clearly indicate the position of any issue in the Internet Draft, and if possible provide alternative text. Please also indicate the nature or severity of the error or correction, e.g. major technical, minor technical, nit, so that we can quickly judge the extent of problems with the document.

      The document can be accessed here:
      http://tools.ietf.org/html/draft-ietf-ipsecme-esp-null-heuristics-01

      Thanks,
                  Yaron


      Email secured by Check Point

      Email secured by Check Point
      _______________________________________________
      IPsec mailing list
      IPsec@ietf.org
      https://www.ietf.org/mailman/listinfo/ipsec

      --=_alternative 006DF62D85257638_=-- From wierbows@us.ibm.com Mon Sep 21 19:52:11 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ACCB3A6934 for ; Mon, 21 Sep 2009 19:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.775 X-Spam-Level: X-Spam-Status: No, score=-5.775 tagged_above=-999 required=5 tests=[AWL=0.823, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HYGCT10VbnH for ; Mon, 21 Sep 2009 19:52:10 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by core3.amsl.com (Postfix) with ESMTP id 079153A682E for ; Mon, 21 Sep 2009 19:52:09 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n8M2vemK030211 for ; Mon, 21 Sep 2009 22:57:40 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8M2r0dP160508 for ; Mon, 21 Sep 2009 22:53:02 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n8M2r0rU028499 for ; Mon, 21 Sep 2009 22:53:00 -0400 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n8M2r08O028493 for ; Mon, 21 Sep 2009 22:53:00 -0400 In-Reply-To: <19127.28334.472030.873072@fireball.kivinen.iki.fi> References: <19127.28334.472030.873072@fireball.kivinen.iki.fi> X-KeepSent: 6B25FFA7:4DF42AEF-85257639:000C7E89; type=4; name=$KeepSent To: IPsecme WG X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: David Wierbowski Date: Mon, 21 Sep 2009 22:52:58 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 09/21/2009 22:52:59 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBFCAADF9FF8198f9e8a93df938690918c0ABBFCAADF9FF819" Content-Disposition: inline Subject: Re: [IPsec] #22 Simultaneous IKE SA rekey text X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 02:52:11 -0000 --0__=0ABBFCAADF9FF8198f9e8a93df938690918c0ABBFCAADF9FF819 Content-type: text/plain; charset=US-ASCII >Tero states: > The basic case is where both ends notice this is simultaneous > rekey, and can delay moving of the CHILD_SAs until they know which > one wins. The more complex case happens where there is dropped > packets and one end does not detect simultaneous rekey until it has > already finished its rekey and moved CHILD_SAs. As the basic case > can be processed in similar way as the more complex case, this > example here only covers the more complex case. > > In this case host A and B has IKE SA up and running and both ends > decide to rekey it: > > Host A Host B > ----------- ----------- > send req1: ... Ni1 ... --> > <-- send req2: ... Ni2 ... > --> recv req1 > > Now if the req2 is dropped for some reason, the Host A does not > know there is simultaneous rekey, but host B will know it when it > receives the req1. It will process the req1, but it cannot yet move > the CHILD_SAs as it does not know the Nr2. It postpones the > CHILD_SA moving until the req2/resp2 rekey finishes. It sends resp1 > back to the Host A to answer req1 IKE SA rekey: > > <-- send resp1: ... Nr1 ... > recv resp1 <-- > > Now the Host A has finished the IKE SA rekey without knowing it was > simultaneous rekey. It will move the CHILD_SAs from the old IKE SA > to new rekeyed IKE SA A. It MUST NOT immediately delete the old IKE > SA, but instead wait for some time to see in case there was > simultaneous rekey ongoing or not. When Host B retransmits its req2 > the Host A will notice that there was simultaneous rekey going on, > and it will send normal reply to that: > I see no reason why Host A MUST NOT immediately delete the old IKE SA. In fact I think is SHOULD immediately delete the old IKE SA. By this I mean it should mark the SA as being deleted, it should send a delete payload, and it should refuse to create any additional SAs. > recv req1 <-- > send resp2: ... Nr2 ... --> Host A should respond with NO_ADDITIONAL SAS in this case because Host A did not detect a simultaneous rekey and should have immediately deleted the original IKE_SA. > --> recv resp2 Host B should receive the NO_ADDITIONAL_SAS notification and it should realize that Host A did not detect the simultaneous rekey. Host B should now move the child SAs from the original IKE SA to the one initiated by Host A. In reality, it's more likely that Host B has already received Host A's delete notification and will ignore the response. > > After sending that reply that also creates the second IKE SA B in > Host A and then Host A can check all the four nonces and see which > of them is lowest, and it will then move all the CHILD_SAs to that > new IKE SA having lowest nonce unless they were already there (i.e. > if the IKE SA A had lowest nonce, Host A has already moved the > CHILD_SAs there, if IKE SA B had lowest nonce, host A needs to move > CHILD_SAs from the IKE SA A to this IKE SA B, and start timer to > delete IKE SA A). Why do you want to mandate all this complication for a case that will occur infrequently? You are impacting every IKE_SA rekey, not just the simultaneous case. I doubt that anybody delays the delete of an IKE_SA on a rekey based on RFC 4306. At the very least I'm sure there are implementations that do not delay the delete. Requiring this delay is a protocol change and one that I do not see the need for. If Host A deletes the IKE_SA immediately then either Host B will see the delete and be able to infer that there is no simultaneous rekey or Host B may also get a NO_ADDITIONAL SAS notification and be able to infer that there is no simultaneous rekey. > > When Host B receives the resp2 it knows that simultaneous rekey is > finished, and it can check the nonces and move CHILD_SAs from the > original IKE SA to either IKE SA A or B depending which had lowest > nonce. If it was IKE SA A, the host B needs to start timer to > delete IKE SA B. > > Depending who created the winning rekeyed IKE SA decides who is > going to delete the old IKE SA, i.e. the one who created the > winning IKE SA also cleans up the old IKE SA. > > Note, that Host B processing is identical to the basic case where > host notices during processing that there is simultaneous rekey > ongoing. > > In case the Host A didn't wait for long enough before start > deleting old IKE SA there can be case where host B is still trying > to retransmit its req2 in the old IKE SA when it receives the > delete to the old IKE SA. In that case it knows that Host A has NOT > received any of its requests, thus is unaware that there is > simultaneous rekey ongoing, thus it can safely stop retrasnmitting > req2, and allow old IKE SA to be deleted, and move all CHILD_SAs to > the IKE SA A created by Host A. And it can do the same when it immediately gets a delete for the original IKE SA or a NO_ADDITIONAL_SAS notification. If you want to defer the delete of the IKE SA that's fine with me. I just don't want to have to do that. I see no value in doing it, especially given the text above indicate one has to handle the delete case anyway. Dave Wierbowski --0__=0ABBFCAADF9FF8198f9e8a93df938690918c0ABBFCAADF9FF819 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

      >Tero states:

      >  The basic case is where both ends notice this is simultaneous
      >  rekey, and can delay moving of the CHILD_SAs until they know which
      >  one wins. The more complex case happens where there is dropped
      >  packets and one end does not detect simultaneous rekey until it has
      >  already finished its rekey and moved CHILD_SAs. As the basic case
      >  can be processed in similar way as the more complex case, this
      >  example here only covers the more complex case.
      >
      >  In this case host A and B has IKE SA up and running and both ends
      >  decide to rekey it:
      >
      >      Host A         Host B
      >    -----------                      -----------
      >    send req1: ... Ni1  ... -->
      >            <-- send req2: ... Ni2 ...
      >             --> recv req1
      >
      >  Now if the req2 is dropped for some reason, the Host A does not
      >  know there is simultaneous rekey, but host B will know it when it
      >  receives the req1. It will process the req1, but it cannot yet move
      >  the CHILD_SAs as it does not know the Nr2. It postpones the
      >  CHILD_SA moving until the req2/resp2 rekey finishes. It sends resp1
      >  back to the Host A to answer req1 IKE SA rekey:
      >
      >            <-- send resp1: ... Nr1 ...
      >    recv resp1 <--
      >
      >  Now the Host A has finished the IKE SA rekey without knowing it was
      >  simultaneous rekey. It will move the CHILD_SAs from the old IKE SA
      >  to new rekeyed IKE SA A. It MUST NOT immediately delete the old IKE
      >  SA, but instead wait for some time to see in case there was
      >  simultaneous rekey ongoing or not. When Host B retransmits its req2
      >  the Host A will notice that there was simultaneous rekey going on,
      >  and it will send normal reply to that:
      >
      I see no reason why Host A MUST NOT immediately delete the old IKE SA.
      In fact I think is SHOULD immediately delete the old IKE SA.  By this
      I mean it should mark the SA as being deleted, it should send a delete
      payload, and it should refuse to create any additional SAs.  
      >    recv req1 <--
      >    send resp2: ... Nr2 ... -->
      Host A should respond with NO_ADDITIONAL SAS in this case because
      Host A did not detect a simultaneous rekey and should have immediately
      deleted the original IKE_SA.
      >             --> recv resp2
      Host B should receive the NO_ADDITIONAL_SAS notification and it should
      realize that Host A did not detect the simultaneous rekey.  Host B
      should now move the child SAs from the original IKE SA to the one
      initiated by Host A.  In reality, it's more likely that Host B has
      already received Host A's delete notification and will ignore the
      response.
      >
      >  After sending that reply that also creates the second IKE SA B in
      >  Host A and then Host A can check all the four nonces and see which
      >  of them is lowest, and it will then move all the CHILD_SAs to that
      >  new IKE SA having lowest nonce unless they were already there (i.e.
      >  if the IKE SA A had lowest nonce, Host A has already moved the
      >  CHILD_SAs there, if IKE SA B had lowest nonce, host A needs to move
      >  CHILD_SAs from the IKE SA A to this IKE SA B, and start timer to
      >  delete IKE SA A).
      Why do you want to mandate all this complication for a case that will
      occur infrequently?  You are impacting every IKE_SA rekey, not just
      the simultaneous case.  I doubt that anybody delays the delete of an
      IKE_SA on a rekey based on RFC 4306.  At the very least I'm sure there
      are implementations that do not delay the delete.  Requiring this
      delay is a protocol change and one that I do not see the need for.  

      If Host A deletes the IKE_SA immediately then either Host B will see
      the delete and be able to infer that there is no simultaneous rekey or
      Host B may also get a NO_ADDITIONAL SAS notification and be able to
      infer that there is no simultaneous rekey.
      >
      >  When Host B receives the resp2 it knows that simultaneous rekey is
      >  finished, and it can check the nonces and move CHILD_SAs from the
      >  original IKE SA to either IKE SA A or B depending which had lowest
      >  nonce. If it was IKE SA A, the host B needs to start timer to
      >  delete IKE SA B.
      >
      >  Depending who created the winning rekeyed IKE SA decides who is
      >  going to delete the old IKE SA, i.e. the one who created the
      >  winning IKE SA also cleans up the old IKE SA.
      >
      >  Note, that Host B processing is identical to the basic case where
      >  host notices during processing that there is simultaneous rekey
      >  ongoing.
      >
      >  In case the Host A didn't wait for long enough before start
      >  deleting old IKE SA there can be case where host B is still trying
      >  to retransmit its req2 in the old IKE SA when it receives the
      >  delete to the old IKE SA. In that case it knows that Host A has NOT
      >  received any of its requests, thus is unaware that there is
      >  simultaneous rekey ongoing, thus it can safely stop retrasnmitting
      >  req2, and allow old IKE SA to be deleted, and move all CHILD_SAs to
      >  the IKE SA A created by Host A.
      And it can do the same when it immediately gets a delete for the
      original IKE SA or a NO_ADDITIONAL_SAS notification.

      If you want to defer the delete of the IKE SA that's fine with me.  I
      just don't want to have to do that.  I see no value in doing it,
      especially given the text above indicate one has to handle the delete
      case anyway.

      Dave Wierbowski


      --0__=0ABBFCAADF9FF8198f9e8a93df938690918c0ABBFCAADF9FF819-- From mcins1@gmail.com Mon Sep 21 23:26:03 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B67813A685C for ; Mon, 21 Sep 2009 23:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnDz5Al86fqO for ; Mon, 21 Sep 2009 23:26:02 -0700 (PDT) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id A7F453A6891 for ; Mon, 21 Sep 2009 23:26:01 -0700 (PDT) Received: by yxe30 with SMTP id 30so4588980yxe.29 for ; Mon, 21 Sep 2009 23:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type; bh=a/Qipy/Oe2p/1icmPBW0Q+vFAyx+QHIiK/WY+77DsMw=; b=xzJmLgXOWkRKUklBIbU8tYedW8GOy+T5+p+yYN3O/lh8GQE77MJ70Wck7qW2TiSbU6 K9OX4dsTQHhhRwLbWBVGrPTD4/hKm8eWeOeBXoFPZzTZUj9Zwa7RCh/Tp4+X4IOmw4gy A6rakcpDTjZLI9RwQilyIT4/TvHtq9zhkSP9Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=IfrrNLpO62xIzVY8vJSAB8PIk1vyW+GUPouzCQz5algRRYthlz5yQvuW0Wbq8YnW3c x9xD2Ah6aldmPbm0ZXL7ZOsxWtlUaKIEjARE6atC8OwJwOxnrGsSLkduVmE4MVtOLjro vuocFiX63C+wdSHSNYUcmCR1iT8LZq6H3laD0= MIME-Version: 1.0 Received: by 10.91.122.11 with SMTP id z11mr378667agm.111.1253600822103; Mon, 21 Sep 2009 23:27:02 -0700 (PDT) In-Reply-To: <99043b4a0909212326r220791a2rb0c719212862c3e2@mail.gmail.com> References: <19127.28334.472030.873072@fireball.kivinen.iki.fi> <99043b4a0909212326r220791a2rb0c719212862c3e2@mail.gmail.com> From: Matthew Cini Sarreo Date: Tue, 22 Sep 2009 08:26:42 +0200 Message-ID: <99043b4a0909212326i4c8abebbg1c458b24a6157023@mail.gmail.com> To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=0016e646a326b10f31047424af39 Subject: Re: [IPsec] #22 Simultaneous IKE SA rekey text X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 06:26:03 -0000 --0016e646a326b10f31047424af39 Content-Type: text/plain; charset=ISO-8859-1 I agree with Dave Wierbowsk, deletion will still occur (for the old IKE SA) so deleting it while Host B is retransmitting (or waiting for some timer to retrasmit) seems to make most sense. Host B notices the delete payload (or NO_ADDITIONAL_SAS), stops retransmitting the request and go on as if there was only one rekeying requested (the one requested by Host A). I don't see a reason to delay the deletion. Regards, Matt 2009/9/22 Matthew Cini Sarreo > > I agree with Dave Wierbowsk, deletion will still occur (for the old IKE SA) > so deleting it while Host B is retransmitting (or waiting for some timer to > retrasmit) seems to make most sense. Host B notices the delete payload (or > NO_ADDITIONAL_SAS), stops retransmitting the request and go on as if there > was only one rekeying requested (the one requested by Host A). I don't see a > reason to delay the deletion. > > Regards, > Matt > > 2009/9/22 David Wierbowski > >> >Tero states: >> >> >> > The basic case is where both ends notice this is simultaneous >> > rekey, and can delay moving of the CHILD_SAs until they know which >> > one wins. The more complex case happens where there is dropped >> > packets and one end does not detect simultaneous rekey until it has >> > already finished its rekey and moved CHILD_SAs. As the basic case >> > can be processed in similar way as the more complex case, this >> > example here only covers the more complex case. >> > >> > In this case host A and B has IKE SA up and running and both ends >> > decide to rekey it: >> > >> > Host A Host B >> > ----------- ----------- >> > send req1: ... Ni1 ... --> >> > <-- send req2: ... Ni2 ... >> > --> recv req1 >> > >> > Now if the req2 is dropped for some reason, the Host A does not >> > know there is simultaneous rekey, but host B will know it when it >> > receives the req1. It will process the req1, but it cannot yet move >> > the CHILD_SAs as it does not know the Nr2. It postpones the >> > CHILD_SA moving until the req2/resp2 rekey finishes. It sends resp1 >> > back to the Host A to answer req1 IKE SA rekey: >> > >> > <-- send resp1: ... Nr1 ... >> > recv resp1 <-- >> > >> > Now the Host A has finished the IKE SA rekey without knowing it was >> > simultaneous rekey. It will move the CHILD_SAs from the old IKE SA >> > to new rekeyed IKE SA A. It MUST NOT immediately delete the old IKE >> > SA, but instead wait for some time to see in case there was >> > simultaneous rekey ongoing or not. When Host B retransmits its req2 >> > the Host A will notice that there was simultaneous rekey going on, >> > and it will send normal reply to that: >> > >> I see no reason why Host A MUST NOT immediately delete the old IKE SA. >> In fact I think is SHOULD immediately delete the old IKE SA. By this >> I mean it should mark the SA as being deleted, it should send a delete >> payload, and it should refuse to create any additional SAs. >> > recv req1 <-- >> > send resp2: ... Nr2 ... --> >> Host A should respond with NO_ADDITIONAL SAS in this case because >> Host A did not detect a simultaneous rekey and should have immediately >> deleted the original IKE_SA. >> > --> recv resp2 >> Host B should receive the NO_ADDITIONAL_SAS notification and it should >> realize that Host A did not detect the simultaneous rekey. Host B >> should now move the child SAs from the original IKE SA to the one >> initiated by Host A. In reality, it's more likely that Host B has >> already received Host A's delete notification and will ignore the >> response. >> > >> > After sending that reply that also creates the second IKE SA B in >> > Host A and then Host A can check all the four nonces and see which >> > of them is lowest, and it will then move all the CHILD_SAs to that >> > new IKE SA having lowest nonce unless they were already there (i.e. >> > if the IKE SA A had lowest nonce, Host A has already moved the >> > CHILD_SAs there, if IKE SA B had lowest nonce, host A needs to move >> > CHILD_SAs from the IKE SA A to this IKE SA B, and start timer to >> > delete IKE SA A). >> Why do you want to mandate all this complication for a case that will >> occur infrequently? You are impacting every IKE_SA rekey, not just >> the simultaneous case. I doubt that anybody delays the delete of an >> IKE_SA on a rekey based on RFC 4306. At the very least I'm sure there >> are implementations that do not delay the delete. Requiring this >> delay is a protocol change and one that I do not see the need for. >> >> If Host A deletes the IKE_SA immediately then either Host B will see >> the delete and be able to infer that there is no simultaneous rekey or >> Host B may also get a NO_ADDITIONAL SAS notification and be able to >> infer that there is no simultaneous rekey. >> > >> > When Host B receives the resp2 it knows that simultaneous rekey is >> > finished, and it can check the nonces and move CHILD_SAs from the >> > original IKE SA to either IKE SA A or B depending which had lowest >> > nonce. If it was IKE SA A, the host B needs to start timer to >> > delete IKE SA B. >> > >> > Depending who created the winning rekeyed IKE SA decides who is >> > going to delete the old IKE SA, i.e. the one who created the >> > winning IKE SA also cleans up the old IKE SA. >> > >> > Note, that Host B processing is identical to the basic case where >> > host notices during processing that there is simultaneous rekey >> > ongoing. >> > >> > In case the Host A didn't wait for long enough before start >> > deleting old IKE SA there can be case where host B is still trying >> > to retransmit its req2 in the old IKE SA when it receives the >> > delete to the old IKE SA. In that case it knows that Host A has NOT >> > received any of its requests, thus is unaware that there is >> > simultaneous rekey ongoing, thus it can safely stop retrasnmitting >> > req2, and allow old IKE SA to be deleted, and move all CHILD_SAs to >> > the IKE SA A created by Host A. >> And it can do the same when it immediately gets a delete for the >> original IKE SA or a NO_ADDITIONAL_SAS notification. >> >> If you want to defer the delete of the IKE SA that's fine with me. I >> just don't want to have to do that. I see no value in doing it, >> especially given the text above indicate one has to handle the delete >> case anyway. >> >> Dave Wierbowski >> >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> > --0016e646a326b10f31047424af39 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
      I agree with Dave Wierbowsk, deletion will still occur (for the old IKE SA) so deleting it while Host B is retransmitting (or waiting for some timer to retrasmit) seems to make most sense. Host B notices the delete payload (or NO_ADDITIONAL_SAS), stops retransmitting the request and go on as if there was only one rekeying requested (the one requested by Host A). I don't see a reason to delay the deletion.

      Regards,
      Matt

      2009/9/22 Matthew Ci= ni Sarreo <mcins1@= gmail.com>

      I agree with Dave Wierbowsk, deletion will still occur (for the old IKE= SA) so deleting it while Host B is retransmitting (or waiting for some tim= er to retrasmit) seems to make most sense. Host B notices the delete payloa= d (or NO_ADDITIONAL_SAS), stops retransmitting the request and go on as if = there was only one rekeying requested (the one requested by Host A). I don&= #39;t see a reason to delay the deletion.

      Regards,
      Matt

      2009/9/22 David Wier= bowski <wierbows@us.ibm.com>

      >Tero states:



      > =A0The basic case is where both ends notice this is simultaneous
      > =A0rekey, and can delay moving of the CHILD_SAs until they know wh= ich
      > =A0one wins. The more complex case happens where there is dropped<= /tt>
      > =A0packets and one end does not detect simultaneous rekey until it= has
      > =A0already finished its rekey and moved CHILD_SAs. As the basic ca= se
      > =A0can be processed in similar way as the more complex case, this<= /tt>
      > =A0example here only covers the more complex case.
      >
      > =A0In this case host A and B has IKE SA up and running and both en= ds
      > =A0decide to rekey it:
      >
      > =A0 =A0 =A0Host A =A0 =A0 =A0 =A0 Host B
      > =A0 =A0----------- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0----= -------
      > =A0 =A0send req1: ... Ni1 =A0... -->
      > =A0 =A0 =A0 =A0 =A0 =A0<-- send req2: ... Ni2 ...<= br> > =A0 =A0 =A0 =A0 =A0 =A0 --> recv req1
      >
      > =A0Now if the req2 is dropped for some reason, the Host A does not=
      > =A0know there is simultaneous rekey, but host B will know it when = it
      > =A0receives the req1. It will process the req1, but it cannot yet = move
      > =A0the CHILD_SAs as it does not know the Nr2. It postpones the
      > =A0CHILD_SA moving until the req2/resp2 rekey finishes. It sends r= esp1
      > =A0back to the Host A to answer req1 IKE SA rekey:
      >
      > =A0 =A0 =A0 =A0 =A0 =A0<-- send resp1: ... Nr1 ...=
      > =A0 =A0recv resp1 <--
      >
      > =A0Now the Host A has finished the IKE SA rekey without knowing it= was
      > =A0simultaneous rekey. It will move the CHILD_SAs from the old IKE= SA
      > =A0to new rekeyed IKE SA A. It MUST NOT immediately delete the old= IKE
      > =A0SA, but instead wait for some time to see in case there was
      > =A0simultaneous rekey ongoing or not. When Host B retransmits its = req2
      > =A0the Host A will notice that there was simultaneous rekey going = on,
      > =A0and it will send normal reply to that:
      >
      I see no reason why Host A MUST NOT immediately delete the = old IKE SA.
      In fact I think is SHOULD immediately delete the old IKE SA. =A0By this=
      I mean it should mark the SA as being deleted, it should send a delete<= /tt>
      payload, and it should refuse to create any additional SAs. =A0
      > =A0 =A0recv req1 <--
      > =A0 =A0send resp2: ... Nr2 ... -->
      Host A should respond with NO_ADDITIONAL SAS in this case because=
      Host A did not detect a simultaneous rekey and should have immediately<= /tt>
      deleted the original IKE_SA.
      > =A0 =A0 =A0 =A0 =A0 =A0 --> recv resp2
      Host B should receive the NO_ADDITIONAL_SAS notification and it should<= /tt>
      realize that Host A did not detect the simultaneous rekey. =A0Host B
      should now move the child SAs from the original IKE SA to the one =
      initiated by Host A. =A0In reality, it's more likely that Host B ha= s
      already received Host A's delete notification and will ignore the <= /tt>
      response.

      >
      > =A0After sending that reply that also creates the second IKE SA B = in
      > =A0Host A and then Host A can check all the four nonces and see wh= ich
      > =A0of them is lowest, and it will then move all the CHILD_SAs to t= hat
      > =A0new IKE SA having lowest nonce unless they were already there (= i.e.
      > =A0if the IKE SA A had lowest nonce, Host A has already moved the<= /tt>
      > =A0CHILD_SAs there, if IKE SA B had lowest nonce, host A needs to = move
      > =A0CHILD_SAs from the IKE SA A to this IKE SA B, and start timer t= o
      > =A0delete IKE SA A).
      Why do you want to mandate all this complication for a case that = will
      occur infrequently? =A0You are impacting every IKE_SA rekey, not just
      the simultaneous case. =A0I doubt that anybody delays the delete of an =
      IKE_SA on a rekey based on RFC 4306. =A0At the very least I'm sure = there
      are implementations that do not delay the delete. =A0Requiring this
      delay is a protocol change and one that I do not see the need for. =A0<= /tt>

      If Host A deletes the IKE_SA immediately then either Host B will see
      the delete and be able to infer that there is no simultaneous rekey or =
      Host B may also get a NO_ADDITIONAL SAS notification and be able to
      infer that there is no simultaneous rekey.

      >
      > =A0When Host B receives the resp2 it knows that simultaneous rekey= is
      > =A0finished, and it can check the nonces and move CHILD_SAs from t= he
      > =A0original IKE SA to either IKE SA A or B depending which had low= est
      > =A0nonce. If it was IKE SA A, the host B needs to start timer to
      > =A0delete IKE SA B.
      >
      > =A0Depending who created the winning rekeyed IKE SA decides who is=
      > =A0going to delete the old IKE SA, i.e. the one who created the
      > =A0winning IKE SA also cleans up the old IKE SA.
      >
      > =A0Note, that Host B processing is identical to the basic case whe= re
      > =A0host notices during processing that there is simultaneous rekey=
      > =A0ongoing.
      >
      > =A0In case the Host A didn't wait for long enough before start=
      > =A0deleting old IKE SA there can be case where host B is still try= ing
      > =A0to retransmit its req2 in the old IKE SA when it receives the
      > =A0delete to the old IKE SA. In that case it knows that Host A has= NOT
      > =A0received any of its requests, thus is unaware that there is
      > =A0simultaneous rekey ongoing, thus it can safely stop retrasnmitt= ing
      > =A0req2, and allow old IKE SA to be deleted, and move all CHILD_SA= s to
      > =A0the IKE SA A created by Host A.
      And it can do the same when it immediately gets a delete for the =
      original IKE SA or a NO_ADDITIONAL_SAS notification.

      If you want to defer the delete of the IKE SA that's fine with me. = =A0I
      just don't want to have to do that. =A0I see no value in doing it, =
      especially given the text above indicate one has to handle the delete <= /tt>
      case anyway.

      Dave Wierbowski



      ___________________________________= ____________
      IPsec mailing list
      IPsec@ietf.org
      h= ttps://www.ietf.org/mailman/listinfo/ipsec



      --0016e646a326b10f31047424af39-- From mcins1@gmail.com Tue Sep 22 01:14:56 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A8FF3A696A for ; Tue, 22 Sep 2009 01:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYixQ0tX7boJ for ; Tue, 22 Sep 2009 01:14:55 -0700 (PDT) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 96B053A698E for ; Tue, 22 Sep 2009 01:14:54 -0700 (PDT) Received: by yxe30 with SMTP id 30so4659874yxe.29 for ; Tue, 22 Sep 2009 01:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type; bh=fm8pWarqaWVDySQOUOBvlyepUy4SrcGEImbHyOTzzVI=; b=I5MQdtceaM43nuTigUzJl8WEBhapTkxPHn0E+GO+6HSwvMSWWstzVgp3A8QjpD5hPK axA3QcRatzJELCzWR7ImCe7230s93gS45wxRAJqNfDKInZSYsGFZaLsVb/w9JXYziZED Myv3xGttxuWoxaNK4WKSMkNmfQQJwHIMMu1Ng= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=GhtTopykBq0+Ga6Ivuz7vwUvJMUXfCtYXssIZ8YDvGdyHNLD6IfPN0yVMUh+A44dtL +InDu+1rHbLesAhFJqr/Ijr5PuJRrAP49EpNbq1UxnxJ5FcqeYwo7P6pB09fGxSRb36c aPbqKrq2wQHTP+Iku7P78zEwcNlbPOqXy6xGM= MIME-Version: 1.0 Received: by 10.90.222.1 with SMTP id u1mr438755agg.103.1253607355140; Tue, 22 Sep 2009 01:15:55 -0700 (PDT) From: Matthew Cini Sarreo Date: Tue, 22 Sep 2009 10:15:35 +0200 Message-ID: <99043b4a0909220115r6b1a4decu36930c912b67895e@mail.gmail.com> To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=001636283e94174a0a047426358b Subject: [IPsec] IKEv2 NAT-T and Traffic Selectors X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 08:14:56 -0000 --001636283e94174a0a047426358b Content-Type: text/plain; charset=ISO-8859-1 Hello all, I have a question regarding proper choosing of traffic selectors in the situation where an initator is behind a NAT device. Let us use the following scenario: [initiator@A]--[NAT@X]----------------[responder@Y] Say A is 192.168.2.22, X is 192.168.3.5 and Y is 192.168.4.25, and all have a 24bit mask. The initiator policy requires traffic selectors for the whole subnet. In the case that A is initiating: TSi 192.168.2.0 to 192.168.2.255 TSr 192.168.4.0 to 192.168.4.255 Y does not know about 192.168.2.* but only about 192.168.3.*. So when it receives TSi it does not match with anything it knows about. Should the responder just accept these due to NAT being previously detected, or should the initiator send selectors with address A (TSi) and Y (TSr) and due to there being NAT the responder just copy them in the reply? Regards, Matt --001636283e94174a0a047426358b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello all,

      I have a question regarding proper choosing of traffic se= lectors in the situation where an initator is behind a NAT device. Let us u= se the following scenario:

      [initiator@A]--[NAT@X]----------------[re= sponder@Y]

      Say A is 192.168.2.22, X is 192.168.3.5 and Y is 192.168.4.25, and all = have a 24bit mask. The initiator policy requires traffic selectors for the = whole subnet. In the case that A is initiating:
      TSi 192.168.2.0 to 192.1= 68.2.255
      TSr 192.168.4.0 to 192.168.4.255

      Y does not know about 192.168.2.* but only about 192.168.3.*. So when i= t receives TSi it does not match with anything it knows about. Should the r= esponder just accept these due to NAT being previously detected, or should = the initiator send selectors with address A (TSi) and Y (TSr) and due to th= ere being NAT the responder just copy them in the reply?

      Regards,
      Matt


      --001636283e94174a0a047426358b-- From kivinen@iki.fi Tue Sep 22 01:52:03 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09B303A6907 for ; Tue, 22 Sep 2009 01:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 846VnvzSHI2J for ; Tue, 22 Sep 2009 01:52:02 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id CF8853A69CA for ; Tue, 22 Sep 2009 01:52:01 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n8M8r0Pv004286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Sep 2009 11:53:00 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n8M8qw6Q002097; Tue, 22 Sep 2009 11:52:58 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19128.36970.56148.968875@fireball.kivinen.iki.fi> Date: Tue, 22 Sep 2009 11:52:58 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B2@il-ex01.ad.checkpoint.com> <19093.12283.746864.474510@fireball.kivinen.iki.fi> <19094.16504.238846.676243@fireball.kivinen.iki.fi> <19095.50105.764201.796499@fireball.kivinen.iki.fi> <19127.26696.732531.959141@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 7 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 08:52:03 -0000 Paul Hoffman writes: > At 2:49 PM +0300 9/21/09, Tero Kivinen wrote: > >The IP addresses are also needed for the RFC 3948 incremental checksum > >fixup in udp encapsulation, not only for undoing the address > >substitution. > > As I said in my earlier note, I have removed all discussion of RFC > 3948 from this new text. RFC 3948 is for IKEv1 only, and is not > relevant here. RFC3947 is for IKEv1, RFC3948 is for IKEv1 and IKEv2. We do have references from RFC4306 to RFC3948 as that is the only document that describes how to do the UDP encapsulation. The problem is that it just says "peer's real source and distination address have been received according to [RFC3947], incrementally ..." and the longer description of original source and destination addresses are in the RFC3947 section 5.2. So we definately need reference to RFC3948 (we already have that as [UDPENCAPS]), but as its description of the addresses is so short my original text refered to longer text in RFC3947. On the other hand as this longer text is just background information and is not really needed for protocol reasons the ones implementing UDPENCAPS/RFC3948 can then see the reference to RFC3947 and read that as background information if they want to. > > > - If the client is behind a NAT, substitute the IP address in the > >> TSi entries with the remote address of the IKE SA. > >> > >> - If the server is behind a NAT substitute the IP address in the > >> TSr entries with the local address of the IKE SA. > > > >"Client" and "server" are ok here, but my original text used "other > >end" and "this end" at least in our implementation our NAT traversal > >detection does tests that way. I.e. it know whether this end and/or > >other end is behind nat and knows to enable suitable processing based > >on that (i.e. sending of RFC3948 keepalives etc). Client and server > >makes this bit more vpn roadwarrior case centric, compared to using > >"this end" and "other end". > > > >But either one is acceptable here. > > I changed to "client" and "server" to match the figure. Let me know > if this is not OK. As I said it is OK, I just explained my reasons to why I originally selected other words, but matching the ones in the figure is also good. -- kivinen@iki.fi From kivinen@iki.fi Tue Sep 22 02:04:47 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C04CB3A697A; Tue, 22 Sep 2009 02:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tB+QeyNQ0pFj; Tue, 22 Sep 2009 02:04:47 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 981EF3A6837; Tue, 22 Sep 2009 02:04:46 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n8M90cBH029261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Sep 2009 12:00:38 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n8M90bUJ003892; Tue, 22 Sep 2009 12:00:37 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19128.37429.438136.60314@fireball.kivinen.iki.fi> Date: Tue, 22 Sep 2009 12:00:37 +0300 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: <19109.286.34505.162897@fireball.kivinen.iki.fi> <73BF7996-C4FA-4442-B49D-DDD710CACA87@checkpoint.com> <19109.11583.348236.158555@fireball.kivinen.iki.fi> <19120.57165.424835.989773@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 6 min Cc: "ipsec@ietf.org WG" , ipsec-bounces@ietf.org, Yoav Nir , Paul Hoffman Subject: Re: [IPsec] Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 09:04:47 -0000 Scott C Moonen writes: > > NOTE FOR WG DISCUSSION: Having other payloads in the message is > > allowed but there are none suggested. One WG member mentioned the > > possibility of adding a DELETE payload when the error is sent in a > > separate INFORMATIONAL exchange. Do we want to allow such additional > > payloads that have operational semantics? > > I think you are asking specifically about the IKE_AUTH response? If so, I > agree that DELETE does not make sense in the IKE_AUTH response, and > N(AUTHENTICATION_FAILED), for example, is sufficient to delete the IKE SA. > I think we can forbid DELETE in the IKE_AUTH response. However, because > a separate INFORMATIONAL exchange cannot be definitively correlated to the > IKE_AUTH exchange, I'd like to retain the option of sending both DELETE > and N(AUTHENTICATION_FAILED) (for example) in a separate INFO exchange. You cannot really get AUTHENTICATION_FAILED in any other places than IKE_AUTH, as the text says: AUTHENTICATION_FAILED 24 Sent in the response to an IKE_AUTH message when for some reason the authentication failed. There is no associated data. Thus AUTHENTICATION_FAILED can always be correlated to the IKE_AUTH. On the other hand, I think it is clear that unless we explictly forbid other payloads you are free to add whatever payloads are normally allowed in INFORMATIONAL exchange anyways (i.e. notice, delete, vendori ID payloads, or even configuration payloads etc). Most likely the other end either processes those or ignores them, and if your error notify is fatal error like INVALID_SYNTAX then it really does not matter as the IKE SA will be deleted anyways. The IKEv2 does not really restrict what you can send in INFORMATIONAL exchange, but there are lots of cases where those simply do not make any sense. -- kivinen@iki.fi From kivinen@iki.fi Tue Sep 22 03:51:11 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AA583A6A0F; Tue, 22 Sep 2009 03:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMPu154BEx8i; Tue, 22 Sep 2009 03:51:10 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 5B4763A68D1; Tue, 22 Sep 2009 03:51:10 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n8MAl5Yd026366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Sep 2009 13:47:05 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n8MAl4eI011416; Tue, 22 Sep 2009 13:47:04 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19128.43815.988530.380031@fireball.kivinen.iki.fi> Date: Tue, 22 Sep 2009 13:47:03 +0300 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328329@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 17 min X-Total-Time: 86 min Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org Subject: Re: [IPsec] WG last call: draft-ietf-ipsecme-esp-null-heuristics-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 10:51:11 -0000 Scott C Moonen writes: > - Is Section 1.2 necessary? None of these terms are used in this fashion > in this document. True. Removed. > - page 8, "sees an new" => "sees a new" > - page 8, "in the Section 8" => "in Section 8" Fixed. > - page 12, excessive space in "i.e. UDP encapsulated"; perhaps replace > with comma. xml2rfc seems to want to put it there, but that is something that can be fixed in the final RFC editing phase. > - page 16, "with a new SA which needs heuristics" => "produces a new SA > which needs heuristics and will benefit from the existing flows". Fixed. > - page 21, "things what needs" => "things that need" > - page 21, suggest "optimize things" => "optimize steps", just to reduce > repetition > - page 21, "For example implementation" => "For example, implementations" Fixed. > - page 25, I believe that DES-MAC has a 64-bit ICV (FIPS 113) and KPDK has > a 128-bit ICV (RFC 1828). RFC4306 does not give reference to AUTH_DES_MAC, and the AUTH_KPDK_MD5 reference is to RFC1826 whic does not define it. I do not want to put those there as both of them are actually quite unsecure and should not be used anyways. Changed to: // AUTH_DES_MAC and AUTH_KPDK_MD5 are left out from // this document. > - page 30, for tunnel mode checks it might be worth just mentioning that > tunnel mode is inferred by protocol 4 for IPv4 and protocol 41 for IPv6. Changed it to be: // Tunnel mode checks (protocol 4 for IPv4 and protocol 41 for // IPv6) is also left out from here to make the document shorter. -- kivinen@iki.fi From kivinen@iki.fi Tue Sep 22 04:52:49 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BC7F3A692F for ; Tue, 22 Sep 2009 04:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qxz3w3P0re5U for ; Tue, 22 Sep 2009 04:52:48 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id E700C3A696A for ; Tue, 22 Sep 2009 04:52:43 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n8MBrfnG001657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Sep 2009 14:53:41 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n8MBreYO007633; Tue, 22 Sep 2009 14:53:40 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19128.47812.239136.479467@fireball.kivinen.iki.fi> Date: Tue, 22 Sep 2009 14:53:40 +0300 From: Tero Kivinen To: David Wierbowski In-Reply-To: References: <19127.28334.472030.873072@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 50 min X-Total-Time: 61 min Cc: IPsecme WG Subject: Re: [IPsec] #22 Simultaneous IKE SA rekey text X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 11:52:49 -0000 David Wierbowski writes: > I see no reason why Host A MUST NOT immediately delete the old IKE SA. Deleting the IKE SA immediately makes it impossible to know what happened to other exchanges going on the same IKE SA. Waiting for 30 seconds or so after rekey would allow those other exchanges to finish before the old IKE SA is deleted. The current IKEv2 document does not specify what happens to the ongoing exchanges when IKE SA is deleted. In normal case that does not matter, as all the IKE SA state goes away when SA is deleted, thus it is simply the case that all exchanges are immediately discarded and all CHILD_SAs on the IKE SA are deleted. This is not the case on the rekey case, as here there might be CREATE_CHILD_SAs and other exchanges ongoing on the IKE SA when it is rekeyed. Now if the IKE SA is deleted immediately without waiting those to finish when rekey finishes the other end does not know what the node deleting the IKE SA did for those exchanges. It might have silently discarded them, or it might have already processed them but their responses were lost because of network error etc. This causes the peers state to get out of sync, which will lead problems and will cause IKE SAs to be deleted completely later. > In fact I think is SHOULD immediately delete the old IKE SA. By this > I mean it should mark the SA as being deleted, it should send a delete > payload, and it should refuse to create any additional SAs. I agree it should mark the SA so that it is no longer used for the new SAs initiated from this end, but the other end might have its own exchanges ongoing when the rekey started, and waiting those to finish makes protocol work better. When both end mark the old SA as being "old", meaning no new exchanges are started on it, but old exchanges are allowed to finished then when those old exchanges are finished, then the old IKE SA should be deleted (and all operations done on the old IKE SA should be moved to the winning SA). > > recv req1 <-- > > send resp2: ... Nr2 ... --> > Host A should respond with NO_ADDITIONAL SAS in this case because > Host A did not detect a simultaneous rekey and should have immediately > deleted the original IKE_SA. NO_ADDITIONAL_SAS is not correct error for this case, as we are talking about IKE SAs not about CHILD_SAs. The NO_ADDITIONAL_SAS description clearly says it is used when no more CHILD_SAs are to be used. Sending some more suitable error could most likely also work, but still the IKE SA cannot be deleted immediately. It can only be deleted when ongoing exchanges have been finished. I have not checked out if your suggested version works with all possible combinations of simulatenous rekeys, but from the first look it seems it might also work. On the other hand there is no text indicating such behavior in the IKEv2 document, so it is protocol change compared to the old text which said that simulatenous rekey is processed by checking out the nonces. The rekeys in this case are simulatenous even when Host A didn't initially detect that. > > After sending that reply that also creates the second IKE SA B in > > Host A and then Host A can check all the four nonces and see which > > of them is lowest, and it will then move all the CHILD_SAs to that > > new IKE SA having lowest nonce unless they were already there (i.e. > > if the IKE SA A had lowest nonce, Host A has already moved the > > CHILD_SAs there, if IKE SA B had lowest nonce, host A needs to move > > CHILD_SAs from the IKE SA A to this IKE SA B, and start timer to > > delete IKE SA A). > Why do you want to mandate all this complication for a case that will > occur infrequently? You are impacting every IKE_SA rekey, not just > the simultaneous case. I doubt that anybody delays the delete of an > IKE_SA on a rekey based on RFC 4306. At the very least I'm sure there > are implementations that do not delay the delete. Requiring this > delay is a protocol change and one that I do not see the need for. We do delay the delete, as we do want to wait for the ongoing exchanges to finish. On the other hand we are almost only one of the implementations who also implement the window size > 1, which means we have cases where might have several CREATE_CHILD_SA exchanges initiated by the host B ongoing when host A decides to do rekey on the IKE SA. That delay does not have anything to do with simultaneous rekey, it is needed to allow the ongoing exchanges to finish before old IKE SA is deleted. On the other hand RFC4306 specifies exactly ONE way to handle simulatenous rekey and that is by checking the nonces. The rekey is simulatenous even when one host didn't immediately detect it as simulatenous because some packet was lost. I agree now that "MUST NOT immediately delete" was too strong, so "SHOULD NOT immediately delete" is better. If implementation does not implement larger window sizes, and is used in environments where there is very limited number of CHILD SAs per IKE SA, so the probability of getting CREATE_CHILD_SA just when other ends decides to rekey is so small, that it does not matter even if the whole IKE SA gets deleted in that case then it can ignore that SHOULD. > If Host A deletes the IKE_SA immediately then either Host B will see > the delete and be able to infer that there is no simultaneous rekey or > Host B may also get a NO_ADDITIONAL SAS notification and be able to > infer that there is no simultaneous rekey. Regardless what host A thinks there was still simultaneous rekey ongoing, and RFC4306 gives only one way to solve that so sending error in that case is against RFC4306. That is also protocol change. If we do protocol change, I would rather make it so we always for example make the original initiator to win in case of simulatenous IKE SA rekey case, and not care about nonces at all... -- kivinen@iki.fi From kivinen@iki.fi Tue Sep 22 05:01:01 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 065BB3A69CA for ; Tue, 22 Sep 2009 05:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7j-hqUM8SWE for ; Tue, 22 Sep 2009 05:01:00 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id D609A3A69E2 for ; Tue, 22 Sep 2009 05:00:59 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n8MC20Yn004607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Sep 2009 15:02:00 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n8MC20Pm006632; Tue, 22 Sep 2009 15:02:00 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19128.48311.977915.880645@fireball.kivinen.iki.fi> Date: Tue, 22 Sep 2009 15:01:59 +0300 From: Tero Kivinen To: Matthew Cini Sarreo In-Reply-To: <99043b4a0909220115r6b1a4decu36930c912b67895e@mail.gmail.com> References: <99043b4a0909220115r6b1a4decu36930c912b67895e@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 4 min Cc: ipsec@ietf.org Subject: [IPsec] IKEv2 NAT-T and Traffic Selectors X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 12:01:01 -0000 Matthew Cini Sarreo writes: > Hello all, > > I have a question regarding proper choosing of traffic selectors in the > situation where an initator is behind a NAT device. Let us use the following > scenario: > > [initiator@A]--[NAT@X]----------------[responder@Y] > > Say A is 192.168.2.22, X is 192.168.3.5 and Y is 192.168.4.25, and all have > a 24bit mask. The initiator policy requires traffic selectors for the whole > subnet. In the case that A is initiating: > TSi 192.168.2.0 to 192.168.2.255 > TSr 192.168.4.0 to 192.168.4.255 As these are subnets, I assume this is tunnel mode not transport mode. > Y does not know about 192.168.2.* but only about 192.168.3.*. So when it > receives TSi it does not match with anything it knows about. Should the > responder just accept these due to NAT being previously detected, or should > the initiator send selectors with address A (TSi) and Y (TSr) and due to > there being NAT the responder just copy them in the reply? The Y should be configured to accept 192.168.2.0/24 as this is tunnel mode and packets exiting from the tunnel will have those addresses as their source address. NAT does not change this, it only affects the gateway address, i.e only the outer IP address of the ESP packet. -- kivinen@iki.fi From ynir@checkpoint.com Tue Sep 22 05:19:16 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87A863A6A08 for ; Tue, 22 Sep 2009 05:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwhyIexwoAMj for ; Tue, 22 Sep 2009 05:19:15 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 517BE3A692F for ; Tue, 22 Sep 2009 05:19:15 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n8MCKHSr024503 for ; Tue, 22 Sep 2009 15:20:17 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 22 Sep 2009 15:20:16 +0300 From: Yoav Nir To: Yaron Sheffer Date: Tue, 22 Sep 2009 15:20:14 +0300 Thread-Topic: [IPsec] WG last call: draft-ietf-ipsecme-esp-null-heuristics-01 Thread-Index: Aco7fwqlhXzw3J43SUGDpch0MBbTNw== Message-ID: <0CBDB9D0-4FBC-4CD4-9F89-2140C3573D8C@checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328329@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328329@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] WG last call: draft-ietf-ipsecme-esp-null-heuristics-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 12:19:16 -0000 I support advancing this document, and I think the explanations and =20 pseudo code are good. I do, however, question the value of it in real life. Security policies or the deep inspection kind usually are something =20 like: - allow HTTP and HTTPS, and verify headers - allow ICMP and DNS - maybe some more allowed protocols - drop everything else I'm sure anything enforcing a policy like this will anyway drop ESP-=20 non-null, because it doesn't look like one of those allowed protocols. =20 However, YMMV so I support publishing this draft. On Sep 17, 2009, at 11:28 PM, Yaron Sheffer wrote: > This is to begin a 2 week working group last call for draft-ietf-=20 > ipsecme-esp-null-heuristics-01. The target status for this document =20 > is Informational. > > Please send your comments to the ipsec list by Oct. 1, 2009, as =20 > follow-ups to this message. > > Note that this document has had very little review until now. We =20 > will only progress it as a WG document if we have at least 3 non-=20 > editor, non-WG chair reviewers who have read it and approve of it. =20 > And yes, this means the pseudocode, too. There has been strong =20 > support of ESP-null detection, so this document is likely to be =20 > widely implemented. Your review will mean a lot to the technical =20 > quality of this document. > > Please clearly indicate the position of any issue in the Internet =20 > Draft, and if possible provide alternative text. Please also =20 > indicate the nature or severity of the error or correction, e.g. =20 > major technical, minor technical, nit, so that we can quickly judge =20 > the extent of problems with the document. > > The document can be accessed here: > http://tools.ietf.org/html/draft-ietf-ipsecme-esp-null-heuristics-01 > > Thanks, > Yaron > From yaronf@checkpoint.com Tue Sep 22 06:52:10 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F00C28C12F for ; Tue, 22 Sep 2009 06:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Glx8n1gJI1W for ; Tue, 22 Sep 2009 06:52:10 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id B3A6D28C110 for ; Tue, 22 Sep 2009 06:52:09 -0700 (PDT) X-CheckPoint: {4AB8D5D7-2-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id A509529C004; Tue, 22 Sep 2009 16:53:11 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 8733B29C002 for ; Tue, 22 Sep 2009 16:53:11 +0300 (IDT) X-CheckPoint: {4AB8D5D7-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n8MDrASr021120 for ; Tue, 22 Sep 2009 16:53:11 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 22 Sep 2009 16:53:10 +0300 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Tue, 22 Sep 2009 16:53:09 +0300 Thread-Topic: Meeting materials for today's conf call Thread-Index: Aco7jATNEjlxAECOQ9qp9wcz6vYaFQ== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD32869D@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] Meeting materials for today's conf call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 13:52:10 -0000 Hi, I have uploaded everything to the wiki: http://trac.tools.ietf.org/wg/ipsec= me/trac/wiki/Interim20090922 See you all later. Yaron Email secured by Check Point Email secured by Check Point From wierbows@us.ibm.com Tue Sep 22 06:53:12 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59DDE28C132 for ; Tue, 22 Sep 2009 06:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.85 X-Spam-Level: X-Spam-Status: No, score=-5.85 tagged_above=-999 required=5 tests=[AWL=0.748, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oJ8qT+UT5mK for ; Tue, 22 Sep 2009 06:53:10 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id 85C9F3A69C8 for ; Tue, 22 Sep 2009 06:53:10 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n8MDlOV3017912 for ; Tue, 22 Sep 2009 09:47:24 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8MDs7pJ218684 for ; Tue, 22 Sep 2009 09:54:07 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n8MDs7GW025578 for ; Tue, 22 Sep 2009 09:54:07 -0400 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n8MDs5bi025527 for ; Tue, 22 Sep 2009 09:54:06 -0400 In-Reply-To: <19128.47812.239136.479467@fireball.kivinen.iki.fi> References: <19127.28334.472030.873072@fireball.kivinen.iki.fi> <19128.47812.239136.479467@fireball.kivinen.iki.fi> X-KeepSent: 45D86819:0C27AAE8-85257639:00447B45; type=4; name=$KeepSent To: IPsecme WG X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: David Wierbowski Date: Tue, 22 Sep 2009 09:53:58 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 09/22/2009 09:54:05 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBFCAADFD7FDD58f9e8a93df938690918c0ABBFCAADFD7FDD5" Content-Disposition: inline Subject: Re: [IPsec] #22 Simultaneous IKE SA rekey text X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 13:53:12 -0000 --0__=0ABBFCAADFD7FDD58f9e8a93df938690918c0ABBFCAADFD7FDD5 Content-type: text/plain; charset=US-ASCII >Tero Stated: > > Deleting the IKE SA immediately makes it impossible to know what > happened to other exchanges going on the same IKE SA. Waiting for 30 > seconds or so after rekey would allow those other exchanges to finish > before the old IKE SA is deleted. > > The current IKEv2 document does not specify what happens to the > ongoing exchanges when IKE SA is deleted. In normal case that does not > matter, as all the IKE SA state goes away when SA is deleted, thus it > is simply the case that all exchanges are immediately discarded and > all CHILD_SAs on the IKE SA are deleted. > > This is not the case on the rekey case, as here there might be > CREATE_CHILD_SAs and other exchanges ongoing on the IKE SA when it is > rekeyed. Now if the IKE SA is deleted immediately without waiting > those to finish when rekey finishes the other end does not know what > the node deleting the IKE SA did for those exchanges. It might have > silently discarded them, or it might have already processed them but > their responses were lost because of network error etc. I agree with what you stated here, but I feel you are addressing something that is not limited to a simultaneous rekey of the IKE SA. It deals with any rekey of an IKE SA. In my opinion the text is misplaced and should be in a section that deals with handling of outstanding exchanges when an IKE SA is rekeyed. With that said I'm not sure I agree with how you propose to handle the outstanding exchanges. > I agree it should mark the SA so that it is no longer used for the new > SAs initiated from this end, but the other end might have its own > exchanges ongoing when the rekey started, and waiting those to finish > makes protocol work better. When both end mark the old SA as being > "old", meaning no new exchanges are started on it, but old exchanges > are allowed to finished then when those old exchanges are finished, > then the old IKE SA should be deleted (and all operations done on the > old IKE SA should be moved to the winning SA). This sounds like a good idea, but it's not what 4306 required and is a protocol change. Based on 4306 I think when an informational exchange request is received containing the delete of an IKE_SA that the receiver can conclude that most likely any outstanding request will fail once a response to the delete is sent. The receiver of the delete request has ways to deal with this. It can delay sending a response until it receives responses to all outstanding requests. It can send a response immediately and conclude that all outstanding requests will fail. In that case it can restart the outstanding request on a newer IKE_SA or wait for traffic to require the creation of a new SA. If one of the outstanding requests is for a perceived simultaneous rekey it now knows it was not perceived that way by the peer. In this case it should move the child SAs to the newer IKE SA. Even with your solution an implementation has to be able to handle the case where a perceived simultaneous rekey of the IKE SA fails. > > NO_ADDITIONAL_SAS is not correct error for this case, as we are > talking about IKE SAs not about CHILD_SAs. The NO_ADDITIONAL_SAS > description clearly says it is used when no more CHILD_SAs are to be > used. Correct, sorry I misspoke. We actually send NO_PROPOSAL_CHOSEN, but the same logic still applies. I believe we used to send NO_ADDITIONAL_SAS, but due to previous discussion on the mailing list we switched to NO_PROPOSAL_CHOSEN. > Sending some more suitable error could most likely also work, but > still the IKE SA cannot be deleted immediately. It can only be deleted > when ongoing exchanges have been finished. > > I have not checked out if your suggested version works with all > possible combinations of simulatenous rekeys, but from the first look > it seems it might also work. > > On the other hand there is no text indicating such behavior in the > IKEv2 document, so it is protocol change compared to the old text > which said that simulatenous rekey is processed by checking out the > nonces. The rekeys in this case are simulatenous even when Host A > didn't initially detect that. > Agreed, so we have two possible protocol changes if we need to mandate one or we could allow implementations solve the problem as they see fit. I think my solution is consistent with what is stated in Section 5.11.4 of RFC 4718. You are introducing the need to detect a simultaneous rekey after the fact. > We do delay the delete, as we do want to wait for the ongoing > exchanges to finish. On the other hand we are almost only one of the > implementations who also implement the window size > 1, which means we > have cases where might have several CREATE_CHILD_SA exchanges > initiated by the host B ongoing when host A decides to do rekey on the > IKE SA. We have tested our code using a window size greater than 1. > > That delay does not have anything to do with simultaneous rekey, it is > needed to allow the ongoing exchanges to finish before old IKE SA is > deleted. As I said earlier I think the ongoing exchange issue should be documented separately from the simultaneous rekey case, although I agree there can be a tie to it if your solution is agreed to. > > On the other hand RFC4306 specifies exactly ONE way to handle > simulatenous rekey and that is by checking the nonces. The rekey is > simulatenous even when one host didn't immediately detect it as > simulatenous because some packet was lost. > > I agree now that "MUST NOT immediately delete" was too strong, so > "SHOULD NOT immediately delete" is better. If implementation does not > implement larger window sizes, and is used in environments where there > is very limited number of CHILD SAs per IKE SA, so the probability of > getting CREATE_CHILD_SA just when other ends decides to rekey is so > small, that it does not matter even if the whole IKE SA gets deleted > in that case then it can ignore that SHOULD. I think "SHOULD NOT immediately delete" is still too strong. I think "MAY delay the deletion to allow ongoing exchanges to complete" is more appropriate at this point. Dave Wierbowski --0__=0ABBFCAADFD7FDD58f9e8a93df938690918c0ABBFCAADFD7FDD5 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

      >Tero Stated:
      >
      > Deleting the IKE SA immediately makes it impossible to know what
      > happened to other exchanges going on the same IKE SA. Waiting for 30
      > seconds or so after rekey would allow those other exchanges to finish
      > before the old IKE SA is deleted.
      >
      > The current IKEv2 document does not specify what happens to the
      > ongoing exchanges when IKE SA is deleted. In normal case that does not
      > matter, as all the IKE SA state goes away when SA is deleted, thus it
      > is simply the case that all exchanges are immediately discarded and
      > all CHILD_SAs on the IKE SA are deleted.
      >
      > This is not the case on the rekey case, as here there might be
      > CREATE_CHILD_SAs and other exchanges ongoing on the IKE SA when it is
      > rekeyed. Now if the IKE SA is deleted immediately without waiting
      > those to finish when rekey finishes the other end does not know what
      > the node deleting the IKE SA did for those exchanges. It might have
      > silently discarded them, or it might have already processed them but
      > their responses were lost because of network error etc.

      I agree with what you stated here, but I feel you are addressing something
      that is not limited to a simultaneous rekey of the IKE SA. It deals with any
      rekey of an IKE SA. In my opinion the text is misplaced and should be in a
      section that deals with handling of outstanding exchanges when an IKE SA
      is rekeyed. With that said I'm not sure I agree with how you propose to
      handle the outstanding exchanges.

      > I agree it should mark the SA so that it is no longer used for the new
      > SAs initiated from this end, but the other end might have its own
      > exchanges ongoing when the rekey started, and waiting those to finish
      > makes protocol work better. When both end mark the old SA as being
      > "old", meaning no new exchanges are started on it, but old exchanges
      > are allowed to finished then when those old exchanges are finished,
      > then the old IKE SA should be deleted (and all operations done on the
      > old IKE SA should be moved to the winning SA).

      This sounds like a good idea, but it's not what 4306 required and is a
      protocol change.

      Based on 4306 I think when an informational exchange request is received
      containing the delete of an IKE_SA that the receiver can conclude that most
      likely any outstanding request will fail once a response to the delete is
      sent. The receiver of the delete request has ways to deal with this.

      It can delay sending a response until it receives responses to all
      outstanding requests. It can send a response immediately and conclude
      that all outstanding requests will fail. In that case it can restart the
      outstanding request on a newer IKE_SA or wait for traffic to require the
      creation of a new SA.

      If one of the outstanding requests is for a perceived simultaneous rekey
      it now knows it was not perceived that way by the peer. In this case
      it should move the child SAs to the newer IKE SA. Even with your solution an
      implementation has to be able to handle the case where a perceived
      simultaneous rekey of the IKE SA fails.

      >
      > NO_ADDITIONAL_SAS is not correct error for this case, as we are
      > talking about IKE SAs not about CHILD_SAs. The NO_ADDITIONAL_SAS
      > description clearly says it is used when no more CHILD_SAs are to be
      > used.

      Correct, sorry I misspoke. We actually send NO_PROPOSAL_CHOSEN, but the same
      logic still applies. I believe we used to send NO_ADDITIONAL_SAS, but
      due to previous discussion on the mailing list we switched to
      NO_PROPOSAL_CHOSEN.

      > Sending some more suitable error could most likely also work, but
      > still the IKE SA cannot be deleted immediately. It can only be deleted
      > when ongoing exchanges have been finished.
      >
      > I have not checked out if your suggested version works with all
      > possible combinations of simulatenous rekeys, but from the first look
      > it seems it might also work.
      >
      > On the other hand there is no text indicating such behavior in the
      > IKEv2 document, so it is protocol change compared to the old text
      > which said that simulatenous rekey is processed by checking out the
      > nonces. The rekeys in this case are simulatenous even when Host A
      > didn't initially detect that.
      >

      Agreed, so we have two possible protocol changes if we need to mandate one
      or we could allow implementations solve the problem as they see fit. I think
      my solution is consistent with what is stated in Section 5.11.4 of RFC 4718.
      You are introducing the need to detect a simultaneous rekey after the fact.

      > We do delay the delete, as we do want to wait for the ongoing
      > exchanges to finish. On the other hand we are almost only one of the
      > implementations who also implement the window size > 1, which means we
      > have cases where might have several CREATE_CHILD_SA exchanges
      > initiated by the host B ongoing when host A decides to do rekey on the
      > IKE SA.

      We have tested our code using a window size greater than 1.

      >
      > That delay does not have anything to do with simultaneous rekey, it is
      > needed to allow the ongoing exchanges to finish before old IKE SA is
      > deleted.

      As I said earlier I think the ongoing exchange issue should be documented
      separately from the simultaneous rekey case, although I agree there can
      be a tie to it if your solution is agreed to.

      >
      > On the other hand RFC4306 specifies exactly ONE way to handle
      > simulatenous rekey and that is by checking the nonces. The rekey is
      > simulatenous even when one host didn't immediately detect it as
      > simulatenous because some packet was lost.
      >
      > I agree now that "MUST NOT immediately delete" was too strong, so
      > "SHOULD NOT immediately delete" is better. If implementation does not
      > implement larger window sizes, and is used in environments where there
      > is very limited number of CHILD SAs per IKE SA, so the probability of
      > getting CREATE_CHILD_SA just when other ends decides to rekey is so
      > small, that it does not matter even if the whole IKE SA gets deleted
      > in that case then it can ignore that SHOULD.

      I think "SHOULD NOT immediately delete" is still too strong. I think
      "MAY delay the deletion to allow ongoing exchanges to complete" is
      more appropriate at this point.


      Dave Wierbowski

      --0__=0ABBFCAADFD7FDD58f9e8a93df938690918c0ABBFCAADFD7FDD5-- From wierbows@us.ibm.com Tue Sep 22 07:08:53 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 258DA3A67E7 for ; Tue, 22 Sep 2009 07:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.913 X-Spam-Level: X-Spam-Status: No, score=-5.913 tagged_above=-999 required=5 tests=[AWL=0.686, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMmgQ+irxPgT for ; Tue, 22 Sep 2009 07:08:52 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id 018413A699D for ; Tue, 22 Sep 2009 07:08:51 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n8ME3C5O007765 for ; Tue, 22 Sep 2009 10:03:12 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8ME9ppq238416 for ; Tue, 22 Sep 2009 10:09:55 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n8ME9oes018496 for ; Tue, 22 Sep 2009 10:09:50 -0400 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n8ME9kq2017873 for ; Tue, 22 Sep 2009 10:09:46 -0400 In-Reply-To: References: X-KeepSent: C97BCC38:20E43DDA-85257639:004D3DC0; type=4; name=$KeepSent To: ipsec@ietf.org X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: David Wierbowski Date: Tue, 22 Sep 2009 10:09:45 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 09/22/2009 10:09:46 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBFCAADFDEBB508f9e8a93df938690918c0ABBFCAADFDEBB50" Content-Disposition: inline Subject: Re: [IPsec] HTTP_CERT_LOOKUP_SUPPORTED notify text X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 14:08:53 -0000 --0__=0ABBFCAADFDEBB508f9e8a93df938690918c0ABBFCAADFDEBB50 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I posted this a last week and have not seen any comments: Section 3.6 of ikev2bis-04 says, "Certificate payloads SHOULD be includ= ed in an exchange if certificates are available to the sender unless the p= eer has indicated an ability to retrieve this information from elsewhere u= sing an HTTP_CERT_LOOKUP_SUPPORTED Notify payload." Section 3.7 of ikev2bis-04, says "The HTTP_CERT_LOOKUP_SUPPORTED notification MAY be included in any message that can include a CERTREQ payload and indicates that the sender is capable of looking up certific= ates based on an HTTP-based URL (and hence presumably would prefer to receiv= e certificate specifications in that format)." Section 3.10.1 of ikev2bis-04 indicates that section 3.6 should be consulted for an explanation of the HTTP_CERT_LOOKUP_SUPPORTED notification. I think section 3.10.1 should say "see section 3.7" as the text that wa= s associated with the HTTP_CERT_LOOKUP_SUPPORTED notify in RFC 4306 is no= w in Section 3.7. I also question the accuracy of the statement in Section 3.6. Section = 3.7 implies that certificate payloads should still be sent when an HTTP_CERT_LOOKUP_SUPPORTED notify is received; however, an encoding typ= e of 12 or 13 should be used if possible as the peer has indicated a prefere= nce to receive certificate specifications in that format. Dave Wierbowski= --0__=0ABBFCAADFDEBB508f9e8a93df938690918c0ABBFCAADFDEBB50 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

      I posted this a last week and have not seen any comments:

      Section 3.6 of ikev2bis-04 says, "Certificate payloads SHOULD be i= ncluded in an exchange if certificates are available to the sender unle= ss the peer has indicated an ability to retrieve this information from = elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload." <= br>
      Section 3.7 of ikev2bis-04, says "The HTTP_CERT_LOOKUP_SUPPORTED = notification MAY be included in any message that can include a CERTREQ = payload and indicates that the sender is capable of looking up certific= ates based on an HTTP-based URL (and hence presumably would prefer to r= eceive certificate specifications in that format)."

      Section 3.10.1 of ikev2bis-04 indicates that section 3.6 should be con= sulted for an explanation of the HTTP_CERT_LOOKUP_SUPPORTED notificatio= n.

      I think section 3.10.1 should say "see section 3.7" as the te= xt that was associated with the HTTP_CERT_LOOKUP_SUPPORTED notify in RF= C 4306 is now in Section 3.7.

      I also question the accuracy of the statement in Section 3.6. Section = 3.7 implies that certificate payloads should still be sent when an HTTP= _CERT_LOOKUP_SUPPORTED notify is received; however, an encoding type of= 12 or 13 should be used if possible as the peer has indicated a prefer= ence to receive certificate specifications in that format.


      Dave Wierbowski
      = --0__=0ABBFCAADFDEBB508f9e8a93df938690918c0ABBFCAADFDEBB50-- From denghui02@gmail.com Tue Sep 22 07:38:38 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C62833A68D9; Tue, 22 Sep 2009 07:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMiEL-Ye6SFb; Tue, 22 Sep 2009 07:38:37 -0700 (PDT) Received: from mail-qy0-f201.google.com (mail-qy0-f201.google.com [209.85.221.201]) by core3.amsl.com (Postfix) with ESMTP id 9C69428C102; Tue, 22 Sep 2009 07:38:37 -0700 (PDT) Received: by qyk39 with SMTP id 39so3019620qyk.31 for ; Tue, 22 Sep 2009 07:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=H2iWTji/CM+g4bFCL3Qr0fkuXEL9zC7C7c/spfrcIqs=; b=RjN06jJ4RkplLGz2Aap8IKkXKQVKK5eVWw8H8YubpZOuiekdOzbUYAz8LAqtcV0nJO LkDjdUKkB8sVIL9be0s4Dkb8QxWjf2gSBSfwGch0goiU0Hgr6HfspoHn0/jy5JX1QeOr bHKN9AvwkNcBQh6PCZFgn7tI/VNBEj4jBeSmM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RiNl3RJF/CRJ+qq8P9t1eC+xsg555R0VuuywzGaBeHJIqNdNdEjnq8154D9XFH7a/a xeMBvnv0089jGr7MapGupM/fwlBWwFIGNPNZ8qyG4qeiB1JONh76cP1pUJ5Sl6G6xV2L 3CXpyqLomakX+nMSL03Rwf58bSPdHLRE0jQCc= MIME-Version: 1.0 Received: by 10.224.115.98 with SMTP id h34mr745299qaq.193.1253630378381; Tue, 22 Sep 2009 07:39:38 -0700 (PDT) In-Reply-To: <19103.34893.896574.218235@fireball.kivinen.iki.fi> References: <20090831140935.4752B3A6E46@core3.amsl.com> <4c5c7a6d0909011932g74decc2dq1ae2cb61b78b2b0a@mail.gmail.com> <4c5c7a6d0909020717r72ee57btaaa9bdafd39a12cd@mail.gmail.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80190A978EFBE@il-ex01.ad.checkpoint.com> <19103.34893.896574.218235@fireball.kivinen.iki.fi> Date: Tue, 22 Sep 2009 22:39:38 +0800 Message-ID: <1d38a3350909220739y496159cexd4f82b1a40df9c31@mail.gmail.com> From: Hui Deng To: Tero Kivinen Content-Type: text/plain; charset=ISO-8859-1 Cc: IPsecme WG , "ietf@ietf.org" , Peny Yang Subject: Re: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 14:38:38 -0000 Comments inline, thanks 2009/9/3 Tero Kivinen : > Yaron Sheffer writes: >> [YS] I see the merits of extending IKE_SA_INIT to support resumption, and in >> fact an early version of our work did exactly that. But the working group >> gave us a clear direction to use a separate exchange, and this is where we >> disagree: I believe we did have a strong WG consensus that the >> implementation benefits of having a separate exchange (i.e. not overloading >> even more the non-trivial IKE_SA_INIT exchange) outweigh the benefits of the >> alternative. > > I agree on that (both to the WG having consensus and also that using > separate exchange is better). [Hui] I don't think so. IMO, in the list, the comparison of extended IKE_SA_INIT exchange and IKE_SESSION_RESUME still did not have a consensus yet. It was a ballot in the mailing list in the begining, and it is quite clear more people opposing sepaparate exchange, we could do one more round ballot if needed. > >> > I know that how a client detects the need for resumption is out of the >> > scope of this draft. But, there is the possibility that IPsec client >> > may be continuously deceived and believe the fail of IPsec gateway. It >> > may continuously present the ticket and update the ticket. In this >> > sense, IMHO, this draft should take care of this case. >> > >> [YS] If I understand the scenario correctly, it is similar to an attacker >> repeatedly sending notifications to an IKE client, making it believe that >> the IKE exchange has failed and needs to be reinitiated. This attack against >> plain-vanilla IKE would be much more CPU-intensive to the client and to the >> (real) gateway, compared to repeated session resumption. Even when you >> factor in the cost of generating a new ticket. Moreover, the regular IKEv2 >> anti-DOS cookie mechanism is supported by IKE_SESSION_RESUME as well. > > Regardless what notifications or ICMP messages you send to any of the > IKE end points that MUST NOT cause them to consider IKE SA failed. It > "MUST conclude that the other endpoind has failed only when repeated > attemtps to contact it have gone unanswered for timeout period or when > a cryptographically protected INITIAL_CONTACT notification is received > on a different IKE SA to the same authenticated identity." (RFC 4306 > section 2.4) > > Notifications and ICMP messages may trigger other end to send empty > INFORMATIONAL message to check whether the other end is alive or not > and only if that times out then the other end is considered dead. > > This means this kind of attack is not possible with notifications and > ICMP. > > On the other hand I do agree with Peny that, as resumption draft makes > it out of scope for this draft, how a client detects the need of > resumption, we might need more text explaining this attack. I.e. we > might need to add text to security considerations which says that the > client implementations should not trust any untrusted source when they > are trying to detect whether the resumption is needed. [Hui] I also agree with Peny and Tero. Although way of detecting failure of gateways is out of the scope of current charter, WG draft should at least handle the issues incurred by mis-judgement of client. thanks -Hui From yaronf@checkpoint.com Tue Sep 22 07:45:18 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56DCE3A6A1F; Tue, 22 Sep 2009 07:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMVsD83hxaIA; Tue, 22 Sep 2009 07:45:17 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id D739D3A6A01; Tue, 22 Sep 2009 07:45:16 -0700 (PDT) X-CheckPoint: {4AB8E24B-9-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 32AE329C004; Tue, 22 Sep 2009 17:46:20 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id EF97529C002; Tue, 22 Sep 2009 17:46:19 +0300 (IDT) X-CheckPoint: {4AB8E24B-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n8MEkJSr007646; Tue, 22 Sep 2009 17:46:19 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 22 Sep 2009 17:46:18 +0300 From: Yaron Sheffer To: Hui Deng , Tero Kivinen Date: Tue, 22 Sep 2009 17:46:17 +0300 Thread-Topic: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard Thread-Index: Aco7krcRM7Zs4qjhTgCXfLTInODe+gAAH2vg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD3286AE@il-ex01.ad.checkpoint.com> References: <20090831140935.4752B3A6E46@core3.amsl.com> <4c5c7a6d0909011932g74decc2dq1ae2cb61b78b2b0a@mail.gmail.com> <4c5c7a6d0909020717r72ee57btaaa9bdafd39a12cd@mail.gmail.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80190A978EFBE@il-ex01.ad.checkpoint.com> <19103.34893.896574.218235@fireball.kivinen.iki.fi> <1d38a3350909220739y496159cexd4f82b1a40df9c31@mail.gmail.com> In-Reply-To: <1d38a3350909220739y496159cexd4f82b1a40df9c31@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG , "ietf@ietf.org" , Peny Yang Subject: Re: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 14:45:18 -0000 Hi Hui, Thank you for your comments. Regarding your second comment, please see http= ://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-resumption-08#section-9.4 Regards, Yaron > -----Original Message----- > From: Hui Deng [mailto:denghui02@gmail.com] > Sent: Tuesday, September 22, 2009 17:40 > To: Tero Kivinen > Cc: Yaron Sheffer; IPsecme WG; ietf@ietf.org; Peny Yang > Subject: Re: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption > (IKEv2 Session Resumption) to Proposed Standard >=20 > Comments inline, thanks >=20 > 2009/9/3 Tero Kivinen : > > Yaron Sheffer writes: > >> [YS] I see the merits of extending IKE_SA_INIT to support resumption, > and in > >> fact an early version of our work did exactly that. But the working > group > >> gave us a clear direction to use a separate exchange, and this is wher= e > we > >> disagree: I believe we did have a strong WG consensus that the > >> implementation benefits of having a separate exchange (i.e. not > overloading > >> even more the non-trivial IKE_SA_INIT exchange) outweigh the benefits > of the > >> alternative. > > > > I agree on that (both to the WG having consensus and also that using > > separate exchange is better). > [Hui] I don't think so. IMO, in the list, the comparison of extended > IKE_SA_INIT exchange and IKE_SESSION_RESUME still did not have a consensu= s > yet. > It was a ballot in the mailing list in the begining, and it is quite > clear more people opposing > sepaparate exchange, we could do one more round ballot if needed. >=20 > > > >> > I know that how a client detects the need for resumption is out of > the > >> > scope of this draft. But, there is the possibility that IPsec client > >> > may be continuously deceived and believe the fail of IPsec gateway. > It > >> > may continuously present the ticket and update the ticket. In this > >> > sense, IMHO, this draft should take care of this case. > >> > > >> [YS] If I understand the scenario correctly, it is similar to an > attacker > >> repeatedly sending notifications to an IKE client, making it believe > that > >> the IKE exchange has failed and needs to be reinitiated. This attack > against > >> plain-vanilla IKE would be much more CPU-intensive to the client and t= o > the > >> (real) gateway, compared to repeated session resumption. Even when you > >> factor in the cost of generating a new ticket. Moreover, the regular > IKEv2 > >> anti-DOS cookie mechanism is supported by IKE_SESSION_RESUME as well. > > > > Regardless what notifications or ICMP messages you send to any of the > > IKE end points that MUST NOT cause them to consider IKE SA failed. It > > "MUST conclude that the other endpoind has failed only when repeated > > attemtps to contact it have gone unanswered for timeout period or when > > a cryptographically protected INITIAL_CONTACT notification is received > > on a different IKE SA to the same authenticated identity." (RFC 4306 > > section 2.4) > > > > Notifications and ICMP messages may trigger other end to send empty > > INFORMATIONAL message to check whether the other end is alive or not > > and only if that times out then the other end is considered dead. > > > > This means this kind of attack is not possible with notifications and > > ICMP. > > > > On the other hand I do agree with Peny that, as resumption draft makes > > it out of scope for this draft, how a client detects the need of > > resumption, we might need more text explaining this attack. I.e. we > > might need to add text to security considerations which says that the > > client implementations should not trust any untrusted source when they > > are trying to detect whether the resumption is needed. >=20 > [Hui] I also agree with Peny and Tero. Although way of detecting > failure of gateways is out of the scope of current charter, WG draft > should at least handle the issues incurred by mis-judgement of client. >=20 > thanks >=20 > -Hui >=20 > Scanned by Check Point Total Security Gateway. Email secured by Check Point Email secured by Check Point From smoonen@us.ibm.com Tue Sep 22 07:58:12 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EDC23A6A5A; Tue, 22 Sep 2009 07:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.565 X-Spam-Level: X-Spam-Status: No, score=-4.565 tagged_above=-999 required=5 tests=[AWL=-1.967, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0orNqhLgXKsU; Tue, 22 Sep 2009 07:58:10 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by core3.amsl.com (Postfix) with ESMTP id 842093A6A85; Tue, 22 Sep 2009 07:58:10 -0700 (PDT) Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e9.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n8MEuOJM005163; Tue, 22 Sep 2009 10:56:24 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8MEwond1077454; Tue, 22 Sep 2009 10:58:50 -0400 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n8MEwZTp023338; Tue, 22 Sep 2009 08:58:35 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n8MEwRsY022947; Tue, 22 Sep 2009 08:58:28 -0600 In-Reply-To: <19128.37429.438136.60314@fireball.kivinen.iki.fi> References: <19109.286.34505.162897@fireball.kivinen.iki.fi> <73BF7996-C4FA-4442-B49D-DDD710CACA87@checkpoint.com> <19109.11583.348236.158555@fireball.kivinen.iki.fi> <19120.57165.424835.989773@fireball.kivinen.iki.fi> <19128.37429.438136.60314@fireball.kivinen.iki.fi> To: Tero Kivinen MIME-Version: 1.0 X-KeepSent: E957431B:9367F162-85257639:0051C8FD; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 09/22/2009 10:56:11 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 09/22/2009 10:56:11 AM, Serialize complete at 09/22/2009 10:56:11 AM, S/MIME Sign failed at 09/22/2009 10:56:11 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V851_08302009|August 30, 2009) at 09/22/2009 08:58:27, Serialize complete at 09/22/2009 08:58:27 Message-ID: Date: Tue, 22 Sep 2009 10:58:25 -0400 Content-Type: multipart/alternative; boundary="=_alternative 00520C6685257639_=" Cc: "ipsec@ietf.org WG" , ipsec-bounces@ietf.org, Yoav Nir , Paul Hoffman Subject: Re: [IPsec] Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 14:58:12 -0000 This is a multipart message in MIME format. --=_alternative 00520C6685257639_= Content-Type: text/plain; charset="US-ASCII" Tero, I don't understand. Two weeks ago you said: > If you use that kind of halfway up IKE SA for sending INFORMATIONAL > message to other end (who thinks the IKE SA is up and valid), then I > agree that sending both N(AUTHENTICATION_FAILED) and DELETE would be > the correct way to do it. DELETE only would also be ok. Now I think you are suggesting that DELETE is improper in this case, which directly contradicts your earlier note. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Tero Kivinen To: Scott C Moonen/Raleigh/IBM@IBMUS Cc: Paul Hoffman , "ipsec@ietf.org WG" , ipsec-bounces@ietf.org, Yoav Nir Date: 09/22/2009 05:06 AM Subject: Re: [IPsec] Issue #26: Missing treatment of error cases Scott C Moonen writes: > > NOTE FOR WG DISCUSSION: Having other payloads in the message is > > allowed but there are none suggested. One WG member mentioned the > > possibility of adding a DELETE payload when the error is sent in a > > separate INFORMATIONAL exchange. Do we want to allow such additional > > payloads that have operational semantics? > > I think you are asking specifically about the IKE_AUTH response? If so, I > agree that DELETE does not make sense in the IKE_AUTH response, and > N(AUTHENTICATION_FAILED), for example, is sufficient to delete the IKE SA. > I think we can forbid DELETE in the IKE_AUTH response. However, because > a separate INFORMATIONAL exchange cannot be definitively correlated to the > IKE_AUTH exchange, I'd like to retain the option of sending both DELETE > and N(AUTHENTICATION_FAILED) (for example) in a separate INFO exchange. You cannot really get AUTHENTICATION_FAILED in any other places than IKE_AUTH, as the text says: AUTHENTICATION_FAILED 24 Sent in the response to an IKE_AUTH message when for some reason the authentication failed. There is no associated data. Thus AUTHENTICATION_FAILED can always be correlated to the IKE_AUTH. On the other hand, I think it is clear that unless we explictly forbid other payloads you are free to add whatever payloads are normally allowed in INFORMATIONAL exchange anyways (i.e. notice, delete, vendori ID payloads, or even configuration payloads etc). Most likely the other end either processes those or ignores them, and if your error notify is fatal error like INVALID_SYNTAX then it really does not matter as the IKE SA will be deleted anyways. The IKEv2 does not really restrict what you can send in INFORMATIONAL exchange, but there are lots of cases where those simply do not make any sense. -- kivinen@iki.fi --=_alternative 00520C6685257639_= Content-Type: text/html; charset="US-ASCII"
      Tero, I don't understand.  Two weeks ago you said:

      > If you use that kind of halfway up IKE SA for sending INFORMATIONAL
      > message to other end (who thinks the IKE SA is up and valid), then I
      > agree that sending both N(AUTHENTICATION_FAILED) and DELETE would be
      > the correct way to do it. DELETE only would also be ok.

      Now I think you are suggesting that DELETE is improper in this case, which directly contradicts your earlier note.


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


      From: Tero Kivinen <kivinen@iki.fi>
      To: Scott C Moonen/Raleigh/IBM@IBMUS
      Cc: Paul Hoffman <paul.hoffman@vpnc.org>, "ipsec@ietf.org WG" <ipsec@ietf.org>, ipsec-bounces@ietf.org, Yoav Nir <ynir@checkpoint.com>
      Date: 09/22/2009 05:06 AM
      Subject: Re: [IPsec] Issue #26: Missing treatment of error cases




      Scott C Moonen writes:
      > > <t>NOTE FOR WG DISCUSSION: Having other payloads in the message is
      > > allowed but there are none suggested. One WG member mentioned the
      > > possibility of adding a DELETE payload when the error is sent in a
      > > separate INFORMATIONAL exchange. Do we want to allow such additional
      > > payloads that have operational semantics?</t>
      >
      > I think you are asking specifically about the IKE_AUTH response?  If so, I
      > agree that DELETE does not make sense in the IKE_AUTH response, and
      > N(AUTHENTICATION_FAILED), for example, is sufficient to delete the IKE SA.
      >  I think we can forbid DELETE in the IKE_AUTH response.  However, because
      > a separate INFORMATIONAL exchange cannot be definitively correlated to the
      > IKE_AUTH exchange, I'd like to retain the option of sending both DELETE
      > and N(AUTHENTICATION_FAILED) (for example) in a separate INFO exchange.

      You cannot really get AUTHENTICATION_FAILED in any other places than
      IKE_AUTH, as the text says:

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

      Thus AUTHENTICATION_FAILED can always be correlated to the IKE_AUTH.

      On the other hand, I think it is clear that unless we explictly forbid
      other payloads you are free to add whatever payloads are normally
      allowed in INFORMATIONAL exchange anyways (i.e. notice, delete,
      vendori ID payloads, or even configuration payloads etc). Most likely
      the other end either processes those or ignores them, and if your
      error notify is fatal error like INVALID_SYNTAX then it really does
      not matter as the IKE SA will be deleted anyways.

      The IKEv2 does not really restrict what you can send in INFORMATIONAL
      exchange, but there are lots of cases where those simply do not make
      any sense.
      --
      kivinen@iki.fi

      --=_alternative 00520C6685257639_=-- From smoonen@us.ibm.com Tue Sep 22 09:52:08 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33DA63A6954; Tue, 22 Sep 2009 09:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.368 X-Spam-Level: X-Spam-Status: No, score=-6.368 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTdwboljVdmb; Tue, 22 Sep 2009 09:52:06 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by core3.amsl.com (Postfix) with ESMTP id BF8B73A67C0; Tue, 22 Sep 2009 09:52:06 -0700 (PDT) Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e31.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n8MGkv4F029716; Tue, 22 Sep 2009 10:46:57 -0600 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8MGqso8163256; Tue, 22 Sep 2009 10:52:56 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n8MGqref031253; Tue, 22 Sep 2009 10:52:53 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av05.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n8MGqrau031234; Tue, 22 Sep 2009 10:52:53 -0600 In-Reply-To: <19128.48311.977915.880645@fireball.kivinen.iki.fi> References: <99043b4a0909220115r6b1a4decu36930c912b67895e@mail.gmail.com> <19128.48311.977915.880645@fireball.kivinen.iki.fi> To: Tero Kivinen MIME-Version: 1.0 X-KeepSent: 6DE1A3BC:44B97463-85257639:004C7A03; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 09/22/2009 12:51:35 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 09/22/2009 12:51:35 PM, Serialize complete at 09/22/2009 12:51:35 PM, S/MIME Sign failed at 09/22/2009 12:51:35 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V851_08302009|August 30, 2009) at 09/22/2009 10:52:52, Serialize complete at 09/22/2009 10:52:52 Message-ID: Date: Tue, 22 Sep 2009 12:52:51 -0400 Content-Type: multipart/alternative; boundary="=_alternative 005C9D4885257639_=" Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, Matthew Cini Sarreo Subject: Re: [IPsec] IKEv2 NAT-T and Traffic Selectors X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 16:52:08 -0000 This is a multipart message in MIME format. --=_alternative 005C9D4885257639_= Content-Type: text/plain; charset="US-ASCII" Hi Matt. Our implementation works a little differently from Tero's, so I'm replying just to provide a different perspective. For our implementation, we've decided that foreign network addresses should not generally appear in either our configuration or our primary displays. In your scenario, if IPsec were not in use, a TCP connection through NAT@X would appear to have a remote address of X at the responder. For our implementation this would remain true even when IPsec is introduced along the path. Speaking in terms of IKEv1, if our IKE is responder in this scenario, we will note the proposed IDi as the real client address and X as the public client address. We will compare address X against our PAD and SPD for policy decisions, but we will echo the original IDi and IDr in our response. Obviously this means that we need to do address translation within our platform to map 192.168.2.* to 192.168.3.5. This grows a little tricky for ICMP messages with embedded packets. Note that in any case the responder really ought to perform port translation in this configuration. Our design decision does prevent our implementation from initiating to a remote IPsec gateway if that gateway is behind a NAT, since we have excluded the possibility of configuring addresses in the network behind that NAT. We believe that initiating to a gateway behind a NAT is an uncommon configuration, especially for our platform. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Tero Kivinen To: Matthew Cini Sarreo Cc: ipsec@ietf.org Date: 09/22/2009 08:02 AM Subject: [IPsec] IKEv2 NAT-T and Traffic Selectors Matthew Cini Sarreo writes: > Hello all, > > I have a question regarding proper choosing of traffic selectors in the > situation where an initator is behind a NAT device. Let us use the following > scenario: > > [initiator@A]--[NAT@X]----------------[responder@Y] > > Say A is 192.168.2.22, X is 192.168.3.5 and Y is 192.168.4.25, and all have > a 24bit mask. The initiator policy requires traffic selectors for the whole > subnet. In the case that A is initiating: > TSi 192.168.2.0 to 192.168.2.255 > TSr 192.168.4.0 to 192.168.4.255 As these are subnets, I assume this is tunnel mode not transport mode. > Y does not know about 192.168.2.* but only about 192.168.3.*. So when it > receives TSi it does not match with anything it knows about. Should the > responder just accept these due to NAT being previously detected, or should > the initiator send selectors with address A (TSi) and Y (TSr) and due to > there being NAT the responder just copy them in the reply? The Y should be configured to accept 192.168.2.0/24 as this is tunnel mode and packets exiting from the tunnel will have those addresses as their source address. NAT does not change this, it only affects the gateway address, i.e only the outer IP address of the ESP packet. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 005C9D4885257639_= Content-Type: text/html; charset="US-ASCII"
      Hi Matt.  Our implementation works a little differently from Tero's, so I'm replying just to provide a different perspective.

      For our implementation, we've decided that foreign network addresses should not generally appear in either our configuration or our primary displays.  In your scenario, if IPsec were not in use, a TCP connection through NAT@X would appear to have a remote address of X at the responder.  For our implementation this would remain true even when IPsec is introduced along the path.

      Speaking in terms of IKEv1, if our IKE is responder in this scenario, we will note the proposed IDi as the real client address and X as the public client address.  We will compare address X against our PAD and SPD for policy decisions, but we will echo the original IDi and IDr in our response.  Obviously this means that we need to do address translation within our platform to map 192.168.2.* to 192.168.3.5.  This grows a little tricky for ICMP messages with embedded packets.  Note that in any case the responder really ought to perform port translation in this configuration.

      Our design decision does prevent our implementation from initiating to a remote IPsec gateway if that gateway is behind a NAT, since we have excluded the possibility of configuring addresses in the network behind that NAT.  We believe that initiating to a gateway behind a NAT is an uncommon configuration, especially for our platform.


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


      From: Tero Kivinen <kivinen@iki.fi>
      To: Matthew Cini Sarreo <mcins1@gmail.com>
      Cc: ipsec@ietf.org
      Date: 09/22/2009 08:02 AM
      Subject: [IPsec]  IKEv2 NAT-T and Traffic Selectors




      Matthew Cini Sarreo writes:
      > Hello all,
      >
      > I have a question regarding proper choosing of traffic selectors in the
      > situation where an initator is behind a NAT device. Let us use the following
      > scenario:
      >
      > [initiator@A]--[NAT@X]----------------[responder@Y]
      >
      > Say A is 192.168.2.22, X is 192.168.3.5 and Y is 192.168.4.25, and all have
      > a 24bit mask. The initiator policy requires traffic selectors for the whole
      > subnet. In the case that A is initiating:
      > TSi 192.168.2.0 to 192.168.2.255
      > TSr 192.168.4.0 to 192.168.4.255

      As these are subnets, I assume this is tunnel mode not transport mode.  

      > Y does not know about 192.168.2.* but only about 192.168.3.*. So when it
      > receives TSi it does not match with anything it knows about. Should the
      > responder just accept these due to NAT being previously detected, or should
      > the initiator send selectors with address A (TSi) and Y (TSr) and due to
      > there being NAT the responder just copy them in the reply?

      The Y should be configured to accept 192.168.2.0/24 as this is tunnel
      mode and packets exiting from the tunnel will have those addresses as
      their source address. NAT does not change this, it only affects the
      gateway address, i.e only the outer IP address of the ESP packet.
      --
      kivinen@iki.fi
      _______________________________________________
      IPsec mailing list
      IPsec@ietf.org
      https://www.ietf.org/mailman/listinfo/ipsec

      --=_alternative 005C9D4885257639_=-- From danmcd@sun.com Tue Sep 22 10:11:28 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42C4F3A6AAC for ; Tue, 22 Sep 2009 10:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FW-+lDlKXW6j for ; Tue, 22 Sep 2009 10:11:27 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 6AC113A67B6 for ; Tue, 22 Sep 2009 10:11:27 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8MHCVvP020084 for ; Tue, 22 Sep 2009 17:12:31 GMT Received: from kebe.East.Sun.COM (kebe.East.Sun.COM [129.148.174.48]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n8MHCVvZ039824 for ; Tue, 22 Sep 2009 13:12:31 -0400 (EDT) Received: from kebe.East.Sun.COM (localhost [127.0.0.1]) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n8MH4axH004270; Tue, 22 Sep 2009 13:04:36 -0400 (EDT) Received: (from danmcd@localhost) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n8MH4ZQH004269; Tue, 22 Sep 2009 13:04:35 -0400 (EDT) X-Authentication-Warning: kebe.East.Sun.COM: danmcd set sender to danmcd@sun.com using -f Date: Tue, 22 Sep 2009 13:04:35 -0400 From: Dan McDonald To: Scott C Moonen Message-ID: <20090922170435.GF3957@kebe.East.Sun.COM> References: <99043b4a0909220115r6b1a4decu36930c912b67895e@mail.gmail.com> <19128.48311.977915.880645@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.19 (2009-01-05) Cc: ipsec@ietf.org Subject: Re: [IPsec] IKEv2 NAT-T and Traffic Selectors X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 17:11:28 -0000 On Tue, Sep 22, 2009 at 12:52:51PM -0400, Scott C Moonen wrote: > Hi Matt. Our implementation works a little differently from Tero's, so > I'm replying just to provide a different perspective. > Our design decision does prevent our implementation from initiating to a > remote IPsec gateway if that gateway is behind a NAT, since we have > excluded the possibility of configuring addresses in the network behind > that NAT. We believe that initiating to a gateway behind a NAT is an > uncommon configuration, especially for our platform. Your design (which is similar to the one in Solaris/OpenSolaris) WOULD allow initiation to a behind-a-NAT peer if (and only if) the NAT was smart enough to redirect 500 and 4500 to a single entity inside its private network. (I'll be experimenting with this directly when I move into my new house this weekend, actually. :) Dan From smoonen@us.ibm.com Tue Sep 22 11:17:51 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF4B53A696D for ; Tue, 22 Sep 2009 11:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.389 X-Spam-Level: X-Spam-Status: No, score=-6.389 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgGZczAfDPbn for ; Tue, 22 Sep 2009 11:17:50 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by core3.amsl.com (Postfix) with ESMTP id 8CD913A698E for ; Tue, 22 Sep 2009 11:17:50 -0700 (PDT) Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e3.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n8MHVaId028007 for ; Tue, 22 Sep 2009 13:31:36 -0400 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8MHcrHO184594 for ; Tue, 22 Sep 2009 13:38:53 -0400 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n8MHe12p031824 for ; Tue, 22 Sep 2009 11:40:01 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av06.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n8MHe1TA031821; Tue, 22 Sep 2009 11:40:01 -0600 In-Reply-To: <20090922170435.GF3957@kebe.East.Sun.COM> References: <99043b4a0909220115r6b1a4decu36930c912b67895e@mail.gmail.com> <19128.48311.977915.880645@fireball.kivinen.iki.fi> <20090922170435.GF3957@kebe.East.Sun.COM> To: Dan McDonald MIME-Version: 1.0 X-KeepSent: B4BE8DFE:CE785E85-85257639:005F65CD; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 09/22/2009 01:31:10 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 09/22/2009 01:31:10 PM, Serialize complete at 09/22/2009 01:31:10 PM, S/MIME Sign failed at 09/22/2009 01:31:10 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V851_08302009|August 30, 2009) at 09/22/2009 11:38:44, Serialize complete at 09/22/2009 11:38:44 Message-ID: Date: Tue, 22 Sep 2009 13:38:43 -0400 Content-Type: multipart/alternative; boundary="=_alternative 00603D1285257639_=" Cc: ipsec@ietf.org Subject: Re: [IPsec] IKEv2 NAT-T and Traffic Selectors X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 18:17:52 -0000 This is a multipart message in MIME format. --=_alternative 00603D1285257639_= Content-Type: text/plain; charset="US-ASCII" Dan, > Your design (which is similar to the one in Solaris/OpenSolaris) WOULD allow > initiation to a behind-a-NAT peer if (and only if) the NAT was smart enough > to redirect 500 and 4500 to a single entity inside its private network. > (I'll be experimenting with this directly when I move into my new house this > weekend, actually. :) Certainly -- initiating to a peer behind a static NAT is not a problem for our implementation as long as we either use transport mode or elide IDi/IDr (i.e., end-to-end protecting all protocols). Initiating to a gateway behind that NAT is a problem, since you cannot populate IDr without knowing addresses in the foreign network. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Dan McDonald To: Scott C Moonen/Raleigh/IBM@IBMUS Cc: ipsec@ietf.org Date: 09/22/2009 01:20 PM Subject: Re: [IPsec] IKEv2 NAT-T and Traffic Selectors On Tue, Sep 22, 2009 at 12:52:51PM -0400, Scott C Moonen wrote: > Hi Matt. Our implementation works a little differently from Tero's, so > I'm replying just to provide a different perspective. > Our design decision does prevent our implementation from initiating to a > remote IPsec gateway if that gateway is behind a NAT, since we have > excluded the possibility of configuring addresses in the network behind > that NAT. We believe that initiating to a gateway behind a NAT is an > uncommon configuration, especially for our platform. Your design (which is similar to the one in Solaris/OpenSolaris) WOULD allow initiation to a behind-a-NAT peer if (and only if) the NAT was smart enough to redirect 500 and 4500 to a single entity inside its private network. (I'll be experimenting with this directly when I move into my new house this weekend, actually. :) Dan --=_alternative 00603D1285257639_= Content-Type: text/html; charset="US-ASCII"
      Dan,

      > Your design (which is similar to the one in Solaris/OpenSolaris) WOULD allow
      > initiation to a behind-a-NAT peer if (and only if) the NAT was smart enough
      > to redirect 500 and 4500 to a single entity inside its private network.
      > (I'll be experimenting with this directly when I move into my new house this
      > weekend, actually.  :)

      Certainly -- initiating to a peer behind a static NAT is not a problem for our implementation as long as we either use transport mode or elide IDi/IDr (i.e., end-to-end protecting all protocols).  Initiating to a gateway behind that NAT is a problem, since you cannot populate IDr without knowing addresses in the foreign network.


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


      From: Dan McDonald <danmcd@sun.com>
      To: Scott C Moonen/Raleigh/IBM@IBMUS
      Cc: ipsec@ietf.org
      Date: 09/22/2009 01:20 PM
      Subject: Re: [IPsec] IKEv2 NAT-T and Traffic Selectors




      On Tue, Sep 22, 2009 at 12:52:51PM -0400, Scott C Moonen wrote:
      > Hi Matt.  Our implementation works a little differently from Tero's, so
      > I'm replying just to provide a different perspective.

      <mucho snippage deleted!>

      > Our design decision does prevent our implementation from initiating to a
      > remote IPsec gateway if that gateway is behind a NAT, since we have
      > excluded the possibility of configuring addresses in the network behind
      > that NAT.  We believe that initiating to a gateway behind a NAT is an
      > uncommon configuration, especially for our platform.

      Your design (which is similar to the one in Solaris/OpenSolaris) WOULD allow
      initiation to a behind-a-NAT peer if (and only if) the NAT was smart enough
      to redirect 500 and 4500 to a single entity inside its private network.
      (I'll be experimenting with this directly when I move into my new house this
      weekend, actually.  :)

      Dan

      --=_alternative 00603D1285257639_=-- From ken.grewal@intel.com Thu Sep 24 11:12:49 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBDA13A6A93 for ; Thu, 24 Sep 2009 11:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.669 X-Spam-Level: X-Spam-Status: No, score=-5.669 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXxJRqYpCoB3 for ; Thu, 24 Sep 2009 11:12:46 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by core3.amsl.com (Postfix) with ESMTP id E01363A6A9A for ; Thu, 24 Sep 2009 11:12:45 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 24 Sep 2009 11:01:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.44,446,1249282800"; d="scan'208,217";a="729907318" Received: from rrsmsx602.amr.corp.intel.com ([10.31.0.33]) by fmsmga001.fm.intel.com with ESMTP; 24 Sep 2009 11:16:52 -0700 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx602.amr.corp.intel.com ([10.31.0.33]) with mapi; Thu, 24 Sep 2009 12:13:54 -0600 From: "Grewal, Ken" To: "ipsec@ietf.org" Date: Thu, 24 Sep 2009 12:13:00 -0600 Thread-Topic: WESP #109 - WESP header alignment for IPv6 Thread-Index: Aco7sTKmZquEp/CORCqTGV/aftvTEABjiCLw Message-ID: References: <99043b4a0909220115r6b1a4decu36930c912b67895e@mail.gmail.com> <19128.48311.977915.880645@fireball.kivinen.iki.fi> <20090922170435.GF3957@kebe.East.Sun.COM> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C49B4B6450D9AA48AB99694D2EB0A48334C7A51Drrsmsx505amrcor_" MIME-Version: 1.0 Subject: [IPsec] WESP #109 - WESP header alignment for IPv6 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 18:12:49 -0000 --_000_C49B4B6450D9AA48AB99694D2EB0A48334C7A51Drrsmsx505amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, During the IPsecME interim meeting earlier this week, there was initial con= sensus from the participants that the WESP header should be aligned on an 8= octet boundary for IPv6 in the following manner. We will extend the WESP header by a 4 octet reserved field (all zeros) and = use a new bit 'X' in the flags field to denote presence (or absence) of thi= s alignment field. This can be depicted as follows: Existing WESP header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | HdrLen | TrailerLen |V|V|E| Rsvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Proposed change 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | HdrLen | TrailerLen |V|V|E|X| Rsvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved (zeros) for IPv6 alignment | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If 'X' is set (value 1), the 4 octet reserved field is present (needed for = IPv6). If 'X' is clear (value 0), the 4 octet reserved field is absent (nee= ded for IPv4). This comment was from AD review of the document and ticket #109 has been ge= nerated to track this item. Any additional feedback? Thanks, - Ken --_000_C49B4B6450D9AA48AB99694D2EB0A48334C7A51Drrsmsx505amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

      All,

       

      During the IPsecME interim meeting earlier this week, there = was initial consensus from the participants that the WESP header should be aligned on a= n 8 octet boundary for IPv6 in the following manner.

       

      We will extend the WESP header by a 4 octet reserved field (= all zeros) and use a new bit ‘X’ in the flags field to denote presence (or absence) of this alignment field.

      This can be depicted as follows:

       

      Existing WESP header:

      0     &nb= sp;             1            &n= bsp;      2            &n= bsp;      3

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |  Next Header  |   HdrLen      |  TrailerLen  = ; |V|V|E|  Rsvd   | 

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       

      Proposed change<= /p>

      0     &nb= sp;             1     &n= bsp;            = ; 2            &n= bsp;      3

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+

      |  Next Header  |   HdrLen      |  TrailerLen  = ; |V|V|E|X| Rsvd  | 

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+

      |          = ;       Reserved (zeros) for IPv6 alignment       &nb= sp;   | 

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+

       

      If ‘X’ is set (value 1), the 4 octet reserved fi= eld is present (needed for IPv6). If ‘X’ is clear (value 0), the 4 octet reserved field is absent (needed for IPv4).

       

      This comment was from AD review of the document and ticket #= 109 has been generated to track this item.

       

      Any additional feedback?

       

      X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACD053A6915 for ; Thu, 24 Sep 2009 12:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqgmYJtFdge0 for ; Thu, 24 Sep 2009 12:55:09 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by core3.amsl.com (Postfix) with ESMTP id DEA603A6887 for ; Thu, 24 Sep 2009 12:55:09 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 24 Sep 2009 12:40:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.44,447,1249282800"; d="scan'208";a="451400940" Received: from rrsmsx602.amr.corp.intel.com ([10.31.0.33]) by orsmga002.jf.intel.com with ESMTP; 24 Sep 2009 13:02:15 -0700 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx602.amr.corp.intel.com ([10.31.0.33]) with mapi; Thu, 24 Sep 2009 13:56:16 -0600 From: "Grewal, Ken" To: Paul Hoffman , "ipsec@ietf.org" Date: Thu, 24 Sep 2009 13:55:22 -0600 Thread-Topic: [IPsec] WESP #109 - WESP header alignment for IPv6 Thread-Index: Aco9RwBeC0h7YQeNR5a8UZD1OeAzJgACeSkA Message-ID: References: <99043b4a0909220115r6b1a4decu36930c912b67895e@mail.gmail.com> <19128.48311.977915.880645@fireball.kivinen.iki.fi> <20090922170435.GF3957@kebe.East.Sun.COM> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] WESP #109 - WESP header alignment for IPv6 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 19:55:10 -0000 Thanks Paul and agreed. - Ken =20 >-----Original Message----- >From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] >Sent: Thursday, September 24, 2009 11:44 AM >To: Grewal, Ken; ipsec@ietf.org >Subject: Re: [IPsec] WESP #109 - WESP header alignment for IPv6 > >At 12:13 PM -0600 9/24/09, Grewal, Ken wrote: >>Proposed change >>0 1 2 3 >>0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>| Next Header | HdrLen | TrailerLen |V|V|E|X| Rsvd | >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>| Reserved (zeros) for IPv6 alignment | >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >No hat: > >I agree with the idea, but I would word it a bit differently. It's not >"reserved", it is actually used. "IPv6Padding (4 octets)" might make it >clearer. > >--Paul Hoffman, Director >--VPN Consortium From paul.hoffman@vpnc.org Thu Sep 24 20:02:51 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95E973A6405 for ; Thu, 24 Sep 2009 20:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.137 X-Spam-Level: X-Spam-Status: No, score=-5.137 tagged_above=-999 required=5 tests=[AWL=0.909, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mj1OiMxUrlym for ; Thu, 24 Sep 2009 20:02:50 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 985D63A6847 for ; Thu, 24 Sep 2009 20:02:50 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n8P2xDlJ044457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 Sep 2009 19:59:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 24 Sep 2009 19:59:12 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Recording of this week's interim WG meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 03:02:51 -0000 ... is available at ; it's about 30 megabytes (120 minutes). We will leave the slides from the meeting up at . I should have the minutes up early next week. --Paul Hoffman, Director --VPN Consortium From ynir@checkpoint.com Fri Sep 25 01:51:26 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 884D83A6965 for ; Fri, 25 Sep 2009 01:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYBztJu2d63R for ; Fri, 25 Sep 2009 01:51:25 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 5F9E43A6962 for ; Fri, 25 Sep 2009 01:51:25 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n8P8qXSr014636; Fri, 25 Sep 2009 11:52:33 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 25 Sep 2009 11:52:33 +0300 From: Yoav Nir To: Paul Hoffman Date: Fri, 25 Sep 2009 11:52:01 +0300 Thread-Topic: [IPsec] WESP #109 - WESP header alignment for IPv6 Thread-Index: Aco9vYVkwiYq51zxQcSglNhaYwiKew== Message-ID: <315A2D9A-E4EC-4D38-B115-E6226BFB7DE8@checkpoint.com> References: <99043b4a0909220115r6b1a4decu36930c912b67895e@mail.gmail.com> <19128.48311.977915.880645@fireball.kivinen.iki.fi> <20090922170435.GF3957@kebe.East.Sun.COM> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; micalg=sha1; boundary="Apple-Mail-3-683614465"; protocol="application/pkcs7-signature" MIME-Version: 1.0 Cc: "ipsec@ietf.org" , "Grewal, Ken" Subject: Re: [IPsec] WESP #109 - WESP header alignment for IPv6 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 08:51:26 -0000 --Apple-Mail-3-683614465 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes On Sep 24, 2009, at 9:44 PM, Paul Hoffman wrote: > At 12:13 PM -0600 9/24/09, Grewal, Ken wrote: >> Proposed change >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Next Header | HdrLen | TrailerLen |V|V|E|X| Rsvd | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Reserved (zeros) for IPv6 alignment | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > No hat: > > I agree with the idea, but I would word it a bit differently. It's > not "reserved", it is actually used. "IPv6Padding (4 octets)" might > make it clearer. Or maybe "extra 32 reserved bits" so that everyone can extend ESP :-) --Apple-Mail-3-683614465 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCCAuAw ggJJoAMCAQICEHWPmpet94anoiUADSB7pZcwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDUxOTIxMDYyOFoXDTEwMDUxOTIxMDYy OFowRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTeW5p ckBjaGVja3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN5Dac6srAGq YgV/Ggt0eXG8MRQRMR1SmIXm66utqDjcJhKDwKeyV5ICqQFr8ETbYZ7YgvSkXE7o9StCeqVvxKt0 hR5DTjho49VrCiaKex3q6d/VNh6E22yBqZBYbVa5xsxcPK6V2g/GXhyoNjoezeRVlRm0bbQtscKt GOt5BJFjjL5Ns/x0MktYgn24NIDnsTJKPEXl7vQzpwp6tnJJuiz/ttdW+7PII8vTkoHZpNGPW/aS bLR01T8ga739zosQ57YAdkih69BMHb+Q9zpRoSyd6NGEQ124TtskwWSAPAvw3TF2p0NlMKBU02Bt B07zkCodlx6sqOxeX7nVML26zI8CAwEAAaMwMC4wHgYDVR0RBBcwFYETeW5pckBjaGVja3BvaW50 LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAA+x/ZiahLKaSb/kWVGx2gJAGAG5 C065lmMky3hmur1IfUa9GBXJO40Z4CdiD6Y/4wQgHkBPnRF4YdhMjd2ecE03/9+x4grNKaXaeiIl MXQtniPa1tO++O/8eaPiMx6AF+v4njB/q0CUpYF78fTloJuhflNPvdbV46Xj41fIDoFAMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0 HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB1j5qXrfeGp6IlAA0ge6WXMAkGBSsOAwIa BQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDkyNTA4 NTIwMVowIwYJKoZIhvcNAQkEMRYEFAKCPpsar9i4Z7ZQHol1QjFLZ/2EMIGFBgkrBgEEAYI3EAQx eDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdY+al633hqei JQANIHullzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQdY+al633hqeiJQANIHullzANBgkqhkiG9w0BAQEFAASCAQDPAhVZJ8av qBazrftoqNLh9/a6LyX7RuR3NbKnTbBCEnXumTXcJT7aZtOGE+x89G3CvKs+paTMzk5Mc0eRDpmU sQaBh5Phs4rd84wI6vPTQwXUT5GxH0aGlYqoOQASqQDh0B3uY3MbpS0gDwBBMGXZR3CGSVaYaWAQ EtOILwJjk2K8nGVS5OIsR/x1ua1C9X9NgsZ8aDgVXMnZuqnOiJm8l0RokjPS3PGpUE9ZOcNFyMpy a6dPpCuSkVe5QzpzQms2PifGXRkx29TZP74vdnV39f+RO4hLoXMWiN59kj4Pvu6e/jPPBDtDf16s zTS4BaD6Da3FZCd0bn+BhApthPjMAAAAAAAA --Apple-Mail-3-683614465-- From paul.hoffman@vpnc.org Fri Sep 25 08:17:53 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3916E28C10F for ; Fri, 25 Sep 2009 08:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.149 X-Spam-Level: X-Spam-Status: No, score=-5.149 tagged_above=-999 required=5 tests=[AWL=0.897, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKmRAvBiV2jY for ; Fri, 25 Sep 2009 08:17:52 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 5E4D33A695D for ; Fri, 25 Sep 2009 08:17:52 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n8PF75MB089572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Sep 2009 08:07:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <315A2D9A-E4EC-4D38-B115-E6226BFB7DE8@checkpoint.com> References: <99043b4a0909220115r6b1a4decu36930c912b67895e@mail.gmail.com> <19128.48311.977915.880645@fireball.kivinen.iki.fi> <20090922170435.GF3957@kebe.East.Sun.COM> <315A2D9A-E4EC-4D38-B115-E6226BFB7DE8@checkpoint.com> Date: Fri, 25 Sep 2009 08:07:04 -0700 To: Yoav Nir From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "ipsec@ietf.org" , "Grewal, Ken" Subject: Re: [IPsec] WESP #109 - WESP header alignment for IPv6 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 15:17:53 -0000 At 11:52 AM +0300 9/25/09, Yoav Nir wrote: >On Sep 24, 2009, at 9:44 PM, Paul Hoffman wrote: > >>At 12:13 PM -0600 9/24/09, Grewal, Ken wrote: >>>Proposed change >>>0 1 2 3 >>>0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>| Next Header | HdrLen | TrailerLen |V|V|E|X| Rsvd | >>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>| Reserved (zeros) for IPv6 alignment | >>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >>No hat: >> >>I agree with the idea, but I would word it a bit differently. It's not "reserved", it is actually used. "IPv6Padding (4 octets)" might make it clearer. > >Or maybe "extra 32 reserved bits" so that everyone can extend ESP :-) You ended that with a smiley, but the intention is not clear. Ken proposed that the X flag *only* be used when there are IPv6 addresses, and that is what people on the call thought was right. Can you clarify whether you mean that you want this for *all* uses of WESP, or just for IPv6? If the former, why? --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Tue Sep 29 08:32:49 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7B0F3A69B5 for ; Tue, 29 Sep 2009 08:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.164 X-Spam-Level: X-Spam-Status: No, score=-5.164 tagged_above=-999 required=5 tests=[AWL=0.882, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+hgxqQp-Gff for ; Tue, 29 Sep 2009 08:32:48 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 3A3783A6AC0 for ; Tue, 29 Sep 2009 08:32:48 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n8TFPqHl006830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 29 Sep 2009 08:25:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 29 Sep 2009 08:25:50 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Fwd: 10th TAHI IPv6 Interoperability test event X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 15:32:49 -0000 This should be of interest to people here. At VPNC, we have seen very little uptake of IPv6 (see ), but I hope more IPsec implementers get involved soon. --Paul Hoffman >Hi, all. > >TAHI Project would like to announce about holding >10th TAHI IPv6 Interoperability test event. > > Date: Jan. 25-29, 2010 > Venue: Makuhari Messe, Makuhari, Japan > Target: Conformance & Interoperability tests > > * IPv6 Ready Logo Program Phase-2 > o IPv6 Core Protocols > o IPsec > o IKEv2 > o MIPv6 > o NEMO Basic Support > o DHCPv6 > o SIP > o SNMP (TBD) > o MLDv2 (router only) > o IMS (Trial) (UE only) > * Others > o KINK > o DNS > o MLDv2 (listener only) > >Registration has been started now. > >If you are interested in participating, >please visit to get details. > >Best regards, > > >-- >Yukiyo Akisada From kivinen@iki.fi Wed Sep 30 07:37:00 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D49133A698C for ; Wed, 30 Sep 2009 07:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-uwfGTp7Y8B for ; Wed, 30 Sep 2009 07:37:00 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id B51593A659C for ; Wed, 30 Sep 2009 07:36:59 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n8UEc4M3012109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Sep 2009 17:38:04 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n8UEc19n016416; Wed, 30 Sep 2009 17:38:01 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19139.27977.320898.239714@fireball.kivinen.iki.fi> Date: Wed, 30 Sep 2009 17:38:01 +0300 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: <19109.286.34505.162897@fireball.kivinen.iki.fi> <73BF7996-C4FA-4442-B49D-DDD710CACA87@checkpoint.com> <19109.11583.348236.158555@fireball.kivinen.iki.fi> <19120.57165.424835.989773@fireball.kivinen.iki.fi> <19128.37429.438136.60314@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 8 min Cc: "ipsec@ietf.org WG" , Yoav Nir , Paul Hoffman Subject: Re: [IPsec] Issue #26: Missing treatment of error cases X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 14:37:00 -0000 Scott C Moonen writes: > Tero, I don't understand. Two weeks ago you said: > > If you use that kind of halfway up IKE SA for sending INFORMATIONAL > > message to other end (who thinks the IKE SA is up and valid), then I > > agree that sending both N(AUTHENTICATION_FAILED) and DELETE would be > > the correct way to do it. DELETE only would also be ok. > > Now I think you are suggesting that DELETE is improper in this case, which > directly contradicts your earlier note. You can either send N(AUTHENTICATION_FAILED) or you can send DELETE, sending them both does not really help (if you send both you just say twice that delete this SA). Or you can simply log the situation to the local end and ask user to take corrective actions (for example if you are VPN client software) and assume that next connection with INITIAL_CONTACT or DPD will take care of the old IKE SA. The reason sending both of them might make sense is that it should be complatible with almost any implementation, i.e. those who consider N(AUTHENTICATION_FAILED) fatal will delete IKE SA because of that and those who do not, still delete the IKE SA because of the DELETE payload. As this is very small corner case which do not affect the interoperability, and in most situations it does not even have any perceivable effect on the whole system, I do not really have strong opinion in either way. It also depends what kind of other text we have. In my suggested text it is clear that N(AUTHENTICATION_FAILED) causes IKE SA to be deleted, so in that case sending delete would be unnecessary (i.e. N(AUTHENTICATION_FAILED) would be enough). With the RFC4306 text sending delete might be helpful (but not required). -- kivinen@iki.fi From kivinen@iki.fi Wed Sep 30 08:14:05 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B76493A6945 for ; Wed, 30 Sep 2009 08:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzWOwb9PNcIs for ; Wed, 30 Sep 2009 08:14:04 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id C5D0A3A68B5 for ; Wed, 30 Sep 2009 08:14:03 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n8UFFMOs017941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Sep 2009 18:15:22 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n8UFFMbT021751; Wed, 30 Sep 2009 18:15:22 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19139.30218.224175.430768@fireball.kivinen.iki.fi> Date: Wed, 30 Sep 2009 18:15:22 +0300 From: Tero Kivinen To: David Wierbowski In-Reply-To: References: <19127.28334.472030.873072@fireball.kivinen.iki.fi> <19128.47812.239136.479467@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 36 min X-Total-Time: 37 min Cc: IPsecme WG Subject: Re: [IPsec] #22 Simultaneous IKE SA rekey text X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 15:14:05 -0000 David Wierbowski writes: > I agree with what you stated here, but I feel you are addressing something > that is not limited to a simultaneous rekey of the IKE SA. It deals with > any > rekey of an IKE SA. In my opinion the text is misplaced and should be in a > section that deals with handling of outstanding exchanges when an IKE SA > is rekeyed. True. This wait is not really because of simultaneous rekey, but rekey in general. The reason I brought this up here, is that I think that wait is important and the solution for simulatenous rekey should be one that works with such wait. > With that said I'm not sure I agree with how you propose to > handle the outstanding exchanges. I do not think there is any other way than to wait some time to get them finished (or at least failed and acked). The other end who started those outstanding exchanges MUST know whether they were processed or not. If IKE SA is deleted immediately there is no way other end can know that as after IKE SA is deleted the other end does not send ACKs back. > > I agree it should mark the SA so that it is no longer used for the new > > SAs initiated from this end, but the other end might have its own > > exchanges ongoing when the rekey started, and waiting those to finish > > makes protocol work better. When both end mark the old SA as being > > "old", meaning no new exchanges are started on it, but old exchanges > > are allowed to finished then when those old exchanges are finished, > > then the old IKE SA should be deleted (and all operations done on the > > old IKE SA should be moved to the winning SA). > > This sounds like a good idea, but it's not what 4306 required and is a > protocol change. Not really. The RFC4306 do say that you MUST be able to process incoming requests while having your own requests out: 2.3. Window Size for Overlapping Requests ... .... An IKE endpoint MUST be prepared to accept and process a request while it has a request outstanding in order to avoid a deadlock in this situation. An IKE endpoint SHOULD be prepared to accept and process multiple requests while it has a request outstanding. I.e. when you have REKEY started and even when the rekey itself has finished, and delete request sent out (and even replied), you still might receive requests from the other end which were started before the REKEY was started. I agree that the behavior how to handle the deleting of IKE SA after rekey is not described explicitly in RFC4306, but the generic text that you MUST be able toprocess incoming requests while having your own requests out is there, and that is regardless what those requests are. > Based on 4306 I think when an informational exchange request is received > containing the delete of an IKE_SA that the receiver can conclude that most > likely any outstanding request will fail once a response to the delete is > sent. The receiver of the delete request has ways to deal with this. The other end cannot know that, and IKEv2 is deterministic protocol, thus such "most likely" is not enough for it. Here is example to show the situation: Host A Host B -------- ---------- <-- sends request packet is dropped by network it never reaches the host A starts rekey --> <-- replies to rekey starts IKE SA delete --> <-- replies to IKE SA delete Now Host A will delete all of the state of old IKE SA and cannot then process the request from Host B even if it ever reaches it. It cannot even send error back as the crypto keys and so on are already deleted. Host B does not know whether the request was processed or not, as situation could have also been this: Host A Host B -------- ---------- <-- sends request processes request and sends reply --> reply packet is dropped by network it never reaches the host B starts rekey --> <-- replies to rekey starts IKE SA delete --> <-- replies to IKE SA delete Now Host A thinks that the request host B sent was done and finished before rekey, but the Host B does not know that. Host A will not retransmit the reply packet unless host B retransmits its request, but if the IKE SA is deleted by A before that host B might not have time to ever send retransmission for its request, thus B does not know whether its request was processed or not. If host A delays deleting of the IKE SA so long that Host B's retransmissions reach it (i.e. time depending on the retransmission timers, i.e. for example 31.5 seconds if original retry timer is 500 ms, and retry timer is doubled after each retry, and retry limit is 6 packets) then after that time it knows that host B should have been able to finish ongoing exchanges during that time, thus it is safe to delete IKE SA after that. During that time it can either process the requests or fail them (I.e. it can fail the CREATE_CHILD_SA exchanges trying to create new Child SAs, or it can finish them, but if it finishes them, then it should make sure the Child SAs are moved to new IKE SA before old IKE SA is deleted. > It can delay sending a response until it receives responses to all > outstanding requests. It cannot as that could reach deadlock situation, and would be against the MUST in RFC4306, which says you MUST be able process a request while it has a request outstanding. > It can send a response immediately and conclude > that all outstanding requests will fail. In that case it can restart the > outstanding request on a newer IKE_SA or wait for traffic to require the > creation of a new SA. As the host A might have already processed the outstanding request before it even started the rekey, but the reply was lost, that would mean that the host A and B are out of sync. > > Sending some more suitable error could most likely also work, but > > still the IKE SA cannot be deleted immediately. It can only be deleted > > when ongoing exchanges have been finished. > > > > I have not checked out if your suggested version works with all > > possible combinations of simulatenous rekeys, but from the first look > > it seems it might also work. > > > > On the other hand there is no text indicating such behavior in the > > IKEv2 document, so it is protocol change compared to the old text > > which said that simulatenous rekey is processed by checking out the > > nonces. The rekeys in this case are simulatenous even when Host A > > didn't initially detect that. > > > > Agreed, so we have two possible protocol changes if we need to mandate one > or we could allow implementations solve the problem as they see fit. I > think > my solution is consistent with what is stated in Section 5.11.4 of RFC > 4718. > You are introducing the need to detect a simultaneous rekey after the fact. The RFC4306 says what you need to do when you see simultaneous rekey, and it only gives you one option: Check for the nonces. The rekey is simultaneous, if either end detects it was simultanoues, it is completely possible that other end didn't notice it. Not the that RFC4718 do consider even that case as simultanoues rekey, as given by the 5.11.3 as last example. It does give the N(NO_PROPOSAL_CHOSEN) option for handling that instead of checking for nonces, but I think RFC4718 is in error there, as RFC4306 still says you should use nonces even there. 5.11.4 says the simultaneous rekey is detect in the same way as was done in 5.11.3. And I think the 5.11.4 is also quite wrong there. Remember that RFC4718 is only Information RFC trying to clarify things in the RFC4306, the RFC4306 is still the standard track document which specifies how things are supposed to work. > > > That delay does not have anything to do with simultaneous rekey, it is > > needed to allow the ongoing exchanges to finish before old IKE SA is > > deleted. > > As I said earlier I think the ongoing exchange issue should be documented > separately from the simultaneous rekey case, although I agree there can > be a tie to it if your solution is agreed to. Yes, we need to add text for that in the ikev2bis somewhere. Where do you think it would be best? > > On the other hand RFC4306 specifies exactly ONE way to handle > > simulatenous rekey and that is by checking the nonces. The rekey is > > simulatenous even when one host didn't immediately detect it as > > simulatenous because some packet was lost. > > > > I agree now that "MUST NOT immediately delete" was too strong, so > > "SHOULD NOT immediately delete" is better. If implementation does not > > implement larger window sizes, and is used in environments where there > > is very limited number of CHILD SAs per IKE SA, so the probability of > > getting CREATE_CHILD_SA just when other ends decides to rekey is so > > small, that it does not matter even if the whole IKE SA gets deleted > > in that case then it can ignore that SHOULD. > > I think "SHOULD NOT immediately delete" is still too strong. I think > "MAY delay the deletion to allow ongoing exchanges to complete" is > more appropriate at this point. I think we should encourage people to allow ongoing exchanes to complete in the rekey case, so I think SHOULD is better than MAY. -- kivinen@iki.fi