From Wassim.Haddad@ericsson.ca Tue Sep 2 14:42:01 2003 From: Wassim.Haddad@ericsson.ca (Wassim Haddad) Date: Tue Sep 2 13:42:01 2003 Subject: [Hipsec] TEST Message-ID: <1062526125.8224.8.camel@ddgflw21> Please ignore From thomas.r.henderson@boeing.com Thu Sep 4 19:12:00 2003 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Thu Sep 4 18:12:00 2003 Subject: [Hipsec] packet processing text Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B59C6@xch-nw-27.nw.nos.boeing.com> Pekka, Here is some draft text that is a start to section 8 material. Embedded in the text are some notes and questions that may generate some more discussion. Feel free to further edit. I did not touch the BOS and CER packet processing. 8. Packet processing [NOTE1: This section and section 5.4 could perhaps be combined, and also the packet processing language in Section 7 could be moved here. Section 7 discusses packet processing in the outbound=20 direction (how outbound packets should be formatted), while the below text is more about inbound packet processing.] [NOTE2: This draft probably needs a terminology section that=20 defines "host" and some other terms. For example, a host can have=20 multiple host identities. Do we say that HIP daemon talks to a host or=20 an identity, when describing state machine operations???. Do we even use the term "daemon" (other places it is "implementation" or "system" or "state machine")?] [NOTE3: There is some ambiguity about whether a host may have=20 multiple active associations with a given peer host identity. I am=20 assuming that it may, but I noticed some implications on how certain packets such as R1 are processed in certain states-- perhaps it=20 should be discussed and clarified.] Each host is assumed to have a HIP daemon that manages the host's HIP associations and handles requests for new ones. Each HIP=20 association is governed by a state machine, with states defined above in Section 5.4. The HIP daemon can simultaneously maintain=20 HIP associations with more than one host. Furthermore, the HIP daemon may have more than one active HIP association with=20 another host; in this case, HIP associations are distinguished by=20 their respective HITs and/or IPsec SPIs. [Q. Is this last possibility = true? Can a host have, or would it want to have, multiple HIP=20 associations (IPsec SAs) with the same peer host identity?] =20 The processing of packets is dependent on the state of the HIP association(s) with respect to the authenticated or apparent=20 originator of the packet. A HIP daemon determines whether it has an active association with the originator of the packet based on the HITs and/or SPI of the packet. =20 =20 8.1 Initiation of a HIP exchange =20 An implementation may originate a HIP exchange to another host based on a local policy decision, usually triggered by an application datagram, in much the same way that an IPsec key exchange can=20 dynamically create a Security Association (SA). In such a case,=20 the implementation prepares an I1 packet and sends it to the IP=20 address that corresponds to the peer host. The IP address of the=20 peer host may be obtained via conventional mechanisms such as DNS=20 lookup. The I1 contents are specified in Section 7.1. The selection = of which host identity to use, if a host has more than one to choose=20 from, can also be a policy decision. =20 The Initiator gets the Responder's HIT either from a DNS lookup of the responder's FQDN, from some other repository, or from a local table. If the initiator does not know the responder's HIT, it may attempt anonymous mode by using NULL (all zeros) as the responder's HIT. Alternatively, a system may initiate a HIP exchange if it has=20 rebooted or timed out, or otherwise lost its HIP state, as described in Section 5.3. Upon sending an I1, the sender shall transition to state E1 and start a timer whose timeout value should be larger than the = worst-case=20 anticipated RTT, and shall increment a timeout counter associated = with=20 the I1. The sender SHOULD retransmit the I1 upon a timeout and = restart=20 the timer, up to a maximum of N1 tries. 8.2 Processing I1 packets An implementation SHOULD reply to an I1 with an R1 packet, unless=20 the implementation is unable or unwilling to setup a HIP association. If the implementation is unable to setup a HIP association, the host SHOULD send an ICMP Destination Protocol Unreachable message to the I1 source address. If the implementation is unwilling to setup a HIP association, the host MAY ignore the I1. This latter case may occur during a DoS attack such as an I1 flood. If the implementation chooses to respond to the I1 with an R1 packet, it should create or select a precomputed R1 according to the format described in Section 7.2 and send the R1 to the source IP address of the I1 packet. Under no circumstances does the HIP state machine transition upon sending an R1. =20 The implementation MUST be able to handle a storm of received I1=20 packets, discarding those with common content that arrive within a=20 small time delta. The HIP control bits MUST be ignored in the received I1. The = received Initiator HIT MUST be copied over to the Initiator HIT field in the = R1. The transmitted R1 is formatted as specified in Section 7.2. 8.2.1 R1 Management All compliant implementations MUST produce R1 packets. An R1 packet MAY be precomputed. An R1 packet MAY be reused for time Delta T. R1 information MUST not be discarded until Delta S after T. Time S is the delay needed for the last I2 to arrive back to the responder. A spoofed I1 can result in an R1 attack on a system. An R1 sender MUST have a mechanism to rate limit R1s to an address. An implementation MAY keep state about received I1s and match the=20 received I2s against the state, as discussed in Section 4.1.1. 8.3 Processing R1 packets A system receiving an R1 first checks to see if it has sent an I1 to the originator of the R1 (i.e., it is in state E1). If so, it SHOULD process the R1 as described below, send an I2, and go to state E2, setting a timer to protect the I2. If the system is in=20 state E0 or state E2 with respect to that host, it SHOULD silently = drop=20 the R1. If the system is in state E3, it SHOULD process with a Security Association and Birthday check as described in Section 5.3,=20 before further processing below. In this last case, if the R1 is successfully processed, the system sends an I2, sets a retransmit timer to protect the I2, drops its old Security Association, and goes = back to state E2. [Q. Is receipt of R1 in state E3, triggering a SA reestablishment, a potential replay attack?] Assuming the system has decided to process the R1, the following steps apply. The R1 SHOULD validate the HIP signature before applying further packet processing, according to Section 6.3.10. =20 The R1 packet may have the C bit set-- in this case, the system=20 should anticipate the receipt of HIP CERT packets that contain the host identity corresponding to the responder's HIT. [Q: Is this a substate that needs to be defined ("waiting for CERT")?] The R1 packet may have the A bit set-- in this case, the system MAY choose to refuse it by dropping the R1 and returning to state E0. [Q. DoS attack by early spoofed anonymous R1, similar to early=20 false DNS replies?]. If the A bit is set, the Responder's HIT is=20 anonymous and should not be stored or validated against a Host=20 Identity. If the A bit is not set, the system SHOULD attempt to=20 validate the HIT against the received Host Identity. Furthermore,=20 if the Initiator specified the Responder's HIT in the I1, it SHOULD=20 also check that the received HIT agrees with the one originally=20 selected. Finally, the Initiator's HIT MUST correspond to the HIT=20 used in the original I1. =20 The system MUST store the received Birthday count for future=20 reference. The system MUST attempt to solve the cookie puzzle, = trying=20 for a number of tries up to the minimum of the degree of difficulty=20 specified by the K value in the cookie parameter or an = implementation-=20 or policy-defined maximum retry count. If the cookie puzzle is not=20 successfully solved, the implementation may either resend I1 or =20 abandon the HIP exchange.=20 =20 The system computes standard Diffie-Hellman keying material according = to the public value and Group ID provided in the DIFFIE_HELLMAN parameter. The Diffie-Hellman keying material Kij is used for key extraction as specified in Section 9. [Q. What happens if D-H Group ID not supported? Start over?] The system selects the HIP transform and ESP transform from the choices presented in the R1 packet and uses the selected values subsequently when generating and using encryption keys, and when sending the I2. =20 =20 Upon sending an I2, the sender shall transition to state E2 and start a timer whose timeout value should be larger than the=20 worst-case anticipated RTT, and shall increment a timeout counter=20 associated with the I2. The sender SHOULD retransmit the I2 upon a=20 timeout and restart the timer, up to a maximum of N2 tries. 8.4 Processing I2 packets Upon receipt of an I2, the system MAY perform initial checks to determine whether the I2 corresponds to a recent R1 that has been sent out, if the Initiator keeps such state. For example, the sender could check whether the I2 is from an address or HIT that has recently sent it an I1. If the I2 is considered to be suspect, it MAY be discarded by the system. Otherwise, the HIP implementation SHOULD process the I2. =20 Assuming that the Responder HIT corresponds to one of the=20 implementation's HITs, the system MUST first validate the solution=20 to the cookie puzzle by computing the SHA-1 hash described in=20 Section 7.3, Next, the system MUST verify the HIP_SIGNATURE=20 according to Section 6.3.9 and Section 7.3. To decrypt the=20 HOST_ID (or HOST_ID_FQDN) corresponding to the signature, the=20 system must first derive Diffie-Hellman keying material based on=20 the public value and Group ID in the DIFFIE_HELLMAN parameter. =20 The encrypted HOST_ID or HOST_ID_FQDN is decrypted by the HIP=20 Initiator key defined in Section 9. The implementation SHOULD=20 also verify that the Initiator's HIT corresponds to the Host=20 Identity sent in the I2. If these checks are valid, then the=20 system proceeds with further I2 processing; otherwise, it discards=20 the I2 and remains in the same state. The I2 packet may have the C bit set-- in this case, the system=20 should anticipate the receipt of HIP CERT packets that contain the host identity corresponding to the responder's HIT.=20 The I2 packet may have the A bit set-- in this case, the system MAY choose to refuse it by dropping the I2 and returning to state E0. If the A bit is set, the Initiator's HIT is anonymous and should not=20 be stored or validated against a Host Identity. If the A bit is not=20 set, the system SHOULD attempt to validate the HIT against the=20 received Host Identity. Furthermore, the system SHOULD also check=20 that the Responder HIT corresponds to one of the system's HITs=20 offered in the R1. =20 The I2 packet may have the E bit set. If so, the HIP implementation will treat the ESP sequence numbers as 64 bit quantities as described in Section 11.4. The Birthday count is extracted from the BIRTHDAY_COOKIE parameter and stored for future use. The SPI_LSI field is parsed to obtain the SPI that will be used for the Security Association inbound to the Initiator. =20 [XXX: LSI unused for now?...] The I2 MUST have a single value in each of the HIP_TRANSFORM and ESP_TRANSFORM parameters, corresponding to the values selected by the Initiator, and they must each match one of the values=20 offered to the Initiator in the R1 packet. Other keying material=20 can be obtained at this time according to Section 9. Upon successful processing of an I2 in states E0, E1, and E2, an R2 is sent and the state machine transitions to state E3. Upon successful processing of an I2 in state E3 (which includes a successful Birthday check), the old Security Association is dropped and a new one is installed, an R2 is sent, and the state=20 machine cycles back to E3. 8.5 Processing R2 packets An R2 received in states E0, E1, or E3 results in the R2 being = dropped and the state machine staying in the same state. If an R2 is received in state E2, it SHOULD be processed. The=20 system MUST verify that the HITs in use correspond to the HITs that were used in R1. The HIP signature MUST be verified according to the procedures in 6.3.9. The R2 packet may have the E bit set. If so, the HIP implementation will treat the ESP sequence numbers as 64 bit quantities as described in Section 11.4. =20 The SPI_LSI field is parsed to obtain the SPI that will be used for the Security Association inbound to the Responder. =20 [XXX: LSI unused for now?...] Upon successful processing of the R2, the state machine moves to state E3. 8.6 Processing NES packets The ESP Sequence Number and current SPI are included to provide replay protection for the receiving peer. The old SA MUST NOT be deleted until all ESP packets with a lower Sequence Number have been received and processed, or a reasonable time has elapsed (to account for lost packets). If the Sequence Number is the replay window is greater than the number in the NES packet, the NES packet MUST be ignored. If the SPI number does not match with an existing SPI number used, the NES packet must be ignored. The peer that initiates a New SPI exchange MUST include a Diffie- Hellmen key. Its peer MUST respond with a New SPI packet, an MAY include a Diffie-Hellman key if the receiving system's policy is to increase the new KEYMAT by changing its key pair. When a host receives a New SPI Packet with a Diffie-Hellman, its next ESP packet MUST use the KEYMAT generated by the new Kij. The sending host MUST expect at least a replay window worth of ESP packets using the old Kij. Out of order delivery could result in needing the old Kij after packets start arriving using the new SA's Kij. Once past the rekeying start, the sending host can drop the old SA and its Kij. The first packet sent by the receiving system MUST be a HIP New SPI packet. It MAY also include a datagram, using the new SAs. This packet supplies the new SPI for the rekeying system, which cannot send any packets until it receives this packet. If it does not receive a HIP New SPI packet within a reasonable round trip delta, it MUST assume it or the HIP Rekey packet was lost and MAY resend the HIP New SPI packet or renegotiate HIP as if in a reboot condition. The choice is a local policy decision. This packet MAY contain a Diffie-Hellman key, if the receiving system's policy is to increase the new KEYMAT by changing its key pair. 8.7 Processing BOS packets 8.8 Processing CER packets From pekka.nikander@nomadiclab.com Fri Sep 5 06:56:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Sep 5 05:56:00 2003 Subject: [Hipsec] Updating moskowitz-hip-07: IPv4 pseudo header Message-ID: <3F58636C.4010409@nomadiclab.com> draft-moskowitz-hip-07.txt currently specifies as follows: 6.1.2 CRC The checksum field is located at the same location within the header as the checksum field in UDP packets, enabling hardware assisted checksum generation and verification. Note that since the checksum covers the source and destination addresses in the IP header, it must be recomputed on HIP based NAT boxes. .... In case of using IPv4, the the IPv6 pseudo header format [10] is still used, but in the pseudo-header source and destination addresses are IPv4 addresses expressed in IPv4-in-IPv6 format [3]. Now, do we really think that the IPv4 practise is the right one? If we have an IPv4 NAT box, it must explicitly know about how to update the HIP pseudo header, and the processing is different from the standard IPv4 TCP and UDP pseudo-header cases. That foils the statement above about being able to use hardware assisted checksum generation and verification. I propose that we change the text as follows: In case of using IPv4, the IPv4 UDP pseudo header format [RFC768] is used. In the pseudo header, the source and destination addresses are those used in the IP header, the zero field is obviously zero, the protocol is the HIP protcol number (TBD), and the length is calculated as in the IPv6 case. This would require a small change to the current implementations. Opinions? --Pekka Nikander From mkomu@niksula.hut.fi Fri Sep 5 08:08:04 2003 From: mkomu@niksula.hut.fi (Miika Komu) Date: Fri Sep 5 07:08:04 2003 Subject: [Hipsec] Updating moskowitz-hip-07: IPv4 pseudo header In-Reply-To: <3F58636C.4010409@nomadiclab.com> Message-ID: On Fri, 5 Sep 2003, Pekka Nikander wrote: > I propose that we change the text as follows: > > In case of using IPv4, the IPv4 UDP pseudo header format [RFC768] > is used. In the pseudo header, the source and destination > addresses are those used in the IP header, the zero field is > obviously zero, the protocol is the HIP protcol number (TBD), > and the length is calculated as in the IPv6 case. > > This would require a small change to the current implementations. > > Opinions? Sounds reasonable to me. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From pekka.nikander@nomadiclab.com Fri Sep 5 09:26:02 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Sep 5 08:26:02 2003 Subject: [Hipsec] Receiving an R1 in the established state (E3)? Message-ID: <3F588688.8070209@nomadiclab.com> draft-moskowitz-hip-07.txt currently specifies that if an implementation receives a valid R1 in the established state, it sends an I2, drops its SAs, and goes to the state E2. For an R1 to be valid, it is required that the host has recently sent data to the sender of the R1, and that the birthday number in the R1 is higher than the currently recorded one. This opens up a potential attack. An attacker can record an R1 from a different connection, forcing a higher birthday number. It can get the higher birthday number by forcing the host to rekey in some other connection. Once the attacker has got this kind of an R1, it can send it to the target node, which will drop the SAs as described above. It is even possible that the state is NOT re-established, since the sent I2 may fail the birthday check at the recipient, and as a result the recipient will never send an R2. I suggest that we add a new state, maybe called E3'. This is otherwise similar to E3, but differs in how an incoming R2 is processed. Currently in the E3 state an incoming R2 is dropped. In the new E3', an incoming R2 would be processed and the SAs would be replaced with the new ones. That would allow the target node to continue sending data using the old SAs, just in the case that its peer is still able to receive data. Hence, in a way, in E3' the implentation remembers two sets of keying material: the old one (still used) and the new one (based on received R1 and sent I2). Only when a matching R2 is received, the key material is replaced. This change would make the implementations more complex, but also more robust against this specific kind of attack. Comments? --Pekka From pekka.nikander@nomadiclab.com Fri Sep 5 09:46:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Sep 5 08:46:00 2003 Subject: [Hipsec] Re: packet processing text In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B59C6@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B59C6@xch-nw-27.nw.nos.boeing.com> Message-ID: <3F588B4F.30407@nomadiclab.com> Henderson, Thomas R wrote: > Here is some draft text that is a start to section 8 material. > Embedded in the text are some notes and questions that may > generate some more discussion. Feel free to further edit. > I did not touch the BOS and CER packet processing. Thanks a lot! I am right now editing the text to XML format. Two questions so far: > The R1 packet may have the A bit set-- in this case, the system > MAY choose to refuse it by dropping the R1 and returning to state E0. > [Q. DoS attack by early spoofed anonymous R1, similar to early > false DNS replies?]. If the A bit is set, the Responder's HIT is > anonymous and should not be stored or validated against a Host > Identity. I don't understand why the HIT should not be validated. Please explain. > The I2 packet may have the A bit set-- in this case, the system > MAY choose to refuse it by dropping the I2 and returning to state E0. > If the A bit is set, the Initiator's HIT is anonymous and should not > be stored or validated against a Host Identity. If the A bit is not I don't understand why the HIT should not be validated. Please explain. --Pekka From pekka.nikander@nomadiclab.com Fri Sep 5 10:30:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Sep 5 09:30:01 2003 Subject: [Hipsec] draft-moskowitz-hip-08.txt snapshot available Message-ID: <3F589582.9040308@nomadiclab.com> As may be apparent from my previous mails, I am finally updating draft-moskowitz-hip. The results from today's editing can be found at the following URLs. I will continue on Monday. The goal is to get -08 out still during this month. http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep05-chbar.txt http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep05-diff.html http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep05.html http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep05.txt http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep05.xml If possible, please send any comments as context diffs against the *xml* file. In that way I can patch them directly in. Otherwise I have to hand edit them. Besides, if anyone is willing to host an issue tracker for us, that would be great. Current list of old unresolved issues: 3. Unification of NES and REA 4. DoS on R2 5. Rules for extensions Issue being worked on: 9. Packet processing New issues: 10. Which pseudo header format to use for IPv4 carried HIP packets, IPv6 or IPv4 format? 11. Need to define the HMAC parameter, needed for mobility 12. It looks like R2 is too weak. It should include something derived from KEYMAT, I think. Maybe a HMAC payload? 13. Define how to send multiple I1s to multiple IP addresses in parallel, and rate limitations. 14. Possible weakness in receiving I2s in E3 state, as discussed in a previous mail. 15. Handling anonymous HITs in received R1 and I2. 16. Handling of LSIs. --Pekka From thomas.r.henderson@Boeing.com Fri Sep 5 15:03:01 2003 From: thomas.r.henderson@Boeing.com (Henderson, Thomas R) Date: Fri Sep 5 14:03:01 2003 Subject: [Hipsec] Updating moskowitz-hip-07: IPv4 pseudo header Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B59CC@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > Sent: Friday, September 05, 2003 3:20 AM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] Updating moskowitz-hip-07: IPv4 pseudo header >=20 >=20 > it must > be recomputed on HIP based NAT boxes. >=20 > .... >=20 For IPv4, what about avoiding dependence of HIP checksum on IP = addresses, since in IPv4 we have header checksums, and thereby reduce what we need an IPv4 NAT to do? It would be nice to figure out a way to avoid the need for any HIP=20 awareness in IPv4 NATs, at least for the most common "outbound from a private network to a public network server" case. HIP over TCP, or UDP/STUN? Tom =20 From pekka.nikander@nomadiclab.com Fri Sep 5 15:39:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Sep 5 14:39:01 2003 Subject: [Hipsec] Updating moskowitz-hip-07: IPv4 pseudo header In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B59CC@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B59CC@xch-nw-27.nw.nos.boeing.com> Message-ID: <3F58DDF7.1060102@nomadiclab.com> >> [the checksum] must be recomputed on HIP based NAT boxes. > > For IPv4, what about avoiding dependence of HIP checksum on IP addresses, > since in IPv4 we have header checksums, and thereby reduce what we need > an IPv4 NAT to do? That is one possibility. On the other hand, the NAT boxes do update the TCP and UDP checksums today, and they must process the HIP packets separately anyway (see below). Hence, the question is not so much of software but how to preserve hardware acceleration while updating firmware. > It would be nice to figure out a way to avoid the need for any HIP > awareness in IPv4 NATs, at least for the most common "outbound from a > private network to a public network server" case. HIP over TCP, or > UDP/STUN? Well, it is not enough to tunnel just the HIP protocol over TCP, UDP or UDP/STUN. You must also tunnel the resulting ESP SAs. Therefore, I think that while such practise is probably valuable, it warrants a separate specification, and should not be included in the base spec. On the other hand, if HIP gets commonplace, I would expect many NAT vendors to provide firmware updates that teach the NAT boxes to process the HIP packets and to set up the SPI mappings so that ESP works. --Pekka Nikander From thomas.r.henderson@boeing.com Fri Sep 5 16:42:01 2003 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Fri Sep 5 15:42:01 2003 Subject: [Hipsec] Updating moskowitz-hip-07: IPv4 pseudo header Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B59D2@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > Sent: Friday, September 05, 2003 12:03 PM > To: Henderson, Thomas R > Cc: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Updating moskowitz-hip-07: IPv4 pseudo header >=20 > > It would be nice to figure out a way to avoid the need for any HIP=20 > > awareness in IPv4 NATs, at least for the most common=20 > "outbound from a > > private network to a public network server" case. HIP over TCP, or > > UDP/STUN? >=20 > Well, it is not enough to tunnel just the HIP protocol > over TCP, UDP or UDP/STUN. You must also tunnel the resulting > ESP SAs. Therefore, I think that while such practise is probably > valuable, it warrants a separate specification, and should not > be included in the base spec. I agree about handling it in a separate spec. For the ESP tunneling, there are already efforts in ipsec WG for tunneling through NATs-- they may be of use. >=20 > On the other hand, if HIP gets commonplace, I would expect > many NAT vendors to provide firmware updates that teach the > NAT boxes to process the HIP packets and to set up the > SPI mappings so that ESP works. >=20 Yes, but we have a chicken-and-egg problem here with the massive NAT deployment in place. NAT is deployed in lots of products=20 nowadays-- some of which may not have a convenient upgrade path. Tom From rgm@htt-consult.com Fri Sep 5 17:05:01 2003 From: rgm@htt-consult.com (Robert Moskowitz) Date: Fri Sep 5 16:05:01 2003 Subject: [Hipsec] Updating moskowitz-hip-07: IPv4 pseudo header In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B59D2@xch-nw-27.nw.nos. boeing.com> Message-ID: <5.1.0.14.2.20030905162633.0314db98@localhost> At 01:05 PM 9/5/2003 -0700, Henderson, Thomas R wrote: > > On the other hand, if HIP gets commonplace, I would expect > > many NAT vendors to provide firmware updates that teach the > > NAT boxes to process the HIP packets and to set up the > > SPI mappings so that ESP works. > > >Yes, but we have a chicken-and-egg problem here with the massive >NAT deployment in place. NAT is deployed in lots of products >nowadays-- some of which may not have a convenient upgrade path. Think about this Netgear bug. 10,000 units out there that need an upgrade. How many will do it? Of course with HIP and NATs the hope is that the NAT owner wants the feature and will be interested in doing the update. On the otherhand, my DSL provider will NOT let me upgrade my router, as that is the version that they got working with their DSLam, and they no longer use my router for new installs.... oy. From thomas.r.henderson@boeing.com Fri Sep 5 20:02:01 2003 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Fri Sep 5 19:02:01 2003 Subject: [Hipsec] RE: packet processing text Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B59D6@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > Sent: Friday, September 05, 2003 6:11 AM > To: Henderson, Thomas R > Cc: hipsec@honor.trusecure.com > Subject: Re: packet processing text >=20 >=20 > Henderson, Thomas R wrote: > > Here is some draft text that is a start to section 8 material. > > Embedded in the text are some notes and questions that may > > generate some more discussion. Feel free to further edit. > > I did not touch the BOS and CER packet processing. >=20 > Thanks a lot! >=20 > I am right now editing the text to XML format. >=20 > Two questions so far: >=20 > > The R1 packet may have the A bit set-- in this case, the system > > MAY choose to refuse it by dropping the R1 and returning=20 > to state E0. > > [Q. DoS attack by early spoofed anonymous R1, similar to early=20 > > false DNS replies?]. If the A bit is set, the=20 > Responder's HIT is=20 > > anonymous and should not be stored or validated against a Host=20 > > Identity. =20 >=20 > I don't understand why the HIT should not be validated. =20 > Please explain. >=20 I didn't see the utility of validating it, since it is anonymous. =20 On the other hand, I don't see any harm in validating it, for consistency sake. I'm fine with deleting "or validated".=20 From pekka.nikander@nomadiclab.com Sat Sep 6 01:18:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Sat Sep 6 00:18:01 2003 Subject: [Hipsec] Updating moskowitz-hip-07: IPv4 pseudo header In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B59D2@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B59D2@xch-nw-27.nw.nos.boeing.com> Message-ID: <3F5965BE.5080304@nomadiclab.com> Henderson, Thomas R wrote: >> Well, it is not enough to tunnel just the HIP protocol >> over TCP, UDP or UDP/STUN. You must also tunnel the resulting >> ESP SAs. Therefore, I think that while such practise is probably >> valuable, it warrants a separate specification, and should not >> be included in the base spec. > > I agree about handling it in a separate spec. For the ESP tunneling, > there are already efforts in ipsec WG for tunneling through NATs-- > they may be of use. Good that we agree on a separate spec. Yes, we can probably use the IPsec WG specs, but we need to be careful with the IPR swamp there. >>On the other hand, if HIP gets commonplace, I would expect >>many NAT vendors to provide firmware updates that teach the >>NAT boxes to process the HIP packets and to set up the >>SPI mappings so that ESP works. > > Yes, but we have a chicken-and-egg problem here with the massive > NAT deployment in place. NAT is deployed in lots of products > nowadays-- some of which may not have a convenient upgrade path. Right. That's the reason why I think that we need the separate spec for making HIP to work with current NAT boxes. I don't want to sacrifice the architectural beauty in the base specifiction for making NAT traversal to work today. Thus, any volunteers for the separate UDP tunneling based NAT spec? --Pekka From pekka.nikander@nomadiclab.com Mon Sep 8 04:04:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Sep 8 03:04:00 2003 Subject: [Hipsec] Re: packet processing text In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B59D6@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B59D6@xch-nw-27.nw.nos.boeing.com> Message-ID: <3F5C2FA8.7040908@nomadiclab.com> Henderson, Thomas R wrote: >>> If the A bit is set, the Responder's HIT is >>> anonymous and should not be stored or validated against a Host >>> Identity. >> >> I don't understand why the HIT should not be validated. >> Please explain. > > I didn't see the utility of validating it, since it is anonymous. I see. We would have a problem with the later HIP messages, though. I think that there are two separate issues here: - validating that a HIT and an HI correspond to each other - validate the signatures, using a HI, in the messages If we do not check that the HITs and HIs correspond to each other, that would allow an attacker to select a HIT that matches with the HIT of some other host. However, since there is the possiblity of genuine collisions, we have to be able to handle that situation anyway. On the other hand, such a situation may trigger slow or less tested code on some implementations, and thereby add the possibility of various nasty implementation dependent attacks. Two more things are that the HITs are used in constructing the puzzle and KEYMAT construction. I don't know if either of them matter, though. What comes to the signature checks, we could run the base exchange and _not_ validate (or even use) the signatures at all. In that case we would just have a purely anonymous D-H secret. However, we do not currently really use the D-H secret in protecting the mobility management or even the NES message. Maybe we should; I've been thinking about adding an HMAC to them. The HMAC would use the HIP SA, and therefore the D-H secret. Opinions on this? Another issue is if we use anonymous HI in one end and an non-anonymous in the other one. In that case only the anonymous host is able to detect possible MitM attackers, which MAY open up some nasty DoS triangle based DoS scenarios. (I am not sure though. I haven't had a suitable amount of coffee yet to be really able to think clearly.) Yet another problem might come with session continuity. That is, if one of the end-points crashes but if they still continue to use the same HIs, the hosts might not be able to securely re-establish the session. > On the other hand, I don't see any harm in validating it, for > consistency sake. I'm fine with deleting "or validated". Given all the reasons above, I would like to fall to the safe side and remove the provision of not validating the HITs. --Pekka Nikander From andrew@indranet.co.nz Mon Sep 8 07:52:00 2003 From: andrew@indranet.co.nz (Andrew McGregor) Date: Mon Sep 8 06:52:00 2003 Subject: [Hipsec] Re: packet processing text In-Reply-To: <3F5C2FA8.7040908@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B59D6@xch-nw-27.nw.nos.boeing .com> <3F5C2FA8.7040908@nomadiclab.com> Message-ID: <19260000.1063019777@ijir> -----BEGIN PGP SIGNED MESSAGE----- - --On Monday, September 08, 2003 10:28:40 AM +0300 Pekka Nikander wrote: > What comes to the signature checks, we could run the base > exchange and _not_ validate (or even use) the signatures at > all. In that case we would just have a purely anonymous > D-H secret. However, we do not currently really use the > D-H secret in protecting the mobility management or even > the NES message. Maybe we should; I've been thinking > about adding an HMAC to them. The HMAC would use the > HIP SA, and therefore the D-H secret. > Opinions on this? I think it's a good idea; for the peer, what is the point in running a signature check in the presence of an HMAC? If we have the case where there is no forwarding agent, just two peers one of whom happens to have changed address, why not just check the HMAC and be done? We still must generate signatures, as we don't necessarily know if there is a forwarding agent (one may appear on a new path during mobility, after all), but we don't need to check them in all cases. We have to assume that the DH secret is unknown to attackers; but then, if they know that, we're pretty much done for. Andrew - -------- Andrew McGregor Director, Scientific Advisor IndraNet Technologies Ltd http://www.indranet.co.nz/ Office: +64 3 3656485 Mobile: +64 21 898856 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBP1xlBFGmVIGYWzvRAQFXLgP+NZiMqlROv2nDOF1C8hfPGBLNoD6j9zNf ClUGBIPNZHNdgTb1thAu0ImN2sQCIvlN2AOsyL8ZP37X2NWMytGyRPP6/UpXqso4 AyKIF3HqDFJJPhlKMR6JhSGoZS7Nt7Jah1vEq5j+8MUiKPdLtltRZqG3QOip72tb UEAkGyC1gRU= =TOme -----END PGP SIGNATURE----- From pekka.nikander@nomadiclab.com Mon Sep 8 08:00:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Sep 8 07:00:01 2003 Subject: [Hipsec] Re: packet processing text In-Reply-To: <19260000.1063019777@ijir> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B59D6@xch-nw-27.nw.nos.boeing .com> <3F5C2FA8.7040908@nomadiclab.com> <19260000.1063019777@ijir> Message-ID: <3F5C670F.6050009@nomadiclab.com> Andrew McGregor wrote: >> ... However, we do not currently really use the >> D-H secret in protecting the mobility management or even >> the NES message. Maybe we should; I've been thinking >> about adding an HMAC to them. The HMAC would use the >> HIP SA, and therefore the D-H secret. >> Opinions on this? > > > I think it's a good idea; for the peer, what is the point in running a > signature check in the presence of an HMAC? If we have the case where > there is no forwarding agent, just two peers one of whom happens to have > changed address, why not just check the HMAC and be done? That is the intention. > We still must generate signatures, as we don't necessarily know if > there is a forwarding agent (one may appear on a new path during > mobility, after all), but we don't need to check them in all cases. Exactly. I'll add an HMAC to REA and NES in the next versions, unless someone objects. --Pekka Nikander From pekka.nikander@nomadiclab.com Mon Sep 8 08:18:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Sep 8 07:18:01 2003 Subject: [Hipsec] (Half joke): Masquarading HIP as UDP/TCP Message-ID: <3F5C6B52.6030609@nomadiclab.com> The beginning of a UDP packet looks like the following: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source port | Destination port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | CRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The beginning of a TCP packet looks like the following: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The beginning of a HIP payload looks like the following: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Payload Len | Type | VER. | RES. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Controls | CRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The NAT boxes only touch the source port, and leave the destination port untouched. They also rewrite the checksum. According to the current spec, in an I1, Next Header = 59 Payload Len = 4 Type = 1 Ver = 1 Res = 0 If we take that, and just inject a MIP header in a place of an UDP or TCP packet, we get a packet with Source port = (256*59) + 4 = 15108 Destination port = (256*1) + 16 = 272 Now, 272 is a reserved port which happens to be unassigned.... (What comes to resetting the checksum in a TCP frame, that should be doable since the original "source port" is known and the untouched HIP CRC can be used to look for for the right original source IP address... Or otherwise we could just include the source IP address in the payload...) --Pekka From pekka.nikander@nomadiclab.com Mon Sep 8 09:06:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Sep 8 08:06:01 2003 Subject: [Hipsec] New issue 17: Unifying HIP and ESP transforms Message-ID: <3F5C767B.6010001@nomadiclab.com> In the current spec the HIP transform only specifies an encryption algorithm while the ESP transform specifies both encryption and integrity algorithms. Now, if we specify an HMAP parameter, using HIP SA keying material, we need to specify the integrity algorithm, too. To solve this, I suggest that we unify the format and ID codes for the HIP and ESP transforms. That is, R1 and I2 would continue to have both parameters, but the format and ID codes for both contents would be identical. Additionally, if HMAC is used, we need to draw the integrity keys from KEYMAT, too. I would propose that the new order would be the following: HIP initiator encryption key HIP initiator integrity key HIP responder encryption key (currently unused) HIP responder integrity key Initiator ESP key Initiator AUTH key Responder ESP key Responder AUTH key Unless there are objections, I will make this change for -08. --Pekka From pekka.nikander@nomadiclab.com Mon Sep 8 09:45:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Sep 8 08:45:01 2003 Subject: [Hipsec] HIP base exchange issues status Message-ID: <3F5C7FA9.8070609@nomadiclab.com> I thought it would be useful (at least for me) to briefly list all the issues on the base exchange spec, and their status. It also appears that I reused the numbers 10-11, and hence we have two of them. Please do send your comments on the issues that have a proposed solution. Text to the open issues would be a very nice surprise. Summary: Closed: 1, 2, 6, 7, 8, (9), 10, 11 Proposal: 4, 10a, 11a, 12, 14, 15 Open: 3, 5, 13, 16 --Pekka Nikander 1. LSI Closed: Use 1.0.0.0/8, with the low order 24 bits being from HIT, with some sort of collision detection. 2. Random SPI requirement Closed: Random SPIs are a SHOULD. 3. Unification of NES and REA packets Open. 4. Timestamps in R1 Proposal: Add HMAC to R2, thereby closing the vulnerability. 5. Rules for extensions Open. 6. Cookie function Closed: Use SHA-1 7. Optional ESP payloads Closed: Removed from base specifiation, leaving space for adding them later. 8. BOS Closed: Kept, but made completely optional. 9. Packet processing Being closed: Received initial text from Tom, adding some more of my own. 10. Fragmentation support Closed: Fragmentation mandatory for IPv4, optional for IPv6. See -07 for details. 11. Non-cryptographi HI Closed: Removed. 10a. Which pseudo header format to use for IPv4 carried HIP packets, IPv6 or IPv4 format? Proposal: Use IPv4 format. 11a. Need to define the HMAC parameter, needed for mobility Proposal: HMAC being added. 12. It looks like R2 is too weak. It should include something derived from KEYMAT, I think. Maybe a HMAC payload? This is basically the same as isssue #4, in a different disguise. Proposal: Add HMAC to R2, thereby closing the vulnerability. 13. Define how to send multiple I1s to multiple IP addresses in parallel, and rate limitations. Open. 14. Possible weakness in receiving I2s in E3 state, as discussed in a previous mail. Proposal: Add a new substate of E3 where the the host has a new KEYMAT ready to be taken into use when a new R2 is received. 15. Handling anonymous HITs in received R1 and I2. Proposal: Still check the HIT vs HI relationship even if the HIT is anonymous. 16. Details for handling of LSIs. Open. From pekka.nikander@nomadiclab.com Mon Sep 8 10:48:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Sep 8 09:48:00 2003 Subject: [Hipsec] New version of draft-moskowitz-hip, with HMAC and more packet processing text Message-ID: <3F5C8E79.4030201@nomadiclab.com> The results of today's editing are available as follows: http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep08-chbar.txt http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep08-diff.html http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep08.html http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep08.txt http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep08.xml There are four big changes from the Friday version: - the HMAC parameter is now defined, and included in R2 and NES. - the HIP transform now uses the same Suite-IDs as the ESP transform - new text to Section 8 on application data processing - new keys are drawn from the KEYMAT, to be used with HMAC Please have a look at the following sections to see if they make sense: 6.3.4 HIP_TRANSFORM 6.3.9 HMAC 7.4 R2 7.5 NES 8.1 and 8.2 for application data processing 8.7 Processing incoming R2 packets (8.8 is not updated yet) 9 KEYMAT --Pekka From Julien.Laganier@Sun.COM Fri Sep 12 14:23:00 2003 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Fri Sep 12 13:23:00 2003 Subject: [Hipsec] HIP signatures Message-ID: <200309121731.12227.julien.laganier@sun.com> Folks, Does anybody knows why authenticated HIP packet are not authenticated with a HMAC rather than signed with DSA ? (apart from R2 so the receiver sign the initiator's HIT) The keying material for HMAC can be derived from the shared secret. That would be cheaper for both nodes. Thanks, --julien From pekka.nikander@nomadiclab.com Fri Sep 12 14:44:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Sep 12 13:44:01 2003 Subject: [Hipsec] HIP signatures In-Reply-To: <200309121731.12227.julien.laganier@sun.com> References: <200309121731.12227.julien.laganier@sun.com> Message-ID: <3F620BB9.2050201@nomadiclab.com> Julien, Julien Laganier wrote: > Does anybody knows why authenticated HIP packet are not authenticated with a > HMAC rather than signed with DSA ? (apart from R2 so the receiver sign the > initiator's HIT) AFAIK, there are two reasons: - the signatures are needed anyway for middle boxes (see the architecture document) - HMACs were not historically used, perhaps just due to simplicity (I think only Bob can tell the history right) Of course, you do need the signatures in R1, I2 and, R2 anyway. The packets coming after them could have both a HMAC and a signature. Some (like AC and ACR) will do even without signatures, since they do not need to be checked by middleboxes. > The keying material for HMAC can be derived from the shared secret. That would > be cheaper for both nodes. I am working on that. See the intermediate version on my web site (URLs in recent messages, see the archive). --Pekka Nikander From pekka.nikander@nomadiclab.com Sun Sep 14 10:49:02 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Sun Sep 14 09:49:02 2003 Subject: [Hipsec] Issue 3: NES and REA Message-ID: <3F6477B1.10409@nomadiclab.com> The goal of this mail is to try to clarify the NES/REA situation. Currently I think that there are some problems, but I'd like to get comments from those that really have implemented NES (we haven't). This mail is somewhat long but an important one, that is, if we want to get the base protocol finished before Minneapolis. I think this NES thing is the largest unresolved issue in the base protocol. All of the other hard parts we have either solved or moved to separate drafts. Once you have read the mail (it will take 10 minutes at most), please answer to the following two questions. If you don't care, a personal note indicating so would be appreciated. 1. Is the new NES scheme, described at the end, acceptable? If yes, no more questions. 2. If the new scheme is not OK, please explain why, and where there is a flaw in my analysis, if any. Background example ------------------ After the base exchange, before any NES packets are sent, all keys all derived from a single piece of keying material: K1 = SHA1( g^xy | HITs | 0x01 ) K2 = SHA1( g^xy | K1 | 0x02 ) ... K = K1 | K2 | ... The ESP SAs used to send traffic between the parties, say SPI1 and SPI2, use keys derived from this keying material. Let's now assume that the first party sends a NES, thereby replacing its public Diffie-Hellman key g^x with a new key, say g^z. As a result, the second party must now generate a new piece of keying material. The first party has to have this keying material ready when it sends the NES, since it must be prepared to receive packets using this new keymat. K1' = SHA1( g^zy | HITs | 0x01 ) ... K' = K1' | K2' | .... As a result of this, the keys for the new SPI used for sending packets to the first party, SPI1', is derived from this new keymaterial, KEYMAT K'. At this point, the SPI used for sending packets to the second party remains the earlier one, SPI2, and is still based on KEYMAT K. Let's suppose further that the second party's policy states that it is also to update its Diffie-Hellman whenever it receives a new Diffie-Hellman key. It generates a new Diffie-Hellman public key, say g^t, and sends it in another NES to the first party. The first party has to generate another piece of keying material, this time using both of the new D-H keys: K1'' = SHA1(g^zt | HITs | 0x01 ) ... K'' = K1'' | K2'' | .... As a result, the first-to-second-party SPI is now SPI1', based on K', and the second-to-first-party SPI is SPI2', based on K''. Problem statement ----------------- If suspect that the following two hold. If they do not, the rest of this message is false and I must start my thinking process anew. 1. It is desirable to update the SAs in both directions so that they use keys from the same KEYMAT. 2. In the majority of cases, there will be a pair of D-H updates and not just a single one. If these hold, there are two basic variants of NES exchanges, the latter being more common than the former: Simplex NES exchange: NES including D-H -------------------------------> NES without D-H <------------------------------- Duplex NES exchange: NES including D-H -------------------------------> NES including D-H <------------------------------- NES without D-H -------------------------------> As a consequence of this setting, I see the following problems: P1. Using the current processing rules, the sender of the first NES usually needs to generate two new KEYMAT sets. It needs to generate the first set before sending the NES, using its own new D-H key and its peer's old D-H key. This must be there so that if the peer opts for the simplex exchange, the host is ready to receive packets. It needs to generate the second set after receiving the D-H containing NES from its peer. This is a performance problem. P2. It is possible that both parties become unable to receive data due to crossing NESes. Consider the following scenario, with NES packets crossing each other: ---------- ---------- \ / X / \ <--------/ \--------> In this case, both parties will consider the receives NES packets be replies to the ones they previously sent, and start sending packets with g^tz. At the same time, they will expect the peer to send packets with half-updated (g^zy or g^xt) associations, until the final NES packets without D-H arrive. According to the current rules, this will break the communications, at least temporarily. Proposal -------- I would propose that we add an acknowledgement to the NES, and make the exchange always exactly two messages long. This seems to solve the above mentioned problems. Let the ack be called NESA, and consider the following. Simplex NES exchange: Generate g^z. Do not generate KEYMAT yet. NES: SPI1', D-H (g^z) -------------------------------> Continue using SPI1. Generate KEYMAT K'. Prepare SPI2'. NESA: SPI2' <------------------------------- Generate KEYMAT K'. Prepare SPI1'. Switch over from SPI2 to SPI2'. ESP: SPI2' -------------------------------> Switch over from SPI1 to SPI1' Duplex NES exchange: Generate g^z. Do not generate KEYMAT yet. NES: SPI1', D-H (g^z) -------------------------------> Continue using SPI1. Generate g^t. Generate KEYMAT K''. Prepare SPI2'. NESA: SPI2', D-H (g^t) <------------------------------- Generate KEYMAT K''. Prepare SPI1'. Switch over from SPI2 to SPI2'. ESP: SPI2' -------------------------------> Switch over from SPI1 to SPI1'. Crossing NES exchange: Generate g^z. Generate g^t. Do not generate Do not generate KEYMAT yet. KEYMAT yet: SPI1', g^z SPI2', g^t -------------- --------------- \ / X / \ <------------/ \-------------> Continue using SPI2. Continue using SPI1. Generate KEYMAT K''. Generate KEYMAT K''. Prepare SPI1'. Prepare SPI2'. NESA: ack NESA: ack -------------- --------------- \ / X / \ <------------/ \-------------> Switch over from SPI2 Switch over from SPI1 to SPI2'. to SPI1'. Note that even if the NESAs don't cross, or if just one of them is passed, the party first receiving the NESA will swich to the new SA, and as the other one starts receiving data on it, it will switch over too. Further work ------------ Depending on the outcome of this consideration, I will continue working on unifying REA and NES. In a way, the NES acknowledgement would correspond to the current AC, and it may be possible to remove ACR. --Pekka Nikander From andrew@indranet.co.nz Sun Sep 14 22:40:02 2003 From: andrew@indranet.co.nz (Andrew McGregor) Date: Sun Sep 14 21:40:02 2003 Subject: [Hipsec] Issue 3: NES and REA In-Reply-To: <3F6477B1.10409@nomadiclab.com> References: <3F6477B1.10409@nomadiclab.com> Message-ID: <4160000.1063591491@ijir> -----BEGIN PGP SIGNED MESSAGE----- - --On Sunday, September 14, 2003 05:14:09 PM +0300 Pekka Nikander wrote: > The goal of this mail is to try to clarify the NES/REA > situation. Currently I think that there are some > problems, but I'd like to get comments from those that > really have implemented NES (we haven't). > > This mail is somewhat long but an important one, that is, > if we want to get the base protocol finished before > Minneapolis. I think this NES thing is the largest > unresolved issue in the base protocol. All of the other > hard parts we have either solved or moved to separate > drafts. > > Once you have read the mail (it will take 10 minutes > at most), please answer to the following two questions. > If you don't care, a personal note indicating so would > be appreciated. > > 1. Is the new NES scheme, described at the end, > acceptable? If yes, no more questions. It looks fine to me. > 2. If the new scheme is not OK, please explain why, > and where there is a flaw in my analysis, if any. > As a consequence of this setting, I see the > following problems: > > P1. Using the current processing rules, the > sender of the first NES usually needs > to generate two new KEYMAT sets. > > It needs to generate the first set before > sending the NES, using its own new > D-H key and its peer's old D-H key. > This must be there so that if the peer > opts for the simplex exchange, the host > is ready to receive packets. > > It needs to generate the second set after > receiving the D-H containing NES from its > peer. > > This is a performance problem. It would be, except my code doesn't do this; instead, it delays any DH work until receiving an NES, and continues to use the old SA until then, in which case it is delaying the work until it knows what to do. However... > P2. It is possible that both parties become > unable to receive data due to crossing > NESes. I had not realised why, but I have seen this happen (and the hosts recover at the next rekey where the NES did not cross). The proposal makes plenty of sense in this light. May I suggest a generic HIP ACK with a field indicating what packet type is being ACKed? So we can have ACK(AC) or ACK(NES) (or anything else that may be needed). I guess type-specific additional fields can be added if necessary. Andrew - -------- Andrew McGregor Director, Scientific Advisor IndraNet Technologies Ltd http://www.indranet.co.nz/ Office: +64 3 3656485 Mobile: +64 21 898856 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBP2UeTlGmVIGYWzvRAQEB+QP/ctC57dYBWDJv0zlgx1ZB0r77MW1Zcl02 +D7ofL+iAcqFiS/+yvKqla4Zy/P0lLjfwauehUtNn6YGmF1JiYkKLb1reeTJab7+ 2NfnRzy1bPUvx2aqgeFc9wuZSn7Tb5RW3HSVfN+lfTkbEkFWLqPqBzFXJvJMa6PY FdyacfH+GE0= =CEhi -----END PGP SIGNATURE----- From pekka.nikander@nomadiclab.com Mon Sep 15 04:42:03 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Sep 15 03:42:03 2003 Subject: [Hipsec] Issue 3: NES and REA In-Reply-To: <4160000.1063591491@ijir> References: <3F6477B1.10409@nomadiclab.com> <4160000.1063591491@ijir> Message-ID: <3F65733E.9080300@nomadiclab.com> Andrew McGregor wrote: >> 1. Is the new NES scheme, described at the end, >> acceptable? If yes, no more questions. > > It looks fine to me. Good. I am still waiting for replies from others. > May I suggest a generic HIP ACK with a field indicating what packet type is > being ACKed? So we can have ACK(AC) or ACK(NES) (or anything else that may > be needed). I guess type-specific additional fields can be added if > necessary. Well, I am planning to see if it would be possible to revise the REA procedure so that it would also consist of only two packets. If that is possible, then REA would basically be just NES + NESA, with one or more additional REA_INFO parameters. However, I haven't had time to analyse the situation, and therefore I don't have a proposal. This is also related to Issue 5: Rules for extensions. My aim is to propose a way where any packet could include additional parameters, not just NES/NESA. That would allow embedding REA_INFO also in I2 and R2, making it easier to establish the initial multihoming/mobility situation already during the base exchange. However, there are some security problems related to such practise, and I haven't had time to properly think about them yet. In this light, I don't think it would be good to have a generic ack. While such practise might be good from a basic protocol design point of view, there might be security complications. It looks like that in most cases where you would benefit from a simple ACK, you can do the same by changing your SPI and wait for data to start appearing on the new SPI. --Pekka Nikander From pekka.nikander@nomadiclab.com Mon Sep 15 06:03:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Sep 15 05:03:01 2003 Subject: [Hipsec] About identifiers, HITs, and security (was Re: A roadmap for end-point identifiers?) In-Reply-To: References: Message-ID: <3F658628.1020302@nomadiclab.com> Michel, [Sorry for the late reply. Cross-posted to HIPSEC since there is the specific question about HIT length. Please adjust your reply list.] Iljitsch van Beijnum wrote: >>> Are you saying that we should make a clear distinction between >>> identifiers and locators, and not have any values that are valid >>> in both realms? Pekka Nikander wrote: >> Yes, in the long run. > > Would that include going to identifiers that are longer than 128 > bits? [I think I answered this separately already elsewhere. Anyway.] No, just making a clear distinction does not necessarily mean that we have to go into identifiers longer than 128 bits. On the other hand, I do think that there are other reasons for going to primary identifiers that are (considerably) longer than 128 bits. > Sorry if I ask a stupid question, but the main deployment issue HIP > has is basically that every host would need an HIP stack. Yes. If HIP is a solution for something, the hosts that want to benefit from that solution have to implement HIP in their stack. On the other hand, HIP does not prevent nodes from using legacy IPv4/IPv6 in parallel with HIP. > Since there is not much you can't do about [requiring a HIP stack in > participating hosts], why haven't you pushed the reasoning further > and opted for an extended HIT that would not have some of the current > limitations (background: we did discuss the issue in Atlanta and one > of the things I recalled is that we both wished we had more bits). Yes, we discussed this in Atlanta. And yes, I think we could fairly easily go to e.g. 256 bit HITs, if desired. However, the probability of collisions with 126 bit HITs seems to be low enough so that I don't see any specific reasons to go to 256 bit HITs, at least not yet. I don't remember any more what might have been the reasons for having more bits. Could you please remind me? Anyway, this is certainly something that needs to be reconsidered if HIP ever becomes a standards track protocol. >> I do understand [the] point about the benefits of an identifier >> also being a locator, but I also believe that the benefits of clean >> separation will more than pay the drawbacks in the long run. (I >> don't have any analysis or data to support this belief, though.) > > I'd be interested in some vague rationale about this. In a separate mail (CC:d to IPv6 list only). >> Nodes with well-known addresses, such as servers and those using >> stateful configuration, are most vulnerable. Nodes that are a part >> of the network infrastructure, such as DNS servers, are >> particularly interesting targets for attackers, > > To put this in context, the paragraph above assumes that the server > is being accessed using the identifier, and that the hackers targets > the id/loc mapping mechanism in order to map the id to _his_ locs, > not the legit ones. Actually, not quite. In its most simple form, it merely states that if you know someone's address, it is easy to launch a flooding DoS attack towards that someone. On the other hand, if you don't know the address, it is much harder. But there are also other, more complex reasons buried within the sentence, if I recall correctly. And again: The potential flooding DoS attacks opened by mobility and multi-address multi-homing are much more serious than the currently possible ICMP/UDP/TCP SYN DDoS reflection attacks. Without proper protection, mobility and/or multi-address multi-homing allow an attacker to redirect whole packet streams, and even keep them running with a fairly simple bit of acknowledgement prediction. > Did I get this right? And if I did, what difference does it make if > the locators and the identifiers are segregated? If the identifiers and locators are separated, it is no longer important to defend individual IP address of *most* nodes. That is, in the most typical case you don't care what your IP address is, and if one address doesn't work, you can try to pick a new one. However, at least DNS servers (or id/loc mapping servers) would continue to need having stable IP addresses. Hence, their address would still need to be protected. Whether this really presents a difference remains to be fully analyzed. --Pekka Nikander From thomas.r.henderson@boeing.com Mon Sep 15 17:14:01 2003 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Mon Sep 15 16:14:01 2003 Subject: [Hipsec] Issue 3: NES and REA Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B5A45@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > Sent: Monday, September 15, 2003 1:07 AM > To: Andrew McGregor > Cc: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Issue 3: NES and REA >=20 >=20 > Andrew McGregor wrote: >=20 > >> 1. Is the new NES scheme, described at the end, > >> acceptable? If yes, no more questions. > >=20 > > It looks fine to me. >=20 > Good. I am still waiting for replies from others. We havent implemented NES so we can't offer insight in that regard, but your basic proposal looks fine. >=20 > > May I suggest a generic HIP ACK with a field indicating=20 > what packet type is=20 > > being ACKed? =20 >=20 I don't see much savings in having a generic ACK packet type because the = concatenation of ACK field and packet type field essentially becomes=20 a larger packet type field-- we don't have many packet types and we have fewer still that require ACKs. > In this light, I don't think it would be good to have a generic > ack. While such practise might be good from a basic protocol > design point of view, there might be security complications. > It looks like that in most cases where you would benefit from > a simple ACK, you can do the same by changing your SPI and wait > for data to start appearing on the new SPI. >=20 NES might occur asynchronously from data transfer (e.g. telnet), in which case without explicit ACK you might be hanging in an ambiguous substate for a while. From michel@arneill-py.sacramento.ca.us Tue Sep 16 01:18:01 2003 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Tue Sep 16 00:18:01 2003 Subject: [Hipsec] RE: About identifiers, HITs, and security (was Re: A roadmap for end-point identifiers?) Message-ID: Pekka, > Pekka Nikander wrote: > I don't remember any more what might have been the reasons > for having more bits. Could you please remind me? Darn, I was hoping _you_ could refresh my memory. I think that there were two things: crypto and hints about the locators. If my recollection is correct (which can be doubted) here it is: - For HIP, one of the issues you have is latency with the initial negotiation, and I think I remember you saying that you could use some extra bits to embed some crypto in order to reduce the number of round trips necessary. Or maybe that is what you wished you had if you were to apply HIP security to MHAP, can't remember. - For MHAP, there were two things I think: 1. I had wished at some point that I could embed a part of the locator's address in the identifier in order to provide enough clue to take a crapshoot at bypassing the loc/id centralized mapping. 2. We discussed CGIs and came to the conclusion that besides the Intellectual Property issues with them there was no way to make them workable with the MHAP identifier being only 128 bits. Michel. From IPV6 WG , Pekka Nikander Tue Sep 16 02:14:00 2003 From: IPV6 WG , Pekka Nikander (Pekka Nikander) Date: Tue Sep 16 01:14:00 2003 Subject: [Hipsec] What end-point identifiers are needed for? Message-ID: <3F66A227.6050809@nomadiclab.com> [Cross-posting to hipsec since this analysis seems to be important for HIP, too. CC:s appropriately, please.] The recent discussion on the ML has led me to believe that we have a fairly poor understanding on what we are speaking about. (Dave Crocker has also privately pointed this out, thereby making my mind clearer.) This is yet another strawman attempt to try to clarify the problem scope, or at least something. After some thought, I think that we have at least three main classes of needs for (loosely speaking) end-point identifiers, and some subclasses: 1) Identification 1a) identification for the purpose of mobility and multi-homing 1b) identification for the purpose of referral or rendezvous (related to 1a but slightly different) 1c) identification for other, e.g. administrative, purposes 2) Referral 3) Rendezvous 3a) initial rendezvous with no existing connection 3b) subsequent rendezvous, e.g., after concurrent movement There are probably others, but these are the ones that my poor brains managed to (small pun) identify. The *point* of this mail is that the different needs have different requirements, and that it may be very difficult or even impossible to design one class of identifiers that would fulfil all of the primary needs plus the related secondary needs, such as privacy and security. Let me try to brefly analyze the above outlined needs one by one, in reverse order. 3) Rendezvous ------------- I haven't seen any good definition for rendezvous in the meaning that we seem to be using it. (If you have, please post a reference). So, here is an attempt: End-point rendezvous refers to the situation where one end-point makes a contact with an explicitly identified other end-point over the network. To be able to perform rendezvous, the first end point seems to need - a means to identify the second end-point (1a or 1b) - a means to reach the second end-point, i.e., locator In the case of 3b), the end-points have been in contact with each other and share explicit "fresh" state. Hence, they can identify each other just based on this state, and they do not necessarily need any stable, long-living end-point identifiers. Due to mobility, they need a service that gives the currently active locator for the other end-point, i.e., the equivalent of mobile IP home agent. In the case of 3a), the end-points have not been in contact with each other, and the only "state" that they share is that the first end-point has an identifier that denotes the second one. The service giving locators does not seem to be very fast or dynamic, as long as the given locator will reach the given end-point. That is, if we have the equivalent of mobile ip home agent, the locator used for 3a) can be the equivalent of mobile ip home address. 2) Referral ----------- Again, I haven't seen any good definitions (and again, please post if you have). Another attempt: Inter-end-point referral refers to a situation where one end-point hands over information about a second end-point to a third end-point, with the purpose of allowing the third end-point to make a rendezvous with the second end-point. For referral to succeed, the transferred information must give the receiving end-point - a means to identify the second end-point (1b) - a means to reach the second end-point Note that in this case the "means to reach" does not need to be a locator. It can be a name that the rendezvous (3b) service is able to convert to a locator. 1) Identification ----------------- Now we get to the real business. Just to refresh the mind, here are again the suggested subclasses: 1a) identification for mobility and multi-homing 1b) identification for referral or rendezvous 1c) identification for other, e.g. administrative, purposes 1a) To me, identification for mobility and multi-homing seems to be the easiest one. There we are only interested in gaining assurance that the peer remains the same. That is, for the sole purpose of mobility or multi-homing, we do not really care with whom we are communicating with, but only that the peer end-point is not changed in mid-communication due to mobility, multi-homing, or attacks based on mobility or multi-homing mechanisms. [There is also the need of keeping the apparent identifier to TCP or UDP stable, but that is really a secondary need, created by the desire of backwards compatibility.] For the purposes of 1a) it seems to be sufficient to create an ephemeral identifier, only known to the participating end-points (and a sufficiently limited class of potential attackers). There is no need for long-lasting stable identifiers. Identification at the mobility related rendezvous (3b) is really a special case of the generic mobility related identification, and therefore the argumentation above holds. 1b) For initial rendezvous and referral, we need something stable. That is, we need to have an identifier that allows us to identify the peer end-point even if it does not share any state (but the identifier/identity) with us. Note that I have explicitly separated the function of locating the end-point from the function of identifying the end-point. For rendezvous and referral we naturally need both. However, they are distinct functions, and it is technically *possible* to use different tokes for these purposes. On the other hand, if there is a need for two tokens, we can also define that the end-point identifier (for referral or initial rendezvous) consists of a *pair* of tokens, ones used for identification and one used for finding the current address. 1c) The final class of needs for identification seems to have nothing to do with mobility, multi-homing or even referral or even rendezvous. There are other needs for identifying end-points: - Human GUI needs: to allow humans to type in names that refer to end-points - Various administrative needs: - configuration management - inventory management - monitoring and intrusion detection - etc. - (running out of coffee.... can't think of others) ------------------------------------------------------------- The next step is to analyse the security and privacy threats associated with all of the above mentioned needs for identifiers. However, that is a subject of another mail. --Pekka Nikander From pekka.nikander@nomadiclab.com Tue Sep 16 02:34:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Sep 16 01:34:00 2003 Subject: [Hipsec] Re: About identifiers, HITs, and security (was Re: A roadmap for end-point identifiers?) In-Reply-To: References: Message-ID: <3F66A6DB.6010007@nomadiclab.com> Michel, [Removing ipv6 from CC: list] >> I don't remember any more what might have been the reasons >> for having more bits. Could you please remind me? > > Darn, I was hoping _you_ could refresh my memory. > I think that there were two things: crypto and hints about the locators. > > If my recollection is correct (which can be doubted) here it is: > > - For HIP, one of the issues you have is latency with the initial > negotiation, and I think I remember you saying that you could use some > extra bits to embed some crypto in order to reduce the number of round > trips necessary. Or maybe that is what you wished you had if you were to > apply HIP security to MHAP, can't remember. I don't think it is possible to redure round trips in HIP base negotiation. However, I really need to read Hugo's sigma paper http://www.ee.technion.ac.il/~hugo/sigma.pdf at some point of time. > - For MHAP, there were two things I think: 1. I had wished at some point > that I could embed a part of the locator's address in the identifier in > order to provide enough clue to take a crapshoot at bypassing the loc/id > centralized mapping. 2. We discussed CGIs and came to the conclusion > that besides the Intellectual Property issues with them there was no way > to make them workable with the MHAP identifier being only 128 bits. I guess you mean CGAs. What comes to embedding locators, that would work only for a limited set of identification purposes (see my separate mail). In general, I think such embedding is a bad idea, and it would be better to use structured identifiers, i.e. pairs. I vaguely remember our discussion about CGA vs. HIP, but I don't remember any of the outcome. Sorry. --Pekka Nikander From moore@cs.utk.edu Tue Sep 16 10:48:00 2003 From: moore@cs.utk.edu (Keith Moore) Date: Tue Sep 16 09:48:00 2003 Subject: [Hipsec] Re: What end-point identifiers are needed for? In-Reply-To: <3F66A227.6050809@nomadiclab.com> References: <3F66A227.6050809@nomadiclab.com> Message-ID: <20030916100222.44a7fa95.moore@cs.utk.edu> > 1) Identification > > 1a) identification for the purpose of mobility and > multi-homing > > 1b) identification for the purpose of referral > or rendezvous (related to 1a but slightly > different) > > 1c) identification for other, e.g. administrative, > purposes > > 2) Referral > > 3) Rendezvous > > 3a) initial rendezvous with no existing connection > > 3b) subsequent rendezvous, e.g., after concurrent movement this is similar to what I had come up with. > 3) Rendezvous > ------------- > To be able to perform rendezvous, the first end point seems > to need > > - a means to identify the second end-point (1a or 1b) > - a means to reach the second end-point, i.e., locator agreed. note that currently these tend to involve the same address, which means that the distinction looks subtle. but basically you do have to do both of these things. > In the case of 3b), the end-points have been in contact > with each other and share explicit "fresh" state. Hence, > they can identify each other just based on this state, > and they do not necessarily need any stable, long-living > end-point identifiers. this would require apps to define their own unique identifiers, which is harder than it might seem at first. (they can't use an IP address since these change. they could use the MAC address of an interface but interfaces can be unplugged, etc.) > In the case of 3a), the end-points have not been in contact > with each other, and the only "state" that they share is > that the first end-point has an identifier that denotes > the second one. this is what I have been calling referral - the end point wishing to make the connection needs to talk to a specific process but hasn't made contact with it yet. > The service giving locators does not seem > to be very fast or dynamic, as long as the given locator > will reach the given end-point. this seems like a dubious assertion to me. > That is, if we have the > equivalent of mobile ip home agent, the locator used for > 3a) can be the equivalent of mobile ip home address. maybe, but it's hard to know what you mean by "equivalent" here. > 2) Referral > ----------- > > Again, I haven't seen any good definitions (and again, > please post if you have). Another attempt: > > Inter-end-point referral refers to a situation where one > end-point hands over information about a second end-point > to a third end-point, with the purpose of allowing the > third end-point to make a rendezvous with the second end-point. > > For referral to succeed, the transferred information must give > the receiving end-point > > - a means to identify the second end-point (1b) > - a means to reach the second end-point > > Note that in this case the "means to reach" does not need > to be a locator. It can be a name that the rendezvous (3b) > service is able to convert to a locator. > right. it's just like what you were calling 3b except with the added constraint that the identifiers need to have the same meaning and be resolvable to locators from any point in the network. > 1) Identification > ----------------- > > Now we get to the real business. in your way of thinking :) > Just to refresh the mind, > here are again the suggested subclasses: > > 1a) identification for mobility and multi-homing > 1b) identification for referral or rendezvous > 1c) identification for other, e.g. administrative, purposes > > 1a) To me, identification for mobility and multi-homing seems to > be the easiest one. There we are only interested in gaining > assurance that the peer remains the same. That is, for the > sole purpose of mobility or multi-homing, we do not really > care with whom we are communicating with, but only that the > peer end-point is not changed in mid-communication due to > mobility, multi-homing, or attacks based on mobility or > multi-homing mechanisms. > > [There is also the need of keeping the apparent identifier to > TCP or UDP stable, but that is really a secondary need, created > by the desire of backwards compatibility.] > > For the purposes of 1a) it seems to be sufficient to create > an ephemeral identifier, only known to the participating end-points > (and a sufficiently limited class of potential attackers). > There is no need for long-lasting stable identifiers. disagree. the problem is that you don't always know how many participating end points there will be. and an application - especially one that encompasses large numbers of hosts - can run indefinitely, meaning that the identifiers may need to last indefinitely. From andrew@indranet.co.nz Tue Sep 16 23:44:01 2003 From: andrew@indranet.co.nz (Andrew McGregor) Date: Tue Sep 16 22:44:01 2003 Subject: [Hipsec] Issue 3: NES and REA In-Reply-To: <3F65733E.9080300@nomadiclab.com> References: <3F6477B1.10409@nomadiclab.com> <4160000.1063591491@ijir> <3F65733E.9080300@nomadiclab.com> Message-ID: <5420000.1063768120@ijir> -----BEGIN PGP SIGNED MESSAGE----- - --On Monday, September 15, 2003 11:07:26 AM +0300 Pekka Nikander wrote: > Andrew McGregor wrote: > >>> 1. Is the new NES scheme, described at the end, >>> acceptable? If yes, no more questions. >> >> It looks fine to me. > > Good. I am still waiting for replies from others. > >> May I suggest a generic HIP ACK with a field indicating what packet type >> is being ACKed? So we can have ACK(AC) or ACK(NES) (or anything else >> that may be needed). I guess type-specific additional fields can be >> added if necessary. > > Well, I am planning to see if it would be possible to revise > the REA procedure so that it would also consist of only two > packets. If that is possible, then REA would basically be just > NES + NESA, with one or more additional REA_INFO parameters. > However, I haven't had time to analyse the situation, and therefore > I don't have a proposal. Well, my implementation manages to do it in two every time, except that it doesn't work in the NES packets cross case. I think if NESs have a timestamp, sequence number, or a nonce in them so we can tell that any given NES is or is not a reply to one we sent previously then we can solve this case. What I do is flag that I've sent an NES, and incoming NESs are processed slightly differently if the flag is set or not, but this doesn't work in the crossing case. By the way, it's easy to test these things; just set a short rekey timeout, and crossing can be tested by setting it the same at both ends. The window for a cross is actually quite large (a second or so, I think). > This is also related to Issue 5: Rules for extensions. > My aim is to propose a way where any packet could include > additional parameters, not just NES/NESA. That would > allow embedding REA_INFO also in I2 and R2, making it easier > to establish the initial multihoming/mobility situation > already during the base exchange. However, there are > some security problems related to such practise, and I haven't > had time to properly think about them yet. Hmm. Yes, that could be messy. > In this light, I don't think it would be good to have a generic > ack. While such practise might be good from a basic protocol > design point of view, there might be security complications. > It looks like that in most cases where you would benefit from > a simple ACK, you can do the same by changing your SPI and wait > for data to start appearing on the new SPI. Of course you can. Silly me :-) Andrew - -------- Andrew McGregor Director, Scientific Advisor IndraNet Technologies Ltd http://www.indranet.co.nz/ Office: +64 3 3656485 Mobile: +64 21 898856 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBP2fQRFGmVIGYWzvRAQFWLQQAhPvIpPyMAf5k9N1aLquy9mpMO4apbqSS pgjvqiEd1JqOhbkKAQaXED43Ex384A2tIuQcGwfCo6+HzPJ+pjEv3/3bbNsds1gX BhCdOq7WPbTaX68yMfKMCX9YOkhNT3a2GpxJCml7mujI5WYoRTE9KHF1ERm6mUIO VOxsKWeGy4I= =gr6y -----END PGP SIGNATURE----- From Erik Nordmark Wed Sep 17 00:09:00 2003 From: Erik Nordmark (Erik Nordmark) Date: Tue Sep 16 23:09:00 2003 Subject: [Hipsec] Re: What end-point identifiers are needed for? In-Reply-To: "Your message with ID" <3F66A227.6050809@nomadiclab.com> Message-ID: > For the purposes of 1a) it seems to be sufficient to create > an ephemeral identifier, only known to the participating end-points > (and a sufficiently limited class of potential attackers). > There is no need for long-lasting stable identifiers. Even if it is ephemeral you still need to be concerned about two parties, both attempting to communicate with a particular node, claiming to have the same identifier. Thus a high probability of uniqueness is a requirement. Erik From michel@arneill-py.sacramento.ca.us Wed Sep 17 00:09:02 2003 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Tue Sep 16 23:09:02 2003 Subject: [Hipsec] RE: What end-point identifiers are needed for? Message-ID: Pekka, > Pekka Nikander wrote: > 1a) To me, identification for mobility and multi-homing seems > to be the easiest one. There we are only interested in > gaining assurance that the peer remains the same. That is, > for the sole purpose of mobility or multi-homing, we do not > really care with whom we are communicating with, but only > that the peer end-point is not changed in mid-communication > due to mobility, multi-homing, or attacks based on mobility > or multi-homing mechanisms. This initially made me scream; after re-reading the text I understood the depth of it. I will point out though that I we have never inventoried a multi-homing solution that did not need referral and initial rendez-vous, which is why I wonder why you split the issue in two here. Michel. From michel@arneill-py.sacramento.ca.us Wed Sep 17 00:09:04 2003 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Tue Sep 16 23:09:04 2003 Subject: [Hipsec] RE: About identifiers, HITs, and security (was Re: A roadmap for end-point identifiers?) Message-ID: > Pekka Nikander wrote: > I don't think it is possible to redure round trips in HIP base Note that I do not intend to be negative, but this will likely be an issue with systems such as credit card transactions and other real-time on-demand transactional systems, for two reasons: 1. The bandwidth in use by the HIP base might significantly increase the aggregated bandwidth for the system. I know that we are talking about peanuts here, but peanuts multiplied by the number of credit card transactions that happen every second can amount to a very large pipe. 2. This also applies to the CPU requirements in front-end systems as well; try to project HIP to millions of 50-byte transactions. The problem of vending terminals having the brains of a bird is no longer, but is still valid on the front-end side that aggregates them. > However, I really need to read Hugo's sigma paper > http://www.ee.technion.ac.il/~hugo/sigma.pdf This doc is not available to me. > I guess you mean CGAs. Thanks for correcting me. I was thinking about Cryptographically Generated Indentifiers :-) Michel. From pekka.nikander@nomadiclab.com Wed Sep 17 01:22:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Sep 17 00:22:00 2003 Subject: [Hipsec] Re: About identifiers, HITs, and security (was Re: A roadmap for end-point identifiers?) In-Reply-To: References: Message-ID: <3F67E77D.4030001@nomadiclab.com> Pekka Nikander wrote: >>I don't think it is possible to redure round trips in HIP base Michel Py wrote: > Note that I do not intend to be negative, but this will likely be an > issue with systems such as credit card transactions and other real-time > on-demand transactional systems, for two reasons: Thanks for point this out. It may be that we need to think about this more. It has been clear from the very beginning that you can't apply HIP to DNS transactions. In general, HIP is good only when you need to have network level identification, for whatever reason. In most transaction systems you don't seem to care about the network level identities. The application level identities do matter, of course, but HIP does not (necessarily) address them. On the other hand, if you need to do transactions repeatedly with the same party, you can have a long lasting HIP SA pair, and use it repeatedly without almost any penalty. >> However, I really need to read Hugo's sigma paper >> http://www.ee.technion.ac.il/~hugo/sigma.pdf > > This doc is not available to me. Seems to be available as postscript: http://www.ee.technion.ac.il/~hugo/sigma.ps --Pekka From Dave Crocker Wed Sep 17 02:27:01 2003 From: Dave Crocker (Dave Crocker) Date: Wed Sep 17 01:27:01 2003 Subject: [Hipsec] Re: What end-point identifiers are needed for? In-Reply-To: <3F66A227.6050809@nomadiclab.com> References: <3F66A227.6050809@nomadiclab.com> Message-ID: <66100493311.20030916225146@brandenburg.com> Folks, PN> [Cross-posting to hipsec since this analysis seems to PN> be important for HIP, too. CC:s appropriately, please.] I have to admit to being pretty confused about choosing the right venue for the various discussion going on. Absent better guidance, I am pointing mobility/multihoming discussions to multi6. I just sent that list the following announcement, which includes an I-D that discusses choices including endpoint identifier. Hence, it tries to go through some of the exercise in Pekka's query. - - - - - I've just submitted some new mobility/multihoming I-Ds for distribution. Meanwhile, they are available from my website, in text and MS Word formats. The first breaks out the "discussion" section of the original MAST paper and expands on it: Choices for Support of Multiaddressing Text: MSWord : The second is the revised draft proposal: Multiple Address Service For Transport (MAST): An Extended Proposal Text: MSWord: d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From michel@arneill-py.sacramento.ca.us Wed Sep 17 12:32:01 2003 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Wed Sep 17 11:32:01 2003 Subject: [Hipsec] RE: About identifiers, HITs, and security (was Re: A roadmap for end-point identifiers?) Message-ID: Pekka, >> Michel Py wrote: >> Note that I do not intend to be negative, but this will likely be >> an issue with systems such as credit card transactions and other >> real-time on-demand transactional systems, for two reasons: > Pekka Nikander wrote: > Thanks for point this out. It may be that we need to think > about this more. It has been clear from the very beginning > that you can't apply HIP to DNS transactions. At the risk of sounding negative again: (I can hear it already: who's this jerk that never contributed anything significant to HIP that comes posting telling us what we screwed up :-) This is an issue you might have to address. What follows is mostly sales/marketing droid BS, but you do have to think about it. When you look where HIP stands on the map of multihoming solutions, your strong point is that you have the best security and your weak point is that you have a deployment problem that can be solved only by some large organizations adopting HIP to give it a shot in the arm. The best target for adoption you have are "secure" transactional systems, both because of the high availability aspect of multihoming (if the credit card system is not working, you're just flushing money in the toilet) and because of the security requirements associated with financial transactions. Without breaking NDA I can tell you that a significant number of them are based on very short transactions. Today, one of the leading issues is modem training: it can take more than 60 seconds to train a modem to connect at 56k and it takes way less than one second to transmit the mighty 16-digit credit card number. Which is why you will find number of dial pools for credit card train only at 2400 baud. And yes it is in the year 2003; saving 40 seconds on modem training offsets by two orders of magnitude the time it takes to push a few bytes over the line at 2400 baud compared to the time it takes to push the same few bytes at 49,999. Been there, done that. One day, all of these credit card gizmos will use IPv6 over {broadband|wireless|foo} instead of using a dedicated copper pair; when that day comes, if it takes 20kByte of HIP overhead to push 50 bytes of data, you do have a problem. Again, this is not an anti-HIP rant; just trying to give you a taste of what's ahead. Michel. From shep@alum.mit.edu Wed Sep 17 13:19:01 2003 From: shep@alum.mit.edu (Tim Shepard) Date: Wed Sep 17 12:19:01 2003 Subject: [Hipsec] RE: About identifiers, HITs, and security (was Re: A roadmap for end-point identifiers?) In-Reply-To: Your message of Wed, 17 Sep 2003 08:45:02 -0700. Message-ID: <200309171636.h8HGa2cT021781@ginger.lcs.mit.edu> > The best target for adoption you have are "secure" transactional > systems, both because of the high availability aspect of multihoming (if > the credit card system is not working, you're just flushing money in the > toilet) and because of the security requirements associated with > financial transactions. I do not imagine that everything will use HIP. I have thought (since this idea was planted in my head by Steve Bellovin when spoke at the microphone at the HIPSEC BOF at the London IETF) that the best path for adoption for HIPSEC is along a path similar to the path that ssh took. My favorite target for adoption is personal: I imagine that with my HIP-enabled notebook computer and the various HIP-enabled servers that I depend upon, I'll be able to suspend-to-disk my notebook, hop on a plane to IETF, resume my notebook, and TCP connections will still be open and functional, even if my connectivity was IPv6-only at home and IPv4-only at the meeting (or vice versa). (I know this will also require some tweaking to improve the persistence of TCP on many operating systems.) If HIP ever becomes as popular as ssh, I think that would be a big success. I don't know if that will happen. I think HIP has potential to be much more widely used than ssh will ever be (since ssh is mostly used as a remote system administration tool as far as I can tell). > Without breaking NDA I can tell you that a significant number of them > are based on very short transactions. Today, one of the leading issues > is modem training: it can take more than 60 seconds to train a modem to > connect at 56k and it takes way less than one second to transmit the > mighty 16-digit credit card number. Which is why you will find number of > dial pools for credit card train only at 2400 baud. And yes it is in the > year 2003; saving 40 seconds on modem training offsets by two orders of > magnitude the time it takes to push a few bytes over the line at 2400 > baud compared to the time it takes to push the same few bytes at 49,999. > Been there, done that. > > One day, all of these credit card gizmos will use IPv6 over > {broadband|wireless|foo} instead of using a dedicated copper pair; when > that day comes, if it takes 20kByte of HIP overhead to push 50 bytes of > data, you do have a problem. Well, what exactly do you think is the competitor to HIP for this story? IKE? In either case, a per-transaction key exchange would be silly. If its going to run over IPSEC transport (ESP of some flavor) then I expect that longer-term associations will be held. I don't see how this scenario is a challange to HIP any more than it is a challenge to IPSEC in general (IKE in particular). HIP, if it catches on, will be one more tool in the tool box. There will still be work to do in designing a credit card verification system like you described. -Tim Shepard shep@alum.mit.edu From andrew@indranet.co.nz Wed Sep 17 18:34:01 2003 From: andrew@indranet.co.nz (Andrew McGregor) Date: Wed Sep 17 17:34:01 2003 Subject: [Hipsec] RE: About identifiers, HITs, and security (was Re: A roadmap for end-point identifiers?) In-Reply-To: <200309171636.h8HGa2cT021781@ginger.lcs.mit.edu> References: <200309171636.h8HGa2cT021781@ginger.lcs.mit.edu> Message-ID: <91700000.1063835964@ijir> -----BEGIN PGP SIGNED MESSAGE----- - --On Wednesday, September 17, 2003 12:36:01 PM -0400 Tim Shepard wrote: > >> The best target for adoption you have are "secure" transactional >> systems, both because of the high availability aspect of multihoming (if >> the credit card system is not working, you're just flushing money in the >> toilet) and because of the security requirements associated with >> financial transactions. Possibly, possibly not. I have an application in power grid management, where the mobility is important as well as the availability. HIP is at least as applicable as any other way of initialising ESP, and, imho, more so than most. > I do not imagine that everything will use HIP. > > I have thought (since this idea was planted in my head by Steve > Bellovin when spoke at the microphone at the HIPSEC BOF at the London > IETF) that the best path for adoption for HIPSEC is along a path > similar to the path that ssh took. > > My favorite target for adoption is personal: I imagine that with my > HIP-enabled notebook computer and the various HIP-enabled servers that > I depend upon, I'll be able to suspend-to-disk my notebook, hop on a > plane to IETF, resume my notebook, and TCP connections will still be > open and functional, even if my connectivity was IPv6-only at home and > IPv4-only at the meeting (or vice versa). (I know this will > also require some tweaking to improve the persistence of TCP on many > operating systems.) Well, I doubt it would cope with my IETF flights, but even just coping with the drive home from the office would be good. > If HIP ever becomes as popular as ssh, I think that would be a big > success. I don't know if that will happen. I think HIP has potential > to be much more widely used than ssh will ever be (since ssh is mostly > used as a remote system administration tool as far as I can tell). Well, many folks like to use ssh as a VPN, since often they have situations that don't suit IPSEC or they can't be bothered with the pain (sticks own hand in the air; damn NAT). We use ssh that way, and every user who reads mail from offsite uses it (via the Windows SFTP client), even though most of them have no clue how to use a unix command line; and in fact we don't even give them a shell. >> One day, all of these credit card gizmos will use IPv6 over >> {broadband|wireless|foo} instead of using a dedicated copper pair; when >> that day comes, if it takes 20kByte of HIP overhead to push 50 bytes of >> data, you do have a problem. Actually, it's about 2k, including IPv6 headers. > Well, what exactly do you think is the competitor to HIP for this story? > IKE? > > In either case, a per-transaction key exchange would be silly. If its > going to run over IPSEC transport (ESP of some flavor) then I expect > that longer-term associations will be held. I don't see how this > scenario is a challange to HIP any more than it is a challenge to > IPSEC in general (IKE in particular). In this country, most credit/debit card authorisation machines are permanently connected; the operator signs them on once per day (and each time the connection drops, but that's rare) and logs off at closing time. (People actually get a little irritated with the dial-on-demand sort.) This is exactly analogous to holding a HIP session open all day, for exactly that same application. Andrew - -------- Andrew McGregor Director, Scientific Advisor IndraNet Technologies Ltd http://www.indranet.co.nz/ Office: +64 3 3656485 Mobile: +64 21 898856 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBP2jZQFGmVIGYWzvRAQFUgQP/cfe4qFVh9cCJeUNcfm148QqiEwzaMX7J IHUGL8ng57BCPqQddGhOC2NoD437MEeQ8lnwKigsDRRBFBuCK1fbaEXmUHQ8JUEB yaEIVfscFNLU16qh3R8biye/BHHX22Yydmb+X2dbf3ExxDKJl7GxN4AJpjb8lMvA rBeBmTkBlmw= =g4Nx -----END PGP SIGNATURE----- From rgm@htt-consult.com Wed Sep 17 18:53:01 2003 From: rgm@htt-consult.com (Robert Moskowitz) Date: Wed Sep 17 17:53:01 2003 Subject: [Hipsec] Sorry I have been sooooo out of this discussion Message-ID: <5.1.0.14.2.20030917181328.030f7ad8@localhost> Struggling with a number of 802.11 and 802.1X items. Touches on EAP and AAA. Sigh. Playing around with an IBE encryption for DSRC (wireless between cars moving at 80mph) where there is NO time for ANY latency or extra exchanges. Basically you either: Pay for protection with an exchange that is at least 4 packets. Can't do it safely in 3. Give up on protection and use weak address bindings (what we have today). Go with an EC-based IBE scheme and accept the intendent risks (in one case, the system that generated the parameters is a defacto key escrow server). now back to how to attack the PSK in WPA..... From michel@arneill-py.sacramento.ca.us Thu Sep 18 15:08:01 2003 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Thu Sep 18 14:08:01 2003 Subject: [Hipsec] RE: About identifiers, HITs, and security (was Re: A roadmap for end-point identifiers?) Message-ID: > Tim Shepard wrote: > I do not imagine that everything will use HIP. I have met with very enthusiastic supporters of HIP that seem to think quite the opposite :-) >> One day, all of these credit card gizmos will use IPv6 over >> {broadband|wireless|foo} instead of using a dedicated copper pair; >> when that day comes, if it takes 20kByte of HIP overhead to push >> 50 bytes of data, you do have a problem. > Well, what exactly do you think is the competitor to HIP for this > story? IKE? No. I'm not even saying there is even a competitor at this point; I was simply trying to suggest that there is room for improvement in some domains. Michel. From pekka.nikander@nomadiclab.com Fri Sep 19 03:39:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Sep 19 02:39:00 2003 Subject: [Hipsec] Towards a HIP BOF / WG Message-ID: <3F6AAA93.4050003@nomadiclab.com> Folks, I had a chance to briefly discuss the possibility of the proposed HIP WG and BOF with the Internet Area ADs, Thomas Narten and Margaret Wasserman, earlier this week. The discussion took place after another conference call, and we didn't have time to go into any specifics. Anyway, if I understood correctly what Thomas and Margaret said, they have basically no problems with an approach that would produce documents that a) specify the interconnections HIP has with the rest of the current IP infrastructure, i.e. IPsec, DNS, and NAT, and b) specify the required new infrastructure (rendezvous servers) that HIP needs. The fact that there have been two BOFs two years ago is a technicality that can be overruled, based on the fact that the situation has considerably changed. HIP is now close to start being experimentally deployed, and it needs the details for the infrastructure support. (Back two years ago people were still being developing the details of the basic protocol, and there were no implementations.) While it is unusual to charter a working group whose goal is to produce experimental documents, that should not be a show stopper, either. On the other hand, Thomas said that it is good that people a honest with the maturity level of the proposed technology. The next step is that I will produce a formal BOF proposal to Thomas and Margaret. For that, we need a detailed BOF description, agenda, and names for the BOF chairs. Already during the Vienna meeting I drafted a charter proposal. I will post it and my proposal for the BOF agenda, separately on the list. --Pekka Nikander From pekka.nikander@nomadiclab.com Fri Sep 19 04:11:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Sep 19 03:11:00 2003 Subject: [Hipsec] A HIP WG charter proposal Message-ID: <3F6AB21C.50605@nomadiclab.com> Folks, Please find below my initial charter proposal for a HIP WG. I wish that we would have a lively discussion on the list, and consider alternativities. On the other hand, I hope that people remain as civilized as they always have been on this list, and that all expressed opinions are well backed with clearly explained thoughts. In particular, I think that is debatable whether the WG should try to standardize any changes to the IPsec ESP, as the charter proposes. --Pekka Nikander Host Identity Protocol (HIP) Chair(s): TBD. Internet Area Director(s): Thomas Narten Margaret Wasserman Internet Area Advisor: TBD. Security Area Liason: TBD. Mailing Lists: Send mail to: hipsec-request@honor.trusecure.com With a subject line: subscribe List archive: http://honor.trusecure.com/pipermail/hipsec/ (This is a new list that has replaced the old list hosted at lists.freeswan.org. It was necessary to move to a new list due to technical problems with the old one.) Description of Working Group: Host Identity Protocol (HIP) proposes a solution for separating the end-point identifier and locator roles of IP addresses. It introduces a new Host Identity (HI) name space, based on self generated public keys. In particular, it specifies a protocol to permit IPv6 and IPv4 hosts to identify each other based on the public keys, to establish a pair of host-to-host ESP security associations using these public keys, and to run both IPv4 and IPv6 applications side-by-side independent of the underlying type of connectivity. It also allows many IPv4 applications to communicate directly with IPv6 applications, and vice versa. The specifications for the architecture and protocol details for these mechanisms consist of: draft-moskowitz-hip-arch-03.txt and draft-moskowitz-hip-07.txt (soon -08.txt) Both of these documents are relatively mature, and planned to be fairly soon submitted to the IESG for consideration as Experimental RFCs. There are four existing, interoperating implementations, some of which are open source. Currently, the HIP base protocol works well with any pair of co-operating end-hosts. However, to be more useful and more widely deployable, HIP needs some support from the existing infrastructure and a new piece of infrastructure, called the HIP rendezvous server of the HIP proxy. +-------------------------------------------------------------+ | The purpose of this Working Group is to define the required | | infrastructure elements that are needed for HIP to be | | experimented in a wide scale. | +-------------------------------------------------------------+ In particular, the objective of this working group is to complete the DNS, mobility, multi-homing, and NAT traversal work on HIP, and produce Experimental RFCs for these. If necessary, the WG can also revise the base HIP protocol specification, but only if the changes do not substantically increase the complexity of the base protocol. Additionally, the working group aims to standardize, together with the IPsec Working Group, the necessary hooks that would allow HIP to utilize unmodified IPsec ESP. One particular way of implementing the small changes required to IPsec ESP has been defined in a separate draft: draft-nikander-esp-beet-mode-00.txt (to be issued) The following are charter items for the working group: 0) If the architecture and base protocol specifications have not been submitted to the IESG by the time the WG is formally created, complete the specifications and submit them to the IESG. 1) Complete the basic mobility and multi-homing support for HIP. This work will use draft-nikander-hip-mm-00.txt as a starting point. While this work partially overlaps the work in Mobile IP and Multi6 Working Groups, it is very different in the sense that is based on the Experimental HIP specification, and cannot function without it. 2) Define DNS interactions, including how to store HIP Host Identifiers into the DNS. 3) Define NAT traversal for HIP. The NAT traversal must work with mobile and multi-homed HIP hosts. The mechanism MAY require changes to existing NAT boxes. 4) Define a HIP rendezvous and proxy mechanism. A HIP rendezvous mechanism is needed to provide initial connectivity with fast moving HIP hosts, and to allow simultaneously moving hosts to find each other after con-current movements. Additionally, HIP hosts are currently able to talk talk to non-HIP hosts using standard IPv6 or IPv4, including MIPv6 or MIPv4. However, if they do so, the HIP hosts do not benefit from the mobility and multi-homing aspects of HIP. A proxy would allow a HIP host to talk to a non-HIP host, but still use HIP mobility. 5) Optionally, define a mechanism that allows any Host Identifier to be as a seach key to find a DNS name and/or an IP address. Such a mechanism could be based on Distributed Hash Tables. 6) If needed to complete any of the items above, revise the base protocol specification. If any such revisions are needed, care must be taken not to unnecessarily increase the complexity of the base protocol. The Working Group bases all the work on the base HIP protocol specifications (as defined above). Specifically out of scope is comparison of HIP to existing or other proposed IP based mobility, multi-homing, security, or NAT traversal solutions. This does *not* mean that such comparison should not be made (indeed, such comparisons would be very valuable), but that they are out of the scope of the working group, and should not be discussed at the working group mailing list. Announcements of any completed works in those areas are acceptable. Goals and Milestones: Nov 03 Complete draft-moskowitz-hip-arch and draft-moskowitz-hip and submit them to the IESG to be considered as Experimental. Nov 03 First version of draft-ietf-hip-mm-00.txt, using draft-nikander-hip-mm-00.txt as a starting point. Nov 03 First version of draft-ietf-hip-esp-beet-00.txt, using draft-nikander-esp-beet-mode-00.txt as a starting point. Dec 03 First version of draft-ietf-hip-dns-00.txt. Jan 04 First version of draft-ietf-hip-nat-00.txt. Jan 04 Combined HIP and IPsec WG LC on draft-ietf-hip-esp-beet-XX.txt Feb 04 First version of draft-ietf-hip-rendezvous-00.txt Mar 04 Submit draft-ietf-hip-esp-beet-XX.txt to the IESG for Standards Track. Mar 04 WG LC on draft-ietf-hip-dns-XX.txt. Apr 04 WG LC on draft-ietf-hip-mm-XX.txt and draft-ietf-hip-nat-XX.txt. May 04 Submit draft-ietf-hip-dns-XX.txt to IESG for Experimental. Jun 04 Submit draft-ietf-hip-mm-XX.txt and draft-ietf-hip-nat-XX.txt to IESG for Experimental. Jul 04 WC LC on draft-ietf-hip-rendezvous-XX.txt. Sep 04 Submit draft-ietf-hip-rendezvous-XX.txt to IESG for Experimental. Nov 04 Close or recharter the WG. Current Internet-Drafts: draft-moskowitz-hip-arch-03.txt draft-moskowitz-hip-07.txt draft-nikander-hip-mm-00.txt Proposed new WG items: draft-ietf-hip-mm-XX.txt draft-ietf-hip-esp-beet-XX.txt draft-ietf-hip-dns-XX.txt draft-ietf-hip-nat-XX.txt draft-ietf-hip-rendezvous-XX.txt From hipsec@honor.trusecure.com Fri Sep 19 04:24:00 2003 From: hipsec@honor.trusecure.com (Pekka Nikander) Date: Fri Sep 19 03:24:00 2003 Subject: [Hipsec] Renewed HIP mailing list & BOF and WG proposals Message-ID: <3F6AB53D.8010005@nomadiclab.com> [Aplogies for cross-posting] Folks, The Host Identity Protocol (HIP) mailing list was restored in July at @honor.trusecure.com. The mailing list existed previously @lists.freeswan.org, but there were some technical problems which necessitated the move of the mailing list. We have now started a discussion on a possible HIP BOF and WG. If you want to participate to the discussion, join the mailing list. However, before doing so, please read the archives, at least the most recent ones. The archive is available at http://honor.trusecure.com/pipermail/hipsec/ The most important messages at this point, related to the WG proposal, are the following: http://honor.trusecure.com/pipermail/hipsec/2003-July/000004.html http://honor.trusecure.com/pipermail/hipsec/2003-September/000070.html http://honor.trusecure.com/pipermail/hipsec/2003-September/000071.html Subscription information is available at: http://honor.trusecure.com/mailman/listinfo/hipsec --Pekka Nikander From swb@employees.org Sun Sep 21 12:33:01 2003 From: swb@employees.org (Scott W Brim) Date: Sun Sep 21 11:33:01 2003 Subject: [Hipsec] A HIP WG charter proposal In-Reply-To: <3F6AB21C.50605@nomadiclab.com> References: <3F6AB21C.50605@nomadiclab.com> Message-ID: <20030921155847.GA2748@sbrim-w2k01> On Fri, Sep 19, 2003 10:37:00AM +0300, Pekka Nikander allegedly wrote: > Additionally, the working group aims to standardize, together > with the IPsec Working Group, the necessary hooks that would > allow HIP to utilize unmodified IPsec ESP. One particular way of > implementing the small changes required to IPsec ESP has been > defined in a separate draft: > > draft-nikander-esp-beet-mode-00.txt (to be issued) I would not put this in. It's a good idea, but putting it in the charter creates a dependency on another working group, and expands the potential scope to the point where arguments about scope might lead to nothing ever happening. Revise the charter to add it later, if we're successful with the main tasks. ..swb From pekka.nikander@nomadiclab.com Tue Sep 23 11:20:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Sep 23 10:20:01 2003 Subject: [Hipsec] A HIP WG charter proposal In-Reply-To: <20030921155847.GA2748@sbrim-w2k01> References: <3F6AB21C.50605@nomadiclab.com> <20030921155847.GA2748@sbrim-w2k01> Message-ID: <3F705CB9.7020502@nomadiclab.com> Scott W Brim wrote: >> Additionally, the working group aims to standardize, together >> with the IPsec Working Group, the necessary hooks that would >> allow HIP to utilize unmodified IPsec ESP. One particular way of >> implementing the small changes required to IPsec ESP has been >> defined in a separate draft: >> >> draft-nikander-esp-beet-mode-00.txt (to be issued) > > I would not put this in. It's a good idea, but putting it in the > charter creates a dependency on another working group, and expands the > potential scope to the point where arguments about scope might lead to > nothing ever happening. Revise the charter to add it later, if we're > successful with the main tasks. Well, if we could get a small change in to ESP, it would be possible to implement HIP completely in the user level, and use kernel level ESP. As the state is now, it is possible to implement HIP in the user level, but it requires a user level ESP implementation as well. In a host that supports IPsec, this results in two different ESP implementations User level ESP also requires that all packets flow through the user space, while one integrated with kernel level ESP allows the packets to be processed in kernel up to the API level. Another difference would be in host protection. The functionality proposed in the draft could also be implemented without modifying ESP, using an other kernel component. A hostNAT (a la Bellovin), if you will. However, such a two-part implementation would be harder to configure, leading to easier and probably more common configuration mistakes. Hence, from an implementation, performance, and security point of view, the proposed small change to ESP would be very good. The draft is also written to be more generic, and not solely HIP specific. I believe that it would be good for Mobile IP, too. An early version of the draft is available at http://www.tml.hut.fi/~pnr/BEET/draft-nikander-esp-beet-mode-00.txt I will submit it as soon as I get an initial version of the security considerations section written, basically pointing out the problems with a two element configuration vs. integrated implementation configuration. --Pekka From mcr@sandelman.ottawa.on.ca Tue Sep 23 11:48:01 2003 From: mcr@sandelman.ottawa.on.ca (Michael Richardson) Date: Tue Sep 23 10:48:01 2003 Subject: [Hipsec] A HIP WG charter proposal In-Reply-To: Your message of "Tue, 23 Sep 2003 16:46:17 +0200." <3F705CB9.7020502@nomadiclab.com> Message-ID: <23663.1064329829@marajade.sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- I read beet mode awhile ago. It seems that beet mode is a new kind of tunnel mode, and the FreeS/WAN effort would be supportive of it. It should be easy to negotiate in IKE (even v1), and shouldn't really be that hard to code. As I understand it, but maybe I'm wrong, beet mode can be replaced with tunnel mode, but there are packet size and PMTU issues that come up. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP3BiZIqHRg3pndX9AQFWvQQAnNnAG3BwvcqWQ9zBnGMsz+BQioopWFRr TWWSrZs7jTnAsJcQ40YSt166qH/a3JzQ6GGeqm4zXCYXpUsgX2xbFR5LvHNO2kpE kUJ0otf7ncwfJSkqwxO4TnL9OOWaItT9ug4j1ZVNlnAGKGvicc77ASst7I+t9J+d BX2+Drizmms= =PP4H -----END PGP SIGNATURE----- From pekka.nikander@nomadiclab.com Wed Sep 24 03:53:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Sep 24 02:53:00 2003 Subject: [Hipsec] Re: What end-point identifiers are needed for? In-Reply-To: <20030916100222.44a7fa95.moore@cs.utk.edu> References: <3F66A227.6050809@nomadiclab.com> <20030916100222.44a7fa95.moore@cs.utk.edu> Message-ID: <3F707F7A.3000702@nomadiclab.com> Keith, [Sorry for late reply.] >> 2) Referral >> For referral to succeed, the transferred information must give >> the receiving end-point >> >> - a means to identify the second end-point (1b) >> - a means to reach the second end-point >> >> Note that in this case the "means to reach" does not need >> to be a locator. It can be a name that the rendezvous (3b) >> service is able to convert to a locator. > > right. it's just like what you were calling 3b except with the added > constraint that the identifiers need to have the same meaning and be > resolvable to locators from any point in the network. Thanks for this clarification. It made my thinking more crystal. >> 1a) To me, identification for mobility and multi-homing seems to >> be the easiest one. There we are only interested in gaining >> assurance that the peer remains the same. That is, for the >> sole purpose of mobility or multi-homing, we do not really >> care with whom we are communicating with, but only that the >> peer end-point is not changed in mid-communication due to >> mobility, multi-homing, or attacks based on mobility or >> multi-homing mechanisms. >> >> For the purposes of 1a) it seems to be sufficient to create >> an ephemeral identifier, only known to the participating end-points >> (and a sufficiently limited class of potential attackers). >> There is no need for long-lasting stable identifiers. > > disagree. the problem is that you don't always know how many participating > end points there will be. and an application - especially one that encompasses > large numbers of hosts - can run indefinitely, meaning that the identifiers > may need to last indefinitely. Well, I think that you are slightly mixing things here. While I agree with you than in most real life situations you most probably would not be done with ephemeral identifiers, the reason for that is that such situations involve other needs but pure mobility or multi-homing (multi-addressing in Dave Croker's terminology). ' If your application encompasses more than two hosts, either they talk pairwise (in which case my statement holds), or they make referrals (in which case the reason for identification is not pure mobility or multi-homing any more). If your application encompasses only two hosts, but lasts "indefinitely", then the "ephemeral" identifier can last "indefinitely". If picked from a large enough space, the chance of collisions is still neglible enough. (We have to remember that "indefinitely" in our field appears to be around 50 years, at most 200 I guess.) Besides, if you application runs that long, then you most probably also need occasional rendezvous, again imposing other reasons (and other requirements) for identification but pure mobility and multi-homing. --Pekka Nikander From pekka.nikander@nomadiclab.com Wed Sep 24 04:23:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Sep 24 03:23:00 2003 Subject: [Hipsec] Security requirements for identification Message-ID: <3F714C8E.4070205@nomadiclab.com> In my previous message (to hipsec&ipv6 ml) I proposed dividing identification to the following three subcategories: a) identification in mobility and multi-homing b) identification in referral or rendezvous c) identification in other, e.g. administrative, contexts I also discussed rendezvous and referral, in order to make the point that identifying a node and locating it are really two distinct functions. The previous message is available at http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg00056.html In this message I will try to analyze the security requirements for identification in the sense of a) and b). Analyzing c) in isolation does not make any sense, since the security requirements depend on the context. In the end of this message, I try to give some conclusions based on the analysis; if you are busy, you may want to see the conclusions first. I am focusing here solely on the identification function, and not touching the security requirements of the location function. It should be noted, however, that these two are related in real life. Analyzing that is for another message. a) identification for mobility and multi-homing ----------------------------------------------- As I wrote earlier, here we are only interested in gaining assurance that the peer remains the *same*. That is, we do not really care *whom* we are communicating with, but only that the peer end-point is not changed in mid- communication. (We probably did care the "real identity" of the peer when we first initiated the communication, but that is a different issue, with different security requirements.) There are two basic dangers related identification in mobility and multi-homing. One is connection hijacking, i.e., somebody "stealing" the connection and replacing one of the peers without being noticed. The other, less obvious one, is flooding. Flooding is an attack where a genuine peer lies about its location(s), with the purpose of choking a victim on excess traffic. That is, the attacker claims to move/be better reachable at the location of a victim, thereby directing the traffic to the victim. Flooding is a serious attack since the amounts of redirected traffic can be large. Consider a public streaming server. Anyone can make a connection to it, and start downloading a stream. For the stream to run, acknowledgments must be sent back. This is easy, since an attacker can open a stream, redirect the stream (using some mobility or multi-homing mechanism) to a victim address, and *continue* sending acknowledgments. Anticipating when and what kinds of acks to send is easy enough. This makes the stream running independent on the actions by the poor victim. Hence, for the purpose of mobility and multi-homing, the identification mechanism has to keep sure that the peer really remains the same, on all changes of locators. Furthermore, the mechanism must not blindly trust what the peer claims about its locations, but must check that the same peer really *is* at all the claimed addresses. If we really do not care who the initial peer really is, then a simple protocol is sufficient; the protocol first creates a shared secret between the peers and then uses the secret to verify persistence of the identity. The protocol may even be vulnerable to MitM attackers in its initialization state; our requirement states that a MitM attacker is equally good to the "real" intended peer, since we don't care about the "real identity". The requirements can be summarized as follows: R1. Verification that the peer is the same one after all changes of locators. R2. Verification that the same peer is reachable at all claimed (and used) locations. The MIPv6 RR protocol is a (somewhat convoluted) example of a protocol fulfilling the requirements. (It also fulfills other, Mobile IPv6 specific security requirements.) b) identification for referral or rendezvous -------------------------------------------- In the case of referral or rendezvous, an initiating party possesses an identifier that it wants to use as a means of identifying another party. The target party may have no idea of the intentions of the first party, and it may have never met the first party. In other words, the parties do not share any state but the identifier itself and any state in the target party that is associated with the identifier. From a security point of view, the requirement is that the party that responds to a communication request really is the party denoted by the identifier, and someone else. That is, the requirement is that the target party really is the intended target party. If we assumed that everybody is honest, any unique bit string would serve well as an identifier. The initiating party just sends the bit string to the target party, and asks the target party to verify that the bit string really is its identifier. The problem is that we cannot necessarily assume everybody to be honest. If we assume dishonest parties, we get two sub cases. In the first case, the initiating party must send the identifier in clear, for some reason, or the identifier is otherwise public and known by the dishonest parties. In the second case, the initiating party is able to keep the identifier in secret. In the first case, the only secure way of performing identification seem to be public key cryptography (or any of its variants, like zero knowledge protocol). The reason for this is the following. Since the identifier is public knowledge, we cannot use the identifier directly. Instead, there must be some secret that only the right party knows and is able to prove to know. The identifier and the secret must be linked. Only public key crypto (or a variant) seems to fulfill these requirements. The second case is more interesting, since it allows for some simple cryptographic protocols that show to the target party that the initiating party knows its secret identifier without revealing it, and where the target party is conversely able to show to the initiator that it also knows the secret identifier. In effect, in this case the identifier is a shared secret. However, it is also almost completely impractical, since one cannot share such a secret with anyone, nor put it into a public directory. (There are some special cases where this kind of identification may be useful, but one cannot build a generic Internet wide architecture on such assumptions.) Hence, if we want to do referral and rendezvous in a secure way, we seem to need public keys as identifiers. It looks best to use public keys as primary identifiers. It is also possible to use public keys only as secondary identifiers, and bind them to some primary identifiers, but that costs more since it requires a PKI. Using public keys directly as primary identifiers does not, as such, require a PKI. To summarize, the requirement is R3. Verification that the target party really is the party denoted by the identifier. With public identifiers and under the assumption that there may be man-in-the-middle or masquerading attackers, public keys (or variants) seem like the only known technology that securely fulfills this requirement. It should be noted, however, that we do not necessarily need to care about potential man-in-the-middle or masquerading attackers. Whether to do so or not is a design choice. Discussion ---------- To my best knowledge, the discussion above describes the essence of the difference between the current architecture and one where identifiers and locators are separated. In the current architecture, the mobility and multi-homing problem does not exist, since one is not allowed to change ones locators on the fly. What comes to rendezvous and referral, the practice of using locators as identifiers offers a somewhat weak but very important form of security. Effectively, the practice limits the number of potential attackers hugely, from all nodes in the Internet to only those nodes that are on the path between the initiating party and the target address. It is extremely important to understand that if we really separate identifiers and locators, we become more vulnerable. Fortunately the class of potential attackers will not be everyone in the Internet, but only those that can tamper with the identifier -> locator mapping or otherwise get on the path between the initiating party and some locator. Conclusions ----------- Separating identifiers and locators has security implications. To address these, we basically have a number of possibilities: 1) Design a _secure enough_ identifier -> locator mapping service, thereby limiting the potential attackers to those that can either tamper with the service or otherwise receive packets sent to the (initially used) locator. What is "secure enough" is a design choice. The service must be dynamic because it must be possible to update the set of locators. 2) Decide to use public keys as primary identifiers, and rely on public key cryptography for identification. 3) Design a _secure enough_ identifier -> public key mapping service, thereby limiting the potential attackers to those that can tamper with the service. This is effectively a PKI, but not necessarily as secure as what people traditionally understand with a PKI. The difference to 1) is that here we are not vulnerable to attackers that just get to the path but can't tamper with the service. The service may be fairly static, since there is seldom need to chance one's public key. 4) Go only half way, and stop where the identifiers can be still used as (limited) locators. The class of attackers depends heavily on details, and cannot be easily summarized. I refrain from making comments on any practical designs (like DNS), since that requires one to consider also other aspects but security. Questions --------- Does this analysis help? Do we have other choices but the four outlined above? Should create an I-D from this and the previus message? If so, should it be accepted by some WG as a working item? --Pekka Nikander From pekka.nikander@nomadiclab.com Wed Sep 24 07:05:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Sep 24 06:05:01 2003 Subject: [Hipsec] Preparing a new version of draft-moskowitz-hip-arch Message-ID: <3F71729A.6050609@nomadiclab.com> I am going to submit a new version of draft-moskowitz-hip-arch in a couple of days. The version is available for preview at the following URLs. The changes are mostly cosmetic, the largest chance being an added acknowledgements section. http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-04-pre-Sep24.txt http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-04-pre-Sep24.html http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-04-pre-Sep24.xml http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-04-pre-Sep24-chbar.txt http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-04-pre-Sep24-diff.html Please send any comments (however minor) to me no later than Sunday, Sep 27th, 10pm PST. I will fix whatever corrections I receive, and submit the draft on Monday. The current draft expires on Sep 30th, and therefore I want to submit the new version pretty soon. --Pekka Nikander From pekka.nikander@nomadiclab.com Wed Sep 24 10:55:02 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Sep 24 09:55:02 2003 Subject: [Hipsec] New NES and packet processing rules Message-ID: <3F71A86A.7040108@nomadiclab.com> I have now completed the description for the NES, and also tried to clarify the packet processing rules in Section 8. A new interim version of draft-moskowitz-hip is now available at the following URLs. http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep24.txt http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep24.html http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep24.xml http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep24-chbar.txt http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep24-diff.html The sections that have changed most are the following: Section 8. Packet processing http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep24.html#anchor37 This is basically completely restructured, and much more detailed than the previous version. There probably a number of mistakes, so careful reading would be very welcome. Section 6.3.12. NES_INFO http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep24.html#anchor34 The new defintion of the NES_INFO parameter. Section 7.5 NES http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep24.html#NES Brief description of the new NES protocol. --Pekka Nikander From pekka.nikander@nomadiclab.com Wed Sep 24 11:03:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Sep 24 10:03:01 2003 Subject: [Hipsec] Update: HIP base exchange issues status In-Reply-To: <3F5C7FA9.8070609@nomadiclab.com> References: <3F5C7FA9.8070609@nomadiclab.com> Message-ID: <3F71AA35.3040708@nomadiclab.com> Issue 3 has now a proposal on the NES side. I think that I will be able to work out the REA side. I will next try to produce a proposal for issue 5. I think that we can even let the spec pass without specific rules for 13 or 16, leaving them for future work. (Opinions?) Summary: Closed: 1, 2, 6, 7, 8, (9), 10, 11 Proposal: 3, 4, 10a, 11a, 12, 14, 15 Open: 5, 13, 16 To remind what was what: 3. Unification of NES and REA packets 5. Rules for extensions 13. Define how to send multiple I1s to multiple IP addresses in parallel, and rate limitations. 16. Details for handling of LSIs. --Pekka Nikander From mbagnulo@ing.uc3m.es Wed Sep 24 13:40:01 2003 From: mbagnulo@ing.uc3m.es (marcelo bagnulo) Date: Wed Sep 24 12:40:01 2003 Subject: [Hipsec] RE: Security requirements for identification In-Reply-To: <3F714C8E.4070205@nomadiclab.com> Message-ID: Hi Pekka, thanks for the posting, some questions below... > -----Mensaje original----- > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > nombre de Pekka Nikander > Enviado el: miercoles, 24 de septiembre de 2003 9:50 > Para: Multi6 WG; hipsec@honor.trusecure.com > Asunto: Security requirements for identification > > > In my previous message (to hipsec&ipv6 ml) I proposed dividing > identification to the following three subcategories: > > a) identification in mobility and multi-homing > b) identification in referral or rendezvous > c) identification in other, e.g. administrative, contexts > > I also discussed rendezvous and referral, in order to > make the point that identifying a node and locating it > are really two distinct functions. > > The previous message is available at > http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg0 > 0056.html > > In this message I will try to analyze the security > requirements for identification in the sense of a) > and b). Analyzing c) in isolation does not make any > sense, since the security requirements depend on the > context. In the end of this message, I try to give > some conclusions based on the analysis; if you are > busy, you may want to see the conclusions first. > > I am focusing here solely on the identification > function, and not touching the security requirements > of the location function. It should be noted, however, > that these two are related in real life. Analyzing that > is for another message. > > > a) identification for mobility and multi-homing > ----------------------------------------------- > > As I wrote earlier, here we are only interested in gaining > assurance that the peer remains the *same*. That is, we > do not really care *whom* we are communicating with, but > only that the peer end-point is not changed in mid- > communication. (We probably did care the "real identity" > of the peer when we first initiated the communication, but > that is a different issue, with different security > requirements.) I am not sure if i understand this... I mean, we do care about recognizing the other end of a communication, right? Usually, when a host establish a communication, the host wants to establish the communications with a certain host, it is not the case that we want to communicate with any host available. So this is expressed by the ip address of the target host. This means that we do care who the other end is.In other words, IP addresses are used today for recognizing the other end. So perhpaps i don't agree with a statement from your previous mail: "1a) To me, identification for mobility and multi-homing seems to be the easiest one. There we are only interested in gaining assurance that the peer remains the same. That is, for the sole purpose of mobility or multi-homing, we do not really care with whom we are communicating with, but only that the peer end-point is not changed in mid-communication due to mobility, multi-homing, or attacks based on mobility or multi-homing mechanisms." I guess we always care with who we are communicating with i.e. we always need a permanent identifier - This is true for at least for one end of the communication, the end that is initiating the communication. Perhaps the server side of the communication does not know who the initiator is and perhaps he doesn't even care, (as long as it remains the same) If you use a transient identifier, actually you are using two identifiers: first the IP address as a permanent identifier to recognize the host and then the transient identifier to recongnize the host when it changes its address. So i guess that what is needed is: - a permanent identifier (so you can talk with who you really want to talk) - A locator (so you can reach it) - something to bind them (which can be a transient identifier, but you can use some other stuff) So i would say that ephemeral identifiers are not enough to provide identification support for multi-homing and mobility support, we need more, i.e. permanent identifiers. Regards, marcelo > > There are two basic dangers related identification in mobility > and multi-homing. One is connection hijacking, i.e., somebody > "stealing" the connection and replacing one of the peers without > being noticed. The other, less obvious one, is flooding. > Flooding is an attack where a genuine peer lies about its > location(s), with the purpose of choking a victim on excess > traffic. That is, the attacker claims to move/be better > reachable at the location of a victim, thereby directing the > traffic to the victim. > > Flooding is a serious attack since the amounts of redirected > traffic can be large. Consider a public streaming server. > Anyone can make a connection to it, and start downloading a > stream. For the stream to run, acknowledgments must be sent > back. This is easy, since an attacker can open a stream, > redirect the stream (using some mobility or multi-homing > mechanism) to a victim address, and *continue* sending > acknowledgments. Anticipating when and what kinds of acks to > send is easy enough. This makes the stream running independent > on the actions by the poor victim. > > Hence, for the purpose of mobility and multi-homing, the > identification mechanism has to keep sure that the peer really > remains the same, on all changes of locators. Furthermore, the > mechanism must not blindly trust what the peer claims about its > locations, but must check that the same peer really *is* > at all the claimed addresses. > > If we really do not care who the initial peer really is, > then a simple protocol is sufficient; the protocol first > creates a shared secret between the peers and then uses > the secret to verify persistence of the identity. The > protocol may even be vulnerable to MitM attackers in its > initialization state; our requirement states that a MitM > attacker is equally good to the "real" intended peer, > since we don't care about the "real identity". > > The requirements can be summarized as follows: > > R1. Verification that the peer is the same one > after all changes of locators. > R2. Verification that the same peer is reachable > at all claimed (and used) locations. > > The MIPv6 RR protocol is a (somewhat convoluted) example of > a protocol fulfilling the requirements. (It also fulfills > other, Mobile IPv6 specific security requirements.) > > > b) identification for referral or rendezvous > -------------------------------------------- > > In the case of referral or rendezvous, an initiating party > possesses an identifier that it wants to use as a means > of identifying another party. The target party may have > no idea of the intentions of the first party, and it may > have never met the first party. In other words, the parties > do not share any state but the identifier itself and any > state in the target party that is associated with the > identifier. > > From a security point of view, the requirement is that > the party that responds to a communication request really > is the party denoted by the identifier, and someone else. > That is, the requirement is that the target party really > is the intended target party. > > If we assumed that everybody is honest, any unique bit > string would serve well as an identifier. The initiating > party just sends the bit string to the target party, and > asks the target party to verify that the bit string really > is its identifier. The problem is that we cannot necessarily > assume everybody to be honest. > > If we assume dishonest parties, we get two sub cases. In > the first case, the initiating party must send the identifier > in clear, for some reason, or the identifier is otherwise > public and known by the dishonest parties. In the second > case, the initiating party is able to keep the identifier in > secret. > > In the first case, the only secure way of performing > identification seem to be public key cryptography (or any of > its variants, like zero knowledge protocol). The reason for > this is the following. Since the identifier is public > knowledge, we cannot use the identifier directly. Instead, > there must be some secret that only the right party > knows and is able to prove to know. The identifier and the > secret must be linked. Only public key crypto (or a variant) > seems to fulfill these requirements. > > The second case is more interesting, since it allows for > some simple cryptographic protocols that show to the > target party that the initiating party knows its secret > identifier without revealing it, and where the target > party is conversely able to show to the initiator that it > also knows the secret identifier. In effect, in this > case the identifier is a shared secret. However, it is > also almost completely impractical, since one cannot > share such a secret with anyone, nor put it into a public > directory. (There are some special cases where this kind > of identification may be useful, but one cannot build a > generic Internet wide architecture on such assumptions.) > > Hence, if we want to do referral and rendezvous in a > secure way, we seem to need public keys as identifiers. > It looks best to use public keys as primary identifiers. > It is also possible to use public keys only as secondary > identifiers, and bind them to some primary identifiers, > but that costs more since it requires a PKI. Using public > keys directly as primary identifiers does not, as such, > require a PKI. > > To summarize, the requirement is > > R3. Verification that the target party really is the > party denoted by the identifier. > > With public identifiers and under the assumption that there > may be man-in-the-middle or masquerading attackers, public > keys (or variants) seem like the only known technology > that securely fulfills this requirement. It should be noted, > however, that we do not necessarily need to care about > potential man-in-the-middle or masquerading attackers. > Whether to do so or not is a design choice. > > Discussion > ---------- > > To my best knowledge, the discussion above describes the > essence of the difference between the current architecture > and one where identifiers and locators are separated. > In the current architecture, the mobility and multi-homing > problem does not exist, since one is not allowed to change > ones locators on the fly. What comes to rendezvous and > referral, the practice of using locators as identifiers > offers a somewhat weak but very important form of security. > Effectively, the practice limits the number of potential > attackers hugely, from all nodes in the Internet to only > those nodes that are on the path between the initiating > party and the target address. > > It is extremely important to understand that if we really > separate identifiers and locators, we become more vulnerable. > Fortunately the class of potential attackers will not be > everyone in the Internet, but only those that can tamper > with the identifier -> locator mapping or otherwise get > on the path between the initiating party and some locator. > > Conclusions > ----------- > > Separating identifiers and locators has security implications. > To address these, we basically have a number of possibilities: > > 1) Design a _secure enough_ identifier -> locator mapping > service, thereby limiting the potential attackers to > those that can either tamper with the service or otherwise > receive packets sent to the (initially used) locator. > What is "secure enough" is a design choice. The service > must be dynamic because it must be possible to update > the set of locators. > > 2) Decide to use public keys as primary identifiers, > and rely on public key cryptography for identification. > > 3) Design a _secure enough_ identifier -> public key mapping > service, thereby limiting the potential attackers > to those that can tamper with the service. This is > effectively a PKI, but not necessarily as secure as what > people traditionally understand with a PKI. The difference > to 1) is that here we are not vulnerable to attackers that > just get to the path but can't tamper with the service. > The service may be fairly static, since there is seldom > need to chance one's public key. > > 4) Go only half way, and stop where the identifiers can > be still used as (limited) locators. The class of > attackers depends heavily on details, and cannot be > easily summarized. > > I refrain from making comments on any practical designs (like > DNS), since that requires one to consider also other aspects > but security. > > Questions > --------- > > Does this analysis help? > Do we have other choices but the four outlined above? > Should create an I-D from this and the previus message? If so, > should it be accepted by some WG as a working item? > > --Pekka Nikander > > > From Julien.Laganier@Sun.COM Wed Sep 24 17:17:00 2003 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Wed Sep 24 16:17:00 2003 Subject: [Hipsec] Update: HIP base exchange issues status In-Reply-To: <3F71AA35.3040708@nomadiclab.com> References: <3F5C7FA9.8070609@nomadiclab.com> <3F71AA35.3040708@nomadiclab.com> Message-ID: <200309242243.42708.julien.laganier@sun.com> On Wednesday 24 September 2003 16:29, Pekka Nikander wrote: > > 13. Define how to send multiple I1s to multiple IP > addresses in parallel, and rate limitations. Hi Pekka, Concerning the use of multiple addresses in parallel, I would like to know what do you guys think of the following paragraph: For the sake of minimizing the session establishment latency, an implementation MAY send the same I1 to more than one of the Responder's addresses. Note that, however, upon timeout, such an implementation MUST refrain from sending the same I1 packet to multiple addresses, in order to avoid congestion of the network. As the Responder is not guaranteed to distinguish the duplicate I1's he receives at several of its addresses (because it avoids to store states when it answers back an R1), the Initiator may receive several duplicate R1's. The Initiator SHOULD then select the destination address using the source address of the first received R1 as a source address for the next I2, and discards subsequent R1's. This strategy seems to be quite good in terms of RTT. Thanks, --julien From pekka.nikander@nomadiclab.com Thu Sep 25 04:03:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Sep 25 03:03:01 2003 Subject: [Hipsec] Re: Security requirements for identification In-Reply-To: References: Message-ID: <3F729955.4070409@nomadiclab.com> Marcelo, >> a) identification for mobility and multi-homing >> ----------------------------------------------- >> >> As I wrote earlier, here we are only interested in gaining >> assurance that the peer remains the *same*. That is, we >> do not really care *whom* we are communicating with, but >> only that the peer end-point is not changed in mid- >> communication. (We probably did care the "real identity" >> of the peer when we first initiated the communication, but >> that is a different issue, with different security >> requirements.) > > I am not sure if i understand this... > I mean, we do care about recognizing the other end of a communication, > right? Yes, we do care. But we do not care for the very specific purpose of "mobility and multi-homing", as I write. A very important point in the analysis is to make a distinction between identification in the beginning of a session, and subsequent identifications that are needed during the session, for various purposes. Hence, the point is that _solely_ for *mobility* or *multi-homing* you don't care about who, or any application level identity. You only care about that the peer is not changed in mid communications. Other parts of the system probably have other concerns, but not the mobility / multi-homing mechanism. > Usually, when a host establish a communication, the host wants to establish > the communications with a certain host, it is not the case that we want to > communicate with any host available. So this is expressed by the ip address > of the target host. This means that we do care who the other end is.In other > words, IP addresses are used today for recognizing the other end. Yes. What you describe is what I called in the previous analysis as "initial rendezvous". Things do get mixed in real life. However, when you try to understand the roots of phenomena, you have to make distinctions and draw lines, even if sometimes they first seem bizarre. >> "1a) To me, identification for mobility and multi-homing seems to >> be the easiest one. There we are only interested in gaining >> assurance that the peer remains the same. That is, for the >> sole purpose of mobility or multi-homing, we do not really >> care with whom we are communicating with, but only that the >> peer end-point is not changed in mid-communication due to >> mobility, multi-homing, or attacks based on mobility or >> multi-homing mechanisms." > > I guess we always care with who we are communicating with i.e. we always > need a permanent identifier - That may well be the case in most communications. But _only_, _solely_, _exclusively_ for mobility and multi-homing, you do not *need* to care. This may be deep, but this is one of the very points of the analysis. Make distinctions. > If you use a transient identifier, actually you are using two identifiers: > first the IP address as a permanent identifier to recognize the host and > then the transient identifier to recongnize the host when it changes its > address. Now, that might be perfectly reasonable. You are using the permanent IP address for initial rendezvous, and then you use a transient identifier to secure mobility. In fact, that is exactly what happens in Mobile IPv6 RO today. You have the home address, and you have Kbm, which is a kind of transient identifier. > So i guess that what is needed is: > - a permanent identifier (so you can talk with who you really want to talk) You need that for identification in the rendezvous sense. > - A locator (so you can reach it) You need that for reachability, not for identification. > - something to bind them (which can be a transient identifier, but you can > use some other stuff) Yes. But I haven't got that far yet :-) > So i would say that ephemeral identifiers are not enough to provide > identification support for multi-homing and mobility support, we need more, > i.e. permanent identifiers. I think that we are not (yet) on the same baseline with respect to understanding the various components in the game. --Pekka Nikander From pekka.nikander@nomadiclab.com Thu Sep 25 05:09:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Sep 25 04:09:00 2003 Subject: [Hipsec] Update: HIP base exchange issues status In-Reply-To: <200309242243.42708.julien.laganier@sun.com> References: <3F5C7FA9.8070609@nomadiclab.com> <3F71AA35.3040708@nomadiclab.com> <200309242243.42708.julien.laganier@sun.com> Message-ID: <3F72A8F6.2050001@nomadiclab.com> Julien, Thanks a lot! I added a limitation that the host MUST NOT send packets to more than three addresses in parallel. That blocks the potential DoS attack of someone luring a host to send I1s into 1000 addresses in parallel. Other than that, I adopted the text as such. --Pekka Nikander >>13. Define how to send multiple I1s to multiple IP >> addresses in parallel, and rate limitations. > > For the sake of minimizing the session establishment latency, an > implementation MAY send the same I1 to more than one of the > Responder's addresses. Note that, however, upon timeout, such an > implementation MUST refrain from sending the same I1 packet to > multiple addresses, in order to avoid congestion of the network. > > As the Responder is not guaranteed to distinguish the > duplicate I1's he receives at several of its addresses (because it > avoids to store states when it answers back an R1), the Initiator > may receive several duplicate R1's. > > The Initiator SHOULD then select the destination address > using the source address of the first received R1 as a source address > for the next I2, and discards subsequent R1's. This strategy seems > to be quite good in terms of RTT. From mbagnulo@ing.uc3m.es Thu Sep 25 05:50:04 2003 From: mbagnulo@ing.uc3m.es (marcelo bagnulo) Date: Thu Sep 25 04:50:04 2003 Subject: [Hipsec] RE: Security requirements for identification In-Reply-To: <3F729955.4070409@nomadiclab.com> Message-ID: Pekka, > -----Mensaje original----- > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > nombre de Pekka Nikander > Enviado el: jueves, 25 de septiembre de 2003 9:29 > Para: mbagnulo@ing.uc3m.es > CC: Multi6 WG; hipsec@honor.trusecure.com > Asunto: Re: Security requirements for identification > > > Marcelo, > > >> a) identification for mobility and multi-homing > >> ----------------------------------------------- > >> > >> As I wrote earlier, here we are only interested in gaining > >> assurance that the peer remains the *same*. That is, we > >> do not really care *whom* we are communicating with, but > >> only that the peer end-point is not changed in mid- > >> communication. (We probably did care the "real identity" > >> of the peer when we first initiated the communication, but > >> that is a different issue, with different security > >> requirements.) > > > > I am not sure if i understand this... > > I mean, we do care about recognizing the other end of a communication, > > right? > > Yes, we do care. But we do not care for the very specific > purpose of "mobility and multi-homing", as I write. > > A very important point in the analysis is to make a distinction > between identification in the beginning of a session, > and subsequent identifications that are needed during the > session, for various purposes. > > Hence, the point is that _solely_ for *mobility* or *multi-homing* > you don't care about who, or any application level identity. > You only care about that the peer is not changed in mid communications. > Other parts of the system probably have other concerns, but not > the mobility / multi-homing mechanism. > > > Usually, when a host establish a communication, the host wants > to establish > > the communications with a certain host, it is not the case that > we want to > > communicate with any host available. So this is expressed by > the ip address > > of the target host. This means that we do care who the other > end is.In other > > words, IP addresses are used today for recognizing the other end. > > Yes. What you describe is what I called in the previous > analysis as "initial rendezvous". Things do get mixed in > real life. However, when you try to understand the roots > of phenomena, you have to make distinctions and draw lines, > even if sometimes they first seem bizarre. > Ok. I think i see what you mean. > >> "1a) To me, identification for mobility and multi-homing seems to > >> be the easiest one. There we are only interested in gaining > >> assurance that the peer remains the same. That is, for the > >> sole purpose of mobility or multi-homing, we do not really > >> care with whom we are communicating with, but only that the > >> peer end-point is not changed in mid-communication due to > >> mobility, multi-homing, or attacks based on mobility or > >> multi-homing mechanisms." > > > > I guess we always care with who we are communicating with i.e. we always > > need a permanent identifier - > > That may well be the case in most communications. But _only_, > _solely_, _exclusively_ for mobility and multi-homing, you > do not *need* to care. > > This may be deep, but this is one of the very points of the > analysis. Make distinctions. > > > If you use a transient identifier, actually you are using two > identifiers: > > first the IP address as a permanent identifier to recognize the host and > > then the transient identifier to recongnize the host when it changes its > > address. > > Now, that might be perfectly reasonable. You are using the > permanent IP address for initial rendezvous, and then you use > a transient identifier to secure mobility. In fact, that is > exactly what happens in Mobile IPv6 RO today. You have the > home address, and you have Kbm, which is a kind of transient > identifier. > > > So i guess that what is needed is: > > - a permanent identifier (so you can talk with who you really > want to talk) > > You need that for identification in the rendezvous sense. > Ok > > - A locator (so you can reach it) > > You need that for reachability, not for identification. > Ok > > - something to bind them (which can be a transient identifier, > but you can > > use some other stuff) > > Yes. But I haven't got that far yet :-) > Well, i been re-considering this point and i think i would like to re-state it in the following way. I guess that identifiers make sense if you can prove that you own them. I mean i can tell you that i have identifier A but if i cannot prove that i own it it isn't really useful. So, usually we use IP addresses as identifiers, and the proof of ownership is provided by the routing system. Now the problem is that when we move or change the path to alternative provider, we connot longer prove that we own our identifier. So here is when a ephemeral identifier can help, since you can start using the permanent idenfitifier (ip address) when you are capable of proving its ownership, and at this moment create an ephemeral identifier, which you can prove that you own by other means than the routing system i.e. crypto. And then just forget about the permanent identifier and keep track of the identity of the other end by just using the ephemeral identifier. So, you don't need the ephemeral identifier to make a safe mapping to a locator, but you need it to provide an alternative identifier whose ownership can be proven when you cannot longer prove the ownership of the permanent identifier. Obviously, you could just solve the problem by using an identifier that doesn't uses the routing system in order to prove its ownership, and it uses a location idenpendent mean to prove it (just like public keys ;-) However, the problem of initial rendezvous remains in this case. > > So i would say that ephemeral identifiers are not enough to provide > > identification support for multi-homing and mobility support, > we need more, > > i.e. permanent identifiers. > > I think that we are not (yet) on the same baseline with respect > to understanding the various components in the game. > I think that your postings are being really useful to understand these issues. Thanks, marcelo > --Pekka Nikander > > > > > From Erik Nordmark Fri Sep 26 09:09:01 2003 From: Erik Nordmark (Erik Nordmark) Date: Fri Sep 26 08:09:01 2003 Subject: [Hipsec] RE: Security requirements for identification In-Reply-To: "Your message with ID" Message-ID: > If you use a transient identifier, actually you are using two identifiers: > first the IP address as a permanent identifier to recognize the host and > then the transient identifier to recongnize the host when it changes its > address. > > So i guess that what is needed is: > - a permanent identifier (so you can talk with who you really want to talk) > - A locator (so you can reach it) > - something to bind them (which can be a transient identifier, but you can > use some other stuff) > > So i would say that ephemeral identifiers are not enough to provide > identification support for multi-homing and mobility support, we need more, > i.e. permanent identifiers. I think the security requirements are far from clear. What is clear is that a mechanism that allows connections to survive multihoming by being able to replace the identifiers that are used for a connection, need to prevent redirection attacks where a connection is accidentally or maliciously redirected to somebody else. What is also clear is that any new system for mapping identifiers to locators need to be concerned about security so that the chain of starting with a FQDN and ending up with a packet received at the peer isn't weaker than it is today, and that DNSsec applied to the parts (e.g. FQDN->identifier lookup) can help make the security of that chain stronger. But the security requirements beyond this depend on what else we want to use the locators for. One possible use is a stable handle on a peer that has a longer lifetime than both the locators and the FQDNs; if a node receives a packet from an identifier and its the same identifier as was used 3 years ago, the node can be sure it is the same node. Another possible use is as a handle into some policy where the identifer might have some hirarchy so that a node can tell e.g. whether a peer's identifer belong to the same or different site as the node. So I don't know if we have consensus that we need long-term stable identifiers as part of id/locator separation. Perhaps we need multiple flavors of identifers with some being long-term stable. Erik From pekka.nikander@nomadiclab.com Fri Sep 26 09:17:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Sep 26 08:17:01 2003 Subject: [Hipsec] Issue 5: Rules for extensions Message-ID: <3F732EB6.2050007@nomadiclab.com> Background ---------- The variable length parameters in HIP packets are encoded in the TLV format, which consists of a 16 bit Type field, 16 bit Length field, and a variable length value. All the parameters must have a length that is a multiple of 8, but the Length field does NOT include the padding. Hence, a Parameter whose length is 14 bytes actually takes 16 bytes in the packet. It has also been specified that the parameters must be ordered by the Type field. The following parameter Types are currently defined: SPI_LSI 1 0x0001 BIRTHDAY_COOKIE 2/3 0x0002/3 NES_INFO 4 0x0004 DIFFIE_HELLMAN 6 0x0006 HIP_TRANSFORM 16 0x0010 ESP_TRANSFORM 18 0x0012 ENCRYPTED 20 0x0014 HOST_ID 32 0x0020 HOST_ID_FQDN 33 0x0021 CERT 64 0x0040 HMAC 49152 0xC000 HIP_SIGNATURE2 65533 0xFFFD HIP_SIGNATURE 65534 0xFFFE The reason for the sparse spacing is to allow later addition of other types in between. The reason for the large type values for HMAC and signatures is so that they will be located in the end of the packet. Otherwise the exact values have not that much meaning, and have their current value largely either due to historical reasons or by the whim of the author. Problem ------- An extension mechanism should allow new parameter types. There must be at least two classes of new parameters: - parameters that will be ignored by a recipient that does not understand them - parameters that will cause the recipient to drop the packet if it does not understand them Furthermore, it would be nice if new parameters could be defined in such a way that they could be located in a "natural" order in the packets. With that I mean that the processing of packets would be as easy as possible, without unnecessary complications. Proposal -------- Let's devide the possible Type values into regions, with some regions requiring recognition while others allowing the parameter to be ignored. Futhermore, let's assign the regions so that they are trivial to recognize. There are various ways how we could achieve that. 1) Renumber the current type codes so that they are all even values. That would allow one to use any odd values as optional parameters, making even values ones that must be recognized. This requires that we renumber SPI_LSI (to 0), BIRTHDAY (to 2/4), preferably NES_INFO (to make room for BIRTHDAY response as 4), HOST_ID_FQDN (to 34), and HIP_SIGNATURE2 (to 0xFFFC). A new value for NES_INFO could be 48. 2) Define regions at the small type codes (e.g. 0-256) and large type codes (e.g 2^16-256 - 2^16-1) where all type codes must be recognized. Renumber HMAC to the upper range. Divide the are in the middle somehow (how?) to a number of alternating regions. 3) Some other way (I am too tired to figure out any) I would prefer 1), but it would require an incompatible change to the protocol. Can we still do that? Does anyone have any troubles if we do it? Opinions? --Pekka Nikander From pekka.nikander@nomadiclab.com Fri Sep 26 09:17:03 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Sep 26 08:17:03 2003 Subject: [Hipsec] Issue 16: Details of LSI handling Message-ID: <3F73E54E.7020308@nomadiclab.com> Background ---------- By default, LSIs are selected by taking the low order 24 bits from a HIT. Each host selects the LSIs for its peers. It is possible that a host is communicating with two remote hosts whose low order 24 HIT bits are identical. It is also possible that a host needs to communicate with another host whose low order 24 HIT bits are identical to those of the host itself. In such situations the host must select an LSI that is different from the default one. Hosts send the selected LSIs to their peers in I2 and R2. When default LSIs are used, they will be always accepted, since each host reserves its default LSI to represent itself. If a Recipient receives an LSI different from the default in I2, it can check that the LSI is available (not used to represent some other host). If the LSI is not available, currently the host will simply drop the I2. Since there are quite a few reasons why an I2 may be dropped, this may not be the best practise. On the other hand, it looks like that we need to regenerate a non-default LSI each time we resend an I2 just to be sure. If an Initiator receives an unsuitable LSI in an R2, we have a bigger problem. The recipient has already created its state, and there is no way the Initiator can tell the Recipient that the LSI is unsuitable. Basically, it needs to start the negotiation again (or at least send an I2 with a larger birthday value), and *hope* that the Recipient will pick a different LSI this time. The probability of a collision is not very high. It basically requires that there is a collision in both ends, i.e., that the party selecting the LSI needs to select a non-default LSI, and the other party cannot accept the non-default LSI. On the other hand, if HIP any receives any larger deployment, there will be collisions (see the probability analysis in the draft). What to do? ----------- I am pretty unsure what to do. Initially there is unlikely to be problems. If the hosts select the non-default LSIs randomly, we will just see a few HIP connections to fail every now and then. There is certainly a place for improvement, but I haven't been able to find one that would be simple and elegant. Given that collisions will be fairly rare, I would like the mechanism to be extremely simple, even if possibly somewhat inefficient. On the other hand, requiring a full new protocol run seems like an overkill. One option is just to document the situation and leave it open for further experimentation. Any opinions? Any nice schemes that would allow us to solve this problem? --Pekka Nikander From Julien.Laganier@Sun.COM Fri Sep 26 10:20:01 2003 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Fri Sep 26 09:20:01 2003 Subject: [Hipsec] Issue 5: Rules for extensions In-Reply-To: <3F732EB6.2050007@nomadiclab.com> References: <3F732EB6.2050007@nomadiclab.com> Message-ID: <200309261546.01671.julien.laganier@sun.com> Hi Pekka, Please find some thoughts below. On Thursday 25 September 2003 20:06, Pekka Nikander wrote: <\snip> > Proposal > -------- > > Let's devide the possible Type values into regions, > with some regions requiring recognition while others > allowing the parameter to be ignored. Futhermore, > let's assign the regions so that they are trivial > to recognize. > > There are various ways how we could achieve that. > > 1) Renumber the current type codes so that they are > all even values. That would allow one to > use any odd values as optional parameters, > making even values ones that must be recognized. > > This requires that we renumber SPI_LSI (to 0), > BIRTHDAY (to 2/4), preferably NES_INFO (to make > room for BIRTHDAY response as 4), HOST_ID_FQDN (to 34), > and HIP_SIGNATURE2 (to 0xFFFC). A new value for > NES_INFO could be 48. > > 2) Define regions at the small type codes (e.g. 0-256) > and large type codes (e.g 2^16-256 - 2^16-1) where > all type codes must be recognized. Renumber HMAC > to the upper range. > > Divide the are in the middle somehow (how?) to a > number of alternating regions. > > 3) Some other way (I am too tired to figure out any) One solution might be to define some Type prefixes for extensions, that make regognition easier, for example: o 0x8 for standardized extensions that can be ignored o 0x9 for private extensions that can be ignored o 0xa for standardized extensions that cannot be ignored o 0xb for private extensions that cannot be ignored That allows space for 2^12 = 4096 different subtypes under each prefixes while not requiring renumbering of existing Types. I guess that would be sufficient for quite a long time. > I would prefer 1), but it would require an incompatible > change to the protocol. Can we still do that? Does anyone > have any troubles if we do it? I have no troube with doing any of the above, so let's others people speak. Thanks, --julien From thomas.r.henderson@boeing.com Fri Sep 26 11:32:01 2003 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Fri Sep 26 10:32:01 2003 Subject: [Hipsec] Issue 16: Details of LSI handling Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B5ACE@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > Sent: Friday, September 26, 2003 12:06 AM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] Issue 16: Details of LSI handling >=20 > Any opinions? Any nice schemes that would allow us to > solve this problem? >=20 Pekka, I still believe that this may be a non-issue. See the discussion at http://lists.freeswan.org/archives/hipsec/2003-March/000495.html Our current implementation only uses LSIs for 32 bit values in the pseudoheader for HIP-using sockets. They do not even need to be exchanged, although we do exchange them for compliance with the draft spec. Now that the draft-08-pre has migrated to use of the=20 IPv6 pseudoheader, we won't even need the LSIs for the pseudoheader anymore. Of course, this issue is tied to how people envision the HIP-enabled sockets API for IPv4. We have taken the stance that LSIs are not=20 used in the sockaddr_in.sin_addr in socket calls-- if HIP is to be=20 used on a connection, it is flagged as such in the IPsec policy table (which is based on IP addresses), and the kernel manages to do the right = thing. =20 So I would like to again propose that we delete the LSIs from the=20 protocol on the wire, and leave the LSI concept as an implementation=20 issue. Counter-arguments? Tom From mbagnulo@ing.uc3m.es Fri Sep 26 14:21:01 2003 From: mbagnulo@ing.uc3m.es (marcelo bagnulo) Date: Fri Sep 26 13:21:01 2003 Subject: [Hipsec] RE: Security requirements for identification In-Reply-To: Message-ID: Hi Erik, > -----Mensaje original----- > De: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > Enviado el: jueves, 25 de septiembre de 2003 23:15 > Para: mbagnulo@ing.uc3m.es > CC: Pekka Nikander; Multi6 WG; hipsec@honor.trusecure.com > Asunto: RE: Security requirements for identification > > > > If you use a transient identifier, actually you are using two > identifiers: > > first the IP address as a permanent identifier to recognize the host and > > then the transient identifier to recongnize the host when it changes its > > address. > > > > So i guess that what is needed is: > > - a permanent identifier (so you can talk with who you really > want to talk) > > - A locator (so you can reach it) > > - something to bind them (which can be a transient identifier, > but you can > > use some other stuff) > > > > So i would say that ephemeral identifiers are not enough to provide > > identification support for multi-homing and mobility support, > we need more, > > i.e. permanent identifiers. > > I think the security requirements are far from clear. > Agree, but i think we are making some progress here. I think i would be a good idea to accept Pekka's offert, and put some of his postings in a ID format. IMHO this could be good starting point to understand the requirements. > What is clear is that a mechanism that allows connections to survive > multihoming by being able to replace the identifiers that are used for a > connection, need to prevent redirection attacks where a connection is > accidentally or maliciously redirected to somebody else. > > What is also clear is that any new system for mapping identifiers to > locators need to be concerned about security so that the chain > of starting with a FQDN and ending up with a packet received at the > peer isn't weaker than it is today, We should also preserve the security of communications that don't use the DNS i.e. they use IP address directly. I mean, it is safer to use directly IP addresses than using names (without DNS). This capability has to be preserved. This means that not only the chain starting from a FQDN and ending in the packet delivery has to remain as safe as it is today, but also it has to be possible to establish a communication with the same level of security of the one obtained today when sending packets directly to ip addresses without using the DNS. > and that DNSsec applied to the parts > (e.g. FQDN->identifier lookup) can help make the security of that chain > stronger. > > But the security requirements beyond this depend on what else we want > to use the locators for. > One possible use is a stable handle on a peer that has a longer lifetime > than both the locators and the FQDNs; if a node receives a packet > from an identifier and its the same identifier as was used 3 > years ago, the > node can be sure it is the same node. > > Another possible use is as a handle into some policy where the identifer > might have some hirarchy so that a node can tell e.g. whether a peer's > identifer belong to the same or different site as the node. > > So I don't know if we have consensus that we need long-term > stable identifiers > as part of id/locator separation. Ok, this depends on what do you call stable. But, i guess we agree that in order to able to establish a communication, the initiating party has to be capable of identifying the other party, so that it can define who he wants to talk to. This means that some form of stable identifier is needed at least for the server party of the communication. Perhap we can see the IPv4 situation and evaluate which kind of identifiers are needed. An intersting point is that some hosts never have a permanent identifier and perhaps they don't need it (for instance hosts through dial-up with dhcp) On the other hand, servers need stable identifiers so they can be reached. > Perhaps we need multiple flavors of > identifers with some being long-term stable. > indeed, perhaps we do. Thanks, marcelo > Erik > From Erik Nordmark Fri Sep 26 14:21:04 2003 From: Erik Nordmark (Erik Nordmark) Date: Fri Sep 26 13:21:04 2003 Subject: [Hipsec] RE: Security requirements for identification In-Reply-To: "Your message with ID" Message-ID: > Agree, but i think we are making some progress here. > I think i would be a good idea to accept Pekka's offert, and put some of his > postings in a ID format. IMHO this could be good starting point to > understand the requirements. Agreed. > We should also preserve the security of communications that don't use the > DNS i.e. they use IP address directly. I mean, it is safer to use directly > IP addresses than using names (without DNS). This capability has to be > preserved. This means that not only the chain starting from a FQDN and > ending in the packet delivery has to remain as safe as it is today, but also > it has to be possible to establish a communication with the same level of > security of the one obtained today when sending packets directly to ip > addresses without using the DNS. You use the term "IP address" which I've removed from my vocabulary in this context; are you talking about an identifier or a locator? > Ok, this depends on what do you call stable. > But, i guess we agree that in order to able to establish a communication, > the initiating party has to be capable of identifying the other party, so > that it can define who he wants to talk to. This means that some form of > stable identifier is needed at least for the server party of the > communication. Yes, but potentially such a number doesn't need to be globally unique. I can envision potential solutions, their desirability aside, where each server would pick a random number at its identifier with no global coordination, publish that number in the DNS (e.g. using a new ID record) together with the locators published as AAAA records. This would allow the client to use the fqdn to find both this identifier and the locators for the service and communicate. Such "identifiers" do not need to be globally unique, and they might change as frequently as it is feasible to update the DNS ID record. So I hope the above illustrates that there isn't an inherent requirement from the multi6 problem set to make the identifiers globally unique or stable. That doesn't mean that it is a good idea to make them unstable. Since we need to prevent redirection attacks there has to be a way to check who is authorized to redirect the packet flow for a given identifier to some new locator. That would be quite confusing if multiple nodes happen to use the same identifier while communicating with the same peer; "redirect packets for id=X" would then affect traffic to two separate nodes thus the authorization question can't be answered. So I think the multi6 problem set requires very low probability that two nodes use the same identifier when communicating with a given peer. But I don't think it is until you also look at other problems, like identifiers that can be used by applications for rendez-vous and referral, that the stability issue comes to the forefront. (One could argue that from the perspective of the UDP/IP stack, an application over UDP behaves in ways that look like applications doing rendez-vous; the only difference might be implicit assumptions about what the elapsed time is between receiving something and trying to send something back.) So I'm all for stable identifiers for general application using being part of the free lunch; but oops - there is no free lunch :-) Thus we need to try to tease apart the different uses of identifiers and understand the requirements a bit more. > Perhap we can see the IPv4 situation and evaluate which kind of identifiers > are needed. > An intersting point is that some hosts never have a permanent identifier and > perhaps they don't need it (for instance hosts through dial-up with dhcp) > On the other hand, servers need stable identifiers so they can be reached. But is this ("clients" not have stable IP or DNS names) a feature or a bug? Turning things around, one could ask what the benefits would be of having an identifier which 1) doesn't change when you change ISP and 2) doesn't change due to some administrative mistake (like not renewing your domain name with the registrar). Erik From Dave Crocker Sat Sep 27 01:09:01 2003 From: Dave Crocker (Dave Crocker) Date: Sat Sep 27 00:09:01 2003 Subject: [Hipsec] Re: Security requirements for identification In-Reply-To: <3F714C8E.4070205@nomadiclab.com> References: <3F714C8E.4070205@nomadiclab.com> Message-ID: <5921363068.20030926172837@brandenburg.com> Pekka, I think I said this last time, but just in case: thanks for working on cohesive discussion about needs and issues for identification. It makes it so much easier to debate specifics... My comments, below, are tuned for multiaddressing, since that it the motivation du jour. If the scope of this discussion is meant to be broader than dealing with mobility and multihoming, please forgive my error. PN> a) identification for mobility and multi-homing PN> As I wrote earlier, here we are only interested in gaining PN> assurance that the peer remains the *same*. yes. PN> There are two basic dangers related identification in mobility PN> and multi-homing. One is connection hijacking, yes. PN> being noticed. The other, less obvious one, is flooding. I am only now finally understanding why this is a problem "created" by multiaddressing. Hijacking is directing traffic to oneself. Flooding is directing traffic to someone else. One is to intercept data and the other is to overload a victim. Both problems are created by being able to ... redirect traffic to a new address. Thank you! PN> Hence, for the purpose of mobility and multi-homing, the PN> identification mechanism has to keep sure that the peer really PN> remains the same, on all changes of locators. Furthermore, the PN> mechanism must not blindly trust what the peer claims about its PN> locations, but must check that the same peer really *is* PN> at all the claimed addresses. Hmmm. Carried to the extreme the requirement seems to specify would probably require having every packet be encrypted -- so it could only be decoded by the correct recipient -- and acknowledged with a signature. At most, I suspect you really mean that there must be a "useful" confirmation when a new target address is used for the first time. For example, if there are nonce-based association identifiers, 1) the initiator using the target address for the first includes the target's nonce in some sort of "hello again" packet, and 2) the target responds with a packet containing the initiator's nonce. This goes beyond the safety provided in current, mono-addressing IP, but certainly is focused on problems caused (or exacerbated) by the introduction of multiaddressing. PN> b) identification for referral or rendezvous PN> In the case of referral or rendezvous, an initiating party PN> possesses an identifier that it wants to use as a means PN> of identifying another party. In spite of the above language, you do not define rendezvous and referral. I have been assuming the latter means "moving an association from one endpoint to another". That is, "hand off" of one end of an association to a new endpoint. So, please clarify what you mean by both terms and how they relate to the distinction between identifying versus locating. I believe the two terms can, and should, refer to two different things (unless there is already an established practise of using them synonymously) Rendezvous is a means of one endpoint finding another. It often uses a third-party intermediary. It may or may not occur when there already is context between the two endpoints. Referral is a means by which one host in an association can replace itself with another host. That is, it transfers the association context to a third host. PN> If we assumed that everybody is honest, any unique bit PN> string would serve well as an identifier. The initiating PN> party just sends the bit string to the target party, and PN> asks the target party to verify that the bit string really PN> is its identifier. The problem is that we cannot necessarily PN> assume everybody to be honest. PN> If we assume dishonest parties, we get two sub cases. In PN> the first case, the initiating party must send the identifier PN> in clear, for some reason, or the identifier is otherwise PN> public and known by the dishonest parties. In the second PN> case, the initiating party is able to keep the identifier in PN> secret. This line of thinking appears to go quite a bit beyond the current world of IP mon-addressing. And I believe it involves concerns not created by multiaddressing. However validly, we trust DNS entries and IP routing. As soon as you worry about whether to send an identifier in the clear, you are considering something far broader than problems caused by multiaddressing. PN> In the first case, the only secure way of performing PN> identification seem to be public key cryptography (or any of PN> its variants, like zero knowledge protocol). The reason for PN> this is the following. Since the identifier is public PN> knowledge, we cannot use the identifier directly. Today, we use domain names and IP addresses in the clear. And things work pretty well. To use Marcelo's phrasing, we do not "prove we own" the domain names are IP addresses we use. So, why must we start encrypting identifiers? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From jari.arkko@piuha.net Sat Sep 27 14:34:01 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sat Sep 27 13:34:01 2003 Subject: [Hipsec] Issue 5: Rules for extensions In-Reply-To: <3F732EB6.2050007@nomadiclab.com> References: <3F732EB6.2050007@nomadiclab.com> Message-ID: <3F75CF88.9050106@piuha.net> Pekka Nikander wrote: > 1) Renumber the current type codes so that they are > all even values. That would allow one to > use any odd values as optional parameters, > making even values ones that must be recognized. > > This requires that we renumber SPI_LSI (to 0), > BIRTHDAY (to 2/4), preferably NES_INFO (to make > room for BIRTHDAY response as 4), HOST_ID_FQDN (to 34), > and HIP_SIGNATURE2 (to 0xFFFC). A new value for > NES_INFO could be 48. > > 2) Define regions at the small type codes (e.g. 0-256) > and large type codes (e.g 2^16-256 - 2^16-1) where > all type codes must be recognized. Renumber HMAC > to the upper range. > > Divide the are in the middle somehow (how?) to a > number of alternating regions. > > 3) Some other way (I am too tired to figure out any) > > I would prefer 1), but it would require an incompatible > change to the protocol. Can we still do that? Does anyone > have any troubles if we do it? I would be in favor of approach #1. --Jari From mkomu@niksula.hut.fi Sat Sep 27 17:20:02 2003 From: mkomu@niksula.hut.fi (Miika Komu) Date: Sat Sep 27 16:20:02 2003 Subject: [Hipsec] Issue 5: Rules for extensions In-Reply-To: <3F732EB6.2050007@nomadiclab.com> References: <3F732EB6.2050007@nomadiclab.com> Message-ID: On Thu, 25 Sep 2003, Pekka Nikander wrote: > There are various ways how we could achieve that. > > 1) Renumber the current type codes so that they are > all even values. That would allow one to > use any odd values as optional parameters, > making even values ones that must be recognized. > > This requires that we renumber SPI_LSI (to 0), > BIRTHDAY (to 2/4), preferably NES_INFO (to make > room for BIRTHDAY response as 4), HOST_ID_FQDN (to 34), > and HIP_SIGNATURE2 (to 0xFFFC). A new value for > NES_INFO could be 48. > > 2) Define regions at the small type codes (e.g. 0-256) > and large type codes (e.g 2^16-256 - 2^16-1) where > all type codes must be recognized. Renumber HMAC > to the upper range. > > Divide the are in the middle somehow (how?) to a > number of alternating regions. > > 3) Some other way (I am too tired to figure out any) > > I would prefer 1), but it would require an incompatible > change to the protocol. Can we still do that? Does anyone > have any troubles if we do it? Option 1 sounds better and simpler. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From gmgross@nac.net Sat Sep 27 17:55:01 2003 From: gmgross@nac.net (George Gross) Date: Sat Sep 27 16:55:01 2003 Subject: [Hipsec] Issue 5: Rules for extensions In-Reply-To: Message-ID: Hi, I noticed that on the original post on this topic, the encoding scheme allowed the combination "mandatory" and "private". In other IETF protocols I've observed, this wasn't allowed. One could potentially stumble across inter-op problems that might occur when Vendor X marks a TLV mandatory and its implementation is proprietary. br, George From kurtis@kurtis.pp.se Sun Sep 28 13:25:01 2003 From: kurtis@kurtis.pp.se (Kurt Erik Lindqvist) Date: Sun Sep 28 12:25:01 2003 Subject: [Hipsec] Re: Security requirements for identification In-Reply-To: <3F714C8E.4070205@nomadiclab.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On onsdag, sep 24, 2003, at 09:49 Europe/Stockholm, Pekka Nikander wrote: > Does this analysis help? I think it does raise / point out some interesting facts on what can / can't be properties of identifiers. > Do we have other choices but the four outlined above? > Should create an I-D from this and the previus message? If so, > should it be accepted by some WG as a working item? I have two question to the WG, and especially to the DT chairs and the AD : 1) Would we consider it useful to have a WG document on properties of identifiers, in terms of security? Maybe even call it "Security requirements"? From Tony's ad-hoc poll, there seems to be a clear majority in favor of some sort of id/loc split, with reservations on what each of them really is. 2) Do we think we could get rough consensus around such a document? In some other words, the WG will still of course be free to choose not to adapt a document by Pekka. But as the discussion following Tonys question showed, there are very different views on what an identifier is/might be. I think we at some point need to start to narrow this down. This is of course part of what the DT's are working on, that is why I also ask the DT chairs if they would consider this helpful. I do realize that such a document will have to make certain assumptions on what an identifier is. But I also think that might be issues we could sort out as the DTs present at we get better understanding. Ok, so.......:-) - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP3MH/KarNKXTPFCVEQIynwCfVBjy3u+XYMtC+49r2Q9PmmaKatIAoMQR sxP4p9jm4KBzA3SkeUYhj84y =dT/c -----END PGP SIGNATURE----- From Tony.Li@procket.com Sun Sep 28 14:45:01 2003 From: Tony.Li@procket.com (Tony Li) Date: Sun Sep 28 13:45:01 2003 Subject: [Hipsec] RE: Security requirements for identification Message-ID: Hmmm.... I suppose that I should respond. ;-) Yes, I think that that some kind of consensus on the properties of identifiers is a necessity. There is a long discussion to get there. Could we get rough consensus on it? Yes, I think so, but it might be very rough. And it might take a very long time. Certainly the discussions within our design team have taken awhile and that's with a much smaller number of people. It may well be faster to start the discussion with the output of one of the design teams, so that the discussion can revolve around an entire design, rather than effectively throwing open design discussions to the entire WG. I'm flexible in this regard. However, as a Loyal Opponent of Bureaucracy, I have to question whether this needs to be a document. And whether this needs to be an official WG document, given that it will not become end product. In the Good Olde Days, the IETF use to be far more cooperative than it is today. Some of that was undoubtedly due to the money grubbing effects that were introducd by the bubble. However, with the=20 bubble behind us, I would very much like to see if we can recapture that cooperative spirit and avoid some of the unnecessary squabbling that goes on. IMHO, having dueling drafts is one of the more destructive forces against cooperation. As soon as there is a draft, the authors have a 'position', and they need to defend it. And the squabbling begins. In the Good Olde Days, the WG chair was a neutral discussion leader and tried to establish consensus by ensuring that=20 differing points of view were represented in the work output and that the group came to rough consensus on very small points in a gradual manner. This is not the only way that these things can happen, but a reminder of what once was. I leave it to the WG to choose the best path. Yours in cooperation, Tony From thomas.r.henderson@boeing.com Sun Sep 28 19:55:01 2003 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Sun Sep 28 18:55:01 2003 Subject: [Hipsec] Updating moskowitz-hip-07: IPv4 pseudo header Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C020AC0BB@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > Sent: Friday, September 05, 2003 3:20 AM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] Updating moskowitz-hip-07: IPv4 pseudo header > >=20 > I propose that we change the text as follows: >=20 > In case of using IPv4, the IPv4 UDP pseudo header format [RFC768] > is used. In the pseudo header, the source and destination > addresses are those used in the IP header, the zero field is > obviously zero, the protocol is the HIP protcol number (TBD), > and the length is calculated as in the IPv6 case. >=20 > This would require a small change to the current implementations. >=20 > Opinions? >=20 > Another option may be to leave out the IP addresses from the IPv4=20 HIP checksum (that's what HIP is all about, right? :). =20 Otherwise, I'm fine with the proposed change. I think that = realistically we should expect to tunnel HIP over UDP for IPv4 NAT traversal, in which case the HIP checksum might be redundant, but if it comes to pass that IPv4 NATs are HIP aware, it is reasonable to either a) make the checksum rewriting the same as TCP/UDP or b) do not require them to=20 rewrite checksums by avoiding the pseudoheader construct or by using dummy addresses in the pseudoheader. =20 Option b) might be more NAT friendly if the deployed base of NATs is=20 able to handle non TCP/UDP traffic by simply manipulating the IP header, = but I suspect that even avoidance of layer 4 manipulation will not be=20 sufficient to get through many legacy NATs. =20 Tom =20 From thomas.r.henderson@boeing.com Sun Sep 28 20:49:01 2003 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Sun Sep 28 19:49:01 2003 Subject: [Hipsec] A HIP WG charter proposal Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B5AEE@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > Sent: Tuesday, September 23, 2003 7:46 AM > To: Scott W Brim > Cc: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] A HIP WG charter proposal >=20 >=20 > Scott W Brim wrote: > >> Additionally, the working group aims to standardize, together > >> with the IPsec Working Group, the necessary hooks that would > >> allow HIP to utilize unmodified IPsec ESP. One particular way of > >> implementing the small changes required to IPsec ESP has been > >> defined in a separate draft: > >> > >> draft-nikander-esp-beet-mode-00.txt (to be issued) > >=20 > > I would not put this in. It's a good idea, but putting it in the > > charter creates a dependency on another working group, and=20 > expands the > > potential scope to the point where arguments about scope=20 > might lead to > > nothing ever happening. Revise the charter to add it=20 > later, if we're > > successful with the main tasks. >=20 > Well, if we could get a small change in to ESP, it would be > possible to implement HIP completely in the user level, and > use kernel level ESP. As the state is now, it is possible > to implement HIP in the user level, but it requires a user > level ESP implementation as well. In a host that supports > IPsec, this results in two different ESP implementations More accurately, it requires either a user level ESP or a patch to a kernel level standard ESP. Specifically, we have been using freeswan but adding some additional checks to the code where it tries to retrieve the appropriate SA for the flow. The changes=20 are not substantial, but if something like BEET were there it=20 could be used for this. Tom =20 From pekka.nikander@nomadiclab.com Mon Sep 29 05:42:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Sep 29 04:42:00 2003 Subject: [Hipsec] LC: draft-moskowitz-hip-arch-04.txt ready for IESG? Message-ID: <3F77F6C2.1040102@nomadiclab.com> I have submitted draft-moskowitz-hip-arch-04.txt to the repositiories. In the meanwhile, it is available in different formats at the following URLs. http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-04.txt http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-04.xml http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-04.html http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-04-diff.html http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-04-chbar.txt The changes from -03 are mostly editorial, with a few places clarified to more strictly say that non-cryptographic HIs are not currently defined. In my opinion, this would be ready to be submitted to the IESG to be considered for Informational. Since we do not have a WG, we cannot really run a WG LC. Anyway, I will consider the next two weeks, until Monday Oct 13th, 10pm PST, as an informal "whatever" Last Call. If I don't receive any comments by the end of the period, I will simply submit -04 to the IESG. Otherwise, I will produce yet another version, and depending on the type of comments (editorial or substantial) either discuss them here or simply fix and directly submit the new version to the IESG. Hence, if you have not reviewed the document lately, now would be the perfect time to do so. --Pekka Nikander From pekka.nikander@nomadiclab.com Mon Sep 29 06:36:02 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Sep 29 05:36:02 2003 Subject: [Hipsec] New Issue 17: Need example checksums as an appendix Message-ID: <3F780366.1060702@nomadiclab.com> Tom reminded me that HIP checksums have been a very hard part to get right in the past. Hence, we need to have checksum examples in an appendix. More specifically, we need to have at least the following examples: - a simple HIP packet carried over IPv4 (an I1, for example) - a simple HIP packet carried over IPv6 (an I1, for example) - a simple UDP packet carried over IPv4, using specific simple HITs - a simple UDP packet carried over IPv6, using specific simple HITs, showing the same checksum as above - a simple TCP packet (e.g. SYN), with specific HITs. As per RFC3330, I will use the IPv4 addresses in the examples from the 192.0.2.0/24 network. As per draft-houston-ipv6-documentation-prefix-01.txt, I will use IPv6 addresses from 2001:0DB8::/32 Are there any opinions on the HITs that should be used? Would 4000::1 and 4000::2 do? Any better ideas? --Pekka Nikander From pekka.nikander@nomadiclab.com Mon Sep 29 06:45:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Sep 29 05:45:01 2003 Subject: [Hipsec] New Issue *18*: Need example checksums as an appendix In-Reply-To: <3F780366.1060702@nomadiclab.com> References: <3F780366.1060702@nomadiclab.com> Message-ID: <3F780560.3000102@nomadiclab.com> Any helping hands to help me keep me up to date with issues? This must be issue #18, since #17 is already assinged to unifying the HIP and ESP SA proposals. --Pekka Nikander Pekka Nikander wrote: > Tom reminded me that HIP checksums have been a very > hard part to get right in the past. Hence, we need > to have checksum examples in an appendix. More specifically, > we need to have at least the following examples: > > - a simple HIP packet carried over IPv4 (an I1, for example) > - a simple HIP packet carried over IPv6 (an I1, for example) > - a simple UDP packet carried over IPv4, using specific > simple HITs > - a simple UDP packet carried over IPv6, using specific > simple HITs, showing the same checksum as above > - a simple TCP packet (e.g. SYN), with specific HITs. > > As per RFC3330, I will use the IPv4 addresses in the examples > from the 192.0.2.0/24 network. > > As per draft-houston-ipv6-documentation-prefix-01.txt, I will > use IPv6 addresses from 2001:0DB8::/32 > > Are there any opinions on the HITs that should be used? > Would 4000::1 and 4000::2 do? Any better ideas? > > --Pekka Nikander > > > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec From pekka.nikander@nomadiclab.com Mon Sep 29 06:55:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Sep 29 05:55:01 2003 Subject: [Hipsec] Updating moskowitz-hip-07: IPv4 pseudo header In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C020AC0BB@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC0BB@xch-nw-27.nw.nos.boeing.com> Message-ID: <3F7807E4.9040100@nomadiclab.com> >>I propose that we change the text as follows: >> >> In case of using IPv4, the IPv4 UDP pseudo header format [RFC768] >> is used. In the pseudo header, the source and destination >> addresses are those used in the IP header, the zero field is >> obviously zero, the protocol is the HIP protcol number (TBD), >> and the length is calculated as in the IPv6 case. >> >>This would require a small change to the current implementations. > Another option may be to leave out the IP addresses from the IPv4 > HIP checksum (that's what HIP is all about, right? :). Well, I would not be willing to remove a feature that is present in all protocols that run over IP. (At least AFAIK; there may be protocols that do not have a CRC.) Even though packet corruption is very rare with current link and router technologies, it does happen. I'd rather drop a packet on a CRC check than to proceed and perhaps try to solve a very hard cookie before giving up. > Otherwise, I'm fine with the proposed change. OK, I will take this as a resolution for Issue 10a. We will use [RFC768] pseudo header format for HIP packets carried over IPv4. > I think that realistically > we should expect to tunnel HIP over UDP for IPv4 NAT traversal, in which > case the HIP checksum might be redundant, but if it comes to pass that > IPv4 NATs are HIP aware, it is reasonable to either a) make the > checksum rewriting the same as TCP/UDP or b) do not require them to > rewrite checksums by avoiding the pseudoheader construct or by using > dummy addresses in the pseudoheader. Now, carrying HIP over UDP is an interesting question. As I showed in my recent half-joke http://honor.trusecure.com/pipermail/hipsec/2003-September/000044.html it might be possible to run HIP masquareded as UDP, i.e., use UDP as the protocol number and then use "magic" port numbers to recognized that it is actually HIP. That is admittedly a hack. However, if we consider the situation more realistically, we do not need all fields from the HIP header if we run HIP over UDP. Instead, the result might look somewhat like the following: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source port | Destination port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | CRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HIP Controls | HIP pkt Type | Ver. | Res. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hence, the overhead caused by UDP would be just 4 bytes. Maybe we should specify that when you run HIP over IPv6, you use the extension header format, but when you run HIP over IPv4, you would carry it over UDP? Doesn't look like too hard to implement. Opinions? > Option b) might be more NAT friendly if the deployed base of NATs is > able to handle non TCP/UDP traffic by simply manipulating the IP header, > but I suspect that even avoidance of layer 4 manipulation will not be > sufficient to get through many legacy NATs. Agreed. --Pekka From pekka.nikander@nomadiclab.com Mon Sep 29 07:06:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Sep 29 06:06:01 2003 Subject: [Hipsec] Issue 5: Rules for extensions In-Reply-To: References: Message-ID: <3F780A4F.7080702@nomadiclab.com> Hi George, > I noticed that on the original post on this topic, the encoding > scheme allowed the combination "mandatory" and "private". In other IETF > protocols I've observed, this wasn't allowed. One could potentially > stumble across inter-op problems that might occur when Vendor X marks a > TLV mandatory and its implementation is proprietary. Since we are dealing with a security protocol, I think that it makes perfect sense to have a combination of "mandatory" and "private". As you notice, it will lead to the situation where the hosts fail to communicate, but that is most probably the desired behaviour. The reason for marking someting "mandatory" in a cryptographic protocol is that the option requires some positive action from the peer, or otherwise the protocol will not be secure. Maybe we should include some normative text making clear the conditions under which it is acceptable to define a "mandatory private" HIP parameter? And make those conditions fairly strict? Yet another issue: Maybe we should define an "Error" parameter, something similar to ICMP errors but carried if there *is* some existing keying material? (HIP uses currently ICMP if there is no keying material and no security assocation. This has its dangers, most of which are (hopefully) documented.) --Pekka Nikander From andrew@indranet.co.nz Mon Sep 29 07:21:00 2003 From: andrew@indranet.co.nz (Andrew McGregor) Date: Mon Sep 29 06:21:00 2003 Subject: [Hipsec] Updating moskowitz-hip-07: IPv4 pseudo header In-Reply-To: <3F7807E4.9040100@nomadiclab.com> References: <3F7807E4.9040100@nomadiclab.com> Message-ID: <302273606.1064875668@[192.168.1.250]> --On Monday, 29 September 2003 1:22 p.m. +0300 Pekka Nikander wrote: > OK, I will take this as a resolution for Issue 10a. > We will use [RFC768] pseudo header format for HIP > packets carried over IPv4. This sounds a lot like the right thing. > However, if we consider the situation more realistically, we do not > need all fields from the HIP header if we run HIP over UDP. Instead, > the result might look somewhat like the following: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Source port | Destination port | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Length | CRC | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | HIP Controls | HIP pkt Type | Ver. | Res. | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Hence, the overhead caused by UDP would be just 4 bytes. > Maybe we should specify that when you run HIP over IPv6, you use > the extension header format, but when you run HIP over IPv4, you > would carry it over UDP? Doesn't look like too hard to implement. > > Opinions? Let's try it and see, shall we? It's almost trivial for me, so I'll have a go before Minneapolis and try it with a few NATs. Andrew From gmgross@nac.net Mon Sep 29 07:24:01 2003 From: gmgross@nac.net (George Gross) Date: Mon Sep 29 06:24:01 2003 Subject: [Hipsec] LC: draft-moskowitz-hip-arch-04.txt ready for IESG? In-Reply-To: <3F77F6C2.1040102@nomadiclab.com> Message-ID: Hi Pekka, On Mon, 29 Sep 2003, Pekka Nikander wrote: > > In my opinion, this would be ready to be submitted to the IESG > to be considered for Informational. Not that it makes substantive difference, you may wish to consider publishing hip-arch as an Experimental RFC. br, George > From pekka.nikander@nomadiclab.com Mon Sep 29 07:34:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Sep 29 06:34:01 2003 Subject: [Hipsec] Issue 5: Rules for extensions In-Reply-To: <200309261546.01671.julien.laganier@sun.com> References: <3F732EB6.2050007@nomadiclab.com> <200309261546.01671.julien.laganier@sun.com> Message-ID: <3F7810F7.9060700@nomadiclab.com> Julien Laganier wrote: > One solution might be to define some Type prefixes for extensions, that make > regognition easier, for example: > > o 0x8 for standardized extensions that can be ignored > o 0x9 for private extensions that can be ignored > o 0xa for standardized extensions that cannot be ignored > o 0xb for private extensions that cannot be ignored > > That allows space for 2^12 = 4096 different subtypes under each prefixes while > not requiring renumbering of existing Types. I guess that would be sufficient > for quite a long time. I thought about that, but from my point of view it has two drawbacks: Firstly, the code would be somewhat more complex. But that is a minor one. A more serious one is that we require that the parameters are ordered in a strictly increasing order by their type values. Hence, allocating regions would make it hard to "insert" parameters between existing ones. I don't know how often such a feature would be needed, but perhaps sometimes. >> I would prefer 1), but it would require an incompatible >> change to the protocol. Can we still do that? Does anyone >> have any troubles if we do it? > > I have no troube with doing any of the above, so let's others people speak. I'd like to get word from the people actually doing implementations. Right now it looks like that -08 will contain a number of incompatible changes compared to -07. Hence, it looks improbable that we could reach full interoperability between -07 and -08 implementations. Hence, I don't know if changing the parameter type code values would be that bad at this stage. On the other hand, the base protocol does not change that much, so without this change -07 and -08 implementations might still be able to interoperate to an extend, at least when IPv6 is used. Right now my proposal is the following: 1. Use the low order bit to distinquish between mandator-to-recognize and ok-to-ignore parameters. 2. Reserve the ranges 0-511 and (2^16-512 - 2^16-1) for future base protocol extensions, to be assinged only through RFCs. 3. Define a range, e.g. (2^15) - (2^15+2^14-1) for experimentation and private extensions. 4. Make the rest assignable by IANA under some rules that prevent people from "hoarding" large amounts of type codes. Would that sound reasonable? --Pekka Nikander From pekka.nikander@nomadiclab.com Mon Sep 29 07:40:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Sep 29 06:40:01 2003 Subject: [Hipsec] HIP over UDP (was something else) In-Reply-To: <302273606.1064875668@[192.168.1.250]> References: <3F7807E4.9040100@nomadiclab.com> <302273606.1064875668@[192.168.1.250]> Message-ID: <3F78124F.1060306@nomadiclab.com> Andrew McGregor wrote: >> However, if we consider the situation more realistically, we do not >> need all fields from the HIP header if we run HIP over UDP. Instead, >> the result might look somewhat like the following: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Source port | Destination port | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Length | CRC | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | HIP Controls | HIP pkt Type | Ver. | Res. | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Hence, the overhead caused by UDP would be just 4 bytes. >> Maybe we should specify that when you run HIP over IPv6, you use >> the extension header format, but when you run HIP over IPv4, you >> would carry it over UDP? Doesn't look like too hard to implement. >> >> Opinions? > > Let's try it and see, shall we? It's almost trivial for me, so I'll > have a go before Minneapolis and try it with a few NATs. Ok. We'll implement it as well. Port number? Would that 272 be fine? I'll add the format as an appendix to -08. I think it is best to use the same port for both source and destination. I could add it to -08, and we could apply for the port from IANA, if the thing works. --Pekka Nikander From mbagnulo@ing.uc3m.es Mon Sep 29 07:41:01 2003 From: mbagnulo@ing.uc3m.es (marcelo bagnulo) Date: Mon Sep 29 06:41:01 2003 Subject: [Hipsec] RE: Security requirements for identification In-Reply-To: Message-ID: > > We should also preserve the security of communications that > don't use the > > DNS i.e. they use IP address directly. I mean, it is safer to > use directly > > IP addresses than using names (without DNS). This capability has to be > > preserved. This means that not only the chain starting from a FQDN and > > ending in the packet delivery has to remain as safe as it is > today, but also > > it has to be possible to establish a communication with the > same level of > > security of the one obtained today when sending packets directly to ip > > addresses without using the DNS. > > You use the term "IP address" which I've removed from > my vocabulary in this context; are you talking about an identifier or > a locator? I am considering the current use of ip addresses i.e. before the loc/id split, so ip addresses are both locators and identifiers. What i mean is that currenlty you can use ip addresses in order to obtain some added security. For instance you can use directly ip addresses (no FQDN) so that you don't have to turst in the DNS, and you can also use the IP address to allow incoming communications an so on. > > > Ok, this depends on what do you call stable. > > But, i guess we agree that in order to able to establish a > communication, > > the initiating party has to be capable of identifying the other > party, so > > that it can define who he wants to talk to. This means that some form of > > stable identifier is needed at least for the server party of the > > communication. > > Yes, but potentially such a number doesn't need to be globally unique. > I can envision potential solutions, their desirability aside, > where each server would pick a random number at its identifier > with no global coordination, publish that number in the DNS > (e.g. using a new ID record) together with the locators published as AAAA > records. > This would allow the client to use the fqdn to find both this identifier > and the locators for the service and communicate. Such "identifiers" do > not need to be globally unique, and they might change as frequently > as it is feasible to update the DNS ID record. > So I hope the above illustrates that there isn't an inherent requirement > from the multi6 problem set to make the identifiers globally > unique or stable. Actually what you are really doing is to use fqdn as permanent identifiers and the DNS as a rendez-vous system, so it provides you with the transient identifier and also with the locator. I mean, if you want to establish a communication with someone you already know, you need a mean to express his identity, and that is a permanent identifier. (the other option that i could think of are limited lifetime identifiers that overlap in time so that you can provide one and obtain the next one, which will be valid for the next period) However i think that we could focus on the case that atr least for some hosts, a permanent identifier is needed, or put it in another way, we can provide differents types of identifiers, but one of these types should be a permentent one. > > That doesn't mean that it is a good idea to make them unstable. > Since we need > to prevent redirection attacks there has to be a way to check who > is authorized > to redirect the packet flow for a given identifier to some new > locator. That > would be quite confusing if multiple nodes happen to use the same > identifier > while communicating with the same peer; "redirect packets for > id=X" would then > affect traffic to two separate nodes thus the authorization > question can't be > answered. > > So I think the multi6 problem set requires very low probability that two > nodes use the same identifier when communicating with a given peer. > > But I don't think it is until you also look at other problems, like > identifiers that can be used by applications for rendez-vous and referral, > that the stability issue comes to the forefront. But you need initial rendez vous if you want to provide a multi-homing solution that works, so it is part of the multi-homing problem > (One could argue that from the perspective of the UDP/IP stack, an > application over UDP behaves in ways that look like applications doing > rendez-vous; the only difference might be implicit assumptions about what > the elapsed time is between receiving something and trying to > send something > back.) > > So I'm all for stable identifiers for general application using being > part of the free lunch; but oops - there is no free lunch :-) > Thus we need to try to tease apart the different uses of identifiers > and understand the requirements a bit more. > > > Perhap we can see the IPv4 situation and evaluate which kind of > identifiers > > are needed. > > An intersting point is that some hosts never have a permanent > identifier and > > perhaps they don't need it (for instance hosts through dial-up > with dhcp) > > On the other hand, servers need stable identifiers so they can > be reached. > > But is this ("clients" not have stable IP or DNS names) a feature > or a bug? > > Turning things around, one could ask what the benefits would be of having > an identifier which 1) doesn't change when you change ISP and 2) doesn't > change due to some administrative mistake (like not renewing your domain > name with the registrar). > Agree, i can see many benefits in those cases, but are those features essential to a multi-homing solution? or are they just a nice-to-have feature? Would you inlcude them in the MUST list of a loc/id split solution for multi-homing? Thanks, marcelo > Erik > > From pekka.nikander@nomadiclab.com Mon Sep 29 07:42:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Sep 29 06:42:00 2003 Subject: [Hipsec] LC: draft-moskowitz-hip-arch-04.txt ready for IESG? In-Reply-To: References: Message-ID: <3F7812DE.3080904@nomadiclab.com> George, George Gross wrote: >>In my opinion, this would be ready to be submitted to the IESG >>to be considered for Informational. > > Not that it makes substantive difference, you may wish to consider > publishing hip-arch as an Experimental RFC. Would you please enlighten me about the difference? hip-arch doesn't specify a protocol, and I thought that Experimental are meant for protocols, i.e., documents that could perhaps be standards track but aren't for various reasons. But perhaps I am wrong, it's been ages since I last check the procedural RFcs. We are definitely planning to submit the actual base protocol spec as Experimental, as soon as it gets stable enough. Hopefully that will be soon, around the time of Minneapolis. The remaining issues seem to be resolvable. --Pekka Nikander From pekka.nikander@nomadiclab.com Mon Sep 29 08:00:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Sep 29 07:00:01 2003 Subject: [Hipsec] Issue 16: Details of LSI handling In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B5ACE@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B5ACE@xch-nw-27.nw.nos.boeing.com> Message-ID: <3F78171F.1020102@nomadiclab.com> Henderson, Thomas R wrote: > I still believe that this may be a non-issue. It may be. > Of course, this issue is tied to how people envision the HIP-enabled > sockets API for IPv4. Indeed. > We have taken the stance that LSIs are not > used in the sockaddr_in.sin_addr in socket calls-- if HIP is to be > used on a connection, it is flagged as such in the IPsec policy table > (which is based on IP addresses), and the kernel manages to do the right > thing. A clarifying question: How do you make sure that the two communicating hosts have the same idea of their IP addresses? That is, if you use IP addresses (instead of LSIs) in the IPv4 API, how do you make e.g. FTP or SIP to work? I am not saying that it is impossible, I am just stating that I don't understand how you do it. There are a number of current protocols that carry IP(v4) addresses in the payload. One of the reasons for using LSIs is to make these work. I don't personally care much about the v4 API, aspecially now that -08-per uses always HITs in the pseudo-header, and thereby allows v6 API apps to talk v4 API apps and vice versa. However, I have understood that some people do care, and quite a lot. Maybe it would be time for them to speak up again. --Pekka Nikander From mbagnulo@ing.uc3m.es Mon Sep 29 08:14:01 2003 From: mbagnulo@ing.uc3m.es (marcelo bagnulo) Date: Mon Sep 29 07:14:01 2003 Subject: [Hipsec] RE: Security requirements for identification In-Reply-To: <5921363068.20030926172837@brandenburg.com> Message-ID: Hi Dave, > > PN> Hence, for the purpose of mobility and multi-homing, the > PN> identification mechanism has to keep sure that the peer really > PN> remains the same, on all changes of locators. Furthermore, the > PN> mechanism must not blindly trust what the peer claims about its > PN> locations, but must check that the same peer really *is* > PN> at all the claimed addresses. > > Hmmm. Carried to the extreme the requirement seems to specify > would probably > require having every packet be encrypted -- so it could only be > decoded by the > correct recipient -- and acknowledged with a signature. > > At most, I suspect you really mean that there must be a "useful" > confirmation > when a new target address is used for the first time. For > example, if there > are nonce-based association identifiers, > > 1) the initiator using the target address for the first includes the > target's nonce in some sort of "hello again" packet, and > > 2) the target responds with a packet containing the initiator's nonce. > > This goes beyond the safety provided in current, mono-addressing IP, but > certainly is focused on problems caused (or exacerbated) by the > introduction > of multiaddressing. Not really. Current mono-addressing IP security relies on routing (id=loc so if you trust the routing system then it will deliver the packet to the correct IP==ID) So current mono-address ip does perform a verification that the other end of the communication remains the same in EVERY packet. This scheme of nonce validation only verifies the id of the other end at the begining of the communication (or when a new address is included). So, it is stronger for the moment when this exchange occurs, but it opens the possibility of attacks shifted in time, since this scheme does not verifies the identity all the time. So, the nonce based scheme it is stronger in one sense but it is weaker in another sense (To overcome this issue, mip demands a periodical exchange of nonces so that the identity of the other end of the communication is verified periodically) > > > PN> b) identification for referral or rendezvous > > PN> In the case of referral or rendezvous, an initiating party > PN> possesses an identifier that it wants to use as a means > PN> of identifying another party. > > In spite of the above language, you do not define rendezvous and > referral. I > have been assuming the latter means "moving an association from > one endpoint > to another". That is, "hand off" of one end of an association to a new > endpoint. > > So, please clarify what you mean by both terms and how they relate to the > distinction between identifying versus locating. > > I believe the two terms can, and should, refer to two different > things (unless > there is already an established practise of using them synonymously) > > Rendezvous is a means of one endpoint finding another. It often uses a > third-party intermediary. It may or may not occur when there already is > context between the two endpoints. > > Referral is a means by which one host in an association can replace itself > with another host. That is, it transfers the association context > to a third > host. > > > PN> If we assumed that everybody is honest, any unique bit > PN> string would serve well as an identifier. The initiating > PN> party just sends the bit string to the target party, and > PN> asks the target party to verify that the bit string really > PN> is its identifier. The problem is that we cannot necessarily > PN> assume everybody to be honest. > > PN> If we assume dishonest parties, we get two sub cases. In > PN> the first case, the initiating party must send the identifier > PN> in clear, for some reason, or the identifier is otherwise > PN> public and known by the dishonest parties. In the second > PN> case, the initiating party is able to keep the identifier in > PN> secret. > > This line of thinking appears to go quite a bit beyond the > current world of IP > mon-addressing. And I believe it involves concerns not created by > multiaddressing. > > However validly, we trust DNS entries and IP routing. As soon as > you worry > about whether to send an identifier in the clear, you are considering > something far broader than problems caused by multiaddressing. > I don't completelly agree. Today you can establish a communication using only an IP address (you can avoid using the DNS for security reasons) So i don't think is reasonable to say that all ip addresses are as weak as a communication that involves a dns query (if we can say this, the security problems would be greatly reduced). I do agree with the routing part. > > PN> In the first case, the only secure way of performing > PN> identification seem to be public key cryptography (or any of > PN> its variants, like zero knowledge protocol). The reason for > PN> this is the following. Since the identifier is public > PN> knowledge, we cannot use the identifier directly. > > Today, we use domain names and IP addresses in the clear. And things work > pretty well. > > To use Marcelo's phrasing, we do not "prove we own" the domain > names are IP > addresses we use. You do prove that you own the IP address, the routing system does it. About the DNS, see my comment below i.e. you can establish a communication without using the DNS today and i don't think it is reasonable to design a solution imposing the dns security level to all possible communications. (BTW I read the address ownership expression fro the first time in Pekka's draft "An Address Ownership Problem in IPv6" ()) Regards, marcelo > > So, why must we start encrypting identifiers? > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA > > From gmgross@nac.net Mon Sep 29 08:16:01 2003 From: gmgross@nac.net (George Gross) Date: Mon Sep 29 07:16:01 2003 Subject: [Hipsec] Issue 5: Rules for extensions In-Reply-To: <3F780A4F.7080702@nomadiclab.com> Message-ID: Hi Pekka, On Mon, 29 Sep 2003, Pekka Nikander wrote: > Hi George, > > > I noticed that on the original post on this topic, the encoding > > scheme allowed the combination "mandatory" and "private". In other IETF > > protocols I've observed, this wasn't allowed. One could potentially > > stumble across inter-op problems that might occur when Vendor X marks a > > TLV mandatory and its implementation is proprietary. > > Since we are dealing with a security protocol, I think that it makes > perfect sense to have a combination of "mandatory" and "private". > As you notice, it will lead to the situation where the hosts fail > to communicate, but that is most probably the desired behaviour. I took a look at the IKE-v2 draft in the hope of finding a precedent, and could only infer that setting "critical" for a proprietary payload was allowed; there didn't seem to be an explicit guidance. Perhaps the IPSEC archive has a thread on this topic but I didn't look.... In Diameter, there is the ability to negotiate mutually supported Vendor-specific AVP lexicons on a per session basis. Vendor IDs are assigned by an IANA SMI. The negotiation requires mutual configuration at the respective session endpoint management interfaces, and falls back to standard AVP only mode. In RFC2661 section 4.2 (for L2TP) it says: " Use of the M-bit with new AVPs (those not defined in this document) MUST provide the ability to configure the associated feature off, such that the AVP is either not sent, or sent with the M-bit not set. So bottom line is that setting any mandatory bit should be configurable on/off at the management interface for vendor-specific uses. In other words, the management interface MUST allow vanilla standards only mode as a default configuration setting, and MAY allow vendor-specific critical payloads to be configured on (and off). > > The reason for marking someting "mandatory" in a cryptographic protocol > is that the option requires some positive action from the peer, > or otherwise the protocol will not be secure. As per above, MPOV this is a security policy decision that must be configurable at the management interface. > > Maybe we should include some normative text making clear the > conditions under which it is acceptable to define a "mandatory private" > HIP parameter? And make those conditions fairly strict? yes, normative text should say this, in addition to what I mentioned earlier about the management interface. > > Yet another issue: Maybe we should define an "Error" parameter, > something similar to ICMP errors but carried if there *is* some > existing keying material? sounds alot like an IKE notify payload. Perhaps borrow from that arena? br, George > (HIP uses currently ICMP if there is > no keying material and no security assocation. This has its > dangers, most of which are (hopefully) documented.) > > --Pekka Nikander > > From gmgross@nac.net Mon Sep 29 08:33:00 2003 From: gmgross@nac.net (George Gross) Date: Mon Sep 29 07:33:00 2003 Subject: [Hipsec] LC: draft-moskowitz-hip-arch-04.txt ready for IESG? In-Reply-To: <3F7812DE.3080904@nomadiclab.com> Message-ID: Hi, On Mon, 29 Sep 2003, Pekka Nikander wrote: > George, > > George Gross wrote: > >>In my opinion, this would be ready to be submitted to the IESG > >>to be considered for Informational. > > > > Not that it makes substantive difference, you may wish to consider > > publishing hip-arch as an Experimental RFC. > > Would you please enlighten me about the difference? hip-arch > doesn't specify a protocol, and I thought that Experimental are > meant for protocols, i.e., documents that could perhaps be > standards track but aren't for various reasons. But perhaps > I am wrong, it's been ages since I last check the procedural > RFcs. I haven't looked to 2026 lately... I suppose it depends on whether HIP arch could ever transition to standards track when HIP gains enough critical mass to become mainstream. Analogous to RFC2401, you would want a standards track arch doc. I'd consult your local AD, or flip a coin ;o) br, George > From shep@alum.mit.edu Mon Sep 29 09:18:00 2003 From: shep@alum.mit.edu (Tim Shepard) Date: Mon Sep 29 08:18:00 2003 Subject: [Hipsec] HIP over UDP (was something else) In-Reply-To: Your message of Mon, 29 Sep 2003 14:06:55 +0300. <3F78124F.1060306@nomadiclab.com> Message-ID: <200309291244.h8TCimWB022122@ginger.lcs.mit.edu> Pekka Nikander wrote: > Andrew McGregor wrote: > >> However, if we consider the situation more realistically, we do not > >> need all fields from the HIP header if we run HIP over UDP. Instead, > >> the result might look somewhat like the following: > >> > >> 0 1 2 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Source port | Destination port | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Length | CRC | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | HIP Controls | HIP pkt Type | Ver. | Res. | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> Hence, the overhead caused by UDP would be just 4 bytes. > >> Maybe we should specify that when you run HIP over IPv6, you use > >> the extension header format, but when you run HIP over IPv4, you > >> would carry it over UDP? Doesn't look like too hard to implement. > >> > >> Opinions? > > > > Let's try it and see, shall we? It's almost trivial for me, so I'll > > have a go before Minneapolis and try it with a few NATs. > > Ok. We'll implement it as well. Port number? Would that 272 be fine? > I'll add the format as an appendix to -08. I think it is best to use > the same port for both source and destination. > If I understand correctly, the purpose of using UDP is to make HIP work when you are behind a NAT. But if you specify what port numbers you use, then are you precluding being able to use HIP from behind a NAT on more than one host? I though I knew how NATs usually handled UDP ports, but now your message has me wondering. If the NAT is going to rewrite the source port on outgoing packets, and use the destination port on incoming packets to determine the ultimate destination (just like what NATs do with TCP), then we're going to need a way to tell the other end not just what IPv4 addresses we can be reached at, but also what IPv4 addresses and UDP port numbers we can be reached at. But how can you when you are behind a NAT learn what these are? Or will it just be implicit that if you receive a packet from a UDP port number at some IPv4 address, then we assume that the far end is behind a NAT and add that to their list of addresses. (Or perhaps even send them a helpful message saying "I heard you at IPv4 address foo UDP port bar.") If the NAT isn't rewriting the UDP port numbers but instead uses memory of recent outbound UDP traffic to decide how to route the incoming UDP traffic, then how are we going to get the traffic to come to us if the node we are corresponding with has moved and now has a different address. Even if the NAT box is rewriting port numbers, we may find that we are unable to get all the appropriate HIP traffic to come our way. The ESP traffic is also an issue. Experiments will be valuable. How much do different real-world NATs vary in how they handle all these issues? -Tim Shepard shep@alum.mit.edu From thomas.r.henderson@boeing.com Mon Sep 29 13:00:01 2003 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Mon Sep 29 12:00:01 2003 Subject: [Hipsec] Issue 16: Details of LSI handling Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B5AF1@xch-nw-27.nw.nos.boeing.com> PN> A clarifying question: How do you make sure that the two PN> communicating hosts have the same idea of their IP addresses? PN> That is, if you use IP addresses (instead of LSIs) in the IPv4 PN> API, how do you make e.g. FTP or SIP to work? PN>=20 PN> I am not saying that it is impossible, I am just stating that PN> I don't understand how you do it. PN>=20 PN> There are a number of current protocols that carry IP(v4) PN> addresses in the payload. One of the reasons for using LSIs PN> is to make these work. I have not seen a perfect solution to this problem. In our=20 discussions in SF, there were two schools of thought, if I recall=20 correctly: i) have resolver return an LSI in place of an actual IP address,=20 and have applications use the LSI instead of the IP address in=20 socket calls. By making LSI fall into an unassigned IP address=20 space, the kernel could distinguish between calls made with an LSI=20 and calls made with an IP address. Now some complications with=20 this approach are: - one probably does not want to invoke a HIP exchange just because=20 someone did a DNS lookup on a hostname (applications use resolver=20 for other reasons than just prior to initiating a flow). Since we made the LSIs a subset of the HIT bits, we could avoid having to do the HIP exchange to find the LSIs, if it weren't for the possibility of collision (the problem with which Pekka started=20 this thread). So this approach seems to be pointing us towards doing HIP exchanges prior to the application's initial socket calls. Note that this would also break the opportunity to piggyback data on the I2/R2. - what happens if kernel is presented with an LSI for which it=20 has no HIP or IP address information cached? - some applications might actually want IP addresses explicitly, such as diagnostic applcations. - some applications likely will obtain addresses out-of-band, so even in this scenario, the kernel may be faced with a case where it would like to use HIP from a policy standpoint, but the=20 invoking application called connect() with an IP address. One way around might be to have a separate resolver call that returns an LSI, or enhance the data structure returned by resolver to include LSI in addition to IP address, but this then throws the=20 burden on applications to be HIP-aware. ii) have HIP be kept in kernel land, with the kernel doing the=20 right housekeeping. Unless the application is HIP aware and can explicitly signal that it wants to use HIP (such as with a setsockopt() flag), the use of HIP is coordinated by a policy table that temporarily traps packets going to particular IP addresses until a HIP exchange completes and the security=20 association is set up. In this case, the kernel does the right checksum munging and handles readdressing, in a manner transparent to the applications, which just think that they have connected to an IP address as before. This essentially means that the kernel is responsible for managing the association between=20 IP address (as perceived by an application) and actual destination identity. Although this is similar to the way that opportunistic IPsec works today, this solution has the following drawbacks: - one is architecturally forced back into the mode of using IP addresses to indirectly identify hosts, at least initially. =20 The IP stack has to maintain tables that say things like "if=20 a socket call comes in for address X, do a HIP exchange to that=20 address." (note that this may require an opportunistic exchange) This constrains the kinds of mobility that the system can handle. =20 - one can construct scenarios for which the kernel and applications are out of sync with respect to IP addresses, and flows may escape their intended IPsec envelope. Example: I open FTP control connection to address X. That host moves to address Y. Some other host takes up address X. I next receive a connect() to address X. Which host does that process want to connect to? Long term, I'd like to see host identity information exposed to=20 applications and explicitly used in socket calls, together with IP addresses if need be, rather than the workarounds described above. =20 If the applications and sockets API are not HIP-aware, then it seems=20 to lead to problems whether one spoofs the IP address to the=20 applications or whether one tries to keep HIP under the hood at all times.=20 For the time being (without changing applications), I favor approach=20 ii) above, because I haven't seen anyone effectively solve all of the=20 issues associated with i), and because ii) basically works without=20 changes to the applications except for some corner cases that we=20 haven't encountered. Whichever solution we adopt, we probably should document the various limitations or restrictions on use.=20 Tom From Erik Nordmark Tue Sep 30 01:39:00 2003 From: Erik Nordmark (Erik Nordmark) Date: Tue Sep 30 00:39:00 2003 Subject: [Hipsec] RE: Security requirements for identification In-Reply-To: "Your message with ID" Message-ID: > > So I hope the above illustrates that there isn't an inherent requirement > > from the multi6 problem set to make the identifiers globally > > unique or stable. > > Actually what you are really doing is to use fqdn as permanent identifiers > and the DNS as a rendez-vous system, so it provides you with the transient > identifier and also with the locator. Yes. > I mean, if you want to establish a communication with someone you already > know, you need a mean to express his identity, and that is a permanent > identifier. Terminology issue alert. It is presumably sufficient to express a name (and there can be a many to one mapping from name to identity.) > (the other option that i could think of are limited lifetime identifiers > that overlap in time so that you can provide one and obtain the next one, > which will be valid for the next period) > However i think that we could focus on the case that atr least for some > hosts, a permanent identifier is needed, or put it in another way, we can > provide differents types of identifiers, but one of these types should be a > permentent one. Agreed. But what does permanence mean? I think we would all agree that having it be stable across changing ISP connectivity, whether due to multihoming or renumbering, is a useful characteristic. Is it also useful to have it be independent of your fqdn so that if you forgot to pay the registration fees or there is a domain name dispute, you would still retain your IP level identifier? > > But I don't think it is until you also look at other problems, like > > identifiers that can be used by applications for rendez-vous and referral, > > that the stability issue comes to the forefront. > > But you need initial rendez vous if you want to provide a multi-homing > solution that works, so it is part of the multi-homing problem Not so fast. If you want to understand the space of epehemeral identifiers you need to dive a bit deeper. In that space the identifier might not be needed before communication is established, but can actually be exchanged as part of establishing the communication between two hosts. A concrete example would using FQDNs to find an (initial, possibly not all working) set of locators and then exchanging the identifiers of the endpoints by the peers communicating. (There are of course several issues in here, such as needing the know the identifiers in order to get things like TCP initial state established, but it is still useful to understand that emphemeral identifier corner of the design space.) > > Turning things around, one could ask what the benefits would be of having > > an identifier which 1) doesn't change when you change ISP and 2) doesn't > > change due to some administrative mistake (like not renewing your domain > > name with the registrar). > > > > Agree, i can see many benefits in those cases, but are those features > essential to a multi-homing solution? or are they just a nice-to-have > feature? Would you inlcude them in the MUST list of a loc/id split solution > for multi-homing? I think it is part of the tradeoffs in this space. Having them be independent of your ISP(s) is probably something many want, so perhaps we must make that. If it is realatively inexpensive (in terms of complexity, overhead, deployment constraints, etc) to make it independent of some "registry infrastructure" that would be a useful thing. Another tradeoffs with high-level visibility are: - whether the ID can be used as the solve information to initiate communication with the entity. (one can envision solutions where one can verify that a peer using a ID is in fact the same entity that used it a long time ago, without being able to use the identifier itself to find the location of the entity.) Erik From Julien.Laganier@Sun.COM Tue Sep 30 03:45:01 2003 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Tue Sep 30 02:45:01 2003 Subject: Fwd: Re: [Hipsec] Issue 16: Details of LSI handling Message-ID: <200309300911.44088.julien.laganier@sun.com> --Boundary_(ID_uqiUHewbVvva+IfHiYGdlQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Folks, [ Sorry for the late reply but I forget hipsec on CC. ] --Boundary_(ID_uqiUHewbVvva+IfHiYGdlQ) Content-type: message/rfc822; name="forwarded message" Content-description: Julien Laganier : Re: [Hipsec] Issue 16: Details of LSI handling Date: Fri, 26 Sep 2003 16:17:22 +0200 From: Julien Laganier Subject: Re: [Hipsec] Issue 16: Details of LSI handling In-reply-to: <3F73E54E.7020308@nomadiclab.com> To: Pekka Nikander Message-id: <200309261617.22511.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.5.3 X-KMail-Transport: SUNW X-KMail-Link-Message: 217430 X-KMail-Link-Type: reply X-KMail-EncryptionState: X-KMail-SignatureState: References: <3F73E54E.7020308@nomadiclab.com> X-Status: S Status: RO Pekka, Some thoughts below, On Friday 26 September 2003 09:05, Pekka Nikander wrote: > What to do? > ----------- > > I am pretty unsure what to do. Initially there is unlikely > to be problems. If the hosts select the non-default LSIs > randomly, we will just see a few HIP connections to fail > every now and then. > > There is certainly a place for improvement, but I haven't been > able to find one that would be simple and elegant. Given > that collisions will be fairly rare, I would like the mechanism > to be extremely simple, even if possibly somewhat inefficient. > On the other hand, requiring a full new protocol run seems > like an overkill. > > One option is just to document the situation and leave it > open for further experimentation. > > Any opinions? Any nice schemes that would allow us to > solve this problem? A solution I see is to put some signalling stuff in the HIP control bits: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |P|C| | | | |L| | | | | | |E|A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L: LSI unavailable, already used to represent another host. In case of collision: o the responder would send back I2 to the initiator with L bit set o the initiator would send back R2 to the responder with L set. While sending back these packets, the sender should replace by their own the SIGNATURE and HOST_ID parameters in I2 and R2. Receiving these packets, the implementation can then select another LSI to represent itself and send back the I2 or R2 packets for another try (and have a maximum number of them). This seems to avoid to run the full exchange again, it's only a round-trip long, and it does not require heavy modifications in the protocol, while being compatible with legacy implementations (they would drop the sent-back I2 or R2). Any opinions on that? Thanks, --julien --Boundary_(ID_uqiUHewbVvva+IfHiYGdlQ)-- From pekka.nikander@nomadiclab.com Tue Sep 30 04:11:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Sep 30 03:11:01 2003 Subject: [Hipsec] Issue 5: Rules for extensions In-Reply-To: References: Message-ID: <3F793302.8030009@nomadiclab.com> George and Juline, I wrote the following text to the draft. Ok? 6.2.1 TLV format [snip] 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |C| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Contents / / +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Type code for the parameter C Critical. Zero if this parameter is critical, and MUST be recognized by the recipient, one otherwise. The C bit is considered to be a part of the Type field. Consequently, critical parameters are always even and non-critical have an odd value. Length Length of the parameter, in bytes. Contents Parameter specific, defined by Type Padding Padding, 0-7 bytes, added if needed Critical parameters MUST be recognized by the recipient. If a recipient encounters a critical parameter that it does not recognize, it MUST NOT process the packet any further. Non-critical parameters MAY be safely ignored. If a recipient encounters a non-critical parameter that it does not recognize, it SHOULD proceed as if the parameter was not present in the received packet. 6.2.2 Defining new parameters Future specifications may define new parameters as needed. When defining new parameters, care must be taken to ensure that the parameter type values are appropriate and leave suitable space for other future extensions. One must remember that the parameters MUST always be arranged in the increasing order by the type code, thereby limiting the order of parameters. The following rules must be followed when defining new parameters. 1. The low order bit C of the Type code is used to distinquish between critical and non-critical parameters. 2. A new parameter may be critical only if an old recipient ignoring it would cause security problems. In general, new parameters SHOULD be defined as non-critical, and expect a reply from the recipient. 3. If a system implements a new critical parameter, it MUST provide the ability to configure the associated feature off, such that the critical parameter is not sent at all. The configuration option must be well documented. By default, sending of such a new critical parameter SHOULD be off. In other words, the management interface MUST allow vanilla standards only mode as a default configuration setting, and MAY allow new critical payloads to be configured on (and off). 4. The following type codes are reserved for future base protocol extensions, and may be assigned only through an appropriate WG or RFC action. 0 - 511 65024 - 65535 5. The following type codes are reserved for experimentation and private use. Types SHOULD be selected in a random fashion from this range, thereby reducing the probability of collisions. A method employing genuine randomness (such as flipping a coin) SHOULD be used. 32768 - 49141 6. All other parameter type codes MUST be registed by the IANA. See Section 14. From pekka.nikander@nomadiclab.com Tue Sep 30 04:51:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Sep 30 03:51:01 2003 Subject: [Hipsec] HIP over UDP (was something else) In-Reply-To: <200309291244.h8TCimWB022122@ginger.lcs.mit.edu> References: <200309291244.h8TCimWB022122@ginger.lcs.mit.edu> Message-ID: <3F793C4D.4090207@nomadiclab.com> Tim Shepard wrote: > If I understand correctly, the purpose of using UDP is to make HIP > work when you are behind a NAT. But if you specify what port numbers > you use, then are you precluding being able to use HIP from behind a > NAT on more than one host? Well, we have to specify the destination port number anyway. I also think that it is good to define the default source port number, making operations simpler if there are no NATs. > I though I knew how NATs usually handled UDP ports, but now your > message has me wondering. If the NAT is going to rewrite the source > port on outgoing packets, and use the destination port on incoming > packets to determine the ultimate destination (just like what NATs do > with TCP), then we're going to need a way to tell the other end not > just what IPv4 addresses we can be reached at, but also what IPv4 > addresses and UDP port numbers we can be reached at. Exactly. > But how can you when you are behind a NAT learn what these are? In the general case you can't. However, your peer will be able to, since it will see your I1 with the modified source address and port number. > Or will it just be implicit that if you receive a packet from a UDP > port number at some IPv4 address, then we assume that the far end is > behind a NAT and add that to their list of addresses. (Or perhaps > even send them a helpful message saying "I heard you at IPv4 address > foo UDP port bar.") That was more or less my thought; I don't know about Tom or Andrew. > If the NAT isn't rewriting the UDP port numbers but instead uses > memory of recent outbound UDP traffic to decide how to route the > incoming UDP traffic, That's my understanding of what NATs typically do. > then how are we going to get the traffic to come to us if the node we > are corresponding with has moved and now has a different address. The moved host needs to send a REA. The REA will (again) have a funny source port, in the typical case. > Even if the NAT box is rewriting port numbers, we may find that we > are unable to get all the appropriate HIP traffic to come our way. > The ESP traffic is also an issue. Indeed. And I don't have any answers for ESP right now. According to my understanding, all the current standards for tunneling ESP over UDP via NATs have IPRs attached. But I may well be wrong. > Experiments will be valuable. How much do different real-world NATs > vary in how they handle all these issues? I have no idea. I simply added the following appendix to the 08-pre. If people are unhappy with this, I can easily remove or modify it. IMHO we need to eventually specify this in a different document, but the following appendix just defines the current thinking. -------------------------- Appendix E. Running HIP over IPv4 UDP In the IPv4 world, with the deployed NAT devices, it may make sense to run HIP over UDP. When running HIP over UDP, the following packet structure is used. The structure is followed by the HITs, as usual. Both the Source and Destionation port MUST be 272. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | Source port | Destination port | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >UDP | Length | CRC | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+< | HIP Controls | HIP pkt Type | Ver. | Res. | > HIP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ It is currently undefined how the actual data transfer, using ESP, is handled. Plain ESP may not go through all NAT devices. It is currently FORBIDDEN to use this packet format with IPv6. --------------------------- --Pekka Nikander From Julien.Laganier@Sun.COM Tue Sep 30 05:14:01 2003 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Tue Sep 30 04:14:01 2003 Subject: [Hipsec] Issue 5: Rules for extensions In-Reply-To: <3F793302.8030009@nomadiclab.com> References: <3F793302.8030009@nomadiclab.com> Message-ID: <200309301041.12032.julien.laganier@sun.com> On Tuesday 30 September 2003 09:38, Pekka Nikander wrote: > George and Julien, > > I wrote the following text to the draft. Ok? Pekka, The new text is fine with me. Thanks, --julien > 6.2.1 TLV format > > [snip] > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type |C| Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > / Contents / > / +-+-+-+-+-+-+-+-+ > > | | Padding | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type Type code for the parameter > C Critical. Zero if this parameter is critical, and > MUST be recognized by the recipient, one otherwise. > The C bit is considered to be a part of the > Type field. > Consequently, critical parameters are always even > and non-critical have an odd value. > Length Length of the parameter, in bytes. > Contents Parameter specific, defined by Type > Padding Padding, 0-7 bytes, added if needed > > Critical parameters MUST be recognized by the recipient. If a > recipient encounters a critical parameter that it does not recognize, > it MUST NOT process the packet any further. > > Non-critical parameters MAY be safely ignored. If a recipient > encounters a non-critical parameter that it does not recognize, it > SHOULD proceed as if the parameter was not present in the received > packet. > > 6.2.2 Defining new parameters > > Future specifications may define new parameters as needed. When > defining new parameters, care must be taken to ensure that the > parameter type values are appropriate and leave suitable space for > other future extensions. One must remember that the parameters MUST > always be arranged in the increasing order by the type code, thereby > limiting the order of parameters. > > The following rules must be followed when defining new parameters. > > 1. The low order bit C of the Type code is used to distinquish > between critical and non-critical parameters. > > 2. A new parameter may be critical only if an old recipient ignoring > it would cause security problems. In general, new parameters > SHOULD be defined as non-critical, and expect a reply from the > recipient. > > 3. If a system implements a new critical parameter, it MUST provide > the ability to configure the associated feature off, such that > the critical parameter is not sent at all. The configuration > option must be well documented. By default, sending of such a > new critical parameter SHOULD be off. In other words, the > management interface MUST allow vanilla standards only mode as a > default configuration setting, and MAY allow new critical > payloads to be configured on (and off). > > 4. The following type codes are reserved for future base protocol > extensions, and may be assigned only through an appropriate WG or > RFC action. > > 0 - 511 > 65024 - 65535 > > 5. The following type codes are reserved for experimentation and > private use. Types SHOULD be selected in a random fashion from > this range, thereby reducing the probability of collisions. A > method employing genuine randomness (such as flipping a coin) > SHOULD be used. > > 32768 - 49141 > > 6. All other parameter type codes MUST be registed by the IANA. See > Section 14. -- Julien Laganier From mkomu@niksula.hut.fi Tue Sep 30 06:49:00 2003 From: mkomu@niksula.hut.fi (Miika Komu) Date: Tue Sep 30 05:49:00 2003 Subject: [Hipsec] Issue 16: Details of LSI handling In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B5AF1@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B5AF1@xch-nw-27.nw.nos.boeing.com> Message-ID: On Mon, 29 Sep 2003, Henderson, Thomas R wrote: > PN> There are a number of current protocols that carry IP(v4) > PN> addresses in the payload. One of the reasons for using LSIs > PN> is to make these work. > TH> I have not seen a perfect solution to this problem. In our TH> discussions in SF, there were two schools of thought, if I recall TH> correctly: I think we need to take the best of the two schools of thought and avoid the worst. We also may want an extra layer of indirection. I begun doing my thesis on the HIP native API in the beginning of the summer, but I haven't progressed very far yet because I have been swamped with other work. I have to present some of the ideas from my thesis related to the discussion before I can quote Thomas more. Many of the ideas are from Jukka and Pekka (= my instructors). The mistakes, however, are my own. What is needed? In the HIP world, we want the applications to be independent of the IP layer in the HIP world. "Independent" here means that the applications _can_ use IP addresses directly if they want to but they can do just fine without. Why is it needed? a) To ease up the transition from IPv4 to IPv6. Later on we could have even IPvX but if we keep mangling the applications to specific versions of IP, we will never learn. Surely, there are some applications that should be aware of IP addresses but most network applications can do just fine without them. b) HIP requires something else than just the IP addresses to be _fully_ functional. If we feed the socket interface just IP addresses, we will get into trouble with mobility (see the bullet points in the "ii" alternative from Thomas). How can it be done? The IP addresses are hidden from the applications that do not explicitly want them. This is accomplished by introducing a new socket address family "AF_HIP" (for use with socket(2)) and the corresponding socket structure "sockaddr_hip". The socket structure does not contain any IP addresses but instead contains a file descriptor (Host Identity Descriptor, HID) which is effectively a "virtual" pointer to a host identity (sockaddr_hip should probably contain the port number redundantly for backwards compatibility, but that is a bit off-the-topic). A totally new resolver function is probably needed because the resolver needs to do more things than a standard resolver. Typically the new HIP resolver inputs a FQDN name of the peer to be resolved and outputs a HID into a sockaddr_hip. The identities of the localhost can be queried with a separate function. The locahost/remote socket addresses can then be fed to the bind(2), connect(2), send(2), recv(2), etc. Under the hood of the resolver, the resolver queries the DNS for the Host Identity and the locators (IP addresses) of the peer. It sends the Host Identity and the locators to the HIP module and in return, receives a HID. It must send the HI and the locators to the HIP module or otherwise HIP module won't be able to identify and locate the peer. The lower layer details are hidden in the interface. This does not mean that they cannot be revealed at all to the application: there is another interface (a set of functions) for tweaking, for example, the IP addresses under the hood. (This was my current view of thinking about the API and it may be out of sync with the current views of Pekka or Jukka because the API has been frozen for a while. Back to quoting Thomas.) TH> i) have resolver return an LSI in place of an actual IP address, TH> and have applications use the LSI instead of the IP address in TH> socket calls. By making LSI fall into an unassigned IP address TH> space, the kernel could distinguish between calls made with an LSI TH> and calls made with an IP address. Now some complications with TH> this approach are: This not part of the native API I just described. This is a "legacy" API, that is, we do not want to change application code. TH> - one probably does not want to invoke a HIP exchange just because TH> someone did a DNS lookup on a hostname (applications use resolver TH> for other reasons than just prior to initiating a flow). This is correct. TH> Since we made the LSIs a subset of the HIT bits, we could avoid TH> having to do the HIP exchange to find the LSIs, if it weren't for TH> the possibility of collision (the problem with which Pekka started TH> this thread). So this approach seems to be pointing us TH> towards doing HIP exchanges prior to the application's initial TH> socket calls. Note that this would also break the opportunity TH> to piggyback data on the I2/R2. Breaking the piggypacking option is a performance drawback and thereby it should be avoided. I think that the LSI collision problem can be overcome with some method (Julien Laganier posted a solution for it) so that the base exchange can be triggered on socket calls. Anyway, that is a very good point you made! I haven't really thought about that about triggering the base exchange before the socket calls... TH> - what happens if kernel is presented with an LSI for which it TH> has no HIP or IP address information cached? Houston, we have a problem!) Currently, the LSI is just a partial, temporary identifier and there is no guarantee that it can be resolved to anything reasonable. One should use full identifiers, and most preferably FQDNs because currently only they can be resolved to any of the other forms (HIT, IP, LSI). The best thing would be to use the native API to hide the LSI details :) TH> - some applications might actually want IP addresses explicitly, TH> such as diagnostic applcations. TH> - some applications likely will obtain addresses out-of-band, so TH> even in this scenario, the kernel may be faced with a case where TH> it would like to use HIP from a policy standpoint, but the TH> invoking application called connect() with an IP address. Yes, there is a minor conflict here: should the legacy resolver return LSIs or IP addresses by default? This is not an issue in the HIP native resolver because the application using it is assumed to want HIP anyway. TH> One way around might be to have a separate resolver call that TH> returns an LSI, or enhance the data structure returned by resolver TH> to include LSI in addition to IP address, but this then throws the TH> burden on applications to be HIP-aware. In this way of thinking, the resolver should return also a HIT. I would prefer that the new resolver communicates the LSIs and HITs directly to the HIP module. This way the application can even be non-HIP-aware if that is wanted. I don't think it is a bad idea to make the network applications HIP-aware, or at least some of them. The applications may gain a better control of the extra HIP layer by using the native API. The applications using the native HIP API may even have their own application specific identities, but that is a bit off-the-topic... TH> ii) have HIP be kept in kernel land, with the kernel doing the TH> right housekeeping. Unless the application is HIP aware and TH> can explicitly signal that it wants to use HIP (such as with TH> a setsockopt() flag), the use of HIP is coordinated by a policy TH> table that temporarily traps packets going to particular IP TH> addresses until a HIP exchange completes and the security TH> association is set up. In this case, the kernel does the right TH> checksum munging and handles readdressing, in a manner transparent TH> to the applications, which just think that they have connected TH> to an IP address as before. This essentially means that the TH> kernel is responsible for managing the association between TH> IP address (as perceived by an application) and actual destination TH> identity. Although this is similar to the way that opportunistic TH> IPsec works today, this solution has the following drawbacks: TH> - one is architecturally forced back into the mode of using IP TH> addresses to indirectly identify hosts, at least initially. TH> The IP stack has to maintain tables that say things like "if TH> a socket call comes in for address X, do a HIP exchange to that TH> address." (note that this may require an opportunistic exchange) TH> This constrains the kinds of mobility that the system can handle. TH> - one can construct scenarios for which the kernel and applications TH> are out of sync with respect to IP addresses, and flows may TH> escape their intended IPsec envelope. Example: I open FTP TH> control connection to address X. That host moves to address Y. TH> Some other host takes up address X. I next receive a connect() TH> to address X. Which host does that process want to connect to? This is correct. Don't do this unless you are ready to accept a lower level of security and mobility support. TH> Long term, I'd like to see host identity information exposed to TH> applications and explicitly used in socket calls, together with IP TH> addresses if need be, rather than the workarounds described above. TH> If the applications and sockets API are not HIP-aware, then it seems TH> to lead to problems whether one spoofs the IP address to the TH> applications or whether one tries to keep HIP under the hood TH> at all times. I'd like to keep HIP under the hood but make there a button the applications can push to pop the hood for twiddling with the engine. There is no need for the most of the application to see under the hood, they just need to drive the network car ;) TH> For the time being (without changing applications), I favor approach TH> ii) above, because I haven't seen anyone effectively solve all of the TH> issues associated with i), and because ii) basically works without TH> changes to the applications except for some corner cases that we TH> haven't encountered. Whichever solution we adopt, we probably should TH> document the various limitations or restrictions on use. I will try out the option iii and see how it goes (I am open to any suggestions and feedback). And yes, we need to document the API whatever it is going to be. Hopefully my thesis will serve as a background work for writing later on a official HIP socket API draft... P.S. Sorry for bloated answer, I just could not squeeze it any shorter ;) -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From gmgross@nac.net Tue Sep 30 09:33:00 2003 From: gmgross@nac.net (George Gross) Date: Tue Sep 30 08:33:00 2003 Subject: [Hipsec] Issue 5: Rules for extensions In-Reply-To: <3F793302.8030009@nomadiclab.com> Message-ID: Hi Pekka, your proposed text for TLV encoding and extensions is very good. thank you, George From mbagnulo@ing.uc3m.es Tue Sep 30 11:12:01 2003 From: mbagnulo@ing.uc3m.es (marcelo bagnulo) Date: Tue Sep 30 10:12:01 2003 Subject: [Hipsec] RE: Security requirements for identification In-Reply-To: Message-ID: Hi Erik, > > > > So I hope the above illustrates that there isn't an inherent > requirement > > > from the multi6 problem set to make the identifiers globally > > > unique or stable. > > > > Actually what you are really doing is to use fqdn as permanent > identifiers > > and the DNS as a rendez-vous system, so it provides you with > the transient > > identifier and also with the locator. > > Yes. > > > I mean, if you want to establish a communication with someone > you already > > know, you need a mean to express his identity, and that is a permanent > > identifier. > > Terminology issue alert. It is presumably sufficient to express a name > (and there can be a many to one mapping from name to identity.) Good point. I guess that we can try to be a bit more precise about this: As you mention, there are multiple times that i don't really need to know the identifier of the end-point that i want to communicate to, but what i want is the identifier of the service that i want to contact (is this what you meant?) So in this case, the fqdn act as a service identifier. So if i have a permanent service identifier (i.e. a fqdn), it is enough to have ephemeral end-points identifier, since when i want to establish a communication with a given service i just look for the currently valid ephermeral endpoint identifier. The next question then is whether this is enough... I mean can we just live with ephemeral endpoint identifiers and stable service identifiers? > > > (the other option that i could think of are limited lifetime identifiers > > that overlap in time so that you can provide one and obtain the > next one, > > which will be valid for the next period) > > However i think that we could focus on the case that atr least for some > > hosts, a permanent identifier is needed, or put it in another > way, we can > > provide differents types of identifiers, but one of these types > should be a > > permentent one. > > Agreed. > But what does permanence mean? > I think we would all agree that having it be stable across changing ISP > connectivity, whether due to multihoming or renumbering, is a useful > characteristic. > Is it also useful to have it be independent of your fqdn so that > if you forgot > to pay the registration fees or there is a domain name dispute, you would > still retain your IP level identifier? > > > > > But I don't think it is until you also look at other problems, like > > > identifiers that can be used by applications for rendez-vous > and referral, > > > that the stability issue comes to the forefront. > > > > But you need initial rendez vous if you want to provide a multi-homing > > solution that works, so it is part of the multi-homing problem > > Not so fast. If you want to understand the space of epehemeral identifiers > you need to dive a bit deeper. > In that space the identifier might not be needed before communication > is established, but can actually be exchanged as part of establishing > the communication between two hosts. > A concrete example would using FQDNs to find an (initial, > possibly not all > working) set of locators and then exchanging the identifiers of the > endpoints by the peers communicating. Not so sure, i mean, you are using the fqdn to make the initial contact, so the fqdn is an permanent identifier. You can consider that the fqdn is a service identifier. Ok, then when contact the other end through the locators that you have obtained through the DNS, you will exchange a ephemeral identifier, but this ephemeral identifier is a *service* ephemeral identifier, isn't it? i mean you know that a service is at given location and then you exchange an identifier to be sure that you always talk to the same entity, this would be a service identifier, i guess. So the point is, you can use a fqdn as a service or endpoint stable identifier and then exchange service or endpoint ephemeral identifiers, but you always need the stable identifier to make initial contact, so you can express who do you want to talk to. > (There are of course several issues in here, such as needing the know > the identifiers in order to get things like TCP initial state established, > but it is still useful to understand that emphemeral identifier corner of > the design space.) > > > > > Turning things around, one could ask what the benefits would > be of having > > > an identifier which 1) doesn't change when you change ISP and > 2) doesn't > > > change due to some administrative mistake (like not renewing > your domain > > > name with the registrar). > > > > > > > Agree, i can see many benefits in those cases, but are those features > > essential to a multi-homing solution? or are they just a nice-to-have > > feature? Would you inlcude them in the MUST list of a loc/id > split solution > > for multi-homing? > > I think it is part of the tradeoffs in this space. > Having them be independent of your ISP(s) is probably something many want, > so perhaps we must make that. > If it is realatively inexpensive (in terms of complexity, > overhead, deployment > constraints, etc) to make it independent of some "registry infrastructure" > that would be a useful thing. > > Another tradeoffs with high-level visibility are: > - whether the ID can be used as the solve information to initiate > communication > with the entity. > (one can envision solutions where one can verify that a peer using a > ID is in fact the same entity that used it a long time ago, without > being able to use the identifier itself to find the location of the > entity.) Been re-reading JNC's Endpoints and Endpoint's Names where there is a great compilation of many relevant characteristics of the endpoint identifer, where most of these are included somehow, and the point is that there are many aspects to consider. So my question is whether we should focus on providing a multi-homing solution based on the loc/id split or we should design a loc/id split that covers as many as possible of the apsects related with the overloaded model of identifiers in current IP, such as the ones that you mention or the ones covered in JNC's paper. Clearly the second option seems the wise thing to do, but there are many operational issues here, such the time requiered for this (during this time we will not provide a multi-homing solution which seems to be a pressing issue right now), the appropriate forum for this (not only because of the formal issues related to this, but more because of the people that should be involved and whose opinions are relevant for this, may not be here). So perhaps the practical thing to do is to provide a multi-homing solution now, focusing only on multi-homing problems. Regards, marcelo > > Erik >