Subject: [Hipsec] Using STUN for end-to-end connectivity checks

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 07 Dec 2007 03:00:49 +0200

Folks,

as I said in our WG session, I have pushed the NAT Traversal for HIP 
design team to make a decision on the protocol to implement end-to-end 
connectivity checks. The design team was spending too much time thinking 
of this issue and, in my opinion (as HIP WG chair), this was keeping the 
team from making progress.

There were two proposals to implement the end-to-end connectivity 
checks: using STUN or using HIP. The design team agreed to make a 
decision before the end of the IETF. Today, we met for two hours to make 
this decision.

The idea was to make a design assumption (i.e., to use STUN or to use 
HIP) so that the team can work on other open issues and implementers can 
start experimenting. If by the time the specification is more or less 
done and we have more implementation experience, we find overwhelming 
evidence that this was the wrong decision, the design team agreed that 
we would able to reevaluate the decision.

The design team could not reach unanimous consensus on which protocol to 
use because there were technical arguments in favor of both of them. 
Therefore, they had to vote. The STUN approach won the voting (4 votes 
for STUN  2 votes for HIP).

Consequently, from now on, the team will be working assuming STUN as the 
protocol to implement end-to-end connectivity checks.

Cheers,

Gonzalo
HIP WG co-chair

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

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 7 Dec 2007 09:20:27 +0200

I would like to see the DT to clearly express their considerations,  
in writing, for the WG to think about.

Personally, I strongly suspect that the DT has made an  
architecturally wrong decision.  However, I trust that the DT then  
has other concerns that they have considered more important than  
architectural beauty (which in the past has been a main concern, or  
perhaps even the main concern, when making design decisions w.r.t.  
HIP).  Hence, I really want understand what those assumedly more  
important factors are.

--Pekka Nikander

On 7 Dec 2007, at 03:00, Gonzalo Camarillo wrote:

> Folks,
>
> as I said in our WG session, I have pushed the NAT Traversal for  
> HIP design team to make a decision on the protocol to implement end- 
> to-end connectivity checks. The design team was spending too much  
> time thinking of this issue and, in my opinion (as HIP WG chair),  
> this was keeping the team from making progress.
>
> decision before the end of the IETF. Today, we met for two hours to  
> make this decision.
>
> The idea was to make a design assumption (i.e., to use STUN or to  
> use HIP) so that the team can work on other open issues and  
> implementers can start experimenting. If by the time the  
> specification is more or less done and we have more implementation  
> experience, we find overwhelming evidence that this was the wrong  
> decision, the design team agreed that we would able to reevaluate  
> the decision.
>
> The design team could not reach unanimous consensus on which  
> protocol to use because there were technical arguments in favor of  
> both of them. Therefore, they had to vote. The STUN approach won  
> the voting (4 votes for STUN  2 votes for HIP).
>
> Consequently, from now on, the team will be working assuming STUN  
> as the protocol to implement end-to-end connectivity checks.
>
> Cheers,
>
> Gonzalo
> HIP WG co-chair
>

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 7 Dec 2007 08:12:02 -0800

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]] 
> Sent: Thursday, December 06, 2007 11:20 PM
> To: Gonzalo Camarillo
> Cc: HIP
> Subject: Re: [Hipsec] Using STUN for end-to-end connectivity checks
> 

Pekka,

Here are my thoughts on this (as one of the STUN proponents):

As background context, we are talking here about the syntax and
parameters of the STUN connectivity check that is used in ICE and flows
from end-to-end.  The requirement here is to make these look like the
data so that they flow through the NAT in the same way.  Since this is
end-to-end, we could pick a HIP-based encoding and put STUN parameters
in there (if needed), or we could pick a STUN-based encoding and put
additional HIP parameters in there (if needed), or invent some other
coding altogether

I do not doubt that the HIP WG or design team could come up with a
format more aligned to HIP.  This I think is the main argument for
defining a HIP connectivity check format.  I also think that it would be
viable to proceed down that path and it would have some advantages.

However, I question whether it is good strategy for the moment to try to
optimize in that area, for a couple of reasons.  
1) taking the STUN format and aligning with STUN where we can makes it
easier for HIP to leverage the STUN/ICE developments and lessons
learned, and focus on other things.
2) there seems to be some interest (see the SAFE BOF this week:
http://www3.ietf.org/proceedings/07dec/slides/safe-0.pdf ) for vendors
to build middleboxes that can tag the STUN messages for optimizing
(reducing) the keep-alive traffic.  If we wanted to take advantage of
that (if that work were to go forward), we would want to look like STUN
in that case.
3) using the STUN format makes it easier to incorporate STUN/ICE by
reference in our design document.

By the same token, I have observed that some people in the P2PSIP WG are
questioning "Why HIP?  Why not selectively pick good ideas from HIP that
are tailored to our particular problem requirements and discard the
rest?"  For consistency, I think it is not the best stance to be
recommending on the one hand "do not, by default, cherry-pick pieces of
HIP; consider the overall system before you resort to that" while on the
other saying "we want to take only the pieces of ICE/STUN that make
sense for us."  If we find strong technical reasons to diverge, so be
it, but that is not the case here from what I understand.

Regarding architectural purity, since we are talking about NAT
traversal, I think we are already sullied unfortunately.  I understand
the possible concern that things that are developed/used for NAT
traversal leak into other aspects of the HIP design (when not running
over NAT), but we will just need I think to monitor and evaluate that as
it comes up.  My personal feeling is that, in the public internet,
operating over NATs will be a very common mode of operation for some
time to come.

Also, you can see from Gonzalo's post that we reserved the right to
revert this decision in a few months if it appears that we goofed, and
the view was expressed that if we were to do so in the future, it would
be easier to recover back to HIP than if we proceeded with HIP initially
and then later tried to map back to STUN.  I also think it would
probably not be too much of a problem to add back in a pure HIP version
of these messages if it is desired later.

