Subject: [Hipsec] ICE-for-HIP: the design choices

From: Philip Matthews <[email-masked]>
Date: Sun, 24 Jun 2007 08:55:16 -0400

Dan Wing wrote (in a separate thread):
> That said, I would really like to first concentrate on the *steps*  
> involved
> in ICE, and how to make them work with HIP.  Because that must  
> first be
> agreed upon before we can reasonably discuss HIP parameter encoding.

What I believe Dan means by the above is that we should first  
concentrate on the
major design choices in a NAT traversal solution for HIP before  
worrying about the little details.
And I totally agree with him.

Here are what I see as the major design choices for a ICE-for-HIP  
design:

1) How (e.g., in what messages) are the ICE offer and answer conveyed?
    (Hannes and Dan are proposing the I2 and R2 messages; Miika is  
proposing the R1 and
     an Update message immediately after the Base Exchange).

2) What protocol is used for connectivity checks?
    (Hannes and Dan are proposing STUN; Miika is proposing HIP)

3) What is the general approach to encoding the Offer and Answer?
   (Hannes and Dan seem to be proposing using the existing text  
encoding;
    Miika is proposing a binary encoding using existing and new TLVs)

4) Do we follow ICE procedures exactly, or do we do some variations  
if they seem appropriate?
    (Hannes and Dan are proposing to follow the ICE procedures almost  
exactly;
    Miika is proposing a protocol that is ICE-like)

5) How do we integrate the security scheme of ICE with the security  
scheme of HIP?

6) How do we handle mobility?
    (Since this is something not really handled by ICE today)

I suggest that a good way to proceed is to try to reach agreement on  
these design choices,
before proposing a detailed proposal.

- Philip

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

---

From: Philip Matthews <[email-masked]>
Date: Sun, 24 Jun 2007 09:07:33 -0400

> Here are what I see as the major design choices for a ICE-for-HIP  

Let me add one other:

7) Do two HIP endpoints ALWAYS perform ICE, even if they have reasons  
to believe
    that they both have public addresses?
    (With SIP, the proposal is to always run ICE, partly because  
there is no sure
     way for an endpoint to tell when ICE is not needed, and partly  
because ICE
     brings advantages beyond NAT traversal: for example, selection  
of the best address
     to use when an endpoint is multihomed).

- Philip

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 24 Jun 2007 15:49:48 +0200

Hi Phillip,

Philip Matthews wrote:
>    (With SIP, the proposal is to always run ICE, partly because there 
> is no sure
>     brings advantages beyond NAT traversal: for example, selection of 
> the best address
Well, there is ICE lite. We suggest to make use of it if one of the end 
point knows for sure that it has global IP addresses and is not located 
behind a stateful packet filtering firewall or similar stuff.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 24 Jun 2007 15:52:12 +0200

Hi Phillip,

a nice summary. Let me just add a minor detail:

Philip Matthews wrote:
>> in ICE, and how to make them work with HIP.  Because that must first be
> Here are what I see as the major design choices for a ICE-for-HIP design:
>
>   (Hannes and Dan seem to be proposing using the existing text encoding;
Actually, we wrote that we just use the current encoding unless someone 
is really excited about the few bits you could save.

> 4) Do we follow ICE procedures exactly, or do we do some variations if 
> they seem appropriate?
Why do you think so? Mobility and multi-homing are just cases where a 
new candidate becomes available and others may become invalid (or may 
work again).

Ciao
Hannes

---

From: Philip Matthews <[email-masked]>
Date: Sun, 24 Jun 2007 10:28:34 -0400

On 24-Jun-07, at 09:49 , Hannes Tschofenig wrote:

>> 7) Do two HIP endpoints ALWAYS perform ICE, even if they have  
>> reasons to believe
> Well, there is ICE lite. We suggest to make use of it if one of the  
> end point knows for sure that it has global IP addresses and is not  
> located behind a stateful packet filtering firewall or similar stuff.

My question was not so much about ICE vs ICE-lite, but more about  
existing HIP procedures
vs. anything ICE-related. It was more:
    Do we see the existing HIP procedures being maintained for the  
situations where they work,
    or everything being redone with ICE in mind?
There would be a lot of simplification if a HIP endpoint always  
followed the ICE procedures (or ICE-lite as you point out).  
Otherwise, there will be two rather different procedures, with no  
reliable way (other than configuration) to detect when the non-ICE  
procedures can be used.

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Sun, 24 Jun 2007 10:40:39 -0400

On 24-Jun-07, at 09:52 , Hannes Tschofenig wrote:

> a nice summary.

Thanks. And thank you for your draft, which helps by providing a view  
of an alternative approach which motivates this discussion.
> Why do you think so? Mobility and multi-homing are just cases where  
> a new candidate becomes available and others may become invalid (or  
> may work again).

The procedures in section 8.3. Freeing Candidates of the ICE spec  
state that a candidate should be freed up after 3 seconds if it is  
not selected for the media exchange.

But in mobility situations, it might make sense to keep alternative  
candidates alive. Consider a mobile computer or phone which has both  
an 802.11 interface and a cellular interface. In the office, the  
computer should probably prefer the 802.11 interface. But what  
happens if the user is in the middle of a voice conversation or doing  
some similar real-time activity when he/she walks out of the  
building? Would it not be nice if ICE-for-HIP allowed the alternative  
of keeping the cellular path alive so traffic could switch to this  
path immediately without having to relocate the remote end and re-offer?

Put another way -- HIP today just talks about a change in address.
But I think we need to subdivide that into two cases:
- Make-before-break cases where we add a new address before losing  
the old one, and
- Break-before-make cases where we lose the old address before  
gaining a new one.
I would like the first cases to have rapid handover.

- Philip

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 24 Jun 2007 19:30:10 +0300

> And I totally agree with him.

Let me take a stab, though somewhat uninformed.  I'm sorry if what I  
write below doesn't make any sense at all.

>     an Update message immediately after the Base Exchange).

I don't have any good opinion here, since I don't understand what  
kind of semantics the choices would imply.

For the record, in the past there has been discussions about whether  
to include LOCATOR parameters already into R1 (I think we rough  
consensus was that it could be allowed as an optional feature, though  
a risky one from a DDoS point of view), or whether to piggyback them  
into I2 and R2.  See Section 3.2.9 of the M&M draft.
http://www.ietf.org/internet-drafts/draft-ietf-hip-mm-05.txt

But, from the past discussion point of view, I think it might make  
sense to follow M&M.

>    (Hannes and Dan are proposing STUN; Miika is proposing HIP)

This hasn't been addressed by HIP so far.  Hence, based on your  
description I don't understand what Miika is proposing.  For me,  
based on the information I've seen so far (and I may miss quite a  
lot), it would probably make most sense to encode STUN somehow within  
HIP.  (I outlined some possibilities in a previous message.)

>    Miika is proposing a binary encoding using existing and new TLVs)

 From the code size point of view, binary TLVs, either existing ones,  
new ones, or ones adopted from STUN, would most probably make most  
sense.  But there may be other aspects beyond the size and complexity  
of the code.

Any implementors around, your opinions?

>    (Hannes and Dan are proposing to follow the ICE procedures  
> almost exactly;

This one goes beyond my current understanding.

> 5) How do we integrate the security scheme of ICE with the security  

I'd be very interested to see someone explaining this in detail.  I  
think this is one of the main issues.

>    (Since this is something not really handled by ICE today)

Mobility is pretty much handled by the M&M draft, though perhaps not  
fully for make-before-break or multi-homing situations.  But, are  
there any good reasons to deviate from that draft?  If there are, I'd  
like to here them explicitly.  That draft has been around, in various  
forms, for three or four years and has received quite a lot of scrutiny.

>     to use when an endpoint is multihomed).

Something similar we have discussed several times in the past.

My strong opinion has been that from an architectural point of view  
it would make most sense to try to run HIP directly, without UDP  
encapsulation, first.  Or at least in parallel with the UDP- 
encapsulated exchange, in the case there are strong reasons to  
suspect that UDP-encapsulation is needed.  The main rationality here  
is that from an architectural point of view UDP encapsulation should  
eventually disappear (maybe in 20 years or so), and we should  
*primarily* engineer our protocols for architectural cleanliness and  
flexibility, and only secondarily for optimality under current  
circumstances.

In the past, idea in the HIP community has been to utilise the SHIM6  
path diversity protocol to select the best address(es).  But maybe  
ICE is better thought out, at least for the IPv4 NAT case.

Anyway, as I said, perhaps the best way would be to draw the best  
ideas from both ICE and SHIM6, and try to combine them for a HIP- 
specific mobility, path diversity / multi-homing, and NAT traversal  
protocol.  I think the M&M draft takes care of most of the mobility- 
specific stuff already, offers some initial hooks for multi-homing,  
and includes the LOCATOR parameter that was explicitly designed to  
allow NAT traversal.

--Pekka Nikander

---

