From hipsec-bounces@lists.ietf.org Thu Feb 01 15:51:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCiu9-00074L-Bh; Thu, 01 Feb 2007 15:51:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCitb-0005Ok-FM; Thu, 01 Feb 2007 15:51:04 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HCitb-0005g7-26; Thu, 01 Feb 2007 15:51:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 00C6E2AD08; Thu, 1 Feb 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HCisc-000866-Ny; Thu, 01 Feb 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 01 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: hipsec@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-base-07.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org --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-base-07.txt Pages : 104 Date : 2007-2-1 This memo 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 name space for mutual peer authentication. The protocol is designed to be resistant to Denial-of-Service (DoS) and Man-in-the- middle (MitM) attacks, and when used together with another suitable security protocol, such as Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper layer protocols, suchs as TCP and UDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-base-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-base-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-base-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-1121637.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-base-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-base-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-1121637.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --NextPart-- From hipsec-bounces@lists.ietf.org Fri Feb 02 16:40:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD66F-0006sb-UW; Fri, 02 Feb 2007 16:37:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD66E-0006oR-7Z for hipsec@ietf.org; Fri, 02 Feb 2007 16:37:38 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD653-0002Tz-PM for hipsec@ietf.org; Fri, 02 Feb 2007 16:36:28 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l12LaN8A023646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 2 Feb 2007 15:36:24 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l12LaNDq014554; Fri, 2 Feb 2007 13:36:23 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l12LaKmL014462; Fri, 2 Feb 2007 13:36:22 -0800 (PST) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 13:36:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Feb 2007 13:35:43 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2FC4E@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <6075605f4a3946c677ab6ae3821beec9@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: about draft-ietf-hip-mm-04 Thread-Index: AcdEfh6bASDnOi5fSha77tbjAcT9tACXp90g From: "Henderson, Thomas R" To: "marcelo bagnulo braun" , "HIP" X-OriginalArrivalTime: 02 Feb 2007 21:36:20.0263 (UTC) FILETIME=[2D8E4370:01C74712] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bcdb6f0ba9636bf286b7e28ccb8bd9b Cc: Subject: [Hipsec] RE: about draft-ietf-hip-mm-04 X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Marcelo, Thanks for the detailed review; below are some inline responses:=20 > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 > Sent: Tuesday, January 30, 2007 6:52 AM > To: Henderson, Thomas R; HIP > Subject: about draft-ietf-hip-mm-04 >=20 > Hi, >=20 > I have some comments about this document. >=20 > Disclaimer: this is a first reading of this version of the draft and=20 > has changed a lot since last time i have read it, so i am probably=20 > missing some things... >=20 > Substantial: >=20 > In multiple parts of the document, it seems that there is an=20 > assumption=20 > that mulithoming is about having multiple locators=20 > simultaneously, and=20 > also using them simultaneously (OTOH, in other parts of the=20 > document it=20 > doesn't seems to be the case, so i am kind of confused...) This is=20 > expressed in the following parts of the document. >=20 > For instance in section 3.3.3. it is stated that: >=20 > In general, when multiple locators are used for a=20 > session, there is > the question of using multiple locators for failover only or for > load-balancing. Due to the implications of load-balancing on the > transport layer that still need to be worked out, this=20 > draft assumes > that multiple locators are used primarily for failover. An > implementation may use ICMP interactions, reachability checks, or > other means to detect the failure of a locator. >=20 > However, in the next section 3.3.4 it is stated that >=20 > address address31 as well. However, the use of different=20 > source and > destination addresses typically leads to different paths, with > different latencies in the network, and if packets were=20 > to arrive via > an arbitrary destination IP address (or path) for a given SPI, the > reordering due to different latencies may cause some=20 > packets to fall > outside of the ESP anti-replay window. For this reason,=20 > HIP provides >=20 > and this type of usage seems the one that governs the mechanisms=20 > described in the spec. > My point (that i expand below) is that it may be an option to=20 > consider=20 > a simple case for multihoming where the addresses are used=20 > sequentially=20 > and not for load sharing, and in this case, much of the complexity of=20 > dealing with multiple SPIs would be reduced. > Then define a more complex multihoming case, where load sharing is=20 > considered and in this case you will need the multiple SPI case. >=20 Perhaps this is a terminology issue; if the addresses are used sequentially, is this not the same as the mobility case (even though the device may not be mobile, but the language in the draft governing the mobility case would cover it)? i.e., if there was some description that by "mobile" we mean that we are talking about the case where multiple addresses on an interface are used sequentially, and that some multihoming scenarios also fit into this category, would it solve this issue for you? > more details on this.... >=20 > In section 3.1 it is stated that: >=20 > Such host multihoming > generally necessitates that a separate ESP SA is=20 > maintained for each > interface in order to prevent packets that arrive over different > paths from falling outside of the ESP replay protection window. >=20 > i fail to understand this part... could you describe a bit more in=20 > detail why would they fall outside the ESP replay protection=20 > window (i=20 > think it would be useful to include such description in the=20 > document in=20 > any case) > but are you assuming here that multiple addresses will be used=20 > simultaneously to exchange packets? Yes, if there are multiple addresses used simultaneously on the same SPI, particularly with multiple interfaces, there seems to be a possibility that, depending on how the ESP sliding window (RFC 4303, Sec 3.4.3) is implemented and configured, reordering due to multiple paths may cause packets to be rejected. Now, in IP routing, paths may change, and one would hope that ESP sliding window sizes would be robust to such typical path changes. I don't know for sure whether multihoming path reordering would result in larger reordering events than what one would see due to routing, but it is conceivable that it may be larger if we are considering multihoming/load balancing across multiple interfaces using different access link technologies. This is the reason that the recommendation for multiple SAs was inserted; namely, that window sizes configured to survive typical path rerouting may not be sufficient for multiple interface multihoming. Another alternative solution would be to increase the ESP window for these types of configurations; this would be simpler to support at the possible expense of more vulnerability in the window.=20 Would this change help in Section 3.2.3: To avoid problems with the ESP anti-replay window, a host SHOULD use a different SA for each interface or address used to receive packets from the peer host. ^^ , when multiple locator pairs are being used simultaneously rather than sequentially. >=20 > I mean, i think that a quite useful reasonable multihoming=20 > application=20 > scenario is where a node has multiple addresses, but it only uses one=20 > of them to exchange traffic as long this one works. If it detects a=20 > failure, it moves the communication to an alternative locator pair.=20 > This is what is needed for fault tolernace. Other applications, like=20 > using multiple locators simultaneously to exchange packets of=20 > the same=20 > communication seems to go beyond the needs for fault tolernace and=20 > would provide other different (not so obviously needed imho)=20 > features.=20 > (In particular, in shim6 this capability is not currently provided) >=20 > So summarizing, i think that for fault tolernace provision in=20 > multihoming, it is not needed to use multiple locators to=20 > exchange data=20 > simultaneously. what is needed is to know that there are multiple=20 > locators, but to use them sequentially, just as in mobility. In this=20 > case, the difference is when you learn the locator set,=20 > rather than how=20 > you use them. If this is the case, i think that it would be=20 > possible to=20 > have multihoming with a single SPI without having problems with the=20 > replay protection window. I think this is really important,=20 > because all=20 > this multiple SPI approach seems to present some additional problems=20 > that i will describe next I agree that it is simpler to avoid multiple SPIs, and perhaps that is what people will do in practice, but we were just trying to cover the case where it was possibly needed. Perhaps we are a little too aggressive in describing examples where all of these SAs become active when, in practice, most need not be. >=20 > Later on in section 3.2.3 it is stated that >=20 >=20 > In multihoming scenarios, it is important that hosts receiving > UPDATEs associate them correctly with the destination=20 > address used in > the packet carrying the UPDATE. >=20 > Ok, so this means that: > In the general case where two multihomed hosts are communicating,=20 > consider host A with N locators and host B with M locators,=20 > host A will=20 > need to send M UPDATe messages (one to each locator of B) containing=20 > all its locators in each message and including N different SPI. then=20 > Host B will need to send N UPDATE messages to host A=20 > containing all its=20 > locator and including M different SPIs. >=20 > so the result is that for exchanging thier locator sets, A and B will=20 > need to exchange M+N UPDATE messages and will need to use 2*M*N=20 > different SPI values, is this correct? >=20 There are possibly more messages; if A and B wished to establish a full mesh of SPIs between their respective locator sets, there could be up to O(N*M) UPDATE handshake exchanges and O(2*N*M) SPI values. We were trying to define the protocol so as to not preclude this, but operationally it is likely that the above would be overkill, and probably N and M are small numbers. If host A wishes to provide host B with N locators to choose from, and likewise B wants to provide A with M locators to choose from, it is a matter of policy as to which pairs of addresses that A or B care to form SPIs on, but it is recommended that for each such pair, an UPDATE handshake is done across that pair of addresses. This is mainly because the UPDATE packet conveys SPI information that a policy-enforcing middlebox may want to inspect, and the use of different locator pairs may cause different middleboxes to be traversed. This is why that text is written as it is; if you get an UPDATE to a particular destination address, then you should send the response UPDATE by reversing the addresses, regardless of whether that is the preferred locator for the peer. > I mean, we need to compare this with the other alternative,=20 > which is to=20 > use just 2 UPDATE messages to exchange the locator sets and=20 > use a pair=20 > of SPIs (one in each direction) I think what you are arguing for is more explicit decoupling of UPDATE function of conveying locator sets from UPDATE function of setting up SPIs between them, right? Note that each LOCATOR parameter conveys a complete locator set. I think that the protocol supports what you are asking for, but the text on how to use it that way is missing from the draft. Much of this draft was written before shim6/REAP had crystallized. Maybe it is worth taking a pass through the multihoming section to try to align it with what Marcelo suggests. I would be willing to take a stab at it, but does the WG support doing so in principle? >=20 > As i mentioned above, i think this is possible if a single=20 > locator pair=20 > is used at the time. I suggest that the draft only deals with simple=20 > multihoming, but that simple is not the case where one end has 2=20 > locators and the other just one locator, but that simple is=20 > defined as=20 > the case where the locator pairs are used sequentially, just=20 > as in the=20 > mobility case, just that it happens the they learn it all together. > In this case, i think we can live with a single SPI pair of=20 > values (one=20 > per direction) and all thiss multiple UPDATE message exchange and=20 > multiple SPI is no longer needed, makes sense? >=20 >=20 > So in this approach, peers would need to exchange only a=20 > single UPDATE=20 > message in each direction to convey alternative locator information. >=20 > The exchange would be >=20 >=20 > Multi-homed Host Peer Host >=20 > UPDATE(ESP_INFO, LOCATOR, SEQ, [DIFFIE_HELLMAN]) > -----------------------------------> > UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ) > <----------------------------------- >=20 > At this point, both ends know all the available locator=20 > pairs, but the=20 > reachability test haven't been done yet. However, the=20 > reachability test=20 > is not actually needed until the peer wants to actually use=20 > the packet,=20 > so in the case that there are many locator pairs, doing all the=20 > reachability test upon the reception of the update message is=20 > probably=20 > not a good idea. Actually the reachability test can be deltayed until=20 > the peer needs to use the locator pair. In addition, this=20 > reahcbaility=20 > test can be use to actually check the reacbaility of the locator pair=20 > when the peer wants to use it. (i mean, making the reachability test=20 > upon the reception of the UPDATe message is useful for preventing=20 > flooding attacks, but is not so useful for determining whether the=20 > locator pair is working, becasue the peer will not use the=20 > locator pair=20 > inmediatelly) >=20 > So, i would suggest that the ECHO request/reply packets are used as a=20 > basic way to determine if the locator pair is working, and that this=20 > verification is only performed when the preferred locator pair stops=20 > working (or when the peer wants to start using a new locator pair for=20 > whatever reason) At this point the echo request reply can be used to=20 > test reachability in order to select a new alternative locator pair=20 > that is working. this i think would also be compatible with using a=20 > single SPI, since you would only send a limited set of=20 > packets through=20 > alternative paths, whcih shouldn't affect the replay=20 > protection window=20 > so much (i am guessing here....) >=20 > So my suggestion is: define a simple multihomed case for sequentially=20 > used locator pairs, where > - Use a single SPI pair for all locator pairs > - Use a single pair of UPDATE messages > - Perform the ECHO request reply only when the new locator=20 > pair will be=20 > used >=20 >=20 >=20 > Semi substantial: >=20 > In section i it is stated that: >=20 > Preferred locator. A locator on which a host prefers to=20 > receive data. >=20 > This is strange... i mean the locator where a node receives=20 > traffic to=20 > doesn't seem to be so relevant as the receiver doesn't even=20 > look at the=20 > locators in the incoming packet, but just to the SPI to perform the=20 > demux. I, mean, as long as the locator has been assigned to the host=20 > and the SPI is the correct one, the particular locator=20 > doesn't seem to=20 > be relevant.=20 Consider the case where you have multiple heterogeneous interfaces and one is preferred for bandwidth or cost reasons. > OTOH, what it seems to be relevant, is the=20 > locator that a=20 > peer uses to send traffic. Of corse, a receiver may express=20 > to the peer=20 > what locator it prefers to receive traffic, but at the end of=20 > the day,=20 > is the choice of the sender which one to actually use to send the=20 > traffic. This is especially true in the multihoming case, where the=20 > sender may have multiple valid locators to send traffic to. So, maybe=20 > including something from the senders perspective would be good here,=20 > like the preferred peer locator and the preferred local locator I don't think the draft precludes it; preferred local source locator is a matter of source policy and not part of the protocol exchange. I wouldn't object to stating something along the lines above that there are policy decisions that affect how packets are sent, and these include decisions on both what locator to tell the peer is preferred destination locator, and also what locator/interface to use as the source. =20 =20 >=20 >=20 > In section 3.1 it is stated that: >=20 > Finally, consider the case when a host is multihomed (has=20 > more than > one globally routable address) and makes these multiple addresses > available for use by the upper layer protocols, for fault=20 > tolerance. >=20 > Not sure about the phrasing of this sentence, the addresses are not=20 > available for the upper layers, since the multiple address are=20 > transparent to the upper layers (this is what all this is about,=20 > right?) > So i would suggest to rephrase this, saying that the addresses are=20 > available for the HIP ayer to be used as alternative locators or=20 > soemthing in this line. I agree with your clarification and will change it unless anyone discusses further. >=20 >=20 > In section 3.2 it is stated that: >=20 > However, some implementations may want to experiment with > sending LOCATOR parameters also on other packets, such as=20 > R1, I2, and > NOTIFY. >=20 > I am not sure that R1 makes much sense... i mean, this is=20 > probably part=20 > of the initial contact problem i.e. when sending the I1, the=20 > initiator=20 > needs to know multiple locators in case one has failed. So including=20 > them in R1 doesn't seem to help much at that point imho. OTOH,=20 > including them in R2, would result in having them already=20 > available for=20 > that communication. >=20 The thinking was that there may be a use case where the responder wants to shift I2/R2 exchange onto a different interface, without necessarily updating the DNS or rendezvous server to do so. Thanks again for the review, Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Feb 03 08:51:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDLHP-0006pH-ET; Sat, 03 Feb 2007 08:50:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDLHN-0006p9-HE for hipsec@ietf.org; Sat, 03 Feb 2007 08:50:09 -0500 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDLHM-0001Nf-Al for hipsec@ietf.org; Sat, 03 Feb 2007 08:50:09 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 3B7E1E4E84; Sat, 3 Feb 2007 14:50:07 +0100 (CET) Received: from [163.117.203.147] (unknown [163.117.203.147]) by smtp02.uc3m.es (Postfix) with ESMTP id 701E9E4E7F; Sat, 3 Feb 2007 14:49:51 +0100 (CET) In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D01A2FC4E@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6D01A2FC4E@XCH-NW-5V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Date: Sat, 3 Feb 2007 14:45:11 +0100 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: e3ebaaff3b3539efaf29ef65eea2aded Cc: HIP Subject: [Hipsec] Re: about draft-ietf-hip-mm-04 X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org El 02/02/2007, a las 22:35, Henderson, Thomas R escribi=F3: > > Perhaps this is a terminology issue; if the addresses are used > sequentially, is this not the same as the mobility case (even though=20= > the > device may not be mobile, but the language in the draft governing the > mobility case would cover it)? > > i.e., if there was some description that by "mobile" we mean that we=20= > are > talking about the case where multiple addresses on an interface are=20 > used > sequentially, and that some multihoming scenarios also fit into this > category, would it solve this issue for you? > i don't think this would be enough... There are two sides of this: First, the multihoming case has some substantial cases that the case of=20= mobility essentially, because in the mobility case the assumption is=20 that the node learns one address at the time, so the sequential usage=20 of the addresses is just a natural concequence of this. In the=20 multihoming case, the node may learn all the addresses in a single=20 update message but it can choose to use them sequentially essntially=20 because this all that is needed for fault tolerance. So, in the draft these cases are clearly differentiated and the=20 mobility case seems to only cover the case where the node learns one=20 address at the time. At least is not clear at all to me from the=20 reading of the draft that the mobility case covers the case of=20 sequential usage of addresses in multihomed cases. Second, it may be required some different processing in the case of=20 multihoming (not very different though) In particular, in case you=20 learn all the addresses in a single update, you need to think about how=20= to perform the verification. I guess that a single HMAC/signature would=20= protect all the addresses, but i don't think it is needed to perform=20 the echo request verification for all the addresses contained in the=20 UPDATE message inmediatelly after the reception of the message. I mean,=20= this verification has a cost (packet exchange) and it may not be=20 required (since you may not need to use the address never) This is=20 again different from the mobility case, where when a node learns a new=20= address, it will inmediatelly use it, since it is the only one it has.=20= Moreover, in the multihoming case, it is highly likely that the node=20 will need to perform the echo request reply exchange just before=20 actually using the new address, since it will want to verify the the=20 address is working. So, i would suggest to include a new section that describes how to=20 support sequential usage of addresses in multihoming. The tools would=20 be very similar than the case of mobility i agree, but i really think=20 the draft would be much clearer if this is explicitly described=20 including the considerations about the different moments the addresses=20= are learnt and used in multihoming. I can provide text for this if you want.... >> more details on this.... >> >> In section 3.1 it is stated that: >> >> Such host multihoming >> generally necessitates that a separate ESP SA is >> maintained for each >> interface in order to prevent packets that arrive over different >> paths from falling outside of the ESP replay protection window. >> >> i fail to understand this part... could you describe a bit more in >> detail why would they fall outside the ESP replay protection >> window (i >> think it would be useful to include such description in the >> document in >> any case) >> but are you assuming here that multiple addresses will be used >> simultaneously to exchange packets? > > Yes, if there are multiple addresses used simultaneously on the same > SPI, particularly with multiple interfaces, there seems to be a > possibility that, depending on how the ESP sliding window (RFC 4303,=20= > Sec > 3.4.3) is implemented and configured, reordering due to multiple paths > may cause packets to be rejected. > > Now, in IP routing, paths may change, and one would hope that ESP > sliding window sizes would be robust to such typical path changes. I > don't know for sure whether multihoming path reordering would result = in > larger reordering events than what one would see due to routing, but = it > is conceivable that it may be larger if we are considering > multihoming/load balancing across multiple interfaces using different > access link technologies. This is the reason that the recommendation > for multiple SAs was inserted; namely, that window sizes configured to > survive typical path rerouting may not be sufficient for multiple > interface multihoming. Another alternative solution would be to > increase the ESP window for these types of configurations; this would=20= > be > simpler to support at the possible expense of more vulnerability in = the > window. > > Would this change help in Section 3.2.3: > > To avoid problems with the ESP anti-replay window, a host SHOULD = use > a different SA for each interface or address used to receive = packets > from the peer host. > ^^ > , when multiple locator pairs are being used > simultaneously rather than sequentially. > yes, very much >> >> I mean, i think that a quite useful reasonable multihoming >> application >> scenario is where a node has multiple addresses, but it only uses one >> of them to exchange traffic as long this one works. If it detects a >> failure, it moves the communication to an alternative locator pair. >> This is what is needed for fault tolernace. Other applications, like >> using multiple locators simultaneously to exchange packets of >> the same >> communication seems to go beyond the needs for fault tolernace and >> would provide other different (not so obviously needed imho) >> features. >> (In particular, in shim6 this capability is not currently provided) >> >> So summarizing, i think that for fault tolernace provision in >> multihoming, it is not needed to use multiple locators to >> exchange data >> simultaneously. what is needed is to know that there are multiple >> locators, but to use them sequentially, just as in mobility. In this >> case, the difference is when you learn the locator set, >> rather than how >> you use them. If this is the case, i think that it would be >> possible to >> have multihoming with a single SPI without having problems with the >> replay protection window. I think this is really important, >> because all >> this multiple SPI approach seems to present some additional problems >> that i will describe next > > I agree that it is simpler to avoid multiple SPIs, and perhaps that is > what people will do in practice, but we were just trying to cover the > case where it was possibly needed. I think it is perfectly okey to cover this case, so when people try to=20= use multiple locators simultaneously, this is already covered in the=20 draft. So, actually i am not suggesting to remove anything, just to add=20= additional text describing more in detail the simpler case where the=20 addresses are used sequentially (but learnt simultaneously) > Perhaps we are a little too > aggressive in describing examples where all of these SAs become active > when, in practice, most need not be. > Well, actually in the simple case described, the text is a bit=20 confusing, since on one hand multiple SPIs are used, but it is=20 reccomended that addresses are not used simultaneously. >> >> Later on in section 3.2.3 it is stated that >> >> >> In multihoming scenarios, it is important that hosts receiving >> UPDATEs associate them correctly with the destination >> address used in >> the packet carrying the UPDATE. >> >> Ok, so this means that: >> In the general case where two multihomed hosts are communicating, >> consider host A with N locators and host B with M locators, >> host A will >> need to send M UPDATe messages (one to each locator of B) containing >> all its locators in each message and including N different SPI. then >> Host B will need to send N UPDATE messages to host A >> containing all its >> locator and including M different SPIs. >> >> so the result is that for exchanging thier locator sets, A and B will >> need to exchange M+N UPDATE messages and will need to use 2*M*N >> different SPI values, is this correct? >> > > There are possibly more messages; if A and B wished to establish a = full > mesh of SPIs between their respective locator sets, there could be up=20= > to > O(N*M) UPDATE handshake exchanges and O(2*N*M) SPI values. We were > trying to define the protocol so as to not preclude this, but > operationally it is likely that the above would be overkill, and > probably N and M are small numbers. > > If host A wishes to provide host B with N locators to choose from, and > likewise B wants to provide A with M locators to choose from, it is a > matter of policy as to which pairs of addresses that A or B care to=20 > form > SPIs on, but it is recommended that for each such pair, an UPDATE > handshake is done across that pair of addresses. This is mainly=20 > because > the UPDATE packet conveys SPI information that a policy-enforcing > middlebox may want to inspect, and the use of different locator pairs > may cause different middleboxes to be traversed. This is why that = text > is written as it is; if you get an UPDATE to a particular destination > address, then you should send the response UPDATE by reversing the > addresses, regardless of whether that is the preferred locator for the > peer. > >> I mean, we need to compare this with the other alternative, >> which is to >> use just 2 UPDATE messages to exchange the locator sets and >> use a pair >> of SPIs (one in each direction) > > I think what you are arguing for is more explicit decoupling of UPDATE > function of conveying locator sets from UPDATE function of setting up > SPIs between them, right? Note that each LOCATOR parameter conveys a > complete locator set. I think that the protocol supports what you are > asking for, but the text on how to use it that way is missing from the > draft. > agree, i think the protocol messages described are all that is needed=20 (what i think is missing is a description of the sequential case and=20 for that case explicitly not reccomend the usage of mutliple SPIs) > Much of this draft was written before shim6/REAP had crystallized. > Maybe it is worth taking a pass through the multihoming section to try > to align it with what Marcelo suggests. I would be willing to take a > stab at it, but does the WG support doing so in principle? as i said above, i am willing to help you with this > >> >> As i mentioned above, i think this is possible if a single >> locator pair >> is used at the time. I suggest that the draft only deals with simple >> multihoming, but that simple is not the case where one end has 2 >> locators and the other just one locator, but that simple is >> defined as >> the case where the locator pairs are used sequentially, just >> as in the >> mobility case, just that it happens the they learn it all together. >> In this case, i think we can live with a single SPI pair of >> values (one >> per direction) and all thiss multiple UPDATE message exchange and >> multiple SPI is no longer needed, makes sense? >> >> >> So in this approach, peers would need to exchange only a >> single UPDATE >> message in each direction to convey alternative locator information. >> >> The exchange would be >> >> >> Multi-homed Host Peer Host >> >> UPDATE(ESP_INFO, LOCATOR, SEQ, [DIFFIE_HELLMAN]) >> -----------------------------------> >> UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ) >> <----------------------------------- >> >> At this point, both ends know all the available locator >> pairs, but the >> reachability test haven't been done yet. However, the >> reachability test >> is not actually needed until the peer wants to actually use >> the packet, >> so in the case that there are many locator pairs, doing all the >> reachability test upon the reception of the update message is >> probably >> not a good idea. Actually the reachability test can be deltayed until >> the peer needs to use the locator pair. In addition, this >> reahcbaility >> test can be use to actually check the reacbaility of the locator pair >> when the peer wants to use it. (i mean, making the reachability test >> upon the reception of the UPDATe message is useful for preventing >> flooding attacks, but is not so useful for determining whether the >> locator pair is working, becasue the peer will not use the >> locator pair >> inmediatelly) >> >> So, i would suggest that the ECHO request/reply packets are used as a >> basic way to determine if the locator pair is working, and that this >> verification is only performed when the preferred locator pair stops >> working (or when the peer wants to start using a new locator pair for >> whatever reason) At this point the echo request reply can be used to >> test reachability in order to select a new alternative locator pair >> that is working. this i think would also be compatible with using a >> single SPI, since you would only send a limited set of >> packets through >> alternative paths, whcih shouldn't affect the replay >> protection window >> so much (i am guessing here....) >> >> So my suggestion is: define a simple multihomed case for sequentially >> used locator pairs, where >> - Use a single SPI pair for all locator pairs >> - Use a single pair of UPDATE messages >> - Perform the ECHO request reply only when the new locator >> pair will be >> used >> >> >> >> Semi substantial: >> >> In section i it is stated that: >> >> Preferred locator. A locator on which a host prefers to >> receive data. >> >> This is strange... i mean the locator where a node receives >> traffic to >> doesn't seem to be so relevant as the receiver doesn't even >> look at the >> locators in the incoming packet, but just to the SPI to perform the >> demux. I, mean, as long as the locator has been assigned to the host >> and the SPI is the correct one, the particular locator >> doesn't seem to >> be relevant. > > Consider the case where you have multiple heterogeneous interfaces and > one is preferred for bandwidth or cost reasons. agree > >> OTOH, what it seems to be relevant, is the >> locator that a >> peer uses to send traffic. Of corse, a receiver may express >> to the peer >> what locator it prefers to receive traffic, but at the end of >> the day, >> is the choice of the sender which one to actually use to send the >> traffic. This is especially true in the multihoming case, where the >> sender may have multiple valid locators to send traffic to. So, maybe >> including something from the senders perspective would be good here, >> like the preferred peer locator and the preferred local locator > > I don't think the draft precludes it; preferred local source locator = is > a matter of source policy and not part of the protocol exchange. > > I wouldn't object to stating something along the lines above that = there > are policy decisions that affect how packets are sent, and these=20 > include > decisions on both what locator to tell the peer is preferred=20 > destination > locator, and also what locator/interface to use as the source. > my point was that it may make sense to also define the local preferred=20= locator and also the peer preferred locator >> >> >> In section 3.1 it is stated that: >> >> Finally, consider the case when a host is multihomed (has >> more than >> one globally routable address) and makes these multiple addresses >> available for use by the upper layer protocols, for fault >> tolerance. >> >> Not sure about the phrasing of this sentence, the addresses are not >> available for the upper layers, since the multiple address are >> transparent to the upper layers (this is what all this is about, >> right?) >> So i would suggest to rephrase this, saying that the addresses are >> available for the HIP ayer to be used as alternative locators or >> soemthing in this line. > > I agree with your clarification and will change it unless anyone > discusses further. > >> >> >> In section 3.2 it is stated that: >> >> However, some implementations may want to experiment with >> sending LOCATOR parameters also on other packets, such as >> R1, I2, and >> NOTIFY. >> >> I am not sure that R1 makes much sense... i mean, this is >> probably part >> of the initial contact problem i.e. when sending the I1, the >> initiator >> needs to know multiple locators in case one has failed. So including >> them in R1 doesn't seem to help much at that point imho. OTOH, >> including them in R2, would result in having them already >> available for >> that communication. >> > > The thinking was that there may be a use case where the responder = wants > to shift I2/R2 exchange onto a different interface, without = necessarily > updating the DNS or rendezvous server to do so. > i see thanks, marcelo > Thanks again for the review, > Tom > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Feb 05 11:39:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE6sb-0005mJ-Lz; Mon, 05 Feb 2007 11:39:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE6sa-0005m8-1k for hipsec@ietf.org; Mon, 05 Feb 2007 11:39:44 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE6sW-00064l-OX for hipsec@ietf.org; Mon, 05 Feb 2007 11:39:44 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l15GddxL004140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Feb 2007 08:39:39 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l15GdctJ004435; Mon, 5 Feb 2007 08:39:38 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l15Gdcg4004424; Mon, 5 Feb 2007 08:39:38 -0800 (PST) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 08:39:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Feb 2007 08:39:36 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2FC58@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: about draft-ietf-hip-mm-04 Thread-Index: AcdHmjlRaz4ODVA8RRK4PBRj6r0HOgBqZSVw From: "Henderson, Thomas R" To: "marcelo bagnulo braun" X-OriginalArrivalTime: 05 Feb 2007 16:39:36.0278 (UTC) FILETIME=[38CAFF60:01C74944] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: HIP Subject: [Hipsec] RE: about draft-ietf-hip-mm-04 X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org =20 > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 > Sent: Saturday, February 03, 2007 5:45 AM > To: Henderson, Thomas R > Cc: HIP > Subject: Re: about draft-ietf-hip-mm-04 >=20 >=20 > So, i would suggest to include a new section that describes how to=20 > support sequential usage of addresses in multihoming. The tools would=20 > be very similar than the case of mobility i agree, but i really think=20 > the draft would be much clearer if this is explicitly described=20 > including the considerations about the different moments the=20 > addresses=20 > are learnt and used in multihoming. >=20 >=20 > I can provide text for this if you want.... >=20 I think it would be helpful to propose this new text; I would think that it would be an agreeable and useful extension of what we have already. There will be a few other changes due the secdir review of the draft; I think that the -05 version of the draft can propose the changes due to this and also the reviews ongoing presently. Thanks, Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Feb 05 23:58:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEIOv-0005mW-TI; Mon, 05 Feb 2007 23:57:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEIOu-0005lH-AT for hipsec@ietf.org; Mon, 05 Feb 2007 23:57:52 -0500 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEIOs-000084-MM for hipsec@ietf.org; Mon, 05 Feb 2007 23:57:52 -0500 Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id RAA13873; Tue, 6 Feb 2007 17:57:33 +1300 In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D01A2FC58@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6D01A2FC58@XCH-NW-5V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <25699E5A-26EA-4C0B-B4B0-7DD81C70894D@indranet.co.nz> Content-Transfer-Encoding: 7bit From: Andrew McGregor Subject: Re: [Hipsec] RE: about draft-ietf-hip-mm-04 Date: Tue, 6 Feb 2007 17:57:13 +1300 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On 06/02/2007, at 5:39 AM, Henderson, Thomas R wrote: > > >> -----Original Message----- >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> Sent: Saturday, February 03, 2007 5:45 AM >> To: Henderson, Thomas R >> Cc: HIP >> Subject: Re: about draft-ietf-hip-mm-04 >> > >> >> So, i would suggest to include a new section that describes how to >> support sequential usage of addresses in multihoming. The tools would >> be very similar than the case of mobility i agree, but i really think >> the draft would be much clearer if this is explicitly described >> including the considerations about the different moments the >> addresses >> are learnt and used in multihoming. >> >> >> I can provide text for this if you want.... >> > > I think it would be helpful to propose this new text; I would think > that > it would be an agreeable and useful extension of what we have already. > > There will be a few other changes due the secdir review of the > draft; I > think that the -05 version of the draft can propose the changes due to > this and also the reviews ongoing presently. However, let's not forget that the reason the draft turned out this way is because there's a known issue with using the same SPI in quick succession going from a very fast link to a very slow one... namely, that the windows in both ESP and TCP interact really badly in that case. So using separate SPIs is rather required. I don't object to text describing how to use this for multihoming, far from it, but the multi-SPI solution really is necessary. Andrew _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Feb 06 03:17:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HELVx-00011O-Dc; Tue, 06 Feb 2007 03:17:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HELVw-0000ws-5q for hipsec@ietf.org; Tue, 06 Feb 2007 03:17:20 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HELVu-000659-JJ for hipsec@ietf.org; Tue, 06 Feb 2007 03:17:20 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id AF46D14588F; Tue, 6 Feb 2007 09:17:10 +0100 (CET) Received: from [163.117.203.89] (unknown [163.117.203.89]) by smtp01.uc3m.es (Postfix) with ESMTP id 4701A147066; Tue, 6 Feb 2007 09:17:09 +0100 (CET) In-Reply-To: <25699E5A-26EA-4C0B-B4B0-7DD81C70894D@indranet.co.nz> References: <77F357662F8BFA4CA7074B0410171B6D01A2FC58@XCH-NW-5V1.nw.nos.boeing.com> <25699E5A-26EA-4C0B-B4B0-7DD81C70894D@indranet.co.nz> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <3e955200fb931241b86102800f5d77e9@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [Hipsec] RE: about draft-ietf-hip-mm-04 Date: Tue, 6 Feb 2007 09:18:17 +0100 To: Andrew McGregor X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org El 06/02/2007, a las 5:57, Andrew McGregor escribi=F3: > > On 06/02/2007, at 5:39 AM, Henderson, Thomas R wrote: > >> >> >>> -----Original Message----- >>> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >>> Sent: Saturday, February 03, 2007 5:45 AM >>> To: Henderson, Thomas R >>> Cc: HIP >>> Subject: Re: about draft-ietf-hip-mm-04 >>> >> >>> >>> So, i would suggest to include a new section that describes how to >>> support sequential usage of addresses in multihoming. The tools = would >>> be very similar than the case of mobility i agree, but i really = think >>> the draft would be much clearer if this is explicitly described >>> including the considerations about the different moments the >>> addresses >>> are learnt and used in multihoming. >>> >>> >>> I can provide text for this if you want.... >>> >> >> I think it would be helpful to propose this new text; I would think=20= >> that >> it would be an agreeable and useful extension of what we have = already. >> >> There will be a few other changes due the secdir review of the draft;=20= >> I >> think that the -05 version of the draft can propose the changes due = to >> this and also the reviews ongoing presently. > > However, let's not forget that the reason the draft turned out this=20 > way is because there's a known issue with using the same SPI in quick=20= > succession going from a very fast link to a very slow one... but it could happen the very same thing in the mobility case, right? I=20= may even say that this is more likely since in mobility the different=20 types of links may differ greatly in terms of bandwidth. Actually, for the multihoming case, the problem is already there even=20 if you don't use multiple locators. I mean if you are using BGP type of=20= multihoming, it may well be the case that you change the exit link in a=20= multihomed site using the same address and then you would face the=20 exact same problems that you are describing, right? > namely, that the windows in both ESP and TCP interact really badly in=20= > that case. So using separate SPIs is rather required. I don't object=20= > to text describing how to use this for multihoming, far from it, but=20= > the multi-SPI solution really is necessary. > as i see it, multiple spi is a must if you want to use multiple=20 locators pairs simultaneously. If you want to use them sequentially i=20 would say a MAY, since it is the same situation that we have here in=20 BGP based multihomed sites even if you use a single locator pair for=20 the hip communication, agree? Regards, marcelo > Andrew > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Feb 06 03:22:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HELab-0003Zs-FB; Tue, 06 Feb 2007 03:22:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HELaa-0003Zg-5E for hipsec@ietf.org; Tue, 06 Feb 2007 03:22:08 -0500 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HELaY-0007mE-HQ for hipsec@ietf.org; Tue, 06 Feb 2007 03:22:08 -0500 Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id VAA16272; Tue, 6 Feb 2007 21:21:51 +1300 In-Reply-To: <3e955200fb931241b86102800f5d77e9@it.uc3m.es> References: <77F357662F8BFA4CA7074B0410171B6D01A2FC58@XCH-NW-5V1.nw.nos.boeing.com> <25699E5A-26EA-4C0B-B4B0-7DD81C70894D@indranet.co.nz> <3e955200fb931241b86102800f5d77e9@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7BC3F8E6-20E6-4BC3-8D5F-39DA339B3510@indranet.co.nz> Content-Transfer-Encoding: 7bit From: Andrew McGregor Subject: Re: [Hipsec] RE: about draft-ietf-hip-mm-04 Date: Tue, 6 Feb 2007 21:21:46 +1300 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On 06/02/2007, at 9:18 PM, marcelo bagnulo braun wrote: > > > but it could happen the very same thing in the mobility case, > right? I may even say that this is more likely since in mobility > the different types of links may differ greatly in terms of bandwidth. A dramatic difference in latency might be worse than a bandwidth change, but yes. > > Actually, for the multihoming case, the problem is already there > even if you don't use multiple locators. I mean if you are using > BGP type of multihoming, it may well be the case that you change > the exit link in a multihomed site using the same address and then > you would face the exact same problems that you are describing, right? Exactly. > > as i see it, multiple spi is a must if you want to use multiple > locators pairs simultaneously. If you want to use them sequentially > i would say a MAY, since it is the same situation that we have here > in BGP based multihomed sites even if you use a single locator pair > for the hip communication, agree? Yes, I suppose. I might suggest SHOULD rather than MAY, as that implies there better be a good reason not to, rather than that the feature is simply optional. Andrew _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Feb 14 15:51:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHR5R-0006SU-OB; Wed, 14 Feb 2007 15:50:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHR5F-0006Ps-QX; Wed, 14 Feb 2007 15:50:33 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HHR5F-0008NY-Bj; Wed, 14 Feb 2007 15:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 98E782AD79; Wed, 14 Feb 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HHR4k-0004KT-Bp; Wed, 14 Feb 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 14 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: hipsec@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-esp-05.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org --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 : Using ESP transport format with HIP Author(s) : P. Jokela, et al. Filename : draft-ietf-hip-esp-05.txt Pages : 37 Date : 2007-2-14 This memo specifies an Encapsulated Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-esp-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-esp-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-esp-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-14132216.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-esp-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-esp-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-14132216.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --NextPart-- From hipsec-bounces@lists.ietf.org Thu Feb 15 09:23:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHhVV-0000wq-M7; Thu, 15 Feb 2007 09:22:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHhVV-0000wi-5Z for hipsec@ietf.org; Thu, 15 Feb 2007 09:22:45 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHhVM-00052K-I4 for hipsec@ietf.org; Thu, 15 Feb 2007 09:22:45 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F348021141; Thu, 15 Feb 2007 15:22:31 +0100 (CET) X-AuditID: c1b4fb3e-b1ed7bb0000007e1-25-45d46ca7ae4b Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DC881203FD; Thu, 15 Feb 2007 15:22:31 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Feb 2007 15:22:31 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Feb 2007 15:22:31 +0100 Received: from [131.160.126.110] (rvi2-126-110.lmf.ericsson.se [131.160.126.110]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 6CE092374; Thu, 15 Feb 2007 16:22:31 +0200 (EET) Message-ID: <45D46CA6.8070409@ericsson.com> Date: Thu, 15 Feb 2007 16:22:30 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Gonzalo Camarillo Subject: Re: [Hipsec] WGLC: draft-ietf-hip-applications-00.txt References: <45C07CBD.8040801@ericsson.com> In-Reply-To: <45C07CBD.8040801@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Feb 2007 14:22:31.0473 (UTC) FILETIME=[BA8EDA10:01C7510C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Pekka Nikander , HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Hi, note that we are already half-way through this WGLC and we have not received any comments (yet). I would like to encourage people to be active in this WGLC. Thanks, Gonzalo Gonzalo Camarillo wrote: > Folks, > > we would like to working group last call the following draft: > http://www.ietf.org/internet-drafts/draft-ietf-hip-applications-00.txt > > This WGLC will end on March 1st. This should give people enough time to > read the draft and send their comments to the list and the authors. > > As the first WGLC comment, the draft should have a null IANA > considerations section. > > Cheers, > > Gonzalo > HIP co-chair > > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Feb 21 03:52:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJnCo-0007FX-S1; Wed, 21 Feb 2007 03:52:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJnCo-0007DZ-CE for hipsec@ietf.org; Wed, 21 Feb 2007 03:52:06 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJnCm-0000pi-1Q for hipsec@ietf.org; Wed, 21 Feb 2007 03:52:06 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 23A0D2DB2; Wed, 21 Feb 2007 10:52:03 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.7-niksula20061027 (2006-10-05) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.1.7-niksula20061027 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id B38FE2D74 for ; Wed, 21 Feb 2007 10:52:02 +0200 (EET) Received: from localhost (mkomu@localhost) by kekkonen.cs.hut.fi (8.13.4+Sun/8.13.3/Submit) with ESMTP id l1L8q05m006819 for ; Wed, 21 Feb 2007 10:52:02 +0200 (EET) X-Authentication-Warning: kekkonen.cs.hut.fi: mkomu owned process doing -bs Date: Wed, 21 Feb 2007 10:52:00 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: hipsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [Hipsec] HIP ja loopback X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Hi all, I think the base draft (and neither the mm draft) does not mention the use of loopback. By loopback I mean that the host is connecting to itself. The state machine simply does not work with loopback: * Host sends I1 to itself and goes to I1_SENT * With luck the host accepts the I1; the host used different src and dst HITs, and the dst HIT of I1 was bigger than the src HIT. It is not really defined what to do when the HITs are the same... anyway, let's assume that the host sent an R1. * Host receives the R1 (still in I1_SENT). Same smaller/bigger than issues as earlier. With luck, the host sends I2 and goes to I2-SENT. * Receive I2. Same smaller/bigger than issues as before. With luck, host sends R2 and goes to R2-SENT. * Receive R2: Drop and stay at R2-SENT. * Exchange Complete Timeout: Move to ESTABLISHED Certainly there is room for improvement with loopback. I'd suggest that the draft either excludes it explicitly or contains a modified version of the state machine. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Feb 21 04:10:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJnUQ-0006oD-Rb; Wed, 21 Feb 2007 04:10:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJnUO-0006nb-O9 for hipsec@ietf.org; Wed, 21 Feb 2007 04:10:17 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJnUN-0006z6-EO for hipsec@ietf.org; Wed, 21 Feb 2007 04:10:16 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id DBE6C212D3A; Wed, 21 Feb 2007 11:10:11 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 8DC3C212D38; Wed, 21 Feb 2007 11:10:11 +0200 (EET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] HIP ja loopback Date: Wed, 21 Feb 2007 11:10:09 +0200 To: Miika Komu X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org > I think the base draft (and neither the mm draft) does not mention > the use of loopback. Simple question: Why would one like to use HIP on a loopback? For testing purposes? Maybe. For anything else? I cannot see a reason. IMHO, if a process connects to the same host through a local HIT, it should result in a simple TCP connection / UDP packet, without HIP, since I cannot see how HIP would bring there any benefit. Virtual hosts are an interesting issue, though, but I don't see there any fundamental difference; they shouldn't use the loopback anyway. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Feb 21 04:54:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJoB9-0004uv-NJ; Wed, 21 Feb 2007 04:54:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJoB8-0004ud-HC for hipsec@ietf.org; Wed, 21 Feb 2007 04:54:26 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJoB7-00037W-7J for hipsec@ietf.org; Wed, 21 Feb 2007 04:54:26 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 910CA2D7A; Wed, 21 Feb 2007 11:54:20 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.7-niksula20061027 (2006-10-05) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.1.7-niksula20061027 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 46D1D2CDA; Wed, 21 Feb 2007 11:54:19 +0200 (EET) Received: from localhost (mkomu@localhost) by kekkonen.cs.hut.fi (8.13.4+Sun/8.13.3/Submit) with ESMTP id l1L9sI6g011157; Wed, 21 Feb 2007 11:54:18 +0200 (EET) X-Authentication-Warning: kekkonen.cs.hut.fi: mkomu owned process doing -bs Date: Wed, 21 Feb 2007 11:54:17 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Pekka Nikander Subject: Re: [Hipsec] HIP ja loopback In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Wed, 21 Feb 2007, Pekka Nikander wrote: >> I think the base draft (and neither the mm draft) does not mention the use >> of loopback. > > Simple question: Why would one like to use HIP on a loopback? One reason is that sometimes services can be local. Connecting to a local vs. remote service should not be any different from the user or application viewpoint. > For testing purposes? Maybe. For anything else? I cannot see a > reason. IMHO, if a process connects to the same host through a local > HIT, it should result in a simple TCP connection / UDP packet, without > HIP, since I cannot see how HIP would bring there any benefit. I think using plain TCP or UDP for loopback in production environments would be the best choice but I don't see any text about this in the draft. Or maybe I just missed it. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Feb 21 05:22:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJobr-0002G7-57; Wed, 21 Feb 2007 05:22:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJobp-0002Fi-RD for hipsec@ietf.org; Wed, 21 Feb 2007 05:22:01 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJobm-0000xw-Dx for hipsec@ietf.org; Wed, 21 Feb 2007 05:22:01 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id C9DC7212D3A; Wed, 21 Feb 2007 12:21:54 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 7F47B212D38; Wed, 21 Feb 2007 12:21:54 +0200 (EET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <11EF9DED-F85C-4171-B786-7DE53B707614@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] HIP ja loopback Date: Wed, 21 Feb 2007 12:21:52 +0200 To: Miika Komu X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org >>> I think the base draft (and neither the mm draft) does not >>> mention the use of loopback. >> >> Simple question: Why would one like to use HIP on a loopback? > > One reason is that sometimes services can be local. Connecting to a > local vs. remote service should not be any different from the user > or application viewpoint. > >> For testing purposes? Maybe. For anything else? I cannot see a >> reason. IMHO, if a process connects to the same host through a >> local HIT, it should result in a simple TCP connection / UDP >> packet, without HIP, since I cannot see how HIP would bring there >> any benefit. > > I think using plain TCP or UDP for loopback in production > environments would be the best choice but I don't see any text > about this in the draft. Or maybe I just missed it. Right. But that is an issue which is local to the implementation and transparent to the apps. Hence, I don't see any need to specify it; different implementations can do it in different ways. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Feb 21 05:24:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJoe8-0003xI-C1; Wed, 21 Feb 2007 05:24:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJoe7-0003xD-ID for hipsec@ietf.org; Wed, 21 Feb 2007 05:24:23 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJoe6-0001Pt-0J for hipsec@ietf.org; Wed, 21 Feb 2007 05:24:23 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 907DF2DAF; Wed, 21 Feb 2007 12:24:21 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.7-niksula20061027 (2006-10-05) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.1.7-niksula20061027 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 2E56B2D5C; Wed, 21 Feb 2007 12:24:21 +0200 (EET) Received: from localhost (mkomu@localhost) by kekkonen.cs.hut.fi (8.13.4+Sun/8.13.3/Submit) with ESMTP id l1LAOKmG012461; Wed, 21 Feb 2007 12:24:20 +0200 (EET) X-Authentication-Warning: kekkonen.cs.hut.fi: mkomu owned process doing -bs Date: Wed, 21 Feb 2007 12:24:20 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Pekka Nikander Subject: Re: [Hipsec] HIP ja loopback In-Reply-To: <11EF9DED-F85C-4171-B786-7DE53B707614@nomadiclab.com> Message-ID: References: <11EF9DED-F85C-4171-B786-7DE53B707614@nomadiclab.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Wed, 21 Feb 2007, Pekka Nikander wrote: >>>> I think the base draft (and neither the mm draft) does not mention the >>>> use of loopback. >>> >>> Simple question: Why would one like to use HIP on a loopback? >> >> One reason is that sometimes services can be local. Connecting to a local >> vs. remote service should not be any different from the user or application >> viewpoint. >> >>> For testing purposes? Maybe. For anything else? I cannot see a reason. >>> IMHO, if a process connects to the same host through a local HIT, it >>> should result in a simple TCP connection / UDP packet, without HIP, since >>> I cannot see how HIP would bring there any benefit. >> >> I think using plain TCP or UDP for loopback in production environments >> would be the best choice but I don't see any text about this in the draft. >> Or maybe I just missed it. > > Right. But that is an issue which is local to the implementation and > transparent to the apps. Hence, I don't see any need to specify it; > different implementations can do it in different ways. Fine. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Feb 21 13:18:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJvdR-0004ve-GR; Wed, 21 Feb 2007 12:52:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJvdO-0004tj-8q for hipsec@ietf.org; Wed, 21 Feb 2007 12:52:06 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJvWL-0002a9-FM for hipsec@ietf.org; Wed, 21 Feb 2007 12:44:50 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 08222212D3C for ; Wed, 21 Feb 2007 19:44:48 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id B0690212D3B for ; Wed, 21 Feb 2007 19:44:47 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v752.3) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <76148728-0D8D-4DFF-988B-16F972F7D4A9@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Wed, 21 Feb 2007 19:44:44 +0200 To: hipsec@ietf.org X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: Subject: [Hipsec] Fwd: Document Action: 'An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)' to Experimental RFC X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org FYI. --Pekka Begin forwarded message: > From: The IESG > Date: 21 February 2007 17:44:49 GMT+02:00 > To: IETF-Announce > Cc: Internet Architecture Board , RFC Editor editor@rfc-editor.org> > Subject: Document Action: 'An IPv6 Prefix for Overlay Routable > Cryptographic Hash Identifiers (ORCHID)' to Experimental RFC > > The IESG has approved the following document: > > - 'An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers > (ORCHID) ' > as an Experimental RFC > > This document has been reviewed in the IETF but is not the product > of an > IETF Working Group. > > The IESG contact person is Jari Arkko. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-laganier-ipv6-khi-07.txt > > Technical Summary > > This document introduces Overlay Routable Cryptographic Hash > Identifiers (ORCHID) as a new, experimental class of IPv6-address- > like identifiers. These identifiers are intended to be used as end- > point identifiers at applications and APIs and not as identifiers > for > network location at the IP layer, i.e., locators. They are designed > to appear as application layer entities and at the existing IPv6 > APIs, but they should not appear in actual IPv6 headers. To make > them > more like vanilla IPv6 addresses, they are expected to be > routable at > an overlay level. Consequently, while they are considered as > non-routable addresses from the IPv6 layer point of view, all > existing IPv6 applications are expected to be able to use them in a > manner compatible with current IPv6 addresses. > > This document requests IANA to allocate a temporary prefix out of > the > IPv6 addressing space for Overlay Routable Cryptographic Hash > Identifiers. > > Working Group Summary > > This proposal comes from Pekka Nikander and Julien Laganier from the > HIP WG, as well as Francis Dupont which has been proposing the > use of > identifiers similar to ORCHIDs in MIP6. This proposal was discussed > both in the HIP WG, the INT area mailing list, and partly during the > ALIEN BOF. > > Protocol Quality > > Jari Arkko has reviewed this specification for the IESG. > > This proposal is currently implemented in all maintained HIP > implementations projects (i.e. OpenHIP , HIP for > Inter.net and HIP for Linux > . > > Geoff Huston (APNIC) has done a thorough review that resulted in the > change from an 8-bits prefix to a 28-bits prefix. This change has > permitted to gain consensus amongst both the IPv6 and Internet > community, and the HIP community. > > A number of people commented this proposal during the IETF > Last Call. One of the issues raised was the conflict with > RFC 4291 rules. Given that an attempt to use another > allocation type would have resulted in significant IETF > work regarding the update of rules for such allocations, > it was decided that it is better to just note the discrepancy > for this experiment. > > Note to RFC Editor > > Please change "returned to IANA in 2027" to "returned > to IANA in 2014" (two occurrences). Similarly, please > change "additional 28-bit functionality" to "additional > functionality". > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Feb 21 13:44:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJwSQ-000259-Pu; Wed, 21 Feb 2007 13:44:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJwSP-00024y-Sw; Wed, 21 Feb 2007 13:44:49 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJwSO-0000ll-Cm; Wed, 21 Feb 2007 13:44:49 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5AD0F198775; Wed, 21 Feb 2007 20:44:47 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id E988C1986AF; Wed, 21 Feb 2007 20:44:46 +0200 (EET) Message-ID: <45DC931F.7070101@piuha.net> Date: Wed, 21 Feb 2007 20:44:47 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Internet Area , HIP References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Subject: [Hipsec] FW: Document Action: 'An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)' to Experimental RFC X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org > The IESG has approved the following document: > > - 'An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers > (ORCHID) ' > as an Experimental RFC > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Jari Arkko. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-laganier-ipv6-khi-07.txt > > Technical Summary > > This document introduces Overlay Routable Cryptographic Hash > Identifiers (ORCHID) as a new, experimental class of IPv6-address- > like identifiers. These identifiers are intended to be used as end- > point identifiers at applications and APIs and not as identifiers for > network location at the IP layer, i.e., locators. They are designed > to appear as application layer entities and at the existing IPv6 > APIs, but they should not appear in actual IPv6 headers. To make them > more like vanilla IPv6 addresses, they are expected to be routable at > an overlay level. Consequently, while they are considered as > non-routable addresses from the IPv6 layer point of view, all > existing IPv6 applications are expected to be able to use them in a > manner compatible with current IPv6 addresses. > > This document requests IANA to allocate a temporary prefix out of the > IPv6 addressing space for Overlay Routable Cryptographic Hash > Identifiers. > > Working Group Summary > > This proposal comes from Pekka Nikander and Julien Laganier from the > HIP WG, as well as Francis Dupont which has been proposing the use of > identifiers similar to ORCHIDs in MIP6. This proposal was discussed > both in the HIP WG, the INT area mailing list, and partly during the > ALIEN BOF. > > Protocol Quality > > Jari Arkko has reviewed this specification for the IESG. > > This proposal is currently implemented in all maintained HIP > implementations projects (i.e. OpenHIP , HIP for > Inter.net and HIP for Linux > . > > Geoff Huston (APNIC) has done a thorough review that resulted in the > change from an 8-bits prefix to a 28-bits prefix. This change has > permitted to gain consensus amongst both the IPv6 and Internet > community, and the HIP community. > > A number of people commented this proposal during the IETF > Last Call. One of the issues raised was the conflict with > RFC 4291 rules. Given that an attempt to use another > allocation type would have resulted in significant IETF > work regarding the update of rules for such allocations, > it was decided that it is better to just note the discrepancy > for this experiment. > > Note to RFC Editor > > Please change "returned to IANA in 2027" to "returned > to IANA in 2014" (two occurrences). Similarly, please > change "additional 28-bit functionality" to "additional > functionality". > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > > > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Feb 25 17:37:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLRyd-00042W-Nj; Sun, 25 Feb 2007 17:36:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLRyc-00042P-HB for hipsec@ietf.org; Sun, 25 Feb 2007 17:36:18 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLRyb-0007MG-7a for hipsec@ietf.org; Sun, 25 Feb 2007 17:36:18 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 549472CC4; Mon, 26 Feb 2007 00:36:14 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.7-niksula20061027 (2006-10-05) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.1.7-niksula20061027 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id BFFA72CC1 for ; Mon, 26 Feb 2007 00:36:13 +0200 (EET) Received: from localhost (mkomu@localhost) by kekkonen.cs.hut.fi (8.13.4+Sun/8.13.3/Submit) with ESMTP id l1PMaDZ0025651 for ; Mon, 26 Feb 2007 00:36:13 +0200 (EET) X-Authentication-Warning: kekkonen.cs.hut.fi: mkomu owned process doing -bs Date: Mon, 26 Feb 2007 00:36:13 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: HIP In-Reply-To: <45C07DEF.6000404@ericsson.com> Message-ID: References: <45C07DEF.6000404@ericsson.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Hipsec] HIP NAT traversal draft X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Hi folks, here is a preversion of the current NAT draft: http://www.iki.fi/miika/docs/draft-ietf-hip-nat-traversal-01-pre1.txt The draft submission DL is on March 5. Please send your comments during this week. Executive summary to earlier versions: * Lots of small corrections from Lauri Silvennoinen * Double NAT scenario is now simplified P.S. Simon Schuetz is going to replace Vivien Schmitt in the forthcoming versions. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec