[Hipsec] comments on new HIP draft

From: Henderson, Thomas R <thomas.r.henderson(at)boeing.com>
Date: Tue Mar 18 2003 - 00:22:57 EST

Comments on draft-moscowitz-hip-06
March 16, 2003
(Miika Komu, Andrew McGregor, Petri Jokela, Jukka Ylitalo, Mika Kousa, Jeff Ahrenholz, Tom Henderson, Tim Shepard, and Pekka Nikander)

Items below are rough consensus opinion on the revised HIP draft, although not everyone in the above list was present for all discussion points below.

Sec 1. Introduction

• the term "Host Layer Protocol" does not seem to convey more information than "Host Identity Protocol" and could be deleted to streamline terminology

Sec. 3. Host Identity

• rephrase: "It (HI) SHOULD be stored in a DNS KEY RDATA format. If the HI does not have a KEY RDATA format, a new RDATA-like format should be defined for the HI." Rationale: as per last meeting, unclear whether HI can be a DNS KEY RR, but we are free to format it like that regardless.
• reference [8] (RFC 2536) should be RFC 2535 instead... the "flags, protocol, algorithm" block should be used to identify the algorithm.
• end of paragraph 3.1, change to "For example, if the Identity is DSA, these bits MUST be the least significant 126 bits of the SHA-1 [13] hash of the Host Identity as it is represented in the Host Identity field in a HIP packet (e.g., in RDATA format)." This disambiguates what exactly should be hashed.

Sec 3.2. Local Scope Identity

• The group could not come to complete resolution on how LSIs are generated or used, or even whether they need to be exchanged. The decision was to leave the procedure alone for now (host picks the LSI that its peer uses for it). However, it was agreed unanimously that LSIs should be used in place of IPv4 addresses in the IPv4 pseudoheader for transport checksums-- and that an explicit statement of this is needed in this section.

Some options for what value is the LSI:
- least 32 significant bits of HIT

• a monotonically increasing number from a random seed
• some IPv4 address in the IPv4 private address space

Benefits of not exchanging LSIs:
- allows for piggybacking of data on I2/R2

• could be cached (semi-static-- may be useful in debugging).

Benefits of exchanging them:
- allows host to deconflict peer LSIs. This is most important if the
applications may be using LSIs in socket calls (see below).

Tom floated again the thought that that the LSI could be completely local and does not need to be exchanged, as long as each host can determine from local information what value for LSI that the peer will use in its checksum computations. Applications continue to use IP addresses in socket calls, and kernel does whatever NATting (including application NATting) is required. It was pointed out that this approach was going to be prone to some kinds of data flows escaping the HIP protection, unless the local housekeeping in an implementation was especially good. Example: FTP opens control connection to IP address. One or both parties move. FTP later opens data connection to the old IP address. Kernel must identify that the application really means to connect to the host that was previously at that IP address-- but obviously if the old address is reused by another host, this becomes difficult.

Related to this, the discussion also opened up the question of DNS resolution. Should the HIT/LSI be returned to applications as a (spoofed) address in the resolution process, allowing apps to use the socket API with HIT or LSI values instead of an IP address? While this seems to be the original intention of LSIs, there are a couple of difficulties especially in the IPv4 case:

• how does kernel know whether value being passed in a socket call is an IP address or an LSI? The fact that a name resolver library gave an application an LSI is no guarantee that the application will use that information in its socket call. It may also have cached some IP address from before or received an IP address as side information. This difficulty may be relieved if LSIs are constrained to some wellknown private subnet space.
  - this may confuse legacy applications that assume that what is being
  passed to them is an IP address. Good examples of this are diagnostic tools such as dig and ping.
  - what does kernel do with an LSI that it cannot map to an address based
  on information that it has locally cached?

It seems that some modification to the resolver library (to explicitly convey HIP information rather than spoofing IP addresses), as well as modifications to socket API to explicitly let the kernel know that the application is HIP aware, are the cleanest long-term solution, but what to do about legacy applications??-- still an open issue. The HUT team has been considering these problems.

3.3 Security Parameter Index

• Regarding the question of who selects SPI, it was agreed that SPIs are selected as specified in the IPsec (ESP) RFCs-- namely, host selects the SPI values for its inbound SAs.
• It is not clear where the requirement for a random SPI comes from. SPIs should be unique on incoming SAs, for demultiplexing (unlike IPsec, cannot reuse SPI value over different IP addresses).

3.4 Difference between LSI and SPI

• This will need to be revised pending changes to section 3.2 (LSI) above.

4.2 HIP Cookie Exchange

• Pekka proposed text that adds HITs (or better yet, IP addresses) to the J value of the cookie puzzle, to prevent the DOS attack of flooding I2s from many hosts. Responder would then make sure that the J value corresponds to the IP address. This does not prevent single malicious host from flooding I2s, but hosts could probably defend against this event better. There was no real disagreement with proposed revision once it was explained.
• Related to this, someone observed that it may be better to use HMAC rather than DSA signatures in R1 packets (faster-- allows more generation of R1s). Not clear that this is a real concern; more information needed.
• It should probably be hinted in the text somewhere that the cookie should be processed before the I2 packet signature is verified.
• A comment was made suggesting that guidance in the draft about rotation of cookies would be appropriate.

