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

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

Below is Kevin Fall's review of draft-irtf-hiprg-nat-01.  We're
expecting two other reviews in the coming weeks.

The next steps are to assemble a RG response to these comments, and then
share that response (and proposed changes) to the IRSG.  We would like
to get the IRSG to declare 'ready to publish' as defined by the process
in:
http://www.ietf.org/internet-drafts/draft-irtf-rfcs-00.txt
I'm serving the role of shepherd of this document (see the expired
draft:
http://psg.com/~mrw/PROTO-Team/shepherding-draft.txt).  We'll discuss
proposed changes on the RG list.  This process is similar but not
identical to IESG review.

Tom

-----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


I read this document yesterday along with the earlier document
draft-ietf-hip-arch-03.  At a high-level, although I have no substantive
objection to the IRTF document, I have a concern with the IETF document
and therefore the HIP effort more generally.

Here's some more constructive comments for the IRTF doc:

draft-irtf-hiprg-nat-01 is only about traversing firewalls and NATs, yet
its title is 'middlebox traversal'.  I believe the title should be
narrowed to reflect its contents, or the content expanded to reflect the
title.

In the abstract I'm not sure its fair to say it 'fundamentally' changes
the way in which two Internet hosts communicate.  Indeed, in the
proposal as is, IP addresses are still being used to do the actual data
routing.  In addition, the phrase "two Internet hosts" gives me concern
that multicast is really completely not addressed.  This comes up again
on page 2 where it says HIP "assumes simple Internet paths, where
routers forward globally routable IP packets..."  I might says "globally
routable unicast IP packets".  This problem isn't one directly related
to the IRTF draft, however, and really is more a common on the IETF
document.  I will say a little on it later.

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 this effect is
mentioned later in section 6, but not in exactly that form.

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

Section 3 typo "This type of middlebox" -> "These types of middleboxes"
Also, "forward or discard them" -> "forward, discard, or process them in
some special way".

Section 4 it says the section identifies possible changes to HIP that
attempt to improve middlebox traversal, but it is only really for
firewall and NAT traversal... see comment above.

Paragraph #3 of section 4 starting with "When contacting peers" needs to
be re-written (overloading of pronouns).

Paragraph #4 of section 4 mentions the rendezvous problem.  This is not
a HIP-only problem, which should be noted, possibly with appropriate
refs.  I3 and Keshav's TCA (http://citeseer.ist.psu.edu/724596.html)
come to mind, for example.

Section 8 refers to "pinholes" which could use a sentence of definition
here.

-- comments on the IETF document draft-ietf-hip-arch --

HIP seems to be looking at an important problem area and it 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 re-tool the end
host implementations for just these protocols?  Maybe it does, but this
issue doesn't seem to be discussed in the architecture document.

- Kevin