From hipsec-bounces@lists.ietf.org Mon Apr 02 06:39:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYJwF-000304-FJ; Mon, 02 Apr 2007 06:39:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYJwD-0002wP-GH for hipsec@ietf.org; Mon, 02 Apr 2007 06:39:01 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYJw7-0001Jv-OA for hipsec@ietf.org; Mon, 02 Apr 2007 06:39:01 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1BF9C208F0; Mon, 2 Apr 2007 12:38:51 +0200 (CEST) X-AuditID: c1b4fb3c-aacefbb0000073d5-af-4610dd3a7787 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id EDA3A20008; Mon, 2 Apr 2007 12:38:50 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 12:38:50 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 12:38:50 +0200 Received: from [131.160.36.63] (E000FB0F665DD.lmf.ericsson.se [131.160.36.63]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 778CB2370; Mon, 2 Apr 2007 13:38:50 +0300 (EEST) Message-ID: <4610DD3A.3050400@ericsson.com> Date: Mon, 02 Apr 2007 13:38:50 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: HIP Subject: Re: [Hipsec] WGLC: draft-ietf-hip-applications-00.txt References: <45C07CBD.8040801@ericsson.com> <45D46CA6.8070409@ericsson.com> <45F4544B.6050406@ericsson.com> In-Reply-To: <45F4544B.6050406@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Apr 2007 10:38:50.0625 (UTC) FILETIME=[1A1C7710:01C77513] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: Pekka Nikander 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, at last, we had some people review the draft. There were a set of comments on the list that need to be addressed. When can we expect a revised document addressing those comments? Additionally, I found a few nits: The acronym "HIP" needs to be expanded in the title of the draft. In the abstract: OLD: The Host Identity Protocol and architecture (HIP) proposes NEW: The Host Identity Protocol (HIP) and architecture proposes There are a few acronyms (e.g., DHT) that need to be expanded on their first use. Others (e.g., API) are probably well known and do not need to be expanded. The Terminology section should include the acronyms of the terms that are defined there (i.e., HIT, LSI). The draft does not have the mandatory IANA Considerations section. It should. References should be divided into Normative and Informative. Alternatively, given that this will be an informational draft, the References Section could be renamed as Informative References. Cheers, Gonzalo Gonzalo Camarillo wrote: > Folks, > > during the month this WGLC has lasted, we have not received a single > comment on the document, even though I sent a reminder half-way through > the WGLC. It seems that the WG is not interested in completing the items > we added to our charter after requesting the publication of our original > chartered items. > > I would like to get at least two volunteers for each of our new charter > items to perform dedicated reviews. This will ensure that we make some > progress in our charter. > > Please, if you would like to volunteer to perform a dedicated (thorough) > review of one (or more) of our chartered items, send an email to the > chairs. > > Thanks, > > Gonzalo > HIP co-chair > > > Gonzalo Camarillo wrote: >> 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 From hipsec-bounces@lists.ietf.org Mon Apr 02 17:02:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYTeh-0003CU-03; Mon, 02 Apr 2007 17:01:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYTee-00036Y-P1 for hipsec@ietf.org; Mon, 02 Apr 2007 17:01:32 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYTea-0007xj-0u for hipsec@ietf.org; Mon, 02 Apr 2007 17:01:32 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l32L1Gkk008914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Apr 2007 14:01:16 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l32L1FAf008001; Mon, 2 Apr 2007 14:01:16 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l32L1EDa007942; Mon, 2 Apr 2007 14:01:15 -0700 (PDT) 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, 2 Apr 2007 14:01:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] WGLC: draft-ietf-hip-applications-00.txt Date: Mon, 2 Apr 2007 14:01:14 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D040491F9@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <4610DD3A.3050400@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] WGLC: draft-ietf-hip-applications-00.txt Thread-Index: Acd1ExxDybK3ldMQRNuA5IrGEUGLnwATUXxQ From: "Henderson, Thomas R" To: "Gonzalo Camarillo" , "HIP" X-OriginalArrivalTime: 02 Apr 2007 21:01:14.0796 (UTC) FILETIME=[0CF8BEC0:01C7756A] X-Spam-Score: 0.0 (/) X-Scan-Signature: e06437eb72f6703f11713d345be8298a Cc: Pekka Nikander , Alberto Garcia 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 Gonzalo, I will publish an -01 version this week, if there are no further comments. Below is how I propose to address the remaining comments that have come in the past two weeks. Also, here is one section of text that needs to be updated with the publication of ORCHID; I'll clean it up: " Depending on how HITs are ultimately defined, it may be hard for a system to distinguish between a HIT and a routable IPv6 address. Elsewhere it has been proposed [7] that HITs be precluded from using highest-ordered bits that correspond to IPv6 addresses, so that at least in the near term, a system could differentiate between a HIT and an IPv6 address by inspection." Let me first address the localhost comments by Miika and Shinta: > -----Original Message----- > From: Miika Komu [mailto:miika@iki.fi]=20 > Sent: Thursday, March 15, 2007 12:01 AM > To: Henderson, Thomas R > Cc: Pekka Nikander; HIP > Subject: RE: [Hipsec] WGLC: draft-ietf-hip-applications-00.txt >=20 > On Wed, 14 Mar 2007, Henderson, Thomas R wrote: >=20 > > I propose: "This method will not necessarily reveal to the user of > > the legacy application that HIP is being used." >=20 > Ok. >=20 > >>> 3.2. Using DNS > >> > >> getaddrinfo DNS resolver is defined in rfc3493 and says that > >> NULL host > >> name refers to the localhost. Is there any differences in local vs. > >> remote host name resolution? Or in the use of local vs. > >> remote host names? > > > > I am not sure what you would like to see stated. If=20 > nodename is null, > > then you are connecting to yourself, and I suppose that a=20 > system could > > use HIP in a loopback fashion in that way, but I don't know the use > > case. I had in mind the non-null case-- do you think it needs to be > > described to that detail? >=20 > Actually the section name is "Using DNS" and since the name=20 > is obtained=20 > locally, it is not relevant for the section. Resolution of=20 > local HITs is=20 > actually more related to my following comment. See below. >=20 > >> The draft does not mention explicitly the use ipv4 and=20 > ipv6 wildcard > >> addresses at the server side. Maybe something like this could > >> be added? > >> > >> The wildcard addresses accept both non-HIP and HIP based > >> connections, > >> and especially the ipv6 wildcard can be used also for=20 > ipv4 traffic > >> [RFC3493]. Depending on the implementation, sockets bound > >> explicitly to > >> an locator may or may not accept HIP based communications > >> as defined in > >> Section 3.1. > > > > I would be fine with adding that-- where do you think it belongs? >=20 > I would prefer a new section 3.4, or alternatively, to the=20 > end of section=20 > 3.1. I would like to propose some concrete text about local name=20 > resolution also. My proposal is based on the observation that=20 > all of the=20 > current implementations are using some kind of a virtual=20 > interface with=20 > LSIs or HITs: >=20 > When getaddrinfo [RFC3493] resolver is used for resolving local > addresses, it may also return HITs or LSIs. An application=20 > that binds > to such an HIP-based identifier, may not be able to accept non-HIP > based communications. In addition, the system may have=20 > several HITs. > Naturally, an application that binds to a single HIT cannot accept > connections that use the other HITs of the system. >=20 > --=20 > Miika Komu =20 > http://www.iki.fi/miika/ > =20 > -----Original Message----- > From: Shinta Sugimoto [mailto:shinta@sfc.wide.ad.jp]=20 > Sent: Friday, March 16, 2007 12:00 AM > To: Henderson, Thomas R; Pekka Nikander > Cc: hipsec@ietf.org > Subject: Re: [Hipsec] WGLC: draft-ietf-hip-applications-00.txt >=20 > Hello, >=20 > I read the draft-ietf-hip-applications-00.txt. Overall, I found the > document easy to read (I mean its readability is high). > The followings are my comments: >=20 > Substantial: >=20 > - I found that Section 3 was primarily focusing on behavior of client > host which is in many cases HIP initiator. I mean, Section 3 gives > detail descriptions about how connect() system call is used by client > and how remote host identifier is treated. But there is no=20 > description > about treatment of local host identifier. Some application may call > bind() system call to bind a socket to a specific local address. > So I think it is better to add some description in Section 3=20 > how system > can/should behave in terms of local address management so that legacy > application can make use of HIP, IMHO. I expect it is done in the > same way as remote address management though. I propose the following text to try to address the above concerns: "3.4. Local address management =20 The previous sections focused mainly on client behavior (HIP initiator). We must also consider the behavior for servers. Typically, a server may bind to a wildcard IP address and well-known port. In the case of HIP use with legacy server implementations, there are again a few options. As in Section 3.1 above, the system may be configured manually to always, optionally (depending on the client behavior), or never use=20 HIP with a particular service, as a matter of policy, when the server specifies a wildcard (IP) address. When getaddrinfo [RFC3493] resolver is used for resolving local addresses, it may also return HITs or LSIs, if the system has assigned HITs or LSIs to internal virtual interfaces (common in many HIP=20 implementations). The application may use such identifiers as addresses in subsequent socket calls.=20 Some applications may call bind() to bind a socket to a specific local address. If the local address specified is an IP address, again, the underlying system may be configured to still use HIP. If the local address specified is a HIT (Section 3.3), the system should enforce that connections can only come to the specified HIT. If a=20 system has many HITs, an application that binds to a single HIT cannot accept connections to the other HITs in the system. It may be possible for a system to specify a special ORCHID value as a local HIT wildcard value, if such wildcarding among local HIs is desired. =20 When a host has multiple HIs and the socket behavior does not prescribe the use of any particular HI as a source identifier, it is a matter of local policy as to how to select a HI to serve as a source identifier." >=20 > - Secondly, I have a question as follows, which is related to the > above comment. I assume that the source identifier would be selected > by either: > 1) source address selection performed by the kernel based on=20 > RFC 3484, or > 2) explicitly specified by bind() > In the case of 1), is there any requirements/recommendation=20 > from HIP to > RFC 3484 with regard to the treatment of HIT? In particular, if we > have ORCHID, how does it influence RFC 3484? That topic seems to me to be outside of the scope of this draft, and probably needs to go into a future multihoming document. =20 > Editorial: >=20 > - Section 3.3, there is a redundant "and" in the first sentence. >=20 OK > -----Original Message----- > From: Alberto Garcia [mailto:Alberto.Garcia@hiit.fi]=20 > Sent: Thursday, March 15, 2007 7:05 AM > To: Henderson, Thomas R > Cc: hipsec@lists.ietf.org > Subject: RE: [Hipsec] WGLC: draft-ietf-hip-applications-00.txt >=20 > Hello again Tom, >=20 > I'm glad that you're interested in my comments. So now I'd=20 > like to discuss some > of your responses: >=20 > > > 3) In general, there is some ambiguity in the usage of the > > > terms host identity, > > > host identifier and host identity tag. > > I do not think there is ambiguity here, but perhaps=20 > inconsistency in use of > > acronym? I am not sure all of these need to be compacted,=20 > since it seems to > > read better to me to spell out "host identities" sometimes. >=20 > I think I didn't explain it correctly. Actually "ambiguity"=20 > was not the right > word to use here. What I meant is that in=20 > http://www.ietf.org/rfc/rfc4423.txt , > page 5, it is defined: > "Host Identity: An abstract concept assigned to a 'computing=20 > platform'. See > 'Host Identifier', below." > "Host Identifier: A public key used as a name for a Host Identity." > In my opinion we should avoid using Host Identity for=20 > something else than the > host itself, since it is "an abstract concept". Then I=20 > suggest to use the term > Host Identifier or HI -previously defined in section 2- when=20 > talking about > mapping IP addresses into HI, and things related to DNS. I see your point, and will clean it up with respect to host identifier terminology. >=20 > > > 5)In "3.2. Using DNS": > > > It seems strange the repetition of the same title just three > > > paragraphs before. > > > I could suggest "3.2. Returning HIs directly from the name > > > resolution process", > > > or something similar. > > > > How about "Using DNS names in applications" to parallel 3.1's title? >=20 > How about in 3.1: "Using DNS to map IPs to HIs"? > As you know, the difference between 3.1 and 3.2 is that: > - in 3.1: domain name -> IP address -> HI > - in 3.2: domain name -> HI > Symbol -> means mapping. I think this difference should be=20 > clearly stated in the > section titles. OK, I will change 3.1 to "Using DNS to map IPs to HIs" and 3.2 to "Using DNS to map domain names to HIs" >=20 > > > [...] to return a Local Scope Identifier (LSI) or Host > > > Identity Tag (HIT) rather > > > than an IP [...] > > > s/Local Scope Identifier (LSI) or Host Identity Tag (HIT)/LSI > > > or HIT -- as > > > they are defined in section 2. > > > > At this point in the text, LSI acronym has not yet been=20 > used. I agree that > > HIT doesn't need to be spelled out here. >=20 > Actually LSI can be defined in section 2: "Local Scope=20 > Identifier (LSI): A 32- > or 128-bit quantity locally [...]". OK >=20 > > > [...] It may be possible for an LSI or HIT to be routable or > > > resolvable, but > > > such a case may not have the level of security in the binding > > > to host identity > > > that a HIT has with the host identity. [...] > > > This sentence is somehow confusing, please consider rewriting it. > > > > How about changing this paragraph: > > > > " It may be possible for an LSI or HIT to be routable or=20 > resolvable, > > but such a case may not have the level of security in=20 > the binding to > > host identity that a HIT has with the host identity. =20 > For example, a > > special IP address that has some location invariance is the > > identifier-address discussed in [6]. In general, LSIs and HITs > > considered to date for HIP have been non-routable." > > > > to this: > > > > " It may be possible for an LSI or HIT to be routable or=20 > resolvable, > > either directly or on an overlay. For example, a > > special IP address that has some location invariance is the > > identifier-address discussed in [6]. A term other than=20 > LSI may be > > needed for these routable identifiers, since they would > > no longer be locally scoped. When using DNS, returning=20 > a routable > > identifier would avoid the aforementioned problems with=20 > referrals. > > However, the cost of routability may be that the hash binding > > between the routable identifier and the host identity would be > > weakened, since more bits may be allocated to the hierarchy." >=20 > Yes, much clearer now. BTW, here, the term "host identity" is=20 > applicable in my > opinion. OK, agree. > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 > Sent: Monday, April 02, 2007 3:39 AM > To: HIP > Cc: Pekka Nikander; Henderson, Thomas R; David Ward > Subject: Re: [Hipsec] WGLC: draft-ietf-hip-applications-00.txt >=20 >=20 > Additionally, I found a few nits: >=20 > The acronym "HIP" needs to be expanded in the title of the draft. OK >=20 > In the abstract: > OLD: > The Host Identity Protocol and architecture (HIP) proposes >=20 > NEW: > The Host Identity Protocol (HIP) and architecture proposes OK >=20 > There are a few acronyms (e.g., DHT) that need to be expanded=20 > on their=20 > first use. Others (e.g., API) are probably well known and do=20 > not need to=20 > be expanded. OK, will do a check. >=20 > The Terminology section should include the acronyms of the terms that=20 > are defined there (i.e., HIT, LSI). OK. >=20 > The draft does not have the mandatory IANA Considerations section. It=20 > should. OK. Will add a new section that states "This document has no actions for IANA." >=20 > References should be divided into Normative and Informative.=20 > Alternatively, given that this will be an informational draft, the=20 > References Section could be renamed as Informative References. Will rename to Informative References. Thanks to all who provided comments, Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Apr 04 04:59:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ1Jo-0008Ks-5X; Wed, 04 Apr 2007 04:58:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ1Jn-0008Km-EO for hipsec@ietf.org; Wed, 04 Apr 2007 04:58:15 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ1Ji-0005MU-Rv for hipsec@ietf.org; Wed, 04 Apr 2007 04:58:15 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 1829F2CAA; Wed, 4 Apr 2007 11:58:10 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.8-niksula20070322 (2007-02-13) 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.8-niksula20070322 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 328F92C8C; Wed, 4 Apr 2007 11:58:09 +0300 (EEST) Date: Wed, 4 Apr 2007 11:58:09 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Philip Matthews Subject: Re: [Hipsec] Re: Comments on draft-ietf-hip-nat-traversal-01.txt In-Reply-To: Message-ID: References: <200703300912.56273.joakim.koskela@hiit.fi> <200703301642.49142.joakim.koskela@hiit.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 Fri, 30 Mar 2007, Philip Matthews wrote: Hi Philip, I agree with the rest of the comments and I still think that integration with ICE is useful, but can you clarify some things? If understood correctly, the main benefits of integrating ICE with the current approach are related to end-host multihoming and to the address selection procedures? The current draft already defines the behaviour with hairpinning and TURN relays, but what is exactly missing or could be improved? (I still need more work with ICE and STUN documentation.) > > I think it would be best to do the following: > > > > * use the relay immediately for IPsec traffic > > * start ICE-like probing of address candidates > > * switch to the workable pairs of address candidates (UPDATE > > handover) > > if any were found, otherwise stick to the relay > > > > This way, the initial connection delay observed by the application is > > smaller as it can already start sending data through the relay. > > ICE used to work in a similar manner, up until the -10 version. This > has the problem though that there will ALWAYS be a burst of packets > through the > TURN relay, and then you will switch away from the relay to a direct > path. This puts a lot of load on your TURN server if 100's or 1000's of > nodes to this, and it will also lead to packet reordering problems > unless there is a > higher-level protocol (like TCP) to take care of this problem. > > My suggestion is to just accept the delay the occurs until a direct path > is found. Agree, the burst of packets may not be a nice thing for the TURN relays. However, I would like to avoid the initial delay in most cases. The 01 version of the draft does not introduce the delay because the UDP hole punching occurs using the HIP base exchange and some additional NOTIFYs. This makes me wonder if we could have a some kind of hybrid approach where we minimize initial connection set-up, try direct data channel and fallback to the relay only after ICE-style probing fails. If the probing fails, it can result in TCP timeouts because ESP packets are dropped. However, I think this would be a reasonable tradeoff because the relay is needed in the most cases. > Some general comments: > > First of all, I would recommend working out most of the details without > worrying about media relays. Media relays will be easy to add once the other > details are known. Also note that BOTH ends must be behind a > non-endpoint-dependent NAT before a TURN relay is needed, and statistically > less than 10% of all NATs fall into the category (according to research done > at Cornell), which means less than 1% of connection attempts will need a TURN > relay. This was actually surprise to me. I thought that only a single endpoint-dependent NAT on the path would necessitate a TURN relay. Does this mean that the current NAT traversal draft also would work without the TURN-like relay with a probability of 99 procent? May I ask where did this 10 % come from? I am getting a little mismatching information. I wonder if it the same paper from Guha et al. The paper below estimates that 70.1% of the deployed NATs support endpoint independent filtering in the wild (table 6): http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat.pdf I counted from the online survey that 141 of 218 of the currently tested NAT devices support endpoint independent mappings: https://www.guha.cc/saikat/stunt-results.php? And of course, there is the recommendation from IETF to consider for future NAT manufacturers: ftp://ftp.rfc-editor.org/in-notes/rfc4787.txt Also, do you think that we should use STUN as it is for detecting initially whether the host is behind a NAT or not? Or would it be better to use HIP based STUN mechanism (with e.g. RVS). -- 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 Apr 04 08:21:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ4UD-0008Pn-4p; Wed, 04 Apr 2007 08:21:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ4UB-0008Pi-F5 for hipsec@ietf.org; Wed, 04 Apr 2007 08:21:11 -0400 Received: from mx5-4.spamtrap.magma.ca ([209.217.78.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ4U8-000628-Ok for hipsec@ietf.org; Wed, 04 Apr 2007 08:21:11 -0400 Received: from mail4.magma.ca (mail4.internal.magma.ca [10.0.10.14]) by mx5-4.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l34CL69q008240; Wed, 4 Apr 2007 08:21:06 -0400 Received: from [10.0.1.3] ([24.139.16.154]) (authenticated bits=0) by mail4.magma.ca (Magma's Mail Server) with ESMTP id l34CL1b9011957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 4 Apr 2007 08:21:06 -0400 In-Reply-To: References: <200703300912.56273.joakim.koskela@hiit.fi> <200703301642.49142.joakim.koskela@hiit.fi> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Hipsec] Re: Comments on draft-ietf-hip-nat-traversal-01.txt Date: Wed, 4 Apr 2007 08:21:33 -0400 To: Miika Komu X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f 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 [Private reply.] I think it is best for us to talk about this in a phone call. I find e-mail to be a poor way to communicate complex ideas like this. I am busy this week, but next week should be good for me. I think that either Tuesday or Wednesday next week would work for me. We could do the phone call at 9h00 Ottawa time, which is 16h00 Helsinki time. Let me know what works for you. I will try to reply on-list to a few of your points below. - Philip On 4-Apr-07, at 04:58 , Miika Komu wrote: > On Fri, 30 Mar 2007, Philip Matthews wrote: > > Hi Philip, > > I agree with the rest of the comments and I still think that > integration with ICE is useful, but can you clarify some things? > > If understood correctly, the main benefits of integrating ICE with > the current approach are related to end-host multihoming and to the > address selection procedures? The current draft already defines the > behaviour with hairpinning and TURN relays, but what is exactly > missing or could be improved? (I still need more work with ICE and > STUN documentation.) > >> > I think it would be best to do the following: >> > >> > * use the relay immediately for IPsec traffic >> > * start ICE-like probing of address candidates >> > * switch to the workable pairs of address candidates (UPDATE > >> handover) >> > if any were found, otherwise stick to the relay >> > >> > This way, the initial connection delay observed by the >> application is >> > smaller as it can already start sending data through the relay. >> >> ICE used to work in a similar manner, up until the -10 version. This >> has the problem though that there will ALWAYS be a burst of >> packets through the >> TURN relay, and then you will switch away from the relay to a >> direct path. This puts a lot of load on your TURN server if 100's >> or 1000's of nodes to this, and it will also lead to packet >> reordering problems unless there is a >> higher-level protocol (like TCP) to take care of this problem. >> >> My suggestion is to just accept the delay the occurs until a >> direct path is found. > > Agree, the burst of packets may not be a nice thing for the TURN > relays. However, I would like to avoid the initial delay in most > cases. The 01 version of the draft does not introduce the delay > because the UDP hole punching occurs using the HIP base exchange > and some additional NOTIFYs. > > This makes me wonder if we could have a some kind of hybrid > approach where we minimize initial connection set-up, try direct > data channel and fallback to the relay only after ICE-style probing > fails. If the probing fails, it can result in TCP timeouts because > ESP packets are dropped. However, I think this would be a > reasonable tradeoff because the relay is needed in the most cases. > >> Some general comments: >> >> First of all, I would recommend working out most of the details >> without worrying about media relays. Media relays will be easy to >> add once the other details are known. Also note that BOTH ends >> must be behind a non-endpoint-dependent NAT before a TURN relay is >> needed, and statistically less than 10% of all NATs fall into the >> category (according to research done at Cornell), which means less >> than 1% of connection attempts will need a TURN relay. > > This was actually surprise to me. I thought that only a single > endpoint-dependent NAT on the path would necessitate a TURN relay. > Does this mean that the current NAT traversal draft also would work > without the TURN-like relay with a probability of 99 procent? > > May I ask where did this 10 % come from? I am getting a little > mismatching information. I wonder if it the same paper from Guha et > al. The paper below estimates that 70.1% of the deployed NATs > support endpoint independent filtering in the wild (table 6): > > http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat.pdf > > I counted from the online survey that 141 of 218 of the currently > tested NAT devices support endpoint independent mappings: > > https://www.guha.cc/saikat/stunt-results.php? > > And of course, there is the recommendation from IETF to consider > for future NAT manufacturers: > > ftp://ftp.rfc-editor.org/in-notes/rfc4787.txt > > > Also, do you think that we should use STUN as it is for detecting > initially whether the host is behind a NAT or not? Or would it be > better to use HIP based STUN mechanism (with e.g. RVS). > > -- > 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 Apr 04 08:57:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ52i-0002pV-Fr; Wed, 04 Apr 2007 08:56:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ52h-0002lA-Md for hipsec@ietf.org; Wed, 04 Apr 2007 08:56:51 -0400 Received: from mx4-3.spamtrap.magma.ca ([209.217.78.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ52f-0007sN-2i for hipsec@ietf.org; Wed, 04 Apr 2007 08:56:51 -0400 Received: from mail2.magma.ca (mail2.internal.magma.ca [10.0.10.12]) by mx4-3.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l34CuiJn026767; Wed, 4 Apr 2007 08:56:44 -0400 Received: from [10.0.1.3] ([24.139.16.154]) (authenticated bits=0) by mail2.magma.ca (Magma's Mail Server) with ESMTP id l34CugHY017756 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 4 Apr 2007 08:56:44 -0400 In-Reply-To: References: <200703300912.56273.joakim.koskela@hiit.fi> <200703301642.49142.joakim.koskela@hiit.fi> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Hipsec] Re: Comments on draft-ietf-hip-nat-traversal-01.txt Date: Wed, 4 Apr 2007 08:57:13 -0400 To: Miika Komu X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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 4-Apr-07, at 04:58 , Miika Komu wrote: > On Fri, 30 Mar 2007, Philip Matthews wrote: [Snip] > > >> > I think it would be best to do the following: >> > >> > * use the relay immediately for IPsec traffic >> > * start ICE-like probing of address candidates >> > * switch to the workable pairs of address candidates (UPDATE > >> handover) >> > if any were found, otherwise stick to the relay >> > >> > This way, the initial connection delay observed by the >> application is >> > smaller as it can already start sending data through the relay. >> >> ICE used to work in a similar manner, up until the -10 version. This >> has the problem though that there will ALWAYS be a burst of >> packets through the >> TURN relay, and then you will switch away from the relay to a >> direct path. This puts a lot of load on your TURN server if 100's >> or 1000's of nodes to this, and it will also lead to packet >> reordering problems unless there is a >> higher-level protocol (like TCP) to take care of this problem. >> >> My suggestion is to just accept the delay the occurs until a >> direct path is found. > > Agree, the burst of packets may not be a nice thing for the TURN > relays. However, I would like to avoid the initial delay in most > cases. The 01 version of the draft does not introduce the delay > because the UDP hole punching occurs using the HIP base exchange > and some additional NOTIFYs. > > This makes me wonder if we could have a some kind of hybrid > approach where we minimize initial connection set-up, try direct > data channel and fallback to the relay only after ICE-style probing > fails. If the probing fails, it can result in TCP timeouts because > ESP packets are dropped. However, I think this would be a > reasonable tradeoff because the relay is needed in the most cases. Yes, there is a delay issue with ICE. The latest draft versions reduce this somewhat, by increasing the rate that address pairs are tried. There are also tricks, like pre-gathering candidates, that can be used to speed things up. However, there is already a delay with HIP as defined today, because of the key exchange and the puzzle computation. [snip] > > This was actually surprise to me. I thought that only a single > endpoint-dependent NAT on the path would necessitate a TURN relay. ICE will find a direct path if one end is behind an address-and-port- dependent mapping/filtering NAT if the NAT has only a single public address (the common case), and the other end is behind an endpoint- independent-mapping/address-dependent-filtering NAT. > Does this mean that the current NAT traversal draft also would work > without the TURN-like relay with a probability of 99 procent? I don't know exactly how frequently the approach in draft-ietf-hip- nat-traversal-01 will fail. However, I know that the general approach of using STUN alone was not reliable enough -- hence the development of ICE. (The start of the ICE work pre-dates my involvement in this area, so I have not seen precise figures, but I can draw you a number of network diagrams where STUN alone does not work) [snip] > > Also, do you think that we should use STUN as it is for detecting > initially whether the host is behind a NAT or not? Or would it be > better to use HIP based STUN mechanism (with e.g. RVS). Not sure what you mean by this, but I will comment that no one has yet found a NAT property detection algorithm that is 100% reliable. Even the test "am I behind a NAT" is not 100% reliable. However, it is possible that the error cases will drop as the IETF recommendations on NATs become more widely implemented. - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Apr 04 09:21:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ5Py-0003jL-CE; Wed, 04 Apr 2007 09:20:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ5Pw-0003jF-6Z for hipsec@ietf.org; Wed, 04 Apr 2007 09:20:52 -0400 Received: from mx1-3.spamtrap.magma.ca ([209.217.78.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ5Pl-0006CP-Fl for hipsec@ietf.org; Wed, 04 Apr 2007 09:20:52 -0400 Received: from mail4.magma.ca (mail4.internal.magma.ca [10.0.10.14]) by mx1-3.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l34DKbJE006396; Wed, 4 Apr 2007 09:20:37 -0400 Received: from [10.0.1.3] ([24.139.16.154]) (authenticated bits=0) by mail4.magma.ca (Magma's Mail Server) with ESMTP id l34DKZ9p032459 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 4 Apr 2007 09:20:37 -0400 In-Reply-To: References: <200703300912.56273.joakim.koskela@hiit.fi> <200703301642.49142.joakim.koskela@hiit.fi> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Hipsec] Re: Comments on draft-ietf-hip-nat-traversal-01.txt Date: Wed, 4 Apr 2007 09:21:08 -0400 To: Philip Matthews X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 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 Whoops. My apologies for bothering the list with the message below, which I had meant to send only to Miika. - Philip On 4-Apr-07, at 08:21 , Philip Matthews wrote: > [Private reply.] > > I think it is best for us to talk about this in a phone call. I > find e-mail to be a poor way to communicate complex ideas like > this. I am busy this week, but next week should be good for me. I > think that either Tuesday or Wednesday next week would work for me. > We could do the phone call at 9h00 Ottawa time, which is 16h00 > Helsinki time. Let me know what works for you. > > I will try to reply on-list to a few of your points below. > > - Philip > > On 4-Apr-07, at 04:58 , Miika Komu wrote: > >> On Fri, 30 Mar 2007, Philip Matthews wrote: >> >> Hi Philip, >> >> I agree with the rest of the comments and I still think that >> integration with ICE is useful, but can you clarify some things? >> >> If understood correctly, the main benefits of integrating ICE with >> the current approach are related to end-host multihoming and to >> the address selection procedures? The current draft already >> defines the behaviour with hairpinning and TURN relays, but what >> is exactly missing or could be improved? (I still need more work >> with ICE and STUN documentation.) >> >>> > I think it would be best to do the following: >>> > >>> > * use the relay immediately for IPsec traffic >>> > * start ICE-like probing of address candidates >>> > * switch to the workable pairs of address candidates (UPDATE >>> > handover) >>> > if any were found, otherwise stick to the relay >>> > >>> > This way, the initial connection delay observed by the >>> application is >>> > smaller as it can already start sending data through the relay. >>> >>> ICE used to work in a similar manner, up until the -10 version. >>> This >>> has the problem though that there will ALWAYS be a burst of >>> packets through the >>> TURN relay, and then you will switch away from the relay to a >>> direct path. This puts a lot of load on your TURN server if 100's >>> or 1000's of nodes to this, and it will also lead to packet >>> reordering problems unless there is a >>> higher-level protocol (like TCP) to take care of this problem. >>> >>> My suggestion is to just accept the delay the occurs until a >>> direct path is found. >> >> Agree, the burst of packets may not be a nice thing for the TURN >> relays. However, I would like to avoid the initial delay in most >> cases. The 01 version of the draft does not introduce the delay >> because the UDP hole punching occurs using the HIP base exchange >> and some additional NOTIFYs. >> >> This makes me wonder if we could have a some kind of hybrid >> approach where we minimize initial connection set-up, try direct >> data channel and fallback to the relay only after ICE-style >> probing fails. If the probing fails, it can result in TCP timeouts >> because ESP packets are dropped. However, I think this would be a >> reasonable tradeoff because the relay is needed in the most cases. >> >>> Some general comments: >>> >>> First of all, I would recommend working out most of the details >>> without worrying about media relays. Media relays will be easy to >>> add once the other details are known. Also note that BOTH ends >>> must be behind a non-endpoint-dependent NAT before a TURN relay >>> is needed, and statistically less than 10% of all NATs fall into >>> the category (according to research done at Cornell), which means >>> less than 1% of connection attempts will need a TURN relay. >> >> This was actually surprise to me. I thought that only a single >> endpoint-dependent NAT on the path would necessitate a TURN relay. >> Does this mean that the current NAT traversal draft also would >> work without the TURN-like relay with a probability of 99 procent? >> >> May I ask where did this 10 % come from? I am getting a little >> mismatching information. I wonder if it the same paper from Guha >> et al. The paper below estimates that 70.1% of the deployed NATs >> support endpoint independent filtering in the wild (table 6): >> >> http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat.pdf >> >> I counted from the online survey that 141 of 218 of the currently >> tested NAT devices support endpoint independent mappings: >> >> https://www.guha.cc/saikat/stunt-results.php? >> >> And of course, there is the recommendation from IETF to consider >> for future NAT manufacturers: >> >> ftp://ftp.rfc-editor.org/in-notes/rfc4787.txt >> >> >> Also, do you think that we should use STUN as it is for detecting >> initially whether the host is behind a NAT or not? Or would it be >> better to use HIP based STUN mechanism (with e.g. RVS). >> >> -- >> Miika Komu http://www.iki.fi/ >> miika/ > > > _______________________________________________ > 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 Thu Apr 05 01:12:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZKGE-000198-Do; Thu, 05 Apr 2007 01:11:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZKGD-00017J-5D for hipsec@ietf.org; Thu, 05 Apr 2007 01:11:49 -0400 Received: from mail.sfc.wide.ad.jp ([2001:200:0:8803:203:47ff:fedf:73a6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZKG7-00037y-Vx for hipsec@ietf.org; Thu, 05 Apr 2007 01:11:49 -0400 Received: from [10.0.0.3] (unknown [61.196.102.216]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id AF6124D992; Thu, 5 Apr 2007 14:11:23 +0900 (JST) Date: Thu, 05 Apr 2007 14:11:12 +0900 From: Shinta Sugimoto To: "Henderson, Thomas R" Subject: Re: [Hipsec] WGLC: draft-ietf-hip-applications-00.txt In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D040491F9@XCH-NW-5V1.nw.nos.boeing.com> References: <4610DD3A.3050400@ericsson.com> <77F357662F8BFA4CA7074B0410171B6D040491F9@XCH-NW-5V1.nw.nos.boeing.com> Message-Id: <20070405131959.50AD.SHINTA@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.25.02 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: Alberto Garcia , 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 Thoams, Please find my response inline. On Mon, 2 Apr 2007 14:01:14 -0700 "Henderson, Thomas R" wrote: > Gonzalo, > > I will publish an -01 version this week, if there are no further > comments. Below is how I propose to address the remaining comments that > have come in the past two weeks. > > Also, here is one section of text that needs to be updated with the > publication of ORCHID; I'll clean it up: > > " Depending on how HITs are ultimately defined, it may be hard for a > system to distinguish between a HIT and a routable IPv6 address. > Elsewhere it has been proposed [7] that HITs be precluded from using > highest-ordered bits that correspond to IPv6 addresses, so that at > least in the near term, a system could differentiate between a HIT > and an IPv6 address by inspection." > > Let me first address the localhost comments by Miika and Shinta: > [snip] > > -----Original Message----- > > From: Shinta Sugimoto [mailto:shinta@sfc.wide.ad.jp] > > Sent: Friday, March 16, 2007 12:00 AM > > To: Henderson, Thomas R; Pekka Nikander > > Cc: hipsec@ietf.org > > Subject: Re: [Hipsec] WGLC: draft-ietf-hip-applications-00.txt > > > > Hello, > > > > I read the draft-ietf-hip-applications-00.txt. Overall, I found the > > document easy to read (I mean its readability is high). > > The followings are my comments: > > > > Substantial: > > > > - I found that Section 3 was primarily focusing on behavior of client > > host which is in many cases HIP initiator. I mean, Section 3 gives > > detail descriptions about how connect() system call is used by client > > and how remote host identifier is treated. But there is no > > description > > about treatment of local host identifier. Some application may call > > bind() system call to bind a socket to a specific local address. > > So I think it is better to add some description in Section 3 > > how system > > can/should behave in terms of local address management so that legacy > > application can make use of HIP, IMHO. I expect it is done in the > > same way as remote address management though. > > I propose the following text to try to address the above concerns: > > "3.4. Local address management > > The previous sections focused mainly on client behavior (HIP > initiator). > We must also consider the behavior for servers. Typically, a server > may bind to a wildcard IP address and well-known port. In the case > of HIP use with legacy server implementations, there are again a few > options. As in Section 3.1 above, the system may be configured > manually > to always, optionally (depending on the client behavior), or never > use > HIP with a particular service, as a matter of policy, when the server > specifies a wildcard (IP) address. > > When getaddrinfo [RFC3493] resolver is used for resolving local > addresses, it may also return HITs or LSIs, if the system has > assigned > HITs or LSIs to internal virtual interfaces (common in many HIP > implementations). The application may use such identifiers as > addresses in subsequent socket calls. > > Some applications may call bind() to bind a socket to a specific > local address. If the local address specified is an IP address, > again, the underlying system may be configured to still use HIP. If > the local address specified is a HIT (Section 3.3), the system should > enforce that connections can only come to the specified HIT. If a > system has many HITs, an application that binds to a single HIT > cannot accept connections to the other HITs in the system. It may > be possible for a system to specify a special ORCHID value as a local > HIT wildcard value, if such wildcarding among local HIs is desired. > > When a host has multiple HIs and the socket behavior does not > prescribe > the use of any particular HI as a source identifier, it is a matter > of local policy as to how to select a HI to serve as a source > identifier." Ok, I think the above texts are fine and useful for users (application programmers). > > > > > > - Secondly, I have a question as follows, which is related to the > > above comment. I assume that the source identifier would be selected > > by either: > > 1) source address selection performed by the kernel based on > > RFC 3484, or > > 2) explicitly specified by bind() > > In the case of 1), is there any requirements/recommendation > > from HIP to > > RFC 3484 with regard to the treatment of HIT? In particular, if we > > have ORCHID, how does it influence RFC 3484? > > > That topic seems to me to be outside of the scope of this draft, and > probably needs to go into a future multihoming document. Ok. > > > Editorial: > > > > - Section 3.3, there is a redundant "and" in the first sentence. > > > > OK I personally see no more issues in the draft. Thanks for the clarification. [rest of the original email was snipped] Regards, Shinta _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Apr 10 15:50:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbMM1-000775-Jo; Tue, 10 Apr 2007 15:50:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbMM0-00076s-N5; Tue, 10 Apr 2007 15:50:12 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbMM0-0000kb-Dw; Tue, 10 Apr 2007 15:50:12 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 5C71226EA2; Tue, 10 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HbMLq-0002ma-74; Tue, 10 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 10 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: hipsec@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-applications-01.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 the Host Identity Protocol with Legacy Applications Author(s) : T. Henderson, P. Nikander Filename : draft-ietf-hip-applications-01.txt Pages : 15 Date : 2007-4-10 The Host Identity Protocol (HIP) and architecture proposes to add a cryptographic name space for network stack names. From an application viewpoint, HIP-enabled systems support a new address family of host identifiers, but it may be a long time until such HIP- aware applications are widely deployed even if host systems are upgraded. This informational document discusses implementation and API issues relating to using HIP in situations in which the system is HIP-aware but the applications are not. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-applications-01.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-applications-01.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-applications-01.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-4-10140827.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-applications-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-applications-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-10140827.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 Apr 13 15:50:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcRmZ-0007F6-0f; Fri, 13 Apr 2007 15:50:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcRmU-0007DR-NO; Fri, 13 Apr 2007 15:50:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcRmU-0002KN-Ej; Fri, 13 Apr 2007 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 344C126E9D; Fri, 13 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HcRmT-0006sw-UH; Fri, 13 Apr 2007 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 13 Apr 2007 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: hipsec@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-dns-09.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 (HIP) Domain Name System (DNS) Extensions Author(s) : P. Nikander, J. Laganier Filename : draft-ietf-hip-dns-09.txt Pages : 21 Date : 2007-4-13 This document specifies a new resource record (RR) for the Domain Name System (DNS), and how to use it with the Host Identity Protocol (HIP). This RR allows a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Names of its rendezvous servers (RVS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-dns-09.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-dns-09.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-dns-09.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-4-13133704.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-dns-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-dns-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-13133704.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 Mon Apr 16 03:06:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdLHy-0006Jq-Hv; Mon, 16 Apr 2007 03:06:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdLHx-0006Jf-1n for hipsec@ietf.org; Mon, 16 Apr 2007 03:06:13 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdLHv-0000Fr-II for hipsec@ietf.org; Mon, 16 Apr 2007 03:06:13 -0400 Received: by ug-out-1314.google.com with SMTP id 72so822317ugd for ; Mon, 16 Apr 2007 00:06:10 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=Un87X0PUyurST7OH3l6qmaqALie0kqOzRMjP07z9huuky8UxpBLM/zlEivoUUgB8UYP3P8SzePT0PZ628BPKILdH8599Wp0PaheYuZ1OEREPPFOZI99Vkegc2pZPFeNGTHR0EXALE6dbLl+HFjYfbyJ6LODSM1CElBhpqTJqUNc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=Oc2kbnQX7TdBlHFXZYJAqeE6Tryef1wHYvbRn/yLK7piBGhtW5YmAfIsqL7p5B7x5d7DLt6oONINe92/EoMCrsXEV5jMQEHJrnje9+RFZmuCuLqRuWb1IOVJgYNTQ+Y/SYNAwfFOFSzwPf7EGqV7g/Xifvnm/qaWfPv6wKmm2DU= Received: by 10.67.30.6 with SMTP id h6mr4121575ugj.1176707170657; Mon, 16 Apr 2007 00:06:10 -0700 (PDT) Received: from ?192.168.1.137? ( [212.119.9.178]) by mx.google.com with ESMTP id e33sm8636338ugd.2007.04.16.00.06.09; Mon, 16 Apr 2007 00:06:10 -0700 (PDT) From: Julien Laganier To: hipsec@ietf.org Subject: Re: [Hipsec] I-D ACTION:draft-ietf-hip-dns-09.txt Date: Mon, 16 Apr 2007 09:05:34 +0200 User-Agent: KMail/1.8.2 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704160905.34320.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: 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 Folks, This version takes care of comments we got from DNS directorate. Changes: The presentation format of the HIP RR has been changed to specify that no whitespace should be present in the public key field (thus reverting to an earlier version of this specification) due to issues with parsing a record. All other changes editorial. Best, --julien On Friday 13 April 2007 21:50, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Host Identity > Protocol Working Group of the IETF. > > Title : Host Identity Protocol (HIP) Domain Name > System (DNS) Extensions Author(s) : P. Nikander, J. > Laganier > Filename : draft-ietf-hip-dns-09.txt > Pages : 21 > Date : 2007-4-13 > > This document specifies a new resource record (RR) > for the Domain Name System (DNS), and how to use it > with the Host Identity Protocol (HIP). This RR > allows a HIP node to store in the DNS its Host > Identity (HI, the public component of the node > public-private key pair), Host Identity Tag (HIT, a > truncated hash of its public key), and the Domain > Names of its rendezvous servers (RVS). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-hip-d >ns-09.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-dns-09.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-dns-09.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. _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 16 04:30:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdMb4-0003ud-S4; Mon, 16 Apr 2007 04:30:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdMb4-0003uY-Gh for hipsec@ietf.org; Mon, 16 Apr 2007 04:30:02 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdMb2-0005WU-Gu for hipsec@ietf.org; Mon, 16 Apr 2007 04:30:02 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D00495480BD; Mon, 16 Apr 2007 10:29:59 +0200 (CEST) X-AuditID: c1b4fb3c-a8cebbb0000073d5-87-4623340759c6 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B78B82052D; Mon, 16 Apr 2007 10:29:59 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 10:29:59 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 10:29:59 +0200 Received: from [131.160.36.11] (E000FB0F665DD.lmf.ericsson.se [131.160.36.11]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 042AE2471; Mon, 16 Apr 2007 11:29:59 +0300 (EEST) Message-ID: <46233405.6010304@ericsson.com> Date: Mon, 16 Apr 2007 11:29:57 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: hipsec@ietf.org Subject: Re: [Hipsec] I-D ACTION:draft-ietf-hip-applications-01.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Apr 2007 08:29:59.0254 (UTC) FILETIME=[6BA35F60:01C78001] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: 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 Folks, this revision of the draft is supposed to address all the WGLC comments received by the authors. If nobody complains, we intend to request its publication shortly. Cheers, Gonzalo Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Host Identity Protocol Working Group of the IETF. > > Title : Using the Host Identity Protocol with Legacy Applications > Author(s) : T. Henderson, P. Nikander > Filename : draft-ietf-hip-applications-01.txt > Pages : 15 > Date : 2007-4-10 > > The Host Identity Protocol (HIP) and architecture proposes to add a > cryptographic name space for network stack names. From an > application viewpoint, HIP-enabled systems support a new address > family of host identifiers, but it may be a long time until such HIP- > aware applications are widely deployed even if host systems are > upgraded. This informational document discusses implementation and > API issues relating to using HIP in situations in which the system is > HIP-aware but the applications are not. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-hip-applications-01.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-applications-01.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-applications-01.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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Mon Apr 16 07:43:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdPbj-0008Nd-0e; Mon, 16 Apr 2007 07:42:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdPbh-0008Mk-5l for hipsec@ietf.org; Mon, 16 Apr 2007 07:42:53 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdPbf-0001Fb-Dd for hipsec@ietf.org; Mon, 16 Apr 2007 07:42:53 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C2A41206C4; Mon, 16 Apr 2007 13:42:50 +0200 (CEST) X-AuditID: c1b4fb3c-a94ecbb0000073d5-b7-4623613a2264 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B6E8B20695; Mon, 16 Apr 2007 13:42:50 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 13:42:50 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 13:42:50 +0200 Received: from [131.160.36.11] (E000FB0F665DD.lmf.ericsson.se [131.160.36.11]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 335D92403; Mon, 16 Apr 2007 14:42:50 +0300 (EEST) Message-ID: <4623613A.5000009@ericsson.com> Date: Mon, 16 Apr 2007 14:42:50 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: HIP Subject: [Fwd: [Hipsec] NAT Traversal and Native HIP API] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Apr 2007 11:42:50.0467 (UTC) FILETIME=[5C9E5B30:01C7801C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: 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 Folks, we have had some discussions on the NAT traversal draft. However, the API draft has not received enough attention. We need reviewers for the API draft. If you are willing to perform a dedicated review, please let the chairs know... or even better, post it to the list! ;o) Thanks, Gonzalo -------- Original Message -------- Subject: [Hipsec] NAT Traversal and Native HIP API Date: Wed, 31 Jan 2007 13:30:55 +0200 From: Gonzalo Camarillo To: HIP Folks, our charter says that we should be WGLCing the NAT traversal and native API drafts as well. However, we believe that they have not yet received enough attention to grant a WGLC at this point. http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-00.txt http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-00.txt Therefore, we would like to, once more, encourage people to read the drafts and send comments to the list and the authors. We are looking forward to having mailing list discussions on these WG items so that we are able to WGLC them shortly. Thanks, Gonzalo _______________________________________________ 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 Thu Apr 19 15:54:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hecha-0006o4-7j; Thu, 19 Apr 2007 15:53:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HechZ-0006ny-8N for hipsec@ietf.org; Thu, 19 Apr 2007 15:53:57 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HechX-0002Mr-I4 for hipsec@ietf.org; Thu, 19 Apr 2007 15:53:57 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0B9E920FF2; Thu, 19 Apr 2007 21:53:55 +0200 (CEST) X-AuditID: c1b4fb3e-b01efbb0000061ca-c7-4627c8d2ada7 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E74E3203F6; Thu, 19 Apr 2007 21:53:54 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 21:53:54 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 21:53:53 +0200 Received: from [131.160.126.150] (rvi2-126-150.lmf.ericsson.se [131.160.126.150]) by mail.lmf.ericsson.se (Postfix) with ESMTP id CF7CC236A; Thu, 19 Apr 2007 22:53:53 +0300 (EEST) Message-ID: <4627C8D1.2060002@ericsson.com> Date: Thu, 19 Apr 2007 22:53:53 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Apr 2007 19:53:53.0947 (UTC) FILETIME=[7575DEB0:01C782BC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [Hipsec] IESG evaluation of base, esp, rvs, registration, and mm 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, FYI: the IESG evaluations of the HIP drafts that are under review are available at the ID tracker. Cheers, Gonzalo _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Apr 20 08:56:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heseq-0001zq-0j; Fri, 20 Apr 2007 08:56:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hesep-0001zf-47 for hipsec@ietf.org; Fri, 20 Apr 2007 08:56:11 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hesen-0001QZ-GE for hipsec@ietf.org; Fri, 20 Apr 2007 08:56:11 -0400 Received: by ug-out-1314.google.com with SMTP id 72so740654ugd for ; Fri, 20 Apr 2007 05:56:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=jK9SZniLwi+zpOJNWFH8Awj9qU+r9aCCi2KCjCqOhjQPwY+Cld6P7IVIzwgHs36/03Z+0cBeNmusnNENwgujXS7DF2fTXMw5hsxU0mc09sd3BkgeusqxhFAmXcJlKL4F4TZg74lQEpfXL+FxHhlBdMwFcST5kESJ4LRJD6hlpnE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=SlVFKwuUiA50NyltlSRJOHy1A0BPgo+5q4b++ZOtXIu7ZeWfPbj23d2VJnwLOkZCdjhVrkeeZTqzFDowfuPNtsbOSwzvbZLPq5HeS0Q2S6+rXaJgVfjW1BjLfA9AM9n+0iv0KMLEuv1nhWA2CUERNiwYoAnAMtWipbnHZi5hdes= Received: by 10.66.220.17 with SMTP id s17mr2577427ugg.1177073768537; Fri, 20 Apr 2007 05:56:08 -0700 (PDT) Received: from ?192.168.1.137? ( [212.119.9.178]) by mx.google.com with ESMTP id 27sm6559583ugp.2007.04.20.05.56.07; Fri, 20 Apr 2007 05:56:07 -0700 (PDT) From: Julien Laganier To: HIP , Russ Housley , Sam Hartman Subject: Re: [Hipsec] IESG evaluation of HIP base, esp, rvs, registration, and mm Date: Fri, 20 Apr 2007 14:56:15 +0200 User-Agent: KMail/1.8.2 References: <4627C8D1.2060002@ericsson.com> In-Reply-To: <4627C8D1.2060002@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704201456.16556.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: 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 Sam, Russ, HIP folks, Please find below are some comments/questions on the IESG evaluation of the HIP document set: > DISCUSSES AND COMMENTS: ====================== > > Sam Hartman: > > Discuss [2007-04-18]: Hi. I've evaluated this > document set and held it to a higher level of quality > than I would normally hold an experimental > publication to. I'm assuming there is some reasonable > chance that this will be the basis of important > internet architecture. I'd rather identify issues now > than when a successor to this version of HIP goes to > proposed. As such, many of my issues may be handled > by documenting (in an IESG note?) as things that must > be fixed before going to proposed. [...] > HIP's handling of lost state seems insufficient to > guarantee interoperability. Section 6.16 allows a HIP > node to drop state at any time. However there is no > mandatory to implement mechanism to recover other > than waiting for a potentially very long timeout. > Implementations MAY send ICMP messages; > implementations may respond to these messages. But > there is not actually a mechanism that people have to > make available to solve this. I believe Section 6.16. is a left-over from pre CLOSE/CLOSE_ACK handshake times (See version -00, Section 8.9) since the problem Sam is describing is IIRC what made Erik Nordmark comes with the CLOSE/CLOSE_ACK handshake, and led us to integrate it in the protocol. Section 6.16 should simply be deleted, IMHO. [...] > Section 6.2 of the base spec says that the IP address > a packet arrives/is sent on should be ignored. The > problem with this approach is that different > interfaces have different security properties. I may > well be willing to send data without confidentiality > protection over a interface internal to a corporation > but not over an external interface. This interaction > would need to be carefully explored and reasonable > controls added before HIP would be appropriate as a > standard. Thinking about HIP interacts with mandatory > access control in the SPD is also going to be > challenging. I discuss one case of this below. I understand Sam's point about willingness to *send* non-confidentiality protected over internal vs. external interfaces. But I miss the link with Section 6.2. which describes "Processing *Incoming* Application Data"... So is the problem with *receiving* non-confidentiality protected traffic over an "untrusted" interface? [...] > In the ESP document , how does HIP interact with the > SPD? Suppose I have an SPD entry saying that traffic > to 18/8 needs to be protected. Suppose that I contact > a machine via HIP whose HIT happens to resolve to > something in 18/8. Do I expect double encapsulation? HITs are now ORCHIDs (see draft-laganier-ipv6-khi), i.e. a special type of IPv6 address which begin with prefix 2001:10::/28 (allocated in the IPv6 address space for ORCHIDs). Because of that, the HIT-is-an-IP-in-SPD situation described above cannot happen. I'm now thinking that since now HITs are IP addresses, we may just use the IPsec SPD to specify: from 2001:10::/28 to 2001:10::/28 -> protect from 2001:10::/28 to ^(2001:10::/28) -> block In addition, we might want a flag for corresponding PAD entries similar to what BTNS does (BTNS_OK), e.g. HIP_OK. > The ESP document does not make it clear what ipsec > mode is being used. It sounds like beet is desired, > but beet is not a normative reference. How is the > mode indicated and what is the mandatory to implement > mode? To me BEET looks pretty much like transport mode followed by NAT HIT->IP on the sending side, and vice versa (NAT followed by transport mode) on receiving side. Maybe we can specify that instead of BEET? [...] > Russ Housley: > > Comment [2007-04-19]: > > It is possible to run vanilla IPsec and HIP on the > same node and get the intended security services > applied to the intended traffic if one is careful > about configuration. The security services are > present, and it appears to be possible to use a > HIP-unaware IPsec to do the HIP ESP processing. One > should worry about whether there is a possibility of > a HIT conflicting with an actual IPv6 address as the > technique advocated for a HIP-unaware IPsec > implementation apparently has HITs masquerade as IPv6 > addresses for IPsec processing. See my comments above about HITs now being special type of IPv6 addresses (so called ORCHIDs), thus making such conflicts no longer conflicts. > Since HIP and IPsec share a common SPI space, and > traffic on any HIP SPI completely bypasses IPsec > policy. (Think about Steve Kent's usual rant about > IPsec being more than just a means to apply > cryptographic security mechanisms to traffic.) The > assurances that IPsec provides are easily broken with > HIP, since inbound HIP traffic bypasses the IPsec SPD > and gets handed directly to HIP, which logically has > its own SPD. See my comment above on introducing HIP SPD entries with ORCHIDs as selectors, and a HIP_OK PAD entry so that HIP traffic no longer bypasses IPsec, but is in fact IPsec, with a different key management protocol (HIP). > It is not clear to me exactly how to avoid this > situation, or what to add to the document to warn > about this security consideration. A long discussion > may be needed. Since the document is intended for > Experimental RFC, this may be an acceptable > situation, but this must be resolved for this > document to transition to the standards track. Do you think specifying IPsec PAD and SPD entries for HIP would solve these issues? [...] Thanks. -- julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 23 06:18:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfvco-0005Co-GX; Mon, 23 Apr 2007 06:18:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf0N7-0002ys-7g for hipsec@ietf.org; Fri, 20 Apr 2007 17:10:25 -0400 Received: from woodstock.binhost.com ([66.150.120.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hf0N6-0005m5-0W for hipsec@ietf.org; Fri, 20 Apr 2007 17:10:25 -0400 Received: (qmail 14616 invoked by uid 0); 20 Apr 2007 21:10:17 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 20 Apr 2007 21:10:17 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 20 Apr 2007 16:58:37 -0400 To: Julien Laganier , Sam Hartman From: Russ Housley Subject: Re: [Hipsec] IESG evaluation of HIP base, esp, rvs, registration, and mm In-Reply-To: <200704201456.16556.julien.IETF@laposte.net> References: <4627C8D1.2060002@ericsson.com> <200704201456.16556.julien.IETF@laposte.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Mon, 23 Apr 2007 06:18:25 -0400 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 Message-Id: Julien: > > It is not clear to me exactly how to avoid this > > situation, or what to add to the document to warn > > about this security consideration. A long discussion > > may be needed. Since the document is intended for > > Experimental RFC, this may be an acceptable > > situation, but this must be resolved for this > > document to transition to the standards track. > >Do you think specifying IPsec PAD and SPD entries for >HIP would solve these issues? Not sure. This is the question that should be answered with implementation experience. I hope people try to use HIP on the same host as vanilla IPsec so that we do learn the answer during the HIP experiment. Russ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 23 08:55:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfy5A-0004QX-HP; Mon, 23 Apr 2007 08:55:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfy59-0004QQ-Pa for hipsec@ietf.org; Mon, 23 Apr 2007 08:55:51 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfy56-0002Oh-Ur for hipsec@ietf.org; Mon, 23 Apr 2007 08:55:50 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5656E20819; Mon, 23 Apr 2007 14:55:48 +0200 (CEST) X-AuditID: c1b4fb3c-a9cedbb0000073d5-5d-462cacd4a63b Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 422A2206DE; Mon, 23 Apr 2007 14:55:48 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 14:55:47 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 14:55:47 +0200 Received: from [131.160.36.33] (E000FB0F665DD.lmf.ericsson.se [131.160.36.33]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B6F5A2358; Mon, 23 Apr 2007 15:55:47 +0300 (EEST) Message-ID: <462CACD3.3060004@ericsson.com> Date: Mon, 23 Apr 2007 15:55:47 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: HIP Subject: [Fwd: [Fwd: [Hipsec] NAT Traversal and Native HIP API]] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Apr 2007 12:55:47.0768 (UTC) FILETIME=[B695BB80:01C785A6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: 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, we are still looking for reviewers for the API draft. It seems that the interest level in our WG items is, surprisingly, very low. Cheers, Gonzalo -------- Original Message -------- Subject: [Fwd: [Hipsec] NAT Traversal and Native HIP API] Date: Mon, 16 Apr 2007 14:42:50 +0300 From: Gonzalo Camarillo To: HIP Folks, we have had some discussions on the NAT traversal draft. However, the API draft has not received enough attention. We need reviewers for the API draft. If you are willing to perform a dedicated review, please let the chairs know... or even better, post it to the list! ;o) Thanks, Gonzalo -------- Original Message -------- Subject: [Hipsec] NAT Traversal and Native HIP API Date: Wed, 31 Jan 2007 13:30:55 +0200 From: Gonzalo Camarillo To: HIP Folks, our charter says that we should be WGLCing the NAT traversal and native API drafts as well. However, we believe that they have not yet received enough attention to grant a WGLC at this point. http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-00.txt http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-00.txt Therefore, we would like to, once more, encourage people to read the drafts and send comments to the list and the authors. We are looking forward to having mailing list discussions on these WG items so that we are able to WGLC them shortly. Thanks, Gonzalo _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 23 09:10:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfyJ3-00012f-PY; Mon, 23 Apr 2007 09:10:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfyIz-000126-15 for hipsec@ietf.org; Mon, 23 Apr 2007 09:10:09 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfyIy-00077W-5g for hipsec@ietf.org; Mon, 23 Apr 2007 09:10:09 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9E5FA204A4; Mon, 23 Apr 2007 15:10:07 +0200 (CEST) X-AuditID: c1b4fb3c-aa4eebb0000073d5-82-462cb02f6fd6 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8332220837; Mon, 23 Apr 2007 15:10:07 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 15:10:07 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 15:10:06 +0200 Received: from [131.160.36.33] (E000FB0F665DD.lmf.ericsson.se [131.160.36.33]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B684E2358; Mon, 23 Apr 2007 16:10:06 +0300 (EEST) Message-ID: <462CB02E.6090203@ericsson.com> Date: Mon, 23 Apr 2007 16:10:06 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Apr 2007 13:10:07.0053 (UTC) FILETIME=[B6C237D0:01C785A8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: Subject: [Hipsec] Publication requested: legacy applications 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 Folks, I've just requested the publication of the legacy applications draft. Below you can find its PROTO write-up. Cheers, Gonzalo (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The document Shepherd for this document is Gonzalo Camarillo, who has personally reviewed this draft and believes it is read for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes, the document has been adequately reviewed. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? It represents the strong concurrence of all active WG participants. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? This draft was checked with Version: 2.04.07 of the ID nits tool. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document only has Informative references. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The document has a null IANA Considerations section. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document does not use formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. The Host Identity Protocol (HIP) and architecture proposes to add a cryptographic name space for network stack names. From an application viewpoint, HIP-enabled systems support a new address family of host identifiers, but it may be a long time until such HIP- aware applications are widely deployed even if host systems are upgraded. This informational document discusses implementation and API issues relating to using HIP in situations in which the system is HIP-aware but the applications are not. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? No. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? This document is based on the experiences of several HIP implementors. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? Document Shepherd: Gonzalo Camarillo AD: Mark Townsley _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Apr 24 16:37:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgRl1-0003cW-PV; Tue, 24 Apr 2007 16:37:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgRl1-0003a4-8b for hipsec@ietf.org; Tue, 24 Apr 2007 16:37:03 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgRkx-0007gZ-RI for hipsec@ietf.org; Tue, 24 Apr 2007 16:37:03 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 98FAD2CBE; Tue, 24 Apr 2007 23:36:58 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.8-niksula20070322 (2007-02-13) 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.8-niksula20070322 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 242F82CB5; Tue, 24 Apr 2007 23:36:58 +0300 (EEST) Date: Tue, 24 Apr 2007 23:36:58 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: "Henderson, Thomas R" Subject: RE: [Fwd: [Fwd: [Hipsec] NAT Traversal and Native HIP API]] In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D040492A8@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D040492A8@XCH-NW-5V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 Tue, 24 Apr 2007, Henderson, Thomas R wrote: (cc:d hipsec because this might be of interest also to other people) > I am a bit confused as to shim6 role and whatever happened to > draft-sugimoto-multihome-shim-api-00. Is the HIP API work supposed to > cover shim6, or not? If not, should it be coordinated with how shim6 > does their API? HIP API does not cover SHIM6 APIs (or BTNS APIs) and I don't currently see any compatibility issues between any of the drafts. The work has been distributed roughly in the following way: * native api * opportunistic mode * some socket options * shim6 api * multihoming * locator handling * btns api * channel bindings, connection latching * tuning some of ipsec security parameters IMHO, the BTNS stuff is meaningful for HIP mostly in the context of opportunistic mode. We have a pile of improvements for the next version of the BTNS draft from Nicolas Williams that we haven't had time to work on yet. http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-01.txt http://www.ietf.org/internet-drafts/draft-ietf-shim6-multihome-shim-api-02.txt http://www.ietf.org/internet-drafts/draft-komu-btns-api-01.txt -- 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 Apr 25 22:23:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgtdq-0001mR-R2; Wed, 25 Apr 2007 22:23:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgtdp-0001mL-Rb for hipsec@ietf.org; Wed, 25 Apr 2007 22:23:29 -0400 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgtdm-0007gv-3l for hipsec@ietf.org; Wed, 25 Apr 2007 22:23:29 -0400 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 OAA29495; Thu, 26 Apr 2007 14:23:19 +1200 In-Reply-To: References: <77F357662F8BFA4CA7074B0410171B6D040492A8@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: <2A2774B9-5807-414B-AC88-8B911D28CA89@indranet.co.nz> Content-Transfer-Encoding: 7bit From: Andrew McGregor Subject: Re: [Fwd: [Fwd: [Hipsec] NAT Traversal and Native HIP API]] Date: Thu, 26 Apr 2007 14:24:26 +1200 To: Miika Komu X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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've not yet had a detailed look at the APIs themselves, but I have a comment on the overall structure of this set of documents. Nowhere do I see a recommendation as to what constitutes a useful referral for applications in HIP, SHIM6 or BTNS. That's really an architectural consideration, but it should be expressed in the API as well, at least insofar as there needs to be a well defined way to get from a valid referral to a running connection. The API certainly has means to construct connections given several kinds of referral. Andrew On 25/04/2007, at 8:36 AM, Miika Komu wrote: > On Tue, 24 Apr 2007, Henderson, Thomas R wrote: > > (cc:d hipsec because this might be of interest also to other people) > >> I am a bit confused as to shim6 role and whatever happened to >> draft-sugimoto-multihome-shim-api-00. Is the HIP API work >> supposed to >> cover shim6, or not? If not, should it be coordinated with how shim6 >> does their API? > > HIP API does not cover SHIM6 APIs (or BTNS APIs) and I don't > currently see any compatibility issues between any of the drafts. > The work has been distributed roughly in the following way: > > * native api > * opportunistic mode > * some socket options > * shim6 api > * multihoming > * locator handling > * btns api > * channel bindings, connection latching > * tuning some of ipsec security parameters > > IMHO, the BTNS stuff is meaningful for HIP mostly in the context of > opportunistic mode. We have a pile of improvements for the next > version of the BTNS draft from Nicolas Williams that we haven't had > time to work on yet. > > http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-01.txt > http://www.ietf.org/internet-drafts/draft-ietf-shim6-multihome-shim- > api-02.txt > http://www.ietf.org/internet-drafts/draft-komu-btns-api-01.txt > > -- > Miika Komu http://www.iki.fi/ > miika/ > > _______________________________________________ > 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 Thu Apr 26 02:50:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgxoR-0003qQ-PR; Thu, 26 Apr 2007 02:50:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgVf1-0007Dz-Ab for hipsec@ietf.org; Tue, 24 Apr 2007 20:47:07 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgVf0-0003cX-TL for hipsec@ietf.org; Tue, 24 Apr 2007 20:47:07 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 84ED849AA; Tue, 24 Apr 2007 20:47:06 -0400 (EDT) From: Sam Hartman To: Julien Laganier Subject: Re: [Hipsec] IESG evaluation of HIP base, esp, rvs, registration, and mm References: <4627C8D1.2060002@ericsson.com> <200704201456.16556.julien.IETF@laposte.net> Date: Tue, 24 Apr 2007 20:47:06 -0400 In-Reply-To: <200704201456.16556.julien.IETF@laposte.net> (Julien Laganier's message of "Fri, 20 Apr 2007 14:56:15 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 X-Mailman-Approved-At: Thu, 26 Apr 2007 02:50:42 -0400 Cc: HIP , Russ Housley 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 >>>>> "Julien" == Julien Laganier writes: Julien> Sam, Russ, HIP folks, Please find below are some Julien> comments/questions on the IESG evaluation of the HIP Julien> document set: >> DISCUSSES AND COMMENTS: ====================== >> >> Sam Hartman: >> >> Discuss [2007-04-18]: Hi. I've evaluated this document set and >> held it to a higher level of quality than I would normally hold >> an experimental publication to. I'm assuming there is some >> reasonable chance that this will be the basis of important >> internet architecture. I'd rather identify issues now than when >> a successor to this version of HIP goes to proposed. As such, >> many of my issues may be handled by documenting (in an IESG >> note?) as things that must be fixed before going to proposed. Julien> [...] >> HIP's handling of lost state seems insufficient to guarantee >> interoperability. Section 6.16 allows a HIP node to drop state >> at any time. However there is no mandatory to implement >> mechanism to recover other than waiting for a potentially very >> long timeout. Implementations MAY send ICMP messages; >> implementations may respond to these messages. But there is not >> actually a mechanism that people have to make available to >> solve this. Julien> I believe Section 6.16. is a left-over from pre Julien> CLOSE/CLOSE_ACK handshake times (See version -00, Section Julien> 8.9) since the problem Sam is describing is IIRC what made Julien> Erik Nordmark comes with the CLOSE/CLOSE_ACK handshake, Julien> and led us to integrate it in the protocol. Julien> Section 6.16 should simply be deleted, IMHO. I think this would be a significant improvement. You still have issues on reboot, but much less of a problem. Julien> [...] >> Section 6.2 of the base spec says that the IP address a packet >> arrives/is sent on should be ignored. The problem with this >> approach is that different interfaces have different security >> properties. I may well be willing to send data without >> confidentiality protection over a interface internal to a >> corporation but not over an external interface. This >> interaction would need to be carefully explored and reasonable >> controls added before HIP would be appropriate as a >> standard. Thinking about HIP interacts with mandatory access >> control in the SPD is also going to be challenging. I discuss >> one case of this below. Julien> I understand Sam's point about willingness to *send* Julien> non-confidentiality protected over internal vs. external Julien> interfaces. Julien> But I miss the link with Section 6.2. which describes Julien> "Processing *Incoming* Application Data"... Ah, thanks for catching this. I missed a point from my discuss turning raw notes into text I hoped someone else could understand. My concern with section 6.2 is that there is no requirement that the HIT on the inbound packet match the expected HIT for the SA. I understand that this needs to be said in a transport-neutral manner, but I think it is critical. Julien> [...] >> In the ESP document , how does HIP interact with the SPD? >> Suppose I have an SPD entry saying that traffic to 18/8 needs >> to be protected. Suppose that I contact a machine via HIP whose >> HIT happens to resolve to something in 18/8. Do I expect double >> encapsulation? Julien> HITs are now ORCHIDs (see draft-laganier-ipv6-khi), i.e. a Julien> special type of IPv6 address which begin with prefix Julien> 2001:10::/28 (allocated in the IPv6 address space for Julien> ORCHIDs). Julien> Because of that, the HIT-is-an-IP-in-SPD situation Julien> described above cannot happen. No. That's not the situation I was describing. In order to contact node node identified by HIT X, I need to find a locator with a given IP address. Let's say I find that HIT X has IP address 18.18.0.2. That IP address is covered by my SPD. Depending on how HIP interacts with my IPsec stack I may or may not get double encapsulation. Julien> I'm now thinking that since now HITs are IP addresses, we Julien> may just use the IPsec SPD to specify: Julien> from 2001:10::/28 to 2001:10::/28 -> protect from Julien> 2001:10::/28 to ^(2001:10::/28) -> block Julien> In addition, we might want a flag for corresponding PAD Julien> entries similar to what BTNS does (BTNS_OK), e.g. HIP_OK. I think in the case of HIP you get this by saying that HIP rather than the IKE is the protocol to use for that PAD entry. You already get that in 4301. >> Since HIP and IPsec share a common SPI space, and traffic on >> any HIP SPI completely bypasses IPsec policy. (Think about >> Steve Kent's usual rant about IPsec being more than just a >> means to apply cryptographic security mechanisms to traffic.) >> The assurances that IPsec provides are easily broken with HIP, >> since inbound HIP traffic bypasses the IPsec SPD and gets >> handed directly to HIP, which logically has its own SPD. Julien> See my comment above on introducing HIP SPD entries with Julien> ORCHIDs as selectors, and a HIP_OK PAD entry so that HIP Julien> traffic no longer bypasses IPsec, but is in fact IPsec, Julien> with a different key management protocol (HIP). >> It is not clear to me exactly how to avoid this situation, or >> what to add to the document to warn about this security >> consideration. A long discussion may be needed. Since the >> document is intended for Experimental RFC, this may be an >> acceptable situation, but this must be resolved for this >> document to transition to the standards track. Julien> Do you think specifying IPsec PAD and SPD entries for HIP Julien> would solve these issues? As best I can tell, yes. It's critical though that the SPD entry for a given SA be locked down to that /128 per my discussion about 6.2. _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Apr 26 05:15:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh04g-0007YX-2P; Thu, 26 Apr 2007 05:15:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh04e-0007YL-He for hipsec@ietf.org; Thu, 26 Apr 2007 05:15:36 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh04d-0003za-01 for hipsec@ietf.org; Thu, 26 Apr 2007 05:15:36 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 8E154212D7B; Thu, 26 Apr 2007 12:15:33 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 5509F212D1A; Thu, 26 Apr 2007 12:15:33 +0300 (EEST) In-Reply-To: <2A2774B9-5807-414B-AC88-8B911D28CA89@indranet.co.nz> References: <77F357662F8BFA4CA7074B0410171B6D040492A8@XCH-NW-5V1.nw.nos.boeing.com> <2A2774B9-5807-414B-AC88-8B911D28CA89@indranet.co.nz> 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: [Fwd: [Fwd: [Hipsec] NAT Traversal and Native HIP API]] Date: Thu, 26 Apr 2007 12:15:31 +0300 To: Andrew McGregor X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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 Good point about referrals. I think we need another document. As far as I can see, the basic message is easy: use the full public key for referrals. Amend it with locators if you know fresh and good ones, but they are only taken as hints. --Pekka On 26 Apr 2007, at 05:24, Andrew McGregor wrote: > I've not yet had a detailed look at the APIs themselves, but I have > a comment on the overall structure of this set of documents. > Nowhere do I see a recommendation as to what constitutes a useful > referral for applications in HIP, SHIM6 or BTNS. That's really an > architectural consideration, but it should be expressed in the API > as well, at least insofar as there needs to be a well defined way > to get from a valid referral to a running connection. The API > certainly has means to construct connections given several kinds of > referral. > > Andrew > > On 25/04/2007, at 8:36 AM, Miika Komu wrote: > >> On Tue, 24 Apr 2007, Henderson, Thomas R wrote: >> >> (cc:d hipsec because this might be of interest also to other people) >> >>> I am a bit confused as to shim6 role and whatever happened to >>> draft-sugimoto-multihome-shim-api-00. Is the HIP API work >>> supposed to >>> cover shim6, or not? If not, should it be coordinated with how >>> shim6 >>> does their API? >> >> HIP API does not cover SHIM6 APIs (or BTNS APIs) and I don't >> currently see any compatibility issues between any of the drafts. >> The work has been distributed roughly in the following way: >> >> * native api >> * opportunistic mode >> * some socket options >> * shim6 api >> * multihoming >> * locator handling >> * btns api >> * channel bindings, connection latching >> * tuning some of ipsec security parameters >> >> IMHO, the BTNS stuff is meaningful for HIP mostly in the context >> of opportunistic mode. We have a pile of improvements for the next >> version of the BTNS draft from Nicolas Williams that we haven't >> had time to work on yet. >> >> http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-01.txt >> http://www.ietf.org/internet-drafts/draft-ietf-shim6-multihome- >> shim-api-02.txt >> http://www.ietf.org/internet-drafts/draft-komu-btns-api-01.txt >> >> -- >> Miika Komu http://www.iki.fi/ >> miika/ >> >> _______________________________________________ >> 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 > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Apr 26 14:14:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh8UM-00053K-7I; Thu, 26 Apr 2007 14:14:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh8UK-00053E-Sl for hipsec@ietf.org; Thu, 26 Apr 2007 14:14:40 -0400 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 1Hh8UK-0000Oy-Gl for hipsec@ietf.org; Thu, 26 Apr 2007 14:14:40 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l3QIEcZV024722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 26 Apr 2007 11:14:39 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l3QIEcDm018808; Thu, 26 Apr 2007 11:14:38 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l3QIEQrd018517; Thu, 26 Apr 2007 11:14:38 -0700 (PDT) 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); Thu, 26 Apr 2007 11:14:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Apr 2007 11:14:34 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D040492B6@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on native HIP API draft Thread-Index: AceGsE+lURmHmsSPQ4iygFM4KWigEABaMr8g From: "Henderson, Thomas R" To: "Miika Komu" X-OriginalArrivalTime: 26 Apr 2007 18:14:35.0133 (UTC) FILETIME=[BE9F42D0:01C7882E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: hipsec@ietf.org Subject: [Hipsec] comments on native HIP API 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 =20 > -----Original Message----- > From: Miika Komu [mailto:miika@iki.fi]=20 > Sent: Tuesday, April 24, 2007 1:37 PM > To: Henderson, Thomas R > Cc: Ahrenholz, Jeffrey M; hipsec@ietf.org > Subject: RE: [Fwd: [Fwd: [Hipsec] NAT Traversal and Native HIP API]] >=20 > On Tue, 24 Apr 2007, Henderson, Thomas R wrote: >=20 > (cc:d hipsec because this might be of interest also to other people) >=20 > > I am a bit confused as to shim6 role and whatever happened to > > draft-sugimoto-multihome-shim-api-00. Is the HIP API work=20 > supposed to > > cover shim6, or not? If not, should it be coordinated with=20 > how shim6 > > does their API? >=20 > HIP API does not cover SHIM6 APIs (or BTNS APIs) and I don't=20 > currently see=20 > any compatibility issues between any of the drafts.=20 I didn't draw the same conclusion. The shim6 API draft talks=20 about HIP, the HIP API draft talks about shims. They don't seem=20 to be consistent either; the shim6 draft talks about EIDs, ULIDs,=20 and HITs, while the HIP draft talks about endpoint descriptors=20 (EDs). Even the document titles seem to be very close: "Native API for SHIM Layer Protocols" and "Socket API for=20 Multihoming Shim". Maybe the socket options are split out between the two drafts, but there seems to me to be a clear relationship. Some comments on the HIP API draft: I do not think that the concept of Endpoint Descriptor as the primary application-level name for endpoints is fully worked out. In particular, I question the overall design of using a=20 locally-scoped name as the primary name at the native API. One criticism of HIP is that it does not properly support application referrals when LSIs are used. ED could be subject to the same criticism. It seems somewhat a step backward to me that we would try to define this new HIP namespace to allow hosts to be named explicitly, then to avoid using such names at native APIs. =20 =20 I understand the goal stated in the draft that users do not want=20 to have to handle 128-bit flat identifiers, but the role of=20 aliases for these identifiers needs to be carefully thought out. =20 I am not sure that abstracting these names at the socket API is=20 critical because humans are not interacting with the system at=20 that level. There may need to be some other resolution mechanism=20 considered. For instance, I can imagine that I might want to assign a=20 name such as "my work laptop" to a host and have that mapped=20 locally to a lower-level identifier somewhere locally on my system,=20 but resolving that might not be the job of the socket API but rather something like the resolver. I think there are a few steps that are needed: 1) definition of a new address family (AF_HOST) that allows for the application to signal to the system that the quantity being passed at the application is a host identifier. Ideally, this should explicitly allow users to specify hosts by HIT and to allow IP addresses to be optionally (additionally) passed as hints. Wildcard values should also be supported. (I don't know about Pekka's suggestion to pass the full HI; I'm not sure why that is needed) 2) there should be a set of flags and policy attributes (sec 3.2.4)=20 that should be settable via the equivalent of setsockopt(). I am=20 not sure about all of the list of options in Table 2, though. For=20 instance, setting the ESP transform is not something that is done=20 at the sockets API but at other APIs like PFKEY. After reaching the above two milestones, an application that is=20 HIP aware could cleanly use the sockets API with HITs. The next=20 step might be to consider how to generalize it to allow for LSIs (endpoint descriptors) and for advanced functionality like allowing=20 an application to register its own application-specific host=20 identity for use on the socket, but the use cases should be clearly=20 described and agreed before venturing down that path, and consideration=20 made as to whether sockets API or another API is the right choice. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Apr 26 21:47:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhFYK-0006pb-O5; Thu, 26 Apr 2007 21:47:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhFYJ-0006oQ-O2 for hipsec@ietf.org; Thu, 26 Apr 2007 21:47:15 -0400 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhFXJ-0006ic-2y for hipsec@ietf.org; Thu, 26 Apr 2007 21:46:13 -0400 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 NAA22461; Fri, 27 Apr 2007 13:46:04 +1200 In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D040492B6@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6D040492B6@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: Content-Transfer-Encoding: 7bit From: Andrew McGregor Subject: Re: [Hipsec] comments on native HIP API draft Date: Fri, 27 Apr 2007 13:47:10 +1200 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 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 27/04/2007, at 6:14 AM, Henderson, Thomas R wrote: > > >> -----Original Message----- >> From: Miika Komu [mailto:miika@iki.fi] >> Sent: Tuesday, April 24, 2007 1:37 PM >> To: Henderson, Thomas R >> Cc: Ahrenholz, Jeffrey M; hipsec@ietf.org >> Subject: RE: [Fwd: [Fwd: [Hipsec] NAT Traversal and Native HIP API]] >> >> On Tue, 24 Apr 2007, Henderson, Thomas R wrote: >> >> (cc:d hipsec because this might be of interest also to other people) >> >>> I am a bit confused as to shim6 role and whatever happened to >>> draft-sugimoto-multihome-shim-api-00. Is the HIP API work >> supposed to >>> cover shim6, or not? If not, should it be coordinated with >> how shim6 >>> does their API? >> >> HIP API does not cover SHIM6 APIs (or BTNS APIs) and I don't >> currently see >> any compatibility issues between any of the drafts. > > I didn't draw the same conclusion. The shim6 API draft talks > about HIP, the HIP API draft talks about shims. They don't seem > to be consistent either; the shim6 draft talks about EIDs, ULIDs, > and HITs, while the HIP draft talks about endpoint descriptors > (EDs). Even the document titles seem to be very close: > "Native API for SHIM Layer Protocols" and "Socket API for > Multihoming Shim". Maybe the socket options are split out > between the two drafts, but there seems to me to be a clear > relationship. I agree about the consistency: there should be one set of terminology. As it is, these documents would make very confusing manual entries for the APIs. > Some comments on the HIP API draft: > > I do not think that the concept of Endpoint Descriptor as the > primary application-level name for endpoints is fully worked out. > In particular, I question the overall design of using a > locally-scoped name as the primary name at the native API. One > criticism of HIP is that it does not properly support application > referrals when LSIs are used. ED could be subject to the > same criticism. It seems somewhat a step backward to me that > we would try to define this new HIP namespace to allow hosts > to be named explicitly, then to avoid using such names at > native APIs. > > I understand the goal stated in the draft that users do not want > to have to handle 128-bit flat identifiers, but the role of > aliases for these identifiers needs to be carefully thought out. > I am not sure that abstracting these names at the socket API is > critical because humans are not interacting with the system at > that level. There may need to be some other resolution mechanism > considered. > > For instance, I can imagine that I might want to assign a > name such as "my work laptop" to a host and have that mapped > locally to a lower-level identifier somewhere locally on my system, > but resolving that might not be the job of the socket API but > rather something like the resolver. I rather agree; and additionally, it seems to require greater refactoring of an application to make it support EDs rather than go with the existing design of passing around struct hostent *s... especially if the application already supports IPv6, because adding a third address family is much easier than adding the second. > > I think there are a few steps that are needed: > > 1) definition of a new address family (AF_HOST) that allows > for the application to signal to the system that the quantity > being passed at the application is a host identifier. Ideally, > this should explicitly allow users to specify hosts by HIT and > to allow IP addresses to be optionally (additionally) passed > as hints. Wildcard values should also be supported. > > (I don't know about Pekka's suggestion to pass the full HI; I'm > not sure why that is needed) At this level I think the API should require at least one locator in a connect(), because the 'how do you look up a HIT' question is still unresolved; I think it should be done within the resolver, not below the sockets API. > > 2) there should be a set of flags and policy attributes (sec 3.2.4) > that should be settable via the equivalent of setsockopt(). I am > not sure about all of the list of options in Table 2, though. For > instance, setting the ESP transform is not something that is done > at the sockets API but at other APIs like PFKEY. But setting a TLS crypto option is done using a library-specific handle that eventually points at a socket. I think setting transform options is better done with setsockopt(), simply because otherwise the application has to do a whole lot more work to get a handle in another API for something it already has a pointer to, namely the socket. > > After reaching the above two milestones, an application that is > HIP aware could cleanly use the sockets API with HITs. The next > step might be to consider how to generalize it to allow for LSIs > (endpoint descriptors) and for advanced functionality like allowing > an application to register its own application-specific host > identity for use on the socket, but the use cases should be clearly > described and agreed before venturing down that path, and > consideration > made as to whether sockets API or another API is the right choice. > > Tom Can't we just assign application specific identities with bind()? That would seem most in line with the existing API. So to make a connection using an app specific identity, you make a socket, bind it to the app identity, resolve the peer, and call connect with the results. Andrew _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Apr 27 02:13:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhJi7-000679-Fz; Fri, 27 Apr 2007 02:13:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhJi6-000674-Mh for hipsec@ietf.org; Fri, 27 Apr 2007 02:13:38 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhJi5-0002cy-5w for hipsec@ietf.org; Fri, 27 Apr 2007 02:13:38 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 5D6BE212D7B for ; Fri, 27 Apr 2007 09:13:35 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 2511B212D1A for ; Fri, 27 Apr 2007 09:13:35 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v752.3) References: <200704270139.l3R1dfnI023433@nit.isi.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2160C009-CF28-4E70-8CFA-9C6D5759265B@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Fri, 27 Apr 2007 09:13:31 +0300 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: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: Subject: [Hipsec] Fwd: RFC 4843 on An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID) 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: rfc-editor@rfc-editor.org > Date: 27 April 2007 04:39:41 GMT+03:00 > To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > Cc: rfc-editor@rfc-editor.org > Subject: RFC 4843 on An IPv6 Prefix for Overlay Routable > Cryptographic Hash Identifiers (ORCHID) > > > A new Request for Comments is now available in online RFC libraries. > > > RFC 4843 > > Title: An IPv6 Prefix for Overlay > Routable Cryptographic Hash Identifiers (ORCHID) > Author: P. Nikander, J. Laganier, > F. Dupont > Status: Experimental > Date: April 2007 > Mailbox: pekka.nikander@nomadiclab.com, > julien.ietf@laposte.net, > Francis.Dupont@fdupont.fr > Pages: 14 > Characters: 32483 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-laganier-ipv6-khi-07.txt > > URL: http://www.rfc-editor.org/rfc/rfc4843.txt > > 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 > endpoint identifiers at applications and Application Programming > Interfaces (API) 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 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. By default, the prefix will be returned to IANA in > 2014, with continued use requiring IETF consensus. This memo > defines an > Experimental Protocol for the Internet community. > > > EXPERIMENTAL: This memo defines an Experimental Protocol for the > Internet > community. It does not specify an Internet standard of any kind. > Discussion and suggestions for improvement are requested. > Distribution > of this memo is unlimited. > > This announcement is sent to the IETF list and the RFC-DIST list. > Requests to be added to or deleted from the IETF distribution list > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > added to or deleted from the RFC-DIST distribution list should > be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > > help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. > Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > Submissions for Requests for Comments should be sent to > RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions > to RFC > Authors, for further information. > > > The RFC Editor Team > USC/Information Sciences Institute > > ... > > > > _______________________________________________ > 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 Fri Apr 27 08:28:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhPYf-0007nO-Hz; Fri, 27 Apr 2007 08:28:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhPYe-0007jO-0K for hipsec@ietf.org; Fri, 27 Apr 2007 08:28:16 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhPUL-000594-DR for hipsec@ietf.org; Fri, 27 Apr 2007 08:23:50 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 9FFF62D78; Fri, 27 Apr 2007 15:23:46 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.8-niksula20070322 (2007-02-13) 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.8-niksula20070322 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 0376C2D71; Fri, 27 Apr 2007 15:23:46 +0300 (EEST) Date: Fri, 27 Apr 2007 15:23:45 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: "Henderson, Thomas R" In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D040492B6@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D040492B6@XCH-NW-5V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: hipsec@ietf.org Subject: [Hipsec] Re: comments on native HIP API 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 On Thu, 26 Apr 2007, Henderson, Thomas R wrote: Thanks Thomas, some comments below, >> -----Original Message----- >> From: Miika Komu [mailto:miika@iki.fi] >> Sent: Tuesday, April 24, 2007 1:37 PM >> To: Henderson, Thomas R >> Cc: Ahrenholz, Jeffrey M; hipsec@ietf.org >> Subject: RE: [Fwd: [Fwd: [Hipsec] NAT Traversal and Native HIP API]] >> >> On Tue, 24 Apr 2007, Henderson, Thomas R wrote: >> >> (cc:d hipsec because this might be of interest also to other people) >> >>> I am a bit confused as to shim6 role and whatever happened to >>> draft-sugimoto-multihome-shim-api-00. Is the HIP API work >> supposed to >>> cover shim6, or not? If not, should it be coordinated with >> how shim6 >>> does their API? >> >> HIP API does not cover SHIM6 APIs (or BTNS APIs) and I don't >> currently see >> any compatibility issues between any of the drafts. > > I didn't draw the same conclusion. The shim6 API draft talks > about HIP, the HIP API draft talks about shims. They don't seem > to be consistent either; the shim6 draft talks about EIDs, ULIDs, > and HITs, while the HIP draft talks about endpoint descriptors > (EDs). Even the document titles seem to be very close: > "Native API for SHIM Layer Protocols" and "Socket API for > Multihoming Shim". Maybe the socket options are split out > between the two drafts, but there seems to me to be a clear > relationship. Ok, I think we need a terminology section in the drafts at the minimum. > I do not think that the concept of Endpoint Descriptor as the > primary application-level name for endpoints is fully worked out. > In particular, I question the overall design of using a > locally-scoped name as the primary name at the native API. One > criticism of HIP is that it does not properly support application > referrals when LSIs are used. ED could be subject to the > same criticism. It seems somewhat a step backward to me that > we would try to define this new HIP namespace to allow hosts > to be named explicitly, then to avoid using such names at > native APIs. If you are suggesting HIs and HITs as referrals, they have their own problems because the locator is needed as hint. The API does not give false feelings about referrals because the EDs don't even look like addresses. The application can figure with getlocaledinfo and getpeeredinfo that what is the best type of referral for its use; an IP address (for legacy apps and for opportunistic connections), HI or HIT. Thomas, you did mention anything about the opportunistic mode in your comments which was the main motivator for the ED in the draft. I believe the draft addresses this problem in a clean way with the EDs as discussed in sections 1, 2.4 and 3.1. > I understand the goal stated in the draft that users do not want > to have to handle 128-bit flat identifiers, but the role of > aliases for these identifiers needs to be carefully thought out. > I am not sure that abstracting these names at the socket API is > critical because humans are not interacting with the system at > that level. There may need to be some other resolution mechanism > considered. The ED concept is engineering choice and it not really related to usability. It is related to code developers (as means for avoiding hard coded applications), but not to the actual end-users. The draft considers that what happens when people decide to transition from 128 bit HITs to 256 bit HITs in the future? I am not sure that it is good idea to hardcode this to the API (recall the SHA1 collision problems). > I think there are a few steps that are needed: > > 1) definition of a new address family (AF_HOST) that allows > for the application to signal to the system that the quantity > being passed at the application is a host identifier. Ideally, > this should explicitly allow users to specify hosts by HIT and > to allow IP addresses to be optionally (additionally) passed > as hints. Wildcard values should also be supported. Please see above my comments regarding to the use of HITs. The draft already contains PF_SHIM (never mind about the difference between AF and PF, it has been already broken). Wildcard values are supported as described in section 3.1. "Automatic" HIT + IP mappings are supported by the resolver and can be manually configured as show in section 3.2.1. > (I don't know about Pekka's suggestion to pass the full HI; I'm > not sure why that is needed) Application can query for full local or peer HIs using the functions in section 3.2.3. > 2) there should be a set of flags and policy attributes (sec 3.2.4) > that should be settable via the equivalent of setsockopt(). I am > not sure about all of the list of options in Table 2, though. For > instance, setting the ESP transform is not something that is done > at the sockets API but at other APIs like PFKEY. The ESP transforms belong to the BTNS API draft. The BTNS security options won't be settable with setsockopt() but rather "wrapper functions for setsockopt". > After reaching the above two milestones, an application that is > HIP aware could cleanly use the sockets API with HITs. The next > step might be to consider how to generalize it to allow for LSIs > (endpoint descriptors) and for advanced functionality like allowing > an application to register its own application-specific host > identity for use on the socket, but the use cases should be clearly > described and agreed before venturing down that path, and consideration > made as to whether sockets API or another API is the right choice. I don't see how burdening a HIP aware application with LSIs, HIT128, HIT256 and HIs is going to make it modular. I think a single "blob" identifier would make things easier. Think about forwards compatibility with other protocols supporting identity locator split (see SHIM_AF_FAMILY in section 3.2.4). The application specific identifiers are already handled in section 3.2.2. -- 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 Fri Apr 27 18:07:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhYaw-0004EH-GN; Fri, 27 Apr 2007 18:07:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhYav-0004EB-KP for hipsec@ietf.org; Fri, 27 Apr 2007 18:07:13 -0400 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 1HhYat-0008IO-7y for hipsec@ietf.org; Fri, 27 Apr 2007 18:07:13 -0400 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 l3RM794T029106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 27 Apr 2007 17:07:10 -0500 (CDT) 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 l3RM78h3009365; Fri, 27 Apr 2007 15:07:09 -0700 (PDT) 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 l3RM78Z0009341; Fri, 27 Apr 2007 15:07:08 -0700 (PDT) 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, 27 Apr 2007 15:07:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Apr 2007 15:07:08 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D040492B9@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on native HIP API draft Thread-Index: AceIxumZxgSfJuU0Svml2QsJKPx+/gAUIrBQ From: "Henderson, Thomas R" To: "Miika Komu" X-OriginalArrivalTime: 27 Apr 2007 22:07:08.0605 (UTC) FILETIME=[65F3DED0:01C78918] X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: hipsec@ietf.org Subject: [Hipsec] RE: comments on native HIP API 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 =20 Miika, some follow-up inline: >=20 > > I do not think that the concept of Endpoint Descriptor as the > > primary application-level name for endpoints is fully worked out. > > In particular, I question the overall design of using a > > locally-scoped name as the primary name at the native API. One > > criticism of HIP is that it does not properly support application > > referrals when LSIs are used. ED could be subject to the > > same criticism. It seems somewhat a step backward to me that > > we would try to define this new HIP namespace to allow hosts > > to be named explicitly, then to avoid using such names at > > native APIs. >=20 > If you are suggesting HIs and HITs as referrals, they have their own=20 > problems because the locator is needed as hint. The API does not give > false feelings about referrals because the EDs don't even look like=20 > addresses.=20 Neither do ORCHIDs to a HIP-aware app. > The application can figure with getlocaledinfo and=20 > getpeeredinfo that what is the best type of referral for its use; an=20 > IP address (for legacy apps and for opportunistic=20 > connections), HI or HIT. >=20 > Thomas, you did mention anything about the opportunistic mode in your=20 > comments which was the main motivator for the ED in the=20 > draft. I believe=20 > the draft addresses this problem in a clean way with the EDs=20 > as discussed=20 > in sections 1, 2.4 and 3.1. Can't you simply connect(*, locator) where * is a wildcard value for the HIT? >=20 > > I understand the goal stated in the draft that users do not want > > to have to handle 128-bit flat identifiers, but the role of > > aliases for these identifiers needs to be carefully thought out. > > I am not sure that abstracting these names at the socket API is > > critical because humans are not interacting with the system at > > that level. There may need to be some other resolution mechanism > > considered. >=20 > The ED concept is engineering choice and it not really related to=20 > usability. It is related to code developers (as means for=20 > avoiding hard=20 > coded applications), but not to the actual end-users. >=20 > The draft considers that what happens when people decide to=20 > transition=20 > from 128 bit HITs to 256 bit HITs in the future? I am not=20 > sure that it is=20 > good idea to hardcode this to the API (recall the SHA1 collision=20 > problems). (see my last comment below) >=20 > > I think there are a few steps that are needed: > > > > 1) definition of a new address family (AF_HOST) that allows > > for the application to signal to the system that the quantity > > being passed at the application is a host identifier. Ideally, > > this should explicitly allow users to specify hosts by HIT and > > to allow IP addresses to be optionally (additionally) passed > > as hints. Wildcard values should also be supported. >=20 > Please see above my comments regarding to the use of HITs. >=20 > The draft already contains PF_SHIM (never mind about the difference=20 > between AF and PF, it has been already broken). Wildcard values are=20 > supported as described in section 3.1. "Automatic" HIT + IP=20 > mappings are=20 > supported by the resolver and can be manually configured as show in=20 > section 3.2.1. >=20 > > (I don't know about Pekka's suggestion to pass the full HI; I'm > > not sure why that is needed) >=20 > Application can query for full local or peer HIs using the=20 > functions in=20 > section 3.2.3. again, I am not sure of the utility, since a HIT uniquely refers to a HI, and the base exchange provides the HI. >=20 > > 2) there should be a set of flags and policy attributes (sec 3.2.4) > > that should be settable via the equivalent of setsockopt(). I am > > not sure about all of the list of options in Table 2, though. For > > instance, setting the ESP transform is not something that is done > > at the sockets API but at other APIs like PFKEY. >=20 > The ESP transforms belong to the BTNS API draft. The BTNS security=20 > options won't be settable with setsockopt() but rather "wrapper=20 > functions for setsockopt". >=20 > > After reaching the above two milestones, an application that is > > HIP aware could cleanly use the sockets API with HITs. The next > > step might be to consider how to generalize it to allow for LSIs > > (endpoint descriptors) and for advanced functionality like allowing > > an application to register its own application-specific host > > identity for use on the socket, but the use cases should be clearly > > described and agreed before venturing down that path, and=20 > consideration > > made as to whether sockets API or another API is the right choice. >=20 > I don't see how burdening a HIP aware application with LSIs, HIT128,=20 > HIT256 and HIs is going to make it modular. I think a single "blob"=20 > identifier would make things easier. Think about forwards=20 > compatibility=20 > with other protocols supporting identity locator split (see=20 > SHIM_AF_FAMILY in section 3.2.4). >=20 > The application specific identifiers are already handled in=20 > section 3.2.2. I think if we go down this path, we need to consider more broadly than HIP what are the implications of making applications work on the basis of LSIs. Maybe the application community can be consulted. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Apr 29 10:18:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiAEO-0001hh-K0; Sun, 29 Apr 2007 10:18:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiAEN-0001hb-Iw for hipsec@ietf.org; Sun, 29 Apr 2007 10:18:27 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiAEK-00087b-0w for hipsec@ietf.org; Sun, 29 Apr 2007 10:18:27 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 27AEA2D6A; Sun, 29 Apr 2007 17:18:19 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.8-niksula20070322 (2007-02-13) 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.8-niksula20070322 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 645892D55; Sun, 29 Apr 2007 17:18:18 +0300 (EEST) Date: Sun, 29 Apr 2007 17:18:18 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: "Henderson, Thomas R" In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D040492B9@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D040492B9@XCH-NW-5V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: hipsec@ietf.org Subject: [Hipsec] RE: comments on native HIP API 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 On Fri, 27 Apr 2007, Henderson, Thomas R wrote: Hi Thomas, > Miika, some follow-up inline: > >> >>> I do not think that the concept of Endpoint Descriptor as the >>> primary application-level name for endpoints is fully worked out. >>> In particular, I question the overall design of using a >>> locally-scoped name as the primary name at the native API. One >>> criticism of HIP is that it does not properly support application >>> referrals when LSIs are used. ED could be subject to the >>> same criticism. It seems somewhat a step backward to me that >>> we would try to define this new HIP namespace to allow hosts >>> to be named explicitly, then to avoid using such names at >>> native APIs. >> >> If you are suggesting HIs and HITs as referrals, they have their own >> problems because the locator is needed as hint. The API does not give >> false feelings about referrals because the EDs don't even look like >> addresses. > > Neither do ORCHIDs to a HIP-aware app. Agree. >> The application can figure with getlocaledinfo and >> getpeeredinfo that what is the best type of referral for its use; an >> IP address (for legacy apps and for opportunistic >> connections), HI or HIT. >> >> Thomas, you did mention anything about the opportunistic mode in your >> comments which was the main motivator for the ED in the draft. I >> believe the draft addresses this problem in a clean way with the EDs as >> discussed in sections 1, 2.4 and 3.1. > > Can't you simply connect(*, locator) where * is a wildcard value for the > HIT? Unfortunately no, because the standard connect system call inputs only a single socket address structure. Creating a new connect2 call (and sendv, sendto, sendmsg) is not good for backwards compatibility. Also, I don't think that using a socket address structure that contains both the identifier and the locator is a good solution either because the locator can get depracated quite soon. The draft specifies the opportunistic style connect() in section 3.1 with SHIM_ED_ANY (it can be used also by clients, not only by servers, will be fixed in the next version). The same flag can already be set in the resolution step with AI_ED_ANY when the application does not want to tweak with connect() (please see the fourth bullet). >>> I think there are a few steps that are needed: >>> >>> 1) definition of a new address family (AF_HOST) that allows >>> for the application to signal to the system that the quantity >>> being passed at the application is a host identifier. Ideally, >>> this should explicitly allow users to specify hosts by HIT and >>> to allow IP addresses to be optionally (additionally) passed >>> as hints. Wildcard values should also be supported. >> >> Please see above my comments regarding to the use of HITs. >> >> The draft already contains PF_SHIM (never mind about the difference >> between AF and PF, it has been already broken). Wildcard values are >> supported as described in section 3.1. "Automatic" HIT + IP mappings >> are supported by the resolver and can be manually configured as show in >> section 3.2.1. >> >>> (I don't know about Pekka's suggestion to pass the full HI; I'm >>> not sure why that is needed) >> >> Application can query for full local or peer HIs using the functions in >> section 3.2.3. > > again, I am not sure of the utility, since a HIT uniquely refers to a > HI, and the base exchange provides the HI. Let's think about it this way: do you think that there is absolutely no need for a HIP-aware application to know the whole HI? >>> 2) there should be a set of flags and policy attributes (sec 3.2.4) >>> that should be settable via the equivalent of setsockopt(). I am >>> not sure about all of the list of options in Table 2, though. For >>> instance, setting the ESP transform is not something that is done >>> at the sockets API but at other APIs like PFKEY. >> >> The ESP transforms belong to the BTNS API draft. The BTNS security >> options won't be settable with setsockopt() but rather "wrapper >> functions for setsockopt". >> >>> After reaching the above two milestones, an application that is >>> HIP aware could cleanly use the sockets API with HITs. The next >>> step might be to consider how to generalize it to allow for LSIs >>> (endpoint descriptors) and for advanced functionality like allowing >>> an application to register its own application-specific host >>> identity for use on the socket, but the use cases should be clearly >>> described and agreed before venturing down that path, and >> consideration >>> made as to whether sockets API or another API is the right choice. >> >> I don't see how burdening a HIP aware application with LSIs, HIT128, >> HIT256 and HIs is going to make it modular. I think a single "blob" >> identifier would make things easier. Think about forwards compatibility >> with other protocols supporting identity locator split (see >> SHIM_AF_FAMILY in section 3.2.4). >> >> The application specific identifiers are already handled in >> section 3.2.2. > > I think if we go down this path, we need to consider more broadly than > HIP what are the implications of making applications work on the basis > of LSIs. Maybe the application community can be consulted. Are you suggesting a cross-area review from applications area? -- 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 Sun Apr 29 11:14:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiB6B-0008Ap-P9; Sun, 29 Apr 2007 11:14:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiB6A-0008Ak-6Z for hipsec@ietf.org; Sun, 29 Apr 2007 11:14:02 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiB68-0003bb-Lr for hipsec@ietf.org; Sun, 29 Apr 2007 11:14:02 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 0E0182D86; Sun, 29 Apr 2007 18:14:00 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.8-niksula20070322 (2007-02-13) 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.8-niksula20070322 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 4D54B2C8F; Sun, 29 Apr 2007 18:13:59 +0300 (EEST) Date: Sun, 29 Apr 2007 18:13:59 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Andrew McGregor Subject: Re: [Hipsec] comments on native HIP API draft In-Reply-To: Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D040492B6@XCH-NW-5V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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 Fri, 27 Apr 2007, Andrew McGregor wrote: >> I didn't draw the same conclusion. The shim6 API draft talks >> about HIP, the HIP API draft talks about shims. They don't seem >> to be consistent either; the shim6 draft talks about EIDs, ULIDs, >> and HITs, while the HIP draft talks about endpoint descriptors >> (EDs). Even the document titles seem to be very close: >> "Native API for SHIM Layer Protocols" and "Socket API for >> Multihoming Shim". Maybe the socket options are split out >> between the two drafts, but there seems to me to be a clear >> relationship. > > I agree about the consistency: there should be one set of terminology. > As it is, these documents would make very confusing manual entries for > the APIs. Ok. >> For instance, I can imagine that I might want to assign a >> name such as "my work laptop" to a host and have that mapped >> locally to a lower-level identifier somewhere locally on my system, >> but resolving that might not be the job of the socket API but >> rather something like the resolver. > > I rather agree; and additionally, it seems to require greater refactoring of > an application to make it support EDs rather than go with the existing design > of passing around struct hostent *s... especially if the application already > supports IPv6, because adding a third address family is much easier than > adding the second. In contrast to draft-00 version, I tried to minimize the cost of converting an IPv6 application to use the SHIM extensions. For example, a client application simply needs to add a AI_ED flag to getaddrinfo() in order to resolve endpoint descriptors. >> I think there are a few steps that are needed: >> >> 1) definition of a new address family (AF_HOST) that allows >> for the application to signal to the system that the quantity >> being passed at the application is a host identifier. Ideally, >> this should explicitly allow users to specify hosts by HIT and >> to allow IP addresses to be optionally (additionally) passed >> as hints. Wildcard values should also be supported. >> >> (I don't know about Pekka's suggestion to pass the full HI; I'm >> not sure why that is needed) > > At this level I think the API should require at least one locator in a > connect(), because the 'how do you look up a HIT' question is still > unresolved; I think it should be done within the resolver, not below the > sockets API. I don't see a clear way of passing a locator in the existing connect() call as discussed in the previous email, but I agree that the HIT-lookup is a task for resolver. >> 2) there should be a set of flags and policy attributes (sec 3.2.4) >> that should be settable via the equivalent of setsockopt(). I am >> not sure about all of the list of options in Table 2, though. For >> instance, setting the ESP transform is not something that is done >> at the sockets API but at other APIs like PFKEY. > > But setting a TLS crypto option is done using a library-specific handle that > eventually points at a socket. I think setting transform options is better > done with setsockopt(), simply because otherwise the application has to do a > whole lot more work to get a handle in another API for something it already > has a pointer to, namely the socket. I will remove the this part from the next version of the draft as a better place for it is the BTNS draft. >> After reaching the above two milestones, an application that is >> HIP aware could cleanly use the sockets API with HITs. The next >> step might be to consider how to generalize it to allow for LSIs >> (endpoint descriptors) and for advanced functionality like allowing >> an application to register its own application-specific host >> identity for use on the socket, but the use cases should be clearly >> described and agreed before venturing down that path, and consideration >> made as to whether sockets API or another API is the right choice. > > Can't we just assign application specific identities with bind()? That would > seem most in line with the existing API. So to make a connection using an > app specific identity, you make a socket, bind it to the app identity, > resolve the peer, and call connect with the results. I am not sure if bind() is the right place to do this. Socket address structures are constrained by size and passing private keys inside socket address structures does not work when private keys are large. The draft specifies in section 3.2.2 to first associate the private key with an ED using a function call and then to pass the ED to bind(). I think ED concept would be useful also with smart cards that do not pass the whole private key but just sign or verify data. The ED could be used to enforce access control mechanism in such a system. However, I think this is out of scope for the draft. -- 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 Sun Apr 29 19:09:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiIWL-0007mn-UC; Sun, 29 Apr 2007 19:09:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiIWK-0007mh-Jt for hipsec@ietf.org; Sun, 29 Apr 2007 19:09:32 -0400 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 1HiIWI-0003CP-4n for hipsec@ietf.org; Sun, 29 Apr 2007 19:09:32 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l3TN9SUY013581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 29 Apr 2007 16:09:28 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l3TN9S0C000688; Sun, 29 Apr 2007 18:09:28 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l3TN9Rkv000679; Sun, 29 Apr 2007 18:09:27 -0500 (CDT) 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); Sun, 29 Apr 2007 16:09:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 29 Apr 2007 16:09:27 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D040492BD@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on native HIP API draft Thread-Index: AceKaT2PPqvGJinCQlen7IBYResCxgARrJjA From: "Henderson, Thomas R" To: "Miika Komu" X-OriginalArrivalTime: 29 Apr 2007 23:09:27.0458 (UTC) FILETIME=[6F4F1020:01C78AB3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: hipsec@ietf.org Subject: [Hipsec] RE: comments on native HIP API 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 > -----Original Message----- > From: Miika Komu [mailto:miika@iki.fi]=20 > (snip) > >> > >> Thomas, you did mention anything about the opportunistic=20 > mode in your=20 > >> comments which was the main motivator for the ED in the draft. I=20 > >> believe the draft addresses this problem in a clean way=20 > with the EDs as=20 > >> discussed in sections 1, 2.4 and 3.1. > > > > Can't you simply connect(*, locator) where * is a wildcard=20 > value for the > > HIT? >=20 > Unfortunately no, because the standard connect system call=20 > inputs only a=20 > single socket address structure. Creating a new connect2 call=20 > (and sendv,=20 > sendto, sendmsg) is not good for backwards compatibility.=20 > Also, I don't=20 > think that using a socket address structure that contains both the=20 > identifier and the locator is a good solution either because=20 > the locator=20 > can get depracated quite soon. >=20 > The draft specifies the opportunistic style connect() in=20 > section 3.1 with=20 > SHIM_ED_ANY (it can be used also by clients, not only by=20 > servers, will be=20 > fixed in the next version). The same flag can already be set in the=20 > resolution step with AI_ED_ANY when the application does not=20 > want to tweak=20 > with connect() (please see the fourth bullet). I think that there may be other more explicit options available to solve this problem that do not require going with an abstract ED just to fit it into the size of a sockaddr. =20 For instance, there could locally be defined some kind of ORCHID wildcard that fits into the sockaddr_in6, and it could be preceded by setsockopt(LOCATOR) of some sort. >=20 > >>> I think there are a few steps that are needed: > >>> > >>> 1) definition of a new address family (AF_HOST) that allows > >>> for the application to signal to the system that the quantity > >>> being passed at the application is a host identifier. Ideally, > >>> this should explicitly allow users to specify hosts by HIT and > >>> to allow IP addresses to be optionally (additionally) passed > >>> as hints. Wildcard values should also be supported. > >> > >> Please see above my comments regarding to the use of HITs. > >> > >> The draft already contains PF_SHIM (never mind about the=20 > difference=20 > >> between AF and PF, it has been already broken). Wildcard=20 > values are=20 > >> supported as described in section 3.1. "Automatic" HIT +=20 > IP mappings=20 > >> are supported by the resolver and can be manually=20 > configured as show in=20 > >> section 3.2.1. > >> > >>> (I don't know about Pekka's suggestion to pass the full HI; I'm > >>> not sure why that is needed) > >> > >> Application can query for full local or peer HIs using the=20 > functions in=20 > >> section 3.2.3. > > > > again, I am not sure of the utility, since a HIT uniquely=20 > refers to a=20 > > HI, and the base exchange provides the HI. >=20 > Let's think about it this way: do you think that there is=20 > absolutely no=20 > need for a HIP-aware application to know the whole HI? Regardless of whether the HIP aware application needs to know the HI, it is not clear to me why the HI must be passed to the system instead of just the HIT. >=20 > >>> 2) there should be a set of flags and policy attributes=20 > (sec 3.2.4) > >>> that should be settable via the equivalent of setsockopt(). I am > >>> not sure about all of the list of options in Table 2, though. For > >>> instance, setting the ESP transform is not something that is done > >>> at the sockets API but at other APIs like PFKEY. > >> > >> The ESP transforms belong to the BTNS API draft. The BTNS security > >> options won't be settable with setsockopt() but rather "wrapper > >> functions for setsockopt". > >> > >>> After reaching the above two milestones, an application that is > >>> HIP aware could cleanly use the sockets API with HITs. The next > >>> step might be to consider how to generalize it to allow for LSIs > >>> (endpoint descriptors) and for advanced functionality=20 > like allowing > >>> an application to register its own application-specific host > >>> identity for use on the socket, but the use cases should=20 > be clearly > >>> described and agreed before venturing down that path, and > >> consideration > >>> made as to whether sockets API or another API is the right choice. > >> > >> I don't see how burdening a HIP aware application with=20 > LSIs, HIT128,=20 > >> HIT256 and HIs is going to make it modular. I think a=20 > single "blob"=20 > >> identifier would make things easier. Think about forwards=20 > compatibility=20 > >> with other protocols supporting identity locator split (see=20 > >> SHIM_AF_FAMILY in section 3.2.4). > >> > >> The application specific identifiers are already handled in > >> section 3.2.2. > > > > I think if we go down this path, we need to consider more=20 > broadly than > > HIP what are the implications of making applications work=20 > on the basis > > of LSIs. Maybe the application community can be consulted. >=20 > Are you suggesting a cross-area review from applications area? >=20 One possible first step might be to raise the question on the applications area mailing list about the possible benefits and costs of making the long-term HIP API based on locally-scoped handles to addresses/identities. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 30 04:30:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiRHC-0008TN-I2; Mon, 30 Apr 2007 04:30:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiRHA-0008TI-Py for hipsec@ietf.org; Mon, 30 Apr 2007 04:30:28 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiRH9-00069q-Ev for hipsec@ietf.org; Mon, 30 Apr 2007 04:30:28 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id C5B822DB5; Mon, 30 Apr 2007 11:30:26 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.8-niksula20070322 (2007-02-13) 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.8-niksula20070322 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 536DD2DAA; Mon, 30 Apr 2007 11:30:26 +0300 (EEST) Date: Mon, 30 Apr 2007 11:30:26 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: "Henderson, Thomas R" In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D040492BD@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D040492BD@XCH-NW-5V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: hipsec@ietf.org Subject: [Hipsec] RE: comments on native HIP API 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 On Sun, 29 Apr 2007, Henderson, Thomas R wrote: > I think that there may be other more explicit options available to solve > this problem that do not require going with an abstract ED just to fit > it into the size of a sockaddr. > > For instance, there could locally be defined some kind of ORCHID > wildcard that fits into the sockaddr_in6, and it could be preceded by > setsockopt(LOCATOR) of some sort. Yes, this is possible. I'd also allow this behaviour from the resolver. This kind of identifier cannot be used as a referral anymore, hence it is a locally scoped identifier within the host. Seems like a shift towards the LSI/ED approach. (We need an additional function call to query for the actual channel bindings when connect() returns.) I think it would be easier (KISS!) to have only single kind of identifiers in the native APIs: either referral-capable or locally-scoped identifiers. Mixing referrals and LSIs/EDs in the API will be confusing for the developer. Since the referral case simply does not work with opportunistic mode, I'd exclude referrals out and stick to the local scope. If you agree on the locally scope identifiers, the next thing is the format of the locally scoped identifiers: do the identifiers need to look like IP addresses or not? Locally scoped IP-address-like identifiers present bogus information to the application, or at least I don't see any benefit from such a information to HIP-aware applications. It could even lead to security problems when a misguided developer starts to use them in access control lists. >> Are you suggesting a cross-area review from applications area? >> > > One possible first step might be to raise the question on the > applications area mailing list about the possible benefits and costs of > making the long-term HIP API based on locally-scoped handles to > addresses/identities. Ok. -- 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 Mon Apr 30 08:58:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiVSn-0007jt-6M; Mon, 30 Apr 2007 08:58:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiVSl-0007bZ-Ij for hipsec@ietf.org; Mon, 30 Apr 2007 08:58:43 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiVSk-0008F3-8c for hipsec@ietf.org; Mon, 30 Apr 2007 08:58:43 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l3UCwWT6029966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 30 Apr 2007 05:58:36 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l3UCwWnt021263; Mon, 30 Apr 2007 05:58:32 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l3UCwSGS021178; Mon, 30 Apr 2007 05:58:32 -0700 (PDT) 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, 30 Apr 2007 05:58:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Apr 2007 05:58:29 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D040492BF@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on native HIP API draft Thread-Index: AceLAc8lDA/ni4DJRlSyHYPANKBK7gAImMsg From: "Henderson, Thomas R" To: "Miika Komu" X-OriginalArrivalTime: 30 Apr 2007 12:58:29.0721 (UTC) FILETIME=[40020C90:01C78B27] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: hipsec@ietf.org Subject: [Hipsec] RE: comments on native HIP API 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 =20 > -----Original Message----- > From: Miika Komu [mailto:miika@iki.fi]=20 > Sent: Monday, April 30, 2007 1:30 AM > To: Henderson, Thomas R > Cc: hipsec@ietf.org > Subject: RE: comments on native HIP API draft >=20 > On Sun, 29 Apr 2007, Henderson, Thomas R wrote: >=20 > > I think that there may be other more explicit options=20 > available to solve > > this problem that do not require going with an abstract ED=20 > just to fit > > it into the size of a sockaddr. > > > > For instance, there could locally be defined some kind of ORCHID > > wildcard that fits into the sockaddr_in6, and it could be=20 > preceded by > > setsockopt(LOCATOR) of some sort. >=20 > Yes, this is possible. I'd also allow this behaviour from the=20 > resolver. >=20 > This kind of identifier cannot be used as a referral anymore,=20 > hence it is=20 > a locally scoped identifier within the host. Seems like a=20 > shift towards=20 > the LSI/ED approach. (We need an additional function call to=20 > query for the=20 > actual channel bindings when connect() returns.) I think there is a difference here-- it is not an identifier, it is explicitly a wildcard. The locator could be used in a referral. The main issue here seems to be whether we want to move to a long-term API based on LSIs. I think you identified a potential benefit: that it would make the API future-proof against changes to the HIT size. Similarly, one might argue that the IPv6 transition would have been a lot easier for applications if the concept of endpoint descriptor were already available for the past twenty years; IPv6 could have been hidden in the system. This latter observation makes me wonder whether there have been such considerations previously in the applications area. =20 Therefore, it seems like asking a question like the following would be helpful: "We are contemplating a level of indirection in naming hosts to future-proof the HIP API. One could conceive that such a level of indirection could be used more generally outside of HIP, to enable applications to be more compatible across IP versions, for instance. What are the benefits and costs that you see about migrating the basic socket API calls towards end-system handles rather than explicit end-system addresses?" Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec