Subject: [Hipsec] HIP-ICE

From: Lauri Silvennoinen <[email-masked]>
Date: Fri, 24 Aug 2007 19:47:45 +0300 (EEST)

Hi all,

I'm trying to wake up the HIP-ICE discussion again. I have studied both 
the draft-ietf-hip-nat-traversal-01 and draft-tschofenig-hip-ice-00, and 
tried to figure out how HIP NAT traversal works according to the drafts. 
Based on these drafts, discussion with Miika and the figure and comments 
Dan Wing previously posted on this list, I sketched the following 
diagrams:

http://users.tkk.fi/~ljsilven/hip/comparison.html

We have the whole HIP life span illustrated in the figures. Host R is 
mobile. The data flow in the Komu, Schuetz, Stiemerling figure is pretty 
straightforward and is approved by Miika. However, the Tschofenig, Wing 
figure is just the best I came up with. Could somebody clarify how the 
packets should flow according to draft-tschofenig-hip-ice-00 or is the 
diagram ok as such.

In the figures, both of the hosts reside behind NATs and thus have their 
own Rendezvous Servers. We have the following basic phases in both of the
figures:

1) registration to HIP relay / RVS / TURN
2) DNS query
3) base exchange
4) ICE connectivity tests
5) ESP data flow
6) Handover, R moves
7) Closing of the HIP association

Also, because it was unclear to me what kind of middlebox is the RVS 
you're talking about in draft-tschofenig-hip-ice-00, I sketched both a 
STUN/TURN server and an RVS+HIP relay in the figure. Observe that this 
approach still needs a new registration type in the RVS, since the basic 
RVS is only capable of relaying the I1 packet. Or alternatively we can 
combine the RVS and STUN/TURN functionalities into a single middlebox,
as suggested in draft-tschofenig-hip-ice-00:

   "In Figure 1 the STUN server is co-located with the HIP rendezvous
    servers for editorial reasons.  From a solution point of view this
    is, however, not necessary."

Comments?

Lauri

> Date: Tue, 05 Jun 2007 10:13:16 -0700
> From: Dan Wing 
>
>  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.

> Date: Sat, 23 Jun 2007 10:31:39 -0700 [direct link]
> From: Dan Wing
> 
> The important difference with draft-tschofenig-hip-ice isn't the
> encoding on-the-wire.
> 
> Rather, the important difference is performing ICE.  Those steps
> are:
>
>   Initiator:
>     * gather candidate addresses
>     * send candidate addresses to remote peer (terminator)
>       via a rendezvous protocol (HIP, in this case; SIP in
>       the traditional case of ICE)
>
>   Terminator:
>     * gather its own candidate addresses
>     * perform connectivity checks with the remote peer
>       (initiator) to find a functional path to the initiator
>     * send candidate addresses to remote peer (initiator) via
>       a rendezvous protocol (HIP)
>
>   Initiator:
>     * perform connectivity checks with the remote peer
>       (terminator)
>     * prioritize successful checks and determine which path
>       is preferred (for example: avoid UDP encapsulation,
>       take a path over only HIP-aware NATs if that's desirable,
>       avoid NATs and take direct path, etc.).  This choice is
>       communicated to the remote peer (terminator), so it can
>       make the same choice so bi-directional traffic can be
>       assured (which is necessary to keep all the NATs open).

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

---

From: Miika Komu <[email-masked]>
Date: Sat, 25 Aug 2007 16:43:14 +0300 (EEST)

> Comments?

Some thoughts below based on your analysis. Please correct if I am wrong:

* STUN/TURN/ICE does not define a forwarding mechanism that exchanges
   transport addresses for hosts (reliably). Therefore, ICE relies on
   external mechanisms to exchange the initial transport addresses.
* As a consequence of previous point, draft-tschofenig-hip-ice-00 relies
   on a HIP base exchange to communicate the initial transport addresses.
   (Also, the I1 packet is NOT the nicest place to insert transport
   addresses)
* The currently defined RVS forwards only I1 packets. This means
   that we need new relaying mechanism.
* There is no specified format for transport addresses in base, mm or rvs
   drafts for transport. A new format is needed.

It seems to me that the coarse-grained approach in 
draft-tschofenig-hip-ice-00 converges towards something like 
draft-ietf-hip-nat-traversal-02 when you think about the details of how to 
use ICE with HIP.

I came up with one additional point on "next generation" NAT middleboxes. 
If we want to make a NAT box HIP aware, does it make sense that the box is 
required to parse both STUN and HIP messages?

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