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

[stiemerling at netlab.nec.de (Martin Stiemerling)]

Hi all,

Many thanks to Kevin for his review. More inline.

Am 06.04.2006 um 16:18 schrieb 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:kevin.fall at intel.com]
> 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.

You are right in the sense that the document is solely handling
NAT and firewall middleboxes. Changed, unless somebody out
of the HIPRG has a major concern about it.

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

Right, IP addresses are still being used but both "use internally"  
the host
IDs. However, I still see the issue of this sentence being a very strong
argument, even though HIP is changing a lot. So, I have stripped out
the 'fundamentally' and it now reads:

   The Host Identity Protocol (HIP) changes the way in which two  
Internet
   hosts communicate. One key advantage over other schemes is that HIP
   does not require modifications to the traditional network-layer  
functionality
   of the Internet, i.e., its routers.

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

Yes, indeed multicast is not handled, but this due to the nature of HIP.

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

The specification of HIP is using plain IP payload and the encapsulation
in UDP has been ruled out in the first place. However, there is now
a proposal to run the HIP base exchange over UDP, as a result of this
IRTF traversal issue draft.

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

This is a comment towards the IETF document rather than this IRTF  
document.

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

Fixed.

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

Fixed to NAT and firewall.

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

Change to:

    HIP nodes located behind a NAT must notify their communication peers
    about the contact information.  The contact information is the NAT's
    public IP address and a specific UDP port number.  This measure
    enables the peers to send return traffic to HIP nodes behind the  
NAT.
    This would require a new HIP mechanisms.

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

I do not know whether those references are appropriate, since the
rendezvous problem is as old as the usage of NAT. However,
they could show the relationship to other architectures. But I do not
see this draft as the place for this, since we do not go into detail
on the rendezvous point.

Thank you for the review!

   Martin for the authors

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