From Erik Nordmark Thu Jul 1 19:19:00 2004 From: Erik Nordmark (Erik Nordmark) Date: Thu Jul 1 18:19:00 2004 Subject: [Hipsec] Recovery from state loss In-Reply-To: "Your message with ID" Message-ID: So here is my attempted approach and a close handshake that can apply to HIP as well as NOID. The goal is to remove the case when one end retains association state and the other end has discarded it, since this seems to open up some DoS opportunity. Comments appreciated. Erik This scheme is robust against arbitrary network partitioning and loss, whether in both directions or one direction, through the use of timers plus a "close" and "closeack" message. The underlying observation is that the network doesn't spontaenously generate packets, thus for a packet to be received it must have been sent by the peer, and if the host does not send a packet no packet will be received by the peer. (But packets might be sent and never received.) In the basic analysis we assume that the network delay (propagation and queuing) is zero that is a packet is received by the peer either immediately when sent, or never (in the case of loss). The mechanism uses a time constant: X minutes. The mechanism works as follows: 1. When no packet has been received on the association for X minutes the association transitions to "closing" state. A "close" message is transmitted to the peer. When in "closing" state the host must not send any data packets using the association. If there is a need to send a data packet a new association must be created by starting by sending an I1. 2. When the host receives a "close" message it discards the association state and responds with a "closeack" message. (The authenticity of the "close" message can be verified the same way data messages are verified.) This processing applies whether or not the state is "closing" in order to handle "close" messages from both ends crossing in flight. Once the association state has been discarded any need to send data packets will trigger establishing a new association, starting with sending an I1. 3. A "close" message which is received when there is no association state can not be verified but will result in a "closeack" response to speed up the peer discarding the state in the precense of packet loss. 4. The "close" message is retransmitted until either a "closeack" message is received, or it has been retransmitted for a total of X minutes. When either occurs the association state is discarded. 5. When a host receives a "closeack" message it verifies that it is in "closing" state and that the "closeack" was in response to the "close" (using e.g. a nonce). It is possible to use stronger verification of the "closeack" based on secrets tied to the association state, but only for the first "close" message since the state is discarded on its reception. Thus if the "closeack" response to the first "close" is lost, the host would need to wait for the full X minutes until discarding its state. Due to packet loss the two sides can have different views of when the last packet might have been sent, but because no received packets in X minutes causes a state transition, this difference can not be larger than X. Since the "close" messages are retransmitted for X minutes (during which the peer can not possibly receive any data packets) the peer will transition to "closing" and stop sending data packets before the host will discard its state. Example 2 shows a case when this happens. Example 1: working communication in both directions Time T: A sends a packet to B. While A doesn't know it yet, this is the last packet A will send using the association. B continues to send packets to A. Time T+X: B has not received any packets from A for X seconds. B marks the association as "closing", that is, it will not use the state to transmit any more. B sends a "close" message to A. Time T+X: A receives a "close" message from A. Discards the association state and responds with a "closeack" message. Time T+X: B receives the "closeack" message and discards the association state. Example 2: Unidirectional failure; A->B packets are all dropped. Time T: A sends a packet to B. While A doesn't know it, this is the last packet B will receive from A. Time T+1 etc: A sends a packet to B which is lost. Time T+X: B has not received any packets from A for X seconds. B marks the association as "closing", that is, it will not use the state to transmit any more. B sends a "close" message to A. Time T+X: A receives a "close" message from A. Discards the association state and responds with a "closeack" message. The "closeack" message is lost. Time T+X+1 etc: B retransmits the "close" message. Time T+X+1 etc: A receives the "close" message, has no association state, and responds with a "closeack" message. The "closeack" message is lost. Time T+2X: B stops retransmitting the "close" message and discards the session state. Example 2: Bidirectional failure; all packets are dropped. Time T1: A sends a packet to B. While A doesn't know it, this is the last packet B will receive from A. Time T2: B sends a packet to A. While B doesn't know it, this is the last packet A will receive from B. Time T1+1 etc: A sends a packet to B which is lost. Time T2+1 etc: B sends a packet to A which is lost. Time T1+X: B has not received any packets from A for X seconds. B marks the association as "closing", that is, it will not use the state to transmit any more. B sends a "close" message to A. The "close" message is lost. Time T2+X: A has not received any packets from B for X seconds. A marks the association as "closing", that is, it will not use the state to transmit any more. A sends a "close" message to B. The "close" message is lost. Time T1+X+1 etc: B retransmits the "close" message, which is lost. Time T2+X+1 etc: A retransmits the "close" message, which is lost. Time T1+2X: B stops retransmitting the "close" message and discards the session state. Time T2+2X: A stops retransmitting the "close" message and discards the session state. Since the difference between T1 and T2 can't be more than X, we know that the session state can not be discarded before the other end has transitioned to "closing". AFAIK the above examples generalize to arbitrary packet loss; in no case will a data packet be received when there is no association state. Hence data packet that are received and have no matching session state can be silently dropped; no need to send an error or an I1. Intuitively it seems like network delays can be handled to make the period for the retransmission of the "close" message be X+MSL (Maximum segment lifetime) instead of X, but I haven't verified this. --- From thomas.r.henderson@boeing.com Sun Jul 4 15:45:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Sun Jul 4 14:45:01 2004 Subject: [Hipsec] Recovery from state loss Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060735@xch-nw-27.nw.nos.boeing.com> Erik, thanks for writing this up. comments and questions inline. > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > Sent: Thursday, July 01, 2004 4:16 PM > To: hipsec@honor.trusecure.com > Cc: erik.nordmark@sun.com > Subject: Re: [Hipsec] Recovery from state loss >=20 >=20 >=20 > So here is my attempted approach and a close handshake that > can apply to HIP as well as NOID. The goal is to remove the case when > one end retains association state and the other end has discarded it, > since this seems to open up some DoS opportunity. >=20 > Comments appreciated. >=20 > Erik >=20 >=20 > This scheme is robust against arbitrary network partitioning and loss, > whether in both directions or one direction, through the use of timers > plus a "close" and "closeack" message. >=20 > The underlying observation is that the network doesn't spontaenously > generate packets, thus for a packet to be received it must have > been sent by the peer, and if the host does not send a packet > no packet will be received by the peer. > (But packets might be sent and never received.) >=20 > In the basic analysis we assume that the network delay > (propagation and queuing) is zero that is a packet > is received by the peer either immediately when sent, or > never (in the case of loss). >=20 > The mechanism uses a time constant: X minutes. >=20 > The mechanism works as follows: > 1. When no packet has been received on the association for X minutes > the association transitions to "closing" state. > A "close" message is transmitted to the peer. I am assuming that you mean "HIP association" by your use of the word association above, since in HIP there is the HIP association (state machine) and then there are individual BEET security associations-- kind of like IKE phase 1/phase 2. If so, then I think you are meaning "when no packet has been received on any of the child SAs of this HIP association for X minutes"? >=20 > When in "closing" state the host must not send any data packets > using the association. If there is a need to send a data packet > a new association must be created by starting by sending an I1. >=20 > 2. When the host receives a "close" message it discards the > association state and responds with a "closeack" message. > (The authenticity of the "close" message can be verified > the same way data messages are verified.) do you mean PK signing of close? (which is not how "data" messages are verified, but how other HIP messages are verified) > This processing applies whether or not the state is "closing" > in order to handle "close" messages from both ends crossing > in flight. >=20 > Once the association state has been discarded any need to > send data packets will trigger establishing a new=20 > association, starting > with sending an I1. >=20 > 3. A "close" message which is received when there is no=20 > association state > can not be verified but will result in a "closeack" response > to speed up the peer discarding the state in the precense of > packet loss. >=20 > 4. The "close" message is retransmitted until either a "closeack" > message is received, or it has been retransmitted for a total of > X minutes. When either occurs the association state is discarded. >=20 > 5. When a host receives a "closeack" message it verifies > that it is in "closing" state and that the "closeack" was in > response to the "close" (using e.g. a nonce). >=20 > It is possible to use stronger verification of the "closeack" > based on secrets tied to the association state, but only > for the first "close" message since the state is discarded > on its reception. Thus if the "closeack" response to the first > "close" is lost, the host would need to wait for the full X minutes > until discarding its state. It might be possible (optional) to cache these closeacks-- maybe something analogous to the "R2_SENT" state that was introduced to allow for retransmission of R2 for a short period of time. Then it is not so much a problem to use elements of previous=20 association state in the closeack-- but could it also be signed in any case? >=20 > Due to packet loss the two sides can have different views > of when the last packet might have been sent, but because no > received packets in X minutes causes a state transition, this > difference can not be larger than X. Since the "close" messages > are retransmitted for X minutes (during which the peer can not > possibly receive any data packets) the peer will transition to > "closing" and stop sending data packets before the host will > discard its state. Example 2 shows a case when this happens. >=20 =20 > Since the difference between T1 and T2 can't be more than X, > we know that the session state can not be discarded > before the other end has transitioned to "closing". >=20 > AFAIK the above examples generalize to arbitrary packet loss; > in no case will a data packet be received when there is no > association state. Hence data packet that are received and have no > matching session state can be silently dropped; no need to send > an error or an I1. I think we still have the reboot scenario even with this (A reboots and loses state, B sends data to A). This mechanism would imply that eventually B would time out, after X minutes. =20 >=20 > Intuitively it seems like network delays can be handled > to make the period for the retransmission of the "close" message > be X+MSL (Maximum segment lifetime) instead of X, but I haven't > verified this. >=20 > --- >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec >=20 From Erik Nordmark Mon Jul 5 06:05:01 2004 From: Erik Nordmark (Erik Nordmark) Date: Mon Jul 5 05:05:01 2004 Subject: [Hipsec] Recovery from state loss In-Reply-To: "Your message with ID" <6938661A6EDA8A4EA8D1419BCE46F24C04060735@xch-nw-27.nw.nos.boeing.com> Message-ID: > I am assuming that you mean "HIP association" by your use of the > word association above, since in HIP there is the HIP association > (state machine) and then there are individual BEET security > associations-- kind of like IKE phase 1/phase 2. I actually wrote it up to make it applicable to other multihoming solutions as well, so I was intentionally vague. > If so, then I think you are meaning "when no packet has been received > on any of the child SAs of this HIP association for X minutes"? Makes sense. > > 2. When the host receives a "close" message it discards the > > association state and responds with a "closeack" message. > > (The authenticity of the "close" message can be verified > > the same way data messages are verified.) > > do you mean PK signing of close? (which is not how "data" messages > are verified, but how other HIP messages are verified) For HIP I think in principle one could take either approach; either PK signed or protected by IPsec. But since we want to be allow retransmitted close messages, e.g. due to the closeack being dropped by the network, to receive a closeack the verification needs to be such that the packet can be processed even after the association state has been deleted. Thus IPsec ESP wouldn't work; IPsec AH would work in pricinple. But PK signing would be expensive. Is there some encrypted set of bits exchange when the HIP association is setup which could be used just to apply a keyed hash on the close message? > It might be possible (optional) to cache these closeacks-- maybe > something analogous to the "R2_SENT" state that was introduced > to allow for retransmission of R2 for a short period of time. > Then it is not so much a problem to use elements of previous > association state in the closeack-- but could it also be signed > in any case? ok > I think we still have the reboot scenario even with this (A reboots > and loses state, B sends data to A). This mechanism would imply > that eventually B would time out, after X minutes. Yes, if a host reboots it would take X minutes for the host to behave as if it hadn't rebooted. Thus a peer which is retransmitting TCP packets would not see the TCP RST until - X minutes has passed since the rebooted host sent the last packet before it rebooted, followed by - A new HIP association is established (triggered by one of the TCP retransmissions) Alternatively, the reboot count could be used to make it possible for the rebooted host to convince the peer that it indeed has lost state, which would make the recovery be faster. Erik From shahrokh.sheik-el-ameh@ericsson.com Mon Jul 5 10:14:01 2004 From: shahrokh.sheik-el-ameh@ericsson.com (Shahrokh Sheik-El-Ameh (AH/TED)) Date: Mon Jul 5 09:14:01 2004 Subject: [Hipsec] IPv6 - IPv6 hand-over Message-ID: Hi, Is there anybody, who has experimented with the mobility / multi-homing feature of HIP, specifically IPv6-IPv6 hand-over, and in case what implementation/prototype has been used? From miika@iki.fi Mon Jul 5 15:01:01 2004 From: miika@iki.fi (Miika Komu) Date: Mon Jul 5 14:01:01 2004 Subject: [Hipsec] IPv6 - IPv6 hand-over In-Reply-To: References: Message-ID: On Mon, 5 Jul 2004, Shahrokh Sheik-El-Ameh (AH/TED) wrote: > Is there anybody, who has experimented with the mobility / multi-homing > feature of HIP, specifically IPv6-IPv6 hand-over, and in case what > implementation/prototype has been used? Ericsson's and Boeing's implementation support IPv6. The same goes for Julien Laganier's and Andrew McGregor's implementation. Our implementation supports only IPv6. AFAIK, the whole implementation from Andrew is public and some part of the Ericsson's implementation is public too. I think Boeing's implementation is not yet public, but I guess they can tell more about it. Our implementation is GNU/GPL and you can find it from http://hipl.hiit.fi/hipl/ -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From thomas.r.henderson@boeing.com Tue Jul 6 11:02:06 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue Jul 6 10:02:06 2004 Subject: [Hipsec] Recovery from state loss Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0452210E@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com]=20 > Sent: Monday, July 05, 2004 2:53 AM > To: Henderson, Thomas R > Cc: Erik Nordmark; hipsec@honor.trusecure.com > Subject: RE: [Hipsec] Recovery from state loss >=20 >=20 >=20 > Is there some encrypted set of bits exchange when the HIP association > is setup which could be used just to apply a keyed hash on=20 > the close message? >=20 There is an HMAC parameter based on keying material derived from the = Diffie Hellman exchange. Tom From Julien.Laganier@Sun.COM Tue Jul 6 11:13:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Tue Jul 6 10:13:01 2004 Subject: [Hipsec] Recovery from state loss In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C0452210E@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0452210E@xch-nw-27.nw.nos.boeing.com> Message-ID: <200407061710.13767.julien.laganier@sun.com> On Tuesday 06 July 2004 16:59, Henderson, Thomas R wrote: > > -----Original Message----- > > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > > Sent: Monday, July 05, 2004 2:53 AM > > To: Henderson, Thomas R > > Subject: RE: [Hipsec] Recovery from state loss > > > > > > > > Is there some encrypted set of bits exchange when the HIP > > association is setup which could be used just to apply a keyed > > hash on the close message? > > There is an HMAC parameter based on keying material derived from > the Diffie Hellman exchange. BTW, having both a HMAC and a SIGNATURE might make sense: The end-node verifies only the HMACs while midboxes verify SIGNATUREs. --julien From thomas.r.henderson@boeing.com Tue Jul 6 11:21:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue Jul 6 10:21:01 2004 Subject: [Hipsec] new preview of mobility mgmt. draft Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060737@xch-nw-27.nw.nos.boeing.com> A new "pre" version of the mobility management draft is at: http://hip.piuha.net/drafts/draft-nikander-hip-mm-02-pre3.txt The plan is to submit this prior to the cutoff, but comments are welcome this week. The main changes are: i) remove the address group identifiers in favor of just=20 directly using SPIs ii) align with the UPDATE exchange defined in the new base spec iii) better definition of the address verification procedure One of the main open issues is the parameter type for REA. This is tied in with middlebox traversal. We could put REA at parameter type 3, which would mean that it precedes everything except SPI and R1_COUNTER. (R1_COUNTER could also be defined down from 2 to 4, since REA might be found in R1). The main messiness IMO, and I don't know how to fix this, is that some UPDATEs may have SPI, some may have both SPI and REA, and some may have just REA (or REA/NES), making it harder in general for middleboxes to parse. This is probably something for which we need to get some=20 experience with before deciding, and redefine if a better way is found. So I would suggest that we set REA to parameter type 3 and consider making R1_COUNTER parameter type 4. Thanks to Mika, Pekka, Jari, and Jonathan for offline comments in developing the above draft revision. Tom From mkousa@cc.hut.fi Wed Jul 7 08:14:03 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Wed Jul 7 07:14:03 2004 Subject: [Hipsec] new preview of mobility mgmt. draft In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060737@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060737@xch-nw-27.nw.nos.boeing.com> Message-ID: About section 5.1 "Mobility with single SA pair" bullet point 1, when the UPDATE does not have a NES parameter, the draft says "the host transitions to a logical READDRESSING state, in which it waits until its UPDATE is acknowledged." What does this "logical READDRESSING state" mean from an implementation point of view ? I did not find any other references what this logical state really means. It is not related to the state machine in any way, right ? If we receive other than the acknowledging UPDATE packets before we receive the acknowledging UPDATE packet, are they just dropped ? From thomas.r.henderson@boeing.com Wed Jul 7 12:39:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Jul 7 11:39:01 2004 Subject: [Hipsec] new preview of mobility mgmt. draft Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0406073E@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Mika Kousa [mailto:mkousa@cc.hut.fi]=20 > Sent: Wednesday, July 07, 2004 5:12 AM > To: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] new preview of mobility mgmt. draft >=20 >=20 > About section 5.1 "Mobility with single SA pair" bullet point=20 > 1, when the > UPDATE does not have a NES parameter, the draft says "the=20 > host transitions > to a logical READDRESSING state, in which it waits until its UPDATE is > acknowledged." >=20 > What does this "logical READDRESSING state" mean from an=20 > implementation > point of view ? I did not find any other references what this logical > state really means. It is not related to the state machine in any way, > right ? It means that the host is waiting for the other side to acknowledge its UPDATE. Whether we consider the substate of "waiting for UPDATE acknowledgement" to be part of ESTABLISHED state or a separate state may be a matter of style. "READDRESSING" might be renamed "UPDATING" if we are just waiting for UPDATE ack-- it may apply to more than=20 READDRESSING. I am not convinced that we need to extend the overall state machine, but we might want to clarify what is meant there-- the host is basically in ESTABLISHED state but it requires an acknowledgment of its UPDATE or it will retransmit it eventually. Presently, we have a REKEYING state. The reason that this is slightly different than the readdressing case or general update case is that a host that is rekeying needs to receive both an ack of its UPDATE and the peer's NES (and optionally, DIFFIE_HELLMAN), since rekeying always occurs for a pair of security associations. Also, to make the protocol simpler, we suppress generating further UPDATEs while in=20 REKEYING. So this amount of departure from ESTABLISHED state seemed to me to justify defining the separate REKEYING state in the state machine. >=20 > If we receive other than the acknowledging UPDATE packets before we > receive the acknowledging UPDATE packet, are they just dropped ? In general, I would say no. Do you have a specific example where you think it should be dropped? Tom From senthil.ayyasamy@gmail.com Wed Jul 7 12:59:01 2004 From: senthil.ayyasamy@gmail.com (Senthil Ayyasamy) Date: Wed Jul 7 11:59:01 2004 Subject: [Hipsec] sigcomm papers Message-ID: of interest to hipsec: 1. A Layered Naming Architecture for the Internet ( introduces two name space) http://nms.lcs.mit.edu/papers/layerednames-sigcomm04.html 2. NUTSS: A SIPbased Approach to UDP and TCP Network Connectivity ( NAT hacks for TCP traversal) http://www.cs.cornell.edu/people/francis/nutss-fdna.pdf 3. Previous work on DHT(chord/pastry/tapestry etc) did not meet the requirements to support DNS-like service due to its its logn performance.) So, a new deployed model; with constant time performance. The Design and Implementation of a Next Generation Name Service for the Internet http://www.cs.cornell.edu/People/egs/beehive/ http://www.cs.cornell.edu/People/egs/papers/codons-sigcomm.pdf From mkousa@cc.hut.fi Thu Jul 8 06:18:01 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Thu Jul 8 05:18:01 2004 Subject: [Hipsec] new preview of mobility mgmt. draft In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C0406073E@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406073E@xch-nw-27.nw.nos.boeing.com> Message-ID: On Wed, 7 Jul 2004, Henderson, Thomas R wrote: -> > -----Original Message----- -> > From: Mika Kousa [mailto:mkousa@cc.hut.fi] -> > Sent: Wednesday, July 07, 2004 5:12 AM -> > To: hipsec@honor.trusecure.com -> > Subject: Re: [Hipsec] new preview of mobility mgmt. draft -> > If we receive other than the acknowledging UPDATE packets before we -> > receive the acknowledging UPDATE packet, are they just dropped ? -> -> In general, I would say no. Do you have a specific example where -> you think it should be dropped? Actually no, at least not yet. I haven't thought about this so much yet. From miika@iki.fi Thu Jul 8 06:43:01 2004 From: miika@iki.fi (Miika Komu) Date: Thu Jul 8 05:43:01 2004 Subject: [Hipsec] native HIP API Message-ID: There were some people interested in the HIP userspace API issues and I promised to get back to the topic later by providing some background information. My master's thesis proposes a new API for HIP aware applications. It is fully not completed yet but you can download a snapshot from the url below: http://hipl.hiit.fi/hipl/hip-native-api-snapshot-20040708.pdf I suggest that we continue the discussion on the hipsec research mailing list although I crossposted this email. Summary: The purpose of the native HIP API is to provide an explicit interface for HIP aware applications. It provides two new features compared to the "legacy HIP API". Applications are given the opportunity to control HIP connection attributes. Applications can also provide their own Host Identities to the host. The native HIP API is based on the BSD sockets API. The sockets API design is extended with two significant changes: a new protocol family (PF_HIP) and a new application identifier (EID). The new family requires a new HIP specific socket handler. The socket handler acts as a EID-to-HI address translator. It also allows setting and querying of HIP specific socket options. The new socket handler isolates the HIP sockets from the IPv4/IPv6 sockets. The Endpoint Identifier Descriptor (EID) is an opaque handle to a HI. It hides the details of the variable length HIs and the associated ephemeral locators. The EID cannot be used as a referral, but there are interfaces for retrieving the HIs and locators corresponding to the EID. The EID is preferred as the AID instead of HIT for a few reasons. It provides forward compatibility with the HIP protocol. If the length of HIT were to change, the changes needed in the userspace would be minimal. The EID concept can also be beneficial for other protocols with the id/locator split. The API provides a new endpoint resolver, which is syntactically similar to the sockets API resolver. Basically, the resolver inputs a hostname and returns the EIDs corresponding to the hostname. The resolver makes the HI-to-locators mapping management transparent to the "typical" applications. However, the API allows the "advanced" applications to configure the mappings manually. The API supports explicit controlling of opportunistic HIP mode. Falling back to plain TCP/IP is also possible if the DNS does not contain the HIs of the peer. I implemented the socket handler into the networking stack, It supports the basic functionality of the API. It acts as a wrapper to IPv6 socket handler and it was not very difficult to implement. I also ported a telnet client and server to use the API with little effort. I writing an IETF draft for API proposal, but first, I would like receive some feedback and open a free discussion on the topic. I have already some specific questions in mind, but feel free to comment on anything. Questions: * Is the EID approach an overkill? It is quite easy to replace the EID with a HIT in the API, if some people prefer HITs as the AID. * Opinions on the PF_HIP family? P.S. I am on a holiday next week and cannot read my email (expect a delay on the replys). -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From mkousa@cc.hut.fi Thu Jul 8 12:42:01 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Thu Jul 8 11:42:01 2004 Subject: [Hipsec] draft-ietf-hip-base-00 submitted In-Reply-To: <40C999E4.2030406@nomadiclab.com> References: <40C999E4.2030406@nomadiclab.com> Message-ID: While updating our implementation to support draft-ietf-hip-base-00 I noticed the following issue: In section 8.11.2 "Processing an UPDATE packet in state REKEYING" there reads "If the packet contains a SEQ and NES parameters, then the system generates a new UPDATE packet with an ACK of the peer's Update ID as received in the SEQ parameter." However, I can't see any more text about this new UPDATE packet whether is to be sent or not. section 8.11.3 does not seem to refer to this packet either. It would be useless to create a new packet if it not used in any way.. So, if understood correctly, when received UPDATE contains both SEQ and NES parameters, we reply to it with the above mentioned new UPDATE packet containing only the ACK parameter (+ HMAC and HIP_SIGNATURE) and nothing else, right ? If yes, then section 8.11.2 needs one more bullet point which tells that "The system sends the UPDATE packet .." Adding similar figures to the UPDATE handling sections as there are in section 4.1 "HIP base exchange" would possibly clarify the understanding of the current UPDATE handling. From Gonzalo.Camarillo@ericsson.com Thu Jul 8 13:15:01 2004 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Thu Jul 8 12:15:01 2004 Subject: [Hipsec] Agenda requests Message-ID: <40ED8090.90508@ericsson.com> Folks, we are officially starting to gather agenda requests for San Diego. In principle, we will be getting a 1 and 1/2 hour slot. Send your agenda request to the chairs. Thanks, Gonzalo HIP co-chair From Jan.Melen@nomadiclab.com Fri Jul 9 02:04:01 2004 From: Jan.Melen@nomadiclab.com (Jan Mikael Melen) Date: Fri Jul 9 01:04:01 2004 Subject: [Hipsec] draft-ietf-hip-base-00 submitted In-Reply-To: References: <40C999E4.2030406@nomadiclab.com> Message-ID: <200407090902.00703.Jan.Melen@nomadiclab.com> On Thursday 08 July 2004 19:39, Mika Kousa wrote: > So, if understood correctly, when received UPDATE contains both SEQ and > NES parameters, we reply to it with the above mentioned new UPDATE packet > containing only the ACK parameter (+ HMAC and HIP_SIGNATURE) and nothing > else, right ? If yes, then section 8.11.2 needs one more bullet point > which tells that "The system sends the UPDATE packet .." If I have understood it correctly one can include SEQ, NES of it's own to this ACK packet and then the other end sends ACK back after which the rekeying state is changed to established. So you have to two ways to complete the rekeying: ---------- SEQ, NES --------> <----- SEQ, NES, ACK ---- ---------------- ACK -----------> Or: ---------- SEQ, NES --------> <-------------- ACK ------------- <----- SEQ, NES ------------- ---------------- ACK -----------> Regards, Jan From mkousa@cc.hut.fi Fri Jul 9 06:29:01 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Fri Jul 9 05:29:01 2004 Subject: [Hipsec] draft-ietf-hip-base-00 submitted In-Reply-To: <200407090902.00703.Jan.Melen@nomadiclab.com> References: <40C999E4.2030406@nomadiclab.com> <200407090902.00703.Jan.Melen@nomadiclab.com> Message-ID: On Fri, 9 Jul 2004, Jan Mikael Melen wrote: -> On Thursday 08 July 2004 19:39, Mika Kousa wrote: -> > So, if understood correctly, when received UPDATE contains both SEQ and -> > NES parameters, we reply to it with the above mentioned new UPDATE packet -> > containing only the ACK parameter (+ HMAC and HIP_SIGNATURE) and nothing -> > else, right ? If yes, then section 8.11.2 needs one more bullet point -> > which tells that "The system sends the UPDATE packet .." -> -> If I have understood it correctly one can include SEQ, NES of it's own to this -> ACK packet and then the other end sends ACK back after which the rekeying -> state is changed to established. -> -> So you have to two ways to complete the rekeying: -> ---------- SEQ, NES --------> -> <----- SEQ, NES, ACK ---- -> ---------------- ACK -----------> -> -> Or: -> ---------- SEQ, NES --------> -> <-------------- ACK ------------- -> <----- SEQ, NES ------------- -> ---------------- ACK -----------> Yes, I was also thinking that it should be done this way. But anyway, I would still like to see third bullet point added to the section 8.11.2 as I mentioned. Just for clarity. From Julien.Laganier@Sun.COM Fri Jul 9 08:06:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Fri Jul 9 07:06:01 2004 Subject: [Hipsec] Agenda requests In-Reply-To: <40ED8090.90508@ericsson.com> References: <40ED8090.90508@ericsson.com> Message-ID: <200407091404.07367.julien.laganier@sun.com> On Thursday 08 July 2004 19:12, Gonzalo Camarillo wrote: > Folks, > > we are officially starting to gather agenda requests for San Diego. > In principle, we will be getting a 1 and 1/2 hour slot. Send your > agenda request to the chairs. Hi, I'd like to request for two slots at San Diego to present: o HIP DNS extensions (draft-nikander-hip-dns-00.txt) - 5 min o HIP RVS extensions (draft-eggert-hip-rvs-00.txt) - 10/15 min Thanks, --julien From thomas.r.henderson@boeing.com Fri Jul 9 12:23:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Fri Jul 9 11:23:01 2004 Subject: [Hipsec] draft-ietf-hip-base-00 submitted Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0406074C@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Mika Kousa [mailto:mkousa@cc.hut.fi]=20 > Sent: Friday, July 09, 2004 3:27 AM > To: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] draft-ietf-hip-base-00 submitted >=20 >=20 > On Fri, 9 Jul 2004, Jan Mikael Melen wrote: >=20 > -> On Thursday 08 July 2004 19:39, Mika Kousa wrote: > -> > So, if understood correctly, when received UPDATE=20 > contains both SEQ and > -> > NES parameters, we reply to it with the above mentioned=20 > new UPDATE packet > -> > containing only the ACK parameter (+ HMAC and=20 > HIP_SIGNATURE) and nothing > -> > else, right ? If yes, then section 8.11.2 needs one more=20 > bullet point > -> > which tells that "The system sends the UPDATE packet .." If we changed "generates" to "sends", will that clarify it? > -> > -> If I have understood it correctly one can include SEQ, NES=20 > of it's own to this > -> ACK packet and then the other end sends ACK back after=20 > which the rekeying > -> state is changed to established. > -> > -> So you have to two ways to complete the rekeying: > -> ---------- SEQ, NES --------> > -> <----- SEQ, NES, ACK ---- > -> ---------------- ACK -----------> > -> > -> Or: > -> ---------- SEQ, NES --------> > -> <-------------- ACK ------------- > -> <----- SEQ, NES ------------- > -> ---------------- ACK -----------> >=20 > Yes, I was also thinking that it should be done this way. Yes, both above options are valid. If we are in REKEYING, this corresponds to being on the left side of the above figures. Point 1 in 8.11.2 handles the first figure above, and point 2 handles the second figure above. >=20 > But anyway, I would still like to see third bullet point added to the > section 8.11.2 as I mentioned. Just for clarity. Will the proposed word change mentioned above be sufficient? From mkousa@cc.hut.fi Fri Jul 9 13:14:00 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Fri Jul 9 12:14:00 2004 Subject: [Hipsec] draft-ietf-hip-base-00 submitted In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C0406074C@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406074C@xch-nw-27.nw.nos.boeing.com> Message-ID: On Fri, 9 Jul 2004, Henderson, Thomas R wrote: -> > -----Original Message----- -> > From: Mika Kousa [mailto:mkousa@cc.hut.fi] -> > Sent: Friday, July 09, 2004 3:27 AM -> > To: hipsec@honor.trusecure.com -> > Subject: Re: [Hipsec] draft-ietf-hip-base-00 submitted -> > -> > -> > On Fri, 9 Jul 2004, Jan Mikael Melen wrote: -> > -> > -> On Thursday 08 July 2004 19:39, Mika Kousa wrote: -> > -> > So, if understood correctly, when received UPDATE -> > contains both SEQ and -> > -> > NES parameters, we reply to it with the above mentioned -> > new UPDATE packet -> > -> > containing only the ACK parameter (+ HMAC and -> > HIP_SIGNATURE) and nothing -> > -> > else, right ? If yes, then section 8.11.2 needs one more -> > bullet point -> > -> > which tells that "The system sends the UPDATE packet .." -> -> If we changed "generates" to "sends", will that clarify it? That is much better. -> > But anyway, I would still like to see third bullet point added to the -> > section 8.11.2 as I mentioned. Just for clarity. -> -> Will the proposed word change mentioned above be sufficient? I think it is just ok. From thomas.r.henderson@boeing.com Sat Jul 10 15:42:00 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Sat Jul 10 14:42:00 2004 Subject: [Hipsec] (not) using HITs as an application identifier Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060750@xch-nw-27.nw.nos.boeing.com> One objection that has been raised to HIP in the multi6 context is that it uses HITs as so-called "application IDs"-- i.e., the 128-bit quantity passed to applications. We have debated before the merits of passing HITs off as IP addresses to applications, but it is clear that such a practice will break applications that pass HITs around to other applications (the "referral" problem), especially non HIP-aware hosts and apps. Another potential problem is if/when the implementation loses (garbage collects?) the context between HITs and IP addresses, and then receives a HIT via socket API-- there is no way (presently) to do a reverse lookup to get the address. I am offering up for discussion the proposal that we use routable IP addresses as application IDs (AIDs) instead of HITs. =20 This means that HIP would use IP addresses (namely, the addresses used in the base exchange) as constant, non-changing addresses in the pseudoheader, and HITs would, in principle, only be exposed=20 to HIP-aware applications. This would solve the referral problem and also the lost context problem if DNS records are present--=20 a host could do a reverse lookup on IP address and then do a forward=20 lookup to get the HIP records. HITs would still be used in the base=20 exchange and for HIP-aware applications and APIs. Besides solving the referral problem, routable AIDs could have a second potential benefit: flexibility. Specifically, now in=20 HIP, it is required to perform a context establishment handshake before the first transport packets are received, since each host needs to know the HITs that it is dealing with (e.g., for checksum computation). If AIDs were routable, it opens the door for some options in establishing HIP state. One example would be the opportunistic use of HIP *after* the transport session had started, and without IPsec. That is, a session could start up by using normal communications, then transition to HIP and do a base exchange if it decided to go mobile. Pekka has previously suggested a "Lightweight HIP" that runs without IPsec, but=20 by using routable AIDs, we might also be able to defer the=20 HIP handshake altogether or use it selectively. In addition, it might be possible to retain some (weaker) crypto properties of these AIDs by allowing the low-order bits of the HIT to be used as the interface ID in the IPv6 address, in the spirit of Erik Nordmark's CB64 proposal in the multi6 group. The main change in our existing implementations would be to specify that the initial IP addresses are used for the transport checksum, instead of HITs, and that a transport session keeps using these same initial addresses in the checksum regardless of whether the=20 addresses change. (logically, the HIP layer would map the current addresses in use back to the initial addresses before handing off to transport). I don't think that such a change would break any=20 existing HIP features. Comments? Tom From marcelo@it.uc3m.es Sun Jul 11 10:40:01 2004 From: marcelo@it.uc3m.es (marcelo bagnulo braun) Date: Sun Jul 11 09:40:01 2004 Subject: [Hipsec] (not) using HITs as an application identifier In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060750@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060750@xch-nw-27.nw.nos.boeing.com> Message-ID: Hi Tom, El 10/07/2004, a las 21:39, Henderson, Thomas R escribi=F3: > One objection that has been raised to HIP in the multi6 context is > that it uses HITs as so-called "application IDs"-- i.e., the 128-bit > quantity passed to applications. We have debated before the merits > of passing HITs off as IP addresses to applications, but it is clear > that such a practice will break applications that pass HITs around > to other applications (the "referral" problem), especially non > HIP-aware hosts and apps. Another potential problem is if/when > the implementation loses (garbage collects?) the context between HITs > and IP addresses, and then receives a HIT via socket API-- there is > no way (presently) to do a reverse lookup to get the address. > > I am offering up for discussion the proposal that we use > routable IP addresses as application IDs (AIDs) instead of HITs. > This means that HIP would use IP addresses (namely, the addresses > used in the base exchange) as constant, non-changing addresses > in the pseudoheader, but wouldn't this expose to time shifted attacks? I mean the ownership of the AID would only be proven by the return=20 routability capabilities of the initial exchange. I mean, if you use the HIT as an AID, the identifier ownership is=20 proven by the crypto features of the HIt, however, if you use the=20 initial address as AID, the ownership of the AID cannot be proven using=20= the crypto capabilties of the HIT, since there is no secure binding=20 between the HIT and the AID, AFAICS. > and HITs would, in principle, only be exposed > to HIP-aware applications. HIP aware apps would still need to be able to obtain locator=20 information from the HIT, how can they do that? I mean, i don't see how using HIT for refferals would work even in the=20= case of HIP aware applications. > This would solve the referral problem > and also the lost context problem if DNS records are present-- > a host could do a reverse lookup on IP address and then do a forward > lookup to get the HIP records. HITs would still be used in the base > exchange and for HIP-aware applications and APIs. > > Besides solving the referral problem, routable AIDs could have a > second potential benefit: flexibility. Specifically, now in > HIP, it is required to perform a context establishment handshake > before the first transport packets are received, since each host > needs to know the HITs that it is dealing with (e.g., for checksum > computation). If AIDs were routable, it opens the door for > some options in establishing HIP state. One example would be > the opportunistic use of HIP *after* the transport session had > started, and without IPsec. That is, a session could start up > by using normal communications, then transition to HIP and do > a base exchange if it decided to go mobile. Pekka has previously > suggested a "Lightweight HIP" that runs without IPsec, but > by using routable AIDs, we might also be able to defer the > HIP handshake altogether or use it selectively. > > In addition, it might be possible to retain some (weaker) crypto > properties of these AIDs by allowing the low-order bits of > the HIT to be used as the interface ID in the IPv6 address, in > the spirit of Erik Nordmark's CB64 proposal in the multi6 group. > i think this approach would provide the ownership proof of the AID that=20= it is required, if it is considered strong enough (crypto speaking) regards, marcelo > The main change in our existing implementations would be to specify > that the initial IP addresses are used for the transport checksum, > instead of HITs, and that a transport session keeps using these > same initial addresses in the checksum regardless of whether the > addresses change. (logically, the HIP layer would map the current > addresses in use back to the initial addresses before handing off > to transport). I don't think that such a change would break any > existing HIP features. > Comments? > > Tom > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > From thomas.r.henderson@boeing.com Sun Jul 11 18:49:00 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Sun Jul 11 17:49:00 2004 Subject: [Hipsec] (not) using HITs as an application identifier Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060751@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > Sent: Sunday, July 11, 2004 7:30 AM > To: Henderson, Thomas R > Cc: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] (not) using HITs as an application identifier >=20 >=20 > Hi Tom, >=20 > El 10/07/2004, a las 21:39, Henderson, Thomas R escribi=F3: >=20 > > One objection that has been raised to HIP in the multi6 context is > > that it uses HITs as so-called "application IDs"-- i.e., the 128-bit > > quantity passed to applications. We have debated before the merits > > of passing HITs off as IP addresses to applications, but it is clear > > that such a practice will break applications that pass HITs around > > to other applications (the "referral" problem), especially non > > HIP-aware hosts and apps. Another potential problem is if/when > > the implementation loses (garbage collects?) the context=20 > between HITs > > and IP addresses, and then receives a HIT via socket API-- there is > > no way (presently) to do a reverse lookup to get the address. > > > > I am offering up for discussion the proposal that we use > > routable IP addresses as application IDs (AIDs) instead of HITs. > > This means that HIP would use IP addresses (namely, the addresses > > used in the base exchange) as constant, non-changing addresses > > in the pseudoheader, >=20 > but wouldn't this expose to time shifted attacks? > I mean the ownership of the AID would only be proven by the return=20 > routability capabilities of the initial exchange. If AID has no crypto properties, yes. If AID has some crypto = properties, it might be a bit stronger than return routability. But just in case this wasn't clear, I am suggesting that the minimal AID is the routable IP address (which may or may not have part of the=20 HIT embedded in it), but in the long run, applications may handle HITs, addresses, (and maybe even HIs), and the original HIP properties are not lost. In some sense, I'm suggesting that the IP address again be used as a = name for the host, for the deployment benefit of those stacks and = applications that are not equipped to handle HIP. On the surface, this seems to take = us back to the same problems that we want HIP to solve. But consider that: i) until a reverse mapping from HIT to IP address is available,=20 HITs will be a pain for both applications and stacks to deal with, ii) a HIP-aware app can provide the system with a HIT plus an address=20 and get all of the benefits of HIP iii) eventually, if a HIT reverse lookup service is available, apps can start dealing only with HITs iv) with parts of the HIT as the identifier ID in the address, maybe some crypto strength even is retained for non-HIP-aware apps >=20 > I mean, if you use the HIT as an AID, the identifier ownership is=20 > proven by the crypto features of the HIt, however, if you use the=20 > initial address as AID, the ownership of the AID cannot be=20 > proven using=20 > the crypto capabilties of the HIT, since there is no secure binding=20 > between the HIT and the AID, AFAICS. >=20 > > and HITs would, in principle, only be exposed > > to HIP-aware applications. >=20 > HIP aware apps would still need to be able to obtain locator=20 > information from the HIT, how can they do that? >=20 > I mean, i don't see how using HIT for refferals would work=20 > even in the=20 > case of HIP aware applications. >=20 It would work in either of two cases: - reverse lookup service for HITs is available - HIT + FQDN is passed as a referral (or HIT + address, with the reverse DNS tree populated) > > This would solve the referral problem > > and also the lost context problem if DNS records are present-- > > a host could do a reverse lookup on IP address and then do a forward > > lookup to get the HIP records. HITs would still be used in the base > > exchange and for HIP-aware applications and APIs. > > > > Besides solving the referral problem, routable AIDs could have a > > second potential benefit: flexibility. Specifically, now in > > HIP, it is required to perform a context establishment handshake > > before the first transport packets are received, since each host > > needs to know the HITs that it is dealing with (e.g., for checksum > > computation). If AIDs were routable, it opens the door for > > some options in establishing HIP state. One example would be > > the opportunistic use of HIP *after* the transport session had > > started, and without IPsec. That is, a session could start up > > by using normal communications, then transition to HIP and do > > a base exchange if it decided to go mobile. Pekka has previously > > suggested a "Lightweight HIP" that runs without IPsec, but > > by using routable AIDs, we might also be able to defer the > > HIP handshake altogether or use it selectively. > > > > In addition, it might be possible to retain some (weaker) crypto > > properties of these AIDs by allowing the low-order bits of > > the HIT to be used as the interface ID in the IPv6 address, in > > the spirit of Erik Nordmark's CB64 proposal in the multi6 group. > > >=20 > i think this approach would provide the ownership proof of=20 > the AID that=20 > it is required, if it is considered strong enough (crypto speaking) >=20 I think that in many cases it would, but several people have objected to the crypto strength of 64 or 48 bits, so in the long run, it=20 would be good to back this up with (or provide transition path to) the stronger 128 bits of a HIT. =20 Tom From marcelo@it.uc3m.es Mon Jul 12 06:50:01 2004 From: marcelo@it.uc3m.es (marcelo bagnulo braun) Date: Mon Jul 12 05:50:01 2004 Subject: [Hipsec] (not) using HITs as an application identifier In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060751@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060751@xch-nw-27.nw.nos.boeing.com> Message-ID: <1BE3F4AC-D3F1-11D8-A131-000D93ACD0FE@it.uc3m.es> > > > If AID has no crypto properties, yes. If AID has some crypto > properties, > it might be a bit stronger than return routability. > imho, return routability is not good enough, not even for a transition mechanism. The minimum required imho would be the second option where some part of the AID contains is crypto based, as in cgas for the rest, i agree with your proposal regards, marcelo > But just in case this wasn't clear, I am suggesting that the minimal > AID > is the routable IP address (which may or may not have part of the > HIT embedded in it), but in the long run, applications may handle > HITs, addresses, (and maybe even HIs), and the original HIP properties > are not lost. > > In some sense, I'm suggesting that the IP address again be used as a > name > for the host, for the deployment benefit of those stacks and > applications > that are not equipped to handle HIP. On the surface, this seems to > take > us back to the same problems that we want HIP to solve. But consider > that: > i) until a reverse mapping from HIT to IP address is available, > HITs will be a pain for both applications and stacks to deal with, > ii) a HIP-aware app can provide the system with a HIT plus an address > and get all of the benefits of HIP > iii) eventually, if a HIT reverse lookup service is available, apps > can start dealing only with HITs > iv) with parts of the HIT as the identifier ID in the address, > maybe some crypto strength even is retained for non-HIP-aware apps > >> >> I mean, if you use the HIT as an AID, the identifier ownership is >> proven by the crypto features of the HIt, however, if you use the >> initial address as AID, the ownership of the AID cannot be >> proven using >> the crypto capabilties of the HIT, since there is no secure binding >> between the HIT and the AID, AFAICS. >> >>> and HITs would, in principle, only be exposed >>> to HIP-aware applications. >> >> HIP aware apps would still need to be able to obtain locator >> information from the HIT, how can they do that? >> >> I mean, i don't see how using HIT for refferals would work >> even in the >> case of HIP aware applications. >> > > It would work in either of two cases: > - reverse lookup service for HITs is available > - HIT + FQDN is passed as a referral (or HIT + address, with the > reverse DNS tree populated) > >>> This would solve the referral problem >>> and also the lost context problem if DNS records are present-- >>> a host could do a reverse lookup on IP address and then do a forward >>> lookup to get the HIP records. HITs would still be used in the base >>> exchange and for HIP-aware applications and APIs. >>> >>> Besides solving the referral problem, routable AIDs could have a >>> second potential benefit: flexibility. Specifically, now in >>> HIP, it is required to perform a context establishment handshake >>> before the first transport packets are received, since each host >>> needs to know the HITs that it is dealing with (e.g., for checksum >>> computation). If AIDs were routable, it opens the door for >>> some options in establishing HIP state. One example would be >>> the opportunistic use of HIP *after* the transport session had >>> started, and without IPsec. That is, a session could start up >>> by using normal communications, then transition to HIP and do >>> a base exchange if it decided to go mobile. Pekka has previously >>> suggested a "Lightweight HIP" that runs without IPsec, but >>> by using routable AIDs, we might also be able to defer the >>> HIP handshake altogether or use it selectively. >>> >>> In addition, it might be possible to retain some (weaker) crypto >>> properties of these AIDs by allowing the low-order bits of >>> the HIT to be used as the interface ID in the IPv6 address, in >>> the spirit of Erik Nordmark's CB64 proposal in the multi6 group. >>> >> >> i think this approach would provide the ownership proof of >> the AID that >> it is required, if it is considered strong enough (crypto speaking) >> > > I think that in many cases it would, but several people have objected > to the crypto strength of 64 or 48 bits, so in the long run, it > would be good to back this up with (or provide transition path to) > the stronger 128 bits of a HIT. > > Tom > From thomas.r.henderson@boeing.com Mon Jul 12 14:30:03 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Mon Jul 12 13:30:03 2004 Subject: [Hipsec] Agenda requests for HIP RG meeting in San Diego Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060755@xch-nw-27.nw.nos.boeing.com> (cross-posted to HIP WG list) The HIP IRTF RG plans to meet in San Diego. We haven't yet heard back from the IETF on a time slot, but I will announce it when the agenda is eventually updated. Please send any proposed agenda items to me and Pekka. Thanks, Tom From Julien.Laganier@Sun.COM Tue Jul 13 05:24:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Tue Jul 13 04:24:01 2004 Subject: [Hipsec] RVS and DNS drafts Message-ID: <200407131122.28252.julien.laganier@sun.com> Hi, The drafts about DNS and RVS extensions for HIP were submitted on Friday, but we had some problems with IPR and boilerplates :( In the meantime they are available at the following URLs: Thanks, --julien From Julien.Laganier@Sun.COM Tue Jul 13 13:53:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Tue Jul 13 12:53:01 2004 Subject: [Hipsec] (not) using HITs as an application identifier In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060750@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060750@xch-nw-27.nw.nos.boeing.com> Message-ID: <200407131951.00478.julien.laganier@sun.com> On Saturday 10 July 2004 21:39, Henderson, Thomas R wrote: > One objection that has been raised to HIP in the multi6 context is > that it uses HITs as so-called "application IDs"-- i.e., the > 128-bit quantity passed to applications. We have debated before > the merits of passing HITs off as IP addresses to applications, but > it is clear that such a practice will break applications that pass > HITs around to other applications (the "referral" problem), > especially non HIP-aware hosts and apps. > Another potential problem > is if/when the implementation loses (garbage collects?) the context > between HITs and IP addresses, and then receives a HIT via socket > API-- there is no way (presently) to do a reverse lookup to get the > address. I can't see how the socket API would return a HIT to an application if the implementation loses context between HITs and IPs. AFAICS, the socket API would return HIT if and only if the HIP layer: o Maintained a context containing the (to be) returned HIT o Performed a DNS lookup on a FQDN, hence establishing an IP <-> HIT mapping. > I am offering up for discussion the proposal that we use > routable IP addresses as application IDs (AIDs) instead of HITs. > This means that HIP would use IP addresses (namely, the addresses > used in the base exchange) as constant, non-changing addresses > in the pseudoheader, and HITs would, in principle, only be exposed > to HIP-aware applications. This would solve the referral problem > and also the lost context problem if DNS records are present-- > a host could do a reverse lookup on IP address and then do a > forward lookup to get the HIP records. HITs would still be used in > the base exchange and for HIP-aware applications and APIs. In this case the application needs to be aware of HIP because it needs to perform a reverse + forward lookup on the IP address. Hence, I'd rather use a Type 2 HIT in this case, and perform a reverse lookup on Type 2 HIT. Also, I fail to see why such applications need _routable_ AIDs. In the scenario you describe above, the application just needs "lookupable" AIDs. One solution for this kind of application would be for the HIP stack to provide a tuning parameter allowing to run such applications with lookupable/routable AIDs (i.e., either IP addresses, or Type 2 HITs). This would retain the HIT-as-AID property for non-referral apps. > Besides solving the referral problem, routable AIDs could have a > second potential benefit: flexibility. Specifically, now in > HIP, it is required to perform a context establishment handshake > before the first transport packets are received, since each host > needs to know the HITs that it is dealing with (e.g., for checksum > computation). If AIDs were routable, it opens the door for > some options in establishing HIP state. One example would be > the opportunistic use of HIP *after* the transport session had > started, and without IPsec. That is, a session could start up > by using normal communications, then transition to HIP and do > a base exchange if it decided to go mobile. Pekka has previously > suggested a "Lightweight HIP" that runs without IPsec, but > by using routable AIDs, we might also be able to defer the > HIP handshake altogether or use it selectively. I don't see why using HITs as AIDs prevents us from establishing a HIP association after the transport session has started, nor why it mandates the use of IPsec. Once your transport session is established with IP addresses as AIDs, nothing prevents you from running an opportunistic HIP exchange afterward. This kind of session will be bound to IP addresses instead of HITs, but we do not need to require such a constraint for all applications. > In addition, it might be possible to retain some (weaker) crypto > properties of these AIDs by allowing the low-order bits of > the HIT to be used as the interface ID in the IPv6 address, in > the spirit of Erik Nordmark's CB64 proposal in the multi6 group. This seems really similar to both CGAs and Type 2 HITs. My understanding is that CGA is IPR-encumbered so we should try to avoid it. I dunno if Type 2 are IPR-free, because (at least to me) they seems very similar to CGAs in their properties (e.g., both aggregatable and provable identifiers). > The main change in our existing implementations would be to specify > that the initial IP addresses are used for the transport checksum, > instead of HITs, and that a transport session keeps using these > same initial addresses in the checksum regardless of whether the > addresses change. (logically, the HIP layer would map the current > addresses in use back to the initial addresses before handing off > to transport). I don't think that such a change would break any > existing HIP features. > > Comments? My (very personal) feeling is is that using HITs as AIDs is one of the stronger pros of using HIP, so I am in favor of keeping the current specification. HITs can be either lookupable, private, long-termed, short-termed, randomly assigned, authority assigned, etc... They are multi-purposes identifiers, as opposed to IP addresses which doesn't have all these nice properties, apart from being routable. Beside that, what do others HIPpies think? Thanks, --julien From thomas.r.henderson@boeing.com Tue Jul 13 14:25:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue Jul 13 13:25:01 2004 Subject: [Hipsec] (not) using HITs as an application identifier Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060766@xch-nw-27.nw.nos.boeing.com> Julien, thanks for your comments, response inline below: > -----Original Message----- > From: Julien Laganier [mailto:Julien.Laganier@Sun.COM]=20 > Sent: Tuesday, July 13, 2004 10:51 AM > To: hipsec@honor.trusecure.com > Cc: Henderson, Thomas R > Subject: Re: [Hipsec] (not) using HITs as an application identifier >=20 >=20 > On Saturday 10 July 2004 21:39, Henderson, Thomas R wrote: > > One objection that has been raised to HIP in the multi6 context is > > that it uses HITs as so-called "application IDs"-- i.e., the > > 128-bit quantity passed to applications. We have debated before > > the merits of passing HITs off as IP addresses to applications, but > > it is clear that such a practice will break applications that pass > > HITs around to other applications (the "referral" problem), > > especially non HIP-aware hosts and apps. =20 >=20 > > Another potential problem=20 > > is if/when the implementation loses (garbage collects?) the context > > between HITs and IP addresses, and then receives a HIT via socket > > API-- there is no way (presently) to do a reverse lookup to get the > > address. >=20 > I can't see how the socket API would return a HIT to an=20 > application if=20 > the implementation loses context between HITs and IPs.=20 Here is the example I have in mind: long-running application does=20 some DNS query at some time, and caches the result. Kernel eventually garbage collects HIT/IP address bindings that are not used for some=20 time. Then the application eventually provides the HIT again. >=20 > AFAICS, the socket API would return HIT if and only if the HIP layer: > o Maintained a context containing the (to be) returned HIT > o Performed a DNS lookup on a FQDN, hence establishing an IP <-> HIT=20 > mapping. >=20 > > I am offering up for discussion the proposal that we use > > routable IP addresses as application IDs (AIDs) instead of HITs. > > This means that HIP would use IP addresses (namely, the addresses > > used in the base exchange) as constant, non-changing addresses > > in the pseudoheader, and HITs would, in principle, only be exposed > > to HIP-aware applications. This would solve the referral problem > > and also the lost context problem if DNS records are present-- > > a host could do a reverse lookup on IP address and then do a > > forward lookup to get the HIP records. HITs would still be used in > > the base exchange and for HIP-aware applications and APIs. >=20 > In this case the application needs to be aware of HIP because=20 > it needs=20 > to perform a reverse + forward lookup on the IP address.=20 I am not following this point. I am not suggesting that the apps have to do anything other than provide the address that they want to talk to. It is the kernel that would need to do the reverse + forward lookup to get the HITs. >=20 > Hence, I'd rather use a Type 2 HIT in this case, and perform=20 > a reverse=20 > lookup on Type 2 HIT.=20 >=20 > Also, I fail to see why such applications need _routable_=20 > AIDs. In the=20 > scenario you describe above, the application just needs "lookupable"=20 > AIDs.=20 In the referral case, when an non-HIP-aware app gives a HIT to a=20 non-HIP aware host, what does the host do with it? It doesn't know=20 about any HIP lookup service. It puts it into the IP header. >=20 > One solution for this kind of application would be for the HIP stack=20 > to provide a tuning parameter allowing to run such applications with=20 > lookupable/routable AIDs (i.e., either IP addresses, or Type 2 HITs).=20 > This would retain the HIT-as-AID property for non-referral apps. >=20 > > Besides solving the referral problem, routable AIDs could have a > > second potential benefit: flexibility. Specifically, now in > > HIP, it is required to perform a context establishment handshake > > before the first transport packets are received, since each host > > needs to know the HITs that it is dealing with (e.g., for checksum > > computation). If AIDs were routable, it opens the door for > > some options in establishing HIP state. One example would be > > the opportunistic use of HIP *after* the transport session had > > started, and without IPsec. That is, a session could start up > > by using normal communications, then transition to HIP and do > > a base exchange if it decided to go mobile. Pekka has previously > > suggested a "Lightweight HIP" that runs without IPsec, but > > by using routable AIDs, we might also be able to defer the > > HIP handshake altogether or use it selectively. >=20 > I don't see why using HITs as AIDs prevents us from=20 > establishing a HIP=20 > association after the transport session has started, nor why it=20 > mandates the use of IPsec. >=20 > Once your transport session is established with IP addresses as AIDs,=20 > nothing prevents you from running an opportunistic HIP exchange=20 > afterward. This kind of session will be bound to IP addresses instead=20 > of HITs, but we do not need to require such a constraint for all=20 > applications. >=20 I agree that it doesn't mandate use of IPsec-- LHIP proves that. As for establishing a HIP association after transport session, then you have a different kind of session as you discuss above-- one not covered by the present spec. So I think you are agreeing on this point? > > In addition, it might be possible to retain some (weaker) crypto > > properties of these AIDs by allowing the low-order bits of > > the HIT to be used as the interface ID in the IPv6 address, in > > the spirit of Erik Nordmark's CB64 proposal in the multi6 group. >=20 > This seems really similar to both CGAs and Type 2 HITs. My=20 > understanding is that CGA is IPR-encumbered so we should try to avoid=20 > it. I dunno if Type 2 are IPR-free, because (at least to me) they=20 > seems very similar to CGAs in their properties (e.g., both=20 > aggregatable and provable identifiers). >=20 > > The main change in our existing implementations would be to specify > > that the initial IP addresses are used for the transport checksum, > > instead of HITs, and that a transport session keeps using these > > same initial addresses in the checksum regardless of whether the > > addresses change. (logically, the HIP layer would map the current > > addresses in use back to the initial addresses before handing off > > to transport). I don't think that such a change would break any > > existing HIP features. > > > > Comments? >=20 > My (very personal) feeling is is that using HITs as AIDs is=20 > one of the=20 > stronger pros of using HIP, so I am in favor of keeping the current=20 > specification. >=20 > HITs can be either lookupable, private, long-termed, short-termed,=20 > randomly assigned, authority assigned, etc... They are multi-purposes=20 > identifiers, as opposed to IP addresses which doesn't have all these=20 > nice properties, apart from being routable. >=20 > Beside that, what do others HIPpies think? >=20 > Thanks, >=20 > --julien >=20 From marcelo@it.uc3m.es Wed Jul 14 09:33:01 2004 From: marcelo@it.uc3m.es (marcelo bagnulo braun) Date: Wed Jul 14 08:33:01 2004 Subject: [Hipsec] (not) using HITs as an application identifier In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060766@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060766@xch-nw-27.nw.nos.boeing.com> Message-ID: <4056CBA8-D59A-11D8-A131-000D93ACD0FE@it.uc3m.es> >>> I am offering up for discussion the proposal that we use >>> routable IP addresses as application IDs (AIDs) instead of HITs. >>> This means that HIP would use IP addresses (namely, the addresses >>> used in the base exchange) as constant, non-changing addresses >>> in the pseudoheader, and HITs would, in principle, only be exposed >>> to HIP-aware applications. This would solve the referral problem >>> and also the lost context problem if DNS records are present-- >>> a host could do a reverse lookup on IP address and then do a >>> forward lookup to get the HIP records. HITs would still be used in >>> the base exchange and for HIP-aware applications and APIs. >> >> In this case the application needs to be aware of HIP because >> it needs >> to perform a reverse + forward lookup on the IP address. > > I am not following this point. I am not suggesting that the apps > have to do anything other than provide the address that they > want to talk to. It is the kernel that would need to do the > reverse + forward lookup to get the HITs. > Perhaps we need to distinguish hip-aware-host from hip-aware-application here? regards, marcelo From Julien.Laganier@Sun.COM Thu Jul 15 03:16:00 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Thu Jul 15 02:16:00 2004 Subject: [Hipsec] DNS support draft online Message-ID: <200407150914.15218.julien.laganier@sun.com> A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Host Identity Protocol (HIP) Domain Name System (DNS) Extensions Author(s) : P. Nikander, J. Laganier Filename : draft-nikander-hip-dns-00.txt Pages : 22 Date : 2004-7-13 This document specifies two new resource records for the Domain Name System, and how to use them with the Host Identity Protocol. These records allow a HIP node to store in the DNS its Host Identity (i.e., its public key), Host Identity Tag (i.e., a truncated hash of its public key), and Rendezvous Servers (RVS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nikander-hip-dns-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-nikander-hip-dns-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-nikander-hip-dns-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce From Julien.Laganier@Sun.COM Thu Jul 15 03:16:04 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Thu Jul 15 02:16:04 2004 Subject: [Hipsec] HIP RVS extensions draft online Message-ID: <200407150915.01483.julien.laganier@sun.com> A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Host Identity Protocol (HIP) Rendezvous Extensions Author(s) : L. Eggert, J. Laganier Filename : draft-eggert-hip-rvs-00.txt Pages : 33 Date : 2004-7-14 This document discusses rendezvous extensions for the Host Identity Protocol (HIP). Rendezvous mechanisms extend HIP for communication with HIP Rendezvous Servers. Rendezvous Servers improve operation when HIP nodes are multi-homed or mobile. The first part of his document motivates the need for rendezvous mechanisms; the second part describes the protocol extensions in detail. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-eggert-hip-rvs-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-eggert-hip-rvs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-eggert-hip-rvs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce From Julien.Laganier@Sun.COM Thu Jul 15 07:27:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Thu Jul 15 06:27:01 2004 Subject: [Hipsec] Recovery from state loss In-Reply-To: References: Message-ID: <200407151325.14103.julien.laganier@sun.com> On Friday 02 July 2004 01:15, Erik Nordmark wrote: > So here is my attempted approach and a close handshake that > can apply to HIP as well as NOID. The goal is to remove the case > when one end retains association state and the other end has > discarded it, since this seems to open up some DoS opportunity. > > Comments appreciated. Hi Erik, IMHO, this scheme fills a hole in the HIP specification, particularly since we removed the RESYNC-related stuff. Hence, I am strongly in favor of adopting (and adapting) the proposed approach. There's a remaining question, though: Does it belongs to the base protocol spec, or rather to an extension? I would vote for the first but I'm not 100% sure... What do other people think? --julien From Julien.Laganier@Sun.COM Thu Jul 15 09:07:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Thu Jul 15 08:07:01 2004 Subject: [Hipsec] (not) using HITs as an application identifier In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060766@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060766@xch-nw-27.nw.nos.boeing.com> Message-ID: <200407151505.43272.julien.laganier@sun.com> Hi Thomas, Please find my response inlined below: On Tuesday 13 July 2004 20:23, Henderson, Thomas R wrote: > Julien, thanks for your comments, response inline below: > > -----Original Message----- > > From: Julien Laganier [mailto:Julien.Laganier@Sun.COM] > > Sent: Tuesday, July 13, 2004 10:51 AM > > To: hipsec@honor.trusecure.com > > Cc: Henderson, Thomas R > > Subject: Re: [Hipsec] (not) using HITs as an application > > identifier > > > > On Saturday 10 July 2004 21:39, Henderson, Thomas R wrote: > > > One objection that has been raised to HIP in the multi6 context > > > is that it uses HITs as so-called "application IDs"-- i.e., the > > > 128-bit quantity passed to applications. We have debated > > > before the merits of passing HITs off as IP addresses to > > > applications, but it is clear that such a practice will break > > > applications that pass HITs around to other applications (the > > > "referral" problem), especially non HIP-aware hosts and apps. > > > > > > Another potential problem > > > is if/when the implementation loses (garbage collects?) the > > > context between HITs and IP addresses, and then receives a HIT > > > via socket API-- there is no way (presently) to do a reverse > > > lookup to get the address. > > > > I can't see how the socket API would return a HIT to an > > application if > > the implementation loses context between HITs and IPs. > > Here is the example I have in mind: long-running application does > some DNS query at some time, and caches the result. Kernel > eventually garbage collects HIT/IP address bindings that are not > used for some time. Then the application eventually provides the > HIT again. I agree that unless the app cached a lookupable Type 2 HIT this is an issue with the current spec. At best we can hope that having the HIP stack return EHOSTUNREACH will trigger the application to lookup again the corresponding FQDN. This appears to me a bit similar to the case where a host has multiple NICs with multiple IP addresses, which are stored in the DNS. If one of these NICs (or its network of attachment) goes down while a long running application (e.g., email client) has cached only its IP address (the first one for example), the app will have problem until it query again the DNS and retries to connect to each of the addresses in the returned set. > > AFAICS, the socket API would return HIT if and only if the HIP > > layer: o Maintained a context containing the (to be) returned HIT > > o Performed a DNS lookup on a FQDN, hence establishing an IP <-> > > HIT mapping. > > > > > I am offering up for discussion the proposal that we use > > > routable IP addresses as application IDs (AIDs) instead of > > > HITs. This means that HIP would use IP addresses (namely, the > > > addresses used in the base exchange) as constant, non-changing > > > addresses in the pseudoheader, and HITs would, in principle, > > > only be exposed to HIP-aware applications. This would solve > > > the referral problem and also the lost context problem if DNS > > > records are present-- a host could do a reverse lookup on IP > > > address and then do a forward lookup to get the HIP records. > > > HITs would still be used in the base exchange and for HIP-aware > > > applications and APIs. > > > > In this case the application needs to be aware of HIP because > > it needs > > to perform a reverse + forward lookup on the IP address. > > I am not following this point. I am not suggesting that the apps > have to do anything other than provide the address that they > want to talk to. It is the kernel that would need to do the > reverse + forward lookup to get the HITs. Ok now I understand. > > Hence, I'd rather use a Type 2 HIT in this case, and perform > > a reverse > > lookup on Type 2 HIT. > > > > Also, I fail to see why such applications need _routable_ > > AIDs. In the > > scenario you describe above, the application just needs > > "lookupable" AIDs. > > In the referral case, when an non-HIP-aware app gives a HIT to a > non-HIP aware host, what does the host do with it? It doesn't > know about any HIP lookup service. It puts it into the IP header. Ok. I think that we sould have a way to run such applications ( "non-HIP-aware & referral-based") on a "pure IP legacy API", which would expose only IP addresses to applications, the HIT being only used in the HIP protocol itself, as per your proposal. > > One solution for this kind of application would be for the HIP > > stack to provide a tuning parameter allowing to run such > > applications with lookupable/routable AIDs (i.e., either IP > > addresses, or Type 2 HITs). This would retain the HIT-as-AID > > property for non-referral apps. > > > > > Besides solving the referral problem, routable AIDs could have > > > a second potential benefit: flexibility. Specifically, now in > > > HIP, it is required to perform a context establishment > > > handshake before the first transport packets are received, > > > since each host needs to know the HITs that it is dealing with > > > (e.g., for checksum computation). If AIDs were routable, it > > > opens the door for some options in establishing HIP state. One > > > example would be the opportunistic use of HIP *after* the > > > transport session had started, and without IPsec. That is, a > > > session could start up by using normal communications, then > > > transition to HIP and do a base exchange if it decided to go > > > mobile. Pekka has previously suggested a "Lightweight HIP" > > > that runs without IPsec, but by using routable AIDs, we might > > > also be able to defer the HIP handshake altogether or use it > > > selectively. > > > > I don't see why using HITs as AIDs prevents us from > > establishing a HIP > > association after the transport session has started, nor why it > > mandates the use of IPsec. > > > > Once your transport session is established with IP addresses as > > AIDs, nothing prevents you from running an opportunistic HIP > > exchange afterward. This kind of session will be bound to IP > > addresses instead of HITs, but we do not need to require such a > > constraint for all applications. > > I agree that it doesn't mandate use of IPsec-- LHIP proves that. > > As for establishing a HIP association after transport session, then > you have a different kind of session as you discuss above-- one not > covered by the present spec. So I think you are agreeing on this > point? I think we mostly agree. My main disagreement was on the scope of the change. You are proposing a HIP-wide change whereas I propose a referral-application-wide change. While it's true that having a single usage model is simpler, and less error-prone while specifying the protocol, I would really like to retain HITs as AIDs for all the applications which works well with non-routable (and possibly non-lookupable, i.e. Type 1 HIT) AIDs. The rationale behind my support for HIT-as-AID is that: - I am (perhaps wrongly) asumming that this kind of application is the majority of networked applications. - I think it is cleaner (architecturally speaking). - I believe we can craft a support for referral apps (by using IP addresses, or type 2 HIT, as AIDs, as per your proposal). Thanks, --julien From marcelo@it.uc3m.es Thu Jul 15 10:07:00 2004 From: marcelo@it.uc3m.es (marcelo bagnulo braun) Date: Thu Jul 15 09:07:00 2004 Subject: [Hipsec] (not) using HITs as an application identifier In-Reply-To: <200407151505.43272.julien.laganier@sun.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060766@xch-nw-27.nw.nos.boeing.com> <200407151505.43272.julien.laganier@sun.com> Message-ID: <458232CE-D668-11D8-A131-000D93ACD0FE@it.uc3m.es> > > I think we mostly agree. My main disagreement was on the scope of the > change. You are proposing a HIP-wide change whereas I propose a > referral-application-wide change. > But, how do you know if the app is planning to do a refferal or not? I mean, in order to make a refferal application wide change the hip layer need to know which are the apps that will make refferals and which wno't. So how do you recognize the refferal apps, i.e. how does the hip layer knows whether to use refferal capable AID or the regular hits? Regards, marcelo > While it's true that having a single usage model is simpler, and less > error-prone while specifying the protocol, I would really like to > retain HITs as AIDs for all the applications which works well with > non-routable (and possibly non-lookupable, i.e. Type 1 HIT) AIDs. > > The rationale behind my support for HIT-as-AID is that: > - I am (perhaps wrongly) asumming that this kind of application is the > majority of networked applications. > - I think it is cleaner (architecturally speaking). > - I believe we can craft a support for referral apps (by using IP > addresses, or type 2 HIT, as AIDs, as per your proposal). > > Thanks, > > --julien > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > From Julien.Laganier@Sun.COM Thu Jul 15 11:07:00 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Thu Jul 15 10:07:00 2004 Subject: [Hipsec] (not) using HITs as an application identifier In-Reply-To: <458232CE-D668-11D8-A131-000D93ACD0FE@it.uc3m.es> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060766@xch-nw-27.nw.nos.boeing.com> <200407151505.43272.julien.laganier@sun.com> <458232CE-D668-11D8-A131-000D93ACD0FE@it.uc3m.es> Message-ID: <200407151705.33604.julien.laganier@sun.com> Hi Marcelo, On Thursday 15 July 2004 16:07, marcelo bagnulo braun wrote: > > > > I think we mostly agree. My main disagreement was on the scope of > > the change. You are proposing a HIP-wide change whereas I propose > > a referral-application-wide change. > > But, how do you know if the app is planning to do a refferal or > not? The administrator knows. For example I know that FTP uses referrals. An heuristic for finding them might be: Does it breaks with NATs? > I mean, in order to make a refferal application wide change the hip > layer need to know which are the apps that will make refferals and > which wno't. > So how do you recognize the refferal apps, i.e. how does the hip > layer knows whether to use refferal capable AID or the regular > hits? It's not the HIP layer, it is the administrator who is determining which app makes referral, and which does not. Thus, the HIP layer will know because this functionnality is activated for each such application. How this functionnality is activated for an application (or a group of apps) is implementation-dependent, but one might think to a wrapper telling the HIP layer which PID (and childs) is about to make referrals, or a Jail (as in FreeBSD) within which all processes uses only IP addresses as AIDs, etc. On my (kludge :) implementation, an application might use indiferrently a HIT, an IPv6 or an IPv4 address in the socket API. If I jail some of them within a HIT-addressed Jail, they'll use only a HIT. If I Jail some of them within an IP-addressed Jail, they'll use only IP addresses, thus allowing for referrals. But this is not automatic, you need to know in advance which applications will make referrals. Thanks, --julien From thomas.r.henderson@boeing.com Thu Jul 15 11:27:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Thu Jul 15 10:27:01 2004 Subject: [Hipsec] HIP MM/MH extensions draft online Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C045221F6@xch-nw-27.nw.nos.boeing.com> A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : End-Host Mobility and Multi-Homing with Host Identity Protocol Author(s) : P. Nikander, et al. Filename : draft-nikander-hip-mm-02.txt Pages : 33 Date : 2004-7-14 =09 This document specifies end-host mobility and multi-homing mechanisms for the Host Identity Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nikander-hip-mm-02.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-nikander-hip-mm-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From thomas.r.henderson@boeing.com Thu Jul 15 23:53:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Thu Jul 15 22:53:01 2004 Subject: [Hipsec] (not) using HITs as an application identifier Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04522215@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Julien Laganier [mailto:Julien.Laganier@Sun.COM] > Sent: Thursday, July 15, 2004 8:06 AM > To: marcelo bagnulo braun > Cc: Henderson, Thomas R; hipsec@honor.trusecure.com > Subject: Re: [Hipsec] (not) using HITs as an application identifier >=20 >=20 > Hi Marcelo, >=20 > On Thursday 15 July 2004 16:07, marcelo bagnulo braun wrote: > > > > > > > I think we mostly agree. My main disagreement was on the scope of > > > the change. You are proposing a HIP-wide change whereas I propose > > > a referral-application-wide change. > > > > But, how do you know if the app is planning to do a refferal or > > not? >=20 > The administrator knows.=20 >=20 > For example I know that FTP uses referrals.=20 >=20 > An heuristic for finding them might be: Does it breaks with NATs?=20 >=20 I don't really know how I would distinguish between referral aps=20 and non-referral apps from within the kernel, or how to wrap them=20 as you mentioned. Perhaps I don't fully understand. Anyway, for those interested more on this topic, a new I-D was just announced to multi6 group and ietf-announce: A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Considerations on HIP based IPv6 multi-homing Author(s) : P. Nikander, T. Henderson Filename : draft-nikander-multi6-hip-01.txt Pages : 30 Date : 2004-7-15 =09 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nikander-multi6-hip-01.txt Changelog: Changes between this version (-01) and -00 draft - added Section 2.6 comparing HIP with other group F multi6 proposals - added Section 3.3 describing how HIP could be possibly changed to include routable AIDs - updated references to HIP WG and HIP RG (Section 1.2) =20 From marcelo@it.uc3m.es Mon Jul 19 13:11:29 2004 From: marcelo@it.uc3m.es (marcelo bagnulo braun) Date: Mon Jul 19 12:11:29 2004 Subject: [Hipsec] (not) using HITs as an application identifier In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04522215@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04522215@xch-nw-27.nw.nos.boeing.com> Message-ID: El 16/07/2004, a las 0:20, Henderson, Thomas R escribi=F3: > > >> -----Original Message----- >> From: Julien Laganier [mailto:Julien.Laganier@Sun.COM] >> Sent: Thursday, July 15, 2004 8:06 AM >> To: marcelo bagnulo braun >> Cc: Henderson, Thomas R; hipsec@honor.trusecure.com >> Subject: Re: [Hipsec] (not) using HITs as an application identifier >> >> >> Hi Marcelo, >> >> On Thursday 15 July 2004 16:07, marcelo bagnulo braun wrote: >>> >>> >>>> I think we mostly agree. My main disagreement was on the scope of >>>> the change. You are proposing a HIP-wide change whereas I propose >>>> a referral-application-wide change. >>> >>> But, how do you know if the app is planning to do a refferal or >>> not? >> >> The administrator knows. >> >> For example I know that FTP uses referrals. >> >> An heuristic for finding them might be: Does it breaks with NATs? >> > > I don't really know how I would distinguish between referral aps > and non-referral apps from within the kernel, or how to wrap them > as you mentioned. Perhaps I don't fully understand. > My understanding is this would work similar to a NAT placed within the=20= host. So the wrap would inspect the contents of the packets and if it=20 recognizes one of the apps that the admin has designed as "refferal=20 apps" then it would substitute the AID for routable AIDs Another possibility is that the resolver is capable of recognizing=20 "refferal apps", so when one of the "refferal apps" asks the resolver,=20= the resolver returns a routable AID instead of the HIT. In any case, this at least requires manual configuration of what are=20 the apps that require refferals are. There is an additional problem though, with long lived communications=20 (as you explained in your initial email) Not only the apps that use refferals have problems but also the apps=20 that have long lived communications, with long periods of inactivity=20 also have problems with the garbage collection mechanisms. I guess that it would also be required that the administrator defines=20 which apps fall in this category, but i am afraid that this will be=20 harder than identifying refferal apps. Regards, marcelo > Anyway, for those interested more on this topic, a new I-D was > just announced to multi6 group and ietf-announce: > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > > > Title : Considerations on HIP based IPv6 multi-homing > Author(s) : P. Nikander, T. Henderson > Filename : draft-nikander-multi6-hip-01.txt > Pages : 30 > Date : 2004-7-15 > =09 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-nikander-multi6-hip-01.txt > > > Changelog: > > Changes between this version (-01) and -00 draft > > - added Section 2.6 comparing HIP with other group F multi6 > proposals > > - added Section 3.3 describing how HIP could be possibly changed > to include routable AIDs > > - updated references to HIP WG and HIP RG (Section 1.2) > > > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > From pekka.nikander@nomadiclab.com Mon Jul 19 13:12:03 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Jul 19 12:12:03 2004 Subject: [Hipsec] (not) using HITs as an application identifier In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060750@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060750@xch-nw-27.nw.nos.boeing.com> Message-ID: <2C8B53A6-D749-11D8-A0C5-000393CE1E8C@nomadiclab.com> A very interesting proposal, Tom. Thanks! But perhaps we could do it slightly differently: > I am offering up for discussion the proposal that we use > routable IP addresses as application IDs (AIDs) instead of HITs. Sounds quite interesting; my first thought was that this sounds like using routable IP addresses as LSIs. > This means that HIP would use IP addresses (namely, the addresses > used in the base exchange) as constant, non-changing addresses > in the pseudoheader, and HITs would, in principle, only be exposed > to HIP-aware applications. What if we used routable IP addresses *only* in the API level, and not even in the pseudo header? That is, what if the API layer would have a table of "HIPed" IP addresses, and would map an IP address returned by an application immediately, before passing it down the stack, into a HIT, an vice versa. There would be a bit in the process context and/or in the socket data structure telling whether this mapping is done or not. It would be implementation specific how to define the default for these bits per process. (Side note: implementing this would be almost trivial in our FreeBSD implementation.) That would allow non-referral apps to interoperate between the current style HIP implementations and the IP-addr-API style HIP implementations, similar in nature to the current ability to allow IPv4 API apps interoperate with IPv6 API apps. Given that most implementations would probably offer both modes of operation, the market would probably pretty soon decide which mode to use. In summary, implementations would map IP address AIDs into HITs when processing "outgoing" system calls, and map the HIT in received packets into the IP address AID in "incoming" system calls. I haven't thought about the security implications of this, yet. --Pekka From pekka.nikander@nomadiclab.com Mon Jul 19 13:12:10 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Jul 19 12:12:10 2004 Subject: [Hipsec] Recovery from state loss In-Reply-To: <200407151325.14103.julien.laganier@sun.com> References: <200407151325.14103.julien.laganier@sun.com> Message-ID: >> So here is my attempted approach and a close handshake that >> can apply to HIP as well as NOID. The goal is to remove the case >> when one end retains association state and the other end has >> discarded it, since this seems to open up some DoS opportunity. > > IMHO, this scheme fills a hole in the HIP specification, particularly > since we removed the RESYNC-related stuff. Hence, I am strongly in > favor of adopting (and adapting) the proposed approach. > > There's a remaining question, though: Does it belongs to the base > protocol spec, or rather to an extension? I would vote for the first > but I'm not 100% sure... > > What do other people think? I don't have any strong opinion. If someone makes a good write up for the base spec, I don't have anything against including it. On the other hand, I'm afraid that getting all the details (like various race conditions) right might take some time and effort. --Pekka From thomas.r.henderson@boeing.com Mon Jul 19 13:12:17 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Mon Jul 19 12:12:17 2004 Subject: [Hipsec] (not) using HITs as an application identifier Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060779@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > Sent: Friday, July 16, 2004 9:57 AM > To: Henderson, Thomas R > Cc: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] (not) using HITs as an application identifier >=20 >=20 > What if we used routable IP addresses *only* in the API level, > and not even in the pseudo header? That is, what if the API layer > would have a table of "HIPed" IP addresses, and would map > an IP address returned by an application immediately, before > passing it down the stack, into a HIT, an vice versa. =20 This is actually how our implementation works already-- we do not pass HITs to user space applications. The main difference that I see is a difficulty in deferring=20 context exchange for a transport session, in the LHIP case. =20 Receiver has to know how the pseudoheader was constructed,=20 and in absence of any context exchange, relies on the IP=20 addresses.=20 Tom=20 From pekka.nikander@nomadiclab.com Mon Jul 19 13:12:21 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Jul 19 12:12:21 2004 Subject: [Hipsec] (not) using HITs as an application identifier In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060779@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060779@xch-nw-27.nw.nos.boeing.com> Message-ID: >> What if we used routable IP addresses *only* in the API level, >> and not even in the pseudo header? That is, what if the API layer >> would have a table of "HIPed" IP addresses, and would map >> an IP address returned by an application immediately, before >> passing it down the stack, into a HIT, an vice versa. > > This is actually how our implementation works already-- we > do not pass HITs to user space applications. Nice :-) > The main difference that I see is a difficulty in deferring > context exchange for a transport session, in the LHIP case. > Receiver has to know how the pseudoheader was constructed, > and in absence of any context exchange, relies on the IP > addresses. In a minimal LHIP exchange, you just exchange the HITs without *any* verification at all. Hence, you have them available in your stack. That can be easily piggybacked in TCP handshake. In practise, you want to exchange also your WIMP hash anchors, though still with no security for the HITs. (Including the HIT in the WIMP hash chain does not seem to add any security wrt. the HITs, but may make sense as it seems to make a MITM attacker's life slightly harder.) Since a HIT is 16 bytes, and a WIMP hash anchor should also be minimal 16 bytes (maybe 20), including them + header overhead means some 40 additional bytes to the initial TCP SYN and SYN ACK. Plus, as you receive the SYN ACK, you know if the other end supports LHIP or not. --Pekka From marcelo@it.uc3m.es Tue Jul 20 05:19:01 2004 From: marcelo@it.uc3m.es (marcelo bagnulo braun) Date: Tue Jul 20 04:19:01 2004 Subject: [Hipsec] (not) using HITs as an application identifier In-Reply-To: <2C8B53A6-D749-11D8-A0C5-000393CE1E8C@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060750@xch-nw-27.nw.nos.boeing.com> <2C8B53A6-D749-11D8-A0C5-000393CE1E8C@nomadiclab.com> Message-ID: Hi Pekka, > I haven't thought about the security implications of this, yet. > i guess that the problem is how to (securely) link an AID with a HIT. I mean, how does a node knows that a given AID (routable IP address) actually corresponds to a given HIT? Regards, marcelo > --Pekka > > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > From thomas.r.henderson@boeing.com Tue Jul 20 22:27:00 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue Jul 20 21:27:00 2004 Subject: [Hipsec] (not) using HITs as an application identifier Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0406078A@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 > Sent: Tuesday, July 20, 2004 2:19 AM > To: Pekka Nikander > Cc: Henderson, Thomas R; hipsec@honor.trusecure.com > Subject: Re: [Hipsec] (not) using HITs as an application identifier >=20 >=20 > Hi Pekka, >=20 >=20 > > I haven't thought about the security implications of this, yet. > > >=20 > i guess that the problem is how to (securely) link an AID with a HIT. >=20 > I mean, how does a node knows that a given AID (routable IP address)=20 > actually corresponds to a given HIT? >=20 What scenario are you worried about? =20 If a system is only provided with a routable AID, there are some=20 limits to the security of being able to link it to a HIT. However, trusted DNS with reverse lookup is one way. CB64 approach to the AID is another. =20 If system is provided with a HIT and a routable AID as a hint of a locator to use, then we shouldn't have lost any security with this = change. From Julien.Laganier@Sun.COM Wed Jul 21 10:20:03 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Wed Jul 21 09:20:03 2004 Subject: [Hipsec] (not) using HITs as an application identifier In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C04060779@xch-nw-27.nw.nos.boeing.com> Message-ID: <200407211601.39554.julien.laganier@sun.com> Hi Pekka, One question below... On Friday 16 July 2004 20:35, Pekka Nikander wrote: > >> What if we used routable IP addresses *only* in the API level, > >> and not even in the pseudo header? That is, what if the API > >> layer would have a table of "HIPed" IP addresses, and would map > >> an IP address returned by an application immediately, before > >> passing it down the stack, into a HIT, an vice versa. I like this idea. > > This is actually how our implementation works already-- we > > do not pass HITs to user space applications. > > Nice :-) > > > The main difference that I see is a difficulty in deferring > > context exchange for a transport session, in the LHIP case. > > Receiver has to know how the pseudoheader was constructed, > > and in absence of any context exchange, relies on the IP > > addresses. > > In a minimal LHIP exchange, you just exchange the HITs without > *any* verification at all. Hence, you have them available in > your stack. That can be easily piggybacked in TCP handshake. In the case of an opportunistic LHIP or HIP exchange (i.e., unknown responder HIT) piggybacked on the TCP handshake, how do you compute the pseudo-header of the initial TCP SYN? with IP addresses? Or does opportunistic mode conflicts w/ piggybacking? Thanks, --julien From marcelo@it.uc3m.es Wed Jul 21 10:20:11 2004 From: marcelo@it.uc3m.es (marcelo bagnulo braun) Date: Wed Jul 21 09:20:11 2004 Subject: [Hipsec] (not) using HITs as an application identifier In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C0406078A@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406078A@xch-nw-27.nw.nos.boeing.com> Message-ID: <688BB052-DB20-11D8-A131-000D93ACD0FE@it.uc3m.es> Hi Tom, El 21/07/2004, a las 4:25, Henderson, Thomas R escribi=F3: > > >> -----Original Message----- >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> Sent: Tuesday, July 20, 2004 2:19 AM >> To: Pekka Nikander >> Cc: Henderson, Thomas R; hipsec@honor.trusecure.com >> Subject: Re: [Hipsec] (not) using HITs as an application identifier >> >> >> Hi Pekka, >> >> >>> I haven't thought about the security implications of this, yet. >>> >> >> i guess that the problem is how to (securely) link an AID with a HIT. >> >> I mean, how does a node knows that a given AID (routable IP address) >> actually corresponds to a given HIT? >> > > What scenario are you worried about? > > If a system is only provided with a routable AID, there are some > limits to the security of being able to link it to a HIT. However, > trusted DNS with reverse lookup is one way. CB64 approach to the AID=20= > is > another. > I agree that those mechanism can provide the security features, but=20 then i wonder what do you use the HIT for? I guess i am not understanding Pekka's suggestion... I mean if the apps uses the routable AID and you build the security=20 mechanisms as those you describe above in order to provide the required=20= security for those identifiers, then why do you need to map to the HIP,=20= for instance in the pseudo header, in other words, who would deal with=20= the HIT in this case? Regards, marcelo > If system is provided with a HIT and a routable AID as a hint of > a locator to use, then we shouldn't have lost any security with this=20= > change. > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > From Julien.Laganier@Sun.COM Wed Jul 21 11:52:08 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Wed Jul 21 10:52:08 2004 Subject: [Hipsec] (not) using HITs as an application identifier In-Reply-To: <688BB052-DB20-11D8-A131-000D93ACD0FE@it.uc3m.es> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406078A@xch-nw-27.nw.nos.boeing.com> <688BB052-DB20-11D8-A131-000D93ACD0FE@it.uc3m.es> Message-ID: <200407211630.36754.julien.laganier@sun.com> Hi Marcelo, I tried to answer your question below... On Wednesday 21 July 2004 16:15, marcelo bagnulo braun wrote: > Hi Tom, > > El 21/07/2004, a las 4:25, Henderson, Thomas R escribi=F3: > >> -----Original Message----- > >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > >> Sent: Tuesday, July 20, 2004 2:19 AM > >> To: Pekka Nikander > >> Cc: Henderson, Thomas R; hipsec@honor.trusecure.com > >> Subject: Re: [Hipsec] (not) using HITs as an application > >> identifier > >> > >> > >> Hi Pekka, > >> > >>> I haven't thought about the security implications of this, yet. > >> > >> i guess that the problem is how to (securely) link an AID with a > >> HIT. > >> > >> I mean, how does a node knows that a given AID (routable IP > >> address) actually corresponds to a given HIT? > > > > What scenario are you worried about? > > > > If a system is only provided with a routable AID, there are some > > limits to the security of being able to link it to a HIT.=20 > > However, trusted DNS with reverse lookup is one way. CB64 > > approach to the AID is > > another. > > I agree that those mechanism can provide the security features, but > then i wonder what do you use the HIT for? > I guess i am not understanding Pekka's suggestion... > I mean if the apps uses the routable AID and you build the security > mechanisms as those you describe above in order to provide the > required security for those identifiers, then why do you need to > map to the HIP, for instance in the pseudo header, in other words, > who would deal with the HIT in this case? My understanding is that some simple client/server applications like=20 telnet, http or ftp can use HITs in the socket API instead of IP=20 addresses, while more complex referral applications might require to=20 use IP addresses in the API.=20 And we might have a library call or something like that for setting=20 the AID API type to IP addresses or HIT , and a global system=20 variable allowing to choose the default system-wide policy. Thanks, =2D-julien From thomas.r.henderson@boeing.com Wed Jul 21 14:50:11 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Jul 21 13:50:11 2004 Subject: [Hipsec] (not) using HITs as an application identifier Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0406078C@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 > Sent: Wednesday, July 21, 2004 7:15 AM > To: Henderson, Thomas R > Cc: hipsec@honor.trusecure.com; Pekka Nikander > Subject: Re: [Hipsec] (not) using HITs as an application identifier >=20 >=20 > Hi Tom, >=20 > El 21/07/2004, a las 4:25, Henderson, Thomas R escribi=F3: >=20 > > > > > >> -----Original Message----- > >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > >> Sent: Tuesday, July 20, 2004 2:19 AM > >> To: Pekka Nikander > >> Cc: Henderson, Thomas R; hipsec@honor.trusecure.com > >> Subject: Re: [Hipsec] (not) using HITs as an application identifier > >> > >> > >> Hi Pekka, > >> > >> > >>> I haven't thought about the security implications of this, yet. > >>> > >> > >> i guess that the problem is how to (securely) link an AID=20 > with a HIT. > >> > >> I mean, how does a node knows that a given AID (routable=20 > IP address) > >> actually corresponds to a given HIT? > >> > > > > What scenario are you worried about? > > > > If a system is only provided with a routable AID, there are some > > limits to the security of being able to link it to a HIT. However, > > trusted DNS with reverse lookup is one way. CB64 approach=20 > to the AID=20 > > is > > another. > > >=20 > I agree that those mechanism can provide the security features, but=20 > then i wonder what do you use the HIT for? > I guess i am not understanding Pekka's suggestion... > I mean if the apps uses the routable AID and you build the security=20 > mechanisms as those you describe above in order to provide=20 > the required=20 > security for those identifiers, then why do you need to map=20 > to the HIP,=20 > for instance in the pseudo header, in other words, who would=20 > deal with=20 > the HIT in this case? >=20 I still think that HIT is useful as a fixed length identifier with strong cryptographic properties and less odds of collision than 64 bits, for example. I view the proposed routable AID more as a=20 transition mechanism to support both referrals to non-HIP-aware hosts = and to help deployment before there is a reverse lookup service for HITs. In the future, were HIP to become useful and deployed, I would expect=20 that the apps eventually deal with the more secure names available=20 such as HITs, and use a HIP-aware API. As far as I understand it, the difference with Pekka's suggestion is mainly what goes into the pseudoheader. Using HITs is=20 architecturally cleaner in my view, but it seems to have possible=20 downside in being able to delay HIP exchange. Tom From pekka.nikander@nomadiclab.com Thu Jul 22 12:18:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Jul 22 11:18:01 2004 Subject: [Hipsec] (not) using HITs as an application identifier In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C0406078C@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406078C@xch-nw-27.nw.nos.boeing.com> Message-ID: >> I agree that those mechanism can provide the security features, but >> then i wonder what do you use the HIT for? >> I guess i am not understanding Pekka's suggestion... > > I view the proposed routable AID more as a > transition mechanism to support both referrals to non-HIP-aware hosts > and > to help deployment before there is a reverse lookup service for HITs. And I fully concur with this view. > In the future, were HIP to become useful and deployed, I would expect > that the apps eventually deal with the more secure names available > such as HITs, and use a HIP-aware API. Again, I fully agree. Furthermore, my personal guess is that most people would configure their stack to return HIT by default, and use IP-address-AIDs only for some odd apps that would not work with HITs. But that's a question where we can get the answer from ther market, I guess. > As far as I understand it, the difference with Pekka's suggestion > is mainly what goes into the pseudoheader. Yes, at the protocol level the difference between your and my suggestions is exactly this. > Using HITs is architecturally cleaner in my view, but it seems to > have possible downside in being able to delay HIP exchange. My gut feeling is that the problem with delaying the HIP exchange can be solved, at least to a degree. Furthermore, for some reason which I can't quite express yet, I dislike the idea of starting a session without any extra signalling, and then "upgrading" later to HIP. IMHO, at minimum there should be a single bit saying that "I support this extension", negotiated during the initial handshake. And if so, I don't see exchanging 2 16 byte words that much more than a single bit :-) --Pekka From pekka.nikander@nomadiclab.com Thu Jul 22 12:41:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Jul 22 11:41:01 2004 Subject: [Hipsec] (not) using HITs as an application identifier In-Reply-To: <200407211601.39554.julien.laganier@sun.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060779@xch-nw-27.nw.nos.boeing.com> <200407211601.39554.julien.laganier@sun.com> Message-ID: >>> The main difference that I see is a difficulty in deferring >>> context exchange for a transport session, in the LHIP case. >>> Receiver has to know how the pseudoheader was constructed, >>> and in absence of any context exchange, relies on the IP >>> addresses. >> >> In a minimal LHIP exchange, you just exchange the HITs without >> *any* verification at all. Hence, you have them available in >> your stack. That can be easily piggybacked in TCP handshake. > > In the case of an opportunistic LHIP or HIP exchange (i.e., unknown > responder HIT) piggybacked on the TCP handshake, how do you compute > the pseudo-header of the initial TCP SYN? with IP addresses? Or does > opportunistic mode conflicts w/ piggybacking? Well, as a first approximation, if HIT_Responder==NULL, then the TCP/UDP pseudo header should use the IP addresses. In fact, I would go one step further and define the IP or TCP Option for the Opportunistic LHIP case NOT to include the Responder HIT at all, and compute the TCP SYN using a fully backward compatible pseudo header. If the Responder does understand Opportunistic LHIP, it will then answer with the same or a similar option, but start using HITs in the pseudo header. For robustness, the Option could contain a single bit indicating which way the pseudo-header has been constructed. In the non-opportunistic LHIP case, there is no need for a IP or TCP option. Instead, one can use the (L)HIP protocol and just piggyback the TCP SYN segment. --Pekka From Gonzalo.Camarillo@ericsson.com Fri Jul 23 08:40:01 2004 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Fri Jul 23 07:40:01 2004 Subject: [Hipsec] Agenda requests In-Reply-To: <40ED8090.90508@ericsson.com> References: <40ED8090.90508@ericsson.com> Message-ID: <410106E6.1010306@ericsson.com> Folks, a preliminary version of the agenda is available at: http://hip.piuha.net/meetings/ietf60/agenda.html If you still have not requested your slot, or you did but it does not appear in the agenda, let us know as soon as possible. Thanks, Gonzalo Gonzalo Camarillo wrote: > Folks, > > we are officially starting to gather agenda requests for San Diego. In > principle, we will be getting a 1 and 1/2 hour slot. Send your agenda > request to the chairs. > > Thanks, > > Gonzalo > HIP co-chair > From mkousa@cc.hut.fi Tue Jul 27 08:59:01 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Tue Jul 27 07:59:01 2004 Subject: [Hipsec] mm-02, SPI parameter in readdressing Message-ID: What is the purpose of the SPI parameter in Figure 3 in section 5.1 ? Do we put in there the SPI value what was in the received REA parameter ? From thomas.r.henderson@boeing.com Wed Jul 28 12:42:02 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Jul 28 11:42:02 2004 Subject: [Hipsec] mm-02, SPI parameter in readdressing Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C045222D0@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Mika Kousa [mailto:mkousa@cc.hut.fi]=20 > Sent: Tuesday, July 27, 2004 5:59 AM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] mm-02, SPI parameter in readdressing >=20 >=20 > What is the purpose of the SPI parameter in Figure 3 in=20 > section 5.1 ? Do=20 > we put in there the SPI value what was in the received REA parameter ? This is for middleboxes to learn of the peer host's inbound SPI on the new packet path. Tom=20 From Erik Nordmark Thu Jul 29 06:05:01 2004 From: Erik Nordmark (Erik Nordmark) Date: Thu Jul 29 05:05:01 2004 Subject: [Hipsec] (not) using HITs as an application identifier Message-ID: > I don't really know how I would distinguish between referral aps > and non-referral apps from within the kernel, or how to wrap them > as you mentioned. Perhaps I don't fully understand. I have the same concern. A conservative approach would be to assume that all unmodified applications need an IP address as the AID and then have sevarel mechanisms by which one can specify that a HIT as the AID is fine: - an API that the application can invoke - mechanisms external to the application that a system admin can use e.g. to say that the applications which use a particular TCP port number, where the application has a particular name, etc can use a HIT as the AID. This way one can incrementally try running different unmodified applications with AID=HIT and see if they work. Separately presumably it is desirable for add new APIs for modified applications to extract lower level information: - get the HIT for the peer (which might be useful even when AID=IP address) - get the current set of known locators for the peer (for referrals using HIT+set of locators) What isn't clear to me though are the tradeoffs between having the transports use the HIT vs. the IP address in the pseudo-header; it would be good to try to enumerate those. Erik From marcelo@it.uc3m.es Thu Jul 29 06:23:01 2004 From: marcelo@it.uc3m.es (marcelo bagnulo braun) Date: Thu Jul 29 05:23:01 2004 Subject: [Hipsec] (not) using HITs as an application identifier In-Reply-To: References: Message-ID: <93AD93E8-E149-11D8-A131-000D93ACD0FE@it.uc3m.es> El 29/07/2004, a las 12:05, Erik Nordmark escribi=F3: >> I don't really know how I would distinguish between referral aps >> and non-referral apps from within the kernel, or how to wrap them >> as you mentioned. Perhaps I don't fully understand. > > I have the same concern. > > A conservative approach would be to assume that all unmodified > applications need an IP address as the AID and then have sevarel > mechanisms by which one can specify that a HIT as the AID is fine: > - an API that the application can invoke > - mechanisms external to the application that a system admin can > use e.g. to say that the applications which use a particular TCP=20 > port > number, where the application has a particular name, etc > can use a HIT as the AID. > > This way one can incrementally try running different unmodified=20 > applications > with AID=3DHIT and see if they work. > > Separately presumably it is desirable for add new APIs for modified > applications to extract lower level information: > - get the HIT for the peer (which might be useful even when AID=3DIP=20= > address) > - get the current set of known locators for the peer (for referrals=20= > using > HIT+set of locators) > Yes, this could be not only useful for referrals apps, but also for=20 those which have long term communications that may be inactive for long=20= periods. If the apps knows that it may have problems with garbage=20 collection mechanism, it can choose to store the HIP and locators in=20 the app level, so that if that info is no longer available in the HIP=20 layer, it is still available in the app. (the other option is always=20 use FQDN instead, but i guess this may provide not provide proper=20 performance for certain apps) regards, marcelo > > What isn't clear to me though are the tradeoffs between having the=20 > transports > use the HIT vs. the IP address in the pseudo-header; it would be good=20= > to > try to enumerate those. > > Erik > > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > From jukka.ylitalo@nomadiclab.com Thu Jul 29 07:01:01 2004 From: jukka.ylitalo@nomadiclab.com (Jukka Ylitalo) Date: Thu Jul 29 06:01:01 2004 Subject: [Hipsec] (not) using HITs as an application identifier In-Reply-To: References: Message-ID: <4108D8CA.7060202@nomadiclab.com> Erik Nordmark wrote: > >What isn't clear to me though are the tradeoffs between having the transports >use the HIT vs. the IP address in the pseudo-header; it would be good to >try to enumerate those. > > Erik > > Using HITs instead of application layer identifiers AIDs (e.g. IPv4/IPv6 addresses) in the pseudo-header makes it possible to make IPv4 applications to talk with IPv6 applications. The pseudo-header checksum is computed with the HIT in both IPv4 and IPv6 application cases. However, this a bit advanced case, e.g., from the Multi6 point of view. I believe that it is better to have HITs in the pseudo header than IP address. However, the resolver library could return either IP address or HIT for the application (as mentioned earlier). br, Jukka From pekka.nikander@nomadiclab.com Thu Jul 29 09:18:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Jul 29 08:18:00 2004 Subject: [Hipsec] (not) using HITs as an application identifier In-Reply-To: <4108D8CA.7060202@nomadiclab.com> References: <4108D8CA.7060202@nomadiclab.com> Message-ID: >> What isn't clear to me though are the tradeoffs between having the >> transports >> use the HIT vs. the IP address in the pseudo-header... >> >> > Using HITs instead of application layer identifiers AIDs (e.g. > IPv4/IPv6 addresses) > in the pseudo-header makes it possible to make IPv4 applications to > talk with > IPv6 applications. The pseudo-header checksum is computed with the HIT > in > both IPv4 and IPv6 application cases. As far as I can understood, that is the main difference. When you use EIDs (i.e. HITs) in the pseudo header, you construct the pseudo header in an API-independent way. That way you can, if the app is well behaving, use different APIs at the different ends of the communication. Implementing dual rewriting, i.e. both at the API level above transport and at the wedge layer below transport, is slightly more complicated than just rewriting once, at the wedge layer. Using IP addresses in the TCP header allow for easier opportunistic operations, but that is really only needed for TCP SYN (or the first UDP packet), and can be taken care as a special case. --Pekka From thomas.r.henderson@boeing.com Thu Jul 29 12:42:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Thu Jul 29 11:42:01 2004 Subject: [Hipsec] (not) using HITs as an application identifier Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040607AE@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > Sent: Thursday, July 29, 2004 6:18 AM > To: Erik Nordmark > Cc: Jukka Ylitalo; hipsec@honor.trusecure.com > Subject: Re: [Hipsec] (not) using HITs as an application identifier >=20 >=20 > >> What isn't clear to me though are the tradeoffs between having the=20 > >> transports > >> use the HIT vs. the IP address in the pseudo-header... > >> > >> > > Using HITs instead of application layer identifiers AIDs (e.g.=20 > > IPv4/IPv6 addresses) > > in the pseudo-header makes it possible to make IPv4 applications to=20 > > talk with > > IPv6 applications. The pseudo-header checksum is computed=20 > with the HIT=20 > > in > > both IPv4 and IPv6 application cases. >=20 > As far as I can understood, that is the main difference. When > you use EIDs (i.e. HITs) in the pseudo header, you construct the > pseudo header in an API-independent way. That way you can, if the > app is well behaving, use different APIs at the different ends of > the communication. >=20 > Implementing dual rewriting, i.e. both at the API level above=20 > transport > and at the wedge layer below transport, is slightly more complicated > than just rewriting once, at the wedge layer. >=20 > Using IP addresses in the TCP header allow for easier opportunistic > operations, but that is really only needed for TCP SYN (or the first > UDP packet), and can be taken care as a special case. >=20 The use case I am thinking of is migrating an existing flow onto HIP protection (maybe for mobility or multihoming reasons that manifest themselves later). For example, I pack up my laptop to go home, and my suspend operation triggers exchange with my peers to establish the (L)HIP context that allows me to resume later from a different location. Pekka's hesitation to this use case is noted: http://honor.trusecure.com/pipermail/hipsec/2004-July/000879.html I don't know if this scenario is a strong requirement or goal of the multi6 group, but I have seen it expressed in mailing list discussion (don't have a reference handy). There doesn't seem to be any advantage (only slight disadvantage?)=20 to using IP addresses instead of HITs in the pseudoheader checksum, in the following two cases: i) full-blown HIP ii) LHIP case, in which we are willing to wait for a single=20 packet exchange to establish the context identifier tags (HITs) to use in the pseudoheaders The case that I think we are debating is some kind of LHIP case for which context establishment is deferred until after some time. That is not relevant to the scenario of IPv4 API on one side and IPv6 API on another, since that cannot work without a wedge. But let's assume that we start out with a normal IPv6 connection using addresses in the pseudoheader, then we establish the wedge context later. After that point, I think it is not important whether HITs or addresses are used in pseudoheader, as long as consistency is maintained; it doesn't impact one of these hosts' ability to migrate to another IPv6 or even IPv4 address-- the pseudoheader manipulation is simple and about the same in either case. Maybe the solution is to keep HIP pseudoheader unchanged, but consider a mode of (to be defined) LHIP operation that keeps=20 pseudoheader based on IP addresses, if multi6 group wants a solution that does not require context exchange up front. And avoid providing non-routable HITs posing as IP addresses to=20 non-HIP-aware apps: http://honor.trusecure.com/pipermail/hipsec/2004-July/000869.html Tom=20