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

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

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

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.)

So the first issue is demuxing. That is, how do I demux different
connections, if my IP address keeps changing.

The second issue is how do I maintain this binding between the demux
numbers (i.e., SPI in this case) and the present IP address of the host.
This issue  is completely separate from the choice of using an SPI, or a
new IP option or what have you.

HIP base, to me seems like a protocol for manging this demux binding. If
you were to propose a new protocol type that will be carried in every
packet (just as SPI) for the purpose of demuxing (and I would have
preferred that over ESP), I wouldn't have complained. But I strongly
disagree that the management of demuxing numbers should be given a
protocol type and should be mixed.

I would like to listen from other people on what they think.

> 
>>     .... But I can see quite a few disadvantages. The biggest
>>     disadvantage is that if HIP is implemented in Kernel, every time
>>     there is a need for an upgrade, for example due to bugs, broken
>>     (colliding) MACs, broken DH (sub)groups, you will need a kernel
>>     upgrade.
> 
> 
> Actually not.  You can easily implement 99% of HIP on user level.

If you're going to implement in user level, then just use UDP. Isn't that
the reasons why UDP exists?

Also, if you want to support multicast using HIP, you will need yet
another  key exchange--substantially different from HIP key exchange.
Are you  proposing to use another protocol-type for multicast key
exchange.  (Also, in case of multicast, one key exchange might not fit
all use  cases, so you will need a lot of protocol types if you want to
do it at  IP layer. And yes, you can multiplex all of them on the same
protocol  type, but then it will be my turn to cry the complexity wolf.
:-) )

> IMHO, it is useful to push I1 handling to the kernel (or even to
> a separate node, see the hi3 draft), but do the rest of processing
> in user level.  But different implementations are differ.
> 
> The rest of your disadvantages don't apply once you realise this.


To me, architecturally it seems cleaner to keep the SA management (i.e.,
3.5 layer management) separate from the 3.5 layer itself. HIP key
exchange is a 3.5 layer manager, and there is no need to mix it with the
3.5 demuxing layer itself--which you achieve through SPI.


> 
>>     IKE is implemented on UDP for a good reason. HIP draft needs to
>>     justify why those reasons are not valid.
> 
> 
> Again, see the architecture draft, and please indicate if it in your
> opinion is not clear enough.
> 

Well the arch document doesn't say anything about this either. Am I
reading the right draft:
http://www.ietf.org/internet-drafts/draft-moskowitz-hip-arch-06.txt?
Isn't this draft in RFC queue right now?


--Yogesh







--------------enig4803AE4239ECFD7D595D74F9
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)

iQEVAwUBQUXyo3kjMhOId4nzAQJEywf/dnv4kFPAJgTbhoB7MDBurZA6JdQOEFzf
zOSk2M7UG1M0Hvp9aZ7VIueiQnMq2MEgeVjcrOUu0xjpPjBwq9huAa/apdbFDU2u
u1mwxmD6a7Tpx0sE9zRXZ5B5fLkRmqd8BpUuoDvx6gDE7RaGLG5G2Opsg+ookVFf
7otrImlM7Xhgqac4nRb0MrdaH1S3I24QMP7J8Asj+tUE5+JKz/U/qg0FXjyaFblT
CYDp7bg9usNZBrh5iEWdSdkOqOlN2mj+OvT2tg7nkGRKAsHUFW3+yxq7UUqK8/8G
vcRNTVqf8r+Vm0LWuR07o/O06QqP73Fk1rKTwF4nMTkFJSTlJ2JRbg==
=IX6E
-----END PGP SIGNATURE-----

--------------enig4803AE4239ECFD7D595D74F9--