4.2.2 HIP controls

• Sentiment expressed against a proliferation of options. As for the two present control bits, bit 0 (anonymous) is useful but bit 1 (64 bit sequence number) might be better off as a special case of the

transform selected. However, there was no strong consensus on this issue.

Section 4 (missing section on piggybacking?)

• The group felt that Section 4 might benefit from a section on piggybacking. Was not clear whether it was a MAY, SHOULD, or MUST to support-- sentiment seemed to settle on MUST, at least for IPv6. For IPv4, piggybacking seems in conflict with LSI selection by the peer-- perhaps another argument against peers picking LSIs, or perhaps piggybacking is not permissible in IPv4.

Section 4 (missing section on use of certificates?)

(A comment on organization)-- some members of the group voiced the opinion that the document should be organized from this point forward as:

• Section 5 (State machine)
• Section 6 (Packet formats)
• Section 7 (Packet processing)

Section 5-- HIP packets

• Group felt that it would be better to fold in the packet formats draft into the specification. Some of the material in the HIP packets section should be reorganized/moved to the Packet processing section.
• Pekka suggested possibly combining the NES and REA packets. Andrew commented that keeping them separate might make sense, given that rekeying might take some time (overhead) while readdressing could take minimal time. Pekka argued for combined NES and REA again but I did not hear all of the details of the argument. If separate, an open issue is whether REA packets should be permitted (probably not) when a rekeying NES event takes place.

Section 5.5 NES packets

• Andrew commented that the procedure for rekeying is more subtle than expressed in the draft, and more explanation is needed. For example, what is the sequence of packets that stimulates a rekeying?
• Several people objected to the requirement to hold up all packets on an old SPI while you are doing the rekeying, due to the latency (e.g., VoIP will not stand it). Instead, it was felt that old and new SPIs could coexist and old SPIs would be garbage-collected when their replay protection ran out.

Section 5.6 REA packets

• The question was raised whether people liked the new Interface ID. The consensus was that this was needed especially to handle multihoming. Detailed multihoming procedures will require more extensive work due to the various complexities (e.g., different addresses with different scopes)-- for now, the focus in the draft is more on mobility than multihoming.

Section 5.7 BOS packet

• Andrew suggested possibility of piggybacked data to create an authenticated UDP.

Section 5.8 HIP Fragmentation

• The group did not discuss a detailed solution for fragmentation, although it was agreed that this is an important section to develop, because of the tunnel impacts on path MTU discovery, and because of

the lack of fragmentation support in IPv6.

Section 6.3 Supported transforms

• A question was raised whether ESP-NULL support should be mandatory.

There was no consensus.

Section 6.5 ESP usage with non-cryptographic HI

• It wasn't clear to the group why non-cryptographic HI would be a good thing. However, it was in the original specification, so the group decided to hear Bob Moscowitz's motivation on it. If it is left in, it needs more development.

Section 7 HLP packet flow (same comment applies to use of HLP instead of HIP)

• move Section 7.6 to new section 5(state machine). Section 7.2 material also may belong in section on packet processing.

Section 7.3 HIP Keymat

The group suggested the following changes
- KEYMAT = Kij | K1 | K2 ... (many situations will just need Kij)

• drop HMAC from SHA hash:
  • K1 = SHA1(Kij | sort(HITi | HITr) | 0x01)
  • K2 = SHA1(Kij | K1 | 0x02) ...
  • K256 = SHA1(Kij | K255 | 0x00) (i.e., permit wraparound)
• sort(HITi | HITr) is defined as the numeric BN-compare of HITs, with lower HIT preceding higher HIT.
• the keys are drawn sequentially in the following order:
  • HIP Initiator key
  • HIP Responder key (currently unused)
  • Initiator ESP key
  • Initiator AUTH key
  • Responder ESP key
  • Responder AUTH key
• subsequent rekeys just requre drawing out one set of ESP keys, as described in the current text.

Section 7.4
- it was felt that Protocol Unreachable would be more appropriate
message than Host Unreachable (which is usually sent from routers and may be misinterpreted)

Section 7.5
- I do not recall discussion of the R1 storm issue described in
this section, although I believe there was a comment that how we handle the potential I2 storm may resolve it?

Section 8 HLP policies
- Suggested rephrase of sentence 2: "Implementations must publish a
different HI in DNS (if any) than one that they use for anonymous mode."

• it was felt that restriction of K <=8 was too low and that there was no need to specify a restriction.

The group did not discuss Section 9 onward.

---

Hipsec mailing list
Hipsec@lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/hipsec Received on Tue Mar 18 00:48:29 2003