From hipsec-bounces@lists.ietf.org Sat Jan 05 04:35:28 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JB5R4-0006Jj-PH; Sat, 05 Jan 2008 04:35:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JB5R3-0006Jd-9T for hipsec@ietf.org; Sat, 05 Jan 2008 04:35:21 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JB5R2-0000hu-Ul for hipsec@ietf.org; Sat, 05 Jan 2008 04:35:21 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 315F02C56; Sat, 5 Jan 2008 11:35:20 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 3D3002CB2 for ; Sat, 5 Jan 2008 11:35:11 +0200 (EET) Date: Sat, 5 Jan 2008 11:35:11 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: hipsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Hipsec] Traffic visibility using IPsec ESP NULL encryption 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, A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Traffic visibility using IPsec ESP NULL encryption Author(s) : K. Grewal, et al. Filename : draft-grewal-ipsec-traffic-visibility-00.txt Pages : 8 Date : 2008-1-3 This document describes leveraging UDP encapsulation for IPsec, using ESP NULL encryption in order for intermediary devices to inspect the IPsec packets. Currently in the IPsec standard, there is no way to differentiate between ESP encryption and ESP NULL encryption by simply examining a packet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-grewal-ipsec-traffic-visibility-00.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 Sat Jan 05 08:43:10 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JB9Iq-00007X-SB; Sat, 05 Jan 2008 08:43:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JB9Ip-0008Sa-Mv for hipsec@ietf.org; Sat, 05 Jan 2008 08:43:07 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JB9Ip-0004zz-87 for hipsec@ietf.org; Sat, 05 Jan 2008 08:43:07 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 643CE2C82; Sat, 5 Jan 2008 15:43:06 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 3591F2D4A for ; Sat, 5 Jan 2008 15:42:57 +0200 (EET) Date: Sat, 5 Jan 2008 15:42:56 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: hipsec@ietf.org Subject: Re: [Hipsec] Traffic visibility using IPsec ESP NULL encryption In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 On Sat, 5 Jan 2008, Miika Komu wrote: > FYI, > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Traffic visibility using IPsec ESP NULL encryption > Author(s) : K. Grewal, et al. > Filename : draft-grewal-ipsec-traffic-visibility-00.txt > Pages : 8 > Date : 2008-1-3 > > This document describes leveraging UDP encapsulation for IPsec, using > ESP NULL encryption in order for intermediary devices to inspect the > IPsec packets. Currently in the IPsec standard, there is no way to > differentiate between ESP encryption and ESP NULL encryption by > simply examining a packet. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-grewal-ipsec-traffic-visibility-00.txt There seemed to be another draft which might interest some folks: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : IPsec Extensions to Support Robust Header Compression over IPsec (RoHCoIPsec) Author(s) : E. Ertekin, et al. Filename : draft-ietf-rohc-ipsec-extensions-hcoipsec-01.txt Pages : 10 Date : 2008-1-4 Integrating RoHC with IPsec (RoHCoIPsec) offers the combined benefits of IP security services and efficient bandwidth utilization. Before this can be realized, however, several extensions to the Security Policy Database (SPD), the Security Association Database (SAD), and the IPsec process are required. This document describes the IPsec extensions required to support RoHCoIPsec. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-ipsec-extensions-hcoipsec-01.txt P.S. Sorry, perhaps hipsec-rg would have been a better channel for these. -- 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 Sat Jan 05 13:51:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBE7I-0000tw-0f; Sat, 05 Jan 2008 13:51:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBE7G-0000tR-MR for hipsec@ietf.org; Sat, 05 Jan 2008 13:51:30 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBE7E-0006vW-5F for hipsec@ietf.org; Sat, 05 Jan 2008 13:51:30 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 316FD2C7D; Sat, 5 Jan 2008 20:51:27 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 856B62D5C; Sat, 5 Jan 2008 20:51:17 +0200 (EET) Date: Sat, 5 Jan 2008 20:51:17 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: "Henderson, Thomas R" Subject: RE: [Hipsec] WGLC: draft-ietf-hip-native-api-03.txt In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D04049A98@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: References: <474DDBFA.1050509@ericsson.com> <77F357662F8BFA4CA7074B0410171B6D04049A98@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: a1dc446dc7ac353b90b60743d0e479e3 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 Tue, 18 Dec 2007, Henderson, Thomas R wrote: >> -----Original Message----- >> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >> Sent: Wednesday, November 28, 2007 1:22 PM >> To: HIP >> Subject: [Hipsec] WGLC: draft-ietf-hip-native-api-03.txt >> >> Folks, >> >> I would like to WGLC the following draft: >> http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-03.txt >> >> This WGLC will end on December 19th. >> >> Send your comments to the author and this list. >> >> Thanks, >> >> Gonzalo >> HIP co-chair >> > > Miika, > Here are some more comments. In summary, I'd like to see more work on > this draft on some points below. Tom, thanks for the comments. Please notice that some of the comments were already addressed in the draft-ietf-hip-native-api-04-pre1 which I had posted to the mailing list in the beginning of December: http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-04-pre1.txt Tom, I updated the version based on your comments. The new draft is found from here: http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-04-pre2.txt Please have a look at the up-to-date version and check if it is ok. More comments below. > Overall > ======== > > I still don't think the document gives enough guidance to the > implementor about where various aspects of HIP-related API are defined > (there are two other API documents in shim6 and BTNS WGs). > Specifically, the shim6 API draft specifies new socket options > applicable to shim6 and HIP, but some of them are not applicable when > using PF_HIP. I would like to see more clearly stated which shim6 > options from Table 1 of the shim6 document are applicable/invalid when > using PF_HIP. I think this should be added to the SHIM6 draft or to a separate draft for the following reasons: * I think it is out of scope when the abstract (and not the title :) of draft is conserned. * The draft only requires only two simple socket options from the shim6 document. Editorialwise, I believe it is a good idea to avoid intertwining the two drafts too much. * The scope of applicability is not clear yet (consider e.g. reap) and I think this needs to mature a bit. > So I would like to see more explicit guidance of the form; e.g.: > - this document specifies extensions to RFC3493 and 3542 to define a new > socket address family and describe how the socket calls in those RFCs > are adapted or extended as a result Agree on RFC3493, but I am not convinced yet that RFC3542 has much to do with this draft. I fitted your comments to one paragraph in the intro: "This document specifies extensions to RFC3493 to define a new socket address family, AF_HIP. The macro PF_HIP is used as an alias for AF_HIP in this document because the distinction between PF and AF has been lost in the practice. The extensions also describe a new socket address structure for sockets using Host Identity Tags (HITs) explicitly and describe how the socket calls in "RFC3493 are adapted or extended as a result." > - socket options for use with PF_HIP/PF_INET6 sockets are defined in the > [shim6-api], and section X.X of this document clarifies which options > are applicable to PF_HIP sockets. I disagree on this, see above. > - this document relates to the RFC5014 as follows... > - APIs to manipulate IPsec bindings are defined in [btns-api]... There are two related API documents. Multihoming and explicit locator-handling related APIs are defined in [I-D.ietf-shim6-multihome-shim-api]. IPsec related policy attributes and channel bindings APIs are defined in [I-D.ietf-btns-c-api]. The extensions defined in this document can be used independently of the two mentioned related API documents. > Andrew also pointed out the need to align with or extend RFC5014 (source > address selection). I'll address these commments in a separate thread. > The introduction should clearly state a design assumption: > "This API allows a HIP-aware application to use the sockets API > independent of any handling of IP addresses, but also allows an > application to use HIP names in conjunction with IP addresses if so > desired. As a result, this API implies that the system may need to > resolve HIP names to IP addresses, and describes how a system resolver > might be able to cache such bindings during the name resolution > process." I believe this was stated already at least in draft-ietf-hip-native-api-04-pre1: The extensions in this document focus on the use of the resolver to map host names to HITs and locators in HIP-aware applications. The resolver associates implicitly the the HIT with the locator(s). However, it is possible that an application operates directly with a peer HIT without interacting with the resolver. In such a case, the application may resort to the system to map the peer HIT to an IP address. Alternatively, the application can explicitly map the HIT to an IP address as specified in [I-D.ietf-shim6-multihome-shim-api] using the socket options SHIM_LOC_LOCAL_PREF and SHIM_LOC_PEER_PREF. "How a system resolver might be able to cache such bindings" sounds more like implementation issue but I added a clarification into section "Interaction with the Resolver": The resolver associates implicitly the HIT with the locator(s) by e.g. communicating the association to the HIP daemon. > In section 4.1: > "The HIT value is an IPv6 address and it is stored in network byte > order." I disagree, and I think other reviewers will too. HITs are not > IPv6 addresses. Corrected to: "The ship_hit is the size of an IPv6 address and it is stored in network byte order." > In section 4.3 (page 8) the document starts talking about ORCHIDs, in a > manner that suggests at first glance that they are distinct from HITs. I changed the text to this: The HIP_HIT_ANY_* macros reject non-HIP based communications. To distinguish between HIP and non-HIP-based communications in the case of the HIP_ADDR_ANY macro, the application calls getsockname() and getpeername() to discover the actual identifiers used for the communications and verifies the prefix with HIP_IS_ORCHID macro. .. > I think I understand what you are trying to do here, but I am not sure > it is the right way. If I understand correctly, you are allowing to > bind sockets to wildcarded HIT macros, but then allowing the system to > accept the communications even if it is not a HIT but is instead an IPv6 > address, unless it sets a flag to "ONLY_ORCHID" in the ship_flags > (although it is unclear which socket call requires this flag to be set). I move the ONLY_ORCHID flag functionality to the HIP_ADDR_ANY macro (seemed to be a more right way to do it): The application can use the HIP_HIT_ANY_* and HIP_ADDR_ANY macros to accept incoming communications to all of the HITs of the local host. Incoming communications refers here to the functions such as bind(), recvfrom() and recvmsg(). The HIP_HIT_* macros correspond to the sockets API macros INADDR_ANY and IN6ADDR_ANY_INIT, but they are applicable at the HIP layer. After initial contact with the peer, the local and peer HITs can be discovered using getsockname() and getpeername() calls for connection oriented sockets. The difference between the use of the HIP_HIT_* and HIP_ADDR_ANY macros here is that the former allows only HIP-based communications but the latter also allows communications without HIP. The application also uses the HIP_HIT_ANY or HIP_ADDR_ANY macros in ship_hit field to establish outgoing communications in Opportunistic mode [I-D.ietf-hip-base], i.e., when the application knows the remote peer locator but not the HIT. Outgoing communications refers here to the use of functions such as connect(), sendto() and sendmsg(). However, the application must first associate the socket with at least one IP address of the peer using SHIM_LOC_PEER_PREF socket option. After initial contact with the peer, the application discovers local and peer HITs using getsockname() and getpeername() calls when it is using connection-oriented sockets. The difference between the use of the HIP_HIT_ANY and HIP_ADDR_ANY macros here is that the former allows only HIP-based communications but the latter allows the socket to timeout and fall-back to communications without HIP. I believe it should be now clear from the context that which socket functions require the HIP_ADDR_ANY macro. > My opinion is that more work needs to be done on this part of the API. Please be more verbose or suggest some text if there is something more needed to the above texts. > I think you want to allow an application to set some wildcards in the > socket calls and possibly permit the socket to open if the peer does not > support HIP but is reachable via IPv6. I think there will need to be > some care taken to not violate semantics since we are mixing address > families at this point. The locator and its family is not actually visible to the application when it is using the wildcards. Also, I don't see why we should constrain only only to IPv6-based locators. > Regarding the last paragraph of section 4.1, some systems support > accept_filters that allow the system to do the access controls-- do we > want to specify the same here? This was new to me. Added a small note about this even though I am not sure yet how relevant this is: Applications may rely on system level access control, either implicit or explicit (such as accept_filter function() found on BSD-based systems), but such discussion is out of scope. However, applications can also implement access control themselves by using the HITs. > In section 4.2 (resolver extensions), the description implies that a > resolver will have to do two queries (nodename to HITs and nodename to > IP addresses), and concatenate the results in the rres field, before > returning from getaddrinfo(). Shouldn't the application instead issue > two getaddrinfo's for each of the different queries? Why complicate things unnecessarily for the developer? The current API is designed so that it can be used in existing apps with minimal changes (i.e. by adding some flags). See e.g. some example code from the FreeBSD man pages: http://www.freebsd.org/cgi/man.cgi?query=getaddrinfo&sektion=3&apropos=0&manpath=FreeBSD+6.2-RELEASE Is there a good reason for doing it this way? If the small delay of DNS is problem, this can certainly parallelized, but that is an implementation issue. > Section 4.3 first paragraph could perhaps be developed further. Maybe > it warrants another major section in the document. I think this comment is too generic for me to write anything concrete. Please suggest some text. > Also, I did not quite understand the placement of the second paragraph > in this section. It seems like this guidance (what error to return if > the HIT cannot be resolved) is more appropriate somewhere in Section > 4.1. Moved to the end of section 4.1. > Editorial > ========== > > The last sentence of the abstract has some missing words. > > Generally, Terminology section follows the Introduction. Moved. > It seemed to me that the third paragraph of the Introduction might be > the one that you want to lead with. Ok. > I do not think that "HIP Layer" row needs to be in Table 2. To me, this > is akin to saying that there is an "ARP Layer" between Network and Link > layer, and that is not how ARP is commonly depicted in the stack. I think the uninitiated reader will question the presence of HIP in the stack if we remove it. Anyway, I think the whole section 3.1 is rather uninformative so I have removed it from the draft. Is this ok? (As a side effect, I moved "Interaction with the Resolver" section upwards to replaced "Design Model" because it was the only section in the main section. > I was surprised that there was no reference to the HIP DNS draft since > this is heavily based on HIP DNS resolution. It was probably removed when I removed one section based on some comments in an earlier version. Reintroduced now the reference to the beginning of the intro. > In the paragraph after figure 2: > s/published or not, but that/published or not, but note that/ > > I thought that we agreed to delete the "IPV6_ADDR" portion from the > macro HIP_IS_IPV6_ADDR_ANON_HIT? This was already fixed in draft-ietf-hip-native-api-04-pre1. > For document title, I would suggest changing from: > Native Application Programming Interfaces (APIs) for Host Identity > Protocol (HIP) to Basic Socket Interface Extensions for Host Identity > Protocol (HIP) which would align the title with RFC 3493. Fine by me. I changed the abbreviation also to "Basic API Extensions for HIP". I won't change the name of the file, though. > Lingering comment from my previous post > ========= > >>>> Both of these two approaches may be more prone to errors >>>> than the use >>>> resolver with host names. Hence, HIP-aware applications should >>>> prefer to use the resolver with host names. >>> >>> Can you specify which errors the resolver-less approach is >> more prone >>> to? >> >> The main concern is wow to map a HIT to an IP address in the >> current state >> of HIP deployment in DNS. Do you suggest to move the last two >> sentences? > > I just want to understand what the assumed error risk is. You seem to > be saying that indirecting through the DNS is less error prone than > directly providing the HIT to IP address binding at the API. Is that > because you are assuming that handling HITs is an error prone operation > (as compared with DNS names) for either applications or users? > > I think it should either be more specified to state what the presumed > error is, or else remove the last two sentences. This was already removed in draft-ietf-hip-native-api-04-pre1. Thanks for the feedback! -- 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 Jan 07 03:31:51 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBnOf-0001hL-TK; Mon, 07 Jan 2008 03:31:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J67Gy-0006cA-8s for hipsec@ietf.org; Sat, 22 Dec 2007 11:32:24 -0500 Received: from py-out-1112.google.com ([64.233.166.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J67Gx-0001zV-Pc for hipsec@ietf.org; Sat, 22 Dec 2007 11:32:24 -0500 Received: by py-out-1112.google.com with SMTP id d32so3353028pye.12 for ; Sat, 22 Dec 2007 08:32:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=ck3HNiGYjC0o+VVkZP2e7F+1lZ6Ohg1tdadkuRjZTfQ=; b=JgJ7LyFurEma/RLs069BDkMWnpS/6BitiKYByMRiQs0VV2Mg6+JdW7BACarnFwUbhfHV4QUfQLeAxdxJW5lEgPIUJDH5KAmwlDayeZRfPdxM6+NGEcnpGPTu8mvF/uQ+P0bzbvs2AhcsA6t3KWsDqf2tvaLOk1ziXe5OeWVAeD4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=s9Lfimooi9V6a2eGkqt++veA3FUqoMiYIB+LuGSH7wnB9xflSOA0MoQFHZDxsGhEd9QMfWqenOZhsyJ9H3VG/WMrazFAvvaeKATkMsA6e6eX7iC9E7lPt70pp3oYT3tuSAF2kF9nDCl6BHL6hyMiCGgxBZj0wrau1wX7DB3XSmw= Received: by 10.65.239.14 with SMTP id q14mr3557363qbr.77.1198341142520; Sat, 22 Dec 2007 08:32:22 -0800 (PST) Received: by 10.65.180.16 with HTTP; Sat, 22 Dec 2007 08:32:22 -0800 (PST) Message-ID: <4d4304a00712220832g4b8b7cedh9fdeb3572a1d0c9f@mail.gmail.com> Date: Sat, 22 Dec 2007 11:32:22 -0500 From: "David A. Bryan" To: "Paine, Richard H" In-Reply-To: <4d4304a00712220831m7ac65f95j9ea045bd0a1e7136@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <0C549DAFE1A8004D8EB57ACDD108646D070BA68B@XCH-NW-2V2.nw.nos.boeing.com> <4d4304a00712220831m7ac65f95j9ea045bd0a1e7136@mail.gmail.com> X-Google-Sender-Auth: 721d57022a9ac413 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-Mailman-Approved-At: Mon, 07 Jan 2008 03:31:47 -0500 Cc: hipsec@ietf.org, p2psip@ietf.org Subject: [Hipsec] Re: [P2PSIP] P2PSIP and HIP Joint Meeting on the Boeing VOIP HIPImplementation 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 ...and now as an individual...thanks for organizing this and I look forward to the call! David On Dec 22, 2007 11:31 AM, David A. Bryan wrote: > Just a clarification here for process purposes -- the meeting in the > hall was NOT a joint meeting of the WGs -- just an informal in > the-hall meeting of (a small number of) interested folks from both > P2PSIP and HIP WGs working to ensure folks in P2PSIP better understand > the HIP proposals so they were more informed about HIP and could make > a better decision about HIPs applicability (or non-applicability) to > P2PSIP. This meeting is a part of that process for the HIP folks -- in > an organized way and encouraged by the chairs -- to make the pitch, so > the P2PSIP WG can decide what they want to do/not do with respect to > HIP going forward. > > Just wanted it to be very clear that neither the in hall group nor > this call are official WG meetings in any way -- just groups of > interested folks. (I'd hate to see all 200+ P2PSIP folks packed into a > hallway...) > > David (as chair) > > > On Dec 21, 2007 5:54 PM, Paine, Richard H wrote: > > When: Tuesday, January 08, 2008 8:00 AM-9:30 AM (GMT-08:00) Pacific Time (US & Canada). > > > > Where: Virtual (866-752-6974 Passcode: 9710856# > > > > *~*~*~*~*~*~*~*~*~* > > > > The teleconference is per a meeting at the Vancouver IETF on Friday, Dec 7, 2007 that was a joint meeting of the HIP and P2PSIP Working Groups. The joint meeting determined the need to look at the Boeing demonstration of SIP over HIP. The demonstration used an IEEE802.11-WPA-wireless connection to the Boeing Intranet and the SIP call traversed both the wireless and wired network securely to get to a wired laptop. The call occurred in a HIP namespace using a cryptographic identity as an SPI value in the ESP field. > > > > This teleconference is being held to discuss the white paper on the demonstration and the use of HIP for secure point-to-point SIP. > > > > Teleconference Details: > > > > Date: Tuesday, January 8, 2008 Starting time: 8:00 pm, Pacific Standard Time (GMT -08:00, San Francisco) Duration: 1 hour 30 minutes Meeting number: 896 132 416 Meeting password: hipmeeting Teleconference: Dial-in:1-866-752-6974 (US) > > Leader passcode:9710856 > > Participant passcode:9710856 Host: Richard Paine Host's email address: richard.h.paine@boeing.com > > > > Richard H. Paine > > Success is getting what you want, happiness is liking what you get! > > Cell: 206-854-8199 > > IPPhone: 425-373-8296 > > Email: richard.h.paine@boeing.com > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > -- > David A. Bryan > dbryan@SIPeerior.com > +1.757.565.0101 x101 > +1.757.565.0088 (fax) > www.SIPeerior.com > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jan 07 03:31:51 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBnOf-0001hG-OI; Mon, 07 Jan 2008 03:31:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J67G0-0005QB-Pn for hipsec@ietf.org; Sat, 22 Dec 2007 11:31:24 -0500 Received: from py-out-1112.google.com ([64.233.166.181]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J67G0-0004Xn-8x for hipsec@ietf.org; Sat, 22 Dec 2007 11:31:24 -0500 Received: by py-out-1112.google.com with SMTP id d32so3351750pye.12 for ; Sat, 22 Dec 2007 08:31:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=FP1L9kwoSsWZ1r/97wrMJI8kXGynOaJALlZuEkZRf3E=; b=KEPUgRnntnFe5Ub6VB/RbaHZ9jHpyVkALuxGcfAf9EMVzVBOxI+qYDnpD3c0cWmaFNTL5WWwIV+5usZ6iqA5dwIJ4uTpppQTkzOHhekgEAa2WnGd4NH7rz8zr79Cs3WVKav4dVZzNs6IcYQeQ+Ie6CIqhdS1cti1a9w9zSBrDvQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=flTs7jmSeFQCs59OTALhgC+Oek4wTArXg9wMEYZqeFN5WTwZS+MGLimS1CSWKH8kmKKeYVscX2NyxmIsTW2iwjdBd5eYf6kAkp/iravhpTK0fkVthIoyTrLIXjf4iZsdGWaEWpuWROvreTZPfD3pmfSkiUlczL2k8Ur/2we8B4U= Received: by 10.65.59.11 with SMTP id m11mr3592687qbk.96.1198341082514; Sat, 22 Dec 2007 08:31:22 -0800 (PST) Received: by 10.65.180.16 with HTTP; Sat, 22 Dec 2007 08:31:22 -0800 (PST) Message-ID: <4d4304a00712220831m7ac65f95j9ea045bd0a1e7136@mail.gmail.com> Date: Sat, 22 Dec 2007 11:31:22 -0500 From: "David A. Bryan" To: "Paine, Richard H" In-Reply-To: <0C549DAFE1A8004D8EB57ACDD108646D070BA68B@XCH-NW-2V2.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <0C549DAFE1A8004D8EB57ACDD108646D070BA68B@XCH-NW-2V2.nw.nos.boeing.com> X-Google-Sender-Auth: e13aa50dcfe7e565 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-Mailman-Approved-At: Mon, 07 Jan 2008 03:31:47 -0500 Cc: hipsec@ietf.org, p2psip@ietf.org Subject: [Hipsec] Re: [P2PSIP] P2PSIP and HIP Joint Meeting on the Boeing VOIP HIPImplementation 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 Just a clarification here for process purposes -- the meeting in the hall was NOT a joint meeting of the WGs -- just an informal in the-hall meeting of (a small number of) interested folks from both P2PSIP and HIP WGs working to ensure folks in P2PSIP better understand the HIP proposals so they were more informed about HIP and could make a better decision about HIPs applicability (or non-applicability) to P2PSIP. This meeting is a part of that process for the HIP folks -- in an organized way and encouraged by the chairs -- to make the pitch, so the P2PSIP WG can decide what they want to do/not do with respect to HIP going forward. Just wanted it to be very clear that neither the in hall group nor this call are official WG meetings in any way -- just groups of interested folks. (I'd hate to see all 200+ P2PSIP folks packed into a hallway...) David (as chair) On Dec 21, 2007 5:54 PM, Paine, Richard H wrote: > When: Tuesday, January 08, 2008 8:00 AM-9:30 AM (GMT-08:00) Pacific Time (US & Canada). > > Where: Virtual (866-752-6974 Passcode: 9710856# > > *~*~*~*~*~*~*~*~*~* > > The teleconference is per a meeting at the Vancouver IETF on Friday, Dec 7, 2007 that was a joint meeting of the HIP and P2PSIP Working Groups. The joint meeting determined the need to look at the Boeing demonstration of SIP over HIP. The demonstration used an IEEE802.11-WPA-wireless connection to the Boeing Intranet and the SIP call traversed both the wireless and wired network securely to get to a wired laptop. The call occurred in a HIP namespace using a cryptographic identity as an SPI value in the ESP field. > > This teleconference is being held to discuss the white paper on the demonstration and the use of HIP for secure point-to-point SIP. > > Teleconference Details: > > Date: Tuesday, January 8, 2008 Starting time: 8:00 pm, Pacific Standard Time (GMT -08:00, San Francisco) Duration: 1 hour 30 minutes Meeting number: 896 132 416 Meeting password: hipmeeting Teleconference: Dial-in:1-866-752-6974 (US) > Leader passcode:9710856 > Participant passcode:9710856 Host: Richard Paine Host's email address: richard.h.paine@boeing.com > > Richard H. Paine > Success is getting what you want, happiness is liking what you get! > Cell: 206-854-8199 > IPPhone: 425-373-8296 > Email: richard.h.paine@boeing.com > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jan 08 03:04:24 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC9Rf-0004BW-9E; Tue, 08 Jan 2008 03:04:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBy76-0007MU-8k; Mon, 07 Jan 2008 14:58:24 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBy73-0007eJ-VU; Mon, 07 Jan 2008 14:58:24 -0500 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m07Jw8aE024092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 7 Jan 2008 13:58:10 -0600 In-Reply-To: <0C549DAFE1A8004D8EB57ACDD108646D06520831@XCH-NW-2V2.nw.nos.boeing.com> References: <0C549DAFE1A8004D8EB57ACDD108646D06520831@XCH-NW-2V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Mon, 7 Jan 2008 13:57:48 -0600 To: "Paine, Richard H" X-Mailer: Apple Mail (2.753) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-Mailman-Approved-At: Tue, 08 Jan 2008 03:04:21 -0500 Cc: "Brewer, Orlie T" , "Wang, Sherry" , p2psip@ietf.org, hipsec@ietf.org, Henry Sinnreich , "Venema, Steve A" , "David Ward \(wardd\)" , "Venema, Steven C" Subject: [Hipsec] Re: [P2PSIP] Updated: P2PSIP and HIP Joint Meeting on the Boeing VOIP HIPImplementation 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 Jan 7, 2008, at 9:37 AM, Paine, Richard H wrote: > I'll parse that for those whose software breaks on the attachment: ------ Just so everyone is clear - the teleconference is at 8am Pacific Time on Tuesday, Jan 8, 2008 at the following teleconference and Webex numbers. The teleconference is per a meeting at the Vancouver IETF on Friday, Dec 7, 2007 that was a joint meeting of the HIP and P2PSIP Working Groups. The joint meeting determined the need to look at the Boeing demonstration of SIP over HIP. The demonstration used an IEEE802.11- WPA-wireless connection to the Boeing Intranet and the SIP call traversed both the wireless and wired network securely to get to a wired laptop. The call occurred in a HIP namespace using a cryptographic identity as an SPI value in the ESP field. This teleconference is being held to discuss the white paper on the demonstration and the use of HIP for secure point-to-point SIP. Teleconference Details: Date: Tuesday, January 8, 2008 Starting time: 8:00 am, Pacific Standard Time (GMT -08:00, San Francisco) Duration: 1 hour 30 minutes Meeting number: 896 132 416 Meeting password: hip meeting Teleconference: Dial-in: 1-866-752-6974 (US) Participant passcode:9710856 Host: Richard Paine Host's email address: richard.h.paine@boeing.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jan 08 03:04:2From hipsec-bounces@lists.ietf.org Tue Jan 08 03:04:24 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC9Rf-0004BW-9E; Tue, 08 Jan 2008 03:04:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBy76-0007MU-8k; Mon, 07 Jan 2008 14:58:24 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBy73-0007eJ-VU; Mon, 07 Jan 2008 14:58:24 -0500 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m07Jw8aE024092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 7 Jan 2008 13:58:10 -0600 In-Reply-To: <0C549DAFE1A8004D8EB57ACDD108646D06520831@XCH-NW-2V2.nw.nos.boeing.com> References: <0C549DAFE1A8004D8EB57ACDD108646D06520831@XCH-NW-2V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Mon, 7 Jan 2008 13:57:48 -0600 To: "Paine, Richard H" X-Mailer: Apple Mail (2.753) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-Mailman-Approved-At: Tue, 08 Jan 2008 03:04:21 -0500 Cc: "Brewer, Orlie T" , "Wang, Sherry" , p2psip@ietf.org, hipsec@ietf.org, Henry Sinnreich , "Venema, Steve A" , "David Ward \(wardd\)" , "Venema, Steven C" Subject: [Hipsec] Re: [P2PSIP] Updated: P2PSIP and HIP Joint Meeting on the Boeing VOIP HIPImplementation 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 Jan 7, 2008, at 9:37 AM, Paine, Richard H wrote: > I'll parse that for those whose software breaks on the attachment: ------ Just so everyone is clear - the teleconference is at 8am Pacific Time on Tuesday, Jan 8, 2008 at the following teleconference and Webex numbers. The teleconference is per a meeting at the Vancouver IETF on Friday, Dec 7, 2007 that was a joint meeting of the HIP and P2PSIP Working Groups. The joint meeting determined the need to look at the Boeing demonstration of SIP over HIP. The demonstration used an IEEE802.11- WPA-wireless connection to the Boeing Intranet and the SIP call traversed both the wireless and wired network securely to get to a wired laptop. The call occurred in a HIP namespace using a cryptographic identity as an SPI value in the ESP field. This teleconference is being held to discuss the white paper on the demonstration and the use of HIP for secure point-to-point SIP. Teleconference Details: Date: Tuesday, January 8, 2008 Starting time: 8:00 am, Pacific Standard Time (GMT -08:00, San Francisco) Duration: 1 hour 30 minutes Meeting number: 896 132 416 Meeting password: hip meeting Teleconference: Dial-in: 1-866-752-6974 (US) Participant passcode:9710856 Host: Richard Paine Host's email address: richard.h.paine@boeing.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jan 08 03:04:2From hipsec-bounces@lists.ietf.org Tue Jan 08 03:04:24 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC9Rf-0004BW-9E; Tue, 08 Jan 2008 03:04:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBy76-0007MU-8k; Mon, 07 Jan 2008 14:58:24 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBy73-0007eJ-VU; Mon, 07 Jan 2008 14:58:24 -0500 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m07Jw8aE024092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 7 Jan 2008 13:58:10 -0600 In-Reply-To: <0C549DAFE1A8004D8EB57ACDD108646D06520831@XCH-NW-2V2.nw.nos.boeing.com> References: <0C549DAFE1A8004D8EB57ACDD108646D06520831@XCH-NW-2V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Mon, 7 Jan 2008 13:57:48 -0600 To: "Paine, Richard H" X-Mailer: Apple Mail (2.753) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-Mailman-Approved-At: Tue, 08 Jan 2008 03:04:21 -0500 Cc: "Brewer, Orlie T" , "Wang, Sherry" , p2psip@ietf.org, hipsec@ietf.org, Henry Sinnreich , "Venema, Steve A" , "David Ward \(wardd\)" , "Venema, Steven C" Subject: [Hipsec] Re: [P2PSIP] Updated: P2PSIP and HIP Joint Meeting on the Boeing VOIP HIPImplementation 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 Jan 7, 2008, at 9:37 AM, Paine, Richard H wrote: > I'll parse that for those whose software breaks on the attachment: ------ Just so everyone is clear - the teleconference is at 8am Pacific Time on Tuesday, Jan 8, 2008 at the following teleconference and Webex numbers. The teleconference is per a meeting at the Vancouver IETF on Friday, Dec 7, 2007 that was a joint meeting of the HIP and P2PSIP Working Groups. The joint meeting determined the need to look at the Boeing demonstration of SIP over HIP. The demonstration used an IEEE802.11- WPA-wireless connection to the Boeing Intranet and the SIP call traversed both the wireless and wired network securely to get to a wired laptop. The call occurred in a HIP namespace using a cryptographic identity as an SPI value in the ESP field. This teleconference is being held to discuss the white paper on the demonstration and the use of HIP for secure point-to-point SIP. Teleconference Details: Date: Tuesday, January 8, 2008 Starting time: 8:00 am, Pacific Standard Time (GMT -08:00, San Francisco) Duration: 1 hour 30 minutes Meeting number: 896 132 416 Meeting password: hip meeting Teleconference: Dial-in: 1-866-752-6974 (US) Participant passcode:9710856 Host: Richard Paine Host's email address: richard.h.paine@boeing.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jan 08 03:04:24 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC9Rf-0004BQ-3D; Tue, 08 Jan 2008 03:04:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBu7f-0002M2-3k; Mon, 07 Jan 2008 10:42:43 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBu7e-0008HI-L5; Mon, 07 Jan 2008 10:42:43 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m07FbXe5027188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Jan 2008 07:37:34 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m07FbXcj027779; Mon, 7 Jan 2008 07:37:33 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m07FbXCK027773; Mon, 7 Jan 2008 07:37:33 -0800 (PST) Received: from XCH-NW-2V2.nw.nos.boeing.com ([130.247.55.18]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 07:37:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:calendarmessage MIME-Version: 1.0 Date: Mon, 7 Jan 2008 07:37:31 -0800 Message-ID: <0C549DAFE1A8004D8EB57ACDD108646D06520831@XCH-NW-2V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: P2PSIP and HIP Joint Meeting on the Boeing VOIP HIPImplementation Thread-Index: AchEJF7WXDz4rIgVQHuS1XYc5gSeRANHthmw From: "Paine, Richard H" To: "Venema, Steve A" , "Mattes, David" , "Brewer, Orlie T" , , X-OriginalArrivalTime: 07 Jan 2008 15:37:32.0081 (UTC) FILETIME=[37CBA210:01C85143] X-Spam-Score: -4.0 (----) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 X-Mailman-Approved-At: Tue, 08 Jan 2008 03:04:21 -0500 Cc: "Matuszewski Marcin \(Nokia-OCTO/Helsinki\)" , "Wang, Sherry" , ndlgroup1@gmail.com, Henry Sinnreich , "Venema, Steven C" , "David Ward \(wardd\)" Subject: [Hipsec] Updated: P2PSIP and HIP Joint Meeting on the Boeing VOIP HIPImplementation 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: , Content-Type: multipart/mixed; boundary="===============1754810447==" Errors-To: hipsec-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1754810447== Content-class: urn:content-classes:calendarmessage Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C85143.3751A3A1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C85143.3751A3A1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When: Tuesday, January 08, 2008 8:00 AM-9:30 AM (GMT-08:00) Pacific Time = (US & Canada). Where: Virtual (866-752-6974 Passcode: 9710856# *~*~*~*~*~*~*~*~*~* Just so everyone is clear - the teleconference is at 8am Pacific Time on = Tuesday, Jan 8, 2008 at the following teleconference and Webex numbers. The teleconference is per a meeting at the Vancouver IETF on Friday, Dec = 7, 2007 4 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC9Rf-0004BQ-3D; Tue, 08 Jan 2008 03:04:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBu7f-0002M2-3k; Mon, 07 Jan 2008 10:42:43 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBu7e-0008HI-L5; Mon, 07 Jan 2008 10:42:43 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m07FbXe5027188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Jan 2008 07:37:34 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m07FbXcj027779; Mon, 7 Jan 2008 07:37:33 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m07FbXCK027773; Mon, 7 Jan 2008 07:37:33 -0800 (PST) Received: from XCH-NW-2V2.nw.nos.boeing.com ([130.247.55.18]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 07:37:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:calendarmessage MIME-Version: 1.0 Date: Mon, 7 Jan 2008 07:37:31 -0800 Message-ID: <0C549DAFE1A8004D8EB57ACDD108646D06520831@XCH-NW-2V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: P2PSIP and HIP Joint Meeting on the Boeing VOIP HIPImplementation Thread-Index: AchEJF7WXDz4rIgVQHuS1XYc5gSeRANHthmw From: "Paine, Richard H" To: "Venema, Steve A" , "Mattes, David" , "Brewer, Orlie T" , , X-OriginalArrivalTime: 07 Jan 2008 15:37:32.0081 (UTC) FILETIME=[37CBA210:01C85143] X-Spam-Score: -4.0 (----) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 X-Mailman-Approved-At: Tue, 08 Jan 2008 03:04:21 -0500 Cc: "Matuszewski Marcin \(Nokia-OCTO/Helsinki\)" , "Wang, Sherry" , ndlgroup1@gmail.com, Henry Sinnreich , "Venema, Steven C" , "David Ward \(wardd\)" Subject: [Hipsec] Updated: P2PSIP and HIP Joint Meeting on the Boeing VOIP HIPImplementation 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: , Content-Type: multipart/mixed; boundary="===============1754810447==" Errors-To: hipsec-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1754810447== Content-class: urn:content-classes:calendarmessage Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C85143.3751A3A1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C85143.3751A3A1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When: Tuesday, January 08, 2008 8:00 AM-9:30 AM (GMT-08:00) Pacific Time = (US & Canada). Where: Virtual (866-752-6974 Passcode: 9710856# *~*~*~*~*~*~*~*~*~* Just so everyone is clear - the teleconference is at 8am Pacific Time on = Tuesday, Jan 8, 2008 at the following teleconference and Webex numbers. The teleconference is per a meeting at the Vancouver IETF on Friday, Dec = 7, 2007 4 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC9Rf-0004BQ-3D; Tue, 08 Jan 2008 03:04:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBu7f-0002M2-3k; Mon, 07 Jan 2008 10:42:43 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBu7e-0008HI-L5; Mon, 07 Jan 2008 10:42:43 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m07FbXe5027188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Jan 2008 07:37:34 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m07FbXcj027779; Mon, 7 Jan 2008 07:37:33 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m07FbXCK027773; Mon, 7 Jan 2008 07:37:33 -0800 (PST) Received: from XCH-NW-2V2.nw.nos.boeing.com ([130.247.55.18]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 07:37:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:calendarmessage MIME-Version: 1.0 Date: Mon, 7 Jan 2008 07:37:31 -0800 Message-ID: <0C549DAFE1A8004D8EB57ACDD108646D06520831@XCH-NW-2V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: P2PSIP and HIP Joint Meeting on the Boeing VOIP HIPImplementation Thread-Index: AchEJF7WXDz4rIgVQHuS1XYc5gSeRANHthmw From: "Paine, Richard H" To: "Venema, Steve A" , "Mattes, David" , "Brewer, Orlie T" , , X-OriginalArrivalTime: 07 Jan 2008 15:37:32.0081 (UTC) FILETIME=[37CBA210:01C85143] X-Spam-Score: -4.0 (----) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 X-Mailman-Approved-At: Tue, 08 Jan 2008 03:04:21 -0500 Cc: "Matuszewski Marcin \(Nokia-OCTO/Helsinki\)" , "Wang, Sherry" , ndlgroup1@gmail.com, Henry Sinnreich , "Venema, Steven C" , "David Ward \(wardd\)" Subject: [Hipsec] Updated: P2PSIP and HIP Joint Meeting on the Boeing VOIP HIPImplementation 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: , Content-Type: multipart/mixed; boundary="===============1754810447==" Errors-To: hipsec-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1754810447== Content-class: urn:content-classes:calendarmessage Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C85143.3751A3A1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C85143.3751A3A1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When: Tuesday, January 08, 2008 8:00 AM-9:30 AM (GMT-08:00) Pacific Time = (US & Canada). Where: Virtual (866-752-6974 Passcode: 9710856# *~*~*~*~*~*~*~*~*~* Just so everyone is clear - the teleconference is at 8am Pacific Time on = Tuesday, Jan 8, 2008 at the following teleconference and Webex numbers. The teleconference is per a meeting at the Vancouver IETF on Friday, Dec = 7, 2007 that was a joint meeting of the HIP and P2PSIP Working Groups. = The joint meeting determined the need to look at the Boeing = demonstration of SIP over HIP. The demonstration used an = IEEE802.11-WPA-wireless connection to the Boeing Intranet and the SIP = call traversed both the wireless and wired network securely to get to a = wired laptop. The call occurred in a HIP namespace using a = cryptographic identity as an SPI value in the ESP field. This teleconference is being held to discuss the white paper on the = demonstration and the use of HIP for secure point-to-point SIP. Teleconference Details: Date: Tuesday, January 8, 2008 Starting time: 8:00 am, Pacific Standard = Time (GMT -08:00, San Francisco) Duration: 1 hour 30 minutes Meeting = number: 896 132 416 Meeting password: hipmeeting Teleconference: = Dial-in:1-866-752-6974 (US) Leader passcode:9710856 Participant passcode:9710856 Host: Richard Paine Host's email address: = richard.h.paine@boeing.com=20 Richard H. Paine Success is getting what you want, happiness is liking what you get! Cell: 206-854-8199 IPPhone: 425-373-8296 Email: richard.h.paine@boeing.com=20 ------_=_NextPart_001_01C85143.3751A3A1 Content-class: urn:content-classes:calendarmessage Content-Type: text/calendar; method=REQUEST; name="meeting.ics" Content-Transfer-Encoding: 8bit BEGIN:VCALENDAR METHOD:REQUEST PRODID:Microsoft CDO for Microsoft Exchange VERSION:2.0 BEGIN:VTIMEZONE TZID:(GMT-08.00) Pacific Time (US & Canada) X-MICROSOFT-CDO-TZID:13 BEGIN:STANDARD DTSTART:16010101T020000 TZOFFSETFROM:-0700 TZOFFSETTO:-0800 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=11;BYDAY=1SU END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T020000 TZOFFSETFROM:-0800 TZOFFSETTO:-0700 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=2SU END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20080107T153731Z DTSTART;TZID="(GMT-08.00) Pacific Time (US & Canada)":20080108T080000 SUMMARY:Updated: P2PSIP and HIP Joint Meeting on the Boeing VOIP HIPImpleme ntation UID:040000008200E00074C5B7101A82E0080000000080ACA250E143C801000000000000000 01000000020FE7606F6D5FC42BF9DE36E7AF87CFA ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Venema, S teve A":MAILTO:Steve.A.Venema@boeing.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Mattes, D avid":MAILTO:david.mattes@boeing.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Brewer, Orlie T'":MAILTO:brewer@thumper.rt.cs.boeing.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'p2psip@i etf.org'":MAILTO:p2psip@ietf.org ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'hipsec@i etf.org'":MAILTO:hipsec@ietf.org ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;X-REPLYTIME=89071205T18 4200Z;RSVP=TRUE;CN="'dwing@cisco.com'":MAILTO:dwing@cisco.com ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'ndlgroup 1@gmail.com'":MAILTO:ndlgroup1@gmail.com ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;X-REPLYTIME=20071226T18 3836Z;RSVP=TRUE;CN="'David Ward (wardd)'":MAILTO:wardd@cisco.com ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;X-REPLYTIME=20080102T16 2106Z;RSVP=TRUE;CN="'Wang, Sherry'":MAILTO:Sherry.Wang@jhuapl.edu ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;X-REPLYTIME=20080103T21 0543Z;RSVP=TRUE;CN="'Henry Sinnreich'":MAILTO:hsinnrei@adobe.com ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;X-REPLYTIME=20080104T11 1500Z;RSVP=TRUE;CN="'Matuszewski Marcin (Nokia-OCTO/Helsinki)'":MAILTO:mar cin.matuszewski@nokia.com ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;X-REPLYTIME=20080107T01 4720Z;RSVP=TRUE;CN="Venema, Steven C":MAILTO:steven.c.venema@boeing.com ORGANIZER;CN="Paine, Richard H":MAILTO:richard.h.paine@boeing.com LOCATION:Virtual (866-752-6974 Passcode: 9710856# DTEND;TZID="(GMT-08.00) Pacific Time (US & Canada)":20080108T093000 DESCRIPTION:Just so everyone is clear - the teleconference is at 8am Pacifi c Time on Tuesday\, Jan 8\, 2008 at the following teleconference and Webex numbers.\N\NThe teleconference is per a mthat was a joint meeting of the HIP and P2PSIP Working Groups. = The joint meeting determined the need to look at the Boeing = demonstration of SIP over HIP. The demonstration used an = IEEE802.11-WPA-wireless connection to the Boeing Intranet and the SIP = call traversed both the wireless and wired network securely to get to a = wired laptop. The call occurred in a HIP namespace using a = cryptographic identity as an SPI value in the ESP field. This teleconference is being held to discuss the white paper on the = demonstration and the use of HIP for secure point-to-point SIP. Teleconference Details: Date: Tuesday, January 8, 2008 Starting time: 8:00 am, Pacific Standard = Time (GMT -08:00, San Francisco) Duration: 1 hour 30 minutes Meeting = number: 896 132 416 Meeting password: hipmeeting Teleconference: = Dial-in:1-866-752-6974 (US) Leader passcode:9710856 Participant passcode:9710856 Host: Richard Paine Host's email address: = richard.h.paine@boeing.com=20 Richard H. Paine Success is getting what you want, happiness is liking what you get! Cell: 206-854-8199 IPPhone: 425-373-8296 Email: richard.h.paine@boeing.com=20 ------_=_NextPart_001_01C85143.3751A3A1 Content-class: urn:content-classes:calendarmessage Content-Type: text/calendar; method=REQUEST; name="meeting.ics" Content-Transfer-Encoding: 8bit BEGIN:VCALENDAR METHOD:REQUEST PRODID:Microsoft CDO for Microsoft Exchange VERSION:2.0 BEGIN:VTIMEZONE TZID:(GMT-08.00) Pacific Time (US & Canada) X-MICROSOFT-CDO-TZID:13 BEGIN:STANDARD DTSTART:16010101T020000 TZOFFSETFROM:-0700 TZOFFSETTO:-0800 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=11;BYDAY=1SU END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T020000 TZOFFSETFROM:-0800 TZOFFSETTO:-0700 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=2SU END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20080107T153731Z DTSTART;TZID="(GMT-08.00) Pacific Time (US & Canada)":20080108T080000 SUMMARY:Updated: P2PSIP and HIP Joint Meeting on the Boeing VOIP HIPImpleme ntation UID:040000008200E00074C5B7101A82E0080000000080ACA250E143C801000000000000000 01000000020FE7606F6D5FC42BF9DE36E7AF87CFA ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Venema, S teve A":MAILTO:Steve.A.Venema@boeing.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Mattes, D avid":MAILTO:david.mattes@boeing.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Brewer, Orlie T'":MAILTO:brewer@thumper.rt.cs.boeing.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'p2psip@i etf.org'":MAILTO:p2psip@ietf.org ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'hipsec@i etf.org'":MAILTO:hipsec@ietf.org ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;X-REPLYTIME=89071205T18 4200Z;RSVP=TRUE;CN="'dwing@cisco.com'":MAILTO:dwing@cisco.com ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'ndlgroup 1@gmail.com'":MAILTO:ndlgroup1@gmail.com ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;X-REPLYTIME=20071226T18 3836Z;RSVP=TRUE;CN="'David Ward (wardd)'":MAILTO:wardd@cisco.com ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;X-REPLYTIME=20080102T16 2106Z;RSVP=TRUE;CN="'Wang, Sherry'":MAILTO:Sherry.Wang@jhuapl.edu ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;X-REPLYTIME=20080103T21 0543Z;RSVP=TRUE;CN="'Henry Sinnreich'":MAILTO:hsinnrei@adobe.com ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;X-REPLYTIME=20080104T11 1500Z;RSVP=TRUE;CN="'Matuszewski Marcin (Nokia-OCTO/Helsinki)'":MAILTO:mar cin.matuszewski@nokia.com ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;X-REPLYTIME=20080107T01 4720Z;RSVP=TRUE;CN="Venema, Steven C":MAILTO:steven.c.venema@boeing.com ORGANIZER;CN="Paine, Richard H":MAILTO:richard.h.paine@boeing.com LOCATION:Virtual (866-752-6974 Passcode: 9710856# DTEND;TZID="(GMT-08.00) Pacific Time (US & Canada)":20080108T093000 DESCRIPTION:Just so everyone is clear - the teleconference is at 8am Pacifi c Time on Tuesday\, Jan 8\, 2008 at the following teleconference and Webex numbers.\N\NThe teleconference is per a mthat was a joint meeting of the HIP and P2PSIP Working Groups. = The joint meeting determined the need to look at the Boeing = demonstration of SIP over HIP. The demonstration used an = IEEE802.11-WPA-wireless connection to the Boeing Intranet and the SIP = call traversed both the wireless and wired network securely to get to a = wired laptop. The call occurred in a HIP namespace using a = cryptographic identity as an SPI value in the ESP field. This teleconference is being held to discuss the white paper on the = demonstration and the use of HIP for secure point-to-point SIP. Teleconference Details: Date: Tuesday, January 8, 2008 Starting time: 8:00 am, Pacific Standard = Time (GMT -08:00, San Francisco) Duration: 1 hour 30 minutes Meeting = number: 896 132 416 Meeting password: hipmeeting Teleconference: = Dial-in:1-866-752-6974 (US) Leader passcode:9710856 Participant passcode:9710856 Host: Richard Paine Host's email address: = richard.h.paine@boeing.com=20 Richard H. Paine Success is getting what you want, happiness is liking what you get! Cell: 206-854-8199 IPPhone: 425-373-8296 Email: richard.h.paine@boeing.com=20 ------_=_NextPart_001_01C85143.3751A3A1 Content-class: urn:content-classes:calendarmessage Content-Type: text/calendar; method=REQUEST; name="meeting.ics" Content-Transfer-Encoding: 8bit BEGIN:VCALENDAR METHOD:REQUEST PRODID:Microsoft CDO for Microsoft Exchange VERSION:2.0 BEGIN:VTIMEZONE TZID:(GMT-08.00) Pacific Time (US & Canada) X-MICROSOFT-CDO-TZID:13 BEGIN:STANDARD DTSTART:16010101T020000 TZOFFSETFROM:-0700 TZOFFSETTO:-0800 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=11;BYDAY=1SU END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T020000 TZOFFSETFROM:-0800 TZOFFSETTO:-0700 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=2SU END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20080107T153731Z DTSTART;TZID="(GMT-08.00) Pacific Time (US & Canada)":20080108T080000 SUMMARY:Updated: P2PSIP and HIP Joint Meeting on the Boeing VOIP HIPImpleme ntation UID:040000008200E00074C5B7101A82E0080000000080ACA250E143C801000000000000000 01000000020FE7606F6D5FC42BF9DE36E7AF87CFA ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Venema, S teve A":MAILTO:Steve.A.Venema@boeing.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Mattes, D avid":MAILTO:david.mattes@boeing.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Brewer, Orlie T'":MAILTO:brewer@thumper.rt.cs.boeing.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'p2psip@i etf.org'":MAILTO:p2psip@ietf.org ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'hipsec@i etf.org'":MAILTO:hipsec@ietf.org ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;X-REPLYTIME=89071205T18 4200Z;RSVP=TRUE;CN="'dwing@cisco.com'":MAILTO:dwing@cisco.com ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'ndlgroup 1@gmail.com'":MAILTO:ndlgroup1@gmail.com ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;X-REPLYTIME=20071226T18 3836Z;RSVP=TRUE;CN="'David Ward (wardd)'":MAILTO:wardd@cisco.com ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;X-REPLYTIME=20080102T16 2106Z;RSVP=TRUE;CN="'Wang, Sherry'":MAILTO:Sherry.Wang@jhuapl.edu ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;X-REPLYTIME=20080103T21 0543Z;RSVP=TRUE;CN="'Henry Sinnreich'":MAILTO:hsinnrei@adobe.com ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;X-REPLYTIME=20080104T11 1500Z;RSVP=TRUE;CN="'Matuszewski Marcin (Nokia-OCTO/Helsinki)'":MAILTO:mar cin.matuszewski@nokia.com ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;X-REPLYTIME=20080107T01 4720Z;RSVP=TRUE;CN="Venema, Steven C":MAILTO:steven.c.venema@boeing.com ORGANIZER;CN="Paine, Richard H":MAILTO:richard.h.paine@boeing.com LOCATION:Virtual (866-752-6974 Passcode: 9710856# DTEND;TZID="(GMT-08.00) Pacific Time (US & Canada)":20080108T093000 DESCRIPTION:Just so everyone is clear - the teleconference is at 8am Pacifi c Time on Tuesday\, Jan 8\, 2008 at the following teleconference and Webex numbers.\N\NThe teleconference is per a meeting at the Vancouver IETF on Friday\, Dec 7\, 2007 that was a joint meeting of the HIP and P2PSIP Worki ng Groups. The joint meeting determined the need to look at the Boeing de monstration of SIP over HIP. The demonstration used an IEEE802.11-WPA-wir eless connection to the Boeing Intranet and the SIP call traversed both th e wireless and wired network securely to get to a wired laptop. The call occurred in a HIP namespace using a cryptographic identity as an SPI value in the ESP field.\N\NThis teleconference is being held to discuss the whi te paper on the demonstration and the use of HIP for secure point-to-point SIP.\N\NTeleconference Details:\N\NDate: Tuesday\, January 8\, 2008 Start ing time: 8:00 am\, Pacific Standard Time (GMT -08:00\, San Francisco) Dur ation: 1 hour 30 minutes Meeting number: 896 132 416 Meeting password: hip meeting Teleconference: Dial-in:1-866-752-6974 (US)\NLeader passcode:97108 56\NParticipant passcode:9710856 Host: Richard Paine Host's email address: richard.h.paine@boeing.com \N\NRichard H. Paine\NSuccess is getting what you want\, happiness is liking what you get!\NCell: 206-854-8199\NIPPhone : 425-373-8296\NEmail: richard.h.paine@boeing.com \N SEQUENCE:0 PRIORITY:5 CLASS: CREATED:20080107T153731Z LAST-MODIFIED:20080107T153731Z STATUS:CONFIRMED TRANSP:OPAQUE X-MICROSOFT-CDO-BUSYSTATUS:BUSY X-MICROSOFT-CDO-INSTTYPE:0 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-OWNERAPPTID:1471530967 X-MICROSOFT-CDO-APPT-SEQUENCE:1 X-MICROSOFT-CDO-ATTENDEE-CRITICAL-CHANGE:20080107T153731Z X-MICROSOFT-CDO-OWNER-CRITICAL-CHANGE:20080107T153731Z BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:REMINDER TRIGGER;RELATED=START:-PT00H15M00S END:VALARM END:VEVENT END:VCALENDAR ------_=_NextPart_001_01C85143.3751A3A1-- --===============1754810447== 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 --===============1754810447==-- From hipsec-bounces@lists.ietf.org Tue Jan 08 03:04:24 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC9Rf-0004Bb-F0; Tue, 08 Jan 2008 03:04:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JByhU-0002Pw-Hc; Mon, 07 Jan 2008 15:36:00 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JByhU-0008Ib-1O; Mon, 07 Jan 2008 15:36:00 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m07KVrjt029437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Jan 2008 14:31:53 -0600 (CST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m07KVq2j000235; Mon, 7 Jan 2008 14:31:52 -0600 (CST) 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.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m07KVjHb029945; Mon, 7 Jan 2008 14:31:52 -0600 (CST) Received: from XCH-NW-2V2.nw.nos.boeing.com ([130.247.55.18]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 12:31:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Jan 2008 12:31:50 -0800 Message-ID: <0C549DAFE1A8004D8EB57ACDD108646D0652083A@XCH-NW-2V2.nw.nos.boeing.com> In-Reply-To: <8390D7C9-7EA5-49D2-B4DE-917FFDD89A71@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Updated: P2PSIP and HIP Joint Meeting on the Beeting at the Vancouver IETF on Friday\, Dec 7\, 2007 that was a joint meeting of the HIP and P2PSIP Worki ng Groups. The joint meeting determined the need to look at the Boeing de monstration of SIP over HIP. The demonstration used an IEEE802.11-WPA-wir eless connection to the Boeing Intranet and the SIP call traversed both th e wireless and wired network securely to get to a wired laptop. The call occurred in a HIP namespace using a cryptographic identity as an SPI value in the ESP field.\N\NThis teleconference is being held to discuss the whi te paper on the demonstration and the use of HIP for secure point-to-point SIP.\N\NTeleconference Details:\N\NDate: Tuesday\, January 8\, 2008 Start ing time: 8:00 am\, Pacific Standard Time (GMT -08:00\, San Francisco) Dur ation: 1 hour 30 minutes Meeting number: 896 132 416 Meeting password: hip meeting Teleconference: Dial-in:1-866-752-6974 (US)\NLeader passcode:97108 56\NParticipant passcode:9710856 Host: Richard Paine Host's email address: richard.h.paine@boeing.com \N\NRichard H. Paine\NSuccess is getting what you want\, happiness is liking what you get!\NCell: 206-854-8199\NIPPhone : 425-373-8296\NEmail: richard.h.paine@boeing.com \N SEQUENCE:0 PRIORITY:5 CLASS: CREATED:20080107T153731Z LAST-MODIFIED:20080107T153731Z STATUS:CONFIRMED TRANSP:OPAQUE X-MICROSOFT-CDO-BUSYSTATUS:BUSY X-MICROSOFT-CDO-INSTTYPE:0 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-OWNERAPPTID:1471530967 X-MICROSOFT-CDO-APPT-SEQUENCE:1 X-MICROSOFT-CDO-ATTENDEE-CRITICAL-CHANGE:20080107T153731Z X-MICROSOFT-CDO-OWNER-CRITICAL-CHANGE:20080107T153731Z BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:REMINDER TRIGGER;RELATED=START:-PT00H15M00S END:VALARM END:VEVENT END:VCALENDAR ------_=_NextPart_001_01C85143.3751A3A1-- --===============1754810447== 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 --===============1754810447==-- From hipsec-bounces@lists.ietf.org Tue Jan 08 03:04:24 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC9Rf-0004Bb-F0; Tue, 08 Jan 2008 03:04:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JByhU-0002Pw-Hc; Mon, 07 Jan 2008 15:36:00 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JByhU-0008Ib-1O; Mon, 07 Jan 2008 15:36:00 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m07KVrjt029437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Jan 2008 14:31:53 -0600 (CST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m07KVq2j000235; Mon, 7 Jan 2008 14:31:52 -0600 (CST) 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.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m07KVjHb029945; Mon, 7 Jan 2008 14:31:52 -0600 (CST) Received: from XCH-NW-2V2.nw.nos.boeing.com ([130.247.55.18]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 12:31:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Jan 2008 12:31:50 -0800 Message-ID: <0C549DAFE1A8004D8EB57ACDD108646D0652083A@XCH-NW-2V2.nw.nos.boeing.com> In-Reply-To: <8390D7C9-7EA5-49D2-B4DE-917FFDD89A71@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Updated: P2PSIP and HIP Joint Meeting on the Boeing VOIP HIPImplementation Thread-Index: AchRZ9ElDuPiOhZ1TwOU6LpptF4qNgABDsjw References: <0C549DAFE1A8004D8EB57ACDD108646D06520831@XCH-NW-2V2.nw.nos.boeing.com> <8390D7C9-7EA5-49D2-B4DE-917FFDD89A71@softarmor.com> From: "Paine, Richard H" To: "Dean Willis" X-OriginalArrivalTime: 07 Jan 2008 20:31:51.0397 (UTC) FILETIME=[55916950:01C8516C] X-Spam-Score: -4.0 (----) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-Mailman-Approved-At: Tue, 08 Jan 2008 03:04:21 -0500 Cc: "Brewer, Orlie T" , "Wang, Sherry" , p2psip@ietf.org, hipsec@ietf.org, "Oredope, Adetola" , ndlgroup1@gmail.com, "Venema, Steve A" , "Matuszewski Marcin \(Nokia-OCTO/Helsinki\)" , Henry Sinnreich , Roy Kuntz , "Venema, Steven C" , "David Ward \(wardd\)" , Sean Olson Subject: [Hipsec] RE: [P2PSIP] Updated: P2PSIP and HIP Joint Meeting on the Boeing VOIP HIPImplementation 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 Non-toll-free number for the P2PSIP and HIP teleconference: 203-310-8979 Participant passcode: 9710856 Richard H. Paine Success is getting what you want, happiness is liking what you get! Cell: 206-854-8199 IPPhone: 425-373-8296 Email: richard.h.paine@boeing.com=20 =20 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Monday, January 07, 2008 11:59 AM To: Paine, Richard H Subject: Re: [P2PSIP] Updated: P2PSIP and HIP Joint Meeting on the Boeing VOIP HIPImplementation On Jan 7, 2008, at 9:37 AM, Paine, Richard H wrote: > It occurs to me that you may have some folks calling in from outside the US, and US toll-free numbers are notoriously difficult to reach from some countries. Do you have a non-toll-free number? Or did I just miss it in that Microsoft-mangled calendar invitation? -- Dean _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec oeing VOIP HIPImplementation Thread-Index: AchRZ9ElDuPiOhZ1TwOU6LpptF4qNgABDsjw References: <0C549DAFE1A8004D8EB57ACDD108646D06520831@XCH-NW-2V2.nw.nos.boeing.com> <8390D7C9-7EA5-49D2-B4DE-917FFDD89A71@softarmor.com> From: "Paine, Richard H" To: "Dean Willis" X-OriginalArrivalTime: 07 Jan 2008 20:31:51.0397 (UTC) FILETIME=[55916950:01C8516C] X-Spam-Score: -4.0 (----) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-Mailman-Approved-At: Tue, 08 Jan 2008 03:04:21 -0500 Cc: "Brewer, Orlie T" , "Wang, Sherry" , p2psip@ietf.org, hipsec@ietf.org, "Oredope, Adetola" , ndlgroup1@gmail.com, "Venema, Steve A" , "Matuszewski Marcin \(Nokia-OCTO/Helsinki\)" , Henry Sinnreich , Roy Kuntz , "Venema, Steven C" , "David Ward \(wardd\)" , Sean Olson Subject: [Hipsec] RE: [P2PSIP] Updated: P2PSIP and HIP Joint Meeting on the Boeing VOIP HIPImplementation 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 Non-toll-free number for the P2PSIP and HIP teleconference: 203-310-8979 Participant passcode: 9710856 Richard H. Paine Success is getting what you want, happiness is liking what you get! Cell: 206-854-8199 IPPhone: 425-373-8296 Email: richard.h.paine@boeing.com=20 =20 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Monday, January 07, 2008 11:59 AM To: Paine, Richard H Subject: Re: [P2PSIP] Updated: P2PSIP and HIP Joint Meeting on the Boeing VOIP HIPImplementation On Jan 7, 2008, at 9:37 AM, Paine, Richard H wrote: > It occurs to me that you may have some folks calling in from outside the US, and US toll-free numbers are notoriously difficult to reach from some countries. Do you have a non-toll-free number? Or did I just miss it in that Microsoft-mangled calendar invitation? -- Dean _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec eeting at the Vancouver IETF on Friday\, Dec 7\, 2007 that was a joint meeting of the HIP and P2PSIP Worki ng Groups. The joint meeting determined the need to look at the Boeing de monstration of SIP over HIP. The demonstration used an IEEE802.11-WPA-wir eless connection to the Boeing Intranet and the SIP call traversed both th e wireless and wired network securely to get to a wired laptop. The call occurred in a HIP namespace using a cryptographic identity as an SPI value in the ESP field.\N\NThis teleconference is being held to discuss the whi te paper on the demonstration and the use of HIP for secure point-to-point SIP.\N\NTeleconference Details:\N\NDate: Tuesday\, January 8\, 2008 Start ing time: 8:00 am\, Pacific Standard Time (GMT -08:00\, San Francisco) Dur ation: 1 hour 30 minutes Meeting number: 896 132 416 Meeting password: hip meeting Teleconference: Dial-in:1-866-752-6974 (US)\NLeader passcode:97108 56\NParticipant passcode:9710856 Host: Richard Paine Host's email address: richard.h.paine@boeing.com \N\NRichard H. Paine\NSuccess is getting what you want\, happiness is liking what you get!\NCell: 206-854-8199\NIPPhone : 425-373-8296\NEmail: richard.h.paine@boeing.com \N SEQUENCE:0 PRIORITY:5 CLASS: CREATED:20080107T153731Z LAST-MODIFIED:20080107T153731Z STATUS:CONFIRMED TRANSP:OPAQUE X-MICROSOFT-CDO-BUSYSTATUS:BUSY X-MICROSOFT-CDO-INSTTYPE:0 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-OWNERAPPTID:1471530967 X-MICROSOFT-CDO-APPT-SEQUENCE:1 X-MICROSOFT-CDO-ATTENDEE-CRITICAL-CHANGE:20080107T153731Z X-MICROSOFT-CDO-OWNER-CRITICAL-CHANGE:20080107T153731Z BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:REMINDER TRIGGER;RELATED=START:-PT00H15M00S END:VALARM END:VEVENT END:VCALENDAR ------_=_NextPart_001_01C85143.3751A3A1-- --===============1754810447== 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 --===============1754810447==-- From hipsec-bounces@lists.ietf.org Tue Jan 08 03:04:24 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC9Rf-0004Bb-F0; Tue, 08 Jan 2008 03:04:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JByhU-0002Pw-Hc; Mon, 07 Jan 2008 15:36:00 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JByhU-0008Ib-1O; Mon, 07 Jan 2008 15:36:00 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m07KVrjt029437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Jan 2008 14:31:53 -0600 (CST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m07KVq2j000235; Mon, 7 Jan 2008 14:31:52 -0600 (CST) 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.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m07KVjHb029945; Mon, 7 Jan 2008 14:31:52 -0600 (CST) Received: from XCH-NW-2V2.nw.nos.boeing.com ([130.247.55.18]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 12:31:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Jan 2008 12:31:50 -0800 Message-ID: <0C549DAFE1A8004D8EB57ACDD108646D0652083A@XCH-NW-2V2.nw.nos.boeing.com> In-Reply-To: <8390D7C9-7EA5-49D2-B4DE-917FFDD89A71@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Updated: P2PSIP and HIP Joint Meeting on the Boeing VOIP HIPImplementation Thread-Index: AchRZ9ElDuPiOhZ1TwOU6LpptF4qNgABDsjw References: <0C549DAFE1A8004D8EB57ACDD108646D06520831@XCH-NW-2V2.nw.nos.boeing.com> <8390D7C9-7EA5-49D2-B4DE-917FFDD89A71@softarmor.com> From: "Paine, Richard H" To: "Dean Willis" X-OriginalArrivalTime: 07 Jan 2008 20:31:51.0397 (UTC) FILETIME=[55916950:01C8516C] X-Spam-Score: -4.0 (----) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-Mailman-Approved-At: Tue, 08 Jan 2008 03:04:21 -0500 Cc: "Brewer, Orlie T" , "Wang, Sherry" , p2psip@ietf.org, hipsec@ietf.org, "Oredope, Adetola" , ndlgroup1@gmail.com, "Venema, Steve A" , "Matuszewski Marcin \(Nokia-OCTO/Helsinki\)" , Henry Sinnreich , Roy Kuntz , "Venema, Steven C" , "David Ward \(wardd\)" , Sean Olson Subject: [Hipsec] RE: [P2PSIP] Updated: P2PSIP and HIP Joint Meeting on the Boeing VOIP HIPImplementation 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 Non-toll-free number for the P2PSIP and HIP teleconference: 203-310-8979 Participant passcode: 9710856 Richard H. Paine Success is getting what you want, happiness is liking what you get! Cell: 206-854-8199 IPPhone: 425-373-8296 Email: richard.h.paine@boeing.com=20 =20 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Monday, January 07, 2008 11:59 AM To: Paine, Richard H Subject: Re: [P2PSIP] Updated: P2PSIP and HIP Joint Meeting on the Boeing VOIP HIPImplementation On Jan 7, 2008, at 9:37 AM, Paine, Richard H wrote: > It occurs to me that you may have some folks calling in from outside the US, and US toll-free numbers are notoriously difficult to reach from some countries. Do you have a non-toll-free number? Or did I just miss it in that Microsoft-mangled calendar invitation? -- Dean _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jan 08 12:42:08 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCISc-0000D2-HP; Tue, 08 Jan 2008 12:41:58 -0500 Received: from hipsec by megatron.ietf.org with local (Exim 4.43) id 1JCISb-0000Cu-N8 for hipsec-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 12:41:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCISb-0000Cm-Aa; Tue, 08 Jan 2008 12:41:57 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCISa-0000rO-61; Tue, 08 Jan 2008 12:41:57 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JUC000SA6HUPX@usaga01-in.huawei.com>; Tue, 08 Jan 2008 09:41:55 -0800 (PST) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JUC00H4E6HQ40@usaga01-in.huawei.com>; Tue, 08 Jan 2008 09:41:54 -0800 (PST) Date: Tue, 08 Jan 2008 11:41:23 -0600 From: Spencer Dawkins To: "Paine, Richard H" Message-id: <042701c8521d$b01b2f80$6601a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <0C549DAFE1A8004D8EB57ACDD108646D070BA68B@XCH-NW-2V2.nw.nos.boeing.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Cc: "Venema, Steve A" , "Brewer, Orlie T" , p2psip@ietf.org, hipsec@ietf.org Subject: [Hipsec] Re: [P2PSIP] P2PSIP and HIP Joint Meeting on the Boeing VOIPHIPImplementation 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 Richard, These are the notes I took during the telechat - I hope you find them helpful. It would be really good for people to see how badly they were misquoted - please send corrections to me privately, and I can provide a bulk update to Richard. I'm almost sure I attributed several Dan York statements randomly to other people... Thanks again for setting up this call - very helpful. Spencer We started with a review of "Note Well" (we're under IETF IPR rules for this meeting). - Agenda bashing... Planned agenda is to review the VoWLAN paper and then do Q&A. No bashing to this agenda. - Paper review... This paper was distributed to P2PSIP mailing list on December 21 (also downloadable from http://www.opengroup.org/bookstore/catalog/e041.htm). Using Open Group's Secure Mobile Architecture for both wireless and wireline secure communication, including voice, for factory operations. Mechanism described is currently in production on the Boeing 777 assembly line robots, but is much more broadly applicable. Overlay network, using HIP ("SCADANET Plane" in the paper). Tunnel looks like IPsec, with a cryptographic identifier. Wireless devices are Nokia 770s with Linux and LinPhone. SIP provides call management services, while HIP provides security associations. Some infrastructure is involved - "virtual directory" (identity, IP address, location of a device), DNS proxy for directory, certificate download-to-device management, location service. Need to know who someone is, and where they are, to do security well. Using HIP UPDATE packets for subnet mobility. Provide crytographic security for every packet (also protects infrastructure). Does rely on enterprise PKI in this demonstration. - Questions and answers ... Did this require mods to Linux IP stack? Used HIP from Helsinki, did have some kernel patches that added a new transform. Does this use Orchid? Tom said all HIP implementations use Orchids (Orchids are a particular form of IPv6 addresses, allocated experimentally). Would this also require changes to a Windows TCP/IP stack? Tom said that Boeing uses an OpenVPN "shim" with all modifications in user space, so no kernel mods are required. There's no way for an application to know that it's talking to an overlay - how does the application know it's using a secure overlay? This is security by configuration - the application "just knows" the interface is magically secure. Do we want applications to know about these security characteristics? Big design question (using ORCHIDs with legacy APIs tells you nothing about these characteristics). What about a secure SIP security indicator? Applications don't get any indication of security from IPsec, this is no different from any other IPsec operation. Dean said that there are mechanisms to make applications aware of HIP-IP mapping, if you build an application to be aware - this demo is using opportunistic mode, which does not, but there are 5 other modes. Lots of discussions about HIP security on VOIP-SEC/VOIP-SA mailing list (voipsec@voipsa.org), but not in about a year. The question here is whether we can use modified applications with unmodified stacks. Ted thinks the real question is whether you get something easy for the application writer to use without awareness of an underlying overlay or not. Anything - OpenVPN, kernel mod, etc. are just creating another interface that is exposed to anything that uses normal mechanisms for discovery - applications would not know the difference between IDs and LOCs. Ted thinks we need to know this difference - need to have a design discussion about this. This is a tradeoff between easy deployment and application awareness of unique characteristics - we need to talk. Spencer- There are a lot of other reasons to dork with an API - multihoming, route selection. Is API enhancement bounded? Dean - we went with TLS 10 years ago because we could do it without dorking with stacks. We might make a different decision now, if we were reconsidering. Henry - the IPsec mechanism secures all applications, not just SIP. Ted - but applications that don't know IPsec is there will run TLS over IPsec happily if they care about security. Maybe we could know that we're using an ORCHID that must be HIP-ergo-IPsec. There are questions about the layering model we need to talk about. Steve - not sure what approach we want - transparency for legacy applications or application awareness. Ted - we're using P2P anyway, HIP or not. If applications understand characteristics, you want to have the same answer for P2P and HIP awareness. Steve - both mechanisms available? and application writer chooses? Dave Bryan - transparency isn't going to make SIP phones P2P, right? built-in free resource location, etc. doesn't happen by magic. Still work to do on both SIP and P2P to make this work. Question (sorry, missed name) - if HIP is providing overlay routing, there is also a coupling with resource location, etc. Dave Bryan - but think about service, voice mail, etc. We still have work to do before we can remove all the servers. Spencer - seeing people talking about HIP over P2P and P2P over HIP - need to nail down an architecture early in this discussion. Tom - HIP is doing security for media streams, and there is separate work about extending the architecture to do routing. Could be different ways to go here (media streams only, or entire overlay on architecture). Gonzalo - WithHIP proposal started discussion using HIP in naive way, but this was too simple an approach to use. We would modify the architecture, use ORCHIDs (or derivation) as identifiers, etc. Sherry - has anyone done competitive analysis about performance, operational scenarios, etc. Richard - not an alternative that met our requirements (in the broader context). We did what we did to meet our requirements. We're going through a competitive analysis now, for another reason (and it's not obvious we would release that analysis externally). - Next Steps? ... Ted would like to resolve design decision about application awareness - write this up early in the process. If HIP is only transport-mode security, it's low-handing but not very valuable fruit. P2PSIP needs to be clear about API expectations about underlying overlay. If we don't get that right, we'll be headed in the wrong direction. David Bryan - consensus on that issue would help a lot. A lot of people in P2PSIP don't understand how this would work and would benefit from one clear statement. Henry - a lot of confusion about protocol stack, what's on top. Could Boeing team identify architectural choices in a separate paper, perhaps working with Gonzalo? It would help the P2PSIP folks a lot. Should come from authoritative source, right now that looks like Boeing and Finland. Gonzalo - three proposals, but thought HIP-HOP was abandoned and no one is working on WithHIP, we're working on HIP-BONE. We need to communicate better with P2PSIP working group. We've been having conversations within HIP, with P2PSIP guys, clearer than before IETF 70. Tom - still needs to be discussion. Eric Cooper is still interested in HIP-HOP, Philip is interested in IP-LOC. Thought we agreed to talk on HIP-RG mailing list and then HIP-BONE came out and things got quiet. Gonzalo - don't see HIP-HOP and HIP-BONE as different proposals - saying similar things. Published new draft because I didn't think there was interest in revising HIP-HOP. Henry - new draft with tutorial and framework? Gonzalo - has some tutorial but did draft in a few hours. Need to add historical statements, etc. Henry - how to represent Boeing contribution to IETF? don't have to decide now, but would like to see Boeing work better understood in IETF. Extremely interesting for entire HIP community. Gonzalo - choices have to be explained further. Richard - Sherry was talking about "competitive analysis" beyond architecture - MEXT, MIP, etc? Sherry - think more practical to decide architecture and educate people. Start with this. Eventually have to give analysis answer - P2PSIP and conventional SIP. Dave Bryan - need to focus on HIP and non-HIP discussion. Is there an interest in HIP within industry? This is what Richard hopes to finish by February. Henry - believe working working group is not proper place for economic analysis, but need to think about wquestions like balkanized security for different applications, etc. Dan York - if we're going to do a comparison, I'd like to understand how widely HIP might be endorsed. Spencer - need to ask about interest in architecture, not interest in specific protocols. Henry - dialup IP is a good model - a way to get started, and then applications that manage connectivity can move into OS code. ANOTHER TELECHAT? Gonzalo - yes, but everyone prepare. Don't discuss on abstract level because we won't make progress. Richard - have to deliver comparison between technologies in February. If I can get that approved for release, it could be a basis for top-down discussion, then talk about protocol stack, architecture, etc. If Gonzalo adds tutorial material that would also help. Gonzalo - sure, what tutorial do people need? Trying to do tutorial in three pages so people will it read it. Henry - had to read 10 references anyway... Having read through HIP-BONE, Gonzalo and team did this well and unfortunate we truncated discussion during the holidays. Let's not keep starting out "what would this architecture look like" - keep going from where we are. Richard - want me to set up another joint meeting? (No objections!) Stopping at 1:35 minutes... will go from there. Much gratitude to Boeing for throwing these ideas out for thought! _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jan 08 14:31:10 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCKAB-00079O-1C; Tue, 08 Jan 2008 14:31:03 -0500 Received: from hipsec by megatron.ietf.org with local (Exim 4.43) id 1JCKA9-00079G-OQ for hipsec-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 14:31:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCKA9-000798-DM; Tue, 08 Jan 2008 14:31:01 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCKA8-0004ie-Tq; Tue, 08 Jan 2008 14:31:01 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m08JUuHR006390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Jan 2008 13:30:56 -0600 (CST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m08JUu9J013260; Tue, 8 Jan 2008 13:30:56 -0600 (CST) 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.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m08JUpR6013049; Tue, 8 Jan 2008 13:30:56 -0600 (CST) 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); Tue, 8 Jan 2008 11:30:56 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Jan 2008 11:30:55 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D04049B0F@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE4A7@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Discussion items for the Tuesday teleconference Thread-Index: AchEH96vkLdr2CwpRny3bB+oZLdYwQNEMNOwADlowyA= References: <0C549DAFE1A8004D8EB57ACDD108646D070BA682@XCH-NW-2V2.nw.nos.boeing.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE4A7@namail5.corp.adobe.com> From: "Henderson, Thomas R" To: "Henry Sinnreich" , "Paine, Richard H" , , X-OriginalArrivalTime: 08 Jan 2008 19:30:56.0016 (UTC) FILETIME=[FD344900:01C8522C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Subject: [Hipsec] RE: [P2PSIP] Discussion items for the Tuesday teleconference 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 Henry, A few responses below.=20 > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 > Sent: Monday, January 07, 2008 5:44 AM > To: Paine, Richard H; p2psip@ietf.org; hipsec@ietf.org > Subject: [P2PSIP] Discussion items for the Tuesday teleconference >=20 > The paper on the Boeing HIP implementation along with the I-D: > draft-camarillo-hip-bone-00.txt is very helpful to SIP oriented people > like me who are new to HIP. Quite frankly I am close to becoming a > believer, if only some questions could be addressed and where more > details would be helpful: >=20 > 1. TCP/IP stack use and implementation >=20 > If and how can the existing PCP/IP stack in Windows, OSX, Symbian and > LINUX be used or does it have to be rewritten? Is there a=20 > workaround and > if yes, can anyone share what it may look like? There are HIP implementations that modify the kernel TCP/IP implementation, and those that do not. Those that do not use various techniques to intercept packets and copy them to user-space where they are further processed and re-injected to the stack. OpenVPN (http://openvpn.net) is one such example. What it may look like in this approach is to create a virtual interface and assign one or more HIP identifiers (that look like addresses to the operating system) to that interface. Packets sent to identifiers in that identifier space are internally routed to that virtual interface. This interface is a tap interface (http://en.wikipedia.org/wiki/TUN/TAP) that directs packets to userspace, where they can be processed further and written back to the interface or to a raw socket. Note that this technique is recommended as a deployment crutch for applications that cannot be easily modified; the eventual goal is that stacks are upgraded to include HIP and that applications use more explicit HIP-aware APIs such as: https://datatracker.ietf.org/drafts/draft-ietf-hip-native-api/ Also note that I do not know about the applicability of the above to Symbian, only that it has worked for Windows XP, OS X, and Linux. >=20 > Product managers would see the rewriting of the TCP/IP stack to insert > HIP as a major problem to avoid at any cost. Waiting for these OS to > support HIP does not seem a good alternative. >=20 > 2. NAT traversal >=20 > VPN implementations have had problems with NAT and as a=20 > result most NAT > vendors have addressed VPN support. What is the experience with HIP > support in NAT, or how much of a problem is NAT traversal for HIP? > Are there any measurements or deployment data that can be shared? To my knowledge, there has been no inbound NAT traversal mechanism integrated with any of the HIP implementations. There have been implementations of UDP encapsulation for outbound NAT traversal for a few years, according to an expired Internet draft: http://tools.ietf.org/html/draft-schmitt-hip-nat-traversal-02. I don't know how much testing they have undergone; not as much as the non-NAT variants, I would say. The HIP WG has a design team working on NAT traversal, and STUN/ICE is the basic design framework. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Jan 09 02:35:09 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCVSh-0003RV-KJ; Wed, 09 Jan 2008 02:34:55 -0500 Received: from hipsec by megatron.ietf.org with local (Exim 4.43) id 1JCFAc-0006gG-5P for hipsec-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 09:11:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCFAb-0006g7-Rn for hipsec@ietf.org; Tue, 08 Jan 2008 09:11:09 -0500 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCFAa-00017e-8s for hipsec@ietf.org; Tue, 08 Jan 2008 09:11:09 -0500 Received: by py-out-1112.google.com with SMTP id x19so4411980pyg.24 for ; Tue, 08 Jan 2008 06:11:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=hARonup28FvRboe4PbDG124f6W1QCtzxxjnIIRc66+4=; b=jA1GBJjsh7jp2dibFrCLJHdt07uAv8twA+EywG85gOXo+FIkKlSNuI+FDczizPW3as3weH4JkcYaRE6TpA8AxrhX95cP0TBaD8tbfaNu+YRe56+Bnb+mXI+IwzI4lNt2eCHAJn27FZV31D6wbtER5+NXgXzf0VsUj2ZFHEu8Es8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=m0rNq7LBFEzS/YK6xYP5wsim32FeqtBWoP01q7BLAr+wWg/dS3ICJLSl4vJAsrbWHRzIoz5T5tfe2I4eJUYIYlshWOUapCEmyPGQkic/5qx843iG8i5zAdu532Evc1h0BBl1dfNb1Jo/AyhVqiHr3wv5QfkzV45Mq8h2m4TsU8Q= Received: by 10.65.224.11 with SMTP id b11mr45072847qbr.93.1199801466949; Tue, 08 Jan 2008 06:11:06 -0800 (PST) Received: by 10.65.180.16 with HTTP; Tue, 8 Jan 2008 06:11:06 -0800 (PST) Message-ID: <4d4304a00801080611q49033d81pa3368beb93f9928f@mail.gmail.com> Date: Tue, 8 Jan 2008 09:11:06 -0500 From: "David A. Bryan" To: "Paine, Richard H" In-Reply-To: <0C549DAFE1A8004D8EB57ACDD108646D0652083A@XCH-NW-2V2.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <0C549DAFE1A8004D8EB57ACDD108646D06520831@XCH-NW-2V2.nw.nos.boeing.com> <8390D7C9-7EA5-49D2-B4DE-917FFDD89A71@softarmor.com> <0C549DAFE1A8004D8EB57ACDD108646D0652083A@XCH-NW-2V2.nw.nos.boeing.com> X-Google-Sender-Auth: 2c4f6086dd855a4f X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-Mailman-Approved-At: Wed, 09 Jan 2008 02:34:55 -0500 Cc: "Venema, Steve A" , "Wang, Sherry" , p2psip@ietf.org, hipsec@ietf.org, Henry Sinnreich , "Brewer, Orlie T" , "David Ward \(wardd\)" , Roy Kuntz , Dean Willis , "Venema, Steven C" , Sean Olson Subject: [Hipsec] Re: [P2PSIP] Updated: P2PSIP and HIP Joint Meeting on the Boeing VOIP HIPImplementation 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 Some folks asked if the IETF note well statement applied here. Since this is being discussed on list, published on list, etc., I believe it does. So, the note well policy applies. If you aren't familiar with the IETF IPR / Note Well policy, it is here; please read it before the call: http://www.ietf.org/NOTEWELL.html Thanks, David (as chair on P2PSIP) On Jan 7, 2008 3:31 PM, Paine, Richard H wrote: > Non-toll-free number for the P2PSIP and HIP teleconference: > > 203-310-8979 > Participant passcode: 9710856 > > Richard H. Paine > Success is getting what you want, happiness is liking what you get! > Cell: 206-854-8199 > IPPhone: 425-373-8296 > Email: richard.h.paine@boeing.com > > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Monday, January 07, 2008 11:59 AM > To: Paine, Richard H > Subject: Re: [P2PSIP] Updated: P2PSIP and HIP Joint Meeting on the > Boeing VOIP HIPImplementation > > > On Jan 7, 2008, at 9:37 AM, Paine, Richard H wrote: > > > > > It occurs to me that you may have some folks calling in from outside the > US, and US toll-free numbers are notoriously difficult to reach from > some countries. Do you have a non-toll-free number? Or did I just miss > it in that Microsoft-mangled calendar invitation? > > -- > Dean > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Jan 16 05:18:31 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF5Lo-0007mm-Dc; Wed, 16 Jan 2008 05:18:28 -0500 Received: from hipsec by megatron.ietf.org with local (Exim 4.43) id 1JF5Ln-0007mh-ON for hipsec-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 05:18:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF5Ln-0007mZ-9A for hipsec@ietf.org; Wed, 16 Jan 2008 05:18:27 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JF5Lm-0005ep-Q8 for hipsec@ietf.org; Wed, 16 Jan 2008 05:18:27 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id C1BDE2E14; Wed, 16 Jan 2008 12:18:25 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id AE0C42E00; Wed, 16 Jan 2008 12:18:17 +0200 (EET) Date: Wed, 16 Jan 2008 12:18:16 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Andrew McGregor , Thomas Henderson Subject: Re: [Hipsec] API draft In-Reply-To: <1B42813E-AC4E-47AF-9DC7-79ECF63627D6@indranet.co.nz> Message-ID: References: <46CC1F15.6050109@ericsson.com> <1B42813E-AC4E-47AF-9DC7-79ECF63627D6@indranet.co.nz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 Tue, 4 Dec 2007, Andrew McGregor wrote: Hi, I have edited the draft to be more coherent with RFC5014 and also RFC3484 based on comments from Andrew. The draft naturally includes the previous comments from Thomas. The next preversion is here: http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-04-pre3.txt Looking forward for feedback regarding to new sections 4.4 and 4.6 on HIT-based source address selection. Andrew and Tom, could you take a look especially at the section 4.6? Tom, I am also waiting for feedback on the other thread on this mailing list. > I have a question: is this draft coherent in the presence of RFC 5014? > Should there be a few values defined to fit into the RFC 5014 framework? > > Andrew > > On 22/08/2007, at 4:33 AM, Gonzalo Camarillo wrote: > >> Folks, >> >> a few months ago, we had some discussions about the API draft. Miika >> contacted the APPS area folks and got some feedback from them. With that >> feedback, he has generated a new revision of the draft: >> >> http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-02.txt >> >> The discussions with the APPS area folks are documented at: >> >> http://www1.ietf.org/mail-archive/web/discuss/current/msg00496.html >> >> http://www1.ietf.org/mail-archive/web/discuss/current/msg00755.html >> >> >> I would like people to have a look at this draft and send comments to the >> list. Note that our plan was, and still is, to have this draft ready for >> publication request by the end of the year. >> >> There were also discussions on producing a more long-term API at some >> point... but that may fall under the scope of the RG instead. >> >> Cheers, >> >> Gonzalo >> HIP co-chair >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/hipsec >> > > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec -- 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 Thu Jan 17 18:56:54 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFebM-0005XQ-V4; Thu, 17 Jan 2008 18:56:52 -0500 Received: from hipsec by megatron.ietf.org with local (Exim 4.43) id 1JFebL-0005Tv-OW for hipsec-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 18:56:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFebL-0005Sm-Ct for hipsec@ietf.org; Thu, 17 Jan 2008 18:56:51 -0500 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFebJ-00018y-5N for hipsec@ietf.org; Thu, 17 Jan 2008 18:56:51 -0500 Received: from localhost (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 MAA25338; Fri, 18 Jan 2008 12:56:36 +1300 Message-Id: From: Andrew McGregor To: Miika Komu In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [Hipsec] API draft Date: Fri, 18 Jan 2008 12:56:28 +1300 References: <46CC1F15.6050109@ericsson.com> <1B42813E-AC4E-47AF-9DC7-79ECF63627D6@indranet.co.nz> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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 That looks like as minimal as you can get and still support everything necessary. Well done. I believe 3484 and 5014 made it a lot simpler. 4.6 looks completely correct, the precedences make sense. Note: I haven't read for editorial nits, only content. Andrew On 16/01/2008, at 11:18 PM, Miika Komu wrote: > On Tue, 4 Dec 2007, Andrew McGregor wrote: > > Hi, > > I have edited the draft to be more coherent with RFC5014 and also > RFC3484 based on comments from Andrew. The draft naturally includes > the previous comments from Thomas. The next preversion is here: > > http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-04-pre3.txt > > Looking forward for feedback regarding to new sections 4.4 and 4.6 > on HIT-based source address selection. Andrew and Tom, could you > take a look especially at the section 4.6? Tom, I am also waiting > for feedback on the other thread on this mailing list. > >> I have a question: is this draft coherent in the presence of RFC >> 5014? Should there be a few values defined to fit into the RFC 5014 >> framework? >> >> Andrew >> >> On 22/08/2007, at 4:33 AM, Gonzalo Camarillo wrote: >> >>> Folks, >>> a few months ago, we had some discussions about the API draft. >>> Miika contacted the APPS area folks and got some feedback from >>> them. With that feedback, he has generated a new revision of the >>> draft: >>> http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-02.txt >>> The discussions with the APPS area folks are documented at: >>> http://www1.ietf.org/mail-archive/web/discuss/current/msg00496.html >>> http://www1.ietf.org/mail-archive/web/discuss/current/msg00755.html >>> I would like people to have a look at this draft and send comments >>> to the list. Note that our plan was, and still is, to have this >>> draft ready for publication request by the end of the year. >>> There were also discussions on producing a more long-term API at >>> some point... but that may fall under the scope of the RG instead. >>> Cheers, >>> Gonzalo >>> HIP co-chair >>> _______________________________________________ >>> Hipsec mailing list >>> Hipsec@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/hipsec >> >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/hipsec > > -- > 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 Jan 20 13:48:58 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGfDx-0001b5-O2; Sun, 20 Jan 2008 13:48:53 -0500 Received: from hipsec by megatron.ietf.org with local (Exim 4.43) id 1JGfDv-0001ax-P0 for hipsec-confirm+ok@megatron.ietf.org; Sun, 20 Jan 2008 13:48:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGfDv-0001am-4n for hipsec@ietf.org; Sun, 20 Jan 2008 13:48:51 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGfDu-00020S-Qw for hipsec@ietf.org; Sun, 20 Jan 2008 13:48:51 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 20 Jan 2008 10:48:50 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0KImovp028420 for ; Sun, 20 Jan 2008 10:48:50 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.12.10/8.12.6) with SMTP id m0KImnsj001655 for ; Sun, 20 Jan 2008 18:48:50 GMT Message-Id: <065C90A6-0CB0-4C01-A168-5670A2C5F63E@cisco.com> From: Cullen Jennings To: HIP Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Sun, 20 Jan 2008 10:48:34 -0800 X-Mailer: Apple Mail (2.915) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=107; t=1200854930; x=1201718930; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Value=20of=20I1=20retransmission=20timer |Sender:=20; bh=JkRNjfi3rmBKFwHhoYVXAZYqjFm1gd1jpVNw5GebAR0=; b=S4Z2TDBwxbaN1cLBAeOnzO6c3Ho9Dj/Jc0BxM3+6HxE4ai/MPZUPuiAwG3 /kjkg8n1IGjCZld3WR2oemxvabw9bWjwZxcCIE3RFqOAHYBK9zApf0IK3F+/ 6Ewmw9JONFFBKM4YOKO//25BSPX8XpvIVa2BbQL1aee+GLLAEZkng=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: Subject: [Hipsec] Value of I1 retransmission timer 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 What are implementations actually using for the value of the retransmission timer? Thanks, Cullen _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Jan 20 16:21:57 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGhc3-0000J4-IW; Sun, 20 Jan 2008 16:21:55 -0500 Received: from hipsec by megatron.ietf.org with local (Exim 4.43) id 1JGhc2-0000Iz-Rs for hipsec-confirm+ok@megatron.ietf.org; Sun, 20 Jan 2008 16:21:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGhc2-0000Ir-9Q for hipsec@ietf.org; Sun, 20 Jan 2008 16:21:54 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGhc1-0001M4-Uh for hipsec@ietf.org; Sun, 20 Jan 2008 16:21:54 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id DE7A22D8B; Sun, 20 Jan 2008 23:21:52 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.2.4-niksula20070810 (2008-01-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.4-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 4F57E2D0C; Sun, 20 Jan 2008 23:21:52 +0200 (EET) Date: Sun, 20 Jan 2008 23:21:51 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Cullen Jennings Subject: Re: [Hipsec] Value of I1 retransmission timer In-Reply-To: <065C90A6-0CB0-4C01-A168-5670A2C5F63E@cisco.com> Message-ID: References: <065C90A6-0CB0-4C01-A168-5670A2C5F63E@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 Sun, 20 Jan 2008, Cullen Jennings wrote: Hi, > What are implementations actually using for the value of the retransmission > timer? HIPL implementation currently retransmits every 10 seconds and gives up after five failures. HIP daemon will continue retransmission even longer if the application persists longer than this, or another application tries to use the same HIT pair. -- 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 Jan 21 05:40:12 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGu4Z-0001yg-7F; Mon, 21 Jan 2008 05:40:11 -0500 Received: from hipsec by megatron.ietf.org with local (Exim 4.43) id 1JGu4X-0001ya-CY for hipsec-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 05:40:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGu4X-0001yS-2v for hipsec@lists.ietf.org; Mon, 21 Jan 2008 05:40:09 -0500 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGu4W-00018p-Q0 for hipsec@lists.ietf.org; Mon, 21 Jan 2008 05:40:09 -0500 Received: by nf-out-0910.google.com with SMTP id 4so237078nfv.31 for ; Mon, 21 Jan 2008 02:40:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=tzY3A4hKQJnKGPMVg+K4lURr/r/lAUcpIIq40tVBrRE=; b=V8Sud0T/aDMG28Bb5lqxY+PKYA/187Y8xKKYniZriLfp77z/x4Zyl3YNiPDNgj0j3q3y4fiGN9VWjQ4+BM99TY5IY9xs1GotLGvMNePg1wb3pEpYr6HVty1dwNIaPVzHw6eyPirX8v/yH71l4FlDdYc6eIfO/RkdPwtJVxraLPo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=Z3konAM/RXuC1klJkodtEN/x9MZ5Ez0JjuDL5k+2Ek321M5VOpqHOnmmMMnhtfYppia9XPQtMwSHljmy7cKv1/w7cQtnSkCb9N6bOyu5lkCZ6G1Na9Sfm91yDE1sc80gNoybJW0ftdMjabcpdGQreqBW4Cvp0wusxosqqCBjV3M= Received: by 10.78.81.20 with SMTP id e20mr8676874hub.60.1200912007602; Mon, 21 Jan 2008 02:40:07 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id d24sm1991314nfh.19.2008.01.21.02.40.05 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Jan 2008 02:40:06 -0800 (PST) From: Julien Laganier To: hipsec@lists.ietf.org Subject: Re: [Hipsec] Value of I1 retransmission timer Date: Mon, 21 Jan 2008 11:40:11 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <065C90A6-0CB0-4C01-A168-5670A2C5F63E@cisco.com> In-Reply-To: <065C90A6-0CB0-4C01-A168-5670A2C5F63E@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801211140.12694.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 Sunday 20 January 2008, Cullen Jennings wrote: > What are implementations actually using for the value of the > retransmission timer? I used to have a configurable retransmission timer set to 3 seconds as default. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jan 21 05:40:16 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGu4d-00021B-1D; Mon, 21 Jan 2008 05:40:16 -0500 Received: from hipsec by megatron.ietf.org with local (Exim 4.43) id 1JGu4Z-0001zC-Nh for hipsec-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 05:40:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGu4Y-0001yh-B8 for hipsec@ietf.org; Mon, 21 Jan 2008 05:40:11 -0500 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGu4W-00018q-VY for hipsec@ietf.org; Mon, 21 Jan 2008 05:40:10 -0500 Received: by nf-out-0910.google.com with SMTP id d21so215557nfb.39 for ; Mon, 21 Jan 2008 02:40:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=tzY3A4hKQJnKGPMVg+K4lURr/r/lAUcpIIq40tVBrRE=; b=V8Sud0T/aDMG28Bb5lqxY+PKYA/187Y8xKKYniZriLfp77z/x4Zyl3YNiPDNgj0j3q3y4fiGN9VWjQ4+BM99TY5IY9xs1GotLGvMNePg1wb3pEpYr6HVty1dwNIaPVzHw6eyPirX8v/yH71l4FlDdYc6eIfO/RkdPwtJVxraLPo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=Z3konAM/RXuC1klJkodtEN/x9MZ5Ez0JjuDL5k+2Ek321M5VOpqHOnmmMMnhtfYppia9XPQtMwSHljmy7cKv1/w7cQtnSkCb9N6bOyu5lkCZ6G1Na9Sfm91yDE1sc80gNoybJW0ftdMjabcpdGQreqBW4Cvp0wusxosqqCBjV3M= Received: by 10.78.81.20 with SMTP id e20mr8676874hub.60.1200912007602; Mon, 21 Jan 2008 02:40:07 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id d24sm1991314nfh.19.2008.01.21.02.40.05 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Jan 2008 02:40:06 -0800 (PST) From: Julien Laganier To: hipsec@lists.ietf.org Subject: Re: [Hipsec] Value of I1 retransmission timer Date: Mon, 21 Jan 2008 11:40:11 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <065C90A6-0CB0-4C01-A168-5670A2C5F63E@cisco.com> In-Reply-To: <065C90A6-0CB0-4C01-A168-5670A2C5F63E@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801211140.12694.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 Sunday 20 January 2008, Cullen Jennings wrote: > What are implementations actually using for the value of the > retransmission timer? I used to have a configurable retransmission timer set to 3 seconds as default. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jan 21 14:47:58 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH2ce-0008JX-Cb; Mon, 21 Jan 2008 14:47:56 -0500 Received: from hipsec by megatron.ietf.org with local (Exim 4.43) id 1JH2cc-0008JS-Dy for hipsec-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 14:47:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH2cc-0008J5-3l for hipsec@ietf.org; Mon, 21 Jan 2008 14:47:54 -0500 Received: from n2.nomadiclab.com ([2001:14b8:400:101::2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JH2cZ-0002o1-Jk for hipsec@ietf.org; Mon, 21 Jan 2008 14:47:54 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 104C41F8E6C; Mon, 21 Jan 2008 21:47:50 +0200 (EET) Received: from localhost (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id CC4671F2044; Mon, 21 Jan 2008 21:47:49 +0200 (EET) From: Jan Mikael Melen To: Cullen Jennings Subject: Re: [Hipsec] Value of I1 retransmission timer Date: Mon, 21 Jan 2008 21:47:46 +0200 User-Agent: KMail/1.9.7 References: <065C90A6-0CB0-4C01-A168-5670A2C5F63E@cisco.com> In-Reply-To: <065C90A6-0CB0-4C01-A168-5670A2C5F63E@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801212147.47376.Jan.Melen@nomadiclab.com> X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 4.5 (++++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 Hi, HIP4Inter.net is implementing exponential backoff for retransmitting I1 packets. The timer has a initial value of 500ms and does 5 retransmissions. Jan On Sunday 20 January 2008 20:48:34 Cullen Jennings wrote: > What are implementations actually using for the value of the > retransmission timer? > > Thanks, Cullen > > > > _______________________________________________ > 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 Jan 21 16:33:43 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH4Gy-0006JH-JX; Mon, 21 Jan 2008 16:33:40 -0500 Received: from hipsec by megatron.ietf.org with local (Exim 4.43) id 1JH4Gx-0006JA-Ov for hipsec-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 16:33:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH4Gx-0006J2-7u for hipsec@ietf.org; Mon, 21 Jan 2008 16:33:39 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JH4Gw-0001Lo-UO for hipsec@ietf.org; Mon, 21 Jan 2008 16:33:39 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m0LLXXlN021092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Jan 2008 13:33:38 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m0LLXXP3019574; Mon, 21 Jan 2008 15:33:33 -0600 (CST) 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.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m0LLXLwq019195; Mon, 21 Jan 2008 15:33:33 -0600 (CST) 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, 21 Jan 2008 13:33:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Value of I1 retransmission timer Date: Mon, 21 Jan 2008 13:33:32 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D04049B57@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <065C90A6-0CB0-4C01-A168-5670A2C5F63E@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] Value of I1 retransmission timer Thread-Index: AchblSLk2YDNF1FJRSC4g8gcD0Iu9QA31w1w References: <065C90A6-0CB0-4C01-A168-5670A2C5F63E@cisco.com> From: "Henderson, Thomas R" To: "Cullen Jennings" , "HIP" X-OriginalArrivalTime: 21 Jan 2008 21:33:32.0961 (UTC) FILETIME=[45A7C110:01C85C75] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 OpenHIP: By default=20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: Sunday, January 20, 2008 10:49 AM > To: HIP > Subject: [Hipsec] Value of I1 retransmission timer >=20 >=20 > What are implementations actually using for the value of the =20 > retransmission timer? By default, OpenHIP will send an I1 and retransmit every 10 seconds (no backoff) until five retransmissions have failed. The default retransmission behavior is therefore to send six I1s spaced 10 seconds apart before moving to E-FAILED state. =20 Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jan 22 02:45:49 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHDpL-0006St-17; Tue, 22 Jan 2008 02:45:47 -0500 Received: from hipsec by megatron.ietf.org with local (Exim 4.43) id 1JHDpJ-0006JM-G6 for hipsec-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 02:45:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHDpC-000654-I6 for hipsec@ietf.org; Tue, 22 Jan 2008 02:45:38 -0500 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHDpC-0001l7-8L for hipsec@ietf.org; Tue, 22 Jan 2008 02:45:38 -0500 Received: by ug-out-1314.google.com with SMTP id u2so2506048uge.46 for ; Mon, 21 Jan 2008 23:45:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=hIA5SaGJLdkbfVM60XXqjGoAJ0vPiqJwRylM8TKrEy4=; b=qtpzq/1IDZe9cjK/uxrBSgvk8ocBIijAv/GvmZs06Q46RFux2cnCsvDsrN7c8uRxHhg1wnd2nkrkXUwX3duQ/b2BbChB4pBDHxeHFpllr+u/WzD1bxmlvvUp7EcrnHrptwTrXhfYrJYZHNxSu4SsmgO7YRyZMZMiRoDmr466QWQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=ZnT5rze5shP8+45llo+X+tK0XquCddt7BOV2NiOyS6dDXODVnP5dH4LrRhzahRrbRJDCKPcQJityVL0efr6IWzXdPe7OCegxozfU0MfM83hbaf5s9jMY5euX53tJNnLCS+QDF98DUUDTwcWsPif3CGxXjihMaFgAAxRf/cq2mWs= Received: by 10.66.217.20 with SMTP id p20mr5324959ugg.51.1200987937101; Mon, 21 Jan 2008 23:45:37 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id q1sm22138191uge.7.2008.01.21.23.45.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Jan 2008 23:45:36 -0800 (PST) From: Julien Laganier To: HIP Subject: Re: [Hipsec] Value of I1 retransmission timer Date: Tue, 22 Jan 2008 08:45:45 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <065C90A6-0CB0-4C01-A168-5670A2C5F63E@cisco.com> <200801211140.12694.julien.IETF@laposte.net> In-Reply-To: <200801211140.12694.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801220845.46029.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 On Monday 21 January 2008, Julien Laganier wrote: > On Sunday 20 January 2008, Cullen Jennings wrote: > > What are implementations actually using for the value of the > > retransmission timer? > > I used to have a configurable retransmission timer set to 3 seconds > as default. forgot to say that I used exponential backoff too. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Jan 23 09:04:40 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHgDX-0000ij-2v; Wed, 23 Jan 2008 09:04:39 -0500 Received: from hipsec by megatron.ietf.org with local (Exim 4.43) id 1JHgDV-0000id-SN for hipsec-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 09:04:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHgDV-0000iL-Hw for hipsec@ietf.org; Wed, 23 Jan 2008 09:04:37 -0500 Received: from mta-2.ms.rz.rwth-aachen.de ([134.130.7.73]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHgDT-0008Dq-C4 for hipsec@ietf.org; Wed, 23 Jan 2008 09:04:37 -0500 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.3.58]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JV300891OFMPRB0@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Wed, 23 Jan 2008 15:04:34 +0100 (CET) Received: from relay.rwth-aachen.de ([134.130.3.1]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Wed, 23 Jan 2008 15:04:34 +0100 Received: from [137.226.59.120] (informatik-lufgi-4-137-226-59-120.una.RWTH-Aachen.DE [137.226.59.120] (may be forged)) by relay.rwth-aachen.de (8.13.7/8.13.3/1) with ESMTP id m0NE4XFo018327; Wed, 23 Jan 2008 15:04:33 +0100 (MET) Date: Wed, 23 Jan 2008 15:04:02 +0100 From: Tobias Heer In-reply-to: <200801231440.38883.julien.IETF@laposte.net> To: hip WG Message-id: <9CCE5C4B-CA78-45DE-8784-9242D42747ED@cs.rwth-aachen.de> MIME-version: 1.0 X-Mailer: Apple Mail (2.753) X-IronPort-AV: E=Sophos;i="4.25,238,1199660400"; d="p7s'?scan'208,217";a="46088207" References: <77F357662F8BFA4CA7074B0410171B6D04049B5D@XCH-NW-5V1.nw.nos.boeing.com> <200801231143.13033.julien.IETF@laposte.net> <34A29409-C62E-42AB-A77B-F283F276A526@cs.rwth-aachen.de> <200801231440.38883.julien.IETF@laposte.net> X-Spam-Score: -4.0 (----) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Cc: Julien Laganier Subject: [Hipsec] Re: [Hipsec-rg] next steps with draft-heer-hip-middle-auth-00 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: , Content-Type: multipart/mixed; boundary="===============0942742739==" Errors-To: hipsec-bounces@lists.ietf.org --===============0942742739== Content-type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4--548457076; protocol="application/pkcs7-signature" --Apple-Mail-4--548457076 Content-Type: multipart/alternative; boundary=Apple-Mail-3--548457168 --Apple-Mail-3--548457168 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Julien, Am 23.01.2008 um 14:40 schrieb Julien Laganier: > Hello Tobias, > > On Wednesday 23 January 2008, Tobias Heer wrote: >> The scope of the draft is to illustrate a possible replay attack >> towards the middlebox and proposes a solution that enables the >> middlebox to interact with the BEX. >> >>> I think the draft should more accurately state what is the goal, >>> security-wise. E.g. authentication alone is vague and prone to >>> ambiguous interpretation. Once that is done, relevance of the >>> solution can be assessed. >> >> Do you think the title is misleading or do you believe we should be >> more specific in the abstract and text? > > I am actually unclear about the goal of BEX inspection by middlebox > (e.g. signature verification). What kind of security service does it > offer? > The goal is that the middlebox can verify the Identity of the hosts that communicate across it unambiguously. Practical usecases could be middleboxes that enforces certain policies based on the identities of two hosts. The middlebox could perform access control (only certain hosts may communicate across the middlebox), or it may perform accounting (e.g. based on traffic volume or connection duration). Every usecase in which a middlebox needs to know who is communicating would apply. If the middlebox only uses the HIs in the BEX and update packets and the signatures generated with these HIs to verify the Identities of the communicating peers, replay attacks are possible: A malicious Initiator collaborating with an malicious Responder can replay authentic BEXes of other hosts to the middlebox and thus, both attackers can impersonate the hosts that performed the authentic BEX. The draft solves this problem by letting the middlebox participate in the BEX and the HIP update process. I have sent an e-mail illustrating the attack to the HIP lists in Summer 2007. Here is a link to the email describing the replay attack: http://www1.ietf.org/mail-archive/web/hipsec/current/msg02157.html I hope this clarifies the scope of the drafft. Best regards, Tobias > Once we have a good understanding of that, we can discuss about what > your draft tries to achieve, and how. > > Thanks. > > --julien > -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany http://ds.cs.rwth-aachen.de/members/heer --Apple-Mail-3--548457168 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Julien,=A0

