Subject: [Hipsec] Pekka Nikander's personal view on HIP related discussions at DC

From: [email-masked] (Pekka Nikander)
Date: Mon Nov 15 05:29:04 2004

Folks,

This collection of notes provides a _personal_ point of view to the 
discussions that I participated to during the DC meeting.  Most 
probably contains some controversial issues; if you want to discuss 
those, PLEASE DO START A NEW THREAD and make sure that you redirect 
your responses to the appropriate list, either WG or RG.  Thank you for 
keeping the mailing list discussions organised.

Outline/Summary
===============

- A lowest location-independent layer of identification
- A and B, or the value of non-secure identifiers
- What is core HIP?
- DNS semantics
- PATH, or HIP NAT traversal
- Extending the idea of locator
- Separation of signalling and data

A lowest location-independent layer of identification
=====================================================

In the good olde days, it was possible to use IPv4 addresses as 
universal identifiers for reaching *any* host in the Internet.  As 
argued in more detail in the architecture document, this had a great 
value, just as such.  Furthermore, this value has now been lost by the 
introduction of NATs, firewalls, IPv4 and IPv6 in parallel, mobility, 
address-based multi-homing, and a plethora of other things that break 
the "end-to-end", in some sense.

Currently, people are trying to fix the situation by introducing new 
location-independent name spaces.  Today, SIP identifiers are probably 
the most prominent example of this.  However, these new identifiers 
tend to be located at the application layer, and tend to be, at least 
to an extent, application specific.

If we could engineer and *deploy* a new *lowest* layer that provides 
universal, location-independent identifiers, that might re-establish 
the end-to-end connectivity that we used to have.  While SIP provides 
such a service in a limited way, it might not be at the right place in 
the stack.  On the other hand, there seems to be more momentum 
currently behind SIP, and in the usual Betamax vs. VHS fashion, SIP may 
be good enough so that few if any people bother even to try HIP.

Punch line:  Let's make HIP to go through current middle boxes at least 
as well as SIP does!

A and B, or the value of non-secure identifiers
===============================================

Right now, HIP seems to provide two "services" at its core.  It aims to 
provide identifiers that
   A. have a cryptographically strong binding to a public key, and
   B. have a location-independent end-to-end semantics, at the lowest 
possible layer in the stack.

There might be some value in separating A and B, and allowing upper 
layers to select either A+B or just B.  B would provide enough security 
just to protect innocent bystanders from flooding and other related 
attacks that might be created by B itself.  A+B, on the other hand, 
would provide the full package, i.e., that "You know whom you are 
talking to", where whom is defined by the public key.  That is, you 
know that you are talking to whoever/whatever possesses (a copy of) the 
private key corresponding to the public key that you are using a 
reference.

Punch line:  Let's make sure that *someone* (multi6?) provides plain B, 
too.

What is core HIP?
=================

An important question raised on Saturday's workshop was that of what is 
"core" to HIP?  In a way, this was a reaction to people using the term 
"HIP" to denote anything that is taking place at the working or 
research groups.  That seems to be confusing.  Hence, we should define 
in specific terms what are the fundamental properties of HIP and what 
are features that are build on the top of that.

As a starting point, I would propose the following:

   - A+B, from above, is core

   - being the *lowest* location-independent layer is core

   - the *idea* of location-independence (such as in middle box
     traversal) is core
     - the specific mechanisms for traversing specific middle
       boxes are NOT core

   - the *idea* of location-independence (such as in mobility)
     is core
     - mobility and multi-homing, as defined in the mobility
      and multi-homing draft, are NOT core

   - even the idea of rendezvous is NOT core but just as
     something that is needed for location-independence

The fact that HIP will eventually require us to reconsider the 
placement of various functions, such as congestion control, in the 
stack, is a feature and not a bug.  Hence, it is a direct consequence 
of what is core to HIP.

Punch line: Use "lowest location-independent" as Occam's razor!

DNS semantics
=============

Today, a (leaf) DNS name defines a service, not a host.  In many cases, 
the same service is provided by many hosts.  The current practise is to 
list the IP addresses of all of the hosts providing to that service 
under the given DNS name.  This is the semantics that HIP must conform 
to.

There is a separate thread on this on the WG mailing list, so no more 
on this here.

Punch line: Don't tell me what to put in my DNS!

Preferred Alternatives to Tunnelling HIP (PATH)
===============================================

I have changed my mind on HIP legacy NAT traversal.  Two years ago I 
opposed it on architectural bases.  A year ago I would not have done it 
myself but didn't oppose it any more.  Now I am doing it.

To make HIP the lowest location-independent layer in today's networks, 
we must make HIP to go through current NATs and firewalls.  While 
making pinholes through firewalls seems like an arms race, there is no 
question in the value of making HIP to go through current "convenience" 
NATs.  Those NATs are primarily there to solve the address space 
problem, and there are a hoard of applications that already make it 
possible to open a connection to a host behind a firewall.  STUN, ICE 
and other specifications already define how you should do that, for 
your application.  Let's make this application independent, allowing 
you to use both existing and future applications without having to 
worry about NATs.

Given that we can directly employ the mechanisms in STUN and ICE, this 
seems to be a relatively easy piece of work, now.  That might not have 
been the case two years ago.  In the future, we can probably lean even 
more to the work in produced by the BEHAVE and other working groups, 
without spending too much cycles on making this clean and mean.

Basically, we agreed to write two drafts:

   1. Packet formats for HIP over UDP and UDP as locator.

   2. A document specifying a STUN-server like HIP rendezvous server, 
and the protocols that you use to register to the server and making HIP 
connections to the host behind the NAT with the help of such a server.

Both documents should be relatively short, as they can mostly rely on 
work done elsewhere.

Punch line: Make UDP based NAT traversal a trivial combination of 
methods developed elsewhere.

What is a locator?
==================

As a starting point, HIP was designed to function on the top of the two 
versions of IP, providing connectivity over both of them.  
Unfortunately, IPv4 does not provide end-to-end connectivity today.  
Instead, one must use various kinds of hacks, like tunnelling other 
protocols on the top of UDP.

To keep the HIP architecture relatively clean, it looks preferable to 
model all the different means of providing end-to-end connectivity as 
locators.  That is, whenever there is an "address", i.e. a piece of 
information that allows one to make a connection, this is modelled as a 
locator.

The first such locator type to be defined would be for HIP-over-UDP 
tunnelling.  Basically, this requires one to convey information about 
IP addresses and UDP ports, and their usage; should a given port be 
used for HIP traffic, for ESP traffic, or for both?  If the latter, how 
exactly one should determine whether a received packet is a HIP or an 
ESP packet?

Hence, to me it looks like that we want to generalise the notion of 
locator, making HIP an universal non-tunnelling tunnelling protocol.  
That is, providing HIP with the generic hooks that allow HIP to 
traverse all the imaginable kinds of protocols, providing the "HIP 
connectivity service" on the top of that.  Note that while we use here 
tunnelling like mechanisms, this is not really tunnelling in the sense 
that we are providing something more than what is available below the 
tunnel, the A+B property from above, and we also provide the property 
of mobility across these various tunnelling methods.

As a result, I think that we should define an extensible locator data 
type, to be used the REA payload.  Additionally, it *might* make sense 
to define a new DNS resource record that allows one to store these 
additional locators into the DNS.  OTOH, my current feeling is that it 
is too early to propose the new DNS resource record.  We might as well 
try to get some operational experience with rendezvous and mobility 
based NAT traversal mechanisms first.

Punch line: HIP over Anything and Everything (HAE)

Separation of signalling and data
=================================

The way HIP is currently defined provide a convenient way of separating 
signalling and data traffic.  Basically, host-to-host signalling 
traffic is carried within the HIP protocol while data traffic is 
carried within the ESP protocol.  In the future, I surmise that we will 
support other data protocols but ESP, too.

As we now aim to support legacy NAT traversal, we probably need to 
provide some more flexibility on this.  For example, we may want to 
provide one UDP port for HIP traffic while using another one for ESP 
traffic.  More generally, we may want to express that one particular 
locator is only valid for HIP traffic while the other locator may be 
used for ESP traffic.  Even more generally, we probably want to add 
capabilities to locators, allowing us to express explicitly what each 
locator is good for.

The telecom people will love this, I am sure.  Finally they can 
understand TCP/IP, at least when HIP is used :-)

Punch line:  Let's make HIP appealing both to Internet and Telecom 
folks :-)

--Pekka

---

From: [email-masked] (Jari Arkko)
Date: Mon Nov 15 09:47:00 2004

Pekka Nikander wrote:

> tunnelling.  Basically, this requires one to convey information about IP 
> addresses and UDP ports, and their usage; should a given port be used 
> for HIP traffic, for ESP traffic, or for both?  If the latter, how 
> That is, providing HIP with the generic hooks that allow HIP to traverse 
> all the imaginable kinds of protocols, providing the "HIP connectivity 
> service" on the top of that.  Note that while we use here tunnelling 
> like mechanisms, this is not really tunnelling in the sense that we are 
> providing something more than what is available below the tunnel, the 
> A+B property from above, and we also provide the property of mobility 
> across these various tunnelling methods.

One aspect of the new locator concept is that location may
not be just data; it may also be state somewhere in the
network that has to be refreshed or it will expire. For
instance, in IKEv2 NAT traversal you have to do keepalive
to avoid the NAT forgetting that you have a connection
through it. Note that if we are doing multihoming, this
keepalive has to be kept not just for the current
locator but also for the backup(s)!

I wonder if we could generalize this somehow. Seems like
a dynamically allocated HIP rendevouz server might also have
soft state in the sense that it too needs to be reminded
now and then that it should serve you.

--Jari

---

From: [email-masked] (Pekka Nikander)
Date: Mon Nov 15 13:25:01 2004

>> information that allows one to make a connection, this is modelled as 
>> a locator.
>
> network that has to be refreshed or it will expire.

Right.

> I wonder if we could generalize this somehow.

Maybe we should add a field for expressing how often one
needs to refresh the state.  For a comparison, see
Section 5.3.7 of ICE:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-03.txt

> Seems like a dynamically allocated HIP rendevouz server
> might also have soft state in the sense that it too needs
> to be reminded now and then that it should serve you.

Right, but my assumption has been that the HIP registration
protocol (which will be split apart from the RVS draft) will take
care of that.  I have further assumed that the same mechanism
will be applied to architected middle boxes.  Hence, what remains
to be solved is those Locators that create implicit state, such
as NAT traversal.

--Pekka

---

From: [email-masked] (Pekka Savola)
Date: Mon Nov 15 15:08:00 2004

> to be solved is those Locators that create implicit state, such

It is also worth noting that NAT traversal functions change such 
rendezvous servers, to, basically, servers having to relay initial 
packets of a session.  Some who would be willing to deploy a DNS-like 
service may be unwilling to deploy network connectivity service.

The tricky part about NAT traversal is that you'll need to channel the 
incoming connectivity requests through a "rendezvous server", which 
has keep-alive state with every client it is servicing -- and the 
state must be refreshed with the interval of O("60 seconds") so that 
the data channel between HIP node behind the NAT box and the 
rendezvous server (and the HIP peers) remains open.  And when the 
incoming connection occurs, what remains is a rather complex and long 
set of signalling exchanges to set up a "shortcut path" which doesn't 
go through the rendezvous server, provided that that's what you want. 
(And if you don't want that, it's even more question of, "who would be 
willing to deploy such a service?")

All in all, that's a reasonably large amount of stuff to be done. 
Luckily enough, there is no necessity to reinvent the wheel, as e.g. 
Teredo should fit the bill if you just assume it's OK to use IPv6 if 
you're behind a NAT.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: [email-masked] (Pekka Nikander)
Date: Tue Nov 16 02:55:00 2004

> packets of a session.

Well, now I am confused.  According to the HIP architecture document, a  
HIP rendezvous server is used to forward (relay) the initial control  
packets, i.e., at least I1.  Hence, I don't understand how adding NAT  
support would change the rendezvous other than requiring the rendezvous  
server to support HIP over UDP.

> Some who would be willing to deploy a DNS-like service may be  
> unwilling to deploy network connectivity service.

Would you please elaborate.  I don't understand your comment.

> rendezvous server (and the HIP peers) remains open.

Right.  Again, as far as I understand the situation, there are two  
differences here between a non-NAT and NAT-supporting rendezvous  
servers:

   - support of HIP-over-UDP (PATH) packet format
   - shorter registration lifetime for the NAT-supporting RVS

The latter is a mere configuration issue; rendezvous is designed to be  
lease-based anyway.  In the case of NAT, you just get a very short time  
lease.

> And when the incoming connection occurs, what remains is a rather  
> complex and long set of signalling exchanges to set up a "shortcut  
> path" which doesn't go through the rendezvous server, provided that  
> that's what you want.

I don't see how this is so complex, but maybe I'm just naive here.  See  
slide 16 of  
http://hip.piuha.net/meetings/ietf61/slides/pres-ietf61-ad-hoc-nats- 
nikander.pdf  I think those on the PATH ad hoc meeting on Thursday  
morning pretty much agreed that it is the way to go.  Again, I may not  
understand the issue properly, but to me it looks like that the overall  
complexity of the base exchange does not change at all.  The only  
difference is that the first three packets (I1, R1, I2) are relayed by  
the RVS, which should not be *that* hard given that it already relays  
I1 and R1, and the last packet (R2) is used to drill the pinhole for  
forthcoming ESP traffic.

Yes, we probably need to add keep-alives for ESP, but that is part of  
ESP NAT-T already, isn't it?

> willing to deploy such a service?")

I really fail to see where the complexity creeps in.  I just fail to  
understand how NAT-supporting RVS is that much more complex than one  
that doesn't support.

If you doubt people willing to adopt RVS servers in the first place,  
then I don't have much to argue.  That is indeed a good question.

> Teredo should fit the bill if you just assume it's OK to use IPv6 if  

Right.  Some people in fact would favour Teredo, and I think it is a  
good solution.  OTOH, it doesn't require any new specs or anything new,  
at least in principle.  Just do it, if your OS supports Teredo and if  
you are willing to use the currently sponsored servers.

--Pekka Nikander

---

From: [email-masked] (Pekka Savola)
Date: Tue Nov 16 07:25:01 2004

Hi,

On Tue, 16 Nov 2004, Pekka Nikander wrote:
>> It is also worth noting that NAT traversal functions change such rendezvous 
>> servers, to, basically, servers having to relay initial packets of a 
>> session.
>
> Well, now I am confused.  According to the HIP architecture document, a HIP 
> rendezvous server is used to forward (relay) the initial control packets, 
> i.e., at least I1.  Hence, I don't understand how adding NAT support would 
> change the rendezvous other than requiring the rendezvous server to support 
> HIP over UDP.

Hmm, sorry, I seem to have had a terminology mismatch.  I recalled 
that a rendezvous server would be needed for establishing 
communications (instead of using, say, DNS), but maybe it isn't -- and 
you can deploy HIP without such a box.

>> And when the incoming connection occurs, what remains is a rather complex 
>> and long set of signalling exchanges to set up a "shortcut path" which 
>> doesn't go through the rendezvous server, provided that that's what you 
>> want.
>
> I don't see how this is so complex, but maybe I'm just naive here.  See slide 
> 16 of http://hip.piuha.net/meetings/ietf61/slides/pres-ietf61-ad-hoc-nats- 
> nikander.pdf  I think those on the PATH ad hoc meeting on Thursday morning 
> pretty much agreed that it is the way to go.  Again, I may not understand the 
> issue properly, but to me it looks like that the overall complexity of the 
> base exchange does not change at all.  The only difference is that the first 
> three packets (I1, R1, I2) are relayed by the RVS, which should not be *that* 
> hard given that it already relays I1 and R1, and the last packet (R2) is used 
> to drill the pinhole for forthcoming ESP traffic.

Are you making the assumption that only one end of the communication 
is behind a NAT, and not both of them?

It's certainly relatively simple if you can assume that you're 
initiating towards a non-NATted network, because there's MUCH less 
state to worry about, but if you need to care about NATs at the both 
ends (which is likely), and the case where the hosts behind those NATs 
use different rendezvous servers, it'll get quite tricky.

It wasn't 100% clear from the slides whether you had considered this 
case or not.

Are you also assuming that the hosts behind a NAT obtain dedicated 
"rendezvous service" from someone, and it can't (practically) be just 
an open service in the Internet? (Like Teredo servers and 6to4 relays 
are, nowadays.)

Just trying to ensure you don't fall to the same pitfalls STUN/ICE 
people did, and v6ops also did..

> If you doubt people willing to adopt RVS servers in the first place, then I 
> don't have much to argue.  That is indeed a good question.

Ok, this was my initial concern about adding too much weight to the 
RVS for relaying messages; that's OK, though the point about NAT 
traversal still stands.

---

From: [email-masked] (Pekka Nikander)
Date: Tue Nov 16 08:09:01 2004

[Updating subject line and removing Jari from CC, assuming that he can 
get this from list.]

>> Well, now I am confused.  According to the HIP architecture document, 
>> a HIP rendezvous server is used to forward (relay) the initial 
>> control packets, i.e., at least I1.  Hence, I don't understand how 
>> adding NAT support would change the rendezvous other than requiring 
>> the rendezvous server to support HIP over UDP.
>

Right, you can deploy HIP without rendezvous server.  Without NAT, 
rendezvous servers are needed to support fast mobility (so that you 
can't update your DNS entries) and simultaneous movement (the case when 
readdressing packets cross each other).  However, you may want to use 
then as an alternative for DNS, if you are willing to.  With NAT, of 
course, the situation changes as they make it possible to contact hosts 
that are behind NATs.

In a way, the base (or core) HIP architecture does not say exactly how 
to convey the very first packets end-to-end.  You may use DNS, you may 
use simple rendezvous, or you may use something more complex, like Hi3. 
  At its core, HIP is very much end-to-end.  It is just the 
complications with the current infrastructure that require us to deploy 
some sort of rendezvous.  Hence, it looks appropriate to match the 
rendezvous to the network reality.

> is behind a NAT, and not both of them?

Well, yes and no.  That may be where you get most benefit.  Or maybe 
not.  Anyway, if one of the NATs is not symmetric but even a port 
restricted cone, you can still establish an end-to-end connection 
fairly simply.  For the two symmetric NATs in a row case, there may not 
be any other possibility than to use a relay.  That case was, more or 
less, covered by the previous slide (1 of 3).

> use different rendezvous servers, it'll get quite tricky.

I admit that it gets tricky with two symmetric NATs.  And I admit that, 
based on what I've heard, it is sometimes very hard to tell whether 
your NAT is symmetric or not.

> an open service in the Internet? (Like Teredo servers and 6to4 relays 

Of course it can just open a connection to Internet.  That should be, 
by all means, trivial.  That's why it is not in the slides.  Or maybe 
there are some pitfalls there, too?  The tricky case is when you open a 
connection from the Internet to the NATted host, or, as you point out, 
when there are two NATs involved.

> people did, and v6ops also did..

Thanks, I appreciate that.  I am still learning the corner cases.  I 
think this discussion is important.

And, BTW, yes, I agree that a rendezvous server that is willing to pass 
the initial packets back and forth may not be willing to pass regular 
data traffic.

--Pekka Nikander