Subject: [Hipsec] Generic locator data for REA

From: [email-masked] (Pekka Nikander)
Date: Mon Nov 15 07:32:00 2004

Below is my initial proposal for the new locator data type,
to be carried by the REA payload.

Initial design constraints:
- support extensibility
- support variable length data
- keep 64-bit alignment
- support locator roles, i.e., what a locator can be used for
- optimise support for the most common locator types
   - IPv4 address
   - IPv6 address
   - IPv4 address + UDP port number

Base locator header:

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |             Type              |            Length             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                              SPI                              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       Locator Lifetime                        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Locator type  |    Flags    |P|         Locator roles     |H|E|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Locator type:

   0  Reserved
   1  IPv4 address
   2  IPv6 address
   3  IPv4 address and UDP port

There must exist an explicit specification and packet formats for
any new locator type, such as HIP over TCP, HIP over HTTP, etc..

Flags:

   P  Preferred locator

Locator roles

all zero: Reserved
   H  These locator(s) can be used for sending HIP packets to the 
recipient.
   E  These locator(s) can be used for sending ESP packets to the 
recipient.

For IPv4, the base header is followed by 0-N IPv4 addresses, each taking
4 bytes.  The number of addresses is determined by the parameter length.

For IPv6, the base header is followed by 0-N IPv6 addresses, each taking
16 bytes.  The number of addresses is determined by the parameter 
length.

For IPv4 UDP encapsulation, the base header is followed by 0-N data
structures of the following format.  The number of structures is 
determined
by the parameter length.

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |         Role XOR mask         |            Port               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                        IPv4 address                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where Role XOR mask is a mask that is applied to the  Locator roles,
allowing the bits to be flipped for this specific locator, and the Port
is the UDP port.

--Pekka

---

From: [email-masked] (Julien Laganier)
Date: Mon Nov 22 11:20:01 2004

Hi Pekka,

> to be carried by the REA payload.

<snip>

I find this proposal very good. I have some questions, though:

Is the sender of such header supposed to determine the the Locator=20
Lifetime of a specific (Address,Port) tuple when a NAT is present? If=20
so, is this determination supposed to occurs while registering with a=20
Rendezvous Server, or while communicating with the remote node?

Thanks,

=2D-julien

=2D-----------------------------------------------------------------
Base locator header:

0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| =A0 =A0 =A0 =A0 =A0 =A0 Type =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0=
 =A0 =A0Length =A0 =A0 =A0 =A0 =A0 =A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0SPI =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Locator Lifetime =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator type =A0| =A0 =A0Flags =A0 =A0|P| =A0 =A0 =A0 =A0 Locator roles =
=A0 =A0 |H|E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Locator type:

=A0 =A00 =A0Reserved
=A0 =A01 =A0IPv4 address
=A0 =A02 =A0IPv6 address
=A0 =A03 =A0IPv4 address and UDP port

=46lags:

=A0 =A0P =A0Preferred locator

Locator roles

all zero: Reserved
=A0 =A0H =A0These locator(s) can be used for sending HIP packets to the=20
recipient.
=A0 =A0E =A0These locator(s) can be used for sending ESP packets to the=20
recipient.

---

From: [email-masked] (Pekka Nikander)
Date: Mon Nov 22 23:50:00 2004

>> Below is my initial proposal for the new locator data type, to be 
>> carried by the REA payload.
>
> I find this proposal very good.

I have thought about this a little bit more, and I feel that my locator 
format proposal for premature.
I'll try to send another message on that later today.

> I have some questions, though:
>
> Is the sender of such header supposed to determine the the Locator 
> Lifetime of a specific (Address,Port) tuple when a NAT is present? If 
> so, is this determination supposed to occurs while registering with a 

Well, this is a tricky question.  In general, the question of how to to 
express a locator lifetime is not that easy.  From an architectural 
point of view, we most probably do want to have explicit locator 
lifetime; most locators do have a to-the-peer local lifetime today 
anyway.  It makes sense to deprecate locators when this lifetime 
expires, unless the peer renews the locator binding before that.

The harder question is how to handle the state in the network.  This 
seems to be trickiest with NATs, which tend to have pretty short 
memory, but it applies to other middle boxes, too.

At this point of time, at least I don't have any good answer.  
Basically, my feeling is that I don't understand the situation well 
enough.  Maybe we should have two lifetimes in a locator, one for the 
actual locator, i.e., how long the sending party is likely to "hold" 
that locator, and another for the network state, i.e., how often one 
must send keep-alives to keep the locator functioning.  My guess is 
that the exact semantics and interpretation of the keep-alive field 
would be locator-type specific.

--Pekka