Protocol type for HIP -- was -- Re: [Hipsec] Moving the base specforward

[[e-mail] (Yogesh Prem Swami)]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig0BB310B09BA5983BCAE4B2A8
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi Tom,

Please see inline:

ext Henderson, Thomas R wrote:
> continuing inline below...
> 
> 
>>-----Original Message-----
>>From: Yogesh Prem Swami [mailto:[e-mail]] 
>>Sent: Monday, September 13, 2004 12:19 PM
>>To: ext Pekka Nikander
>>Cc: [e-mail]
>>Subject: Protocol type for HIP -- was -- Re: [Hipsec] Moving 
>>the base specforward
>>
>>
>>2nd e-mail.
>>
>>
>>
>>>>*  A protocol-type just for a key exchange?
>>>
>>>
>>>Well, architecturally all traffic flows over the new protocol type,
>>>as there is a new layer between IP and upper layers.  Using ESP
>>>is just a convenient shorthand.
>>
>>
>>I strongly disagree with this. Let's backtrack a little bit 
>>here. In the
>>past (and present) we have used the socket quadruple to demux 
>>different
>>connection. The assumption was that the quad will not change after
>>connection setup. With mobility and multi homing, the IP 
>>address change,
>>so we need a new mechanism to demux different connections.  You are
>>achieving this through SPIs. (Note also, that the HIT flipping as
>>defined  in the draft is also not essential. Keeping it there might
>>still be a  good idea, if you don't want to change your TCP code, but
>>it's not  needed, in principle. The connection is already 
>>demuxed by the
>>time of IPsec processing, beyond which you only need to look at port
>>numbers.)
> 
> 
> I think that what you say is correct-- that SPI + port is sufficient
> to demultiplex-- since SPI is a locally unique alias for a HIT.  But
> there still needs to be something to put into the transport pseudoheader,
> and the HIT seems cleanest to use, especially in mobile or multihomed
> world.
> 
> There has also been some interest expressed in multi6 community of
> not requiring IPsec for all flows, in which case SPI might not be
> there-- see section 3.1 of:
> http://www.ietf.org/internet-drafts/draft-nikander-multi6-hip-01.txt
> 

I too would've preferred a new "only SPI; nothing more" extension 
header, with the possibly of managing SPI to IP address binding/update 
secure.

> 
> I don't think that I understand fully your objection.  If you are
> arguing that HIP exchange should run over UDP instead of raw IP,
> there may be value in that in terms of traversing middleboxes-- but
> I don't think that is the basis of your objection to a new protocol
> type value.


I guess I was responding to Peeka's comment (at the start of this 
e-mail) that HIP key exchange is needed at IP layer because all traffic 
uses this new protocol. In reality, this is not true, because all 
traffic goes over ESP (which in itself is sufficient to demultiplex 
connections, HIP or not). So HIP key exchange in reality is a SPI (SA in 
case of ESP) management protocol.

So I was suggestion to move HIP key exchange to UDP (as SHOULD) and 
probably IP as MAY, if people feel strongly about keeping it at IP.

Thanks
Yogesh

--------------enig0BB310B09BA5983BCAE4B2A8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iQEVAwUBQUZtsXkjMhOId4nzAQITiwf+L7effkAjImSYHVlCbn47xd2h7jDyW1ev
+HASjUJ5j4JZGlFkwGY0Avl5fOB/YhmOJKbLKGaTfhC3XBsqApgZDctRM6U/mp++
hcM8k5ZUhhFxL6Ui+eEbZTJ9tdTWjk7R0HEH6mrCSJF2gqhsNaxJw3I1g+bMkqtj
NxIAOU2NhBa2nH0LX/gFl7qKw5TaKNmZ0rkHpyrvKYBrmXYrooXz3ZSrnwR3U3T0
ou0m39GzBEr/YO4QwOzBgy3LqMAq4aHPXmdLdVIBKjrETfr8o5QIJkReBrkVWWcb
2t5nMhd3RsZLVVhFvEfr5QXZOQ+5LbHT/4E30Iv1tYr9C5lhBb59aw==
=uMVh
-----END PGP SIGNATURE-----

--------------enig0BB310B09BA5983BCAE4B2A8--