Subject: RE: AW: [Hipsec] Rebuilding ICE

From: Miika Komu <[email-masked]>
Date: Fri, 10 Aug 2007 11:25:22 +0300 (EEST)

On Tue, 10 Jul 2007, Dan Wing wrote:

Hi,

some comments below after a long and refreshing summer holiday...

> Yes, it is clear that not all 100 pages of ICE would apply to HIP.
>
> The first version of ICE (draft-rosenberg-sipping-ice-00.txt, Feb-2003) was
> 34 pages.  That is only one page longer than
> draft-ietf-hip-nat-traversal-00!  In four and a half years of design, ICE is
> now 110 pages long and is used on the Internet (Google, MSN, and Yahoo use
> ICE for their interactive audio and video features).

is it already? I thought that the ICE development efforts have been frozen 
as the specs have been changing too much, but I may be wrong.

Regarding to the specification length, I think it is rather common to have 
long IETF specifications. I think the goal is not to optimize the length 
the draft, but to design technically the best NAT traversal protocol for 
*HIP*, what ever it is and in whatever format. Also, I don't see how 
changing the format of packets substantially delays the standardization 
completion time as long as the ICE acts as a blueprint to the protocol.

> I expect the HIP working group (or IRTF, as you are proposing) could
> re-invent ICE in less than 4.5 years -- afterall, ICE can be used as a
> design guide.  However, what is the value in spending IETF/IRTF time and
> energy re-inventing ICE?  Any shortcuts may not work well, whereas ICE was
> designed (and works) in all NAT scenarios after significant peer review.
> Those additional 70 pages in ICE weren't added because the author's fingers
> needed the exercise!  There are already ICE libraries available with
> reasonable licensing terms.  There are people willing to help HIP (and MIP,
> and RTSP) get ICE specified.

We are not re-inventing ICE. We are mostly debating on the on-wire format 
for ICE. I said "mostly" because there are some things, such as 
cryptographic end-host identities, mobility and rendezvous functionality 
in HIP, that are not handled within the current ICE specifications. Such 
things remain technically unaddressed in hip-ice-00 draft.

> My attempt to improve HIP's NAT traversal are clearly undesired by the
> working group.  If and when HIP desires a functional, robust, and
> incrementally-deployable NAT traversal mechanism, that works on the
> Internet, hopefully someone will drop me an email and I can engage with HIP
> again.

It is not clear to me how the approach in hip-ice-00 is more incrementally 
deployable because you need to first deploy HIP enabled rendezvous 
servers. As explained later, the rendezvous server as defined in 
hip-ice-00 should also have a STUN service running. Also, the "relay" 
service as defined in ietf-hip-nat-traversal-02 could be supported in 
rendezvous servers.

The draft situation is currently annoying and I would like to proceed 
forward because there are implementation activities starting on the topic 
in two projects. To speed-up the process, below is my qualitative, 
technical comparison on hip-ice-00 and ietf-hip-nat-traversal-02 
approaches. But first, I am including my view on ietf-hip-nat-traversal-01 
draft since there are at least two persons still supporting the approach. 
For the time being, I am still oriented towards ietf-hip-nat-traversal-02 
approach for the reasons I hope the comparison will explain better. 
Technical, detailed comments would be highly appreciated!

ietf-hip-nat-traversal-01:

+ Smallest RTT of all of the approaches.
+ Simplest to implement and natural integration to RVS architecture,
   with the exception of some hole punching hacks. Most of the
   "NAT intelligence" is contained at the RVS.
+ Stateless operation for RVS
- Responder privacy is neglected; the RVS reveals automatically the R
   location. The reason for the lack of privacy are the hole punching
   hacks in the RVS.
- Biggest drawback is fallback to TURN relay with p2p-unfriendly NATs.
   It is not possible to negotiate this as the base exchange packets are
   dropped in such case, and relaying all packets would result in some
   thing similar to ietf-hip-nat-traversal-02. Alternatively, this could be
   overcome using a separate record in DNS (or DHT) for TURN.
   Once again, the TURN protocol would require a similar box as the full
   HIP/ESP-relay  in the 02-draft. Still, sounds like a hack and the switch
   to full relay would have really long waiting delay and RTT.
- What about interoperability with an ICE-based approach?
- Does not endorse end-host multihoming.

hip-ice-00:

+ A benefit of this approach is that we can reuse ICE implementations, at
   least partially.
- However, you need hacks in ICE like inserting HITs in place of
   ICE usernames.
- ICE specs do not address mobility or multihoming.
- It would also seem like ICE is actually in control of the mobility and
   multihoming rather than HIP. I think this conflicts with the mm-draft.
- The approach may be more insecure than nat-traversal-02.
   Particularly, ICE messages are not protected with signatures of HIP
   public keys?
- ICE security issues section is quite long. Can we avoid introducing the
   security issues to HIP by using HIP protocol along with its HMACs,
   signatures, puzzles and return routability mechanisms?
- I believe the ICE relay mechanism requires state in the RVS for
   the Initiator if STUN is used as it is. Please correct if I am wrong.
* It is unclear to me how the wide use of STUN/ICE in varying protocols
   would be helpful for HIP. At least it does not seem to help with
   ICE-aware middleboxes because ICE was primarly designed for legacy NAT
   traversal without middleboxes.