Some of these points above are subjective and different people have
different views of the future; hence the lack of consensus on the design
team. 

Regards,
Tom

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 11 Dec 2007 14:35:23 +0200

Tom,

Thanks for your reply.  I've been thinking it for a while, and find  
only a couple of your arguments even slightly convincing.  I think I  
have counter-arguments even to them, but let's see.  My main argument  
is in the very end of this message -- before that I'll just try to  
tear down your other arguments. :-)

> parameters of the STUN connectivity check that is used in ICE and  
> flows from end-to-end.

I don't quite agree with that characterisation.  I would say that we  
are talking here about the right approach for doing ICE-like  
connectivity checks to find out which address pairs to use for HIP- 
controlled control (HIP) and data (ESP, later others) traffic.

> The requirement here is to make these look like the data so that  
> they flow through the NAT in the same way.

I agree.

> Since this is end-to-end, we could pick a HIP-based encoding and  
> put STUN parameters in there (if needed), or we could pick a STUN- 
> based encoding and put additional HIP parameters in there (if  
> needed), or invent some other coding altogether.

I agree with that.

> defining a HIP connectivity check format.  I also think that it  
> would be viable to proceed down that path and it would have some  
> advantages.

Ok.  I have more to say about this, below.

> However, I question whether it is good strategy for the moment to  
> try to optimize in that area, for a couple of reasons.
> 1) taking the STUN format and aligning with STUN where we can makes  
> it easier for HIP to leverage the STUN/ICE developments and lessons  

Hmm.  I don't see how.  When I went down to the STUN and TURN details  
(for writing the hip-sturn draft), I found there many things that are  
"inconvenient" from a HIP point of view, even to the level of I would  
call them incompatible.  I no longer remember all of the details (I  
worked on that for only some 5 hours), but at least the following  
come still to my mind:

a. TURN (and I think also STUN) security requires pre-distributed  
shared secrets, or alternatively need to have the ability to have a  
side channel.  Pre-distributed creates an enrolment problem that HIP  
can trivially avoid, and using HIP to create such a side channel and  
then using STUN seems pointless to me; see below.

b. I found STUN referral completely insecure (that's why I didn't  
specify how to do it but only referred to a missing HIP delegation  
spec).  I suspect that might even form a vehicle for flooding  
redirection attacks, but I didn't analyse the situation well enough  
to see if that is really the case or not.

c. TURN relaying is tightly bound to TCP and UDP, and incompatible  
with ESP relaying.  Hence, while TURN could perhaps be used to relay  
ESP traffic, all that traffic would need to be UDP encapsulated.

Hence, while I agree with you in principle, I don't believe that in  
practise we could use STUN in an unmodified form.  I am pretty sure  
that we cannot use TURN as such.  But, of course, I may be wrong.

> http://www3.ietf.org/proceedings/07dec/slides/safe-0.pdf ) for  
> vendors to build middleboxes that can tag the STUN messages for  
> optimizing (reducing) the keep-alive traffic.  If we wanted to take  
> advantage of that (if that work were to go forward), we would want  
> to look like STUN in that case.

OK.  This is the first argument that I find somewhat convincing. I  
see the point.

However, after some thinking, I have two counter-arguments:

i) AFAICS, we can take advantages of such developments also through  
OPTIONAL mechanisms.  That is, if using STUN would be optional for  
HIP, we would avoid making HIP dependent on STUN but still allow HIP  
to benefit from STUN where-ever there are such advanced STUN  
deployments.

ii) As I argue towards the end of this message, I don't see how we  
could work _only_ with STUN servers.  That is, to me it looks like  
that we will anyway need HIP-specific RVS servers. That makes STUN  
servers to look unnecessary to me.

> reference in our design document.

That would be a reason if we really could do so.  However, as I wrote  
above, based on what I saw while writing the first incomplete version  
of the hip-sturn draft, I don't believe that to be case.  I don't  
believe that we could use STUN as it is.  But I may be wrong, and  
actually would like someone to prove me to be wrong, through  
implementation.  (I've discussed this with some implementers, and  
they say that their early exploration indicates that changes to STUN  
may be inevitable.)

Hence, if we would anyway need to adopt STUN to HIP, then I don't see  
much difference, i.e., I don't buy you argument of STUN-syntax  
approach being easier.  I think we can refer to those documents even  
if we are using HIP-based syntax, and define just a delta.  To  
clarify, I believe that independent of which of the two approaches is  
selected, such delta documents are needed, and that their complexity  
will be roughly at the same level.  I do admit that the HIP-syntax- 
based deltas are likely to be somewhat longer, but they may turn out  
to be easier to implement and have better support for mobility and  
multi-homing.

> By the same token, I have observed that some people in the P2PSIP  
> WG are questioning "Why HIP?  Why not selectively pick good ideas  
> from HIP that are tailored to our particular problem requirements  
> and discard the rest?"

And they may be right.  HIP may be a bad match for their specific  
requirements.

I think there is lots of good work in the STUN/TURN/ICE specs.   
However, I also find them very SIP-flavoured.  That is, in many  
places they seem to assume a side channel (through SIP proxies).   
Hence, for HIP we will anyway need to reconstruct such a side  
channel; we definitely should not attempt to reuse SIP proxies for  
that.  Consequently, if I'm right, we will need HIP RVS servers, and  
therefore we will not *need* (but could still optionally use) STUN  
servers.  See below.

> For consistency, I think it is not the best stance to be  
> recommending on the one hand "do not, by default, cherry-pick  
> pieces of HIP; consider the overall system before you resort to  
> that" while on the other saying "we want to take only the pieces of  
> ICE/STUN that make sense for us."  If we find strong technical  
> reasons to diverge, so be it, but that is not the case here from  
> what I understand.

