From samu.varjonen@hiit.fi Sun Oct 3 23:55:16 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C73D3A6F3A for ; Sun, 3 Oct 2010 23:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSSt3SHiQAQp for ; Sun, 3 Oct 2010 23:55:15 -0700 (PDT) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 1F2AD3A6F2D for ; Sun, 3 Oct 2010 23:55:15 -0700 (PDT) Received: from [128.214.114.246] (wel-36.pc.hiit.fi [128.214.114.246]) by argo.otaverkko.fi (Postfix) with ESMTP id B527A25ED14; Mon, 4 Oct 2010 09:56:05 +0300 (EEST) Message-ID: <4CA97A85.4070709@hiit.fi> Date: Mon, 04 Oct 2010 09:56:05 +0300 From: Samu Varjonen User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: Ari Keranen , HIP References: <20100923104502.A5CA73A6951@core3.amsl.com> <4C9B337D.4000904@hiit.fi> <4C9B580A.4080808@nomadiclab.com> <4CA06B6E.3060308@hiit.fi> <4CA34445.6040007@nomadiclab.com> <4CA97A29.2080204@hiit.fi> In-Reply-To: <4CA97A29.2080204@hiit.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] draft-ietf-hip-cert-04 review X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 06:55:16 -0000 Hi, Forgot to CC the list :) On 04/10/10 09:54, Samu Varjonen wrote: > On 29/09/10 16:51, Ari Keranen wrote: >> On 09/27/2010 01:01 PM, Samu Varjonen wrote: >>> On 23/09/10 16:37, Ari Keranen wrote: >>>> Format: >>>> Issuer: CN=hit-of-host >>>> Subject: CN=hit-of-host >>>> >>>> X509v3 extensions: >>>> X509v3 Issuer Alternative Name: >>>> IP Address:HIT-OF-HOST >>>> X509v3 Subject Alternative Name: >>>> IP Address:HIT-OF-HOST >>>> >>>> From here (and especially from the example) one gets the idea that the >>>> exact same information would be there 4 times. The issuer and subject >>>> can be (and often are?) different, right? >>>> >>> >>> The answer is above the example. >>> >>> " >>> If only HIP information is presented as either >>> the issuer or the subject the HIT is also placed into the respective >>> entity's DNs Common Name (CN) section in a colon delimited >>> presentation format. *Inclusion of CN is not necessary if DN contains >>> any other information.* It is RECOMMENDED to use the FQDN/NAI from >>> the hosts HOST_ID parameter in the DN if one exists. >>> " >>> >>> Do you think that this needs clarification? >> >> Yes, that would help. >> >> For example, what is meant by "only HIP information" is not really >> clear. Also I guess it should say "DN's" instead of "DNs" in the text. >> And there isn't any text on whether the issuer and subject HITs can be >> different (the text and example implies that they're always identical). >> > > OK, I can change the example to contain different HITs as issuer and > subject and clarify the paragraph. > >>>> >>>> 6. Error signaling >>>> >>>> INVALID_CERTIFICATE 50 >>>> >>>> Sent in response to a failed verification of a certificate. >>>> Notification Data contains 4 octets, in order Cert group, >>>> Cert count, Cert ID, and Cert type of the certificate >>>> parameter that caused the failure. >>>> >>>> How does the verifier determine which certificate (if there are more >>>> than one) caused the failure? Isn't it rather always so that none of >>>> the >>>> given certificates were valid (for this particular use)? >>>> >>> >>> In most cases I would say that one failed verification fails the >>> verification of the whole chain. But in a case where you send two >>> certificates/chains for different services and the other one fails you >>> might want to know which failed. Registration extensions the REG_FAILED >>> would reveal the failed chain. I would like to leave the possibility to >>> tell the specific failed certificate for HIP-aware applications. So, >>> maybe it should say that the Notification Data MAY contain 4 octets... >> >> OK. But what if you send three (or more) certificates? > > If I followed you correctly the Notification Data would need more than 4 > octets to inform about more than one failed certificate in one or more > groups. How about "the Notification Data MAY contain n groups of 4 > octets (n calculated from the length of the parameter) . The group > contains octets in the following order: Cert group, Cert count, Cert ID, > and Cert type." > > Any other suggestions/ideas? > >> >> >> Cheers, >> Ari > From ari.keranen@nomadiclab.com Mon Oct 4 09:30:20 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B47DD3A7018 for ; Mon, 4 Oct 2010 09:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIiZtNOVtvEm for ; Mon, 4 Oct 2010 09:29:42 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 9C4753A7016 for ; Mon, 4 Oct 2010 09:29:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id A42844E6D7; Mon, 4 Oct 2010 19:30:26 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeimL+EZJnfS; Mon, 4 Oct 2010 19:30:25 +0300 (EEST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id B459F4E6C1; Mon, 4 Oct 2010 19:30:25 +0300 (EEST) Message-ID: <4CAA0121.1000102@nomadiclab.com> Date: Mon, 04 Oct 2010 19:30:25 +0300 From: Ari Keranen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8 MIME-Version: 1.0 To: "Henderson, Thomas R" References: <4C91C129.2090608@ericsson.com> <7CC566635CFE364D87DC5803D4712A6C4CEC45191B@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4CEC45191B@XCH-NW-10V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] WGLC: draft-ietf-hip-over-hip-01 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 16:30:20 -0000 Hi Tom, Thanks a lot for the review! Comments inline. On 09/29/2010 08:36 PM, Henderson, Thomas R wrote: > 3.1 Mode Negotiation > > In the second paragraph, perhaps clarify that if either an empty > HIP_TRANSPORT_MODE parameter or the absence of a HIP_TRANSPORT_MODE > parameter in the I2 packet will invoke the policy decision by the > responder (presently, it does not talk about what to do if no > parameter is returned in the I2). Good point. I changed the sentence describing this behavior into: Depending on local policy, the Responder MAY either abort the base exchange or continue HIP signaling without using an encrypted connection, if there was no HIP_TRANSPORT_MODE parameter in I2 or the parameter was empty. > 3.2 Mode Negotiation after HIP Base Exchange > > During the base exchange in 3.1, the initiator is not required to > respond (it is a SHOULD) but here, it is a MUST. I think it probably > should be relaxed to a SHOULD, or if not, can you please clarify why > it is a MUST here but not in 3.1? I assume you mean the following in 3.1: If the Initiator cannot or will not use any of the modes proposed by the Responder, the Initiator SHOULD include an empty HIP_TRANSPORT_MODE parameter to the I2 packet to signal that it support this extension but will not use any of the proposed modes. Now when you mentioned this, I would lean towards making it a MUST here too. I was thinking about use cases where one would not want to reveal support for this in BeX, but can't find really compelling ones. And this is important behavior for interoperability, so it would make sense to have it as MUST.. Or what do you think, are there cases which would make SHOULD really useful? > Likewise, at the end of this section, it probably should be stated > that the host that receives the acknowledged UPDATE that does not > contain any parameter will make a local policy decision whether to > continue or close the association. If it were to decide to close the > association, perhaps it would be good practice to have it issue a > Notify before it closes down. True, if we end up making this SHOULD level, that would make sense. > 3.3 HIP Messages on Encrypted Connections > > "HIP messages that result in changing or generating new keying > material, i.e., the base exchange and re-keying UPDATE messages, > MUST NOT be sent over an encrypted connection that is created using > the keying material that is being changed." > > I think that the above could be more clearly stated as: > > "HIP messages that result in changing or generating new keying > material, i.e., the base exchange and re-keying UPDATE messages, > MUST NOT be sent over an encrypted connection using the newly > created keying material. It should be obvious that messages that > generate new keying material cannot be sent over sessions that > require the keying material to already be in place, but this > statement pertains to the case in which one side of the association > has obtained the new keying material but the other has not, such as > an R2 or UPDATE ACK packet." > > (if you agree that the above is what is intended). Actually, the intention with that text was that one would not send those messages over the connection using the *old* keying material. This change was made when Jan commented that using the encrypted connection would result in unnecessary complexity with SA selection and retransmissions: http://www.ietf.org/mail-archive/web/hipsec/current/msg02975.html That said, I could clarify that neither the new keying material can be used. I guess adding "nor over an encrypted connection using the newly created keying material" to the end would be sufficient. Or do you think it still needs the additional clarification? > 3.3.2 ESP-TCP mode > > s/lower HIT/smaller HIT/ Good catch, fixed. > 3.4 Recovering from Failed Encrypted Connections > > "Hence, while listening for incoming HIP messages on the encrypted > connection, hosts MUST still accept incoming HIP messages using the > same transport method (e.g., UDP or plain IP) that was used for the > base exchange. When responding to a HIP message sent outside of > encrypted connection, the response MUST be sent using the same > transport method as the original message used." > > It seems to me that the specification allows a host to negotiate the > use of encrypted mode, but then can disregard the "MUST send over > ESP" (seciton 3.2) and send outside of the security association, and > the peer must use non-encrypted messaging according to the above > text. Is this what is intended, or should there be some statement > such as "if the host receives a HIP message outside of an encrypted > connection when the encrypted mode has previously been negotiated, it > MAY or SHOULD conclude that the ESP association is failed and must be > restarted."? The "MUST" in 3.2. means that "MUST send over ESP as long as the ESP tunnel works". The latter part was implicit, but I could make it more explicit there. Also, hosts should not send other than encryption-reestablishment-messages outside of the encrypted connections; I'll clarify this too. I added to the end of that paragraph: Hosts SHOULD send outside of the encrypted connection only HIP messages that are used to reestablish the encrypted connection. Especially, messages that are intended to be sent only encrypted (e.g., DATA messages using an encrypted transport mode) MUST NOT be sent before the encrypted connection is reestablished. > 4. Notify Packet Types > > The indentation of the last paragraph should be moved leftward. > > s/If a host sends UPDATE/If a host sends an UPDATE/ s/it sends > back/the receiving host sends back/ Good catch here too. > 5. Security > > s/Thus, host requiring/Thus, a host requiring/ Fixed. > 6. IANA > > Should the document specify to IANA that whatever type value is > selected must have lower bit equal to zero, so that the parameter is > interpreted as being non-critical? I think it's enough if we propose such a value in this document (as we do) and make sure IANA uses that, like we've done with the other documents so far. Cheers, Ari From ari.keranen@nomadiclab.com Tue Oct 5 01:22:22 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB89D3A6EEA for ; Tue, 5 Oct 2010 01:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 tvHbCY8jBw4N for ; Tue, 5 Oct 2010 01:22:21 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 0FC0F3A6CD5 for ; Tue, 5 Oct 2010 01:22:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 239604E6D7; Tue, 5 Oct 2010 11:23:11 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZJ47EkcoW23; Tue, 5 Oct 2010 11:23:10 +0300 (EEST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 91F884E6C1; Tue, 5 Oct 2010 11:23:10 +0300 (EEST) Message-ID: <4CAAE06E.2020609@nomadiclab.com> Date: Tue, 05 Oct 2010 11:23:10 +0300 From: Ari Keranen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8 MIME-Version: 1.0 To: Samu Varjonen References: <20100923104502.A5CA73A6951@core3.amsl.com> <4C9B337D.4000904@hiit.fi> <4C9B580A.4080808@nomadiclab.com> <4CA06B6E.3060308@hiit.fi> <4CA34445.6040007@nomadiclab.com> <4CA97A29.2080204@hiit.fi> <4CA97A85.4070709@hiit.fi> In-Reply-To: <4CA97A85.4070709@hiit.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] draft-ietf-hip-cert-04 review X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 08:22:22 -0000 On 10/04/2010 09:56 AM, Samu Varjonen wrote: > On 04/10/10 09:54, Samu Varjonen wrote: >> On 29/09/10 16:51, Ari Keranen wrote: >>> On 09/27/2010 01:01 PM, Samu Varjonen wrote: >>>> On 23/09/10 16:37, Ari Keranen wrote: >>>>> >>>>> 6. Error signaling >>>>> >>>>> INVALID_CERTIFICATE 50 >>>>> >>>>> Sent in response to a failed verification of a certificate. >>>>> Notification Data contains 4 octets, in order Cert group, >>>>> Cert count, Cert ID, and Cert type of the certificate >>>>> parameter that caused the failure. >>>>> >>>>> How does the verifier determine which certificate (if there are more >>>>> than one) caused the failure? Isn't it rather always so that none of >>>>> the >>>>> given certificates were valid (for this particular use)? >>>>> >>>> >>>> In most cases I would say that one failed verification fails the >>>> verification of the whole chain. But in a case where you send two >>>> certificates/chains for different services and the other one fails you >>>> might want to know which failed. Registration extensions the REG_FAILED >>>> would reveal the failed chain. I would like to leave the possibility to >>>> tell the specific failed certificate for HIP-aware applications. So, >>>> maybe it should say that the Notification Data MAY contain 4 octets... >>> >>> OK. But what if you send three (or more) certificates? >> >> If I followed you correctly the Notification Data would need more than 4 >> octets to inform about more than one failed certificate in one or more >> groups. How about "the Notification Data MAY contain n groups of 4 >> octets (n calculated from the length of the parameter) . The group >> contains octets in the following order: Cert group, Cert count, Cert ID, >> and Cert type." >> >> Any other suggestions/ideas? We could be looking into a really corner case here (how often would one send more than one or two certificates?), but assuming this would happen, my point was that there will likely be no single certificate (chain) that fails, but rather all but one (or some) fail. Also some certificates may fail for some registration (or other requested service) types and others for different types with a single HIP message. Hence, there could be a problem on how to match those with each other in the NOTIFY. Anyhow, probably this problem is not that severe that we should add much complexity into the draft to solve this and having identifiers for (all) the failed certificates (i.e., those that were not accepted for any of the requested services) in the Notification data, as you suggested, is sufficient. By the way, wouldn't Cert group and ID be sufficient information in the Notification data? Cheers, Ari From thomas.r.henderson@boeing.com Wed Oct 6 21:48:15 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87DC43A687E for ; Wed, 6 Oct 2010 21:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.375 X-Spam-Level: X-Spam-Status: No, score=-106.375 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCtiVZCRIJnO for ; Wed, 6 Oct 2010 21:48:14 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id B9AA23A6FD9 for ; Wed, 6 Oct 2010 21:48:13 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o974n4PT021347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 Oct 2010 21:49:05 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o974n47w003637; Wed, 6 Oct 2010 23:49:04 -0500 (CDT) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o974n35W003631 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 6 Oct 2010 23:49:03 -0500 (CDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Wed, 6 Oct 2010 21:49:03 -0700 From: "Henderson, Thomas R" To: Ari Keranen Date: Wed, 6 Oct 2010 21:49:02 -0700 Thread-Topic: [Hipsec] WGLC: draft-ietf-hip-over-hip-01 Thread-Index: Actj5NTFJ+f6WIIfSIq1+dOjDWg16AB2BCFA Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CEC60A500@XCH-NW-10V.nw.nos.boeing.com> References: <4C91C129.2090608@ericsson.com> <7CC566635CFE364D87DC5803D4712A6C4CEC45191B@XCH-NW-10V.nw.nos.boeing.com> <4CAA0121.1000102@nomadiclab.com> In-Reply-To: <4CAA0121.1000102@nomadiclab.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: HIP Subject: Re: [Hipsec] WGLC: draft-ietf-hip-over-hip-01 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 04:48:15 -0000 Ari, some responses to the open issues remaining in your reply, in-line bel= ow: > > > 3.2 Mode Negotiation after HIP Base Exchange > > > > During the base exchange in 3.1, the initiator is not required to > > respond (it is a SHOULD) but here, it is a MUST. I think > it probably > > should be relaxed to a SHOULD, or if not, can you please clarify why > > it is a MUST here but not in 3.1? > > I assume you mean the following in 3.1: > > If the Initiator cannot or will not use any of the modes > proposed by > the Responder, the Initiator SHOULD include an empty > HIP_TRANSPORT_MODE parameter to the I2 packet to signal that it > support this extension but will not use any of the proposed modes. Yes > > Now when you mentioned this, I would lean towards making it a > MUST here > too. I was thinking about use cases where one would not want > to reveal > support for this in BeX, but can't find really compelling > ones. And this > is important behavior for interoperability, so it would make sense to > have it as MUST.. Or what do you think, are there cases which > would make > SHOULD really useful? I don't think it really matters from the Initiator's perspective whether it= is a SHOULD or MUST, because this is a non-critical parameter. Even if th= e supporting Responder MUST reply, the non-supporting Responder will not re= ply, and the Initiator has to handle both cases. I'm neutral to whether this should be a SHOULD or MUST; suggest to just pic= k the same one in both cases. > > > Likewise, at the end of this section, it probably should be stated > > that the host that receives the acknowledged UPDATE that does not > > contain any parameter will make a local policy decision whether to > > continue or close the association. If it were to decide to > close the > > association, perhaps it would be good practice to have it issue a > > Notify before it closes down. > > True, if we end up making this SHOULD level, that would make sense. It seems to me to be somewhat independent of the SHOULD or MUST; it is a ma= tter of whether to help the Responder to log the reason why the Initiator d= ecided to shut down the association. > > > 3.3 HIP Messages on Encrypted Connections > > > > "HIP messages that result in changing or generating new keying > > material, i.e., the base exchange and re-keying UPDATE messages, > > MUST NOT be sent over an encrypted connection that is created using > > the keying material that is being changed." > > > > I think that the above could be more clearly stated as: > > > > "HIP messages that result in changing or generating new keying > > material, i.e., the base exchange and re-keying UPDATE messages, > > MUST NOT be sent over an encrypted connection using the newly > > created keying material. It should be obvious that messages that > > generate new keying material cannot be sent over sessions that > > require the keying material to already be in place, but this > > statement pertains to the case in which one side of the association > > has obtained the new keying material but the other has not, such as > > an R2 or UPDATE ACK packet." > > > > (if you agree that the above is what is intended). > > Actually, the intention with that text was that one would not > send those > messages over the connection using the *old* keying material. This Yes, I read it the other way. > change was made when Jan commented that using the encrypted > connection > would result in unnecessary complexity with SA selection and > retransmissions: > http://www.ietf.org/mail-archive/web/hipsec/current/msg02975.html > > That said, I could clarify that neither the new keying > material can be > used. I guess adding "nor over an encrypted connection using > the newly > created keying material" to the end would be sufficient. Or > do you think > it still needs the additional clarification? I would be fine with your suggested brief change above. > > 6. IANA > > > > Should the document specify to IANA that whatever type value is > > selected must have lower bit equal to zero, so that the parameter is > > interpreted as being non-critical? > > I think it's enough if we propose such a value in this > document (as we > do) and make sure IANA uses that, like we've done with the other > documents so far. OK - Tom From samu.varjonen@hiit.fi Thu Oct 7 02:13:46 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9F4B3A6EF3 for ; Thu, 7 Oct 2010 02:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 HJUwyTPhzvv2 for ; Thu, 7 Oct 2010 02:13:45 -0700 (PDT) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id A08573A6E47 for ; Thu, 7 Oct 2010 02:13:44 -0700 (PDT) Received: from [128.214.114.246] (wel-36.pc.hiit.fi [128.214.114.246]) by argo.otaverkko.fi (Postfix) with ESMTP id 9B03925ED2D; Thu, 7 Oct 2010 12:14:45 +0300 (EEST) Message-ID: <4CAD8F85.50707@hiit.fi> Date: Thu, 07 Oct 2010 12:14:45 +0300 From: Samu Varjonen User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: Ari Keranen , HIP References: <20100923104502.A5CA73A6951@core3.amsl.com> <4C9B337D.4000904@hiit.fi> <4C9B580A.4080808@nomadiclab.com> <4CA06B6E.3060308@hiit.fi> <4CA34445.6040007@nomadiclab.com> <4CA97A29.2080204@hiit.fi> <4CA97A85.4070709@hiit.fi> <4CAAE06E.2020609@nomadiclab.com> In-Reply-To: <4CAAE06E.2020609@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] draft-ietf-hip-cert-04 review X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 09:13:46 -0000 On 05/10/10 11:23, Ari Keranen wrote: > On 10/04/2010 09:56 AM, Samu Varjonen wrote: >> On 04/10/10 09:54, Samu Varjonen wrote: >>> On 29/09/10 16:51, Ari Keranen wrote: >>>> On 09/27/2010 01:01 PM, Samu Varjonen wrote: >>>>> On 23/09/10 16:37, Ari Keranen wrote: >>>>>> >>>>>> 6. Error signaling >>>>>> >>>>>> INVALID_CERTIFICATE 50 >>>>>> >>>>>> Sent in response to a failed verification of a certificate. >>>>>> Notification Data contains 4 octets, in order Cert group, >>>>>> Cert count, Cert ID, and Cert type of the certificate >>>>>> parameter that caused the failure. >>>>>> >>>>>> How does the verifier determine which certificate (if there are more >>>>>> than one) caused the failure? Isn't it rather always so that none of >>>>>> the >>>>>> given certificates were valid (for this particular use)? >>>>>> >>>>> >>>>> In most cases I would say that one failed verification fails the >>>>> verification of the whole chain. But in a case where you send two >>>>> certificates/chains for different services and the other one fails you >>>>> might want to know which failed. Registration extensions the >>>>> REG_FAILED >>>>> would reveal the failed chain. I would like to leave the >>>>> possibility to >>>>> tell the specific failed certificate for HIP-aware applications. So, >>>>> maybe it should say that the Notification Data MAY contain 4 octets... >>>> >>>> OK. But what if you send three (or more) certificates? >>> >>> If I followed you correctly the Notification Data would need more than 4 >>> octets to inform about more than one failed certificate in one or more >>> groups. How about "the Notification Data MAY contain n groups of 4 >>> octets (n calculated from the length of the parameter) . The group >>> contains octets in the following order: Cert group, Cert count, Cert ID, >>> and Cert type." >>> >>> Any other suggestions/ideas? > > We could be looking into a really corner case here (how often would one > send more than one or two certificates?), but assuming this would > happen, my point was that there will likely be no single certificate > (chain) that fails, but rather all but one (or some) fail. > > Also some certificates may fail for some registration (or other > requested service) types and others for different types with a single > HIP message. Hence, there could be a problem on how to match those with > each other in the NOTIFY. > > Anyhow, probably this problem is not that severe that we should add much > complexity into the draft to solve this and having identifiers for (all) > the failed certificates (i.e., those that were not accepted for any of > the requested services) in the Notification data, as you suggested, is > sufficient. OK > > By the way, wouldn't Cert group and ID be sufficient information in the > Notification data? Yes, it would be, the count and type are not really necessary. > > > Cheers, > Ari From ari.keranen@nomadiclab.com Mon Oct 11 05:47:28 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D44563A6A03 for ; Mon, 11 Oct 2010 05:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 88iOYrTHBydW for ; Mon, 11 Oct 2010 05:47:27 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 53BA73A69E8 for ; Mon, 11 Oct 2010 05:47:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id BA5534E6F0; Mon, 11 Oct 2010 15:48:37 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9hMueErBTnx; Mon, 11 Oct 2010 15:48:36 +0300 (EEST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 943E84E6EE; Mon, 11 Oct 2010 15:48:36 +0300 (EEST) Message-ID: <4CB307A4.3030001@nomadiclab.com> Date: Mon, 11 Oct 2010 15:48:36 +0300 From: Ari Keranen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8 MIME-Version: 1.0 To: "Henderson, Thomas R" References: <4C91C129.2090608@ericsson.com> <7CC566635CFE364D87DC5803D4712A6C4CEC45191B@XCH-NW-10V.nw.nos.boeing.com> <4CAA0121.1000102@nomadiclab.com> <7CC566635CFE364D87DC5803D4712A6C4CEC60A500@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4CEC60A500@XCH-NW-10V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] WGLC: draft-ietf-hip-over-hip-01 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 12:47:29 -0000 Tom, Thanks for the follow-up comments, I've updated the draft accordingly. Details in-line. On 10/07/2010 07:49 AM, Henderson, Thomas R wrote: > Ari, some responses to the open issues remaining in your reply, > in-line below: > >> >>> 3.2 Mode Negotiation after HIP Base Exchange >>> >>> During the base exchange in 3.1, the initiator is not required >>> to respond (it is a SHOULD) but here, it is a MUST. I think >> it probably >>> should be relaxed to a SHOULD, or if not, can you please clarify >>> why it is a MUST here but not in 3.1? >> >> I assume you mean the following in 3.1: >> >> If the Initiator cannot or will not use any of the modes proposed >> by the Responder, the Initiator SHOULD include an empty >> HIP_TRANSPORT_MODE parameter to the I2 packet to signal that it >> support this extension but will not use any of the proposed modes. > > Yes > >> >> Now when you mentioned this, I would lean towards making it a MUST >> here too. I was thinking about use cases where one would not want >> to reveal support for this in BeX, but can't find really >> compelling ones. And this is important behavior for >> interoperability, so it would make sense to have it as MUST.. Or >> what do you think, are there cases which would make SHOULD really >> useful? > > I don't think it really matters from the Initiator's perspective > whether it is a SHOULD or MUST, because this is a non-critical > parameter. Even if the supporting Responder MUST reply, the > non-supporting Responder will not reply, and the Initiator has to > handle both cases. > > I'm neutral to whether this should be a SHOULD or MUST; suggest to > just pick the same one in both cases. You have a point; I changed this into SHOULD. >>> Likewise, at the end of this section, it probably should be >>> stated that the host that receives the acknowledged UPDATE that >>> does not contain any parameter will make a local policy decision >>> whether to continue or close the association. If it were to >>> decide to >> close the >>> association, perhaps it would be good practice to have it issue >>> a Notify before it closes down. >> >> True, if we end up making this SHOULD level, that would make >> sense. > > It seems to me to be somewhat independent of the SHOULD or MUST; it > is a matter of whether to help the Responder to log the reason why > the Initiator decided to shut down the association. OK, I changed the last paragraph into: Since the HIP_TRANSPORT_MODE parameter's type is not critical (as defined in Section 5.2.1 of [RFC5201]), a host not supporting this extension would simply reply with an acknowledgement UPDATE packet without a HIP_TRANSPORT_MODE parameter. In such a case, depending on local policy as in mode negotiation during the base exchange, the host that requested the new transport mode MAY close the HIP association. If the association is closed, the host closing the association SHOULD send a NO_VALID_HIP_TRANSPORT_MODE NOTIFY packet to the other host before closing the association. I also clarified the negotiation in BeX section to have the same logic (should send the notify when aborting BeX due to HIP_TRANSPORT_MODE parameter; if there's no valid mode or the parameter was not there but is needed to continue). Now it says: Depending on local policy, the Responder MAY either abort the base exchange or continue HIP signaling without using an encrypted connection, if there was no HIP_TRANSPORT_MODE parameter in I2 or the parameter was empty. If the Initiator selects a mode that the Responder does not support (and hence was not included in R1), the Responder MUST abort the base exchange. If the base exchange is aborted due to (possibly lack of) HIP_TRANSPORT_PARAMETER, the Responder SHOULD send a NO_VALID_HIP_TRANSPORT_MODE NOTIFY packet (see Section 4) to the Initiator. Cheers, Ari From heer@informatik.rwth-aachen.de Wed Oct 13 09:11:52 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22A7F3A682A for ; Wed, 13 Oct 2010 09:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=-0.556, BAYES_20=-0.74, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 FlHP7cympzAO for ; Wed, 13 Oct 2010 09:11:47 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 86D953A6A11 for ; Wed, 13 Oct 2010 09:11:40 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LA8005JUL1KY460@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Wed, 13 Oct 2010 18:12:56 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.57,326,1283724000"; d="scan'208";a="76760525" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Wed, 13 Oct 2010 18:12:56 +0200 Received: from informatik-lufgi-4-137-226-59-218.nn.rwth-aachen.de ([unknown] [137.226.59.218]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LA800GEPL1KD780@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Wed, 13 Oct 2010 18:12:56 +0200 (CEST) From: Tobias Heer Date: Wed, 13 Oct 2010 18:12:55 +0200 Message-id: <917A9DF6-17C4-4AAF-9132-1A865D0A824B@cs.rwth-aachen.de> To: HIP WG X-Mailer: Apple Mail (2.1081) Subject: [Hipsec] Completing 5201 state machine X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 16:11:53 -0000 Hello, the state machine of RFC5201 (not -bis) has some white spots which I try to cover now. Nothing essential is missing but it seems slightly underspecified the way it is now. Handling of the following packets is missing in some states: CLOSE, CLOSE_ACK, and NOTIFY. And it is not caught by the "handle ANYOTHER" rules that serve as catch-all. I'll list the changes that I'll make here and ask for feedback from the group and especially implementors. 1.) Receive CLOSE in state I2-sent: ------------------------------ Why can this happen? - R2 is lost (maybe repeatedly), Responder transitions to from R2-SENT to ESTABLISHED because of timeout, Responder decides to close association (because of some reason) Proposed action: process packet - successful: transition to CLOSING - fail: drop and stay at I2-sent 2.) Receive CLOSE in state R2-sent ------------------------------ Why can this happen? - Responder cannot observe data packet flow (this is the case for some implementations), Responder timeout for transition from R2-SENT to ESTABLISHED has not fired yet, Initiator decides to close association (because of some reason) Proposed action: process packet - successful: transition to CLOSING - fail: drop and stay at R2-sent 3.) Receive CLOSE_ACK in state R2-sent ------------------------------ Why can this happen? - It shouldn't but there is nothing specified. Proposed action: drop 4.) Receive NOTIFY in state R2-sent ------------------------------ Why can this happen? - Responder cannot observe the data channel and timeout has not fired yet. Proposed action: process and stay in R2 sent 5.) Receive CLOSE_ACK in state ESTABLISHED ------------------------------ Why can this happen? - It shouldn't but there is nothing specified. Proposed action: drop 6. Receive NOTIFY in state ESTABLISHED ------------------------------ Why can this happen? - Well, there are many reasons for this. This is normal behavior. Proposed action: process and stay in ESTABLISHED I would appreciate if you could have a look at the proposed changes and give feedback. None of the changes has dramatic effects on existing implementations of HIPv1 but 1) and 2) might require some minor change of code if the implementations don't handle (or handle differently) the CLOSE messages in these states. BR, Tobias -- Dipl.-Inform. Tobias Heer, Ph.D. Student Chair of Communication and Distributed Systems - comsys RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi From root@core3.amsl.com Mon Oct 18 05:15:05 2010 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4D2D43A6D9E; Mon, 18 Oct 2010 05:15:05 -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: <20101018121505.4D2D43A6D9E@core3.amsl.com> Date: Mon, 18 Oct 2010 05:15:05 -0700 (PDT) Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-over-hip-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 12:15:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol Signaling Message Transport Modes Author(s) : A. Keranen Filename : draft-ietf-hip-over-hip-02.txt Pages : 9 Date : 2010-10-18 This document specifies two transport modes for Host Identity Protocol (HIP) signaling messages that allow conveying them over encrypted connections initiated with the Host Identity Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-over-hip-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-hip-over-hip-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-18051304.I-D@ietf.org> --NextPart-- From ari.keranen@nomadiclab.com Mon Oct 18 05:28:07 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F4473A6A9E for ; Mon, 18 Oct 2010 05:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQQBeUpcWPbJ for ; Mon, 18 Oct 2010 05:28:06 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 2476A3A6ADC for ; Mon, 18 Oct 2010 05:28:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 1E1AD4E6EB for ; Mon, 18 Oct 2010 15:29:33 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsiLMLNxBpF7 for ; Mon, 18 Oct 2010 15:29:32 +0300 (EEST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 8A1464E6DE for ; Mon, 18 Oct 2010 15:29:32 +0300 (EEST) Message-ID: <4CBC3DAC.7020404@nomadiclab.com> Date: Mon, 18 Oct 2010 15:29:32 +0300 From: Ari Keranen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8 MIME-Version: 1.0 To: hipsec@ietf.org References: <20101018121505.4D2D43A6D9E@core3.amsl.com> In-Reply-To: <20101018121505.4D2D43A6D9E@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] I-D Action:draft-ietf-hip-over-hip-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 12:28:07 -0000 Hi all, This updated version addresses all the comments given during the WGLC, changes the proposed NOTIFY packet type to avoid clash with taken values, updates the IANA section regarding the NOTIFY type, updates the security section with short note about security of different ESP transforms, and has some editorial fixes. For details, see the diff: http://tools.ietf.org/rfcdiff?url2=draft-ietf-hip-over-hip-02 Cheers, Ari On 10/18/2010 03:15 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Host Identity Protocol Working Group of the IETF. > > > Title : Host Identity Protocol Signaling Message Transport Modes > Author(s) : A. Keranen > Filename : draft-ietf-hip-over-hip-02.txt > Pages : 9 > Date : 2010-10-18 > > This document specifies two transport modes for Host Identity > Protocol (HIP) signaling messages that allow conveying them over > encrypted connections initiated with the Host Identity Protocol. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-hip-over-hip-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. From root@core3.amsl.com Mon Oct 18 11:15:17 2010 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4F4743A6DF6; Mon, 18 Oct 2010 11:15: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: <20101018181508.4F4743A6DF6@core3.amsl.com> Date: Mon, 18 Oct 2010 11:15:01 -0700 (PDT) Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-rfc5206-bis-01.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 18:15:17 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Mobility with the Host Identity Protocol Author(s) : P. Nikander, et al. Filename : draft-ietf-hip-rfc5206-bis-01.txt Pages : 32 Date : 2010-10-18 This document defines mobility extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general "LOCATOR" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host -- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR parameter can also be used to support end-host multihoming, detailed procedures are out of scope for this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-rfc5206-bis-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-hip-rfc5206-bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-18111307.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 18 11:15:22 2010 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5CC0C3A6B90; Mon, 18 Oct 2010 11:15:07 -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: <20101018181521.5CC0C3A6B90@core3.amsl.com> Date: Mon, 18 Oct 2010 11:15:08 -0700 (PDT) Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-multihoming-00.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 18:15:23 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Multihoming with the Host Identity Protocol Author(s) : P. Nikander, et al. Filename : draft-ietf-hip-multihoming-00.txt Pages : 22 Date : 2010-10-18 This document defines host multihoming extensions to the Host Identity Protocol (HIP), by leveraging protocol components defined for host mobility. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-multihoming-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. --NextPart Content-Type: Message/External-body; name="draft-ietf-hip-multihoming-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-18111414.I-D@ietf.org> --NextPart-- From thomas.r.henderson@boeing.com Mon Oct 18 12:04:40 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 752C43A6E7E for ; Mon, 18 Oct 2010 12:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.117 X-Spam-Level: X-Spam-Status: No, score=-106.117 tagged_above=-999 required=5 tests=[AWL=0.482, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyDQxoEqnIYy for ; Mon, 18 Oct 2010 12:04:39 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 46E003A6E66 for ; Mon, 18 Oct 2010 12:04:26 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o9IJ5ntY015389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 18 Oct 2010 12:05:50 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o9IJ5mxs000427 for ; Mon, 18 Oct 2010 14:05:48 -0500 (CDT) Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o9IJ5Rbg029369 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Mon, 18 Oct 2010 14:05:47 -0500 (CDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Mon, 18 Oct 2010 12:05:37 -0700 From: "Henderson, Thomas R" To: HIP Date: Mon, 18 Oct 2010 12:05:36 -0700 Thread-Topic: new mobility/multihoming drafts posted Thread-Index: Actu93Ln22RGx85+SMmbBdZK35TdOg== Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CEC4519F9@XCH-NW-10V.nw.nos.boeing.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: [Hipsec] new mobility/multihoming drafts posted X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 19:04:40 -0000 I've posted two drafts today that implement the document split discussed at= IETF 77 regarding RFC5206-bis. The first draft removes the multihoming-sp= ecific content from RFC5206-bis: http://www.ietf.org/internet-drafts/draft-ietf-hip-rfc5206-bis-01.txt and the second draft adds that content back into a new multihoming draft: http://www.ietf.org/internet-drafts/draft-ietf-hip-multihoming-00.txt However, there are no normative specification changes yet to the above two = documents, nor are there any attempts to improve them editorially. We can = now start to work on improving each of the documents and aligning with the = other -bis documents. I have started to use the WG tracker to track issues for mobility and multi= homing revisions. I've listed all of the issues that I have in my notes wi= th respect to RFC5206(bis); if I am forgetting any, please remind me or upd= ate the tracker yourself. http://trac.tools.ietf.org/wg/hip/trac/report/1 - Tom From thomas.r.henderson@boeing.com Mon Oct 18 16:40:31 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D39F3A6C06 for ; Mon, 18 Oct 2010 16:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.165 X-Spam-Level: X-Spam-Status: No, score=-106.165 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNPEZ0Cc9tBQ for ; Mon, 18 Oct 2010 16:40:30 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 2ADCD3A6BF6 for ; Mon, 18 Oct 2010 16:40:30 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o9INfqoX024052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 18 Oct 2010 16:41:53 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o9INfp28003438; Mon, 18 Oct 2010 18:41:52 -0500 (CDT) Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o9INfpcX003421 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 18 Oct 2010 18:41:51 -0500 (CDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Mon, 18 Oct 2010 16:41:51 -0700 From: "Henderson, Thomas R" To: "'Tobias Heer'" , HIP WG Date: Mon, 18 Oct 2010 16:41:50 -0700 Thread-Topic: [Hipsec] Completing 5201 state machine Thread-Index: Actq8Zr3o9/LxZxbRHKiYjilUp9rBQEKkZwg Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CEC451A09@XCH-NW-10V.nw.nos.boeing.com> References: <917A9DF6-17C4-4AAF-9132-1A865D0A824B@cs.rwth-aachen.de> In-Reply-To: <917A9DF6-17C4-4AAF-9132-1A865D0A824B@cs.rwth-aachen.de> 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: [Hipsec] Completing 5201 state machine X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 23:40:31 -0000 Tobias, I reviewed the OpenHIP behavior to these white spots, below: > -----Original Message----- > From: hipsec-bounces@ietf.org > [mailto:hipsec-bounces@ietf.org] On Behalf Of Tobias Heer > Sent: Wednesday, October 13, 2010 9:13 AM > To: HIP WG > Subject: [Hipsec] Completing 5201 state machine > > Hello, > > the state machine of RFC5201 (not -bis) has some white spots > which I try to cover now. Nothing essential is missing but it > seems slightly underspecified the way it is now. > Handling of the following packets is missing in some states: > CLOSE, CLOSE_ACK, and NOTIFY. And it is not caught by the > "handle ANYOTHER" rules that serve as catch-all. > > I'll list the changes that I'll make here and ask for > feedback from the group and especially implementors. > > 1.) Receive CLOSE in state I2-sent: > ------------------------------ > Why can this happen? > - R2 is lost (maybe repeatedly), Responder transitions to > from R2-SENT to ESTABLISHED because of timeout, Responder > decides to close association (because of some reason) > > Proposed action: process packet > - successful: transition to CLOSING > - fail: drop and stay at I2-sent OpenHIP allows CLOSE in states ESTABLISHED, CLOSING, CLOSED, and R2_SENT, b= ut does not process it in this state. Can you clarify what you want to happen here? Usually, if peer sends a CLO= SE, you send CLOSE_ACK and transition to CLOSED, not to CLOSING. > > > 2.) Receive CLOSE in state R2-sent > ------------------------------ > Why can this happen? > - Responder cannot observe data packet flow (this is the case > for some implementations), Responder timeout for transition > from R2-SENT to ESTABLISHED has not fired yet, Initiator > decides to close association (because of some reason) > > Proposed action: process packet > - successful: transition to CLOSING > - fail: drop and stay at R2-sent OpenHIP accepts this packet, sends CLOSE_ACK, and transitions to CLOSED. A= s in 1) above, are you suggesting state CLOSING or CLOSED? > > > 3.) Receive CLOSE_ACK in state R2-sent > ------------------------------ > Why can this happen? > - It shouldn't but there is nothing specified. > > Proposed action: drop Agree; in OpenHIP, CLOSE_ACK is only processed in state CLOSING or CLOSED. > > > 4.) Receive NOTIFY in state R2-sent > ------------------------------ > Why can this happen? > - Responder cannot observe the data channel and timeout has > not fired yet. > > Proposed action: process and stay in R2 sent Agree; in OpenHIP, NOTIFY is processed in any state that has a valid associ= ation > > > 5.) Receive CLOSE_ACK in state ESTABLISHED > ------------------------------ > Why can this happen? > - It shouldn't but there is nothing specified. > > Proposed action: drop Agree; see 3) above. > > > 6. Receive NOTIFY in state ESTABLISHED > ------------------------------ > Why can this happen? > - Well, there are many reasons for this. This is normal behavior. > > Proposed action: process and stay in ESTABLISHED Agree. - Tom From fabrice.hobaya@gmail.com Tue Oct 19 00:46:21 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F26E3A6C19 for ; Tue, 19 Oct 2010 00:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXBaS3oW0Dk9 for ; Tue, 19 Oct 2010 00:46:19 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 14EEC3A69A1 for ; Tue, 19 Oct 2010 00:46:18 -0700 (PDT) Received: by bwz14 with SMTP id 14so1583593bwz.31 for ; Tue, 19 Oct 2010 00:47:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=bkLK8zc8ldLvf9ayhBDzM5C2sIb9OwC8Jige7lhI9+8=; b=SmZqO68zYb/UhIvvNBPMPBs2uerqjBG/icSXuRDlY3gNzo0Y7R1Oz9sJN3/y7WB+eh 2aal+H63RsbWULDsCHXH/BBbDS1W55V18tVP9sniR44Zo27E7/QGZdR+lnnqKxCfKOtl foKv7sU4Qxrhmms2uC/+a9yJy8V58buaasZ1w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=UPsV7ZfsO2MLA3AaA0Elqxha7V7/YWZM1e/zPF8EhplaBlI8ITG6aVHkjqlnmlTAx+ 1/skDLLOdZf80elChRC1L3t9Y44fN+0wVoHKIf+9nYS69+N98oR07Vu/R1TySxhAbZ/y Up5nzYdm2kQcDq94n5dHdxCS+HBAFKMS/UaQY= Received: by 10.204.53.142 with SMTP id m14mr5062333bkg.147.1287474468436; Tue, 19 Oct 2010 00:47:48 -0700 (PDT) MIME-Version: 1.0 Sender: fabrice.hobaya@gmail.com Received: by 10.204.123.130 with HTTP; Tue, 19 Oct 2010 00:47:28 -0700 (PDT) In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4CEC4519F9@XCH-NW-10V.nw.nos.boeing.com> References: <7CC566635CFE364D87DC5803D4712A6C4CEC4519F9@XCH-NW-10V.nw.nos.boeing.com> From: Fabrice HOBAYA Date: Tue, 19 Oct 2010 09:47:28 +0200 X-Google-Sender-Auth: gpsQLMUqkmv0D4_mhOruNExzlzw Message-ID: To: "Henderson, Thomas R" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: HIP Subject: Re: [Hipsec] new mobility/multihoming drafts posted X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 07:46:21 -0000 Hi Thomas, all, Regarding the first issue (RVS Double Jump support) may I suggest the reading of this paper: =09 "Host Identity Protocol Extension Supporting Simultaneous End-Host Mobility= " http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=3D5279586 Regards, Fabrice & Al. On 18 October 2010 21:05, Henderson, Thomas R wrote: > I've posted two drafts today that implement the document split discussed = at IETF 77 regarding RFC5206-bis. =A0The first draft removes the multihomin= g-specific content from RFC5206-bis: > http://www.ietf.org/internet-drafts/draft-ietf-hip-rfc5206-bis-01.txt > and the second draft adds that content back into a new multihoming draft: > http://www.ietf.org/internet-drafts/draft-ietf-hip-multihoming-00.txt > > However, there are no normative specification changes yet to the above tw= o documents, nor are there any attempts to improve them editorially. =A0We = can now start to work on improving each of the documents and aligning with = the other -bis documents. > > I have started to use the WG tracker to track issues for mobility and mul= tihoming revisions. =A0I've listed all of the issues that I have in my note= s with respect to RFC5206(bis); if I am forgetting any, please remind me or= update the tracker yourself. > > http://trac.tools.ietf.org/wg/hip/trac/report/1 > > - Tom > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > --=20 Fabrice HOBAYA -- PhD student CNES / Thales Alenia Space / T=E9SA +335 34 35 41 12 - from monday to wednesday +335 61 24 73 70 - from thursday to friday fabrice.hobaya@tesa.prd.fr From mkomu@cs.hut.fi Tue Oct 19 01:58:13 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51C743A6A65 for ; Tue, 19 Oct 2010 01:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.193 X-Spam-Level: X-Spam-Status: No, score=-6.193 tagged_above=-999 required=5 tests=[AWL=0.406, 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 aNVH5+uGImCs for ; Tue, 19 Oct 2010 01:58:12 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by core3.amsl.com (Postfix) with ESMTP id EA0743A694F for ; Tue, 19 Oct 2010 01:58:11 -0700 (PDT) Received: from hutcs.cs.hut.fi ([130.233.192.10] helo=[127.0.0.1]) by mail.cs.hut.fi with esmtp (Exim 4.54) id 1P882m-0006m0-Lm for hipsec@ietf.org; Tue, 19 Oct 2010 11:59:40 +0300 Message-ID: <4CBD5E83.9090908@cs.hut.fi> Date: Tue, 19 Oct 2010 12:01:55 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: hip WG References: <917A9DF6-17C4-4AAF-9132-1A865D0A824B@cs.rwth-aachen.de> <7CC566635CFE364D87DC5803D4712A6C4CEC451A09@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4CEC451A09@XCH-NW-10V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] Completing 5201 state machine X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 08:58:13 -0000 Hi, On 19/10/10 02:41, Henderson, Thomas R wrote: > Tobias, I reviewed the OpenHIP behavior to these white spots, below: > >> -----Original Message----- >> From: hipsec-bounces@ietf.org >> [mailto:hipsec-bounces@ietf.org] On Behalf Of Tobias Heer >> Sent: Wednesday, October 13, 2010 9:13 AM >> To: HIP WG >> Subject: [Hipsec] Completing 5201 state machine >> >> Hello, >> >> the state machine of RFC5201 (not -bis) has some white spots >> which I try to cover now. Nothing essential is missing but it >> seems slightly underspecified the way it is now. >> Handling of the following packets is missing in some states: >> CLOSE, CLOSE_ACK, and NOTIFY. And it is not caught by the >> "handle ANYOTHER" rules that serve as catch-all. >> >> I'll list the changes that I'll make here and ask for >> feedback from the group and especially implementors. >> >> 1.) Receive CLOSE in state I2-sent: >> ------------------------------ >> Why can this happen? >> - R2 is lost (maybe repeatedly), Responder transitions to >> from R2-SENT to ESTABLISHED because of timeout, Responder >> decides to close association (because of some reason) >> >> Proposed action: process packet >> - successful: transition to CLOSING >> - fail: drop and stay at I2-sent > > OpenHIP allows CLOSE in states ESTABLISHED, CLOSING, CLOSED, and R2_SENT, but does not process it in this state. > > Can you clarify what you want to happen here? Usually, if peer sends a CLOSE, you send CLOSE_ACK and transition to CLOSED, not to CLOSING. HIPL also ignores this, i.e., drops the CLOSE packet. >> 2.) Receive CLOSE in state R2-sent >> ------------------------------ >> Why can this happen? >> - Responder cannot observe data packet flow (this is the case >> for some implementations), Responder timeout for transition >> from R2-SENT to ESTABLISHED has not fired yet, Initiator >> decides to close association (because of some reason) >> >> Proposed action: process packet >> - successful: transition to CLOSING >> - fail: drop and stay at R2-sent > > OpenHIP accepts this packet, sends CLOSE_ACK, and transitions to CLOSED. As in 1) above, are you suggesting state CLOSING or CLOSED? HIPL currently ignores this, but I think it might be a good idea to process this. >> >> 3.) Receive CLOSE_ACK in state R2-sent >> ------------------------------ >> Why can this happen? >> - It shouldn't but there is nothing specified. >> >> Proposed action: drop > > Agree; in OpenHIP, CLOSE_ACK is only processed in state CLOSING or CLOSED. Agred. Dropped by HIPL too. >> 4.) Receive NOTIFY in state R2-sent >> ------------------------------ >> Why can this happen? >> - Responder cannot observe the data channel and timeout has >> not fired yet. >> >> Proposed action: process and stay in R2 sent > > Agree; in OpenHIP, NOTIFY is processed in any state that has a valid association Agree (processed and logged by HIPL). >> 5.) Receive CLOSE_ACK in state ESTABLISHED >> ------------------------------ >> Why can this happen? >> - It shouldn't but there is nothing specified. >> >> Proposed action: drop > > Agree; see 3) above. Agree (dropped by HIPL). >> >> >> 6. Receive NOTIFY in state ESTABLISHED >> ------------------------------ >> Why can this happen? >> - Well, there are many reasons for this. This is normal behavior. >> >> Proposed action: process and stay in ESTABLISHED > > Agree. Agree (processed and logged by HIPL). From heer@informatik.rwth-aachen.de Tue Oct 19 02:43:55 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B51903A63EC for ; Tue, 19 Oct 2010 02:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.377 X-Spam-Level: X-Spam-Status: No, score=-4.377 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 G-1DRmRNJEFX for ; Tue, 19 Oct 2010 02:43:53 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id E929E3A63D2 for ; Tue, 19 Oct 2010 02:43:52 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LAJ00CUU73MT6B0@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Tue, 19 Oct 2010 11:45:22 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.57,349,1283724000"; d="scan'208";a="41309083" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Tue, 19 Oct 2010 11:45:22 +0200 Received: from umic-i4-137-226-45-90.nn.rwth-aachen.de ([unknown] [137.226.45.90]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LAJ00IYB73M6C20@relay-auth-2.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Tue, 19 Oct 2010 11:45:22 +0200 (CEST) From: Tobias Heer In-reply-to: <7CC566635CFE364D87DC5803D4712A6C4CEC451A09@XCH-NW-10V.nw.nos.boeing.com> Date: Tue, 19 Oct 2010 11:45:21 +0200 Message-id: References: <917A9DF6-17C4-4AAF-9132-1A865D0A824B@cs.rwth-aachen.de> <7CC566635CFE364D87DC5803D4712A6C4CEC451A09@XCH-NW-10V.nw.nos.boeing.com> To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.1081) Cc: HIP WG Subject: Re: [Hipsec] Completing 5201 state machine X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 09:43:55 -0000 Hi Tom, thanks for your review of this! Am 19.10.2010 um 01:41 schrieb Henderson, Thomas R: > Tobias, I reviewed the OpenHIP behavior to these white spots, below: > >> -----Original Message----- >> From: hipsec-bounces@ietf.org >> [mailto:hipsec-bounces@ietf.org] On Behalf Of Tobias Heer >> Sent: Wednesday, October 13, 2010 9:13 AM >> To: HIP WG >> Subject: [Hipsec] Completing 5201 state machine >> [...] >> >> 1.) Receive CLOSE in state I2-sent: >> ------------------------------ >> Why can this happen? >> - R2 is lost (maybe repeatedly), Responder transitions to >> from R2-SENT to ESTABLISHED because of timeout, Responder >> decides to close association (because of some reason) >> >> Proposed action: process packet >> - successful: transition to CLOSING >> - fail: drop and stay at I2-sent > > OpenHIP allows CLOSE in states ESTABLISHED, CLOSING, CLOSED, and R2_SENT, but does not process it in this state. > > Can you clarify what you want to happen here? Usually, if peer sends a CLOSE, you send CLOSE_ACK and transition to CLOSED, not to CLOSING. > Good catch. Indeed I mean CLOSED. The host should send a CLOSE_ACK and transition to CLOSED. I guess this case will only happen rarely - maybe never for some implementations. How do we end up here? 0.) I1, R1 1.) Initiator sends I2. 2.) Responder sends R2 3.) R2 is lost or delayed 4.) Timeout at Responder fires: Responder transitions to ESTABLISHED 5.) Further I2 messages from Initiator are lost 6.) Responder decides to close the ESTABLISHED connection, sends CLOSE and transitions to CLOSING 7.) Now the Initiator receives the CLOSE message while in state I2-sent I admit that the case is somewhat constructed but possible nonetheless. >> >> >> 2.) Receive CLOSE in state R2-sent >> ------------------------------ >> Why can this happen? >> - Responder cannot observe data packet flow (this is the case >> for some implementations), Responder timeout for transition >> from R2-SENT to ESTABLISHED has not fired yet, Initiator >> decides to close association (because of some reason) >> >> Proposed action: process packet >> - successful: transition to CLOSING >> - fail: drop and stay at R2-sent > > OpenHIP accepts this packet, sends CLOSE_ACK, and transitions to CLOSED. As in 1) above, are you suggesting state CLOSING or CLOSED? > Same as 1). Process, if valid: send CLOSE_ACK and transition to CLOSED. Above you said that OpenHIP wouldn't process CLOSE messages in state R2_SENT. What do you mean by that? Isn't sending a CLOSE_ACK (as you mention for 2.) such processing? Am I confusing something here? [...] Tobias -- Dipl.-Inform. Tobias Heer, Ph.D. Student Chair of Communication and Distributed Systems - comsys RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi From thomas.r.henderson@boeing.com Tue Oct 19 07:03:16 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E51E3A6813 for ; Tue, 19 Oct 2010 07:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.204 X-Spam-Level: X-Spam-Status: No, score=-106.204 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHQ8AakYVSMj for ; Tue, 19 Oct 2010 07:03:15 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 029A03A680A for ; Tue, 19 Oct 2010 07:03:13 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o9JE4YGE004157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 19 Oct 2010 07:04:35 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o9JE4YCj003335; Tue, 19 Oct 2010 07:04:34 -0700 (PDT) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o9JE4YDY003322 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 19 Oct 2010 07:04:34 -0700 (PDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Tue, 19 Oct 2010 07:04:34 -0700 From: "Henderson, Thomas R" To: "'Tobias Heer'" Date: Tue, 19 Oct 2010 07:04:32 -0700 Thread-Topic: [Hipsec] Completing 5201 state machine Thread-Index: Actvclr7apmJuL+MQ06xHdXO6qwUNAAI/bqw Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CEC451A0B@XCH-NW-10V.nw.nos.boeing.com> References: <917A9DF6-17C4-4AAF-9132-1A865D0A824B@cs.rwth-aachen.de><7CC5666 35CFE364D87DC5803D4712A6C4CEC451A09@XCH-NW-10V.nw.nos.boeing.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: HIP WG Subject: Re: [Hipsec] Completing 5201 state machine X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 14:03:16 -0000 > -----Original Message----- > From: Tobias Heer [mailto:heer@cs.rwth-aachen.de] > Sent: Tuesday, October 19, 2010 2:45 AM > To: Henderson, Thomas R > Cc: HIP WG > Subject: Re: [Hipsec] Completing 5201 state machine > > Hi Tom, > > thanks for your review of this! > > Am 19.10.2010 um 01:41 schrieb Henderson, Thomas R: > > > Tobias, I reviewed the OpenHIP behavior to these white spots, below: > > > >> -----Original Message----- > >> From: hipsec-bounces@ietf.org > >> [mailto:hipsec-bounces@ietf.org] On Behalf Of Tobias Heer > >> Sent: Wednesday, October 13, 2010 9:13 AM > >> To: HIP WG > >> Subject: [Hipsec] Completing 5201 state machine > >> > [...] > >> > >> 1.) Receive CLOSE in state I2-sent: > >> ------------------------------ > > > > OpenHIP allows CLOSE in states ESTABLISHED, CLOSING, > CLOSED, and R2_SENT, but does not process it in this state. > > > > Above you said that OpenHIP wouldn't process CLOSE messages > in state R2_SENT. What do you mean by that? Isn't sending a > CLOSE_ACK (as you mention for 2.) such processing? Am I > confusing something here? > Sorry for not being clear; the "this state" in the above explanation refers= to state I2-sent, not R2-sent. - Tom From heer@informatik.rwth-aachen.de Tue Oct 19 07:06:11 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B8163A680A for ; Tue, 19 Oct 2010 07:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.412 X-Spam-Level: X-Spam-Status: No, score=-4.412 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 NQyCotWb-Ybt for ; Tue, 19 Oct 2010 07:06:08 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 569FC3A682E for ; Tue, 19 Oct 2010 07:06:08 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LAJ00A3DJ8P2K50@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Tue, 19 Oct 2010 16:07:37 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.57,350,1283724000"; d="scan'208";a="77586273" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Tue, 19 Oct 2010 16:07:37 +0200 Received: from umic-i4-137-226-45-90.nn.rwth-aachen.de ([unknown] [137.226.45.90]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LAJ00I53J8P6C90@relay-auth-2.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Tue, 19 Oct 2010 16:07:37 +0200 (CEST) From: Tobias Heer In-reply-to: <4CBC3DAC.7020404@nomadiclab.com> Date: Tue, 19 Oct 2010 16:07:36 +0200 Message-id: <16D5B0B9-F299-4177-8769-364172361798@cs.rwth-aachen.de> References: <20101018121505.4D2D43A6D9E@core3.amsl.com> <4CBC3DAC.7020404@nomadiclab.com> To: Ari Keranen X-Mailer: Apple Mail (2.1081) Cc: HIP WG Subject: Re: [Hipsec] I-D Action:draft-ietf-hip-over-hip-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 14:06:11 -0000 Hello Ari, I read the draft and I have some comments/questions below: a) In my opinion, there is a good reason why HIP control messages are not encrypted by default. I think this design was chosen to support on-path elements so that they can understand what's going on. Sending HIP control messages over encrypted channel obviously changes this property. I think this should be stated somewhere. b) Sending HIP control messages over an encrypted channel makes some of the security measures that HIP uses unnecessary. The HMAC might still be needed (because ESP without authentication is deemed insecure). However, the public-key signature of the update seems quite superfluous to me now because it is intended to help on-path verification of packets - which the encryption prevents. Maybe the draft should comment on this? The update signatures is mandatory (according to RFC5201) so it might be an option not to touch it and accept the wasted overhead (although I don't fancy that option). c) You discuss host mobility but do not mention multihoming is this intended? d) To me it is not entirely clear how mobility or multihoming would work with the encrypted channels in place. You describe that it can work if it is done before the connection breaks. Would both hosts set up new SA pairs / TCP connections for all of their possible address pairs in order to do the address verification? If yes, the address verification during the update is rather useless for TCP because TCP does its own handshake already. If no, how does it work? Am I missing the point here? BR, Tobias Am 18.10.2010 um 14:29 schrieb Ari Keranen: > Hi all, > > This updated version addresses all the comments given during the WGLC, changes the proposed NOTIFY packet type to avoid clash with taken values, updates the IANA section regarding the NOTIFY type, updates the security section with short note about security of different ESP transforms, and has some editorial fixes. For details, see the diff: > > http://tools.ietf.org/rfcdiff?url2=draft-ietf-hip-over-hip-02 > > > Cheers, > Ari > > On 10/18/2010 03:15 PM, Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Host Identity Protocol Working Group of the IETF. >> >> >> Title : Host Identity Protocol Signaling Message Transport Modes >> Author(s) : A. Keranen >> Filename : draft-ietf-hip-over-hip-02.txt >> Pages : 9 >> Date : 2010-10-18 >> >> This document specifies two transport modes for Host Identity >> Protocol (HIP) signaling messages that allow conveying them over >> encrypted connections initiated with the Host Identity Protocol. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-hip-over-hip-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. > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec -- Dipl.-Inform. Tobias Heer, Ph.D. Student Chair of Communication and Distributed Systems - comsys RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi From heer@informatik.rwth-aachen.de Tue Oct 19 07:23:55 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 786203A6820 for ; Tue, 19 Oct 2010 07:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.442 X-Spam-Level: X-Spam-Status: No, score=-4.442 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 x4uaIZ999hBQ for ; Tue, 19 Oct 2010 07:23:50 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id BA6343A6823 for ; Tue, 19 Oct 2010 07:23:49 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LAJ00MRAK278840@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Tue, 19 Oct 2010 16:25:19 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.57,350,1283724000"; d="scan'208";a="41337703" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Tue, 19 Oct 2010 16:25:19 +0200 Received: from umic-i4-137-226-45-90.nn.rwth-aachen.de ([unknown] [137.226.45.90]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LAJ00IHLK276C90@relay-auth-2.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Tue, 19 Oct 2010 16:25:19 +0200 (CEST) From: Tobias Heer In-reply-to: <7CC566635CFE364D87DC5803D4712A6C4CEC451A0B@XCH-NW-10V.nw.nos.boeing.com> Date: Tue, 19 Oct 2010 16:25:18 +0200 Message-id: References: <917A9DF6-17C4-4AAF-9132-1A865D0A824B@cs.rwth-aachen.de> <"7CC5666 35CFE364D87DC5803D4712A6C4CEC451A09"@XCH-NW-10V.nw.nos.boeing.com> <7CC566635CFE364D87DC5803D4712A6C4CEC451A0B@XCH-NW-10V.nw.nos.boeing.com> To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.1081) Cc: HIP WG Subject: Re: [Hipsec] Completing 5201 state machine X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 14:23:55 -0000 Hi Tom, thanks for the clarification. Am 19.10.2010 um 16:04 schrieb Henderson, Thomas R: [...] >>> >>> OpenHIP allows CLOSE in states ESTABLISHED, CLOSING, >> CLOSED, and R2_SENT, but does not process it in this state. >>> > > > >> >> Above you said that OpenHIP wouldn't process CLOSE messages >> in state R2_SENT. What do you mean by that? Isn't sending a >> CLOSE_ACK (as you mention for 2.) such processing? Am I >> confusing something here? >> > > Sorry for not being clear; the "this state" in the above explanation refers to state I2-sent, not R2-sent. > What is your opinion on processing CLOSE messages in state I2-sent? Do you have reasons why you don't process it in that state? Tobias > - Tom -- Dipl.-Inform. Tobias Heer, Ph.D. Student Chair of Communication and Distributed Systems - comsys RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi From wwwrun@rfc-editor.org Tue Oct 19 07:54:05 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFA5A3A6897; Tue, 19 Oct 2010 07:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.388 X-Spam-Level: X-Spam-Status: No, score=-102.388 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 qqqUUW2qrD9o; Tue, 19 Oct 2010 07:54:04 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id C8D2F3A6849; Tue, 19 Oct 2010 07:54:04 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 17254E06F9; Tue, 19 Oct 2010 07:55:36 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20101019145536.17254E06F9@rfc-editor.org> Date: Tue, 19 Oct 2010 07:55:36 -0700 (PDT) Cc: hipsec@ietf.org, rfc-editor@rfc-editor.org Subject: [Hipsec] RFC 6028 on Host Identity Protocol (HIP) Multi-Hop Routing Extension X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 14:54:06 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6028 Title: Host Identity Protocol (HIP) Multi-Hop Routing Extension Author: G. Camarillo, A. Keranen Status: Experimental Stream: IETF Date: October 2010 Mailbox: Gonzalo.Camarillo@ericsson.com, Ari.Keranen@ericsson.com Pages: 10 Characters: 21571 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-hip-via-03.txt URL: http://www.rfc-editor.org/rfc/rfc6028.txt This document specifies two extensions to the Host Identity Protocol (HIP) to implement multi-hop routing. The first extension allows implementing source routing in HIP. That is, a node sending a HIP packet can define a set of nodes that the HIP packet should traverse. The second extension allows a HIP packet to carry and record the list of nodes that forwarded it. This document defines an Experimental Protocol for the Internet community. This document is a product of the Host Identity Protocol Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From thomas.r.henderson@boeing.com Tue Oct 19 07:54:19 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A1E83A68BE for ; Tue, 19 Oct 2010 07:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.356 X-Spam-Level: X-Spam-Status: No, score=-105.356 tagged_above=-999 required=5 tests=[AWL=-0.519, BAYES_00=-2.599, MISSING_SUBJECT=1.762, 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 88c5TxyYjHPU for ; Tue, 19 Oct 2010 07:54:18 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 5C92C3A68B8 for ; Tue, 19 Oct 2010 07:54:17 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o9JEti5Y010177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 19 Oct 2010 07:55:45 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o9JEtiru022237; Tue, 19 Oct 2010 07:55:44 -0700 (PDT) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o9JEtipV022231 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 19 Oct 2010 07:55:44 -0700 (PDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Tue, 19 Oct 2010 07:55:44 -0700 From: "Henderson, Thomas R" To: "'Tobias Heer'" Date: Tue, 19 Oct 2010 07:55:41 -0700 Thread-Index: ActvnbNJ0h14T+frT/+SXdIUel0uGg== Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CEC451A0E@XCH-NW-10V.nw.nos.boeing.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: HIP WG Subject: [Hipsec] (no subject) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 14:54:19 -0000 > -----Original Message----- > From: Tobias Heer [mailto:heer@cs.rwth-aachen.de] > Sent: Tuesday, October 19, 2010 7:25 AM > To: Henderson, Thomas R > Cc: HIP WG > Subject: Re: [Hipsec] Completing 5201 state machine > > Hi Tom, > > thanks for the clarification. > > Am 19.10.2010 um 16:04 schrieb Henderson, Thomas R: > > [...] > >>> > >>> OpenHIP allows CLOSE in states ESTABLISHED, CLOSING, > >> CLOSED, and R2_SENT, but does not process it in this state. > >>> > > > > > > > >> > >> Above you said that OpenHIP wouldn't process CLOSE messages > >> in state R2_SENT. What do you mean by that? Isn't sending a > >> CLOSE_ACK (as you mention for 2.) such processing? Am I > >> confusing something here? > >> > > > > Sorry for not being clear; the "this state" in the above > explanation refers to state I2-sent, not R2-sent. > > > What is your opinion on processing CLOSE messages in state > I2-sent? Do you have reasons why you don't process it in that state? > I can't recall exactly the reason for this decision, but another possible s= cenario: 1.) remote host sends CLOSE 2.) local host sends CLOSE_ACK, moves to CLOSED. CLOSE_ACK lost 3.) local host tries to immediately set up the session again, sends I1, rec= eives (stateless) R1 4.) local host sends I2. Meanwhile, remote host is still in CLOSING state = until it gets I2, which it accepts and moves back to R2-sent. Here it it m= ore helpful for the local host to just ignore the (stale) CLOSE from the pa= st association Again, this is somewhat of a contrived scenario. I am fairly neutral as to= how to handle this since these seem to be unlikely scenarios, and would be= willing to adopt your suggestion. - Tom From heer@informatik.rwth-aachen.de Tue Oct 19 10:03:25 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7124B3A6905 for ; Tue, 19 Oct 2010 10:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.468 X-Spam-Level: X-Spam-Status: No, score=-4.468 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 3KQmanaeAACR for ; Tue, 19 Oct 2010 10:03:24 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id DF2533A68E1 for ; Tue, 19 Oct 2010 10:03:23 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LAJ00DY5RG6ANG0@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Tue, 19 Oct 2010 19:04:54 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.57,351,1283724000"; d="scan'208";a="41351417" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Tue, 19 Oct 2010 19:04:55 +0200 Received: from umic-i4-137-226-45-90.nn.rwth-aachen.de ([unknown] [137.226.45.90]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LAJ00IA2RG6QR10@relay-auth-2.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Tue, 19 Oct 2010 19:04:54 +0200 (CEST) From: Tobias Heer In-reply-to: <7CC566635CFE364D87DC5803D4712A6C4CEC451A0E@XCH-NW-10V.nw.nos.boeing.com> Date: Tue, 19 Oct 2010 19:04:53 +0200 Message-id: References: <7CC566635CFE364D87DC5803D4712A6C4CEC451A0E@XCH-NW-10V.nw.nos.boeing.com> To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.1081) Cc: HIP WG Subject: [Hipsec] CLOSE and identical session keys X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 17:03:25 -0000 Hello Tom, Am 19.10.2010 um 16:55 schrieb Henderson, Thomas R: > > >> -----Original Message----- >> From: Tobias Heer [mailto:heer@cs.rwth-aachen.de] >> Sent: Tuesday, October 19, 2010 7:25 AM >> To: Henderson, Thomas R >> Cc: HIP WG >> Subject: Re: [Hipsec] Completing 5201 state machine >> >> Hi Tom, >> >> thanks for the clarification. >> >> Am 19.10.2010 um 16:04 schrieb Henderson, Thomas R: >> >> [...] >>>>> >>>>> OpenHIP allows CLOSE in states ESTABLISHED, CLOSING, >>>> CLOSED, and R2_SENT, but does not process it in this state. >>>>> >>> >>> >>> >>>> >>>> Above you said that OpenHIP wouldn't process CLOSE messages >>>> in state R2_SENT. What do you mean by that? Isn't sending a >>>> CLOSE_ACK (as you mention for 2.) such processing? Am I >>>> confusing something here? >>>> >>> >>> Sorry for not being clear; the "this state" in the above >> explanation refers to state I2-sent, not R2-sent. >>> >> What is your opinion on processing CLOSE messages in state >> I2-sent? Do you have reasons why you don't process it in that state? >> > > I can't recall exactly the reason for this decision, but another possible scenario: > > 1.) remote host sends CLOSE > 2.) local host sends CLOSE_ACK, moves to CLOSED. CLOSE_ACK lost > 3.) local host tries to immediately set up the session again, sends I1, receives (stateless) R1 > 4.) local host sends I2. Meanwhile, remote host is still in CLOSING state until it gets I2, which it accepts and moves back to R2-sent. Here it it more helpful for the local host to just ignore the (stale) CLOSE from the past asso In my opinion it is unlikely that the Initiator confuses the old CLOSE with a new close for the newly established association because it is protected with an HMAC that depends on the DH and puzzle used in the handshake. Hence, processing of the CLOSE packet will only be successful if the R1 counter has not advanced and the puzzle solution was identical. However, the suggestion for generating new puzzles is "once every few minutes" so identical session keys could actually be the case and it is not so unlikely at all. It might make sense to be able to detect replayed and old CLOSE packets reliably to avoid vulnerabilities for hosts that set up and close connections rapidly. Such detection should probably happen via the HMAC/shared key. Hence, the key generation should be different. The best option for varying keys would be the puzzle. My suggestion would be: a) add a recommendation that a host SHOULD to not send the same puzzle to a host twice. A host can use the opaque field in the puzzle to generate unique puzzle parameters (e.g., by using a counter as input for the generation of I and by using the opaque field in the puzzle to remember it). or b) add MUST to use different puzzles. This may be a bit more costly because a host could deprive the puzzles that can be indexed with the opaque field with 2^16 I1 packets. In that case the responder would have to increase the R1 generation counter (and would possibly generate new DH keys and signatures for these). Any opinions? Tobias > ciation > > Again, this is somewhat of a contrived scenario. I am fairly neutral as to how to handle this since these seem to be unlikely scenarios, and would be willing to adopt your suggestion. > > - Tom -- Dipl.-Inform. Tobias Heer, Ph.D. Student Chair of Communication and Distributed Systems - comsys RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi From mkomu@cs.hut.fi Wed Oct 20 02:19:14 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F5FF3A67DA for ; Wed, 20 Oct 2010 02:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.22 X-Spam-Level: X-Spam-Status: No, score=-6.22 tagged_above=-999 required=5 tests=[AWL=0.379, 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 cXcRbpvvxPDD for ; Wed, 20 Oct 2010 02:19:13 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by core3.amsl.com (Postfix) with ESMTP id DBA483A683F for ; Wed, 20 Oct 2010 02:19:12 -0700 (PDT) Received: from hutcs.cs.hut.fi ([130.233.192.10] helo=[127.0.0.1]) by mail.cs.hut.fi with esmtp (Exim 4.54) id 1P8Uqi-0004oF-Dv for hipsec@ietf.org; Wed, 20 Oct 2010 12:20:44 +0300 Message-ID: <4CBEB46C.6090207@cs.hut.fi> Date: Wed, 20 Oct 2010 12:20:44 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: hipsec@ietf.org References: <7CC566635CFE364D87DC5803D4712A6C4CEC451A0E@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] CLOSE and identical session keys X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 09:19:14 -0000 Hi, On 10/19/2010 08:04 PM, Tobias Heer wrote: > Hello Tom, > > Am 19.10.2010 um 16:55 schrieb Henderson, Thomas R: > >> >> >>> -----Original Message----- >>> From: Tobias Heer [mailto:heer@cs.rwth-aachen.de] >>> Sent: Tuesday, October 19, 2010 7:25 AM >>> To: Henderson, Thomas R >>> Cc: HIP WG >>> Subject: Re: [Hipsec] Completing 5201 state machine >>> >>> Hi Tom, >>> >>> thanks for the clarification. >>> >>> Am 19.10.2010 um 16:04 schrieb Henderson, Thomas R: >>> >>> [...] >>>>>> >>>>>> OpenHIP allows CLOSE in states ESTABLISHED, CLOSING, >>>>> CLOSED, and R2_SENT, but does not process it in this state. >>>>>> >>>> >>>> >>>> >>>>> >>>>> Above you said that OpenHIP wouldn't process CLOSE messages >>>>> in state R2_SENT. What do you mean by that? Isn't sending a >>>>> CLOSE_ACK (as you mention for 2.) such processing? Am I >>>>> confusing something here? >>>>> >>>> >>>> Sorry for not being clear; the "this state" in the above >>> explanation refers to state I2-sent, not R2-sent. >>>> >>> What is your opinion on processing CLOSE messages in state >>> I2-sent? Do you have reasons why you don't process it in that state? >>> >> >> I can't recall exactly the reason for this decision, but another possible scenario: >> >> 1.) remote host sends CLOSE >> 2.) local host sends CLOSE_ACK, moves to CLOSED. CLOSE_ACK lost >> 3.) local host tries to immediately set up the session again, sends I1, receives (stateless) R1 >> 4.) local host sends I2. Meanwhile, remote host is still in CLOSING state until it gets I2, which it accepts and moves back to R2-sent. Here it it more helpful for the local host to just ignore the (stale) CLOSE from the past asso > > In my opinion it is unlikely that the Initiator confuses the old CLOSE with a new close for the newly established association because it is protected with an HMAC that depends on the DH and puzzle used in the handshake. > Hence, processing of the CLOSE packet will only be successful if the R1 counter has not advanced and the puzzle solution was identical. However, the suggestion for generating new puzzles is "once every few minutes" so identical session keys could actually be the case and it is not so unlikely at all. > > It might make sense to be able to detect replayed and old CLOSE packets reliably to avoid vulnerabilities for hosts that set up and close connections rapidly. Such detection should probably happen via the HMAC/shared key. Hence, the key generation should be different. The best option for varying keys would be the puzzle. > > My suggestion would be: > > a) add a recommendation that a host SHOULD to not send the same puzzle to a host twice. A host can use the opaque field in the puzzle to generate unique puzzle parameters (e.g., by using a counter as input for the generation of I and by using the opaque field in the puzzle to remember it). > > or > > b) add MUST to use different puzzles. This may be a bit more costly because a host could deprive the puzzles that can be indexed with the opaque field with 2^16 I1 packets. In that case the responder would have to increase the R1 generation counter (and would possibly generate new DH keys and signatures for these). > > Any opinions? +1 for (a) From rene.hummen@informatik.rwth-aachen.de Wed Oct 20 02:40:29 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1644D3A6907 for ; Wed, 20 Oct 2010 02:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.501 X-Spam-Level: X-Spam-Status: No, score=-4.501 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, 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 cKgodDBx2AS4 for ; Wed, 20 Oct 2010 02:39:15 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id EC8993A68C4 for ; Wed, 20 Oct 2010 02:35:04 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LAL00J671CF7LD0@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Wed, 20 Oct 2010 11:36:15 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.57,354,1283724000"; d="scan'208";a="77712081" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Wed, 20 Oct 2010 11:36:16 +0200 Received: from umic-i4-137-226-45-95.nn.rwth-aachen.de ([unknown] [137.226.45.95]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LAL00F6O1CFXL30@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Wed, 20 Oct 2010 11:36:15 +0200 (CEST) From: =?iso-8859-1?Q?Ren=E9_Hummen?= In-reply-to: <4CBEB46C.6090207@cs.hut.fi> Date: Wed, 20 Oct 2010 11:36:15 +0200 Message-id: <5CB5421E-4AF9-4255-9836-F8EA254FBC86@cs.rwth-aachen.de> References: <7CC566635CFE364D87DC5803D4712A6C4CEC451A0E@XCH-NW-10V.nw.nos.boeing.com> <4CBEB46C.6090207@cs.hut.fi> To: HIP WG X-Mailer: Apple Mail (2.1081) Subject: Re: [Hipsec] CLOSE and identical session keys X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 09:40:36 -0000 On 20.10.2010, at 11:20, Miika Komu wrote: > Hi, > On 10/19/2010 08:04 PM, Tobias Heer wrote: >> Hello Tom, >> Am 19.10.2010 um 16:55 schrieb Henderson, Thomas R: >>>> -----Original Message----- >>>> From: Tobias Heer [mailto:heer@cs.rwth-aachen.de] >>>> Sent: Tuesday, October 19, 2010 7:25 AM >>>> To: Henderson, Thomas R >>>> Cc: HIP WG >>>> Subject: Re: [Hipsec] Completing 5201 state machine >>>> >>>> Hi Tom, >>>> >>>> thanks for the clarification. >>>> >>>> Am 19.10.2010 um 16:04 schrieb Henderson, Thomas R: >>>> [...] >>>>>>> >>>>>>> OpenHIP allows CLOSE in states ESTABLISHED, CLOSING, >>>>>> CLOSED, and R2_SENT, but does not process it in this state. >>>>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> Above you said that OpenHIP wouldn't process CLOSE messages >>>>>> in state R2_SENT. What do you mean by that? Isn't sending a >>>>>> CLOSE_ACK (as you mention for 2.) such processing? Am I >>>>>> confusing something here? >>>>>> >>>>> >>>>> Sorry for not being clear; the "this state" in the above >>>> explanation refers to state I2-sent, not R2-sent. >>>>> >>>> What is your opinion on processing CLOSE messages in state >>>> I2-sent? Do you have reasons why you don't process it in that state? >>>> >>> >>> I can't recall exactly the reason for this decision, but another possible scenario: >>> >>> 1.) remote host sends CLOSE >>> 2.) local host sends CLOSE_ACK, moves to CLOSED. CLOSE_ACK lost >>> 3.) local host tries to immediately set up the session again, sends I1, receives (stateless) R1 >>> 4.) local host sends I2. Meanwhile, remote host is still in CLOSING state until it gets I2, which it accepts and moves back to R2-sent. Here it it more helpful for the local host to just ignore the (stale) CLOSE from the past asso >> >> In my opinion it is unlikely that the Initiator confuses the old CLOSE with a new close for the newly established association because it is protected with an HMAC that depends on the DH and puzzle used in the handshake. >> Hence, processing of the CLOSE packet will only be successful if the R1 counter has not advanced and the puzzle solution was identical. However, the suggestion for generating new puzzles is "once every few minutes" so identical session keys could actually be the case and it is not so unlikely at all. >> >> It might make sense to be able to detect replayed and old CLOSE packets reliably to avoid vulnerabilities for hosts that set up and close connections rapidly. Such detection should probably happen via the HMAC/shared key. Hence, the key generation should be different. The best option for varying keys would be the puzzle. >> >> My suggestion would be: >> >> a) add a recommendation that a host SHOULD to not send the same puzzle to a host twice. A host can use the opaque field in the puzzle to generate unique puzzle parameters (e.g., by using a counter as input for the generation of I and by using the opaque field in the puzzle to remember it). >> >> or >> >> b) add MUST to use different puzzles. This may be a bit more costly because a host could deprive the puzzles that can be indexed with the opaque field with 2^16 I1 packets. In that case the responder would have to increase the R1 generation counter (and would possibly generate new DH keys and signatures for these). >> >> Any opinions? > +1 for (a) +1 for (a) from me as well. -- Dipl.-Inform. Rene Hummen, Ph.D. Student Chair of Communication and Distributed Systems RWTH Aachen University, Germany tel: +49 241 80 20772 web: http://ds.rwth-aachen.de/members/hummen From thomas.r.henderson@boeing.com Wed Oct 20 08:15:49 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2A2E3A67D3 for ; Wed, 20 Oct 2010 08:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.216 X-Spam-Level: X-Spam-Status: No, score=-106.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0m6842aykRgu for ; Wed, 20 Oct 2010 08:15:46 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id DF2C03A683F for ; Wed, 20 Oct 2010 08:15:40 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o9KFGtfO019948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 20 Oct 2010 08:16:56 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o9KFGtrv025639; Wed, 20 Oct 2010 08:16:55 -0700 (PDT) Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o9KFGsXo025632 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 20 Oct 2010 08:16:55 -0700 (PDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Wed, 20 Oct 2010 08:16:54 -0700 From: "Henderson, Thomas R" To: "'Tobias Heer'" Date: Wed, 20 Oct 2010 08:16:54 -0700 Thread-Topic: CLOSE and identical session keys Thread-Index: ActvsFNuzyy/3uA6TymQIHcrzkoWRgAuVIRA Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CEC451A22@XCH-NW-10V.nw.nos.boeing.com> References: <7CC566635CFE364D87DC5803D4712A6C4CEC451A0E@XCH-NW-10V.nw.nos.boeing.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: HIP WG Subject: Re: [Hipsec] CLOSE and identical session keys X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 15:15:50 -0000 > -----Original Message----- > From: Tobias Heer [mailto:heer@cs.rwth-aachen.de] > Sent: Tuesday, October 19, 2010 10:05 AM > To: Henderson, Thomas R > Cc: HIP WG > Subject: CLOSE and identical session keys > > Hello Tom, > > Am 19.10.2010 um 16:55 schrieb Henderson, Thomas R: > > > > > > >> -----Original Message----- > >> From: Tobias Heer [mailto:heer@cs.rwth-aachen.de] > >> Sent: Tuesday, October 19, 2010 7:25 AM > >> To: Henderson, Thomas R > >> Cc: HIP WG > >> Subject: Re: [Hipsec] Completing 5201 state machine > >> > >> Hi Tom, > >> > >> thanks for the clarification. > >> > >> Am 19.10.2010 um 16:04 schrieb Henderson, Thomas R: > >> > >> [...] > >>>>> > >>>>> OpenHIP allows CLOSE in states ESTABLISHED, CLOSING, > >>>> CLOSED, and R2_SENT, but does not process it in this state. > >>>>> > >>> > >>> > >>> > >>>> > >>>> Above you said that OpenHIP wouldn't process CLOSE messages > >>>> in state R2_SENT. What do you mean by that? Isn't sending a > >>>> CLOSE_ACK (as you mention for 2.) such processing? Am I > >>>> confusing something here? > >>>> > >>> > >>> Sorry for not being clear; the "this state" in the above > >> explanation refers to state I2-sent, not R2-sent. > >>> > >> What is your opinion on processing CLOSE messages in state > >> I2-sent? Do you have reasons why you don't process it in > that state? > >> > > > > I can't recall exactly the reason for this decision, but > another possible scenario: > > > > 1.) remote host sends CLOSE > > 2.) local host sends CLOSE_ACK, moves to CLOSED. CLOSE_ACK lost > > 3.) local host tries to immediately set up the session > again, sends I1, receives (stateless) R1 > > 4.) local host sends I2. Meanwhile, remote host is still > in CLOSING state until it gets I2, which it accepts and moves > back to R2-sent. Here it it more helpful for the local host > to just ignore the (stale) CLOSE from the past asso > > In my opinion it is unlikely that the Initiator confuses the > old CLOSE with a new close for the newly established > association because it is protected with an HMAC that depends > on the DH and puzzle used in the handshake. > Hence, processing of the CLOSE packet will only be successful > if the R1 counter has not advanced and the puzzle solution > was identical. However, the suggestion for generating new > puzzles is "once every few minutes" so identical session keys > could actually be the case and it is not so unlikely at all. > > It might make sense to be able to detect replayed and old > CLOSE packets reliably to avoid vulnerabilities for hosts > that set up and close connections rapidly. Such detection > should probably happen via the HMAC/shared key. Hence, the > key generation should be different. The best option for > varying keys would be the puzzle. > > My suggestion would be: > > a) add a recommendation that a host SHOULD to not send the > same puzzle to a host twice. A host can use the opaque field > in the puzzle to generate unique puzzle parameters (e.g., by > using a counter as input for the generation of I and by using > the opaque field in the puzzle to remember it). > > or > > b) add MUST to use different puzzles. This may be a bit more > costly because a host could deprive the puzzles that can be > indexed with the opaque field with 2^16 I1 packets. In that > case the responder would have to increase the R1 generation > counter (and would possibly generate new DH keys and > signatures for these). > > Any opinions? > I had some similar thoughts when originally replying (about the possible ne= ed to detect replayed CLOSE packets) and of the two choices above, I would = probably favor a). - Tom From julienl@qualcomm.com Wed Oct 20 10:02:40 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C27993A69E0 for ; Wed, 20 Oct 2010 10:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.591 X-Spam-Level: X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdNwf7tfe+B9 for ; Wed, 20 Oct 2010 10:02:39 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 728293A68F2 for ; Wed, 20 Oct 2010 10:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1287594253; x=1319130253; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Tobias=20Heer=20,=20HIP=20 WG=20|Date:=20Wed,=2020=20Oct=202010=201 0:04:09=20-0700|Subject:=20RE:=20[Hipsec]=20Completing=20 5201=20state=20machine|Thread-Topic:=20[Hipsec]=20Complet ing=205201=20state=20machine|Thread-Index:=20Actq8Y6leclJ dGSqQ5uBcVAZc+ZZogFhp9qA|Message-ID:=20 |References:=20<917A9DF6-17C4-4AAF-9132-1A865D0A824B@cs.r wth-aachen.de>|In-Reply-To:=20<917A9DF6-17C4-4AAF-9132-1A 865D0A824B@cs.rwth-aachen.de>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=LX7JlIpggHl+jlTMpFuaXtIfm6H0G+vE0kylkNqZGVQ=; b=FlhGFF+vTFOSgrYV18RlnrDzfMxpd91cSXehqT76oYt+O7TiuKNv3sBg aiMcR/FkR+bK+zWMTSGHwIQ4MkSnLuDEJLnLnlaI2Xe9YatQsnOMto7Q+ ArvnKM5cSz0/YE17+REmBaigAmCwx8iH29cUGfQgBeZtND9EFeE36cpzj M=; X-IronPort-AV: E=McAfee;i="5400,1158,6142"; a="58661574" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP; 20 Oct 2010 10:04:12 -0700 X-IronPort-AV: E=Sophos;i="4.57,356,1283756400"; d="scan'208";a="13199920" Received: from nasanexhub01.na.qualcomm.com ([10.46.93.121]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-MD5; 20 Oct 2010 10:04:12 -0700 Received: from nasanexhc08.na.qualcomm.com (172.30.39.7) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.3.83.0; Wed, 20 Oct 2010 10:04:12 -0700 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhc08.na.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 20 Oct 2010 05:04:05 -1200 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Wed, 20 Oct 2010 10:04:18 -0700 From: "Laganier, Julien" To: Tobias Heer , HIP WG Date: Wed, 20 Oct 2010 10:04:09 -0700 Thread-Topic: [Hipsec] Completing 5201 state machine Thread-Index: Actq8Y6leclJdGSqQ5uBcVAZc+ZZogFhp9qA Message-ID: References: <917A9DF6-17C4-4AAF-9132-1A865D0A824B@cs.rwth-aachen.de> In-Reply-To: <917A9DF6-17C4-4AAF-9132-1A865D0A824B@cs.rwth-aachen.de> 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: [Hipsec] Completing 5201 state machine X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 17:02:40 -0000 Hello Tobias, I have no time to look into the details so I'm just asking here - sorry abo= ut that:=20 While we're at moving HIP forward to standard track we're going to make a c= ertain number of changes. Since experimental HIP already has a little broth= er that made it to Proposed Standard (SHIM6 in RFC 5533), could we simply r= eplicate that state machine into our standard track HIP (v2)? --julien Tobias Heer wrote: >=20 > Hello, >=20 > the state machine of RFC5201 (not -bis) has some white spots which I > try to cover now. Nothing essential is missing but it seems slightly > underspecified the way it is now. > Handling of the following packets is missing in some states: CLOSE, > CLOSE_ACK, and NOTIFY. And it is not caught by the "handle ANYOTHER" > rules that serve as catch-all. >=20 > I'll list the changes that I'll make here and ask for feedback from the > group and especially implementors. >=20 > 1.) Receive CLOSE in state I2-sent: > ------------------------------ > Why can this happen? > - R2 is lost (maybe repeatedly), Responder transitions to from R2-SENT > to ESTABLISHED because of timeout, Responder decides to close > association (because of some reason) >=20 > Proposed action: process packet > - successful: transition to CLOSING > - fail: drop and stay at I2-sent >=20 >=20 > 2.) Receive CLOSE in state R2-sent > ------------------------------ > Why can this happen? > - Responder cannot observe data packet flow (this is the case for some > implementations), Responder timeout for transition from R2-SENT to > ESTABLISHED has not fired yet, Initiator decides to close association > (because of some reason) >=20 > Proposed action: process packet > - successful: transition to CLOSING > - fail: drop and stay at R2-sent >=20 >=20 > 3.) Receive CLOSE_ACK in state R2-sent > ------------------------------ > Why can this happen? > - It shouldn't but there is nothing specified. >=20 > Proposed action: drop >=20 >=20 > 4.) Receive NOTIFY in state R2-sent > ------------------------------ > Why can this happen? > - Responder cannot observe the data channel and timeout has not fired > yet. >=20 > Proposed action: process and stay in R2 sent >=20 >=20 > 5.) Receive CLOSE_ACK in state ESTABLISHED > ------------------------------ > Why can this happen? > - It shouldn't but there is nothing specified. >=20 > Proposed action: drop >=20 >=20 > 6. Receive NOTIFY in state ESTABLISHED > ------------------------------ > Why can this happen? > - Well, there are many reasons for this. This is normal behavior. >=20 > Proposed action: process and stay in ESTABLISHED >=20 >=20 > I would appreciate if you could have a look at the proposed changes and > give feedback. None of the changes has dramatic effects on existing > implementations of HIPv1 but 1) and 2) might require some minor change > of code if the implementations don't handle (or handle differently) the > CLOSE messages in these states. >=20 > BR, >=20 > Tobias >=20 > -- > Dipl.-Inform. Tobias Heer, Ph.D. Student > Chair of Communication and Distributed Systems - comsys > RWTH Aachen University, Germany > tel: +49 241 80 207 76 > web: http://ds.cs.rwth-aachen.de/members/heer > blog: http://dtobi.wordpress.com/ > card: http://card.ly/dtobi >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From heer@informatik.rwth-aachen.de Wed Oct 20 12:21:06 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 606AF3A680D for ; Wed, 20 Oct 2010 12:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.368 X-Spam-Level: X-Spam-Status: No, score=-4.368 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 msInEVs-+qZJ for ; Wed, 20 Oct 2010 12:21:02 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 7502D3A67DF for ; Wed, 20 Oct 2010 12:21:02 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LAL005UXSHM0B60@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Wed, 20 Oct 2010 21:22:34 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.57,356,1283724000"; d="scan'208";a="77819047" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Wed, 20 Oct 2010 21:22:35 +0200 Received: from [192.168.3.3] ([unknown] [91.179.7.114]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LAL00F7CSHLXI90@relay-auth-2.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Wed, 20 Oct 2010 21:22:34 +0200 (CEST) From: Tobias Heer In-reply-to: <7CC566635CFE364D87DC5803D4712A6C4CEC451A22@XCH-NW-10V.nw.nos.boeing.com> Date: Wed, 20 Oct 2010 21:22:32 +0200 Message-id: <501C3DB4-1F0B-458E-BD7A-0265E63D19CD@cs.rwth-aachen.de> References: <7CC566635CFE364D87DC5803D4712A6C4CEC451A0E@XCH-NW-10V.nw.nos.boeing.com> <7CC566635CFE364D87DC5803D4712A6C4CEC451A22@XCH-NW-10V.nw.nos.boeing.com> To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.1081) Cc: HIP WG Subject: Re: [Hipsec] CLOSE and identical session keys X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 19:21:06 -0000 Hello Tom (and everyone else involved), Am 20.10.2010 um 17:16 schrieb Henderson, Thomas R: >> [...] >> a) add a recommendation that a host SHOULD to not send the >> same puzzle to a host twice. A host can use the opaque field >> in the puzzle to generate unique puzzle parameters (e.g., by >> using a counter as input for the generation of I and by using >> the opaque field in the puzzle to remember it). >> >> or >> >> b) add MUST to use different puzzles. This may be a bit more >> costly because a host could deprive the puzzles that can be >> indexed with the opaque field with 2^16 I1 packets. In that >> case the responder would have to increase the R1 generation >> counter (and would possibly generate new DH keys and >> signatures for these). >> >> Any opinions? >> > > I had some similar thoughts when originally replying (about the possible need to detect replayed CLOSE packets) and of the two choices above, I would probably favor a). > My suggestion for the new passage for RFC5201-bis: The puzzle value I and the solution J are inputs for deriving the keying material from the Diffie Hellman key exchange (Section 6.5). Therefore, a responder SHOULD NOT use the same puzzle I with the same DH keys for the same Initiator twice to ensure that the derived keying material differs. Such uniqueness can be achieved, for example, by using a counter as input for generating I. This counter can be increased for each processed I1 packet. The state of the counter can be transmitted in the Opaque data field in the PUZZLE (Section 5.2.4), in an ECHO_REQUEST_SIGNED (Section 5.2.19) or in an ECHO_REQUEST_UNSIGNED parameter (Section 5.2.20) without the need to establish state. Any comments / suggestions? However, with this passage some other text on the puzzle requires minor changes and clarifications as well. BR, Tobias -- Dipl.-Inform. Tobias Heer, Ph.D. Student Chair of Communication and Distributed Systems - comsys RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi From ari.keranen@nomadiclab.com Thu Oct 21 04:47:24 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BD933A6452 for ; Thu, 21 Oct 2010 04:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 sD5dvMZaqwvX for ; Thu, 21 Oct 2010 04:47:23 -0700 (PDT) Received: from gw.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id BD3A43A66B4 for ; Thu, 21 Oct 2010 04:47:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id E58F34E6C1; Thu, 21 Oct 2010 14:48:53 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJki94321dEE; Thu, 21 Oct 2010 14:48:53 +0300 (EEST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 4769D4E6BD; Thu, 21 Oct 2010 14:48:53 +0300 (EEST) Message-ID: <4CC028A5.10408@nomadiclab.com> Date: Thu, 21 Oct 2010 14:48:53 +0300 From: Ari Keranen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8 MIME-Version: 1.0 To: Tobias Heer References: <20101018121505.4D2D43A6D9E@core3.amsl.com> <4CBC3DAC.7020404@nomadiclab.com> <16D5B0B9-F299-4177-8769-364172361798@cs.rwth-aachen.de> In-Reply-To: <16D5B0B9-F299-4177-8769-364172361798@cs.rwth-aachen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP WG Subject: Re: [Hipsec] I-D Action:draft-ietf-hip-over-hip-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 11:47:24 -0000 Hi Tobi, Thanks for the review! Comments inline. On 10/19/2010 05:07 PM, Tobias Heer wrote: > a) In my opinion, there is a good reason why HIP control messages are > not encrypted by default. I think this design was chosen to support > on-path elements so that they can understand what's going on. Sending > HIP control messages over encrypted channel obviously changes this > property. I think this should be stated somewhere. OK, I can add a comment about that. > b) Sending HIP control messages over an encrypted channel makes some > of the security measures that HIP uses unnecessary. The HMAC might > still be needed (because ESP without authentication is deemed > insecure). However, the public-key signature of the update seems > quite superfluous to me now because it is intended to help on-path > verification of packets - which the encryption prevents. Maybe the > draft should comment on this? The update signatures is mandatory > (according to RFC5201) so it might be an option not to touch it and > accept the wasted overhead (although I don't fancy that option). I would prefer not to modify the HIP protocol itself even if some of the features would become redundant. The idea of the ESP transport mode(s) was to work as a drop-in replacement for the regular (no encryption) mode. Regarding the signature, hosts that are on the encrypted path as one of the relaying elements (e.g., in a HIP BONE scenario) could still use it for verification since they terminate the ESP tunnels and thus see the decrypted HIP packets, right? > c) You discuss host mobility but do not mention multihoming is this > intended? I did not see any special behavior that would be needed for the multihoming case (beyond what is needed for the mobility cases), but you're right that making this more explicit makes sense. I changed the "Mobility" section's name into "Mobility and Multihoming" and we can add more details there if needed (see next question). > d) To me it is not entirely clear how mobility or multihoming would > work with the encrypted channels in place. You describe that it can > work if it is done before the connection breaks. Would both hosts set > up new SA pairs / TCP connections for all of their possible address > pairs in order to do the address verification? If yes, the address > verification during the update is rather useless for TCP because TCP > does its own handshake already. If no, how does it work? Am I missing > the point here? It seems there could be more details on this. The basic idea was "do as you used to do but once you're done (with mobility and/or multihoming actions) send HIP messages over the new SA". That is, in the TCP mode the TCP connection used for the HIP messages should survive just like any other TCP connection and in the ESP mode, once there is a new SA, it is used for the messages. So new SA pairs would be set for all pairs (as before) and there would be no new TCP connections or handshakes but the address verification works as it used to. Cheers, Ari From heer@informatik.rwth-aachen.de Thu Oct 21 05:41:41 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22E853A691A for ; Thu, 21 Oct 2010 05:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.49 X-Spam-Level: X-Spam-Status: No, score=-4.49 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 F6PS1GHIlZ5o for ; Thu, 21 Oct 2010 05:41:37 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 548413A69A9 for ; Thu, 21 Oct 2010 05:41:28 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LAN006054L2E860@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Thu, 21 Oct 2010 14:41:26 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.58,217,1286143200"; d="scan'208";a="77927173" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Thu, 21 Oct 2010 14:41:26 +0200 Received: from umic-i4-137-226-45-90.nn.rwth-aachen.de ([unknown] [137.226.45.90]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LAN009LD4L22340@relay-auth-2.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Thu, 21 Oct 2010 14:41:26 +0200 (CEST) From: Tobias Heer In-reply-to: Date: Thu, 21 Oct 2010 14:41:25 +0200 Message-id: References: <917A9DF6-17C4-4AAF-9132-1A865D0A824B@cs.rwth-aachen.de> To: "Laganier, Julien" X-Mailer: Apple Mail (2.1081) Cc: HIP WG Subject: Re: [Hipsec] Completing 5201 state machine X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 12:41:41 -0000 Hi Julien, Am 20.10.2010 um 19:04 schrieb Laganier, Julien: > Hello Tobias, > > I have no time to look into the details so I'm just asking here - sorry about that: > > While we're at moving HIP forward to standard track we're going to make a certain number of changes. Since experimental HIP already has a little brother that made it to Proposed Standard (SHIM6 in RFC 5533), could we simply replicate that state machine into our standard track HIP (v2)? I'll investigate this. Maybe we can borrow this and that. However, the state machine is not wrong or shaky but merely did not mention a few corner cases which should be handled for completeness. I assume that most implementation implement the suggested "new" behavior already. However, thanks for the good suggestion! Tobias > > --julien > > Tobias Heer wrote: >> >> Hello, >> >> the state machine of RFC5201 (not -bis) has some white spots which I >> try to cover now. Nothing essential is missing but it seems slightly >> underspecified the way it is now. >> Handling of the following packets is missing in some states: CLOSE, >> CLOSE_ACK, and NOTIFY. And it is not caught by the "handle ANYOTHER" >> rules that serve as catch-all. >> >> I'll list the changes that I'll make here and ask for feedback from the >> group and especially implementors. >> >> 1.) Receive CLOSE in state I2-sent: >> ------------------------------ >> Why can this happen? >> - R2 is lost (maybe repeatedly), Responder transitions to from R2-SENT >> to ESTABLISHED because of timeout, Responder decides to close >> association (because of some reason) >> >> Proposed action: process packet >> - successful: transition to CLOSING >> - fail: drop and stay at I2-sent >> >> >> 2.) Receive CLOSE in state R2-sent >> ------------------------------ >> Why can this happen? >> - Responder cannot observe data packet flow (this is the case for some >> implementations), Responder timeout for transition from R2-SENT to >> ESTABLISHED has not fired yet, Initiator decides to close association >> (because of some reason) >> >> Proposed action: process packet >> - successful: transition to CLOSING >> - fail: drop and stay at R2-sent >> >> >> 3.) Receive CLOSE_ACK in state R2-sent >> ------------------------------ >> Why can this happen? >> - It shouldn't but there is nothing specified. >> >> Proposed action: drop >> >> >> 4.) Receive NOTIFY in state R2-sent >> ------------------------------ >> Why can this happen? >> - Responder cannot observe the data channel and timeout has not fired >> yet. >> >> Proposed action: process and stay in R2 sent >> >> >> 5.) Receive CLOSE_ACK in state ESTABLISHED >> ------------------------------ >> Why can this happen? >> - It shouldn't but there is nothing specified. >> >> Proposed action: drop >> >> >> 6. Receive NOTIFY in state ESTABLISHED >> ------------------------------ >> Why can this happen? >> - Well, there are many reasons for this. This is normal behavior. >> >> Proposed action: process and stay in ESTABLISHED >> >> >> I would appreciate if you could have a look at the proposed changes and >> give feedback. None of the changes has dramatic effects on existing >> implementations of HIPv1 but 1) and 2) might require some minor change >> of code if the implementations don't handle (or handle differently) the >> CLOSE messages in these states. >> >> BR, >> >> Tobias >> >> -- >> Dipl.-Inform. Tobias Heer, Ph.D. Student >> Chair of Communication and Distributed Systems - comsys >> RWTH Aachen University, Germany >> tel: +49 241 80 207 76 >> web: http://ds.cs.rwth-aachen.de/members/heer >> blog: http://dtobi.wordpress.com/ >> card: http://card.ly/dtobi >> >> >> >> >> >> >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec -- Dipl.-Inform. Tobias Heer, Ph.D. Student Chair of Communication and Distributed Systems - comsys RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi From ari.keranen@nomadiclab.com Thu Oct 21 06:20:29 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B90D3A67B7 for ; Thu, 21 Oct 2010 06:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 sn9bdDnQUthd for ; Thu, 21 Oct 2010 06:20:28 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 174753A672F for ; Thu, 21 Oct 2010 06:20:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 2E56A4E6DA; Thu, 21 Oct 2010 16:22:01 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yu4pqmtCSQJz; Thu, 21 Oct 2010 16:22:00 +0300 (EEST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id A76444E6BD; Thu, 21 Oct 2010 16:22:00 +0300 (EEST) Message-ID: <4CC03E78.10106@nomadiclab.com> Date: Thu, 21 Oct 2010 16:22:00 +0300 From: Ari Keranen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8 MIME-Version: 1.0 To: Tobias Heer References: <7CC566635CFE364D87DC5803D4712A6C4CEC451A0E@XCH-NW-10V.nw.nos.boeing.com> <7CC566635CFE364D87DC5803D4712A6C4CEC451A22@XCH-NW-10V.nw.nos.boeing.com> <501C3DB4-1F0B-458E-BD7A-0265E63D19CD@cs.rwth-aachen.de> In-Reply-To: <501C3DB4-1F0B-458E-BD7A-0265E63D19CD@cs.rwth-aachen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP WG Subject: Re: [Hipsec] CLOSE and identical session keys X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 13:20:29 -0000 On 10/20/2010 10:22 PM, Tobias Heer wrote: > Hello Tom (and everyone else involved), > > Am 20.10.2010 um 17:16 schrieb Henderson, Thomas R: >>> [...] >>> a) add a recommendation that a host SHOULD to not send the >>> same puzzle to a host twice. A host can use the opaque field >>> in the puzzle to generate unique puzzle parameters (e.g., by >>> using a counter as input for the generation of I and by using >>> the opaque field in the puzzle to remember it). >>> >>> or >>> >>> b) add MUST to use different puzzles. This may be a bit more >>> costly because a host could deprive the puzzles that can be >>> indexed with the opaque field with 2^16 I1 packets. In that >>> case the responder would have to increase the R1 generation >>> counter (and would possibly generate new DH keys and >>> signatures for these). >>> >>> Any opinions? >>> >> >> I had some similar thoughts when originally replying (about the possible need to detect replayed CLOSE packets) and of the two choices above, I would probably favor a). >> > > My suggestion for the new passage for RFC5201-bis: > > The puzzle value I and the solution J are inputs for deriving the > keying material from the Diffie Hellman key exchange (Section 6.5). > Therefore, a responder SHOULD NOT use the same puzzle I with the same > DH keys for the same Initiator twice to ensure that the derived > keying material differs. Such uniqueness can be achieved, for > example, by using a counter as input for generating I. This counter > can be increased for each processed I1 packet. The state of the > counter can be transmitted in the Opaque data field in the PUZZLE > (Section 5.2.4), in an ECHO_REQUEST_SIGNED (Section 5.2.19) or in an > ECHO_REQUEST_UNSIGNED parameter (Section 5.2.20) without the need to > establish state. > > Any comments / suggestions? Looks good to me. Cheers, Ari From ari.keranen@nomadiclab.com Thu Oct 21 08:59:51 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D660C3A69F6 for ; Thu, 21 Oct 2010 08:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHY9dzU-OBlq for ; Thu, 21 Oct 2010 08:59:47 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 75B533A6899 for ; Thu, 21 Oct 2010 08:59:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 0029B4E6DC for ; Thu, 21 Oct 2010 19:01:22 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vMrPpMG25Rb for ; Thu, 21 Oct 2010 19:01:21 +0300 (EEST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 710C94E6BD for ; Thu, 21 Oct 2010 19:01:21 +0300 (EEST) Message-ID: <4CC063D1.1030706@nomadiclab.com> Date: Thu, 21 Oct 2010 19:01:21 +0300 From: Ari Keranen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8 MIME-Version: 1.0 To: HIP WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] TCP port negotiation for HIP over HIP X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 15:59:51 -0000 Hi all, In an off-line discussion we figured out that using a fixed TCP port number in the ESP TCP mode in the HIP-over-HIP draft would most likely require registering such a port with IANA (currently the draft uses 10500 noted as "reserved" by IANA due to same UDP port number being assigned for HIP NAT traversal), but since this port is never used outside of a HIP-initiated SA, it could be hard (and probably not make much sense) to register a port for that. Therefore, I would propose making the port number negotiable and piggyback it in the transport mode parameter negotiation. In practice the change would look something like this: http://users.piuha.net/akeranen/drafts/draft-ietf-hip-over-hip.rHEAD.xml-diff.html Opinions? Cheers, Ari From mkomu@cs.hut.fi Thu Oct 21 09:07:22 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D61173A693B for ; Thu, 21 Oct 2010 09:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.244 X-Spam-Level: X-Spam-Status: No, score=-6.244 tagged_above=-999 required=5 tests=[AWL=0.355, 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 31TASnr39-RQ for ; Thu, 21 Oct 2010 09:07:21 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by core3.amsl.com (Postfix) with ESMTP id 1F5833A680A for ; Thu, 21 Oct 2010 09:07:21 -0700 (PDT) Received: from hutcs.cs.hut.fi ([130.233.192.10] helo=[127.0.0.1]) by mail.cs.hut.fi with esmtp (Exim 4.54) id 1P8xhI-0004mx-CJ for hipsec@ietf.org; Thu, 21 Oct 2010 19:08:56 +0300 Message-ID: <4CC06598.9020008@cs.hut.fi> Date: Thu, 21 Oct 2010 19:08:56 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: hipsec@ietf.org References: <4CC063D1.1030706@nomadiclab.com> In-Reply-To: <4CC063D1.1030706@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] TCP port negotiation for HIP over HIP X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 16:07:22 -0000 On 10/21/2010 07:01 PM, Ari Keranen wrote: > Hi all, > > In an off-line discussion we figured out that using a fixed TCP port > number in the ESP TCP mode in the HIP-over-HIP draft would most likely > require registering such a port with IANA (currently the draft uses > 10500 noted as "reserved" by IANA due to same UDP port number being > assigned for HIP NAT traversal), but since this port is never used > outside of a HIP-initiated SA, it could be hard (and probably not make > much sense) to register a port for that. > > Therefore, I would propose making the port number negotiable and > piggyback it in the transport mode parameter negotiation. In practice > the change would look something like this: > http://users.piuha.net/akeranen/drafts/draft-ietf-hip-over-hip.rHEAD.xml-diff.html > > > Opinions? Hi, sounds reasonable to me. From julienl@qualcomm.com Thu Oct 21 09:15:14 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F6C23A683E for ; Thu, 21 Oct 2010 09:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.591 X-Spam-Level: X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAnmrvJKV82h for ; Thu, 21 Oct 2010 09:15:03 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id B36423A6A22 for ; Thu, 21 Oct 2010 09:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1287677798; x=1319213798; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Tobias=20Heer=20|CC:=20HIP =20WG=20|Date:=20Thu,=2021=20Oct=202010 =2009:16:35=20-0700|Subject:=20RE:=20[Hipsec]=20Completin g=205201=20state=20machine|Thread-Topic:=20[Hipsec]=20Com pleting=205201=20state=20machine|Thread-Index:=20ActxHVFW Uyjy5qJLQNu3GyeBrcHo3gAHV0eg|Message-ID:=20|References:=20<917A9DF6-17C4-4AAF-9132-1A865D0A824B@cs. rwth-aachen.de>=0D=0A=20=0D=0A=20 |In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=IOqBQk75xkzHk3AkIyaTCDxN6zYE6o39Y6Oq6e3pZX8=; b=xZjfKA1Qt26wBdYUmeE3qbr/IxMhKon7zBHFgF3c5ghCZOyUTEywZdjU 924sIU5LFV7Fw9gy9YFj7hGIYn/nZG9wNdsMrMsk6Tcqa36rzSxkxOzhD mzu/Bu9huAWAUubIoSY0jE4IrIRkOJbRfHQ+ae9+8yjSBOuxeZsLly0xm c=; X-IronPort-AV: E=McAfee;i="5400,1158,6142"; a="58799326" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP; 21 Oct 2010 09:16:38 -0700 X-IronPort-AV: E=Sophos;i="4.58,217,1286175600"; d="scan'208";a="89908744" Received: from nasanexhub01.na.qualcomm.com ([10.46.93.121]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 21 Oct 2010 09:16:38 -0700 Received: from nasanexhc09.na.qualcomm.com (172.30.39.8) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.3.83.0; Thu, 21 Oct 2010 09:16:36 -0700 Received: from nalasexhc02.na.qualcomm.com (10.47.129.186) by nasanexhc09.na.qualcomm.com (172.30.39.8) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 21 Oct 2010 09:16:30 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Thu, 21 Oct 2010 09:16:47 -0700 From: "Laganier, Julien" To: Tobias Heer Date: Thu, 21 Oct 2010 09:16:35 -0700 Thread-Topic: [Hipsec] Completing 5201 state machine Thread-Index: ActxHVFWUyjy5qJLQNu3GyeBrcHo3gAHV0eg Message-ID: References: <917A9DF6-17C4-4AAF-9132-1A865D0A824B@cs.rwth-aachen.de> 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: HIP WG Subject: Re: [Hipsec] Completing 5201 state machine X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 16:15:14 -0000 Tobias Heer wrote: >=20 > Hi Julien, >=20 > Am 20.10.2010 um 19:04 schrieb Laganier, Julien: >=20 > > Hello Tobias, > > > > I have no time to look into the details so I'm just asking here - > sorry about that: > > > > While we're at moving HIP forward to standard track we're going to > make a certain number of changes. Since experimental HIP already has a > little brother that made it to Proposed Standard (SHIM6 in RFC 5533), > could we simply replicate that state machine into our standard track > HIP (v2)? >=20 > I'll investigate this. Maybe we can borrow this and that. However, the > state machine is not wrong or shaky but merely did not mention a few > corner cases which should be handled for completeness. > I assume that most implementation implement the suggested "new" > behavior already. No need to investigate, I checked RFC 5533 and it doesn't have the CLOSE / = CLOSE ACK handshake that Erik originally proposed for HIP. For those intere= sted, more details here: --julien From heer@informatik.rwth-aachen.de Sat Oct 23 07:29:03 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 577153A68D7 for ; Sat, 23 Oct 2010 07:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.476 X-Spam-Level: X-Spam-Status: No, score=-4.476 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 VFFYmo6H37lQ for ; Sat, 23 Oct 2010 07:29:02 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id D27953A68CC for ; Sat, 23 Oct 2010 07:29:01 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LAQ00KNRYZ4LK10@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Sat, 23 Oct 2010 16:30:40 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.58,227,1286143200"; d="scan'208";a="41645330" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Sat, 23 Oct 2010 16:30:40 +0200 Received: from [192.168.3.5] ([unknown] [91.179.168.66]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LAQ006VKYZ30U60@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Sat, 23 Oct 2010 16:30:40 +0200 (CEST) From: Tobias Heer Date: Sat, 23 Oct 2010 16:30:39 +0200 Message-id: References: <20101023142325.22FD03A688D@core3.amsl.com> To: HIP WG X-Mailer: Apple Mail (2.1081) Subject: [Hipsec] Fwd: New Version Notification for draft-ietf-hip-rfc5201-bis-03 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2010 14:29:03 -0000 Hello everyone, we just submitted this new version of draft-ietf-hip-rfc5201-bis. The document is available here: http://datatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis/ I would like to encourage you to provide feedback and reviews. Thanks! BR, Tobias Anfang der weitergeleiteten E-Mail: > Von: IETF I-D Submission Tool > Datum: 23. Oktober 2010 16:23:25 MESZ > An: heer@cs.rwth-aachen.de > Kopie: robert.moskowitz@icsalabs.com, petri.jokela@nomadiclab.com, thomas.r.henderson@boeing.com > Betreff: New Version Notification for draft-ietf-hip-rfc5201-bis-03 > > > A new version of I-D, draft-ietf-hip-rfc5201-bis-03.txt has been successfully submitted by Tobias Heer and posted to the IETF repository. > > Filename: draft-ietf-hip-rfc5201-bis > Revision: 03 > Title: Host Identity Protocol > Creation_date: 2010-10-23 > WG ID: hip > Number_of_pages: 116 > > Abstract: > This document specifies the details of the Host Identity Protocol > (HIP). HIP allows consenting hosts to securely establish and > maintain shared IP-layer state, allowing separation of the identifier > and locator roles of IP addresses, thereby enabling continuity of > communications across IP address changes. HIP is based on a SIGMA- > compliant Diffie-Hellman key exchange, using public key identifiers > from a new Host Identity namespace for mutual peer authentication. > The protocol is designed to be resistant to denial-of-service (DoS) > and man-in-the-middle (MitM) attacks. When used together with > another suitable security protocol, such as the Encapsulated Security > Payload (ESP), it provides integrity protection and optional > encryption for upper-layer protocols, such as TCP and UDP. > > This document obsoletes RFC 5201 and addresses the concerns raised by > the IESG, particularly that of crypto agility. It also incorporates > lessons learned from the implementations of RFC 5201. > > > > The IETF Secretariat. > > -- Dipl.-Inform. Tobias Heer, Ph.D. Student Chair of Communication and Distributed Systems - comsys RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi From root@core3.amsl.com Sat Oct 23 07:30:05 2010 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B9F9E3A68C4; Sat, 23 Oct 2010 07:30:02 -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: <20101023143004.B9F9E3A68C4@core3.amsl.com> Date: Sat, 23 Oct 2010 07:30:03 -0700 (PDT) Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-rfc5201-bis-03.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2010 14:30:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol Author(s) : R. Moskowitz, et al. Filename : draft-ietf-hip-rfc5201-bis-03.txt Pages : 116 Date : 2010-10-23 This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a SIGMA- compliant Diffie-Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCP and UDP. This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-rfc5201-bis-03.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-hip-rfc5201-bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-23072324.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 25 08:30:02 2010 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id F12503A6A7C; Mon, 25 Oct 2010 08:30: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: <20101025153001.F12503A6A7C@core3.amsl.com> Date: Mon, 25 Oct 2010 08:30:01 -0700 (PDT) Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-over-hip-03.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 15:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol Signaling Message Transport Modes Author(s) : A. Keranen Filename : draft-ietf-hip-over-hip-03.txt Pages : 10 Date : 2010-10-25 This document specifies two transport modes for Host Identity Protocol (HIP) signaling messages that allow conveying them over encrypted connections initiated with the Host Identity Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-over-hip-03.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-hip-over-hip-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-25081657.I-D@ietf.org> --NextPart-- From ari.keranen@nomadiclab.com Tue Oct 26 06:50:48 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B9F13A6888 for ; Tue, 26 Oct 2010 06:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 HLhcj7LXMSG1 for ; Tue, 26 Oct 2010 06:50:46 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 950353A6784 for ; Tue, 26 Oct 2010 06:50:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 6AAA74E6DA for ; Tue, 26 Oct 2010 16:52:33 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pw6AGh+V9J+a for ; Tue, 26 Oct 2010 16:52:32 +0300 (EEST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id D9B894E6D8 for ; Tue, 26 Oct 2010 16:52:32 +0300 (EEST) Message-ID: <4CC6DD20.5030406@nomadiclab.com> Date: Tue, 26 Oct 2010 16:52:32 +0300 From: Ari Keranen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.14) Gecko/20101006 Lightning/1.0b1 Thunderbird/3.0.9 MIME-Version: 1.0 To: hipsec@ietf.org References: <20101025153001.F12503A6A7C@core3.amsl.com> In-Reply-To: <20101025153001.F12503A6A7C@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] I-D Action:draft-ietf-hip-over-hip-03.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 13:50:48 -0000 Hi all, This version has fixes for the WGLC comments from Tobias and also adds the port negotiation feature discussed in the other thread. Diff is available here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-hip-over-hip-03.txt I think this draft is ready to move forward, but comments on the latest changes are still appreciated. Cheers, Ari On 10/25/2010 06:30 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Host Identity Protocol Working Group of the IETF. > > > Title : Host Identity Protocol Signaling Message Transport Modes > Author(s) : A. Keranen > Filename : draft-ietf-hip-over-hip-03.txt > Pages : 10 > Date : 2010-10-25 > > This document specifies two transport modes for Host Identity > Protocol (HIP) signaling messages that allow conveying them over > encrypted connections initiated with the Host Identity Protocol. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-hip-over-hip-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From thomas.r.henderson@boeing.com Tue Oct 26 21:52:45 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89E803A67E3 for ; Tue, 26 Oct 2010 21:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.231 X-Spam-Level: X-Spam-Status: No, score=-106.231 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoPj0OLQp-uV for ; Tue, 26 Oct 2010 21:52:44 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 0968E3A698C for ; Tue, 26 Oct 2010 21:36:06 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o9R4bnAT016534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 26 Oct 2010 21:37:50 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o9R4bnli009317; Tue, 26 Oct 2010 21:37:49 -0700 (PDT) Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o9R4bnQl009313 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 26 Oct 2010 21:37:49 -0700 (PDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Tue, 26 Oct 2010 21:37:49 -0700 From: "Henderson, Thomas R" To: "'Ari Keranen'" , HIP WG Date: Tue, 26 Oct 2010 21:37:48 -0700 Thread-Topic: [Hipsec] TCP port negotiation for HIP over HIP Thread-Index: ActxOWBBFE/5cQQbR8WR0DDpC742VgEV0ncQ Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CEC451A74@XCH-NW-10V.nw.nos.boeing.com> References: <4CC063D1.1030706@nomadiclab.com> In-Reply-To: <4CC063D1.1030706@nomadiclab.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: [Hipsec] TCP port negotiation for HIP over HIP X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 04:52:45 -0000 > -----Original Message----- > From: hipsec-bounces@ietf.org > [mailto:hipsec-bounces@ietf.org] On Behalf Of Ari Keranen > Sent: Thursday, October 21, 2010 9:01 AM > To: HIP WG > Subject: [Hipsec] TCP port negotiation for HIP over HIP > > Hi all, > > In an off-line discussion we figured out that using a fixed TCP port > number in the ESP TCP mode in the HIP-over-HIP draft would > most likely > require registering such a port with IANA (currently the draft uses > 10500 noted as "reserved" by IANA due to same UDP port number being > assigned for HIP NAT traversal), but since this port is never used > outside of a HIP-initiated SA, it could be hard (and probably > not make > much sense) to register a port for that. > > Therefore, I would propose making the port number negotiable and > piggyback it in the transport mode parameter negotiation. In practice > the change would look something like this: > http://users.piuha.net/akeranen/drafts/draft-ietf-hip-over-hip > .rHEAD.xml-diff.html > > Opinions? > +1 - Tom From ari.keranen@nomadiclab.com Wed Oct 27 03:03:22 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A68C3A6905 for ; Wed, 27 Oct 2010 03:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 KSKlirXNZh5J for ; Wed, 27 Oct 2010 03:03:21 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 150B53A67A7 for ; Wed, 27 Oct 2010 03:03:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id E447A4E6DC for ; Wed, 27 Oct 2010 13:04:49 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5pSzkDdcfSZ for ; Wed, 27 Oct 2010 13:04:49 +0300 (EEST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 7D5DE4E6D8 for ; Wed, 27 Oct 2010 13:04:49 +0300 (EEST) Message-ID: <4CC7F954.3060907@nomadiclab.com> Date: Wed, 27 Oct 2010 13:05:08 +0300 From: Ari Keranen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.14) Gecko/20101006 Lightning/1.0b1 Thunderbird/3.0.9 MIME-Version: 1.0 To: HIP WG References: <4CC063D1.1030706@nomadiclab.com> In-Reply-To: <4CC063D1.1030706@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] TCP port negotiation for HIP over HIP X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 10:03:22 -0000 Hi all, FYI, people seemed to agree that this is a good idea (thanks to all commenting, on and off-list), so this feature is included in the latest revision. Cheers, Ari From ari.keranen@nomadiclab.com Fri Oct 29 05:05:33 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2C303A6899 for ; Fri, 29 Oct 2010 05:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 3pWwSGQrwc69 for ; Fri, 29 Oct 2010 05:05:32 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 4E92E3A683B for ; Fri, 29 Oct 2010 05:05:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 6DFB14E6D8 for ; Fri, 29 Oct 2010 14:53:52 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDWYU6fQVc7H for ; Fri, 29 Oct 2010 14:53:51 +0300 (EEST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 9DA3C4E6D4 for ; Fri, 29 Oct 2010 14:53:51 +0300 (EEST) Message-ID: <4CCAB8DB.1080506@nomadiclab.com> Date: Fri, 29 Oct 2010 15:06:51 +0300 From: Ari Keranen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.14) Gecko/20101006 Lightning/1.0b1 Thunderbird/3.0.9 MIME-Version: 1.0 To: hipsec@ietf.org References: <20101025153001.F12503A6A7C@core3.amsl.com> <4CC6DD20.5030406@nomadiclab.com> In-Reply-To: <4CC6DD20.5030406@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] I-D Action:draft-ietf-hip-over-hip-03.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 12:05:33 -0000 Hi all, Based on off-list feedback, it seems that the mobility & multihoming part would still deserve some more details. Since we're past the cut-off date, I'll update the draft after the meeting. Cheers, Ari On 10/26/2010 04:52 PM, Ari Keranen wrote: > Hi all, > > This version has fixes for the WGLC comments from Tobias and also adds > the port negotiation feature discussed in the other thread. Diff is > available here: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-hip-over-hip-03.txt > > I think this draft is ready to move forward, but comments on the latest > changes are still appreciated. > > > Cheers, > Ari > > On 10/25/2010 06:30 PM, Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Host Identity Protocol Working Group >> of the IETF. >> >> >> Title : Host Identity Protocol Signaling Message Transport Modes >> Author(s) : A. Keranen >> Filename : draft-ietf-hip-over-hip-03.txt >> Pages : 10 >> Date : 2010-10-25 >> >> This document specifies two transport modes for Host Identity >> Protocol (HIP) signaling messages that allow conveying them over >> encrypted connections initiated with the Host Identity Protocol. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-hip-over-hip-03.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec