Subject: RE: [Hipsec] hip-nat-traversal-02-pre5

From: Miika Komu <[email-masked]>
Date: Mon, 4 Jun 2007 15:10:35 +0300 (EEST)

On Tue, 29 May 2007, Dan Wing wrote:

> Thanks for the opportunity to review this document before publication.

Thanks for feedback and apologies for the long delay. The next preversion 
includes your comments and it is available here:

http://www.iki.fi/miika/docs/draft-ietf-hip-nat-traversal-02-pre6.txt

> Comments:
>
> 1. section 3:
>
>   This section describes NAT traversal between two HIP end-hosts.  A
>   successful NAT traversal requires at least the Responder to register
>   to a relay server.  The base exchange is relayed through the relay
>   server.
>
> In the introduction you described three cases -- where the initiator is
> behind a NAT, where the terminator is behind a NAT, and where both are
> behind (different) NATs.  In the second case, where the terminator
> (HIP Responder, I presume?) is not behind a NAT but is on a public
> network, is it true that it still needs to register to a relay server?

If the responder is always in a public network, it has no need for a relay 
server. Added: "The use of the relay is optional when the Responder is 
located in a public address realm without rendezvous server"

> 2. section 3:
>
>   The end-hosts need a fixed transport layer port number to be able to
>   communicate with each other.  The end-hosts MUST accept incoming HIP
>   and ESP traffic arriving at UDP port 50500 (future extensions may use
>   the same port number for TCP).  It is RECOMMENDED that an Initiator
>   selects a random port number between 49152-65535 for initiating a
>   base exchange even for registration.  However, the allocated port
>   MUST be maintained until all of the corresponding Host Associations
>   are closed.  Alternatively, a host MAY also use source port 50500 for
>   initiating a base exchange.  The RECOMMENDED transport layer protocol
>   is UDP.
>
> From this requirement, I can only assume that HIP doesn't communicate the
> port number across th HIP rendezvous server.  Is my assumption 
> corrrect?

Your assumption is correct assuming you mean relay instead of rendezvous 
server. Should it communicate it?

Actually, this brought to my mind a related idea that I did not 
include in the draft yet. The registration phase could be identical to 
the connectivity test phase, except there not may be a relay available yet 
and the packets are carrying REG parameters. In this case, the packets 
would also carry the locator information of the initiator to the relay.

>From an implementation point of view, this would perhaps simplify 
implementations because currently registration and connectivity tests are 
handled differently. From a performance point of view, this would increase 
the latency in the registration to the relay server, but this probably is 
an acceptable cost.

What do you think?

> 3. section 3.1:
>
>   When the ESP relay registration was successful, the relay server uses
>   the source IP address and port (typically 50500) of the R2 to relay
>   ESP traffic with the client.  This address-port pair of the relay is
>   referred as "leased transport locator" in this document.
>
> Please delete "(typically 50500)", because earlier text allows using 50500
> as the source address or using the 49152-65535 range as the source address.

Source port of the R2 is 50500 (i.e. the port the relay is listening) is 
50500. The "typically" meant (now removed) that sometimes you may want to 
use non-default ports.

> But more importantly, a NAT may be unable to retain whatever UDP port the
> host chose because another host is already using that same UDP port, or
> because the NAT doesn't like to retain source UDP ports.  So -- what is
> the significance of this choice of ephemeral port?

If I recall correctly the original reason for this, it was the cone NATs.

> 4. Section 3.2:
>
>   The relay MUST change the transport
>   source and destination of the message to match the one the Responder
>   used when registrating to the relay.
>
>
> Does this mean the relay spoofs the IP address?  That is how I read it...
> If you're referring to transport source and destination addresses inside of
> HIP itself, the text needs to be clarified.  If you really do want the relay
> to spoof IP addresses, I think the design is flawed.

I modified the text. What I meant that the relay forwards the message to 
the destination address the responder that it used in the registration.

> 5. Section 3.2:
>
>   The base
>   exchange was concluded by I2 and R2 messages over transport layer
>   that contained RELAY_TO parameters.
>
>   After this, the state of the HIP
>   associations is ESTABLISHED, but the hosts MUST NOT allow any ESP
>   traffic until the connectivity tests described in the next section
>   are performed successfully.
>
>
> But the next section (3.3) describes cases where there aren't connectivity
> tests, even if there was a RELAY_TO.  This needs to be cleaned up.  I
> suggest moving the last two paragraphs of 3.2 into 3.3,

Done.

> and not described ESTABLISHED as 
> some-state-that-isn't-quite-like-ESTABLISHED.  I think you need to 
> transition to a different state (such as perhaps UNVERIFIED?), and 
> describe the rules for when you enter that state and when you can skip 
> that state and go directly to ESTABLISHED.

I am not convinced yet that this is necessary. The draft proposes that 
ESTABLISHED means that the host associations are established, but the 
locators still have to be separately tested for return routability 
similarly as in draft-ietf-mm.

