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

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 13 Sep 2004 16:48:11 -0700

continuing inline below...

> -----Original Message-----
> From: Yogesh Prem Swami [mailto:[email-masked]] 
> Sent: Monday, September 13, 2004 12:19 PM
> To: ext Pekka Nikander
> Cc: [email-masked]
> 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

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

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.

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

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 
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: Yogesh Prem Swami <[email-masked]>
Date: Mon, 13 Sep 2004 23:03:54 -0500

Hi Tom,

Please see inline:

> 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 is the basis of your objection to a new protocol

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

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 14 Sep 2004 14:12:09 +0300

> I guess I was responding to Pekka'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.

I didn't say it is *needed*.  I said that it is *architecturally* 
cleaner
as it is arranged today.

There are many practical reasons, including NATs, why it would be more
desirable to use UDP for HIP.  That has been suggested multiple times,
and I have strongly resisted it for the sake of architectural purity.

If people want to define HIP-over-UDP for NAT traversal etc, I don't 
have
anything against that per se, even though I'm afraid that it might 
prove to
be more popular than "pure" HIP.  However, I definitely don't want that 
to
be the default case, mostly because of this architectural purity 
stance, but
also as that would necessitate us to carry yet another unnecessary
header in the packets.

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

Almost, but not quite.

> probably IP as MAY, if people feel strongly about keeping it at IP.

I am willing to consider UDP as OPTIONAL.  I cannot be easily convinced
to move the current arrangement into anything less than SHOULD.
Architecturally, there is too much at stake.  The IETF has a bad history
of sacrificing long term architectural view to short term practical
considerations.

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 14 Sep 2004 14:18:42 +0300

> to demultiplex-- since SPI is a locally unique alias for a HIT.  But
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This is important.  Architecturally, the SPI is an _alias_ for a
HIT pair.

>> 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 referred that over ESP), I wouldn't have complained.

There has been some talk of replacing ESP with something else for
HIP use.  Maybe the time starts to be mature for this?  Define
a simplified (0-bit) format for the current HIP payload, cleary
distinguishable from the default HIP header?  And then reuse the
same protocol number?

For example,

    0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Next Header   |  Payload Len  |     Type      |  VER. | RES.|1|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Controls             |           Checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        SPI (64 bits)                          |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notice the "1" in the end of the first word.

This would firstly have a 64 bit SPI, making collision management
in middle boxes easier.  Secondly, it would have the standard IPv6
extension header, creating less ugly code in kernels.

Of course, it would not be as secure as ESP, as it would always
show what is the type of the next header (if any), but IMHO that
doesn't matter.

-_Pekka