[Hipsec-rg] RE: [IRSG] review of document draft-irtf-hiprg-nat-01

[[e-mail] (Henderson, Thomas R)]

Kevin, I wanted to respond to those comments of yours that were not
specific to the NAT draft but to HIP in general.

> -----Original Message-----
> From: Fall, Kevin [mailto:[e-mail]]=20
> Sent: Thursday, March 30, 2006 9:50 AM
> To: Internet Research Steering Group
> Subject: [IRSG] review of document draft-irtf-hiprg-nat-01
>=20
(snip)
>=20
> The discussion of NATP points out that the IPv4 HIP base exchange
> doesn't contain port numbers.  Is this fundamental?  Could the HIP
> exchange be carried, e.g. over UDP.  I think something to=20
> this effect is
> mentioned later in section 6, but not in exactly that form.

Yes, the IETF HIP WG is discussing a recharter that would focus on a
UDP-based encapsulation for NAT traversal.  There are two drafts on this
topic:
http://www.ietf.org/internet-drafts/draft-schmitt-hip-nat-traversal-00.t
xt
http://www.ietf.org/internet-drafts/draft-nikander-hip-path-01.txt

>=20
> I am curious also about whether the TCP alternate checksum (RFC1146)
> when the TCP pseudoheader cksum computation is changed to=20
> work on HITs.
> Again, this may be a comment on the IETF doc rather than this=20
> IRTF doc.

If I understand correctly, the TCP alternate checksums are just
different algorithms applied to the same pseudoheader and payload.  I
also don't know if they are used in practice, or if they have been
applied to IPv6.  It seems that the alternate checksums could also use
HITs or LSIs in place of IP addresses in the pseudoheader.=20

>=20
> -- comments on the IETF document draft-ietf-hip-arch --
>=20
> HIP seems to be looking at an important problem area and it=20
> seems to be
> viable at least for the scenarios studied (TCP and UDP transport).  In
> reading this document, I wasn't really sure it works in cases where
> these aren't the transports.  I think about ICMP, for example, as well
> as multicast.  Perhaps its not in HIP's scope to look at these things,
> but if that's the case then does it really make sense to=20
> re-tool the end
> host implementations for just these protocols?  Maybe it=20
> does, but this
> issue doesn't seem to be discussed in the architecture document.
>=20
>

It may not be explicit enough in the architecture document, but HIP is
intended for unicast upper layer protocols that can be protected by ESP,
where TCP and UDP are cited as the most common examples.  Now that I
read the base draft, it is a little vague on this point, and perhaps can
be clarified in Section 4.5.

ICMP is an interesting case, because it may be that you really want to
avoid a HIP encapsulation of such traffic (e.g., ping an interface, not
a host).  The HIP implementation and SPD should have enough granularity
to allow for the right rules to be applied.  In the OpenHIP
implementation, we are able to control it to some degree-- if we say
"ping <ip address>" the stack will not use HIP but if we say "ping
<LSI>" or "ping <HIT>" it will use HIP and ESP to encapsulate the ping.

Multicast has been out of scope to date, but it is conceivable that a
variation of HIP could be used as a phase 1 protocol supporting RFC 3547
secure multicast.  There has also been work on integrating HIP with i3,
which supports a multicast-like indirection; see
<<http://www.ambient-networks.org/docs/Host_Identity_Indirection_Infrast
ructure_Hi3.pdf>>
(and Andrei Gurtov provided a patch to the OpenHIP implementation for
this feature).

Tom =20