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

[[e-mail] (Henderson, Thomas R)]

continuing inline below...

> -----Original Message-----
> From: Yogesh Prem Swami [mailto:[e-mail]]=20
> Sent: Monday, September 13, 2004 12:19 PM
> To: ext Pekka Nikander
> Cc: [e-mail]
> Subject: Protocol type for HIP -- was -- Re: [Hipsec] Moving=20
> the base specforward
>=20
>=20
> 2nd e-mail.
>=20
>=20
> >=20
> >> *  A protocol-type just for a key exchange?
> >=20
> >=20
> > 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.
>=20
>=20
> I strongly disagree with this. Let's backtrack a little bit=20
> here. In the
> past (and present) we have used the socket quadruple to demux=20
> different
> connection. The assumption was that the quad will not change after
> connection setup. With mobility and multi homing, the IP=20
> 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=20
> 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

>=20
> So the first issue is demuxing. That is, how do I demux different
> connections, if my IP address keeps changing.
>=20
> 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=20
> of the host.
> This issue  is completely separate from the choice of using=20
> an SPI, or a
> new IP option or what have you.
>=20
> HIP base, to me seems like a protocol for manging this demux=20
> 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.
>=20
> I would like to listen from other people on what they think.

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.

>=20
> >=20
> >>     .... But I can see quite a few disadvantages. The biggest
> >>     disadvantage is that if HIP is implemented in Kernel,=20
> 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.
> >=20
> >=20
> > Actually not.  You can easily implement 99% of HIP on user level.
>=20
> If you're going to implement in user level, then just use=20
> UDP. Isn't that
> the reasons why UDP exists?

See above comment-- UDP might be preferable for transporting the
handshake.  But what is the basis of your objection to using a new
protocol number and running it on top of IP?

I do not have a strong opinion as to whether HIP exchange should
run over IP or UDP-- I have been thinking that it would be useful
to define both modes and see which one is more useful in practice.

Tom=20