> 6.  Section 3.2:
>
> I don't think the FROM_PEER is sufficient to identify peers.  Consider, for
> example, that almost every consumer-grade NAT in the world uses 192.168.1.0
> as its private (internal) network, and the first host is typically assigned
> 192.168.1.1, the second host .2, and so forth.  Two HIP hosts behind their
> own NATs could easily have the same private IP address, and could be trying
> to establish communication with each other.  In this case, FROM_PEER isn't
> useful to distinguish connectivity checks from yourself versus from your
> peer.  Rather than using IP address, ICE uses a USERNAME, half of which is
> chosen by each peer, to provide this distinguisher.  I suggest using a
> peer-selected value to identify each peer is superior to IP address as a
> peer identifier.

I am unconvinced that we should drag the usernames and passwords from ICE 
to HIP. HIP has alreadt a crypgraphically more secure identifiers in the 
form of public keys (which can btw include a NAI, such as foo@bar etc).

> 7.  Section 3.3:
>
>   If the FROM_PEER and TO_PEER do not
>   match, the Responder is behind a "p2p-unfriendly" NAT
>   [I-D.ietf-behave-p2p-state].
>
> I believe there are two cases where you'll still encounter that situation,
> even if you are behind 100% p2p-friendly NATs.
>
> Case 1:  you're behind two p2p-friendly NATs ("nested NATs").
>
> Case 2:  if you have a network topology like this, with 100% p2p-friendly
> NATs, I believe they'll also not match:
>
>         Rendezvous Server
>       /                   \
>      /                     \
>     /                       \
>  Intiator------------NAT----Router
>                              |
>                          Responder
>
> That is, where a NAT is only on-path between the Initator and Responder, but
> isn't on-path between Responder and its Rendezvous Server.  There could be a
> different NAT that is on-path between the Responder and its Rendezvous
> Server.  Such a situation can occur (and does occur) with NATs inside
> enterprises.  This situation is why ICE has 'triggered checks':  for
> situations where the ICE endpoint doesn't know its traffic will traverse a
> NAT because the NAT isn't on-path with the ICE endpoint's STUN server.

I believe the connectivity tests will detect this. Changed the text to 
"the responder may be behind.."

> I encourage you to not use IP addresses as identifiers, especially for NAT
> traversal.

The HITs are used as the identifier. Both source and destination HITs are 
included in all HIP control packets.

> 8.  The first paragraph of section 3.3 burdens public hosts with NAT
> keepalives:
>
>   They MUST NOT
>   follow the extensions of this draft, except for the NAT keepalives
>   described in a later section.
>
> You don't need to create that burden:  only the hosts behind NATs need to be
> burdened with keeping their NAT pinholes alive.

If I recall correctly, both directions are important to keep the NAT state 
alive, but the outgoing direction was more important. Is the incoming 
direction completely unimportant?

> 9.  The NAT keepalive section (section 3.6) needs to describe how often the
> keepalives need to be sent.  As I mentioned above, you don't need to burden
> everyone with NAT keepalives -- just the hosts that are behind NATs.

How do you detect which host actually is "behind" the NAT. The current 
document uses also this "behind" term loosely, but the protocol actually 
tests "between".

> 10.     Section 5, firewall traversal:
>
> There is an odd statement about NAT traversal that is included in the
> firewall traversal section:
>
>   The NAT traversal mechanisms described in Section 3 require that the
>   firewall - stateful or not - allow inbound UDP traffic to port 50500
>   and allow outbound UDP traffic to arbitrary UDP ports.  If necessary
>   for firewall traversal, ports reserved for IKE MAY be used for
>   initiating new connections, but the implementation MUST be able to
>   listen for UDP packets from port 50500.
>
> This needs to be made clearer.  Here is an example of a topology that
> wouldn't work if all the firewall did was the above paragraph:
>
>         Rendezvous Server
>                          \
>                           \
>                           Firewall
>                              |
>                             NAT
>                              |
>                          Responder
>
> The Rendezvous server would listen for traffic on UDP/50500.

I modified the text, hope it is more clear now.

> Nits:
>
> Nit 1:  Introduction:
>
>  This document
>   specifies how HIP can traverse through such NAT middleboxes which are
>   neither HIP-aware or ESP-aware without manual configuration of the
>   NAT devices.
>
> You're using the term "NAT middlebox" and "NAT devices" in the same
> sentence.   You should use one.  I also found the "without manual
> configuration" awkward to read; inserting a comma might help separate
> out the two awareness clauses.  Like this:
>
>  ... neither HIP-aware or ESP aware, without manual ...
>                                    ^
>
> Nit 2:  The paragraph starting with:
>
>  "The new namespace of HIP has some additional benefits."
>
> seems to need a transitional phrase or something; it sort of sticks out
> there by itself.  I think before that paragraph you need an introductory
> paragraph describing the "HIP namespace".
>
>
> Nit 3:
>
> OLD:
> The protocol extensions in this document make
> NEW:
> The HIP extensions in this document make
>    ^^^
>
> Nit 4:
>
> OLD:
> the behavior of the NAT devices to make NAT traversal to work even
> NEW:
> the behavior of the NAT devices so that NAT traversal will work even
>                                ^^^^^^^               ^^^^