From: Miika Komu <[email-masked]>
Date: Mon, 25 Jun 2007 14:51:25 +0300 (EEST)

On Sun, 24 Jun 2007, Philip Matthews wrote:

>> That said, I would really like to first concentrate on the *steps* involved
> concentrate on the major design choices in a NAT traversal solution for 
> HIP before worrying about the little details. And I totally agree with 
> him.

Both drafts are based on ICE, so I still think that the encoding is the 
main issue here. But ok, let's concentrate on the high level design issues 
of the encodings instead of worrying about the bits yet.

Also, regarding to the design choices, I would like to remind the 
draft-tschofenig-hip-ice-00 authors to show some flow diagrams in their 
draft. The current draft only considers mostly about protocol encodings 
and showing the diff between ICE. high-level operation is still very 
blurry in the draft.

>  (Hannes and Dan are proposing the I2 and R2 messages; Miika is proposing 
> the R1 and

I have no strong opinion of moving the LOCATOR from the R1 to the R2. The 
drawback is the "incompatibility" with draft-hip-mm, but the benefit would 
be in terms of monetary cost. We briefly discussed the topic with Philip 
last week and the credit for the idea really belongs to him. To explain 
the motivation for this, let's consider a multihomable Responder with two 
NATted interfaces. The first interface is a "free", but unstable WLAN 
interface, and the second is a "hi-cost", stable cellural interface.

The Responder normally keeps only the WLAN interface up because it does 
not want to pay for the NAT keepalives. However, the responder may 
activate also the cellular interaface and its costful NAT keepalives, but 
only upon receiving a high-priority HIP connection (based on Initiator 
HIT).

If the secondary interface is activated upon receiving I1, the Responder 
is subject to costful DoS because it is trivial to forge I1 packets. 
However, the situation is better when the secondary interface is activated 
upon receiving the I2. The I2 packet is protected using a signature and it 
even contains the solution of the puzzle. Now, the Responder can activate 
the secondary interface and send the related information in R2.

Comments?

>  Miika is proposing a binary encoding using existing and new TLVs)

Text encoding takes too much space and fragmentation of HIP packets should 
be avoided to reduce RTT. The UDP header already eats some bits. If we use 
text encoding, we may end-up introducing silly compression methods in 
later standards.

>  (Since this is something not really handled by ICE today)

draft-ietf-hip-nat-traversal-02-pre6 describes mobility in terms of 
draft-mm UPDATE handover (LOCATOR, ECHO_REQUEST, RESPONSE). The 
reachability detection is basically a handover.

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

---

From: Miika Komu <[email-masked]>
Date: Mon, 25 Jun 2007 14:51:37 +0300 (EEST)

On Sun, 24 Jun 2007, Hannes Tschofenig wrote:

>> 7) Do two HIP endpoints ALWAYS perform ICE, even if they have reasons to 
>> believe
>>    (With SIP, the proposal is to always run ICE, partly because there is no 
>> sure
>>     way for an endpoint to tell when ICE is not needed, and partly because 
>> ICE
>>     brings advantages beyond NAT traversal: for example, selection of the 
>> best address
> Well, there is ICE lite. We suggest to make use of it if one of the end point 
> knows for sure that it has global IP addresses and is not located behind a 
> stateful packet filtering firewall or similar stuff.

This is addressed in draft-ietf-hip-nat-traversal-02-pre6:

3.4.  Connectivity Tests

    There is no relay when the RELAY_TO parameters are not present.  In
    this case, the hosts SHOULD allow the transmission of ESP traffic
    even though the base exchange is sent over the transport layer.  A
    possible scenario where this can occur is when the Initiator is
    behind a NAT and Responder is located in a public network.

---

From: Miika Komu <[email-masked]>
Date: Mon, 25 Jun 2007 14:52:02 +0300 (EEST)

On Sun, 24 Jun 2007, Hannes Tschofenig wrote:

> Actually, we wrote that we just use the current encoding unless someone is 
> really excited about the few bits you could save.

I am. I don't like fragmentation.

> Why do you think so? Mobility and multi-homing are just cases where a new 
> candidate becomes available and others may become invalid (or may work 
> again).

ICE draft does not define how to handle end-host mobility and the security 
challenges related to mobility.

How does the mobility in your draft integrate with regular draft-mm 
mobility?

---

From: Miika Komu <[email-masked]>
Date: Mon, 25 Jun 2007 14:53:56 +0300 (EEST)

On Sun, 24 Jun 2007, Pekka Nikander wrote:

> I don't have any good opinion here, since I don't understand what kind of 
> semantics the choices would imply.
>
> For the record, in the past there has been discussions about whether to 
> include LOCATOR parameters already into R1 (I think we rough consensus was 
> that it could be allowed as an optional feature, though a risky one from a 
> DDoS point of view), or whether to piggyback them into I2 and R2.  See 
> Section 3.2.9 of the M&M draft.
> But, from the past discussion point of view, I think it might make sense to 
> follow M&M.

I believe the main reason why the LOCATOR is in R1 is that the Responder 
can "force" the Initiator to switch immediately to an alternative address 
already in I2. However, this cannot be applied to NAT traversal because 
reachability detection for working addresss pairs must be done first.

Tom, can you comment this?

> description I don't understand what Miika is proposing.  For me, based 
> on the information I've seen so far (and I may miss quite a lot), it 
> would probably make most sense to encode STUN somehow within HIP.  (I 
> outlined some possibilities in a previous message.)

The connectivity tests are done after a base exchange or a handover 
(both relayed through RVS over UDP).  We are proposing to trigger the 
reachability detection using HIP UPDATE. This is followed by ECHO REQUEST 
and RESPONSE messages that do the UDP hole punching and verify address 
reachability as in draft-hip-mm.

Philip also asked if we could send the I2 message with NATted LOCATORs for 
triggering the connectivity tests. This would save one packet 
transmission, but the trigger mechanism would be different for base 
exchange and mobility.

> From the code size point of view, binary TLVs, either existing ones, new 
> ones, or ones adopted from STUN, would most probably make most sense.  But 
> there may be other aspects beyond the size and complexity of the code.
>

I already gave a comment on the fragmentation to reduce extra RTTs.

>> 4) Do we follow ICE procedures exactly, or do we do some variations if they 
>> seem appropriate?

