Subject: [Hipsec] SPIs and IPv6 address indexing

From: Robert Moskowitz <[email-masked]>
Date: Wed, 18 Nov 2009 16:03:09 -0500

Consider a VERY constrained PHY/MAC.  Where signal fade makes it hard to 
get large datagrams through and you want to do everything you can to 
shorten the datagrams.  These exist.  I just sat through two 
presentations in IEEE 802.15.4g with real measurements and separate 
modeling validation (actually two different groups only becoming aware 
of the other when they published their data) on significant channel fade 
problems....

So here we are with ESP and its SPI.  Per RFC 5202, the SPI is a mapping 
of the Destination HIP SA.  This tells the receiver what are both the 
HIT and IPv6 pairs it is to use in processing the ESP datagram.

So for traffic strickly on the constrained local link, it would seem 
that the IPv6 addresses are not 'needed' on the link, as there is a 
mapping of SPI to IPv6 addresses that map to MAC addresses.  And there 
are always the MAC addresses in the datagram anyway.

This ASSuMEs that two different Initiators did not use the same SPI with 
a given Responder (or two Responders to Initiator).  Given that SPIs are 
ONLY 32 bits, collisions probably really happen?  But again you do have 
the MAC addresses to help keep this all straight.  So maybe this is not 
such a concern.

Now what about traffic that goes through a Midbox off the constrained 
local net.  The Midbox could have the SPI to Addr mapping from the HIP 
exchange, but then the Midbox has to be aware of all mobility Updates?  
Perhaps a bit complex.  But there is a real incentive here to shave off 
considerable overhead that can be the make-it/break-it point for the 
link....

I am sure that there is some good discussions of this somewhere....

Why did I ever get involved again with MACs?  It is sooooo much easier 
to just pretend they are all the same.

---

From: Miika Komu <[email-masked]>
Date: Thu, 19 Nov 2009 00:11:30 +0200

Robert Moskowitz wrote:

Hi,

> to just pretend they are all the same.

I have to remind about the SPINAT work from Ylitalo et al. I think the 
UDP is a more practical way to support HIP and ESP to make better 
guarantees about middlebox traversal in general. Further, the UDP port 
numbers can be used to replace the MAC address bindings in your approach?

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 18 Nov 2009 17:33:03 -0500

Miika Komu wrote:
> Robert Moskowitz wrote:
>
> Hi,
>
>> Consider a VERY constrained PHY/MAC.  Where signal fade makes it hard 
>> to get large datagrams through and you want to do everything you can 
>> to shorten the datagrams.  These exist.  I just sat through two 
>> modeling validation (actually two different groups only becoming 
>> aware of the other when they published their data) on significant 
>> channel fade problems....
>>
>> So here we are with ESP and its SPI.  Per RFC 5202, the SPI is a 
>> mapping of the Destination HIP SA.  This tells the receiver what are 
>> both the HIT and IPv6 pairs it is to use in processing the ESP datagram.
>>
>> mapping of SPI to IPv6 addresses that map to MAC addresses.  And 
>> there are always the MAC addresses in the datagram anyway.
>>
>> This ASSuMEs that two different Initiators did not use the same SPI 
>> with a given Responder (or two Responders to Initiator).  Given that 
>> SPIs are ONLY 32 bits, collisions probably really happen?  But again 
>> you do have the MAC addresses to help keep this all straight.  So 
>> maybe this is not such a concern.
>>
>> local net.  The Midbox could have the SPI to Addr mapping from the 
>> HIP exchange, but then the Midbox has to be aware of all mobility 
>> Updates?  Perhaps a bit complex.  But there is a real incentive here 
>> to shave off considerable overhead that can be the make-it/break-it 
>> point for the link....
>>
>> Why did I ever get involved again with MACs?  It is sooooo much 
>> easier to just pretend they are all the same.
>

Well this is strictly an IPv6 world, so middle boxes are not NATing 
unless you buy into NAT66.  There is no reason for even NAT66 in my view 
of this world, all the devices have IPv6 addresses with the prefixes 
handed out through some mechanism.  The issue is packet compression, so 
running ESP over UDP becomes an upstream battle  :)

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 19 Nov 2009 10:34:26 -0500

gabriel montenegro wrote:
> You might want to look at what we did in 6lowpan for header compression of IPv6 over 802.15.4:
>
> http://tools.ietf.org/html/rfc4944#section-10
>   

I have.

> For example, in some situations one may completely elide the IPv6 addresses if they are derived in a known way from the MAC EUI-64 addresses.
>   

Yes.
> Further header compression work is going on in:
> http://tools.ietf.org/wg/6lowpan/draft-ietf-6lowpan-hc/
>   

I am following this.

> Gabriel
>
>
> ----- Original Message ----
>   
>> From: Robert Moskowitz <[email-masked]>
>> To: [email-masked]
>> Cc: [email-masked]
>> Sent: Wed, November 18, 2009 5:33:03 PM
>> Subject: Re: [Hipsec] SPIs and IPv6 address indexing
>>
>> Miika Komu wrote:
>>     
>>> Robert Moskowitz wrote:
>>>
>>> Hi,
>>>
>>>       
>>>> Consider a VERY constrained PHY/MAC.  Where signal fade makes it hard to get 
>>>>         
>> large datagrams through and you want to do everything you can to shorten the 
>> datagrams.  These exist.  I just sat through two presentations in IEEE 802.15.4g 
>> with real measurements and separate modeling validation (actually two different 
>> groups only becoming aware of the other when they published their data) on 
>> significant channel fade problems....
>>     
>>>> So here we are with ESP and its SPI.  Per RFC 5202, the SPI is a mapping of 
>>>>         
>> the Destination HIP SA.  This tells the receiver what are both the HIT and IPv6 
>> pairs it is to use in processing the ESP datagram.
>>     
>>>> So for traffic strickly on the constrained local link, it would seem that the 
>>>>         
>> IPv6 addresses are not 'needed' on the link, as there is a mapping of SPI to 
>> IPv6 addresses that map to MAC addresses.  And there are always the MAC 
>> addresses in the datagram anyway.
>>     
>>>> This ASSuMEs that two different Initiators did not use the same SPI with a 
>>>>         
>> given Responder (or two Responders to Initiator).  Given that SPIs are ONLY 32 
>> bits, collisions probably really happen?  But again you do have the MAC 
>> addresses to help keep this all straight.  So maybe this is not such a concern.
>>     
>>>> Now what about traffic that goes through a Midbox off the constrained local 
>>>>         
>> net.  The Midbox could have the SPI to Addr mapping from the HIP exchange, but 
>> then the Midbox has to be aware of all mobility Updates?  Perhaps a bit 
>> complex.  But there is a real incentive here to shave off considerable overhead 
>> that can be the make-it/break-it point for the link....
>>     
>>>> Why did I ever get involved again with MACs?  It is sooooo much easier to 
>>>>         
>> just pretend they are all the same.
>>     
>>> I have to remind about the SPINAT work from Ylitalo et al. I think the UDP is 
>>>       
>> a more practical way to support HIP and ESP to make better guarantees about 
>> middlebox traversal in general. Further, the UDP port numbers can be used to 
>> replace the MAC address bindings in your approach? 
>>
>> Well this is strictly an IPv6 world, so middle boxes are not NATing unless you 
>> buy into NAT66.  There is no reason for even NAT66 in my view of this world, all 
>> the devices have IPv6 addresses with the prefixes handed out through some 
>> mechanism.  The issue is packet compression, so running ESP over UDP becomes an 
>> upstream battle  :)
>>
>>
>> _______________________________________________
>> Hipsec mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/hipsec
>>     
>
>
>