Applied.

> Nit 5:
> Instead of repeating the procedure to choose the source port (50500 or in
> that port range), how about describing it once in a tiny section and then
> referring to that section everywhere in the document.
>
> It would be useful if the suggestion for 49152-65535 was clarified:  does
> something break if I were to use 49151, for example?
>
> (I found a discussion in section 5, "firewall traversal", which seemed to
> describe why the selection of source port was useful.  This should be
> consolidated into one place.)

Applied. What part of the firewall traversal did you find particarly 
useful?

> Nit 6: Section 3.2:
>
>   The source port is chosen randomly between the range
>   49152-65535 and destination port is 50500.  The destination address
>   is the relay address.  The source address is one of the addresses of
>   the link, which are also referenced to as "unreflexive locators" in
>   ^^^^^^^^
>   this document.
>
> "Links" don't have addresses; I think this should be 'one of the routable
> addresses for the host' or something like that??  (I'm not sure)

Changed to routable addresses.

> Nit 7:  Section 3.3:
>
>   In the case of direct path, the hosts
>   prefer a path without transport layer encapsulation which means that
>   the hosts have no legacy NAT between them.
>
> This encapsulation has not previously been described in the document.

Added references.

> Question:  is legacy NAT the only reason for UDP encapsulation?  I would
> think a firewall that doesn't like the HIP protocol number might also be
> another reason.  And perhaps also another case is an operating system that
> doesn't understand HIP, where HIP is done entirely by the application?  I do
> not know HIP well enough to answer these two questions.

You are right. Added the HIP protocol issue. Did not add the operating 
system issue because it is an implementation issue.

> Nit 8: Section 3.3:
>
>   The
>   Initiator MUST pace the NOTIFY messages sequentially 20 ms apart (as
>   explained in [I-D.ietf-mmusic-ice]).
>
> FYI, this ICE pacing algorithm is going to be changed.  See Sally Floyd's
> response to my email about those upcoming changes at:
>  http://www1.ietf.org/mail-archive/web/tsv-area/current/msg00085.html

Thanks for the reference. For the time being, the draft is just 
referencing ICE on the pacing.

> Nit 9: section 8:
>
>   Thanks for Jonathan
>   Rosenberg and the rest of the ICE WG folks for the excellent work on
>                                 ^^^^^^
>   ICE.
>
> ICE is a product of the MMUSIC working group.

Sorry, my bad. Corrected.

-- 
Miika Komu                                       http://www.iki.fi/miika/

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 4 Jun 2007 18:16:20 -0700

> Thanks for feedback and apologies for the long delay. The 
> next preversion includes your comments and it is available here:
> 

I'll look at that tomorrow or Wednesday.

...

> Your assumption is correct assuming you mean relay instead of 
> rendezvous server. Should it communicate it?

Yes, at the same time you communicate the IP address, because
you can't assume the remote peer will be able to obtain the 
expected UDP port --- the NAT may very well have given a 
different host that UDP port already.

> include in the draft yet. The registration phase could be 
> identical to the connectivity test phase, except there not may 
> be a relay available yet and the packets are carrying REG 
> parameters. In this case, the packets would also carry the 
> locator information of the initiator to the relay.

That sounds similar to what ICE does.

Which brings up a huge meta-question:  why don't you just define
how to do an offer in HIP and an answer in HIP, and use ICE?  This
way you'd be sure to function all the time, as ICE has gone through
tons of peer review to ensure it always works in the weirdest of
network topologies.

> implementations because currently registration and 
> connectivity tests are handled differently. From a performance 
> point of view, this would increase the latency in the registration 
> to the relay server, but this probably is an acceptable cost.
> 
> What do you think?

I'd need to digest the suggestion some more.  As you know, I'm not
very hip in my understanding of HIP.

> 50500. The "typically" meant (now removed) that sometimes you 
> may want to use non-default ports.

If you only removed the word 'typically', and it now reads:

  ... the source IP address and port (50500) ...

then I'm really worried -- what happens when two hosts behind the same NAT
need to get that same port?

> If I recall correctly the original reason for this, it was 

Relying on the source port always being 50500 won't work at all, though, if
there are two hosts behind the same NAT -- no matter what kind of NAT you're
considering.  

Here is a concrete example of the problem I'm describing:

            |
         +--+--+
         | NAT |
         ++---++
          |   |
      +---+   +----+
      |            |
      |            |
    host-a      host-b

