Subject: [Hipsec] HIP over STUN, or HIP NAT-traversal through legacy NATs

From: [email-masked] (Pekka Nikander)
Date: Mon Nov 8 17:01:02 2004

Based on hallway conversations, there seems to be quite a
lot of interest in producing a specification for how to
run HIP through legacy NATs.  Furthermore, people seem to
agree that at least one way to go is to somehow integrate
HIP rendezvous service and STUN.

To get this forward, I would suggest that we have an ad
hoc meeting on this.  I would suggest Thursday morning
at 9am, but I am also open to other alternatives.

If you are interested, please let me know.  If you are
interested but the time is not good for you, feel free
to suggest alternative times at the list.  Anyway, I
will collect a list of interested people and try to arrange
a meeting at some point of time.

And, of course, we need a good acronym for this.
Here are some suggestions:
   HoS   HIP over STUN
   HIPU  HIP over UDP
   HTN   HIP through NATs

--Pekka

---

From: [email-masked] (Martin Stiemerling)
Date: Tue Nov 9 10:21:01 2004

Hi all,

Juergen Quittek and I have outlined some implications of HIP and NAT 
traversal in this draft

<http://www.ietf.org/internet-drafts/draft-stiemerling-hip-nat-02.txt>

Meeting for Thursday 9am is fine.

  Martin

--On Montag, 8. November 2004 18:12 Uhr -0500 Pekka Nikander 
<[email-masked]> wrote:

| Based on hallway conversations, there seems to be quite a
| lot of interest in producing a specification for how to
| run HIP through legacy NATs.  Furthermore, people seem to
| agree that at least one way to go is to somehow integrate
| HIP rendezvous service and STUN.
|
| To get this forward, I would suggest that we have an ad
| hoc meeting on this.  I would suggest Thursday morning
| at 9am, but I am also open to other alternatives.
|
| If you are interested, please let me know.  If you are
| interested but the time is not good for you, feel free
| to suggest alternative times at the list.  Anyway, I
| will collect a list of interested people and try to arrange
| a meeting at some point of time.
|
| And, of course, we need a good acronym for this.
| Here are some suggestions:
|    HoS   HIP over STUN
|    HIPU  HIP over UDP
|    HTN   HIP through NATs
|
| --Pekka
|
| _______________________________________________
| Hipsec mailing list
| [email-masked]
| http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: [email-masked] (Pekka Nikander)
Date: Tue Nov 9 12:21:01 2004

> <http://www.ietf.org/internet-drafts/draft-stiemerling-hip-nat-02.txt>

I have read the draft and while I think it has some value
(see below), it is not really what I have in mind.  I'd like
to proceed more directly to a specific class of solutions,
i.e., to see how to marry HIP with STUN in a reasonable way.
Since that work is not currently chartered in any WG, this
should probably go as individual work.

Anyway, some comments to the draft:

- In general, I think that the draft may act as a problem
   statement, but it definitely does not propose a suitable
   solution, even though it briefly discusses some.

- Depending on what happens at the next HIP WG re-chartering,
   it might be useful to have a crystal clear problem statement
   for HIP middle box traversal.  Perhaps this draft could act
   as a starting point for that.

More detail:

- In Section 4.1, the draft claims:

>         When IPv4 is used, HIP messages are transmitted as UDP payload.
>         (see Appendix E of [HIP-PROTO]).

   As (I think) I have previously said, this has never been true.
   App E was a placeholder for thought, and would never have worked.
   The intention has always been that the _preferable_ way for HIP
   is to run on the top of IP.  And as of the newest base spec,
   the appendix is gone, or at least should be.

   As a consequence of this, Section 4.1.2 needs to be fixed, too.

   Now, we do need to get HIP to run on the top of UDP (and probably
   HTTP) to traverse NATs (and some other middle boxes).  But that
   has not been defined.  We still need to nail down the details.

- In Section 4.1.1, the draft claims:

>    Another problem (that also applies to IPv4) is that HIP provides no
>    explicit means for transmitting the IP address used by a host other
>    than using the source IP address of the packet carrying HIP 
> messages.

   While that is true wrt the base spec, the mm spec explicitly defines
   a means to carry IP addresses, i.e., the readdressing payload.
   While that most probably is not quite enough for NAT traversal
   purposes, perhaps it could be made more generic to fit for that 
purpose.

--Pekka

---

From: [email-masked] (Martin Stiemerling)
Date: Wed Nov 10 19:29:00 2004

Hi Pekka,

--On Dienstag, 9. November 2004 13:31 Uhr -0500 Pekka Nikander 
<[email-masked]> wrote:

|> Juergen Quittek and I have outlined some implications of HIP and NAT
|> traversal in this draft
|>
|> <http://www.ietf.org/internet-drafts/draft-stiemerling-hip-nat-02.txt>
|
| I have read the draft and while I think it has some value
| (see below), it is not really what I have in mind.  I'd like
| to proceed more directly to a specific class of solutions,
| i.e., to see how to marry HIP with STUN in a reasonable way.
| Since that work is not currently chartered in any WG, this
| should probably go as individual work.

Thanks for reading and giving comments!

|
| Anyway, some comments to the draft:
|
| - In general, I think that the draft may act as a problem
|    statement, but it definitely does not propose a suitable
|    solution, even though it briefly discusses some.

Yes, indeed it is a problem statement and should only open the space for 
further discussions and activities.  We've just reached the point of 
getting to a solution, which is great :)

|
| - Depending on what happens at the next HIP WG re-chartering,
|    it might be useful to have a crystal clear problem statement
|    for HIP middle box traversal.  Perhaps this draft could act
|    as a starting point for that.

I'll do my best to get this as clear as possible.

|
| More detail:
|
| - In Section 4.1, the draft claims:
|
|>         When IPv4 is used, HIP messages are transmitted as UDP payload.
|>         (see Appendix E of [HIP-PROTO]).
|
|    As (I think) I have previously said, this has never been true.
|    App E was a placeholder for thought, and would never have worked.
|    The intention has always been that the _preferable_ way for HIP
|    is to run on the top of IP.  And as of the newest base spec,
|    the appendix is gone, or at least should be.
|
|    As a consequence of this, Section 4.1.2 needs to be fixed, too.

The statement made in the problem statement is misleading and should be 
clarified within the next revision.

|
|    Now, we do need to get HIP to run on the top of UDP (and probably
|    HTTP) to traverse NATs (and some other middle boxes).  But that
|    has not been defined.  We still need to nail down the details.

Running HIP base exchange over UDP is good start, but, as you've said, the 
whole things needs to nail down the details.  I'm happy to help on this!

|
| - In Section 4.1.1, the draft claims:
|
|>    Another problem (that also applies to IPv4) is that HIP provides no
|>    explicit means for transmitting the IP address used by a host other
|>    than using the source IP address of the packet carrying HIP
|> messages.
|
|    While that is true wrt the base spec, the mm spec explicitly defines
|    a means to carry IP addresses, i.e., the readdressing payload.
|    While that most probably is not quite enough for NAT traversal
|    purposes, perhaps it could be made more generic to fit for that
| purpose.

I've had in mind that the problem statement does mention the mm spec, 
referring to carrying the IP address between hip nodes.  It may be that I 
have not put in the draft, but I'm having this in my mind.

Looking forward for the HIP&NAT meeting on Thursday morning.

Thanks,

  Martin