Subject: [Hipsec-rg] RE: [IRSG] review of document draft-irtf-hiprg-nat-01
From: [email-masked] (Henderson, Thomas R)
Date: Tue Apr 25 10:39:00 2006

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:[email-masked]]=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

From: [email-masked] (Henderson, Thomas R)
Date: Tue Apr 25 10:07:01 2006
Subject: [Hipsec-rg] RE: [IRSG] review of document draft-irtf-hiprg-nat-01
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Thanks to Kevin Fall, Karen Sollins, and Mark Allman for reviewing the
NAT problem statement draft.  All of the reviewers seemed comfortable
with publishing it if their comments are satisfactorily addressed.  I've
asked the authors to summarize, to the list, their response to the
comments, and to produce a new draft version.

Tom=20

From: [email-masked] (Karen R. Sollins)
Date: Tue Apr 25 05:38:01 2006
Subject: [Hipsec-rg] draft-irtf-hiprg-nat-01.txt review
Message-ID: <p06230907c072c836b0b4@[18.26.0.27]>

In general I find draft-irtf-hiprg-nat-01.txt to be ready to publish 
with a few additional and reiterated small points or nits.  I think 
it does a nice job of identifying and considering the issues, and 
should be valuable.

First, I also found that it didn't quite stand on its own because it 
uses so many acronyms that are not even spelled out.  Perhaps at the 
first usage of each acronym, it should be written out fully, with the 
acronym in parentheses (to hint to the reader that henceforth the 
acronym will be used).

In addition to the nits reported by others, here is my further list:

*  p. 4, 2nd line: "refer to" should be "reference"

* p. 4, 4th line: "It also does not..." - eliminate "also" to read 
"It does not".. (since this is the first negative about what the doc 
does NOT do).

* p. 5, first line - last word is missing.  The sentence ends it 
"before", but doesn't tell me before what - perhaps what is meant is 
"before transmission"?

* p. 5, Sect. 2.2, last sentence, 2nd paragraph: The sentence reads, 
"They may be addressed in the BEHAVE working group or in [RFC3489]." 
This suggests a future action, but one can't plan to do something in 
the future within an already existing RFC, so the sentence needs to 
say something slightly different about what might happen and what has 
already happened.

* Finally, is there an issue with the fact that several of the key 
references (2 normative and 1 informative) are currently only 
Internet Drafts?

			Karen Sollins

From: [email-masked] (Mark Allman)
Date: Mon Apr 24 06:18:04 2006
Subject: [Hipsec-rg] review of draft-ietf-hiprg-nat-01.txt
Message-ID: <[email-masked]>

--=_bOundary
Content-Type: text/plain
Content-Disposition: inline

I found this document to be pretty reasonable and have no problem with
it being published.  I have a few nits; none of which are a big deal.

allman

2.1:

  + "it uses an IP payload" --> "it uses the IP payload"

2.1.1:

  + "suggests to encapsulate" --> "suggests encapsulating"

3.1.2:

  + "issue Section 2.1.1 applies" --> "issue applies" 

  + "configurations Section 3.1 that" --> "configurations that"

  (Both of these look like they are trying to refer back to particular
  previous discussions, but its a very odd construct to just plop
  "Section X" in the middle of a sentence that then makes no sense.  I
  suggest using a parenthetical at the end of the sentence or some other
  method.)

8:

  + The term "pinhole" is first used here.  Maybe it should be
    introduced earlier?  (Or, defined right here?)

Meta:
 
  + My biggest issue with the draft was with the use of undefined
    acronyms ("HIT", "SPI", "SPINAT", "NSLP", etc.).  Some of these I
    knew and some of them I had to go off and figure out.  I suggest
    spelling them out and if their purpose is not clear from said
    spelling out then please give a sentence of explanation.

--=_bOundary
Content-Type: application/pgp-signature

--=_bOundary--

From: [email-masked] (Henderson, Thomas R)
Date: Thu Apr  6 10:14:01 2006
Subject: [Hipsec-rg] FW: [IRSG] review of document draft-irtf-hiprg-nat-01
Message-ID: <[email-masked]>

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:[email-masked]]=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