The HIP stack on Host-A gets UDP/50500, and the HIP stack on Host-B gets
UDP/50500.  One of them will be first to send a UDP packet across the
HIP-unaware NAT.  Let's pretend the winner is Host-A.  Host-B, when he sends
his UDP packet across the NAT, the NAT cannot give Host-B port 50000
(because it's being used by Host-A); instead, the NAT will get some other
UDP port from the range 1024-65535 (which is all that is required by the
BEHAVE UDP specification).   

By the way, the BEHAVE UDP specification is purposefully silent about port
preservation -- thus, there is no encouragement that NATs preserve ports.
This is by design, because relying on port preservation fails if another
application (on the same host) recently used the port or another host
(behind the same NAT) recently used the same port.  Thus, such a reliance
creates a fragile system that worked fine during product development (when
the developer had a single host and a single NAT).

...
> similarly as in draft-ietf-mm.

Ok, I'll re-read it with that in mind.

> I am unconvinced that we should drag the usernames and 
> passwords from ICE to HIP. HIP has alreadt a crypgraphically 
> more secure identifiers in the form of public keys (which can 
> btw include a NAI, such as foo@bar etc).

(ICE doesn't use the STUN username and password fields for
cryptographic security (or, really, any sort of real security); 
it uses them to ensure that connectivity has been established 
with the desired peer.  Please ignore the names of the fields;
they are carryovers from STUN's (RFC3489) original purpose and
really are misnomers when considered with ICE's connectivity
checks.)

Based on a comment you made below, it seems you're using HIT
as a similar peer identifier?

If so, what is the purpose of FROM_PEER?  

> I believe the connectivity tests will detect this.

Hmkay, I'll diagram it again on my whiteboard and try to figure
out how your connectivity checks will resolve this situation.

> Changed 
> the text to "the responder may be behind.."
>
> > I encourage you to not use IP addresses as identifiers, 
> > especially for NAT traversal.
> 
> The HITs are used as the identifier. Both source and 
> destination HITs are included in all HIP control packets.

Ah.  Thanks.

> alive, but the outgoing direction was more important.
> Is the incoming direction completely unimportant?

That's correct:  the NAT doesn't really care if a packet is 
received ouside->inside; sending a packet inside->outside is
what creates the initial state and also what resets the timer.

> document uses also this "behind" term loosely, but the 

This was just an observation I had about an optimization you could 
make, not an important point.  

If you were using STUN, your STUN Response would tell
you if you're behind a NAT.  If you are, then you have to generate
some kind of keepalive.  Likewise for the peer you're talking to --
they would learn (via an identical mechanism) if they're behind a
NAT.  This is learnable per flow.

You may well be able to do a similar optimization for HIP.  The
advantage of doing such an optimization is you drop the number
of packets necessary for your keepalive traffic by half.  This
can be very valuable on some networks (3G, for example).

...
> Applied. What part of the firewall traversal did you find particarly 

There were a few sentences that explained how, if everyone used
the same ports for HIP, a firewall could trust that all use of
those ports was HIP and could permit that traffic through the
firewall.

-d

---

From: Miika Komu <[email-masked]>
Date: Tue, 5 Jun 2007 12:42:41 +0300 (EEST)

On Mon, 4 Jun 2007, Dan Wing wrote:

> Yes, at the same time you communicate the IP address, because you can't 
> assume the remote peer will be able to obtain the expected UDP port --- 
> the NAT may very well have given a different host that UDP port already.

The current draft assumes that the same port (50500) of the relay can be 
used by several hosts. The multiplexing is done based on the ESP SPI 
numbers and not the UDP port. This description is still missing from the 
draft.

If we want to multiplex just based on the UDP port number, the relay 
client needs to punch a separate hole into its NAT and keep it alive 
separately. I think this would actually require the registration to 
include the connectivity test phase. A benefit of this could be that 
the UDP port could be allocated also from a regular STUN server.

> tons of peer review to ensure it always works in the weirdest of

Well, I guess the meta-answer is that HIP is not SIP. How would you design 
the protocol based on offer/answer? Could illustrate with a simple flow 
diagram? Please also illustrate the handover.

To me, the current draft is ICE fitted to the HIP protocol. We have 
already a base exchange protocol and mobility extensions for non-natted 
environments, so it made sense to me to reuse the existing mechanism for 
NATted environments. For example, registration is a base exhange and the 
connectivity test is almost the same as a mobility handover. A separate 
protocol mechanism would introduce larger code base for implementations 
which is not very nice.

> need to get that same port?

See the SPI discussion above.

> Here is a concrete example of the problem I'm describing:

I fail to see the problem here. The fixed port number is for receiving 
packets, either at the relay server or when the hosts are behind the same 
NAT.

When a host is behind NAT(s), the NAT(s) will translate the port. The host 
can discover the translated port number (reflexive relay locator) from the 
relay or during connectivity tests (reflexive peer locator). These 
reflexive addresses are given/discovered by the peer and the peer will use 
them to communicate with the host.

It does not really matter whether the NAT preserves the port or not as the 
translated port is sent to peer. If there is something said unclearly in 
the document about this, please give specific pointers to the text and/or 
suggestions to corrections.

> as a similar peer identifier?

Yes.

> If so, what is the purpose of FROM_PEER?

To discover the reflexive peer locators. See step 4 in section section 
3.4.

> make, not an important point.

This optimization could require some additional STUN-like tricks in the 
HIP NAT traversal protocol, like answering from a different port and/or IP 
address. This would introduce extra complexity to the protocol.

> can be very valuable on some networks (3G, for example).

Is STUN NAT detection 100 % sure with legacy NATs? If not, the 
optimization does not work in 100 % of the cases.

Yes, the dual-directional keepalives double the traffic, but they are also 
used for path failure detection. See section 3.7.

I still remain unconvinced that the optimization is worth it.

> those ports was HIP and could permit that traffic through the

The port for the host inside the firewall can be emphemeral and for 
the host outside of the firewall it is always 50500. I don't think it is 
necessary to require that both ports are 50500.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 5 Jun 2007 10:13:16 -0700

> numbers and not the UDP port.

But you can only accomplish that multiplexing after you're doing
IPSec ESP -- HIP runs before that, I think?

> This description is still 
> missing from the draft.
> 

Right.

> Well, I guess the meta-answer is that HIP is not SIP.

ICE does not require SIP.  

XMPP (Jabber) has implemented ICE, but XMPP is not SIP.  XMPP
did not have an offer/answer model, but in order to use ICE as-is,
they determined how to create one in XMPP, and XMPP exchanges the
information needed by ICE between the two endpoints to accomplish
the NAT traversal.

> How would you design the protocol based on offer/answer?

offer:
- gather candidate IP addresses and UDP ports
- send those candidate IP addresses and UDP ports to your intended
  HIP peer, via your rendezvous server.

answer:
- have your intended HIP peer gather its candidate IP addresses
  and UDP ports
- have your intended HIP peer send its candidate IP addresses and
  UDP ports back to the offerer, via your rendezvous server.

As soon as one side learns the candidate addresses of the other side
it can immediately begin doing connectivity checks.  For HIP, you
might want to map your two HIT identifiers directly into the STUN 
username field; you are already communicating your HIT to your
intended peer anyway.

> Could 
> illustrate with a simple flow diagram? Please also illustrate 
> the handover.

  Offer    NAT    STUN server   rendezvous server       Answerer
    |       |         |               |                    |
 1  |---------------->|               |                    |
 2  |<----------------|               |                    |
 3  |-------------------------------->|                    |
 4  |       |         |               |------------------->|
 5  |       X<=============================================|
 6  |       |         |               |<-------------------|
 7  |<--------------------------------|                    |
 8  |=====================================================>|
 9  |<=====================================================|
10  |<=====================================================|
11  |=====================================================>| 
 
1. gather candidates (send STUN binding request)
2. receive STUN binding response
3. send candidates to intended peer, via rendezvous server
4. message continues from rendezvous server to intended peer
5. intended peer does a connectivity check, which is dropped by 
   the NAT (let's pretend the NAT does some filtering, otherwise
   this message flow wouldn't be very interesting).
6. intended peer isn't behind a NAT, so doesn't bother with
   the candidate gathering; if it was behind a NAT, it would do
   its own candidate gathering.  This isn't shown in this message
   flow to keep it a little simplier.  Message 6 shows the 
   intended peer replying with its candidate address (which is
   its own IP address and UDP port).  
7. Answer is relayed, via the rendezvous server, to the offerer.
   The offerer now has the answerer's candidate IP addresses
   and candidate UDP ports.
8. Offerer sends a STUN Binding Request packet directly to the
   answerer's candidate IP address.  This is received by the
   answerer (the intended peer)
9. Answerer sends STUN Binding Response.  when offerer receives
   this message, the offerer knows -- without any doubt -- that
   it is communicating to the correct host (because that correct
   host proved it because it created a valid SHA1 HMAC of the
   message).  It can now communicate with it -- in HIP's case,
   initiate your HIP exchange with the peer and initiate IPsec
   ESP.
10. A so-called "triggered check" occurs, (due to receiving
   message 8), which causes the answerer to immediately send
   a STUN Binding Request to check its connectivity with the
   intended peer (the offerer).  This is really an accelerated
   re-transmit of message 5 (which was dropped by the offerer's
   NAT, due to his NAT's filtering rules).  
11. STUN response is sent, and received by the answerer.  It
   now knows it has bi-directional communication with the
   offerer.

> To me, the current draft is ICE fitted to the HIP protocol.

There are significant differences; for example, ICE doesn't 
use IP addresses as identifiers, because they are rendered 
meaningless with overlapped IP address space (192.168.1.2, 
commonly given to everyone's PC behind a Linksys/DLink/Belkin 
NAT).  The mechanism in HIP-NAT-TRAVERSAL seems to use IP
addresses as identifiers.

> We have already a base exchange protocol and mobility 
> extensions for non-natted environments, so it made sense to 
> me to reuse the existing mechanism for NATted environments. 
> For example, registration is a base exhange and the 
> connectivity test is almost the same as a mobility handover. 

I agree reusing those is useful; I think more of the stuff
that's in ICE -- using an identifier other than IP address
and proving proof of some private information (exchanged
via the rendezvous server between the intended peers) would
go a long way towards thwarting accidental association with
the wrong peer and towards thwarting attackers interfering
with handover.

> A separate protocol mechanism would introduce larger 
> code base for implementations which is not very nice.

Understood.  However, we need to tease apart the differences
between what ICE is doing -- successfully on the Internet --
and what you're proposing to do, and make sure HIP's NAT 
traversal will be as successful when HIP needs to traverse
non-HIP-aware NATs.  Saving a few hundred lines of code isnn't
the desired goal; successful operation on today's Internet is 
the desired goal.

> packets, either at the relay server or when the hosts are 
> behind the same NAT.

We must be talking past each other.

If the hosts are behind the same NAT, they're going to get 
different source UDP ports -- that's how every sane NAT
functions.  There can be no successful, properly operating
NAT that does port overloading -- it doesn't work.  That's
why it's a MUST NOT in the BEHAVE UDP specification.

> suggestions to corrections.

Yes, the document states that the source UDP port 50500 is 
retained when the UDP port traverses the NAT.  Specifically:

   3.1.  Port Number Selection

   The end-hosts need a fixed transport layer port number to be able to
   communicate with each other.  The end-hosts MUST accept incoming HIP
   and ESP traffic arriving at UDP port HIPPORT (future extensions may
   use the same port number for TCP). 

If an end-host already registers with a rendezvous server, I don't see the
need for assignment of a fixed UDP port.  Furthermore, if the end host does
allocate HIPPORT for use by HIP and that host is behind a NAT, then from the
perspective of all the other hosts on the Internet, the NAT _is_ the end
host.  And of course if that NAT has already allocated HIPPORT to another
host behind the same NAT, the NAT cannot also allocate the same HIPPORT to
this (new) host.  

Thus, you need to communicate both an IP address and UDP port to the
rendezvous server.  

Section 3.2:
...
   When the ESP relay registration was successful, the relay server uses
   the source IP address and port HIPPORT of the R2 packet to relay ESP
   traffic with the client.
...

Same problem -- the relaying agent (on the Internet) can't send traffic to
HIPPORT; it needs to send traffic to whatever UDP port was used to
communicate with the relay agent.

(The text in 3.3, which describes this same relaying again, describes it
correctly; it says:

   The
   relay MUST change the transport source to and destination of the
   packet to match the values the Responder used when registering to the
   relay, i.e., the reverse of the R2 used in the registration.
)

One new comment I have, is text in section 5, which reads:

   When the Initiator is behind a firewall, the NAT traversal mechanisms
   described in Section 3 depend on the ability to initiate
   communication via UDP to the destination port HIPPORT from arbitrary
   source ports and to receive UDP response traffic from that port to
   the chosen source port.  If the Initiator is behind a firewall that
   does not support "UDP connection tracking", the NAT traversal
   mechanisms described in Section 3 can still be supported, if the
   firewall allows permanently inbound UDP traffic from the port HIPPORT
   and destined to arbitrary source IP addresses and UDP ports.

It should be noted, though, that if there is a NAT between the hosts and the
firewall, the use of the source HIPPORT won't be useful:

  PC ---\
  PC ---\\
  PC ----++--[NAT]----[firewall]
  PC ---//
  PC ---/

because if all those PCs use the source HIPPORT, only the first one to cause
a UDP packet to traverse the NAT has any chance of getting the NAT to map
that same HIPPORT to the NAT's source UDP port.  The other 4 PCs will lose.

> To discover the reflexive peer locators. See step 4 in 
> section section 3.4.

Ok.  I'm still unclear on its overall purpose, but I did find the following
in section 3.4:

   If the FROM_PEER and TO_PEER do not
   match, the Responder may be behind a "p2p-unfriendly" NAT
   [I-D.ietf-behave-p2p-state].  This means the NAT does not preserve
   the transport locator of the Responder when it communicates with
   multiple hosts.  This kind of address-port pair is referred as "peer
   reflexive transport locator".  The Initiator MUST store the transport
   address for later processing.  The Initiator MUST transition the
   corresponding locator pair to ACTIVE state.

and in section 2 (introduction):

   In contrast, the relay service
   relays all HIP control packets because p2p-unfriendly NAT devices
   drop the packets otherwise [I-D.ietf-behave-p2p-state]. 

With ICE, there is one and only one case where a relay is needed.  That is
when _BOTH_ peers are behind p2p-unfriendly NATs.  If only one of the peers
is behind a p2p-unfriendly NAT, a relay is not needed.

We can design the same thing for HIP.  This is very desirable, I would
expect; everyone prefers to avoid relays.

> This optimization could require some additional STUN-like 
> tricks in the HIP NAT traversal protocol, like answering from 
> a different port and/or IP address. This would introduce extra 
> complexity to the protocol.

I believe you are referring to the mechanisms described originally in
RFC3489 in now described in draft-ietf-behave-nat-behavior-discovery.  That
is not needed to determine if you are behind a NAT; rather, those complex
steps are only needed to diagnose what *kind* of NAT you are behind.   I do
not recommend those procedures for anything; they are fragile at best, and
inaccurate at worst.  Their purpose in
draft-ietf-behave-nat-behavior-discovery is to assist in writing diagnostic
tools.  Their fragility, and the fact that ICE doesn't need those
procedures, is why they were removed from the update to RFC3489
(draft-ietf-behave-rfc3489bis doesn't mention those procedures at all).

Rather, I was suggesting just determining if you were behind a NAT; that's
trivial.  There are two cases:

  * your device wasn't configured with the IP address of a STUN server,
which means you must not be behind a NAT (or else you would have been given
the IP address of a STUN server in order to do candidate gathering)

  * if you were configured with a STUN server, you can send it a Binding
Request packet when your software first initializes.  If the Binding
Response indicates a different transport address (transport locator, in
HIP's terms, I guess?), then you know you're behind a NAT.  Thereafter,
whenever you establish UDP communications that cross that NAT, you know you
should be doing keepalives.  You would know if your UDP communications
crossed that NAT by sending a STUN Binding Request (or a HIP message that is
functionally the same) and learning that your peer saw that IP packet arrive
from a different transport address than you sent it from -- which means a
NAT was along that path that you are responsible for keeping alive its
binding.

> used for path failure detection. See section 3.7.

Yes, I agree they're useful for path failure detection; I figured you would
have a different technique for that, as it's useful to detect path failure
even without NATs.

> I still remain unconvinced that the optimization is worth it.

That's fine.  As I said, it isn't a big deal; it can be done later without
interoperability problems, too, so it's safe to defer it until there is a
need to reduce keepalive traffic by half.

> necessary to require that both ports are 50500.

Agreed.

-d

---

From: Miika Komu <[email-masked]>
Date: Wed, 13 Jun 2007 17:28:57 +0300 (EEST)

On Tue, 5 Jun 2007, Dan Wing wrote:

(sorry, response quite late again)

>>> Yes, at the same time you communicate the IP address, because you 
>>> can't assume the remote peer will be able to obtain the expected UDP 
>>> port --- the NAT may very well have given a different host that UDP 
>>> port already.
>>
>> The current draft assumes that the same port (50500) of the relay can 
>> be used by several hosts. The multiplexing is done based on the ESP SPI 

I didn't get this. We have two kinds of packets that the relay server can 
forward. It can forward either HIP or ESP packets:

* IP(UDP(HIP))
* IP(UDP(ESP(TCP or UDP)))
       ^   ^
       |   |
       +---+---- ESP forwarding/multiplexing can be done here. Either using
                 IP addresses and ports, or ESP SPI number. I am proposing
                 the latter.

This should be clarified in the draft.

>>>> include in the draft yet. The registration phase could be identical 
>>>> to the connectivity test phase, except there not may be a relay 
>>>> available yet and the packets are carrying REG parameters. In this 
>>>> case, the packets would also carry the locator information of the 
>>>> initiator to the relay.
>>>

Actually, it may be a better idea to treat HIP associations with relay 
registration differently from others. When a relay client initially 
registers to relay, the overhead of connectivity tests would be 
negligible. However, the overhead more critical with handovers. If 
connectivity tests have to be done before a handover, it will increase the 
latency and this will not be nice for e.g. TCP.

Or is there any good reason to do connectivity tests with a 
publicly-addressable relay server? The only good reason would be to get 
rid of the UDP encapsulation, but this would happen at the cost of a 
slower handover. Removal of the UDP encapsulation has some additional 
problems when the other peer is still behind NAT, so I am not sure if it 
is a good idea.

Currently I would just propose to keep the registration text as it is and 
add a description that relay HIP associations do not require connectivity 
tests.

>> Could illustrate with a simple flow diagram? Please also illustrate the 
>> handover.
>

12 |<================= base exchange =======================>|  ?

>   now knows it has bi-directional communication with the

12. Run base exchange over the UDP tunnel created by ICE?

A reason why this is not defined like depicted above is to reduce RTT 
time. A minor benefit is that we save some RTT by piggypacking the port 
allocation to RVS registration (this is actually missing from the above 
picture for the answerer). The rendezvous server is required anyway, so 
why not? A major benefit is for handovers. When a mobile client moves, it 
does not need to do connectivity tests with the rendezvous server (see 
above my comment on handling rendezvous registration and connectivity 
a little bit differently).

A minor reason is that we save some RTT by sending the first base exchange 
packet (I1) already in step 3. When the rendezvous is on the path, we save 
more RTT because we don't have to wait for base exchange until step 12. 
However, your proposal is better when the rendezvous server is far from 
the path between offerer and answerer because step 8 can be done (and 
should be done) without the rendezvous. In the current draft, R1 and I2 
messages have to be forwarded through the relay because they may contain 
also ESP relay information.

> There are significant differences; for example, ICE doesn't use IP 
> addresses as identifiers, because they are rendered meaningless with 
> overlapped IP address space (192.168.1.2, commonly given to everyone's 
> PC behind a Linksys/DLink/Belkin NAT).  The mechanism in 
> HIP-NAT-TRAVERSAL seems to use IP addresses as identifiers.

I did not still understand this comment. We probably have some sort of 
terminology mismatch here. If I understood correctly, ICE used username 
and password as the identifier. In HIP, the identifier is HIT, not IP. 
HITs are present in all HIP control packet headers. IP address are in IP 
packet headers, and also in HIP LOCATOR parameters (to inform the peer on 
all available locators).

>> We have already a base exchange protocol and mobility extensions for 
>> non-natted environments, so it made sense to me to reuse the existing 
>> mechanism for NATted environments. For example, registration is a base 
>> exhange and the connectivity test is almost the same as a mobility 
>> handover.
>
> I agree reusing those is useful; I think more of the stuff that's in ICE 
> -- using an identifier other than IP address and proving proof of some 
> private information (exchanged via the rendezvous server between the 
> intended peers) would go a long way towards thwarting accidental 
> association with the wrong peer and towards thwarting attackers 
> interfering with handover.

Yes.

> Understood.  However, we need to tease apart the differences between 
> what ICE is doing -- successfully on the Internet -- and what you're 
> proposing to do, and make sure HIP's NAT traversal will be as successful 
> when HIP needs to traverse non-HIP-aware NATs.  Saving a few hundred 
> lines of code isnn't the desired goal; successful operation on today's 
> Internet is the desired goal.

Saving RTT time is very important for successful user experience although
I like your idea of plugging the NAT traversal as a separate component 
below HIP layer from engineering point of view. It could actually allow 
even more software reuse.

> If the hosts are behind the same NAT, they're going to get different 
> source UDP ports -- that's how every sane NAT functions.  There can be 
> no successful, properly operating NAT that does port overloading -- it 
> doesn't work.  That's why it's a MUST NOT in the BEHAVE UDP 
> specification.

Yes, I think there was just a misunderstanding here. See below.

>> When a host is behind NAT(s), the NAT(s) will translate the port. The 
>> host can discover the translated port number (reflexive relay locator) 
>> from the relay or during connectivity tests (reflexive peer locator). 
>> These reflexive addresses are given/discovered by the peer and the peer 
>> will use them to communicate with the host.
>>
>> It does not really matter whether the NAT preserves the port or not as 
>> the translated port is sent to peer. If there is something said 
>> unclearly in the document about this, please give specific pointers to 
>> the text and/or suggestions to corrections.
>
> Yes, the document states that the source UDP port 50500 is retained when 
> the UDP port traverses the NAT.  Specifically:
>

I think I got your point now, but the fixed port number is still required 
for the relay server. The fixed port number is required at the relay when 
the a relay client registers through its NAT to a publicly-addressable 
relay server. In short, the fixed port number requirement applies only to 
the relay server, not to the end-hosts. This should be changed in the 
draft.

(I believe there is no need to use the fixed port number when the hosts 
are behind the same NAT since they can talk directly over IP)

> communicate with the relay agent.

It sends traffic _from_ HIPPORT. This needs to explained better in the 
draft.

> that same HIPPORT to the NAT's source UDP port.  The other 4 PCs will lose.

Only relays need the fixed port number, not the end-hosts. The relay sees 
the outernmost NAT IP address and port number, and uses it to send HIP 
control packets the correct PC.

Do you see any harm in using a fixed port number also at the end-hosts 
even though the NAT will translate it?

> is behind a p2p-unfriendly NAT, a relay is not needed.

The same applies to the current draft. Please suggest more detailed 
clarification if possible.

> need to reduce keepalive traffic by half.

Ok.

---

From: Philip Matthews <[email-masked]>
Date: Mon, 18 Jun 2007 22:13:06 -0400

I apologize for coming late to this discussion.
See comments inline.
- Philip

On 13-Jun-07, at 10:28 , Miika Komu wrote:

>>> Could illustrate with a simple flow diagram? Please also  
>>> illustrate the handover.
>>

First of all, I want to say that I basically agree with Dan.
You want to have an offer/answer exchange.
However, you do not need to actually include SDP in the HIP messages.
It is fine to encode the details into HIP TLVs as you have done in  
your draft.

Back in Prague, we discussed including the offer and answer in the I2  
and R2 messages respectively.
Thus the base exchange and offer/answer exchange happens at the same  
time.
Why not go with this design?

- Philip

---

From: Miika Komu <[email-masked]>
Date: Wed, 20 Jun 2007 09:10:45 +0300 (EEST)

On Mon, 18 Jun 2007, Philip Matthews wrote:

Hi,

> First of all, I want to say that I basically agree with Dan. You want to 
> have an offer/answer exchange. However, you do not need to actually 
> include SDP in the HIP messages. It is fine to encode the details into 
> HIP TLVs as you have done in your draft.

Ok. Please tell if there is still something missing.

> and R2 messages respectively. Thus the base exchange and offer/answer 
> exchange happens at the same time. Why not go with this design?

I did not forget about this. I thought about it for long and decided to 
change it for two reasons. First, to retain similarity with the HIP 
mobility draft (no locators in R2). Second, I thought that it would be 
more useful to have a single mechanism to trigger the 
reachability/connectivity tests. The UPDATE with LOCATOR acts as the 
trigger, both after a base exchange and a handover.