While I can sympathise with your political arguments, I do see here  
technical reasons, as explained above and below.

> traversal, I think we are already sullied unfortunately.

Ok, that is the second argument I find somewhat convincing.  :-)    
But perhaps there are grades even in ugliness :-)  More seriously, I  
am concerned about unnecessary circular dependencies and enrolment  
hurdles.

> I understand the possible concern that things that are developed/ 
> used for NAT traversal leak into other aspects of the HIP design  
> (when not running over NAT), but we will just need I think to  
> monitor and evaluate that as it comes up.  My personal feeling is  
> that, in the public internet, operating over NATs will be a very  
> common mode of operation for some time to come.

Here we seem to agree.

> revert this decision in a few months if it appears that we goofed,  
> and the view was expressed that if we were to do so in the future,  
> it would be easier to recover back to HIP than if we proceeded with  
> HIP initially and then later tried to map back to STUN.  I also  
> think it would probably not be too much of a problem to add back in  
> a pure HIP version of these messages if it is desired later.

Ok, that I can buy, even though I don't really see it as a convincing  
argument for STUN-based syntax.  But if the DT/WG wants to play, I'm  
not too concerned with a six-months detour, either. :-)

------

Now, let me check if I still understand what the HIP NAT traversal is  
about.

My understanding is that with just UDP encapsulation (and nothing  
else) a HIP host behind a legacy NAT can contact any (UDP- 
encapsulation-supporting) HIP host in the public Internet.  Hence,  
solving the problem of having a client behind a NAT does not seem to  
require anything from STUN/TURN/ICE.

Hence, the problem we are attempting to solve with STUN/TURN/ICE is  
the problem of connecting to a HIP server that is located behind a  
NAT box.

By definition, a server behind a NAT box does not have a public IP  
address that one could send an I1 to.  Hence, to be reachable in the  
first place, the server needs to register at least one RVS server at  
the DNS.  Consequently, for the RVS server to be able to forward any  
arriving I1s to the server, the HIP server has to keep alive a UDP- 
encapsulated HIP control channel with the RVS server.  In more  
practical terms, the HIP server has to create a HIP SA with the RVS  
server (base exchange, over UDP encapsulation), to register as a RVS  
client with the RVS server, and then keep up the UDP-encapsulated  
channel through the NAT so that the NAT will be able to forward any  
I1s from the RVS server to the HIP server.

If that is the case, I fail to see where we need STUN or TURN  
servers.  As I try to show in the hip-sturn draft, it is a trivial  
extension to the HIP protocol for the RVS server to inform the HIP  
server about its public IP address and UDP port, as seen by the RVS  
server.  And that is exactly the service a STUN server is supposed to  
provide, and nothing else.  Or am I mistaken here.  Would a STUN  
server do something else but provide the HIP server with the external  
<IP address, UDP port> pair?

What comes to TURN, the RVS server already provides the ability to  
forward (I1) packets to the HIP server. Hence, I fail to see for what  
TURN is needed.

Hence, based on my perhaps completely flawed understanding, HIP does  
not need either STUN or TURN, as the same functionality either is  
already provided (TURN) or can be trivially provided (STUN) by the  
RVS server, which is needed anyway.  Accordingly, all that HIP can  
adopt from the STUN/TURN/ICE work is really the ICE algorithm, which  
I have been advocating all way along.  For the actual connectivity  
checks (Sections 7 and 8 of the ICE draft), I would simply use ESP,  
either as such or UDP-encapsulated, or whatever data encapsulation  
protocol is planned to be used if ESP is not used.  If something is  
needed inside (to solicit replies), simple ICMP (i.e. ping) would  
suffice.

Now.  Where do I go astray?  Or how the DT has thought to solve the  
problem in a different way so that STUN and/or TURN servers become  
useful?

--Pekka Nikander

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 11 Dec 2007 19:50:58 +0200

An afterthought:

> Now, let me check if I still understand what the HIP NAT traversal  
> is about.
>
> ...
>
> Hence, based on my perhaps completely flawed understanding, HIP  
> does not need either STUN or TURN, as the same functionality either  
> is already provided (TURN) or can be trivially provided (STUN) by  
> the RVS server, which is needed anyway.  Accordingly, all that HIP  
> can adopt from the STUN/TURN/ICE work is really the ICE algorithm,  
> which I have been advocating all way along.

So far so good, but ...

> For the actual connectivity checks (Sections 7 and 8 of the ICE  
> draft), I would simply use ESP, either as such or UDP-encapsulated,  
> or whatever data encapsulation protocol is planned to be used if  
> ESP is not used.  If something is needed inside (to solicit  
> replies), simple ICMP (i.e. ping) would suffice.

... here I was clearly too simplistic.  Within those ESP, ESP-over- 
UDP, or why not anything-over-UDP packets, we need something more  
sophisticated than ping, as connectivity may be one-way.   
Alternatives that I see are the following:

a) ICE-STUN messages according to the ICE spec.  Here using plain  
STUN might be appropriate, iff SAFE were to  take place and improve  
NAT behaviour.

b) messages preserving ICE-STUN semantics, such as STUN-encapsulated- 
in-ESP-in-UDP, or STUN-with-HIP-syntax-encapsulated-in-UDP

c) SHIM6 failure detection protocol [draft-ietf-shim6-failure- 
detection-09.txt], adopted to HIP.  (Such adoption should be very  
straightforward due to the by-default packet compatibility.)

Of course, there may be others that I fail to see now.

--Pekka Nikander

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 11 Dec 2007 12:05:12 -0800

Pekka, continuing this inline below 

