Subject: [Hipsec] Rechartering items?

From: Pekka Nikander <[email-masked]>
Date: Tue, 1 Nov 2005 11:52:45 +0100

Now that we have time for starting HIP WG re-chartering discussion at  
our agenda next week, I'd like to hear people's ideas of what should  
be the next items.  As far as I can see, it may take a while before  
mobility and multi-homing stabilises, so that might need to  
continue.  But other than that?

Some things that I would consider important:

  - making HIP to work with legacy NATs (and firewalls when feasible)

  - invisible HIP, or using HIP with IP addresses as LSIs, similar to  
SHIM6 ULIDs

What else would be both important and mature enough for WG side work?

--Pekka

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

---

From: Miika Komu <[email-masked]>
Date: Tue, 1 Nov 2005 13:57:13 +0200 (EET)

> What else would be both important and mature enough for WG side work?

What do you feel about the native HIP API work?

I think the opportunistic HIP draft would be nice to have on WG side, as
the next version of the draft is going to be even simpler than the
earlier.

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 1 Nov 2005 13:29:00 +0100

> What do you feel about the native HIP API work?

Personally, I don't think that is mature enough, and I am not even  
sure if we want to run it through a working group at all.  But at  
least we need a much more implementation and *use* experience.

> the next version of the draft is going to be even simpler than the

I think it may be mature enough once someone implements it; the  
question (at least for me) is whether people feel it is interesting  
enough.

--Pekka

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 02 Nov 2005 08:08:34 -0800

>  - invisible HIP, or using HIP with IP addresses as LSIs, similar to  

Aren't LSIs and SHIM6 ULIDs quite different with different implications?
The former is 32 bits, which makes it unlikely that it will be a 
globally unique number, and the latter are regular 128-bit IPv6 addresses.

So while both might result in "invisible HIP" it might make sense to 
discuss them separately.

    Erik

---

From: Julien Laganier <[email-masked]>
Date: Wed, 2 Nov 2005 17:29:41 +0100

On Wednesday 02 November 2005 17:08, Erik Nordmark wrote:
> Pekka Nikander wrote:
> >  - invisible HIP, or using HIP with IP addresses as LSIs, similar
> > to SHIM6 ULIDs
>
> Aren't LSIs and SHIM6 ULIDs quite different with different
> implications? The former is 32 bits, which makes it unlikely that
> it will be a globally unique number, and the latter are regular
> 128-bit IPv6 addresses.

My understanding of LSI is that they are identifier meant to be used 
as HIT representation in legacy IP APIs. 

IIRC we discussed 128 bits LSIs a while ago; they would be prefixed by 
some fixed string allocated to HIP (similar to the 1.x.x.x/8 used for 
IPv4 LSIs). This is now part of the KHI concept: Having  
cryptographic identifier usable in legacy IPv6 APIs.

Then I understand 'IP address as LSIs' as 'Use routable IP address in 
legacy APIs', which is, for IPv6, the same as SHIM6 ULID. If I am not 
wrong that is the approach chosen by the HIP implementation from 
Boeing.  

> So while both might result in "invisible HIP" it might make sense
> to discuss them separately.

But yes, I agree that it might make sense to discuss them separately 
because their uniqueness property are very different.

--julien

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 2 Nov 2005 18:19:36 +0100

Erik,

> implications?

That is certainly something that I would like to understand better.
For IPv6, I would be tended to see SHIM6 ULIDs as a subset of what kind
of identifiers you can use in HIP as ULIDs.

> globally unique number, and the latter are regular 128-bit IPv6  

You are right that LSIs were originally meant to be only 32 bits, but  
we've been discussing also 128 bit LSIs.  Should probably invent a  
new name for them, to avoid confusion.

> to discuss them separately.

Based on the above, I'm not that sure.

--Pekka

---

From: Julien Laganier <[email-masked]>
Date: Thu, 3 Nov 2005 16:02:07 +0100

Erik and Pekka,

I thought a bit more...

> it will be a globally unique number, and the latter are regular

Let's say we are using IP addresses as LSIs. IMHO it is implicit that 
these IPs/LSIs are routable, because if they are not, then they would 
be quite similar to "pure LSIs".

Then if these IPs/LSIs are routable, they can be expected to be 
globally unique... I am wrong?

So the situation seems to be the same whether we use IPv4 or IPv6 
addresses as IP/LSIs, the latter being the same than using SHIM6 
ULIDs.

Off course if one considers RFC1918 addresses the situation is 
different.

--julien

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 03 Nov 2005 13:23:40 -0800

> globally unique... I am wrong?

With NATs that isn't actually required - the destination address might 
be routable, but the source address will be replaced when passing 
through the NAT.

But in any case, I've associated the term "LSI" with a number that the 
two peers make up and exchange.
For clarity, if one is using routable IPv* addresses, it would make 
sense to give that a different term.

> addresses as IP/LSIs, the latter being the same than using SHIM6 

Which brings us to what problem we are trying to solve by using ULIDs in 
  HIP, and what the resulting security properties will be.

If the ULPs identify the peer using a ULID, then the strength is limited 
by the 62 bit of hash that can be placed in the ULID, even if you have a 
HIT with a larger hash.
How would the security properties of HIP with ULIDs differ from 
shim6+opportunistic IPsec? I imagine there is a difference in that the 
key used for ESP would be bound to a hash that is in the ULID. Is that 
correct?

    Erik

---

From: Julien Laganier <[email-masked]>
Date: Fri, 4 Nov 2005 15:38:30 +0100

> What else would be both important and mature enough for WG side

What about support for inter-addressing-domain communication, i.e. 
IPv4-to-IPv{4|6} ?

--julien