Am 23.01.2008 um 14:40 schrieb Julien = Laganier:

Hello Tobias,

On = Wednesday 23 January 2008, Tobias Heer wrote:
The scope of the draft is to = illustrate a possible replay attack =A0
towards = the middlebox and proposes a solution that enables the =A0
middlebox to interact with the BEX.

I think the draft should more = accurately state what is the goal,
ambiguous interpretation. Once that is done, = relevance of the
solution can be assessed.
=

Do you think the title is misleading or do you = believe we should be =A0
more specific = in the abstract and text?

I am actually = unclear about the goal of BEX inspection by middlebox=A0
(e.g. = signature verification). What kind of security service does it=A0
Practical usecases could = be=A0middleboxes that enforces certain policies based on the identities = of two hosts. The middlebox could perform access control (only certain = hosts may communicate across the middlebox), or it may perform = accounting (e.g. based on traffic volume or connection duration). Every = usecase in which a middlebox needs to know who is communicating would = apply.

If = the middlebox only uses the HIs in the BEX and update packets and the = signatures generated with these HIs to verify the Identities of the = communicating peers, replay attacks are possible:=A0A malicious = Initiator collaborating with an malicious Responder can replay authentic = BEXes of other hosts to the middlebox and thus, both attackers can = impersonate the hosts that performed the authentic BEX. The draft solves = this problem by letting the middlebox participate in the BEX and the HIP = update process.