> Sent: Tuesday, December 11, 2007 4:35 AM
> To: Henderson, Thomas R
> Cc: HIP

I have two responses here. 

1) I feel that we need some implementation experience with these
approaches before finalizing the NAT traversal draft; if what you
forecast turns out to be true, then it should become evident when we try
to work the details.  However, my default preference is to push on the
STUN/TURN approach until it is shown to be inadequate, rather than
immediately decide to go the other way.

2) if there are indeed problems with STUN/TURN mechanisms, wouldn't it
be better to fix those (or have those standards adopt HIP-friendly
options or extensions) than run in parallel?

I guess I don't really see the point of spending cycles right now to
redefine and document (diffs) how all of these HIP parameters relate to
ICE (btw, there are several more defined in ICE that are not mentioned
in the sturn draft), and it doesn't offend my sensibilities to suggest
that we just adopt STUN formatting for these messages.  Rather, I think
it would be nice if we find problems with STUN or TURN that we ask
whether options or extensions could be made to accommodate HIP, and end
up with a unified format.

You mentioned that REAP/FD from shim6 is an alternative for these
messages.  While I agree that it is much better aligned, it neither
supports IPv4 nor NAT traversal presently (although that also could be
fixed).  

Regards,
Tom

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 11 Dec 2007 22:26:41 +0200

>>> 1) taking the STUN format and aligning with STUN where we can  
>>> makes it easier for HIP to leverage the STUN/ICE developments and  
>>> lessons learned, and focus on other things.
>>
>> Hmm.  I don't see how.  When I went down to the STUN and TURN  
>> details (for writing the hip-sturn draft), I found there many  
>> things that [...] I would call ... incompatible.
>>
>> <snip>
>>
>> Hence, while I agree with you in principle, I don't believe that  
>> in practise we could use STUN in an unmodified form.  I am pretty  
>> sure that we cannot use TURN as such.  But, of course, I may be  
>> wrong.
>
> forecast turns out to be true, then it should become evident when  
> we try to work the details.  However, my default preference is to  
> push on the STUN/TURN approach until it is shown to be inadequate,  
> rather than immediately decide to go the other way.

I'm fine with that.  As I said, I'm fine with the WG taking a six  
month detour.  And, of course, I may well be wrong and it may turn  
out that what I currently consider as an almost-sure detour will turn  
out to be the right thing, after all.

Having done the somewhat-detail thinking today, I am no longer that  
convinced that STUN would really be wrong for the ICE connectivity  
tests (ICE sections 7 and 8).  There it may play nicely.

However, I'm still pretty convinced that trying to utilise existing  
STUN and TURN servers will be pointless, and we'll do better just  
with HIP RVS servers.  But I may be missing something there; I would  
even encourage people think of creative ways to use STUN or TURN  
servers as HIP RVS servers.  That would be an ubercool (and very  
ugly) hack.  :-)  Almost as cool as the idea of carrying HIP I1s in  
TCP options.  :-)

> 2) if there are indeed problems with STUN/TURN mechanisms, wouldn't  
> it be better to fix those (or have those standards adopt HIP- 
> friendly options or extensions) than run in parallel?

Maybe.  I cannot say as I haven't followed BEHAVE.

> supports IPv4 nor NAT traversal presently (although that also could  
> be fixed).

I don't see there any big issues in adding them.  As far as I can  
see, connectivity testing is really that, independent of whether the  
path is IPv4, IPv6, or NATed IPv4.  As long as the address candidates  
are there (and I still think the most sensible way to collect them in  
the NATted case is to use RLOCATOR from an RVS server), you can just  
churn them without really considering what kind of locators they  
are.  Ok, looking at REAP it appears that we would need to define how  
to encode IPv4 addresses and IPv4+UDP address+port pairs in the REAP  
PROBE message, but as far as I could see, that would be the only  
modification needed.

But I have to admit that I have not read ICE nor REAP in detail.   
Hence, I cannot really evaluate their pros and cons in real life  
situations.  It would be nice if people implemented both, just to  
compare.  That might even make a nice paper for someone.

--Pekka

---

From: Jan Mikael Melen <[email-masked]>
Date: Wed, 12 Dec 2007 10:47:20 +0200

Pekka Nikander wrote:
>> forecast turns out to be true, then it should become evident when we 
>> try to work the details.  However, my default preference is to push 
>> on the STUN/TURN approach until it is shown to be inadequate, rather 
>> than immediately decide to go the other way.
>
> month detour.  And, of course, I may well be wrong and it may turn out 
> that what I currently consider as an almost-sure detour will turn out 
> to be the right thing, after all.
>
> STUN and TURN servers will be pointless, and we'll do better just with 
> HIP RVS servers.  But I may be missing something there; I would even 
> encourage people think of creative ways to use STUN or TURN servers as 
> HIP RVS servers.  That would be an ubercool (and very ugly) hack.  
> :-)  Almost as cool as the idea of carrying HIP I1s in TCP options.  :-)
>

Concerning the STUN server usage for gathering your own addresses. Yes 
Pekka you are right and this was even decided by the DT that you have 
two different options how you gather them. First option is that you use 
the RVS to reflect your public address and second option is that you use 
STUN server which ever method you use is local policy issue. (Or even 
more generally speaking you could even manually configure your public 
addresses if you will)

As I see it from our implementation point of view I don't see why would 
you ever use a STUN server to reflect the addresses but some of the DT 
members thought that this would be sensible option to be left open. IMHO 
the RVS option is more natural from HIP point of view. Maybe the STUN 
option could be handy, if the scenario would be that people would have 
deployed RVS servers as defined by the current draft-ietf-hip-rvs which 
do not reflect your address (yes I know there is also some other 
limitations with these type of RVS servers as well but let's not go 
there), but as I see it the NAT traversal stuff should be ready before 
any flavor of RVS servers will be deployed anyway.

