Subject: [Hipsec] WGLC: draft-ietf-hip-nat-traversal-07.txt

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 11 Jun 2009 09:59:09 +0300

Folks,

I would like to start the WGLC on the NAT traversal draft:

http://tools.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-07.txt

This WGLC will end on June 28th. Please, send your comments to this 
mailing list.

Thanks,

Gonzalo
HIP co-chair

---

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Tue, 16 Jun 2009 14:11:00 -0700

> This WGLC will end on June 28th. Please, send your comments to this 

Here are some comments on this latest NAT traversal draft.

All of these are just editorial nits, but I do have one general comment:

It is not explicitly stated in RFC 5203 or in this NAT draft that when
you make a registration with a server, you maintain a HIP association
with that server as long as you are registered for that service. This is
implied in RFC 5203 Section 6 ("Because they have to store HIP
association state anyway..."), and in the NAT draft Section 4.1 ("...the
client sends NAT keepalives periodically to the relay..."). Maybe there
should be a sentence stating the relationship between the registration
and the association?

Another comment is that I think the text reads better to have "registers
with the relay" rather than "registers to the relay" (specific changes
below).

Section 4.1 p. 9
Figure 2: Example Registration with a HIP Relay
                               ^^^^
Section 4.2 p. 10
The Initiator takes the role of...
^^^
Section 4.3 p. 10
With registration with a HIP relay it is...
                  ^^^^
Section 4.5 p. 13
MUST contain the same information as the RELAY_FROM
             ^^^
Section 4.9 p. 17
R1 and answering [to] it with an I2
                 ^^^^ delete "to"
Section 4.9 p. 17
successfully registered with the rendezvous
                        ^^^^
Section 4.9 p. 17
suggest replacing:
   to be used in case of mobility or multihoming event
   which causes NAT traversal to be taken in to use
   during the lifetime of the HIP association
with:
   in case of a mobility or multihoming event
   which causes NAT traversal to be used
   during the lifetime of the HIP association

Section 4.10 p. 18
pair established for a data channel without
                     ^
Section 4.10 p. 18
registered with the relay MUST utilize the RELAY_TO parameter as in
           ^^^^                                               ^^
the base exchange

Section 5.1 p. 19
the UDP header already contains a checksum
               ^^^^^^^^^^^^^^^^
Section 6.3 p. 27
suggest replacing:
   The relay can protect itself against replay attacks by
   involving in the base exchange by introducing nonces
   that the end-hosts (Initiator and Responder) have to sign.
with:
   The relay can protect itself against replay attacks by
   becoming involved in the base exchange by introducing
   nonces that the end-hosts (Initiator and Responder) are
   required to sign.

Appendix A p.30
suggest replacing:
   The value should not be too small so that the checks
   do not cause congestion in the network or overwhelm 
   the NATs.  On the other hand, too high pacing value
   makes the checks last for a long time and thus
   increase the connection setup delay.
with:
   The value should not be so small that the checks
   cause network congestion or overwhelm the NATs.  On the
   other hand, a pacing value that is too high makes the
   checks last for a long time, thus increasing the
   connection setup delay.

Appendix A p.30
characteristics are not known
                        ^^^^^

-Jeff

---

From: Miika Komu <[email-masked]>
Date: Wed, 17 Jun 2009 09:48:52 +0300

Ahrenholz, Jeffrey M wrote:

Hi Jeff,

> should be a sentence stating the relationship between the registration

strictly speaking, a full-blown HIP association is not necessary for the 
keepalives. However, HIPL (and hip4inter?) implement this using a full 
HIP association, so I have no strong objections against your suggestion.

---

From: Ari Keranen <[email-masked]>
Date: Wed, 17 Jun 2009 10:49:50 +0300

Hi Miika and Jeff,

> HIP association, so I have no strong objections against your suggestion.

Just to clarify: you don't need to have a Security Association with the 
HIP relay server, but surely you need to keep some state, i.e., a HIP 
association, with it. You can also make an SA with the relay server and 
also our implementation currently does this. The difference regarding 
NAT traversal comes from the fact that without the SA you don't draw ESP 
keys from the keying material before drawing the keys used for STUN 
integrity.

But I agree that stating this more explicitly makes sense. I added to 
the end of the last paragraph of 4.1:

    The relay client maintains the HIP association with the relay
    server as long as it requires relaying service from it.

Cheers,
Ari

---

From: Ari Keranen <[email-masked]>
Date: Wed, 17 Jun 2009 12:46:28 +0300

Hi Jeff,

> Here are some comments on this latest NAT traversal draft.
[...]

Thanks for the review and comments!

I made all the changes you proposed and a fixed pre-version is available 
here:
http://users.piuha.net/akeranen/drafts/draft-ietf-hip-nat-traversal-08-pre1.txt

Also a diff to the -07 version showing just the fixes is available here:
http://users.piuha.net/akeranen/drafts/draft-ietf-hip-nat-traversal-08-pre1-diff.html

Cheers,
Ari

---

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Wed, 17 Jun 2009 08:07:09 -0700

>> strictly speaking, a full-blown HIP association is not 
>> necessary for the keepalives. 

Yes, I was thinking that because of the RELAY_HMAC (or RVS_HMAC)
parameter you need to maintain a HIP association while registered, due
to the required keying material, but I guess these parameters are only
used initially.

> Just to clarify: you don't need to have a Security 
> Association with the HIP relay server, but surely
> you need to keep some state, i.e., a HIP association

To have a HIP association without Security Association I'm assuming you
would omit the ESP_INFO and ESP_TRANSFORM parameters, that is
interesting. I don't know how useful any SA with the relay would be,
since the relay server is not relaying data packets.

>     server as long as it requires relaying service from it.

This text looks good.

-Jeff

---

From: Ari Keranen <[email-masked]>
Date: Thu, 18 Jun 2009 16:07:58 +0300

> to the required keying material, but I guess these parameters are only

Yes, but you need HMACs also for closing the association. And the NAT 
traversal mobility extensions could have use for (RELAY_)HMACs during 
the lifetime of HIP association too.

> since the relay server is not relaying data packets.

Yes, you would omit the ESP_* parameters from the BeX. And you could 
want to exchange secured data also directly with the relay (i.e., not 
for relaying) and then making an SA with it would make sense.

>>     server as long as it requires relaying service from it.

Thanks.

Cheers,
Ari