I believe I borrowed all ideas from ICE that HIP needs. I am open for more 
detailed comments if someone finds any.

> Mobility is pretty much handled by the M&M draft, though perhaps not fully 
> for make-before-break or multi-homing situations.  But, are there any good 
> reasons to deviate from that draft?  If there are, I'd like to here them 
> explicitly.  That draft has been around, in various forms, for three or four 
> years and has received quite a lot of scrutiny.

draft-ietf-hip-nat-traversal-02-pre6 is heavily based on draft-hip-mm.

> My strong opinion has been that from an architectural point of view it would 
> make most sense to try to run HIP directly, without UDP encapsulation, first. 
> Or at least in parallel with the UDP-encapsulated exchange, in the case there 
> are strong reasons to suspect that UDP-encapsulation is needed.  The main 
> rationality here is that from an architectural point of view UDP 
> encapsulation should eventually disappear (maybe in 20 years or so), and we 
> should *primarily* engineer our protocols for architectural cleanliness and 
> flexibility, and only secondarily for optimality under current circumstances.

This is handled by the prioritization algorithm. It prioritizes non-UDP 
encapsulated reachability tests as the first.

> In the past, idea in the HIP community has been to utilise the SHIM6 path 
> diversity protocol to select the best address(es).  But maybe ICE is better 
> thought out, at least for the IPv4 NAT case.
>
> Anyway, as I said, perhaps the best way would be to draw the best ideas from 
> both ICE and SHIM6, and try to combine them for a HIP-specific mobility, path 
> diversity / multi-homing, and NAT traversal protocol.  I think the M&M draft 
> takes care of most of the mobility-specific stuff already, offers some 
> initial hooks for multi-homing, and includes the LOCATOR parameter that was 
> explicitly designed to allow NAT traversal.

Agree.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 25 Jun 2007 09:57:41 -0700

>     behind a NAT and Responder is located in a public network.

The hosts should only send traffic after a successful connectivity
check.  Otherwise if that NAT doesn't do what is commonly called "IPsec 
passthru" (which is NATting using the IPsec SPI), ESP won't work.  And 
even in cases where IPsec Passthru is supported by a NAT, many of them 
are quite brain-dead in their support; for example, an old Linksys NAT
that I own only allows one host behind the NAT to connect to one IPsec
host -- if I try to have another host connect to the same VPN 
concentrator, that second host will never succeed (until I switch
to IPsec-over-UDP or IPsec-over-TCP).

-d

---

From: Miika Komu <[email-masked]>
Date: Mon, 25 Jun 2007 21:15:16 +0300 (EEST)

> to IPsec-over-UDP or IPsec-over-TCP).

The text I cited concerns only UDP-encapsulated ESP traffic. Perhaps I 
should clarify it to the draft.