The TURN servers then again is a whole different story. It is like 
shooting a moving target. Even behave WG is not able to say yet how it 
looks like. They seem not to be able to even decide what kind of 
multiplexing header they would like to use which was once more modified :-)

   Regards,
      Jan

---

From: Lars Eggert <[email-masked]>
Date: Wed, 12 Dec 2007 17:48:40 +0200

> ugly) hack.  :-)  Almost as cool as the idea of carrying HIP I1s in  

In case you said that last thing to see if I'm paying attention - I  
am :-)

Seriously though, merging STUN/TURN with HIP RVS may make sense. As I  
understand it, although the old RFC3489 STUN was something that could  
be run on its own, the new-style 3489bis-style STUN merely provides  
some methods that can be used to build a NAT traversal solution, but  
isn't a complete one by itself. TURN uses the 3489bis-style STUN to do  
just that. It might be possible to use the 3489bis-style STUN with HIP  
RVS, to create a "HIP-TURN" thingie.

(My meta-issue with STUN/TURN/ICE is that the current documents aren't  
consistent with one another. That makes it difficult to understand how  
the pieces fit together. In addition, they were written when STUN/TURN/ 
ICE was targeted at SIP and RTP, and are now being updated to be a  
more general NAT traversal suite for any type of traffic. Significant  
chunks of the documents have this implicit assumption that data = SIP  
or RTP, and if you read them with a different application in mind,  
they don't answer all the questions.)

Lars

---

From: Philip Matthews <[email-masked]>
Date: Tue, 11 Dec 2007 15:43:11 -0800

I am also on the HIP NAT Traversal team and I also voted using STUN  
for connectivity checks.
Tom has expressed most of my thoughts below. I will just try to add a  
few more points.

I could not see any strong technical arguments one way or another.  
The best technical arguments that anyone seemed to come up in either  
direction seemed to depend heavily on guesses on how the future would  
evolve.

So a lot of it came down to gut feel. Personally, I feel that it is  
important to be practical and try to leverage the work being done  
elsewhere in the IETF as much as possible. As someone trying to sell  
the benefits of HIP to other (primarily P2PSIP), I already see a lot  
of "HIP - you cannot be serious" comments and non-verbal actions, and  
I felt that using HIP for connectivity checks would not help that  
situation.

I will also note that I asked Jonathan Rosenberg for his opinion, and  
convinced him to come to the HIP WG meeting to express it.

Personally, I am very willing to keep an open mind. If using STUN  
proves to be a mistake, then I think we can switch later, and also  
take that useful feedback to the BEHAVE working group.

- Philip

On 7-Dec-07, at 08:12 , Henderson, Thomas R wrote:

> flows
> would be
> try to
> WG are
> pieces of

---

From: Philip Matthews <[email-masked]>
Date: Tue, 11 Dec 2007 15:48:02 -0800

On 11-Dec-07, at 04:35 , Pekka Nikander wrote:

[Long message snipped]

> solving the problem of having a client behind a NAT does not seem  
> to require anything from STUN/TURN/ICE.
>
> address that one could send an I1 to.  Hence, to be reachable in  
> the first place, the server needs to register at least one RVS  
> server at the DNS.  Consequently, for the RVS server to be able to  
> forward any arriving I1s to the server, the HIP server has to keep  
> alive a UDP-encapsulated HIP control channel with the RVS server.   
> In more practical terms, the HIP server has to create a HIP SA with  
> the RVS server (base exchange, over UDP encapsulation), to register  
> as a RVS client with the RVS server, and then keep up the UDP- 
> encapsulated channel through the NAT so that the NAT will be able  
> to forward any I1s from the RVS server to the HIP server.
>
> server.  And that is exactly the service a STUN server is supposed  
> to provide, and nothing else.  Or am I mistaken here.  Would a STUN  
> server do something else but provide the HIP server with the  
> external <IP address, UDP port> pair?
>
> forward (I1) packets to the HIP server. Hence, I fail to see for  
> what TURN is needed.
>
> which I have been advocating all way along.  For the actual  
> connectivity checks (Sections 7 and 8 of the ICE draft), I would  
> simply use ESP, either as such or UDP-encapsulated, or whatever  
> data encapsulation protocol is planned to be used if ESP is not  
> used.  If something is needed inside (to solicit replies), simple  
> ICMP (i.e. ping) would suffice.
>

Pekka:

The use of the connectivity checks is not for getting HIP through  
NATs, but for getting the HIP Data plane (currently ESP) through  
NATs. All the stuff above is talking about HIP signaling, and your  
thoughts there are correct.

- Philip

---

From: Miika Komu <[email-masked]>
Date: Thu, 13 Dec 2007 09:01:53 +0200 (EET)

On Tue, 11 Dec 2007, Pekka Nikander wrote:

Hi,

> Hmm.  I don't see how.  When I went down to the STUN and TURN details (for 
> writing the hip-sturn draft), I found there many things that are 
> "inconvenient" from a HIP point of view, even to the level of I would call 
> them incompatible.  I no longer remember all of the details (I worked on that 
> for only some 5 hours), but at least the following come still to my mind:
>
> a. TURN (and I think also STUN) security requires pre-distributed shared 
> secrets, or alternatively need to have the ability to have a side channel. 
> Pre-distributed creates an enrolment problem that HIP can trivially avoid, 
> and using HIP to create such a side channel and then using STUN seems 
> pointless to me; see below.

If I recall correctly, it was Philip or Hannes who proposed to reuse HIP 
keymaterial with STUN.

> redirection attacks, but I didn't analyse the situation well enough to 
> see if that is really the case or not.

STUN referral?

> What comes to TURN, the RVS server already provides the ability to forward 
> (I1) packets to the HIP server. Hence, I fail to see for what TURN is needed.

