Subject: RE: [mobile-ip] Authentication Data as a BU suboption

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 1 Aug 2001 19:11:04 +0200

I like authentication data as a BU suboption. this 
authentication data protects the BU option and the 
home address option alone. nothing else. draft-14 
gives a cleaner solution for authenticating BU's IMO.

advantages
----------

1. we dont have to get a new next header value for the
destination options header containing the BU

=> That would add zero cost.

2. we dont have to modify the ipsec selectors

=> Again zero (or insignificant) cost

3. we dont have to protect the whole packet

=> Why is that an advantage ?

4. we dont have bother about the traffic flows between
the MN and the CN.

=> We don't have to anyway if we stop piggybacking.

5. we can piggyback BU's. somebody asked a question if 
BU's are sent often. YES, BUs could be sent often to 
refresh the bindings. its not necessary the home agents 
agree to very large lifetimes for BUs. and BUs are sent
to everybody in your binding update list everytime you
move.

6. we dont have to store the security association for
protecting the BU in the ipsec database. lookup is 
expensive. it could be stored in the binding update 
list entries. you already have access to the key.

=> Do you really see a lookup time as a critical issue ?
I'm not sure that it would be, even for real time 
data. Are there any figures on how long it takes ?

7. authentication checksum calculation can be done 
very early (ie when the BU is being formed). in the 
current implementations you pull the packet out from 
the ip6_output function, calculate the checksum and 
put it out again in the ip6_output function. this is 
because you cant calculate the checksum until the 
whole packet has been formed.

=> Sure, but what's the added value in doing it 
earlier ?

One advantage is that you might like to allow for
IKE when strong authentication is needed. Why 
eliminate that option ?

Hesham