* I think the proper term for the "rendezvous server" in the draft would
   be "rendezvous AND stun server" as these separate services are really
   coupled into a single server. HIP has nothing to do with STUN message
   forwarding.
* This approach is claimed to support incremental deployment. Well, you
   need to deploy RVS boxes first and the RVS boxes (or relays, as in 02
   version of the draft) can also support outer-NAT transport address
   detection.

ietf-hip-nat-traversal-02:

+ <Invert all the drawbacks from hip-ice-00 and insert them here as
   benefits>
+ Reuses the HIP TLV format which has smaller space requirements as it is
   a binary format.
+ I think this approach has less RTT than ICE draft. Better user
   experience and less packets congesting the network.
- Requires reimplementing ICE in HIP implementations (but reuses most of
   the existing base exchange / UPDATE extensions).
* Does not mandate extra STUN servers. The less dependencies to
   middleboxes, the less we have extra points for possible failure.
* HIP requires to deploy new RVS boxes anyway; why not embed also the NAT
   relay ability to them?
* The claim on the mailing list was that standardizing this would take
   more time. I partially disagree because the draft follows ICE design.
* The major functional difference to ICE is that there is no controller;
   the end-hosts can end-up with asymmetric paths to each other. However,
   it is possible to introduce this feature if somebody convinces me in
   technical detail that this is really necessary for *HIP*.

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

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

---

From: Philip Matthews <[email-masked]>
Date: Fri, 10 Aug 2007 12:57:32 -0400

>   technical detail that this is really necessary for *HIP*.

Another advantage of the Controller concept is that it provides a  
form a "future-proofing" for ICE.
Can you describe how future-proofing working in ietf-hip-nat- 
traversal-02?

On a related topic: A difference between ICE-for-SIP and the use of  
ICE ideas for HIP
is that the former carries traffic of different types in different  
streams, while the latter
carries them in one steam. So if one kind of traffic wants a high- 
bandwidth stream but is willing to
tolerate high delay, but another kind of traffic wants a low delay  
but is willing to  tolerate
low-bandwidth, then in ICE-for-SIP, these two different traffic types  
can take different paths.
However, I believe both ICE-for-HIP proposals force all the traffic  
exchanged over a HIP association
to take the same path. Am I correct? Is there some way to solve this  
problem?

- Philip

---

From: Miika Komu <[email-masked]>
Date: Mon, 13 Aug 2007 13:50:05 +0300 (EEST)

On Fri, 10 Aug 2007, Philip Matthews wrote:

> Another advantage of the Controller concept is that it provides a form a 
> "future-proofing" for ICE.
> Can you describe how future-proofing working in ietf-hip-nat-traversal-02?

Based on section 14 of the ICE draft, I think the main purpose of the 
controller remains the same even for future proofing, that is, to enforce 
same address pair at the "controlling" host. If a host is running ICEv2 
(capable of selecting more optimal address pair than ICEv1) and its peer 
is running ICEv1, and when the ICEv2 host happens to be the controller, it 
can enforce a better address pair without the pressure to upgrade all 
hosts to ICEv2.

However, it seems like that it will be based on luck that the ICEv2 host 
will be the controller in the communications. According to section 5.2 of 
the ICE draft, the ICE version number plays no role in selection of the 
controller role. Please correct me if I am wrong.

Thus, it seems to me that main component for future-proofing for ICE are 
the triggered checks. They are also included in ietf-hip-nat-traversal-02.

> On a related topic: A difference between ICE-for-SIP and the use of ICE 
> ideas for HIP is that the former carries traffic of different types in 
> different streams, while the latter carries them in one steam. So if one 
> kind of traffic wants a high-bandwidth stream but is willing to tolerate 
> high delay, but another kind of traffic wants a low delay but is willing 
> to tolerate low-bandwidth, then in ICE-for-SIP, these two different 
> traffic types can take different paths. However, I believe both 
> ICE-for-HIP proposals force all the traffic exchanged over a HIP 
> association to take the same path. Am I correct? Is there some way to 
> solve this problem?

draft-tschofenig-hip-ice does not really talk about this, but I guess it 
is assumed that a single, bi-directional UDP tunnel is set-up as a result 
of ICE connectivity tests. The purpose for the tunnel is the same also for 
ietf-hip-nat-traversal-02. However, the difference is that you may end-up 
with two uni-directional tunnels due to lack of the controller role. As a 
result, you end up with one or two streams.

I consider the primary goal of UDP tunnels is to get HIP and ESP traffic 
through. A secondary goal is to set-up multiple tunnels with different QoS 
characteristics. The secondary goal requires HIP-aware applications as 
described in:

http://www2.tools.ietf.org/html/draft-pierrel-hip-sima-00

(or maybe it could described here as well:
http://www.ietf.org/internet-drafts/draft-ietf-shim6-multihome-shim-api-03.txt
http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-02.txt
)

I think draft-tschofenig-hip-ice can accomplish multiple UDP tunnels using 
the "foundation" mechanism. This foundation concept is currently excluded 
from ietf-hip-nat-traversal-02 because the focus is not on QoS and I think 
it can be done using the mobility extensions described in section 3.7 of 
the draft.

I would personally concentrate on the QoS issues in a different draft.