TURN (media relay) forwards ESP traffic, not HIP traffic. The 
functionality of forwarding ESP traffic should be decoupled from 
forwarding of HIP traffic.

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

---

From: Miika Komu <[email-masked]>
Date: Thu, 13 Dec 2007 09:02:08 +0200 (EET)

On Tue, 11 Dec 2007, Pekka Nikander wrote:

>> For the actual connectivity checks (Sections 7 and 8 of the ICE draft), I 
>> would simply use ESP, either as such or UDP-encapsulated, or whatever data 
>> encapsulation protocol is planned to be used if ESP is not used.  If 
>> something is needed inside (to solicit replies), simple ICMP (i.e. ping) 
>> would suffice.
>
> ... here I was clearly too simplistic.  Within those ESP, ESP-over-UDP, or 
> why not anything-over-UDP packets, we need something more sophisticated than 
> ping, as connectivity may be one-way.  Alternatives that I see are the 
> following:
>
> a) ICE-STUN messages according to the ICE spec.  Here using plain STUN might 
> be appropriate, iff SAFE were to  take place and improve NAT behaviour.
>
> b) messages preserving ICE-STUN semantics, such as 
> STUN-encapsulated-in-ESP-in-UDP, or STUN-with-HIP-syntax-encapsulated-in-UDP
>
> c) SHIM6 failure detection protocol 
> [draft-ietf-shim6-failure-detection-09.txt], adopted to HIP.  (Such adoption 
> should be very straightforward due to the by-default packet compatibility.)
>

Regarding to option b, I have also thought about 
STUN-encapsulated-in-ESP-in-UDP, but never said it aloud for some reasons. 
Here I am assuming that you are reusing the symmetric keys and SPIs 
generated during base exchange for STUN messages. I see at least three 
problems in this approach:

* SPIs should be different on different network interfaces according to
   mm draft and you have only a single SPI pair after base exchange
* STUN messages have to be forced to use HITs in order to force the STUN
   message to go through the ESP tunnel. The IP addresses are
   usually fixed in ESP SAs and you would have to do some weird
   variations in the SAs to get the STUN messages through IP addresses
* I am not sure how cleanly this works after mobility events

Regarding to option c, one of the decisions of the DT was that the format 
for the connectivity tests and failure detection should be unified.

---

From: Philip Matthews <[email-masked]>
Date: Thu, 13 Dec 2007 08:53:20 -0500

> shooting a moving target. Even behave WG is not able to say yet how  
> it looks like. They seem not to be able to even decide what kind of  

I agree that TURN is a moving target. However, the recent changes are  
all based on feedback from the WG, and there is strong pressure to  
finish TURN-UDP soon. I think that TURN-UDP will be finalized before  
the HIP NAT Traversal stuff is.

- Philip

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 14 Dec 2007 09:08:29 +0200

Philip, Tom, and others,

First I must apologise for having misunderstood part of what the  
discussions and decision at Vancouver considered.  Briefly, I did not  
understand that the term "connectivity check" in the decision was  
limited to consider the ICE end-to-end connectivity checks, as per  
Sections 7 and 8 of the ICE draft, and not to connectivity checks  
e.g. w.r.t between a HIP host and an RVS server.  Once I've  
understood that (thanks to many people for clarifying this, both on  
the list and in off-list discussions), I see that I've risen a storm  
in glass of water.  Yes, I know several people said this to me  
upfront, but it took some time for me to understand.  Sorry for my  
denseness, especially to you, Tom.  I was stubborn enough not to  
understand the issue from your first mail.  My apologies.  [My only  
excuse here is that I do not see any big structural differences  
between different types of connectivity checks, and therefore tend to  
clump together all kinds of them.  See also below.]

I think there are still some issues, but much smaller than I  
originally thought.  Consequently, I have to reconsider both Philip's  
and Tom's argumentation.  That I do below.

Philip wrote:
> The best technical arguments that anyone seemed to come up in  
> either direction seemed to depend heavily on guesses on how the  
> future would evolve.

Having now understood what the issue is about, and that it is NOT  
about whether to use HIP RVS or STUN/TURN servers, I tend to almost  
agree.  While I do see there technical arguments for not using STUN  
(see below), they appear sufficiently vague so that I think we need  
to resort to experimentation to bring light to the issue.

<snip>
> take that useful feedback to the BEHAVE working group.

I like this attitude, and think the DT/WG can continue on the  
selected path.

>> lessons learned, and focus on other things.

I agree that it can make it easier for HIP to leverage.  However, I'm  
still worried about the shortfalls of STUN/ICE, in areas such as  
mobility, multi-homing, non-NATed (ESP) connections, and asynchronous  
paths.

The biggest issue here that I see is HIP desire to support other  
protocols but TCP and UDP, something that does not currently seem to  
align well with STUN/TURN.

>> optimizing (reducing) the keep-alive traffic.  If we wanted to  
>> take advantage of that (if that work were to go forward), we would  
>> want to look like STUN in that case.

I think that I already acknowledged that this may be a good reason to  
use STUN packet formats.  But maybe I didn't; I've been working with  
too many things lately so that my memory tends to fail time-to-time.

>> 3) using the STUN format makes it easier to incorporate STUN/ICE  
>> by reference in our design document.

Again, I now have to admit that maybe.  However, given my concerns  
above I am still not convinced.

>> traversal, I think we are already sullied unfortunately.

If connectivity checks were only about NAT traversal, I would need to  
fully agree.  However, given that I see the connectivity checks like  
this also needed in mobility (for return routability), multi-homing  
(for robustness), and therefore for non-NAT cases, I cannot fully  
agree.  I think we have to think about the overall architecture just  
because connectivity checks are not only about NATs.

