From hipsec-bounces@ietf.org Mon Nov 3 05:42:30 2008 Return-Path: X-Original-To: hipsec-archive@megatron.ietf.org Delivered-To: ietfarch-hipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BB573A6AA9; Mon, 3 Nov 2008 05:42:30 -0800 (PST) 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 86DB33A6AD0 for ; Mon, 3 Nov 2008 05:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.116 X-Spam-Level: X-Spam-Status: No, score=-6.116 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 lKhex4WNL03U for ; Mon, 3 Nov 2008 05:42:28 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id B69453A6AA9 for ; Mon, 3 Nov 2008 05:42:28 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A09F1212DD for ; Mon, 3 Nov 2008 14:42:25 +0100 (CET) X-AuditID: c1b4fb3e-ac781bb00000537b-98-490effc10c85 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9224D212CF for ; Mon, 3 Nov 2008 14:42:25 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Nov 2008 14:42:25 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Nov 2008 14:42:25 +0100 Received: from [131.160.37.21] (E000FB0F665DD.lmf.ericsson.se [131.160.37.21]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 10B092339 for ; Mon, 3 Nov 2008 15:42:25 +0200 (EET) Message-ID: <490EFFC0.6060304@ericsson.com> Date: Mon, 03 Nov 2008 15:42:24 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: HIP X-OriginalArrivalTime: 03 Nov 2008 13:42:25.0153 (UTC) FILETIME=[0148CF10:01C93DBA] X-Brightmail-Tracker: AAAAAA== Subject: [Hipsec] New version of the HICCUPS draft 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Folks, we have just submitted a new version of the HICCUPS draft: http://www.ietf.org/internet-drafts/draft-nikander-hip-hiccups-01.txt As usual, comments are welcome. Cheers, Gonzalo _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Tue Nov 4 07:23:27 2008 Return-Path: X-Original-To: hipsec-archive@megatron.ietf.org Delivered-To: ietfarch-hipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74E0C3A69C5; Tue, 4 Nov 2008 07:23:27 -0800 (PST) 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 5D9F33A69C3 for ; Tue, 4 Nov 2008 07:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0F0x1M3WLcO for ; Tue, 4 Nov 2008 07:23:25 -0800 (PST) Received: from creon.otaverkko.fi (creon.otaverkko.fi [212.68.0.5]) by core3.amsl.com (Postfix) with ESMTP id 2BA2E3A69C5 for ; Tue, 4 Nov 2008 07:23:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by creon.otaverkko.fi (Postfix) with ESMTP id AB0AE21AF4F; Tue, 4 Nov 2008 17:23:21 +0200 (EET) Received: from creon.otaverkko.fi ([127.0.0.1]) by localhost (creon.otaverkko.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04859-05; Tue, 4 Nov 2008 17:23:15 +0200 (EET) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by creon.otaverkko.fi (Postfix) with ESMTP id 7E9A221AF4C; Tue, 4 Nov 2008 17:23:15 +0200 (EET) Received: from [192.168.1.14] (cs135140.pp.htv.fi [213.243.135.140]) by argo.otaverkko.fi (Postfix) with ESMTP id 6A34825ED06; Tue, 4 Nov 2008 17:23:15 +0200 (EET) Message-ID: <491068E3.5050203@hiit.fi> Date: Tue, 04 Nov 2008 17:23:15 +0200 From: Varjonen Samu User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Gonzalo Camarillo References: <490EFFC0.6060304@ericsson.com> In-Reply-To: <490EFFC0.6060304@ericsson.com> X-Virus-Scanned: amavisd-new at otaverkko.fi Cc: HIP Subject: Re: [Hipsec] New version of the HICCUPS draft 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Gonzalo Camarillo wrote: > Folks, > > we have just submitted a new version of the HICCUPS draft: > > http://www.ietf.org/internet-drafts/draft-nikander-hip-hiccups-01.txt > > As usual, comments are welcome. > > Cheers, > > Gonzalo > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec Hi, Some comments and questions on draft-nikander-hip-hiccups-01. These are the points where I would like to see some clarifications. In section 3 in the definition of the HIP DATA packet, it says that the optional parameters are SEQ and ACK and on the next line they are SEQ_DATA and ACK_DATA. Same section in the reference to RFC5201 and end of section 2.1.1, a question. Currently Next Header is set to 0x3B (59) "No Next Header", Should there be "TBD IANA" for a new value for this field because now there is data after the header and the definition of 59 is "Note that there is also a "dummy" extension header called No Next Header that has a value of 59. This is a placeholder that when found in the Next Header field indicates that there is nothing after that extension header." and this says there is *nothing* after the header. section 3.3 Next Header, "identifies the data that protected by this..." to "Identifies the data that is protected by this..." Section 4.2 the generation of a HIP DATA packet. Where and how exactly is the data gotten from the upper-layer? This is not handled in the draft. To me this sounds like it should be handled in native API draft for natively HIP aware applications and for legacy applications by doing local policies like "protocols that would use UDP should use HIP DATA instead". Now the draft just gets the data from "somewhere". Same section point 1, the host just takes a sequence number. I think it would be easier to just use monotonically increasing sequence numbers as the original SEQ and its UPDATE id does. Then the book keeping on which numbers are used is much simpler. Same as above, more clarification on the processing window, duration, how it is defined and so on. Same section point 4, how is RTT estimate calculated? Is there some uniform way to do this or can implementors just decide on one. For example TCP has some initial values and information on how to calculate the estimates, should we have something similar? Same section point 5, is the DATA_ENTRY_MAX totally based upon local policy or is there some HIP default? Same section and point, about the error notification and its counterpart, should also ACKed HIP DATA packets be ACKed to the application. This actually could be too much but for some applications it could be a useful socket option in Native API. Section 4.3 "The host MAY responds..." to "The host MAY respond..." Same section, "... if the packet contained SEQ_DATA and PAYLOAD_HMAC parameter. Because PAYLOAD_HMAC is mandatory parameter in HIP DATA packet it would be enough to say if it contained SEQ_DATA Section 4.3.1, How long ago is this recently received, so how long and how much HIP DATA packets do I need to cache. Same section, "...to avoid generating a new ACK packet to respond to a *replayed* HIP DATA packet". What is the valid reason for replay any packets and is it not that the idea in using sequence numbers should be used to fight against replay attacks, as it says on the same paragraph? A question about the fragmentation in section 5. In section 5.3. in RFC 5201 it says that HIP packets MUST NOT be fragmented, doesn't this include IP-layer fragmentation or not? Or did I just misinterpret that line. BR, Samu Varjonen _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Wed Nov 5 03:52:21 2008 Return-Path: X-Original-To: hipsec-archive@megatron.ietf.org Delivered-To: ietfarch-hipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FF3F3A699A; Wed, 5 Nov 2008 03:52:21 -0800 (PST) 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 8AB703A6998 for ; Wed, 5 Nov 2008 03:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWIcaeG4QWgD for ; Wed, 5 Nov 2008 03:52:19 -0800 (PST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 12D773A6768 for ; Wed, 5 Nov 2008 03:52:18 -0800 (PST) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 9E28C1F43DF; Wed, 5 Nov 2008 13:52:12 +0200 (EET) Received: from despair.unknown.com (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 50C081F43DC; Wed, 5 Nov 2008 13:52:12 +0200 (EET) Message-ID: <491188EC.7000302@nomadiclab.com> Date: Wed, 05 Nov 2008 13:52:12 +0200 From: Jan Mikael Melen User-Agent: Thunderbird 2.0.0.7pre (X11/20080131) MIME-Version: 1.0 To: Varjonen Samu References: <490EFFC0.6060304@ericsson.com> <491068E3.5050203@hiit.fi> In-Reply-To: <491068E3.5050203@hiit.fi> X-Virus-Scanned: ClamAV using ClamSMTP Cc: HIP Subject: Re: [Hipsec] New version of the HICCUPS draft 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Hi Samu Thanks for the comments. See inline. Varjonen Samu wrote: > Gonzalo Camarillo wrote: >> Folks, >> >> we have just submitted a new version of the HICCUPS draft: >> >> http://www.ietf.org/internet-drafts/draft-nikander-hip-hiccups-01.txt >> >> As usual, comments are welcome. >> >> Cheers, >> >> Gonzalo >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec > > Hi, > > Some comments and questions on draft-nikander-hip-hiccups-01. These > are the points where I would like to see some clarifications. > > In section 3 in the definition of the HIP DATA packet, it says that > the optional parameters are SEQ and ACK and on the next line they are > SEQ_DATA and ACK_DATA. Oops... Will fix this one. > > Same section in the reference to RFC5201 and end of section 2.1.1, a > question. Currently Next Header is set to 0x3B (59) "No Next Header", > Should there be "TBD IANA" for a new value for this field because now > there is data after the header and the definition of 59 is > "Note that there is also a "dummy" extension header called No Next > Header that has a value of 59. This is a placeholder that when found > in the Next Header field indicates that there is nothing after that > extension header." and this says there is *nothing* after the header. I'm a bit confused where are you referring at? Because we are saying in section 2 "The HIP protocol specification RFC5201 defines a number of messages and parameters. The parameters are encoded as TLVs, as shown in 2.1.2. Furthermore, the HIP header carries a Next Header field, allowing other arbitrary packets to be carried within HIP packets." and in section 2.1.1 "this document describes processing for Next Header values as they are carried on the HIP DATA packet." So we are basically saying that you would use the next header value of the HIP header in the same fashion as you would use with any other IPv6 protocol e.g. next header value 6 would be TCP. > > section 3.3 Next Header, "identifies the data that protected by > this..." to "Identifies the data that is protected by this..." > Will fix that. > Section 4.2 the generation of a HIP DATA packet. Where and how exactly > is the data gotten from the upper-layer? This is not handled in the > draft. To me this sounds like it should be handled in native API draft > for natively HIP aware applications and for legacy applications by > doing local policies like "protocols that would use UDP should use HIP > DATA instead". Now the draft just gets the data from "somewhere". > I agree that it should be somehow defined but I don't want to limit to only current type of APIs as there might be new ones and even implementation specific APIs which still could use the HIP_DATA as specified in this draft. We will have to think about that more in the future versions. > Same section point 1, the host just takes a sequence number. I think > it would be easier to just use monotonically increasing sequence > numbers as the original SEQ and its UPDATE id does. Then the book > keeping on which numbers are used is much simpler. > There is no reason to do sequence counter that starts from 1 and is incremented every time host sends a packet, because data packet may be sent even if the hosts don't have a HIP association between them and thus the receiver doesn't have any context for the peer and will only store for a short period of time the last seen SEQ value. > Same as above, more clarification on the processing window, duration, > how it is defined and so on. there is an example included that you may implement it as an wrap-around counter if you like but you don't have to. > > Same section point 4, how is RTT estimate calculated? Is there some > uniform way to do this or can implementors just decide on one. For > example TCP has some initial values and information on how to > calculate the estimates, should we have something similar? > Maybe... this is really a implementation policy. > Same section point 5, is the DATA_ENTRY_MAX totally based upon local > policy or is there some HIP default? probably you mean DATA_RETRY_MAX. Yes this again is implementation policy. > > Same section and point, about the error notification and its > counterpart, should also ACKed HIP DATA packets be ACKed to the > application. This actually could be too much but for some applications > it could be a useful socket option in Native API. I fail to see the use for this kind of function could you elaborate a bit more the case where you would like to know it? > > Section 4.3 "The host MAY responds..." to "The host MAY respond..." > Fixed that one. > Same section, "... if the packet contained SEQ_DATA and PAYLOAD_HMAC > parameter. Because PAYLOAD_HMAC is mandatory parameter in HIP DATA > packet it would be enough to say if it contained SEQ_DATA Will do some rewording. > Section 4.3.1, How long ago is this recently received, so how long and > how much HIP DATA packets do I need to cache. You do not need to cache the packets only the sequence numbers. It is like the ESP replay protection window which is a matter of local policy. > > Same section, "...to avoid generating a new ACK packet to respond to a > *replayed* HIP DATA packet". What is the valid reason for replay any > packets and is it not that the idea in using sequence numbers should > be used to fight against replay attacks, as it says on the same > paragraph? If the host replied to a HIP_DATA packet containing SEQ_DATA#h1, PAYLOAD_HMAC with a packet containing SEQ_DATA#h2, ACK_DATA#h1, PAYLOAD_HMAC it should not create a new packet containing only ACK_DATA#h1 because then you would still have a timer running for the SEQ_DATA#h2 that it has sent which would mean that you increase the number of packets sent through the network. > > A question about the fragmentation in section 5. In section 5.3. in > RFC 5201 it says that HIP packets MUST NOT be fragmented, doesn't this > include IP-layer fragmentation or not? Or did I just misinterpret that > line. Interesting section "HIP Fragmentation Support" http://tools.ietf.org/html/rfc5201#section-5.1.3 allows it and section 5.3 denies :-) Jan _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Fri Nov 7 03:34:40 2008 Return-Path: X-Original-To: hipsec-archive@megatron.ietf.org Delivered-To: ietfarch-hipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 530DD3A6B5A; Fri, 7 Nov 2008 03:34:40 -0800 (PST) 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 5C2683A6B60 for ; Fri, 7 Nov 2008 03:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 3-Dp4cBYBP0M for ; Fri, 7 Nov 2008 03:34:38 -0800 (PST) Received: from creon.otaverkko.fi (creon.otaverkko.fi [212.68.0.5]) by core3.amsl.com (Postfix) with ESMTP id 12C763A6B58 for ; Fri, 7 Nov 2008 03:34:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by creon.otaverkko.fi (Postfix) with ESMTP id 00CB521AF3F; Fri, 7 Nov 2008 13:34:23 +0200 (EET) Received: from creon.otaverkko.fi ([127.0.0.1]) by localhost (creon.otaverkko.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20183-05; Fri, 7 Nov 2008 13:34:16 +0200 (EET) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by creon.otaverkko.fi (Postfix) with ESMTP id 7A1A121AF39; Fri, 7 Nov 2008 13:34:16 +0200 (EET) Received: from [62.237.148.247] (unknown [62.237.148.247]) by argo.otaverkko.fi (Postfix) with ESMTP id 6966E25ED06; Fri, 7 Nov 2008 13:34:16 +0200 (EET) Message-ID: <491427B7.9020409@hiit.fi> Date: Fri, 07 Nov 2008 13:34:15 +0200 From: Varjonen Samu User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Jan Mikael Melen References: <490EFFC0.6060304@ericsson.com> <491068E3.5050203@hiit.fi> <491188EC.7000302@nomadiclab.com> In-Reply-To: <491188EC.7000302@nomadiclab.com> X-Virus-Scanned: amavisd-new at otaverkko.fi Cc: HIP Subject: Re: [Hipsec] New version of the HICCUPS draft 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Jan Mikael Melen wrote: > Hi Samu > >> >> Same section in the reference to RFC5201 and end of section 2.1.1, a >> question. Currently Next Header is set to 0x3B (59) "No Next Header", >> Should there be "TBD IANA" for a new value for this field because now >> there is data after the header and the definition of 59 is >> "Note that there is also a "dummy" extension header called No Next >> Header that has a value of 59. This is a placeholder that when found >> in the Next Header field indicates that there is nothing after that >> extension header." and this says there is *nothing* after the header. > > I'm a bit confused where are you referring at? Because we are saying in > section 2 "The HIP protocol specification RFC5201 defines a number of > messages and parameters. The parameters are encoded as TLVs, as shown > in 2.1.2. Furthermore, the HIP header carries a Next Header field, > allowing other arbitrary packets to be carried within HIP packets." and > in section 2.1.1 "this document describes processing for Next Header > values as they are carried on the HIP DATA packet." So we are basically > saying that you would use the next header value of the HIP header in the > same fashion as you would use with any other IPv6 protocol e.g. next > header value 6 would be TCP. > Sorry for the messed up question but you managed to get the right point out of it. This was exactly what I was needing clarification with. It was not directly obvious from the text that use IPv6 extension header next header values directly. But I would probably use 17 (UDP) with HIP DATA. >> Section 4.2 the generation of a HIP DATA packet. Where and how exactly >> is the data gotten from the upper-layer? This is not handled in the >> draft. To me this sounds like it should be handled in native API draft >> for natively HIP aware applications and for legacy applications by >> doing local policies like "protocols that would use UDP should use HIP >> DATA instead". Now the draft just gets the data from "somewhere". >> > > I agree that it should be somehow defined but I don't want to limit to > only current type of APIs as there might be new ones and even > implementation specific APIs which still could use the HIP_DATA as > specified in this draft. We will have to think about that more in the > future versions. > OK >> Same as above, more clarification on the processing window, duration, >> how it is defined and so on. > > there is an example included that you may implement it as an wrap-around > counter if you like but you don't have to. > Yeah, managed to miss almost full paragraph of text. Maybe then there should be something like "Processing window could practically be,..." or something that I cannot miss it again :D >> >> Same section and point, about the error notification and its >> counterpart, should also ACKed HIP DATA packets be ACKed to the >> application. This actually could be too much but for some applications >> it could be a useful socket option in Native API. > > I fail to see the use for this kind of function could you elaborate a > bit more the case where you would like to know it? > OK, brain missfire, it actually would more useful to suppress the NACKs after timeouts, for example in streaming apps. If you do not need ACK do not put SEQ, and if you put SEQ and need ACK then the upper-layer will also wait for some content, for example ping or sorts (ICMP message wrapped into HIP DATA with SEQ and get back the HIP DATA wrapped mirror of the timestamp in ICMP message and ACK). So it would already be obvious it succeeded. >> Section 4.3.1, How long ago is this recently received, so how long and >> how much HIP DATA packets do I need to cache. > > You do not need to cache the packets only the sequence numbers. It is > like the ESP replay protection window which is a matter of local policy. > Hiccups 4.3.1 page 11 " It is recommended that a host cache HIP DATA packets sent with ACKs to avoid the cost of generating a new ACK packet to respond to a replayed HIP DATA packet. " I think that says it is recommended to cache packets and not just the sequence number? >> >> A question about the fragmentation in section 5. In section 5.3. in >> RFC 5201 it says that HIP packets MUST NOT be fragmented, doesn't this >> include IP-layer fragmentation or not? Or did I just misinterpret that >> line. > > Interesting section "HIP Fragmentation Support" > http://tools.ietf.org/html/rfc5201#section-5.1.3 allows it and section > 5.3 denies :-) :) So, the final conclusion is that what ever RFC5201 says you can fragment HIP packets with IP-layer fragmentation. > > Jan > BR, Samu _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Wed Nov 12 06:56:31 2008 Return-Path: X-Original-To: hipsec-archive@megatron.ietf.org Delivered-To: ietfarch-hipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C64083A6A9F; Wed, 12 Nov 2008 06:56:31 -0800 (PST) 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 55D623A6A9F for ; Wed, 12 Nov 2008 06:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 iYWKfFN22hHQ for ; Wed, 12 Nov 2008 06:56:30 -0800 (PST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 0390C3A68A9 for ; Wed, 12 Nov 2008 06:56:30 -0800 (PST) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 1DB0C1EF12C; Wed, 12 Nov 2008 16:56:23 +0200 (EET) Received: from despair.unknown.com (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id DB4271EF12B; Wed, 12 Nov 2008 16:56:22 +0200 (EET) Message-ID: <491AEE96.7070003@nomadiclab.com> Date: Wed, 12 Nov 2008 16:56:22 +0200 From: Jan Mikael Melen User-Agent: Thunderbird 2.0.0.7pre (X11/20080131) MIME-Version: 1.0 To: orlie.t.brewer@boeing.com References: <1225155863.13213.3.camel@crescent.rt.cs.boeing.com> In-Reply-To: <1225155863.13213.3.camel@crescent.rt.cs.boeing.com> X-Virus-Scanned: ClamAV using ClamSMTP Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] HIP Mobile Router draft 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Hi, Orlie Brewer wrote: > We have been implementing portions of the HIP mobile router draft to > OpenHIP: > > <> > > Below are a few questions and comments about our effort. > > In section 5.1 of the draft, the "mobile router adds its self-signed > locator set information to the I1 message" and "its signed LOCATOR TLV > and ESP_INFO TLV to the I2 message." This only seems useful if the peer > node has the host identity public key of the mobile router to verify the > signature, but there is no mention of the mobile router passing that > information to the peer node or establishing a HIP connection with the > peer node. Yes the mobile router could add its own HI in to the I2 message as well or the the HI might be fetched from some directory service such DHT in which case the MR should add its HIT. > Also, these would have to be added after the portion of the > message signed by the mobile node. We have defined a ESP_INFO_UNSIGNED > parameter to place the SPINAT info after the portion of the message > signed by the mobile node in the I2 message. > Yes, this was the plan that we introduce new parameters which are added after the signature. > Also, in that section, "the mobile router adds an encrypted 'echo > request' parameter to the I1 message." We are assuming that it is an > ECHO_REQUEST_UNSIGNED parameter that would be placed after the portion > of the message signed by the mobile node. > Yes. > Another question with signatures is with the UPDATE packet. The HIP > RFC5201, section 5.3.5, say that an HMAC parameter and a HIP_SIGNATURE > parameter are mandatory. Again, is this suppose to be the mobile > router's signature? The draft does not mention signatures in relation > to the UPDATE packet. > If the MR is sending the packet then it is supposed to be the MR signature and when the MR is generating the UPDATE there wont be any HMAC as the MR doesn't have common keying material with the peer. > A general comment is that the draft seems to consider two cases, a > mobile node with existing SAs moving behind a mobile router and a mobile > node already behind a mobile router establishing an SA through a mobile > router. However, it is a little confusing which case is being discussed > at times as the draft seems to jump between the two cases. It would be > clearer if it were explicitly stated when the different cases were begin > discussed. > Yes it is considering two cases and I think your suggestion sounds good that there would be a statement in each section that to which case this applies to. Regards, Jan _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Fri Nov 14 15:08:00 2008 Return-Path: X-Original-To: hipsec-archive@megatron.ietf.org Delivered-To: ietfarch-hipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D87CD3A68BD; Fri, 14 Nov 2008 15:08:00 -0800 (PST) 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 D6D4C3A68BD for ; Fri, 14 Nov 2008 15:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CEEC77yB6oZM for ; Fri, 14 Nov 2008 15:07:59 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id F344E3A67F7 for ; Fri, 14 Nov 2008 15:07:58 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,606,1220227200"; d="scan'208";a="195108925" Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-6.cisco.com with ESMTP; 14 Nov 2008 23:07:59 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id mAEN7xBG029606 for ; Fri, 14 Nov 2008 15:07:59 -0800 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id mAEN7w6x024380 for ; Fri, 14 Nov 2008 23:07:58 GMT Message-Id: From: Cullen Jennings To: HIP Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 14 Nov 2008 16:07:49 -0700 X-Mailer: Apple Mail (2.929.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=252; t=1226704079; x=1227568079; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Comments=20on=20draft-cao-hip-geolocation |Sender:=20; bh=lJgzIfIjTMBlbbdnBGUKQm3Chz6enu98LS1t107E4Vs=; b=c0zMTLwiL5SG5Cy2TC9U6v9VZdhnFYehp+Pzsg0FADiKxvEoAol/Le86sZ VAT1LSleuss5WDk0cefKMHBntfWZuS0+gWf1j9vtID3iefx2dalFzttzP9/A O4XsiOgE/Z; Authentication-Results: sj-dkim-7; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); Subject: [Hipsec] Comments on draft-cao-hip-geolocation 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Due to the requirements of managing the privacy of geo and civil location information, I think this type of information is much better transfered at an application layer than at the transport layer. Cullen in my individual contributor role _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Mon Nov 17 17:24:35 2008 Return-Path: X-Original-To: hipsec-archive@megatron.ietf.org Delivered-To: ietfarch-hipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5551D28C0E6; Mon, 17 Nov 2008 17:24:35 -0800 (PST) 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 9867C28C0E6 for ; Mon, 17 Nov 2008 17:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCODrS9I+Bbr for ; Mon, 17 Nov 2008 17:24:32 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 4B4D83A6922 for ; Mon, 17 Nov 2008 17:24:32 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so1072439eyd.31 for ; Mon, 17 Nov 2008 17:24:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=0cPsgvUolIWGwCwG2UCXpQ4S6ohpmSRPyE+9zMAMYqk=; b=iKyw8JLUziPOmmEjAUOXH5xfU52kqTfwxU6cz3Bfnm2FE+htFLfEicb5G5feME0ita KJg5F1eEwRiSC/AmUqTSDK8nTOgEwEmNRVTbzdtFP8SDz6OmeO466F2d9LFi2WAa17aE FvlXUdL2mRH35E9BzHcmz7G+8NDQM8oeBZeaM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=LbNXzSimJEH5zEQNv+oD6S4VgxwXnoN+9hkXKiDWdJPSR0jG7DfZ72aWKEhh8uEO5P cqi6EfzRm5dVEVpyQgvY/SRx3VsImcHwBL0GFM+HpDkSG60HrW/z+hR/Kj7t6U/TMHif r0eoS4GjlXwI4RzTFXsLkEXynqPx5V4ALi5Fw= Received: by 10.210.57.12 with SMTP id f12mr4448174eba.199.1226971470197; Mon, 17 Nov 2008 17:24:30 -0800 (PST) Received: by 10.210.109.14 with HTTP; Mon, 17 Nov 2008 17:24:30 -0800 (PST) Message-ID: <1d38a3350811171724m6a7f2f84la1b47dcf2ac5b5c5@mail.gmail.com> Date: Tue, 18 Nov 2008 09:24:30 +0800 From: "Hui Deng" To: "Cullen Jennings" , "Hui Deng" In-Reply-To: MIME-Version: 1.0 References: Cc: HIP Subject: Re: [Hipsec] Comments on draft-cao-hip-geolocation 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: , Content-Type: multipart/mixed; boundary="===============1877681511==" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org --===============1877681511== Content-Type: multipart/alternative; boundary="----=_Part_45357_23296530.1226971470196" ------=_Part_45357_23296530.1226971470196 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Cullen, Thanks for your comments, It could be understand from another direction, if the mobile users use HIP. Here are some reasons listed below. -- HIP has the security mechanisms (i.e. ENCRYPTED) -- GEOPRIV security framework can be integrated into HIP call flow -- the geo-location changes of mobile user may not be cared or covered by many applications. -- delivering geo-location in HIP can provide the generic mechanism and interface for the up-layer applications; -- delivering geo-location in HIP can greatly reduce the redundant work for up-layer applications. Basically, operator sometime prefer use infrastructure layer to transmit this information. thanks for your understanding. Best regards, -Hui Deng 2008/11/15 Cullen Jennings > > Due to the requirements of managing the privacy of geo and civil location > information, I think this type of information is much better transfered at > an application layer than at the transport layer. > > Cullen in my individual contributor role > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > ------=_Part_45357_23296530.1226971470196 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi, Cullen,
 
Thanks for your comments,
 
It could be understand from another direction, if the mobile users use HIP. Here are some reasons listed below. 
 
-- HIP has the  security mechanisms (i.e. ENCRYPTED)
-- GEOPRIV security framework can be integrated into HIP call flow
-- the geo-location changes of mobile user may not be cared or covered by many applications.
-- delivering geo-location in HIP can provide the generic mechanism and interface for the up-layer applications;
-- delivering geo-location in HIP can greatly reduce the redundant work for up-layer applications.
Basically, operator sometime prefer use infrastructure layer to transmit this information.
 
thanks for your understanding.
Best regards,
 
-Hui Deng
2008/11/15 Cullen Jennings <fluffy@cisco.com>

Due to the requirements of managing the privacy of geo and civil location information, I think this type of information is much better transfered at an application layer than at the transport layer.

Cullen in my individual contributor role

_______________________________________________
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

------=_Part_45357_23296530.1226971470196-- --===============1877681511== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec --===============1877681511==-- From hipsec-bounces@ietf.org Mon Nov 17 17:30:18 2008 Return-Path: X-Original-To: hipsec-archive@megatron.ietf.org Delivered-To: ietfarch-hipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9FCB28C1DA; Mon, 17 Nov 2008 17:30:18 -0800 (PST) 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 604EE28C1D7 for ; Mon, 17 Nov 2008 17:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.167 X-Spam-Level: X-Spam-Status: No, score=-1.167 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2ZQO9SwZmeP for ; Mon, 17 Nov 2008 17:30:16 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 35FDA28C1A0 for ; Mon, 17 Nov 2008 17:30:16 -0800 (PST) Received: (qmail invoked by alias); 18 Nov 2008 01:30:14 -0000 Received: from unknown (EHLO 4FIL42860) [130.129.31.217] by mail.gmx.net (mp049) with SMTP; 18 Nov 2008 02:30:14 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/Aso8gPefAapiHBdVYi+/scQH/NF6VTReGLq7GdX UzgCR2OG0VVjuA From: "Hannes Tschofenig" To: "'Hui Deng'" , "'Cullen Jennings'" , "'Hui Deng'" References: <1d38a3350811171724m6a7f2f84la1b47dcf2ac5b5c5@mail.gmail.com> Date: Mon, 17 Nov 2008 19:30:12 +0200 Message-ID: <016c01c948da$279c60c0$6612a20a@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1d38a3350811171724m6a7f2f84la1b47dcf2ac5b5c5@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AclJHGsCm8X0lq+BROyes8RGMWTIPgAQmSWg X-Y-GMX-Trusted: 0 X-FuHaFi: 0.85 Cc: 'HIP' Subject: Re: [Hipsec] Comments on draft-cao-hip-geolocation 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org I believe that conveying location in HIP is a misguided approach. Wrong layer! ________________________________ From: hipsec-bounces@ietf.org [mailto:hipsec-bounces@ietf.org] On Behalf Of Hui Deng Sent: 18 November, 2008 03:25 To: Cullen Jennings; Hui Deng Cc: HIP Subject: Re: [Hipsec] Comments on draft-cao-hip-geolocation Hi, Cullen, Thanks for your comments, It could be understand from another direction, if the mobile users use HIP. Here are some reasons listed below. -- HIP has the security mechanisms (i.e. ENCRYPTED) -- GEOPRIV security framework can be integrated into HIP call flow -- the geo-location changes of mobile user may not be cared or covered by many applications. -- delivering geo-location in HIP can provide the generic mechanism and interface for the up-layer applications; -- delivering geo-location in HIP can greatly reduce the redundant work for up-layer applications. Basically, operator sometime prefer use infrastructure layer to transmit this information. thanks for your understanding. Best regards, -Hui Deng 2008/11/15 Cullen Jennings Due to the requirements of managing the privacy of geo and civil location information, I think this type of information is much better transfered at an application layer than at the transport layer. Cullen in my individual contributor role _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Mon Nov 17 19:37:15 2008 Return-Path: X-Original-To: hipsec-archive@megatron.ietf.org Delivered-To: ietfarch-hipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA4643A6828; Mon, 17 Nov 2008 19:37:15 -0800 (PST) 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 4982E3A6828 for ; Mon, 17 Nov 2008 19:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDFGP6huGoMz for ; Mon, 17 Nov 2008 19:37:13 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id EC5C53A67E1 for ; Mon, 17 Nov 2008 19:37:12 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so1083683eyd.31 for ; Mon, 17 Nov 2008 19:37:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=YDwUuLmU1U1JO1DOZfK+Z8CUKrfVtf8vOWX9ZIu2qQ4=; b=Tokgztki+izwk8Pop/2+uycrHJV64M3wvQAECXV+lZhm+kGUbee+kHa0ydntf6uY1I tP5pN2vyDPF6j98Cm+PCQrZtToPqSS2AeDQGCw1RG5ZAjJigx1beoIgnFZl6OBUVOjP3 o4RQBPZRkLkKLNYR9JYRGqr0d+WabxB7qNNfE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=fXinnKeooxt/OfMhAwlIOPjX1k+2+qvdrJNc9Li69vKQ7G0EfhGDmpl8YAEt0jWHpW B5HYMSTM7L+rUWdpFQxup7gujvcjsUK3tSLWUirC5k9g++wi1tDxhNVm2pl5DC8es99G J0TRMMyNio+VZbq6uNz8EaGPp1KV+4Om6r9zg= Received: by 10.210.30.1 with SMTP id d1mr4587006ebd.2.1226979430362; Mon, 17 Nov 2008 19:37:10 -0800 (PST) Received: by 10.210.109.14 with HTTP; Mon, 17 Nov 2008 19:37:10 -0800 (PST) Message-ID: <1d38a3350811171937l5774a3adlb3f8d3ce2e3af82@mail.gmail.com> Date: Tue, 18 Nov 2008 11:37:10 +0800 From: "Hui Deng" To: "Hannes Tschofenig" In-Reply-To: <016c01c948da$279c60c0$6612a20a@nsnintra.net> MIME-Version: 1.0 References: <1d38a3350811171724m6a7f2f84la1b47dcf2ac5b5c5@mail.gmail.com> <016c01c948da$279c60c0$6612a20a@nsnintra.net> Cc: HIP , Hui Deng Subject: Re: [Hipsec] Comments on draft-cao-hip-geolocation 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: , Content-Type: multipart/mixed; boundary="===============1413367792==" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org --===============1413367792== Content-Type: multipart/alternative; boundary="----=_Part_46806_12232669.1226979430378" ------=_Part_46806_12232669.1226979430378 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Hannes, Please help to explain any issue with that, other than like this. Thanks -Hui 2008/11/18 Hannes Tschofenig > I believe that conveying location in HIP is a misguided approach. > Wrong layer! > > > > ________________________________ > > From: hipsec-bounces@ietf.org [mailto:hipsec-bounces@ietf.org] On > Behalf Of Hui Deng > Sent: 18 November, 2008 03:25 > To: Cullen Jennings; Hui Deng > Cc: HIP > Subject: Re: [Hipsec] Comments on draft-cao-hip-geolocation > > > Hi, Cullen, > > Thanks for your comments, > > It could be understand from another direction, if the mobile users > use HIP. Here are some reasons listed below. > > -- HIP has the security mechanisms (i.e. ENCRYPTED) > -- GEOPRIV security framework can be integrated into HIP call flow > -- the geo-location changes of mobile user may not be cared or > covered by many applications. > -- delivering geo-location in HIP can provide the generic mechanism > and interface for the up-layer applications; > -- delivering geo-location in HIP can greatly reduce the redundant > work for up-layer applications. > > Basically, operator sometime prefer use infrastructure layer to > transmit this information. > > thanks for your understanding. > Best regards, > > -Hui Deng > > 2008/11/15 Cullen Jennings > > > > Due to the requirements of managing the privacy of geo and > civil location information, I think this type of information is much better > transfered at an application layer than at the transport layer. > > Cullen in my individual contributor role > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > > > > > ------=_Part_46806_12232669.1226979430378 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi, Hannes,
 
Please help to explain any issue with that, other than like this.
 
Thanks
 
-Hui

2008/11/18 Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
I believe that conveying location in HIP is a misguided approach.
Wrong layer!



________________________________

       From: hipsec-bounces@ietf.org [mailto:hipsec-bounces@ietf.org] On
Behalf Of Hui Deng
       Sent: 18 November, 2008 03:25
       To: Cullen Jennings; Hui Deng
       Cc: HIP
       Subject: Re: [Hipsec] Comments on draft-cao-hip-geolocation


       Hi, Cullen,

       Thanks for your comments,

       It could be understand from another direction, if the mobile users
use HIP. Here are some reasons listed below.

       -- HIP has the  security mechanisms (i.e. ENCRYPTED)
       -- GEOPRIV security framework can be integrated into HIP call flow
       -- the geo-location changes of mobile user may not be cared or
covered by many applications.
       -- delivering geo-location in HIP can provide the generic mechanism
and interface for the up-layer applications;
       -- delivering geo-location in HIP can greatly reduce the redundant
work for up-layer applications.

       Basically, operator sometime prefer use infrastructure layer to
transmit this information.

       thanks for your understanding.
       Best regards,

       -Hui Deng

       2008/11/15 Cullen Jennings <fluffy@cisco.com>



               Due to the requirements of managing the privacy of geo and
civil location information, I think this type of information is much better
transfered at an application layer than at the transport layer.

               Cullen in my individual contributor role

               _______________________________________________
               Hipsec mailing list
               Hipsec@ietf.org
               https://www.ietf.org/mailman/listinfo/hipsec





------=_Part_46806_12232669.1226979430378-- --===============1413367792== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec --===============1413367792==-- From hipsec-bounces@ietf.org Tue Nov 25 07:27:43 2008 Return-Path: X-Original-To: hipsec-archive@megatron.ietf.org Delivered-To: ietfarch-hipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 615133A6A78; Tue, 25 Nov 2008 07:27:43 -0800 (PST) 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 D55703A6961 for ; Tue, 25 Nov 2008 07:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxHyf1p+KyEp for ; Tue, 25 Nov 2008 07:27:41 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [208.83.67.147]) by core3.amsl.com (Postfix) with ESMTP id F2E8C3A6A07 for ; Tue, 25 Nov 2008 07:27:40 -0800 (PST) Received: from z9m9z.htt-consult.com (localhost.localdomain [127.0.0.1]) by z9m9z.htt-consult.com (8.13.8/8.13.8) with ESMTP id mAPFQPEp000488 for ; Tue, 25 Nov 2008 10:26:25 -0500 Received: from nc2400.htt-consult.com (onlo.htt-consult.com [208.83.67.148]) by z9m9z.htt-consult.com (Scalix SMTP Relay 11.3.0.11339) via ESMTP; Tue, 25 Nov 2008 10:25:40 -0500 (EST) Date: Tue, 25 Nov 2008 10:25:59 -0500 From: Robert Moskowitz To: HIP Message-ID: <492C1907.1040908@htt-consult.com> x-scalix-Hops: 1 User-Agent: Thunderbird 2.0.0.18 (X11/20081120) MIME-Version: 1.0 Content-Disposition: inline Subject: [Hipsec] BEET discussions 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Has BEET mode been discussed outside of the HIP list? In my work last week to get HIP moving to Standards track, it became clear that BEET ESP will be a part of this and it will need to be reviewed by IPsec-centric people. Tim Polk already had Sheila Frankel looking at it, and Paul Hoffman acknowledged that he would also have to review it. One thing that became evident is that the why of BEET mode is needed to be clearly stated. For example I am missing the explaination that in BEET mode, the SA survives changes to the outer IP addresses. Also the semantics are related to tunnel mode with a nod to tranport mode. I am still trying to get a feel for the ID. It still feels like the placement of BEET mode with respect to the other modes is defused over the document and not well delineated in the beginning. Not only what BEET adds, but what problems occur when you try to do BEET semantics with tunnel or transport instead. I do want to say that I applaud the efforts that went into creating BEET mode, developing the current draft, and getting it into the 2.6.27 kernel (of course I want it in the 2.6.18 kernel as well without patching....). _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Tue Nov 25 07:48:17 2008 Return-Path: X-Original-To: hipsec-archive@megatron.ietf.org Delivered-To: ietfarch-hipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 178683A6BFC; Tue, 25 Nov 2008 07:48:17 -0800 (PST) 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 1990D3A6BFC for ; Tue, 25 Nov 2008 07:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bq8PePZDVCcg for ; Tue, 25 Nov 2008 07:48:15 -0800 (PST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 046DA3A6BFB for ; Tue, 25 Nov 2008 07:48:15 -0800 (PST) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id C24D11EF8B6; Tue, 25 Nov 2008 17:48:11 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 4FAF31EF8B5; Tue, 25 Nov 2008 17:48:11 +0200 (EET) Message-Id: <2F7887B7-4121-4DD0-B7DC-6E595DA486EE@nomadiclab.com> From: Pekka Nikander To: Robert Moskowitz In-Reply-To: <492C1907.1040908@htt-consult.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 25 Nov 2008 17:48:11 +0200 References: <492C1907.1040908@htt-consult.com> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV using ClamSMTP Cc: HIP Subject: Re: [Hipsec] BEET discussions 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org BEET mode was discussed in its early dais, and was basically rejected by the IPsec folks (mainly Steve K) then, mainly due to not being any "need" for it, or just not wanting even to consider a new mode to IPsec. Then some people claimed that it would be better to simply used inner header compression instead. --Pekka On 25 Nov 2008, at 17:25, Robert Moskowitz wrote: > Has BEET mode been discussed outside of the HIP list? > > In my work last week to get HIP moving to Standards track, it became > clear that BEET ESP will be a part of this and it will need to be > reviewed by IPsec-centric people. Tim Polk already had Sheila > Frankel looking at it, and Paul Hoffman acknowledged that he would > also have to review it. > > One thing that became evident is that the why of BEET mode is needed > to be clearly stated. For example I am missing the explaination > that in BEET mode, the SA survives changes to the outer IP addresses. > > Also the semantics are related to tunnel mode with a nod to tranport > mode. > > I am still trying to get a feel for the ID. It still feels like the > placement of BEET mode with respect to the other modes is defused > over the document and not well delineated in the beginning. Not > only what BEET adds, but what problems occur when you try to do BEET > semantics with tunnel or transport instead. > > I do want to say that I applaud the efforts that went into creating > BEET mode, developing the current draft, and getting it into the > 2.6.27 kernel (of course I want it in the 2.6.18 kernel as well > without patching....). > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Tue Nov 25 07:54:19 2008 Return-Path: X-Original-To: hipsec-archive@megatron.ietf.org Delivered-To: ietfarch-hipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D8F53A6BFD; Tue, 25 Nov 2008 07:54:19 -0800 (PST) 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 EDCB53A6BFD for ; Tue, 25 Nov 2008 07:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PwusMzEYjgr for ; Tue, 25 Nov 2008 07:54:17 -0800 (PST) Received: from creon.otaverkko.fi (creon.otaverkko.fi [212.68.0.5]) by core3.amsl.com (Postfix) with ESMTP id CD8943A6B8F for ; Tue, 25 Nov 2008 07:54:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by creon.otaverkko.fi (Postfix) with ESMTP id 1BE0221AF48; Tue, 25 Nov 2008 17:54:13 +0200 (EET) Received: from creon.otaverkko.fi ([127.0.0.1]) by localhost (creon.otaverkko.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03817-03; Tue, 25 Nov 2008 17:54:07 +0200 (EET) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by creon.otaverkko.fi (Postfix) with ESMTP id C033721AF35; Tue, 25 Nov 2008 17:54:07 +0200 (EET) Received: from [193.167.187.26] (halko.pc.infrahip.net [193.167.187.26]) by argo.otaverkko.fi (Postfix) with ESMTP id B758725ED06; Tue, 25 Nov 2008 17:54:07 +0200 (EET) Message-ID: <492C1F9F.2040303@hiit.fi> Date: Tue, 25 Nov 2008 17:54:07 +0200 From: Miika Komu User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Pekka Nikander References: <492C1907.1040908@htt-consult.com> <2F7887B7-4121-4DD0-B7DC-6E595DA486EE@nomadiclab.com> In-Reply-To: <2F7887B7-4121-4DD0-B7DC-6E595DA486EE@nomadiclab.com> X-Virus-Scanned: amavisd-new at otaverkko.fi Cc: HIP Subject: Re: [Hipsec] BEET discussions X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: miika@iki.fi List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Pekka Nikander wrote: Hi, times have also changed since then and there are three interoperable BEET implementations now (in linux 2.6.27 kernel, in BSD and the userspace BEET). Could you or Jan resubmit the draft to the IETF archives? > BEET mode was discussed in its early dais, and was basically rejected by > the IPsec folks (mainly Steve K) then, mainly due to not being any > "need" for it, or just not wanting even to consider a new mode to > IPsec. Then some people claimed that it would be better to simply used > inner header compression instead. > > --Pekka > > On 25 Nov 2008, at 17:25, Robert Moskowitz wrote: > >> Has BEET mode been discussed outside of the HIP list? >> >> In my work last week to get HIP moving to Standards track, it became >> clear that BEET ESP will be a part of this and it will need to be >> reviewed by IPsec-centric people. Tim Polk already had Sheila Frankel >> looking at it, and Paul Hoffman acknowledged that he would also have >> to review it. >> >> One thing that became evident is that the why of BEET mode is needed >> to be clearly stated. For example I am missing the explaination that >> in BEET mode, the SA survives changes to the outer IP addresses. >> >> Also the semantics are related to tunnel mode with a nod to tranport >> mode. >> >> I am still trying to get a feel for the ID. It still feels like the >> placement of BEET mode with respect to the other modes is defused over >> the document and not well delineated in the beginning. Not only what >> BEET adds, but what problems occur when you try to do BEET semantics >> with tunnel or transport instead. >> >> I do want to say that I applaud the efforts that went into creating >> BEET mode, developing the current draft, and getting it into the >> 2.6.27 kernel (of course I want it in the 2.6.18 kernel as well >> without patching....). >> >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec >> > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Tue Nov 25 14:06:24 2008 Return-Path: X-Original-To: hipsec-archive@megatron.ietf.org Delivered-To: ietfarch-hipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F1B528C1BE; Tue, 25 Nov 2008 14:06:24 -0800 (PST) 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 7B6B528C1BC for ; Tue, 25 Nov 2008 14:06:23 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Header field occurs more than once: "References" occurs 3 times X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-eIIgyb2Rb7 for ; Tue, 25 Nov 2008 14:06:22 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [208.83.67.147]) by core3.amsl.com (Postfix) with ESMTP id 7FB2528C1AF for ; Tue, 25 Nov 2008 14:06:22 -0800 (PST) Received: from z9m9z.htt-consult.com (localhost.localdomain [127.0.0.1]) by z9m9z.htt-consult.com (8.13.8/8.13.8) with ESMTP id mAPM5m8v022383 for ; Tue, 25 Nov 2008 17:05:48 -0500 Received: from nc2400.htt-consult.com (onlo.htt-consult.com [208.83.67.148]) by z9m9z.htt-consult.com (Scalix SMTP Relay 11.3.0.11339) via ESMTP; Tue, 25 Nov 2008 17:05:41 -0500 (EST) Date: Tue, 25 Nov 2008 17:06:01 -0500 From: Robert Moskowitz To: hipsec@ietf.org Message-ID: <492C76C9.5040304@htt-consult.com> In-Reply-To: <492C1F9F.2040303@hiit.fi> References: <492C1907.1040908@htt-consult.com> References: <2F7887B7-4121-4DD0-B7DC-6E595DA486EE@nomadiclab.com> References: <492C1F9F.2040303@hiit.fi> x-scalix-Hops: 1 User-Agent: Thunderbird 2.0.0.18 (X11/20081120) MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [Hipsec] BEET discussions 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Miika Komu wrote: > Pekka Nikander wrote: > > Hi, > > times have also changed since then and there are three interoperable > BEET implementations now (in linux 2.6.27 kernel, in BSD and the > userspace BEET). Could you or Jan resubmit the draft to the IETF > archives? Draft 9 is already out there. They did this for me back after I visited Helsinki. > >> BEET mode was discussed in its early dais, and was basically rejected >> by the IPsec folks (mainly Steve K) then, mainly due to not being any >> "need" for it, or just not wanting even to consider a new mode to >> IPsec. Then some people claimed that it would be better to simply >> used inner header compression instead. >> >> --Pekka >> >> On 25 Nov 2008, at 17:25, Robert Moskowitz wrote: >> >>> Has BEET mode been discussed outside of the HIP list? >>> >>> In my work last week to get HIP moving to Standards track, it became >>> clear that BEET ESP will be a part of this and it will need to be >>> reviewed by IPsec-centric people. Tim Polk already had Sheila >>> Frankel looking at it, and Paul Hoffman acknowledged that he would >>> also have to review it. >>> >>> One thing that became evident is that the why of BEET mode is needed >>> to be clearly stated. For example I am missing the explaination that >>> in BEET mode, the SA survives changes to the outer IP addresses. >>> >>> Also the semantics are related to tunnel mode with a nod to tranport >>> mode. >>> >>> I am still trying to get a feel for the ID. It still feels like the >>> placement of BEET mode with respect to the other modes is defused >>> over the document and not well delineated in the beginning. Not only >>> what BEET adds, but what problems occur when you try to do BEET >>> semantics with tunnel or transport instead. >>> >>> I do want to say that I applaud the efforts that went into creating >>> BEET mode, developing the current draft, and getting it into the >>> 2.6.27 kernel (of course I want it in the 2.6.18 kernel as well >>> without patching....). >>> >>> >>> _______________________________________________ >>> Hipsec mailing list >>> Hipsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/hipsec >>> >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec > > _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Tue Nov 25 14:08:14 2008 Return-Path: X-Original-To: hipsec-archive@megatron.ietf.org Delivered-To: ietfarch-hipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E3D228C1C5; Tue, 25 Nov 2008 14:08:14 -0800 (PST) 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 51C8D28C1C5 for ; Tue, 25 Nov 2008 14:08:13 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "References" X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEKIphd8-CpZ for ; Tue, 25 Nov 2008 14:08:12 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [208.83.67.147]) by core3.amsl.com (Postfix) with ESMTP id 3AC1028C1C4 for ; Tue, 25 Nov 2008 14:08:12 -0800 (PST) Received: from z9m9z.htt-consult.com (localhost.localdomain [127.0.0.1]) by z9m9z.htt-consult.com (8.13.8/8.13.8) with ESMTP id mAPM6qE8022498 for ; Tue, 25 Nov 2008 17:06:52 -0500 Received: from nc2400.htt-consult.com (onlo.htt-consult.com [208.83.67.148]) by z9m9z.htt-consult.com (Scalix SMTP Relay 11.3.0.11339) via ESMTP; Tue, 25 Nov 2008 17:06:01 -0500 (EST) Date: Tue, 25 Nov 2008 17:06:20 -0500 From: Robert Moskowitz To: hipsec@ietf.org Message-ID: <492C76DC.6060806@htt-consult.com> In-Reply-To: <2F7887B7-4121-4DD0-B7DC-6E595DA486EE@nomadiclab.com> References: <492C1907.1040908@htt-consult.com> References: <2F7887B7-4121-4DD0-B7DC-6E595DA486EE@nomadiclab.com> x-scalix-Hops: 1 User-Agent: Thunderbird 2.0.0.18 (X11/20081120) MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [Hipsec] BEET discussions 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Pekka Nikander wrote: > BEET mode was discussed in its early dais, and was basically rejected > by the IPsec folks (mainly Steve K) then, mainly due to not being any > "need" for it, or just not wanting even to consider a new mode to > IPsec. Then some people claimed that it would be better to simply used > inner header compression instead. So then it is valuable to capture in the draft a comparison of BEET to Tunnel with header compression? The 'need' can be clearer. I am almost thinking of a WHY? section after the introduction. It would restate things covered elsewhere, but it would draw a reader in and present the case for BEET compared to transport and wrapping the SA with internal address semantics or tunnel with internal header compression, and both with zeroing out the outer addresses to gain outer address independence. (I suspect there is more, but to me these seem to be the 'high' points). > > --Pekka > > On 25 Nov 2008, at 17:25, Robert Moskowitz wrote: > >> Has BEET mode been discussed outside of the HIP list? >> >> In my work last week to get HIP moving to Standards track, it became >> clear that BEET ESP will be a part of this and it will need to be >> reviewed by IPsec-centric people. Tim Polk already had Sheila Frankel >> looking at it, and Paul Hoffman acknowledged that he would also have >> to review it. >> >> One thing that became evident is that the why of BEET mode is needed >> to be clearly stated. For example I am missing the explaination that >> in BEET mode, the SA survives changes to the outer IP addresses. >> >> Also the semantics are related to tunnel mode with a nod to tranport >> mode. >> >> I am still trying to get a feel for the ID. It still feels like the >> placement of BEET mode with respect to the other modes is defused >> over the document and not well delineated in the beginning. Not only >> what BEET adds, but what problems occur when you try to do BEET >> semantics with tunnel or transport instead. >> >> I do want to say that I applaud the efforts that went into creating >> BEET mode, developing the current draft, and getting it into the >> 2.6.27 kernel (of course I want it in the 2.6.18 kernel as well >> without patching....). >> >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec >> > > _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Wed Nov 26 04:49:54 2008 Return-Path: X-Original-To: hipsec-archive@megatron.ietf.org Delivered-To: ietfarch-hipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9081328C16F; Wed, 26 Nov 2008 04:49:54 -0800 (PST) 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 3180F28C16F for ; Wed, 26 Nov 2008 04:49:53 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "References" X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCzqZsrtBBZI for ; Wed, 26 Nov 2008 04:49:52 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [208.83.67.147]) by core3.amsl.com (Postfix) with ESMTP id E9D163A6817 for ; Wed, 26 Nov 2008 04:49:49 -0800 (PST) Received: from z9m9z.htt-consult.com (localhost.localdomain [127.0.0.1]) by z9m9z.htt-consult.com (8.13.8/8.13.8) with ESMTP id mAQCmw6F029623 for ; Wed, 26 Nov 2008 07:49:06 -0500 Received: from nc2400.htt-consult.com (onlo.htt-consult.com [208.83.67.148]) by z9m9z.htt-consult.com (Scalix SMTP Relay 11.3.0.11339) via ESMTP; Wed, 26 Nov 2008 07:48:55 -0500 (EST) Date: Wed, 26 Nov 2008 07:49:15 -0500 From: Robert Moskowitz To: hipsec@ietf.org Message-ID: <492D45CB.9080308@htt-consult.com> In-Reply-To: <492C76DC.6060806@htt-consult.com> References: <492C1907.1040908@htt-consult.com> References: <492C76DC.6060806@htt-consult.com> x-scalix-Hops: 1 User-Agent: Thunderbird 2.0.0.18 (X11/20081120) MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [Hipsec] BEET discussions 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Robert Moskowitz wrote: > Pekka Nikander wrote: >> BEET mode was discussed in its early dais, and was basically rejected >> by the IPsec folks (mainly Steve K) then, mainly due to not being any >> "need" for it, or just not wanting even to consider a new mode to >> IPsec. Then some people claimed that it would be better to simply >> used inner header compression instead. > I have gotten a few emails asking for where the current draft is: http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-09.txt > So then it is valuable to capture in the draft a comparison of BEET to > Tunnel with header compression? > > The 'need' can be clearer. I am almost thinking of a WHY? section after > the introduction. It would restate things covered elsewhere, but it > would draw a reader in and present the case for BEET compared to > transport and wrapping the SA with internal address semantics or tunnel > with internal header compression, and both with zeroing out the outer > addresses to gain outer address independence. (I suspect there is more, > but to me these seem to be the 'high' points). > >> >> --Pekka >> >> On 25 Nov 2008, at 17:25, Robert Moskowitz wrote: >> >>> Has BEET mode been discussed outside of the HIP list? >>> >>> In my work last week to get HIP moving to Standards track, it became >>> clear that BEET ESP will be a part of this and it will need to be >>> reviewed by IPsec-centric people. Tim Polk already had Sheila >>> Frankel looking at it, and Paul Hoffman acknowledged that he would >>> also have to review it. >>> >>> One thing that became evident is that the why of BEET mode is needed >>> to be clearly stated. For example I am missing the explaination that >>> in BEET mode, the SA survives changes to the outer IP addresses. >>> >>> Also the semantics are related to tunnel mode with a nod to tranport >>> mode. >>> >>> I am still trying to get a feel for the ID. It still feels like the >>> placement of BEET mode with respect to the other modes is defused >>> over the document and not well delineated in the beginning. Not only >>> what BEET adds, but what problems occur when you try to do BEET >>> semantics with tunnel or transport instead. >>> >>> I do want to say that I applaud the efforts that went into creating >>> BEET mode, developing the current draft, and getting it into the >>> 2.6.27 kernel (of course I want it in the 2.6.18 kernel as well >>> without patching....). >>> >>> >>> _______________________________________________ >>> Hipsec mailing list >>> Hipsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/hipsec >>> >> >> > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec