[Hipsec-rg] Pekka Nikander's personal view on HIP related discussions at DC

[[e-mail] (Pekka Nikander)]

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