>> monitor and evaluate that as it comes up.

Ok, I can live with that, as long as the DT keeps a keen eye on  
exactly those issues.

-----------

That all given, my main concerns seem to boil down to the following  
(but perhaps I'm still densely denying reality in some sense :-):

1. Return routability in mobility and connectivity checks for NAT are  
architecturally the same thing, though for different purposes.

2. Connectivity checks for multi-homing (a la SHIM6 REAP) and to  
determine a best address-pair for NAT-traversal are architecturally  
the same thing, with some differences related to NAT-state and  
asymmetric paths.

Given that, and given that I have not read in detail REAP nor ICE  
drafts, I cannot determine what is the best way forward.  As longer- 
term options, I see the following possibilities:

a. Design how to use STUN for return routability (could be already  
there -- need to be checked) and fail-over (needs work).

b. Design how to use REAP for NATed case (could be trivial or could  
require more work).

Personally, I would prefer the latter path, as it looks  
architecturally better aligned to me.  However, when we are dealing  
with legacy systems (NATs) and potential developments such as the  
SAFE proposal, non-architectural considerations may be more valuable  
than purely architectural ones.

----------

 From this, I think we get to a question that seems to fall between  
INT and TSV areas (I hope the ADs are listening).  How to proceed  
towards a unified connectivity check architecture for mobility, multi- 
homing, and NAT-traversal?  Such an (micro)architecture is needed for  
HIP, but could potentially benefit also other, non-HIP systems.

--Pekka Nikander

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 14 Dec 2007 13:20:28 +0200

Trying to think about this even more ...

>>> draft), I would simply ... whatever data encapsulation protocol  
>>> is planned to be used.

... I became stuck the above observation of mine.

I think here we have a major difference between SIP and HIP:

- in the SIP architecture, the actual data is carried by plain UDP or  
TCP, using different protocols above

- in the HIP architecture, the actual data is always encapsulated, in  
a form or another, in order to associate the data with a HIT pair,  
since the pair of IP addresses may be insufficient to indicate the  
HIT pair.

Hence, when considering ICE-like connectivity with HIP, there will  
always be such an encapsulation protocol.  Now, the *encapsulation*  
protocol could be UDP, in which case STUN might really be the right  
choice.  However, even in that case there would be an explicit  
decapsulator in the HIP case; something which typically is missing in  
a SIP case.

Hence, ...

>> Within those [data protocol connectivity check] packets, we need  
>> something more sophisticated than ping, as connectivity may be one- 
>> way.  Alternatives that I see are the following:
>> a) ICE-STUN messages according to the ICE spec
>> b) messages preserving ICE-STUN semantics [but differently encoded]
>> c) SHIM6 failure detection protocol ...

... I am starting to lean towards a direction where I think,  
tentatively, that the connectivity check protocol should be  
architecturally coupled with the data encapsulation protocol, in a  
way or another.  Apparently, the simplest case is where the  
connectivity check protocol is run within the data encapsulation  
protocol, as a separate protocol.  That would, presumedly, lead to  
maximum data path compatibility, since the boxes in the middle could  
not tell a connectivity check packet from a regular data packet.

If I am right in that thinking, then for *current* HIP, the options  
that apparently would do most sense are the following:

i) ICE-STUN-within-ESP, either UDP encapsulated or not

ii) REAP-within-ESP, either UDP encapsulated or not

Thoughts about that?

Miika writes:
> Regarding to option b) [aka i)], I have also thought about STUN- 
> encapsulated-in-ESP-in-UDP, but never said it aloud for some  
> reasons. Here I am assuming that you are reusing the symmetric keys  
> and SPIs generated during base exchange for STUN messages.

That was my assumption.  But then we have to remember that it  
wouldn't be just a plain base exchange, but it would also need to  
exchange the address/locator candidates.

> I see at least three problems in this approach:
>

Hmm.  Not necessarily, if you space the probes long enough from each  
other.  The reason for the different SPIs was to handle replay  
protection, which would become on the way if some of the links are  
really slow.  Here, if you manage to get packets both though a slow link

>   variations in the SAs to get the STUN messages through IP addresses

Hmm.  I don't quite understand this.

> * I am not sure how cleanly this works after mobility events

This may be a concern.  Can you clarify more?

--Pekka

---

From: Philip Matthews <[email-masked]>
Date: Fri, 14 Dec 2007 14:01:20 -0500

On 14-Dec-07, at 02:08 , Pekka Nikander wrote:

[First portion of message snipped.]

> 1. Return routability in mobility and connectivity checks for NAT  
> are architecturally the same thing, though for different purposes.
>

I agree that these seems to be basically the same thing. Personally,  
I think that ICE needs to be extended to handle mobility and perhaps  
multihoming. From what I hear from Marcelo, the Mobile IP folk are  
interested in the former as well.

> SAFE proposal, non-architectural considerations may be more  
> valuable than purely architectural ones.

I don't know much about REAP, but I agree that ICE and REAP seem to  
be similar protocols. So I mostly influenced by Marcelo, who has said  
that he thinks we are better off starting with ICE and adding  
mobility and multihoming, than starting with REAP and adding NAT  
traversal and mobility.

> towards a unified connectivity check architecture for mobility,  
> multi-homing, and NAT-traversal?  Such an (micro)architecture is  
> needed for HIP, but could potentially benefit also other, non-HIP  
> systems.

Marcelo pointed this out to me back in Chicago and we both spoke to a  
number of people about it. I was hoping that the HIP work would be a  
part of such an effort, but it doesn't currently seem to be.

- Philip

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 15 Dec 2007 15:35:58 +0100

El 14/12/2007, a las 8:08, Pekka Nikander escribió:

