Subject: Re: [arch-d] Benefits of identity/location separation?

From: Brian E Carpenter <[email-masked]>
Date: Tue, 01 May 2007 10:57:38 +0200

On 2007-05-01 01:31, Andrew McGregor wrote:
> 
> On 01/05/2007, at 2:25 AM, Dan McDonald wrote:
> 
>> On Mon, Apr 30, 2007 at 07:22:03AM -0700, Merike Kaeo wrote:
>>> IKEv2 and/or Mobike should be able to handle an ID/locator split
>>> [although I want to check the details to make sure that is absolutely
>>> the case] but can IPsec AH handle the ID/locator split?
>>
>> Ahhh, now THAT's an interesting question.
>>
>>> While there are camps that believe AH is deprecated, and of course you
>>> cannot use it with IPv4 NATs, there was a long discussion in IPv6 
>>> mailing
>>> lists (non-IETF) regarding requiring AH for specific use cases.  
>>> There was
>>> some talk of requiring a 'new AH' to handle a future ID/locator 
>>> split....
>>
>> I'm not sure if a "new AH" would be needed, but rather a "new AH rules 
>> for
>> new IP protocol".
>>
>> Assuming the ID/locator split is technically a new IP header (v9?), 
>> all one
>> would need is a processing rule for AH that says "don't include the 
>> locator
>> in the AH computation".  If the split is a change to IPv6, then I suppose
>> there could be an SA attribute (negotiated by IKE, or say an 
>> SADB_X_SAFLAG_
>> value for PF_KEY) that says "don't include locator part of IPv6 header".
>>
>> It shouldn't be that hard to make AH work in a post-split world.  
>> Protocol
>> designers in the audience - please take note that AH still matters to 
>> some
>> people.
>>
>> Dan
> 
> The same trick as is used by HIP's BEET mode for ESP would work; require 
> that the locators in the header be rewritten to identifiers (or hashes 
> thereof) before doing crypto or checksums.
> 
> Or, use ESP with null encryption and authentication enabled (yes, I know 
> this is regarded as a bad idea... but it does work).

I'm no expert, but RFC 4301 says:

>> 3.2.  How IPsec Works
>> 
>>    IPsec uses two protocols to provide traffic security services --
>>    Authentication Header (AH) and Encapsulating Security Payload (ESP).
>>    Both protocols are described in detail in their respective RFCs
>>    [Ken05b, Ken05a].  IPsec implementations MUST support ESP and MAY
>>    support AH. (Support for AH has been downgraded to MAY because
>>    experience has shown that there are very few contexts in which ESP
>>    cannot provide the requisite security services.  Note that ESP can be
>>    used to provide only integrity, without confidentiality, making it
>>    comparable to AH in most contexts.)

However, I feel we are a little ahead of ourselves here. If we end up
with an identifier in every packet, plus potentially variable
locators, I'm sure that the fine details of which fields are covered
by both AH and ESP will need to be adapted. I don't see how that can
be defined in advance. There will surely be code changes in IPSEC.

     Brian

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: "Alvaro Vives Martinez" <[email-masked]>
Date: Wed, 9 May 2007 18:28:03 +0200

Hello Brian,

> 
> > One thing you should find is that based on what Saltzer writes, the
> > minimum necessary scope of a point of attachment  address is that it be
> > unambiguous only between nearest neighbors.
> 
> I can readily believe that as a mathematical theorem. But the question
> is whether it's an operationally useful observation.
> >
> > The scope of node addresses is greater, usually "global,"
> 
> I don't think that's true, given the number of NATs deployed.
> I think usually "site-local" is the usual scope today.
> 
> I think the interesting question, where Noel and I likely disagree,
> is whether having identifier == locator within site-local scope
> is a Good Thing or a Bad Thing.

IMHO this is a bad thing. For example in the case of a mobile node that have
already established a connection using the identifier (== locator) on its
side. When moves to another network locator can change, no problem, but
having an ID equal to another network locator doesn't seem a good thing.

Best regards,
Alvaro

> 
>      Brian
> 
> > but strictly
> > speaking doesn't have to be.
> >
> > Take care,
> > John
> >
> >>
> >>
> >>     > Then I guess if you think "stack name" is node address, then I
> >> think
> >>     > it has the wrong properties! ;-) And we are in for scaling
> >> problems.
> >>
> >> And I still have no clue whatsoever that these scaling problems might
> be.
> >> Please expand your allusion.
> >>
> >>        Noel
> >>

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.