I have sent an e-mail = illustrating the attack to the HIP lists in Summer 2007.=A0
Here= is a link to the email describing the replay attack:=A0
http://www1.ietf.org/mail-archive/web/hipsec/current/msg02157.html

I hope this = clarifies the scope of the drafft.

Best = regards,

Tobias





Once we have a good understanding of that, we can = discuss about what=A0
your draft tries to achieve, and how.


--julien





--=A0=A0
Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group=A0
RWTH Aachen University, Germany




 =

= --Apple-Mail-3--548457168-- --Apple-Mail-4--548457076 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQjCCAvsw ggJkoAMCAQICEC1IEZFFsMbqCTfVL3CGGP8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDcwNjA2NDQ0MloXDTA4MDcwNTA2NDQ0 MlowXTENMAsGA1UEBBMESGVlcjEPMA0GA1UEKhMGVG9iaWFzMRQwEgYDVQQDEwtUb2JpYXMgSGVl cjElMCMGCSqGSIb3DQEJARYWaGVlckBjcy5yd3RoLWFhY2hlbi5kZTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMw9OUSRfF10zWkVrIsXsjCC8hsCRqg7NLKWYPr1M7CfJyk/0B14o8Eu PK1qUfjl1w/E5rlHIuC3rbok9tV2hHsWqPV9+tAAr4g5QJVNrou9BCD7vHPuCMJ/7WTWMcEewmS2 +U0762iVFK/bLSKwPvaaQWQV1ULUy9zJaLPHQQIAVooBQSypQy+wtxJ3PIn6nfQQnE8hc+hhz5gd 8jLoGozYz0Xv75W4YSYRjH+/R+JLS60do+V2Si1BUaOjQPS+PBSI3uNmWQQCJOb/3LBFDiUBNWe5 PoVe+HiHZi+L4s0wimzu9O/y7IUme6U5kWQTcMYdVTqxkHDk/TbcAjniyE0CAwEAAaMzMDEwIQYD VR0RBBowGIEWaGVlckBjcy5yd3RoLWFhY2hlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEB BQUAA4GBAD+gsUZ2GBKOG8XHPo8vGSBn85ucmwhiY7CHF+B9EvLKX1QebGCg7TooQLvJOighEUCt d5L59l4kjM6u3PrwcHlUkDeImHW3LP2bOvkXhmpYKTLz1QxlnV3WtyydO0JvNQz9pLSI2DAwuPx1 8E7q/XdJ5IWg6J1acNpiNhMuXOrhMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRow GAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNl cyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZI hvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEz MDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Ia dr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+ K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1Ud EwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1Ro YXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRow GAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2as Zw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCU YsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9l TzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhAtSBGRRbDG6gk31S9whhj/MAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDEyMzE0MDQwMlowIwYJKoZIhvcNAQkEMRYEFHAK0Pctv0Wx eUOdxX4aTPxejh//MIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQLUgRkUWwxuoJN9UvcIYY/zCBhwYLKoZIhvcNAQkQAgsxeKB2MGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQLUgRkUWwxuoJN9UvcIYY /zANBgkqhkiG9w0BAQEFAASCAQC/tQJne7accuLjxxTVTzPmyq4ObRPar/IG0xa7PlUF1O7naXPy wLhcTC8MpYRPFk3hKnvDNAfnxhy0/ImPJhhg4B2yqYzsZz59Ie5PreA+oFECQQbUrbK3uFRt8jj7 ZBTSlSaIPmieec9R5D8S9xaaifWfg11BWTwaUFTVN2+O8D/k4hsGFuw+J/eB9uqop/wCRwH6jGJT /r2iAXW3J0GnphaMdN5c4U6cGnivmBDJDmuLSBAOa5DAL1wutQhgNn+3lp4O4gYwVGgtqo4nM+Nx AvcmewzksdRZr4oGCTbccywV1Jt07bGtDoYKVBUh5kmj25GvezFhp4Pty1GnFV93AAAAAAAA --Apple-Mail-4--548457076-- --===============0942742739== 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 --===============0942742739==-- From hipsec-bounces@lists.ietf.org Wed Jan 23 09:23:59 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHgWE-0000gF-Lw; Wed, 23 Jan 2008 09:23:58 -0500 Received: from hipsec by megatron.ietf.org with local (Exim 4.43) id 1JHgWD-0000Xz-Ap for hipsec-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 09:23:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHgWC-0000VC-SN for hipsec@ietf.org; Wed, 23 Jan 2008 09:23:56 -0500 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHgWA-0000At-Iq for hipsec@ietf.org; Wed, 23 Jan 2008 09:23:56 -0500 Received: by ug-out-1314.google.com with SMTP id u2so224784uge.46 for ; Wed, 23 Jan 2008 06:23:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=rGBAaQGHjmVLAGFjP5gY1vZwCu/VZXavTR6ebFkoxnk=; b=AIN5JZ7IMyaTtGxoyDndcYsTitdeoMSGziE8klUQ5f64yWOboLYyKimxz9Bwd5egBOcVgbwmY4EPZw59ABOGpdpF+mQK61CLW2OmX/NbGt2Aa5B4XbWUWjSAv/BX7L614sFWLrbe/NvoUTNxJZCTHeN4wr+dvCuOWArPyQ2Ges8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=aF5crSKJZc9ls0z67s5vb14H6lxFMBfdsJ8oHEmqpYGHS939vfac4/CX72uWlS0d0eJGy2BStjKdcgGs8ylUi37RFF3bLBF6mE9MADZKMdpIXYzwKpLaoct+oT8HNlAWrWhg3OiUg5Kh9Fk/2wQCBMObwE+Cp4hABNWZotNrpls= Received: by 10.67.20.19 with SMTP id x19mr964884ugi.48.1201098233494; Wed, 23 Jan 2008 06:23:53 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id k30sm2033277ugc.53.2008.01.23.06.23.51 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Jan 2008 06:23:52 -0800 (PST) From: Julien Laganier To: Tobias Heer Date: Wed, 23 Jan 2008 15:24:05 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <77F357662F8BFA4CA7074B0410171B6D04049B5D@XCH-NW-5V1.nw.nos.boeing.com> <200801231440.38883.julien.IETF@laposte.net> <9CCE5C4B-CA78-45DE-8784-9242D42747ED@cs.rwth-aachen.de> In-Reply-To: <9CCE5C4B-CA78-45DE-8784-9242D42747ED@cs.rwth-aachen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200801231524.05815.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: hip WG Subject: [Hipsec] Re: [Hipsec-rg] next steps with draft-heer-hip-middle-auth-00 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 Wednesday 23 January 2008, Tobias Heer wrote: > > I am actually unclear about the goal of BEX inspection by middlebox > > (e.g. signature verification). What kind of security service does > > it offer? > > The goal is that the middlebox can verify the Identity of the hosts =A0 > that communicate across it unambiguously. This is ambiguous in itself :)=20 AFAIU, 'communicate' refers only the BEX. The middlebox doesn't verify=20 identity of the hosts sending payload packets (e.g., ESP). > Practical usecases could be middleboxes that enforces certain =A0 > policies based on the identities of two hosts. The middlebox could =A0 > perform access control (only certain hosts may communicate across the > =A0 middlebox), or it may perform accounting (e.g. based on traffic > volume or connection duration). Every usecase in which a middlebox > needs to know who is communicating would apply. Agree that in every such usecase the middlebox needs to know who is=20 communicating.=20 The point is that the current HIP middlebox story where midboxes are=20 verifying signatures in the BEX doesn't achieve that (see above). Thus,=20 we cannot use the BEX inspection in any of these usecase... Let's first discuss what is (are?) the security service(s) offered by=20 midbox BEX inspection. =2D-julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jan 28 11:41:49 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJX3H-0007aV-U6; Mon, 28 Jan 2008 11:41:43 -0500 Received: from hipsec by megatron.ietf.org with local (Exim 4.43) id 1JJX3G-0007Yc-6T for hipsec-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 11:41:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJX3F-0007Wd-PS for hipsec@ietf.org; Mon, 28 Jan 2008 11:41:41 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJX3F-0000km-5q for hipsec@ietf.org; Mon, 28 Jan 2008 11:41:41 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m0SGfQTm010491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Jan 2008 10:41:32 -0600 (CST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m0SGfQlm010413; Mon, 28 Jan 2008 08:41:26 -0800 (PST) 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.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m0SGfO5a010309; Mon, 28 Jan 2008 08:41:26 -0800 (PST) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jan 2008 08:41:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] WGLC: draft-ietf-hip-native-api-03.txt Date: Mon, 28 Jan 2008 08:41:25 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D04049B89@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] WGLC: draft-ietf-hip-native-api-03.txt Thread-Index: AchPy/xj8LL1mP1YRhS4FAvVVU3qkgR+DOIg References: <474DDBFA.1050509@ericsson.com><77F357662F8BFA4CA7074B0410171B6D04049A98@XCH-NW-5V1.nw.nos.boeing.com> From: "Henderson, Thomas R" To: "Miika Komu" X-OriginalArrivalTime: 28 Jan 2008 16:41:26.0252 (UTC) FILETIME=[9FD072C0:01C861CC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 Hi Miika, Sorry for the latency in responding. Partly this is because I was thinking a bit about some of the larger issues with this draft: http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-04-pre3.txt >=20 > > In section 4.2 (resolver extensions), the description implies that a > > resolver will have to do two queries (nodename to HITs and=20 > nodename to > > IP addresses), and concatenate the results in the rres field, before > > returning from getaddrinfo(). Shouldn't the application=20 > instead issue > > two getaddrinfo's for each of the different queries? >=20 > Why complicate things unnecessarily for the developer? The=20 > current API is=20 > designed so that it can be used in existing apps with minimal changes=20 > (i.e. by adding some flags).=20 This depends perhaps on the perception of what complicates things for the developer. I do not agree that trying to make the native HIP API deviate as little as possible from the address-based API should be the primary goal here. Rather, the main goal should be to have an API with clear semantics, which is somewhat in conflict with aligning with the address-based API because functions and data structures get overloaded. The sockets API is already roundly criticized for its semantic ambiguity; I think we should not make things worse if we can help it. Here are two main issues I have with the current draft: - it presumes that DNS is the entry point for applications to use HIP. Personally, I suspect that HIP-based applications will more often than not use something else like a DHT, or other things we haven't thought of yet. But the main issue is that this draft delegates handling of the HIT/IP address bindings to an intermediate layer; i.e., it is kind of a higher-level API. This might be a nice eventual goal in some cases but I think that introducing the abstraction immediately (that applications never need to handle locators) might be taking too big of an initial step. =20 - there is a mixture of IP addresses and HITs in some cases (HIP_ADDR_ANY); a given data structure may hold an IP address or a HIT depending on the context. I understand the appeal for doing it this way because it involves the least change to the current sockets API, but I think it will lead to semantic difficulties later. I would rather that we consider the design that addresses are in address data structures and HITs are in HIT data structures and not to mix these. The current draft covers a lot of ground; not only is the basic API (partially) covered but also resolver interactions and now (in the latest version) source HIT selection policy. My preference would be to focus first on the basic raw API and then move to the other points. I would like to suggest the following steps. 1) try to write a draft that has no DNS/DHT dependency whatsoever. The starting assumption is that the application holds zero or more HITs and zero or more locators for the host it is trying to communicate with, and possibly additional information such as rendezvous server information. In other words, the draft picks up at the point after any DNS or DHT resolutions have occurred. 2) write down the various use cases of interest, and how the system should respond from an application's perspective for each of them. For instance, what if the destination HIT field is wildcarded but there are locators (opportunistic mode). What if both destination HIT fields and address fields are wildcarded (illegal). What should the system do if the locators field is empty and it doesn't have the binding? For instance, what error should be conveyed to the application if a HIT but no locators are provided, and the system cannot resolve the locator? How does this differ from the case when the locator is resolved but the host at that address denies ownership of that HIT? Note that the case where the intelligent resolver caches address/locator bindings (i.e., the current draft) can be a particular use case elaborated. 3) once the WG agrees on the use cases and the policies that are implicit therein, then adopt/adapt the existing sockets API as needed. I would be willing to help work on such revisions, but I'd first like to hear from the rest of the WG whether they agree with my concerns or whether the current draft direction is fine with everyone else and I should just stand down. =20 Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jan 29 04:03:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJmNO-00015Q-JP; Tue, 29 Jan 2008 04:03:30 -0500 Received: from hipsec by megatron.ietf.org with local (Exim 4.43) id 1JJmNO-00015L-1H for hipsec-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 04:03:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJmNN-00015D-JV for hipsec@ietf.org; Tue, 29 Jan 2008 04:03:29 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJmNM-0006RY-CZ for hipsec@ietf.org; Tue, 29 Jan 2008 04:03:29 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 698C72E03; Tue, 29 Jan 2008 11:03:27 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 72DC72CB0; Tue, 29 Jan 2008 11:03:19 +0200 (EET) Date: Tue, 29 Jan 2008 11:03:18 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: "Henderson, Thomas R" Subject: RE: [Hipsec] WGLC: draft-ietf-hip-native-api-03.txt In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D04049B89@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: References: <474DDBFA.1050509@ericsson.com><77F357662F8BFA4CA7074B0410171B6D04049A98@XCH-NW-5V1.nw.nos.boeing.com> <77F357662F8BFA4CA7074B0410171B6D04049B89@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: a8041eca2a724d631b098c15e9048ce9 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 Mon, 28 Jan 2008, Henderson, Thomas R wrote: Hi Tom, > Hi Miika, > > Sorry for the latency in responding. Partly this is because I was > thinking a bit about some of the larger issues with this draft: > http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-04-pre3.txt no problem and thanks for the comments! Some comments below and the next version based on your technical corrections is here: http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-04-pre4.txt Tom, please send further comments and technical feedback to the list ASAP so that I can post the draft to the official IETF archives. >>> In section 4.2 (resolver extensions), the description implies that a >>> resolver will have to do two queries (nodename to HITs and >> nodename to >>> IP addresses), and concatenate the results in the rres field, before >>> returning from getaddrinfo(). Shouldn't the application >> instead issue >>> two getaddrinfo's for each of the different queries? >> >> Why complicate things unnecessarily for the developer? The current API >> is designed so that it can be used in existing apps with minimal >> changes (i.e. by adding some flags). > > This depends perhaps on the perception of what complicates things for > the developer. I do not agree that trying to make the native HIP API > deviate as little as possible from the address-based API should be the > primary goal here. Rather, the main goal should be to have an API with > clear semantics, which is somewhat in conflict with aligning with the > address-based API because functions and data structures get overloaded. Have you thought about what the application would look like when it is going to do two resolver calls and can initiate both HIP and non-HIP connections? > The sockets API is already roundly criticized for its semantic > ambiguity; I think we should not make things worse if we can help it. Can you be more specific what parts of the sockets API have received criticism? AFAIK, the main part I've heard of in the apps area is the resolver part which has not met its promises in the real world. Also, it was not originally designed with multihoming in mind. I believe you are suggesting here effectively an additional deployment obstacle. Even my futile attempt to introduce an additional abstraction ("end-point descriptor") to the HIP sockets API extensions (in draft 02 version) was shot down by the research, apps area and hip community. I have some serious doubts about the future of such an approach. I think we need to follow the narrow path of sockets API to its end for two reasons. First, to facilititate deployment of HIP-enabled applications by introducing minimal changes to the current applications. Second, to get experimental-driven feedback on where to improve when designing better APIs for the future. Either from the scratch, or as python/java/c-library/etc middleware on top of the sockets API (apps-area folks think that the latter will be the reality). This is getting a little-bit off topic... > Here are two main issues I have with the current draft: > > - it presumes that DNS is the entry point for applications to use HIP. > Personally, I suspect that HIP-based applications will more often than > not use something else like a DHT, or other things we haven't thought of > yet. But the main issue is that this draft delegates handling of the > HIT/IP address bindings to an intermediate layer; i.e., it is kind of a > higher-level API. This might be a nice eventual goal in some cases but > I think that introducing the abstraction immediately (that applications > never need to handle locators) might be taking too big of an initial > step. I disagree about the DNS presumptions partially. There is one section, 4.5. Manual Handling of Locators, dedicated completely to non-lookup environments. I agree that the draft has more focus on DNS, but I believe think this is acceptable since most of the current applications rely on DNS. Also, now that the draft is more compatible with RFC5014, there is more space for e.g. OpenDHT-related resolution flags. > - there is a mixture of IP addresses and HITs in some cases > (HIP_ADDR_ANY); a given data structure may hold an IP address or a HIT > depending on the context. I understand the appeal for doing it this way > because it involves the least change to the current sockets API, but I > think it will lead to semantic difficulties later. I would rather that > we consider the design that addresses are in address data structures and > HITs are in HIT data structures and not to mix these. I don't like this either, but HIP folks wanted to see HITs in the data structures instead of endpoint descriptors. Notice how the HIP_ADDR_ANY resembles that concept? Anyway, I requested comments earlier on this list whether HIP folks want to see just HITs in sockaddr_hip structure, or both HITs and locators. The feedback was that people wanted only HITs. I think this was a reasonable call for four reasons. First, the locators in sockaddr_hip structure can get depracated quite soon in mobile environments and it is easier for the application (developer) to misuse them. Second, sockaddr structures have size limits and can hold only a number of locators. Third, when the resolver resolves multiple HITs, it does not make sense to have the locators spread redundantly in multiple socket address structures. Fourth, I think the current version of the draft is more compatible with the multihoming draft this way. This design choice had a consequence on the opportunistic mode. Namely, I had to introduce the HIP_ADDR_ANY concept because there is no locator structure in sockaddr_hip. I don't like it either, but that is rough consensus ;) > The current draft covers a lot of ground; not only is the basic API > (partially) covered but also resolver interactions and now (in the > latest version) source HIT selection policy. My preference would be to > focus first on the basic raw API and then move to the other points. I > would like to suggest the following steps. I was working on the assumption that you were concurring with Andrew on the source HIT selection policy because you repeated his request on your comments: http://www1.ietf.org/mail-archive/web/hipsec/current/msg02323.html Hence, I included the source HIT selection policy to the API. > 1) try to write a draft that has no DNS/DHT dependency whatsoever. The > starting assumption is that the application holds zero or more HITs and > zero or more locators for the host it is trying to communicate with, and > possibly additional information such as rendezvous server information. > In other words, the draft picks up at the point after any DNS or DHT > resolutions have occurred. See Section 4.5. Manual Handling of Locators. Is the name of the section somehow misleading? I have already given my statement that the defails of locator handling is specified in multihoming API. I believe that I have added enough references from the native API draft to the multihoming draft. Further, it does not make sense to me to specify the same thing multiple times. > 2) write down the various use cases of interest, and how the system > should respond from an application's perspective for each of them. For > instance, what if the destination HIT field is wildcarded but there are > locators (opportunistic mode). > > What if both destination HIT fields and address fields are wildcarded > (illegal). Right, should result in EDESTADDRREQ. > What should the system do if the locators field is empty and it doesn't > have the binding? For instance, what error should be conveyed to the > application if a HIT but no locators are provided, and the system cannot > resolve the locator? Agree that this should be added to the draft and should result in EDESTADDRREQ error. > How does this differ from the case when the locator is resolved but the > host at that address denies ownership of that HIT? Section 4.5: The function returns EINVALIDLOCATOR when the HIT is not reachable at the specified locator. > Note that the case where the intelligent resolver caches address/locator > bindings (i.e., the current draft) can be a particular use case > elaborated. I belive this is addressed in a minimal way now in section 4.5. > 3) once the WG agrees on the use cases and the policies that are > implicit therein, then adopt/adapt the existing sockets API as needed. > > I would be willing to help work on such revisions, but I'd first like to > hear from the rest of the WG whether they agree with my concerns or > whether the current draft direction is fine with everyone else and I > should just stand down. Tom, it seems like you are suggesting a complete rewrite of both native and multihoming drafts. Lately, we have spend quite many cycles on polishing the two drafts and a complete rewrite would result in a further slip in the chartered schedule. It seems like you are mostly disagreeing about the structuring of draft(s), but there is more than one way to write about things. I think the current draft is split into sections and paragraphs in a reasonably understandable way even though I admit that there is some historical burden and I still have room for improvement as a writer. There seems to be some disagreeing also in the area of the technical approach. I have proposed three different design alternatives and the current approach is based on the consensus on hip-wg. If you want to propose a clean slate approach for the sockets API, the proper place to do it is probably hipsec-rg, apps-area or some research conferences. -- 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 Tue Jan 29 12:31:34 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJuJ4-0005Gp-5R; Tue, 29 Jan 2008 12:31:34 -0500 Received: from hipsec by megatron.ietf.org with local (Exim 4.43) id 1JJuJ3-0005GQ-DA for hipsec-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 12:31:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJuJ2-0005EP-WB for hipsec@ietf.org; Tue, 29 Jan 2008 12:31:33 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJuJ2-0005it-Jf for hipsec@ietf.org; Tue, 29 Jan 2008 12:31:32 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m0THVNI4024040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Jan 2008 09:31:24 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m0THVNMO002917; Tue, 29 Jan 2008 11:31:23 -0600 (CST) 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.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m0THVKdG002852; Tue, 29 Jan 2008 11:31:23 -0600 (CST) 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); Tue, 29 Jan 2008 09:31:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] WGLC: draft-ietf-hip-native-api-03.txt Date: Tue, 29 Jan 2008 09:31:21 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D04049B9E@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] WGLC: draft-ietf-hip-native-api-03.txt Thread-Index: AchiVdGQU4MM7u1QSFq7YoM6ARflbQAPnbSw References: <474DDBFA.1050509@ericsson.com><77F357662F8BFA4CA7074B0410171B6D04049A98@XCH-NW-5V1.nw.nos.boeing.com><77F357662F8BFA4CA7074B0410171B6D04049B89@XCH-NW-5V1.nw.nos.boeing.com> From: "Henderson, Thomas R" To: "Miika Komu" X-OriginalArrivalTime: 29 Jan 2008 17:31:21.0669 (UTC) FILETIME=[C3A28F50:01C8629C] X-Spam-Score: -4.0 (----) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 =20 >=20 > Tom, it seems like you are suggesting a complete rewrite of=20 > both native=20 > and multihoming drafts. Lately, we have spend quite many cycles on=20 > polishing the two drafts and a complete rewrite would result=20 > in a further=20 > slip in the chartered schedule. >=20 > It seems like you are mostly disagreeing about the structuring of=20 > draft(s), but there is more than one way to write about=20 > things. I think=20 > the current draft is split into sections and paragraphs in a=20 > reasonably=20 > understandable way even though I admit that there is some historical=20 > burden and I still have room for improvement as a writer. >=20 > There seems to be some disagreeing also in the area of the technical=20 > approach. I have proposed three different design alternatives and the=20 > current approach is based on the consensus on hip-wg. If you want to=20 > propose a clean slate approach for the sockets API, the=20 > proper place to do=20 > it is probably hipsec-rg, apps-area or some research conferences. >=20 Miika, It would probably be more productive if I just propose some specific text changes at this point. I understand your frustration with my complaints, but IMO it is not critical that we get this API draft finalized quickly (the NAT traversal draft seems to me to be much higher priority). I appreciate that you have been very responsive and proactive to handling suggestions through this process. =20 Regards, Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Thu Jan 31 23:19:34 2008 Return-Path: X-Original-To: ietfarch-hipsec-archive@core3.amsl.com Delivered-To: ietfarch-hipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E89763A684A; Thu, 31 Jan 2008 23:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIz3do5RoLIT; Thu, 31 Jan 2008 23:19:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 525933A683D; Thu, 31 Jan 2008 23:19:33 -0800 (PST) X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F8B13A681E for ; Thu, 31 Jan 2008 23:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMSaGHT-QQ3O for ; Thu, 31 Jan 2008 23:19:30 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id AFDCD3A6811 for ; Thu, 31 Jan 2008 23:19:30 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m117Kn1q025686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 31 Jan 2008 23:20:50 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m117KnXp011017; Thu, 31 Jan 2008 23:20:49 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m117KnNO011012; Thu, 31 Jan 2008 23:20:49 -0800 (PST) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jan 2008 23:20:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 31 Jan 2008 23:20:49 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D04049BC7@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] WGLC: draft-ietf-hip-native-api-03.txt Thread-Index: AchiVdGQU4MM7u1QSFq7YoM6ARflbQCSVneg References: <474DDBFA.1050509@ericsson.com><77F357662F8BFA4CA7074B0410171B6D04049A98@XCH-NW-5V1.nw.nos.boeing.com><77F357662F8BFA4CA7074B0410171B6D04049B89@XCH-NW-5V1.nw.nos.boeing.com> From: "Henderson, Thomas R" To: "Miika Komu" X-OriginalArrivalTime: 01 Feb 2008 07:20:49.0235 (UTC) FILETIME=[F83DFA30:01C864A2] Cc: HIP Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-api-03.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Miika, I owe you some more specific text proposals, but I thought I'd respond to some points inline below. > -----Original Message----- > From: Miika Komu [mailto:miika@iki.fi] > Sent: Tuesday, January 29, 2008 1:03 AM > To: Henderson, Thomas R > Cc: HIP; Gonzalo Camarillo > Subject: RE: [Hipsec] WGLC: draft-ietf-hip-native-api-03.txt > > On Mon, 28 Jan 2008, Henderson, Thomas R wrote: > > Hi Tom, > > > Hi Miika, > > > > Sorry for the latency in responding. Partly this is because I was > > thinking a bit about some of the larger issues with this draft: > > http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-04-pre3.txt > > no problem and thanks for the comments! Some comments below and the > next version based on your technical corrections is here: > > http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-04-pre4.txt > > Tom, please send further comments and technical feedback to > the list ASAP > so that I can post the draft to the official IETF archives. > > >>> In section 4.2 (resolver extensions), the description > implies that a > >>> resolver will have to do two queries (nodename to HITs and > >> nodename to > >>> IP addresses), and concatenate the results in the rres > field, before > >>> returning from getaddrinfo(). Shouldn't the application > >> instead issue > >>> two getaddrinfo's for each of the different queries? > >> > >> Why complicate things unnecessarily for the developer? The > current API > >> is designed so that it can be used in existing apps with minimal > >> changes (i.e. by adding some flags). > > > > This depends perhaps on the perception of what complicates > things for > > the developer. I do not agree that trying to make the > native HIP API > > deviate as little as possible from the address-based API > should be the > > primary goal here. Rather, the main goal should be to have > an API with > > clear semantics, which is somewhat in conflict with > aligning with the > > address-based API because functions and data structures get > overloaded. > > Have you thought about what the application would look like > when it is > going to do two resolver calls and can initiate both HIP and non-HIP > connections? I thought we were going down that path already with the DNS draft (see section 3.2). I think that there may be cases where the application gathers the information it wants through DNS or whatever means directly, and then uses a low-level API, and cases where the application just wants to use HITs alone and not have to worry about RVS and addresses. IMO, we should strive for an API that allows either case, but to me, it is important to get the first one done first. > > > The sockets API is already roundly criticized for its semantic > > ambiguity; I think we should not make things worse if we > can help it. > > Can you be more specific what parts of the sockets API have received > criticism? AFAIK, the main part I've heard of in the apps area is the > resolver part which has not met its promises in the real world. > Also, it was not originally designed with multihoming in mind. Plus, the mixture of stream and datagram semantics. > > I believe you are suggesting here effectively an additional > deployment > obstacle. Even my futile attempt to introduce an additional > abstraction > ("end-point descriptor") to the HIP sockets API extensions > (in draft 02 > version) was shot down by the research, apps area and hip > community. I > have some serious doubts about the future of such an approach. > > I think we need to follow the narrow path of sockets API to > its end for > two reasons. First, to facilititate deployment of HIP-enabled > applications > by introducing minimal changes to the current applications. > Second, to get > experimental-driven feedback on where to improve when > designing better > APIs for the future. Either from the scratch, or as > python/java/c-library/etc middleware on top of the sockets > API (apps-area > folks think that the latter will be the reality). This is getting a > little-bit off topic... Well, if we announce "this is the native HIP API" and then change it a few years later, apps developers will not be happy. That is why I'd prefer to have the raw low-level API done first (which shouldn't have to change in the future) and then start to engineer abstractions and performance improvements-- those should be more experimental. > > > Here are two main issues I have with the current draft: > > > > - it presumes that DNS is the entry point for applications > to use HIP. > > Personally, I suspect that HIP-based applications will more > often than > > not use something else like a DHT, or other things we > haven't thought of > > yet. But the main issue is that this draft delegates > handling of the > > HIT/IP address bindings to an intermediate layer; i.e., it > is kind of a > > higher-level API. This might be a nice eventual goal in > some cases but > > I think that introducing the abstraction immediately (that > applications > > never need to handle locators) might be taking too big of an initial > > step. > > I disagree about the DNS presumptions partially. There is one > section, > 4.5. Manual Handling of Locators, dedicated completely to non-lookup > environments. I agree that the draft has more focus on DNS, > but I believe > think this is acceptable since most of the current > applications rely on > DNS. As I commented previously, it requires reading/using the shim6 draft to really implement the section 4.5, and here it was ambiguous (at least to me) how these options might apply to HIP. For instance: "5.6. SHIM_LOC_PEER_PREF The SHIM_LOC_PEER_PREF option can be used to read or set preferred locator on peer side within a given context. Hence this option is effective only when there is a shim context associated with the socket." Does that apply to HIP? When is there a HIP "shim context" present? I don't think the use of these options is as clear as it could be, especially to people who do not know HIP and shim6. > > Also, now that the draft is more compatible with RFC5014, > there is more > space for e.g. OpenDHT-related resolution flags. > > > - there is a mixture of IP addresses and HITs in some cases > > (HIP_ADDR_ANY); a given data structure may hold an IP > address or a HIT > > depending on the context. I understand the appeal for > doing it this way > > because it involves the least change to the current sockets > API, but I > > think it will lead to semantic difficulties later. I would > rather that > > we consider the design that addresses are in address data > structures and > > HITs are in HIT data structures and not to mix these. > > I don't like this either, but HIP folks wanted to see HITs in > the data > structures instead of endpoint descriptors. Notice how the > HIP_ADDR_ANY > resembles that concept? > > Anyway, I requested comments earlier on this list whether HIP > folks want > to see just HITs in sockaddr_hip structure, or both HITs and > locators. The > feedback was that people wanted only HITs. Yes, I am suggesting that HITs be in sockaddr_hip structures, and IP addresses be elsewhere. >I think this was a > reasonable > call for four reasons. First, the locators in sockaddr_hip > structure can > get depracated quite soon in mobile environments and it is > easier for the > application (developer) to misuse them. Second, sockaddr > structures have > size limits and can hold only a number of locators. Third, when the > resolver resolves multiple HITs, it does not make sense to have the > locators spread redundantly in multiple socket address > structures. Fourth, > I think the current version of the draft is more compatible with the > multihoming draft this way. > > This design choice had a consequence on the opportunistic > mode. Namely, I > had to introduce the HIP_ADDR_ANY concept because there is no locator > structure in sockaddr_hip. I don't like it either, but that is rough > consensus ;) The option is to always allow for a (possibly wildcarded) locator structure. > > > The current draft covers a lot of ground; not only is the basic API > > (partially) covered but also resolver interactions and now (in the > > latest version) source HIT selection policy. My preference > would be to > > focus first on the basic raw API and then move to the other > points. I > > would like to suggest the following steps. > > I was working on the assumption that you were concurring with > Andrew on > the source HIT selection policy because you repeated his > request on your > comments: > > http://www1.ietf.org/mail-archive/web/hipsec/current/msg02323.html > > Hence, I included the source HIT selection policy to the API. Yes, I am just mentioning that you have recently added the equivalent of RFC 3484 and 5014, which makes it cover a lot of ground now. I have not carefully thought about the choices in Table 3, although it occurred to me that key (HI) length is not a criteria in the selection (should it be?). > > > 1) try to write a draft that has no DNS/DHT dependency > whatsoever. The > > starting assumption is that the application holds zero or > more HITs and > > zero or more locators for the host it is trying to > communicate with, and > > possibly additional information such as rendezvous server > information. > > In other words, the draft picks up at the point after any DNS or DHT > > resolutions have occurred. > > See Section 4.5. Manual Handling of Locators. Is the name of > the section > somehow misleading? > > I have already given my statement that the defails of locator > handling is > specified in multihoming API. I believe that I have added enough > references from the native API draft to the multihoming > draft. Further, it > does not make sense to me to specify the same thing multiple times. > > > 2) write down the various use cases of interest, and how the system > > should respond from an application's perspective for each > of them. For > > instance, what if the destination HIT field is wildcarded > but there are > > locators (opportunistic mode). > > > > What if both destination HIT fields and address fields are > wildcarded > > (illegal). > > Right, should result in EDESTADDRREQ. > > > What should the system do if the locators field is empty > and it doesn't > > have the binding? For instance, what error should be > conveyed to the > > application if a HIT but no locators are provided, and the > system cannot > > resolve the locator? > > Agree that this should be added to the draft and should result in > EDESTADDRREQ error. Yes, this is the point that I am trying to make-- we should try to clarify these types of things now. - Tom > > > How does this differ from the case when the locator is > resolved but the > > host at that address denies ownership of that HIT? > > Section 4.5: The function returns EINVALIDLOCATOR when the HIT is not > reachable at the specified locator. > > > Note that the case where the intelligent resolver caches > address/locator > > bindings (i.e., the current draft) can be a particular use case > > elaborated. > > I belive this is addressed in a minimal way now in section 4.5. > > > 3) once the WG agrees on the use cases and the policies that are > > implicit therein, then adopt/adapt the existing sockets API > as needed. > > > > I would be willing to help work on such revisions, but I'd > first like to > > hear from the rest of the WG whether they agree with my concerns or > > whether the current draft direction is fine with everyone else and I > > should just stand down. > > Tom, it seems like you are suggesting a complete rewrite of > both native > and multihoming drafts. Lately, we have spend quite many cycles on > polishing the two drafts and a complete rewrite would result > in a further > slip in the chartered schedule. > > It seems like you are mostly disagreeing about the structuring of > draft(s), but there is more than one way to write about > things. I think > the current draft is split into sections and paragraphs in a > reasonably > understandable way even though I admit that there is some historical > burden and I still have room for improvement as a writer. > > There seems to be some disagreeing also in the area of the technical > approach. I have proposed three different design alternatives and the > current approach is based on the consensus on hip-wg. If you want to > propose a clean slate approach for the sockets API, the > proper place to do > it is probably hipsec-rg, apps-area or some research conferences. > > -- > Miika Komu > http://www.iki.fi/miika/ > _______________________________________________ Hipsec mailing list Hipsec@ietf.org http://www.ietf.org/mailman/listinfo/hipsec