> If connectivity checks were only about NAT traversal, I would need  
> to fully agree.  However, given that I see the connectivity checks  
> like this also needed in mobility (for return routability), multi- 
> homing (for robustness), and therefore for non-NAT cases, I cannot  
> fully agree.  I think we have to think about the overall  
> architecture just because connectivity checks are not only about NATs.
>

one more thing about this: afaiu, probably NAT traversal techniques  
are not only required for dealing with nats but also to deal with  
stateful firewalls. So we need this not only in the v4 natted cas,  
but also in the more general case, for instance a v6 only case with  
stateful firewall in the middle of the path.

So, i am so worried about importing this t the multihoming and  
mobility case, since we would have done that in any cas to deal with  
the firewall case

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 15 Dec 2007 15:36:02 +0100

Hi,

El 14/12/2007, a las 20:01, Philip Matthews escribió:

>> That all given, my main concerns seem to boil down to the  
>> following (but perhaps I'm still densely denying reality in some  
>> sense :-):
>>
>> determine a best address-pair for NAT-traversal are  
>> architecturally the same thing, with some differences related to  
>> NAT-state and asymmetric paths.
>
> I agree that these seems to be basically the same thing.  
> Personally, I think that ICE needs to be extended to handle  
> mobility and perhaps multihoming. From what I hear from Marcelo,  
> the Mobile IP folk are interested in the former as well.
>

Well there are some people in the mobility community that are  
proposing that and i am personally interested, but it is far from  
general i would say.

>> drafts, I cannot determine what is the best way forward.  As  
>> longer-term options, I see the following possibilities:
>>
>> b. Design how to use REAP for NATed case (could be trivial or  
>> could require more work).
>>
>> architecturally better aligned to me.  However, when we are  
>> dealing with legacy systems (NATs) and potential developments such  
>> as the SAFE proposal, non-architectural considerations may be more  
> be similar protocols. So I mostly influenced by Marcelo, who has  
> said that he thinks we are better off starting with ICE and adding  

as you know, i was proposing the adoption of REAP for HIP  
multihoming. REAP was designed in a way that it can be trivially  
adopted in HIP. The first issue that need to be addressed, as Tom has  
mentioned, one is about v4 support. That is very easy and i don't  
think it is a problem

The second thing is much more critical and it is about supporting  
unidirectional paths.
In shim6 we have decided that we needed to support unidirectional  
paths, in order to be robust in the case of ingress filters. This was  
a design decision in shim6 and the result is the REAP protocol which  
is somehow more complex than a simple return routability check.

As you mentioned it seems clear that connectivity checks, failure  
detection keepalives, return routability checks for flooding  
prevention and keepalives to preserve nat binding state can be  
performed by the same type of packets. The main difference is about  
frequency and some additional information you need to include in some  
cases, but i guess it is fairly asy to find a single packet format  
that can be used in all cases without much additional cost.

However, it seems harder to extend this unidirectional path support  
that REAP provides for the NAT case in particular and for preserving  
NAT state alive. This is so because in some cases, since we are  
asuming unidirectional paths, the first packet can come from either  
direction. So if we want to support REAP in nat environments, we  
would need to do more work that would be non trivila imho to support  
the unidirectional path work. If we don't support the unidirectional  
path case, then we are not really ding rap, we are merely doing a  
return routability check imho. The question then is whether this is  
worth it. I really think that the complexity would be big and i think  
that at this stage and as a base mechanism, we should be able to live  
with the bidirectional assumption and leave the unidirectional case  
for future work at this stage.

So, imho we should use a single packet format for connectivity tests,  
failure detection, return routability and keeping nat state and at  
this stage we could do the bidirectional path assumption and probably  
we should be able to find a solution that provides most of th  
functionality that would be way much easy to understand and implment  
that having separate mechanisms and packet format for these.

exactly

this is needed in many protocols imho, HIP being one, but mip could  
also benefit from something like this. This is why probably a general  
nat traversal solution is very attractive and ICE seems a good  
starting point for this imho. I mean, essntially ICE is the response  
to that problem from the SIP community, so probbaly with their help  
we can extend this to the other protocols

Regards, marcelo

> Marcelo pointed this out to me back in Chicago and we both spoke to  
> a number of people about it. I was hoping that the HIP work would  
> be a part of such an effort, but it doesn't currently seem to be.
>
> - Philip
>
>

---

From: Miika Komu <[email-masked]>
Date: Mon, 17 Dec 2007 17:57:11 +0200 (EET)

On Sat, 15 Dec 2007, marcelo bagnulo braun wrote:

Hi,

> However, it seems harder to extend this unidirectional path support that 
> REAP provides for the NAT case in particular and for preserving NAT 
> state alive. This is so because in some cases, since we are asuming 
> unidirectional paths, the first packet can come from either direction. 
> So if we want to support REAP in nat environments, we would need to do 
> more work that would be non trivila imho to support the unidirectional 
> path work. If we don't support the unidirectional path case, then we are 
> not really ding rap, we are merely doing a return routability check 
> imho. The question then is whether this is worth it. I really think that 
> the complexity would be big and i think that at this stage and as a base 
> mechanism, we should be able to live with the bidirectional assumption 
> and leave the unidirectional case for future work at this stage.

Agree.

> failure detection, return routability and keeping nat state and at this 
> stage we could do the bidirectional path assumption and probably we 
> should be able to find a solution that provides most of th functionality 
> that would be way much easy to understand and implment that having 
> separate mechanisms and packet format for these.

The extensions for STUN that we have to write will be deployed far later 
than the current bis version, if ever. Also, I think we may have made 
a related conflicting choice in the design team; to avoid optimization and 
to use unified connectivity/failure/return/nat packet format. For these 
reasons, I'd actually suggest to use STUN only for connectivity tests. It 
is also easier to bolt to current implementations this way for initial 
experimentation.