Subject: [Hipsec-rg] FW: I-D ACTION:draft-ahrenholz-hiprg-dht-00.txt
From: [email-masked] (Henderson, Thomas R)
Date: Fri Aug 26 17:45:01 2005

FYI, this draft has made it to the repository

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]=20
Sent: Friday, August 26, 2005 12:50 PM
To: [email-masked]
Subject: I-D ACTION:draft-ahrenholz-hiprg-dht-00.txt=20

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: HIP DHT Interface
	Author(s)	: J. Ahrenholz
	Filename	: draft-ahrenholz-hiprg-dht-00.txt
	Pages		: 16
	Date		: 2005-8-26
=09
   This document specifies a common interface for using HIP with a DHT
   to provide lookup services.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ahrenholz-hiprg-dht-00.txt

From: [email-masked] (Ahrenholz, Jeffrey M)
Date: Thu Aug 25 13:32:01 2005
Subject: [Hipsec-rg] RE: [Hipsec] Boeing test server and implementation
Message-ID: <[email-masked]>

Teemu,
I wouldn't quite say "strongly moving towards LSI"; IPv4 apps need a
32-bit handle to the Host Identity and LSIs are all that we have. For
IPv6, the LSI can be the HIT, although it doesn't have to be.  More work
on that aspect is needed.

- in Windows, we don't yet support IPv6, and therefore HITs, for two
reasons. (1) Windows will not allow us to bind an IPv6 ESP socket, and
(2) we have not yet implemented IPv6/HITs over IPv4 (Cygwin IPv6 support
is lacking in some areas.)

- for Linux, we may adopt the BEET kernel patch in the future to support
LSI- and HIT-based communication. (Especially if it is part of the
standard kernel.) However, we are not happy with the current design of
the BEET patch being based on tunnel mode, with the SADB entries bound
to the outer IP addresses instead of the inner HITs (a point that I
tried to raise in the HIP RG meeting).

-Jeff

> -----Original Message-----
> From: Teemu Koponen [mailto:[email-masked]]=20
> Sent: Thursday, August 25, 2005 1:23 AM
> To: Ahrenholz, Jeffrey M
> Cc: <[email-masked]>
> Subject: Re: [Hipsec] Boeing test server and implementation
>=20
>=20
> On Aug 24, 2005, at 12:52, Ahrenholz, Jeffrey M wrote:
>=20
> Jeff,
>=20
> > We've released a new version of our HIP software for=20
> Linux/Windows XP:
> > http://hipserver.mct.phantomworks.org/
>=20
> I see you are strongly moving towards LSI based application=20
> view. May I=20
> inquire what is your current plan to expose HITs (as IPv6 addresses)=20
> for applications?
>=20
> Teemu
>=20
> --
>=20
>=20

From: [email-masked] (Henderson, Thomas R)
Date: Thu Aug 25 10:52:00 2005
Subject: [Hipsec-rg] Re: [Hipsec] Boeing test server and implementation
Message-ID: <[email-masked]>

=20

> -----Original Message-----
> From: Lars Eggert [mailto:[email-masked]]=20
> Sent: Thursday, August 25, 2005 1:04 AM
> To: Ahrenholz, Jeffrey M
> Cc: [email-masked]; [email-masked]
> Subject: [Hipsec-rg] Re: [Hipsec] Boeing test server and=20
> implementation
>=20
> Hi,
>=20
> On Aug 24, 2005, at 21:52, Ahrenholz, Jeffrey M wrote:
> > We've released a new version of our HIP software for=20
> Linux/Windows XP:
> > http://hipserver.mct.phantomworks.org/
>=20
> great news, thanks!
>=20
> But this leaves me a bit confused - I thought the Boeing HIP=20
> was available as OpenHIP? Guess I'm wrong; what is the=20
> relation between OpenHIP and Boeing HIP then?
>=20

Sorry for the confusion; we plan to patch the OpenHIP code shortly, and
host future development there.  This is just an early release.

I will announce to the list when that occurs.

Tom

From: [email-masked] (Teemu Koponen)
Date: Thu Aug 25 04:17:01 2005
Subject: [Hipsec-rg] Re: [Hipsec] Boeing test server and implementation
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Aug 24, 2005, at 12:52, Ahrenholz, Jeffrey M wrote:

Jeff,

> We've released a new version of our HIP software for Linux/Windows XP:
> http://hipserver.mct.phantomworks.org/

I see you are strongly moving towards LSI based application view. May I 
inquire what is your current plan to expose HITs (as IPv6 addresses) 
for applications?

Teemu

--

From: [email-masked] (Lars Eggert)
Date: Thu Aug 25 03:59:01 2005
Subject: [Hipsec-rg] Re: [Hipsec] Boeing test server and implementation
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

--Apple-Mail-32-620956709
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Hi,

On Aug 24, 2005, at 21:52, Ahrenholz, Jeffrey M wrote:
> We've released a new version of our HIP software for Linux/Windows XP:
> http://hipserver.mct.phantomworks.org/

great news, thanks!

But this leaves me a bit confused - I thought the Boeing HIP was  
available as OpenHIP? Guess I'm wrong; what is the relation between  
OpenHIP and Boeing HIP then?

Thanks,
Lars
--
Lars Eggert                                     NEC Network Laboratories

--Apple-Mail-32-620956709
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

--Apple-Mail-32-620956709--

From: [email-masked] (Ahrenholz, Jeffrey M)
Date: Wed Aug 24 15:47:01 2005
Subject: [Hipsec-rg] Boeing test server and implementation
Message-ID: <[email-masked]>

All,
We've released a new version of our HIP software for Linux/Windows XP:
http://hipserver.mct.phantomworks.org/

Supporting base-03, esp-00, and mm-02 drafts, and interops from the last
IETF meeting. New in this version is user-mode HIP (UMH) that runs
entirely in Linux userspace so you don't need to patch your Linux
kernel. Also, our HIP test server is back and should now remain online
permanently.

-Jeff

From: [email-masked] (Michael Richardson)
Date: Wed Aug 10 12:27:01 2005
Subject: [Hipsec-rg] Opportunistic HIP and TCP options
In-Reply-To: Message from Wesley Eddy <[email-masked]> of "Wed, 10 Aug 2005 10:32:10 EDT." <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>  <[email-masked]>
Message-ID: <[email-masked]>

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Wesley" == Wesley Eddy <[email-masked]> writes:
    >> >>>>> "Pekka" == Pekka Nikander <[email-masked]>
    >> writes: >> Alas, many firewalls drop packets with TCP options.
    >> 
    Pekka> Do you have any numbers of how usual that is?
    >> Ask the ECN folks.  (There isn't just the ECN bit in the TOS, but
    >> also the TCP option to use it

    Wesley> Actually it's a TCP *flag*, NOT an option.  The paper that
    Wesley> Lars has cited has some numbers on deployed ECN

  yeah, that's true as well. My bad --- tcpdump shows some options
(e.g. window scaling) in such a fashion that one forgets that the ECN
flag is not an option :-)

    Wesley> capabilities, if you're interested.  It also shows pretty
    Wesley> definitively that we're actually quite safe to use new TCP
    Wesley> options without fear of them causing packet drops.  0.2% of
    Wesley> connections break with an "Option Y" tacked onto the SYN,
    Wesley> and only 3% break when such an option is suddenly used
    Wesley> mid-connection.

  Okay, so I didn't understand that from my reading, but I didn't read
it very well.

- -- 
] Michael Richardson          Xelerance Corporation, Ottawa, ON |  firewalls  [
] mcr @ xelerance.com           Now doing IPsec training, see   |net architect[
] http://www.sandelman.ca/mcr/    www.xelerance.com/training/   |device driver[
]                    I'm a dad: http://www.sandelman.ca/lrmr/                 [

From: [email-masked] (Michael Richardson)
Date: Wed Aug 10 12:25:00 2005
Subject: [Hipsec-rg] Opportunistic HIP and TCP options
In-Reply-To: Message from Lars Eggert <[email-masked]> of "Wed, 10 Aug 2005 16:17:20 +0200." <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>  <[email-masked]>
Message-ID: <[email-masked]>

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Lars" == Lars Eggert <[email-masked]> writes:
    Lars> On Aug 10, 2005, at 14:55, Michael Richardson wrote:
    >> Alas, many firewalls drop packets with TCP options.
    >> 
    >> For this reason, I suggest that the HIT be in the TCP SYN/ACK,
    >> and the subsequent ACK. I.e:

    Lars> This has recently been discussed on TCPM for a new TCP option
    Lars> we're proposing. It turns out that this is not a big problem
    Lars> anymore, see http://www.icir.org/floyd/papers/tbit-Aug2004.pdf

  That's good news for ECN.

  But, ECN had a two-factor issues:
       a) ECN bit
       b) TCP option

  It's possible that the rather plentiful boxes that were ECN intolerant
were fixed to be ECN tolerant. That doesn't mean that they are
unknown-TCP-option tolerant, does it?

  I didn't follow reference [23] yet.

- -- 
] Michael Richardson          Xelerance Corporation, Ottawa, ON |  firewalls  [
] mcr @ xelerance.com           Now doing IPsec training, see   |net architect[
] http://www.sandelman.ca/mcr/    www.xelerance.com/training/   |device driver[
]                    I'm a dad: http://www.sandelman.ca/lrmr/                 [

From: [email-masked] (RJ Atkinson)
Date: Wed Aug 10 12:22:01 2005
Subject: [Hipsec-rg] IP options
Message-ID: <[email-masked]>

> Originally Pekka Nikkander said:
>> AFAIK (and I may well be wrong here), IP options require the packet
>> to take the slow path in most current routers, causing problems.
>> Furthermore, many firewalls and even some routers tend to drop
>> packets with IP options.

Later, Tim Shepard said:
> Make that IPv4 options.  And I'm not so sure that it is still true.
> Routers these days have to be robust against DoS attacks, and you
> don't want your router to be vulnerable to having its "slow path"
> clogged up by a bunch of IPv4 packets with options.

As far as I know, no modern IP router drops packets merely
because the packet contains an option.  So I agree with Tim
on that.

Many deployed firewalls either strip IP options or drop packets
containing IP options.  I doubt that will change anytime soon.
Of course, many deployed firewalls only support IPv4 and will
drop packets that are tunnelled, including "IPv6 in IPv4" packets.

Juniper and cisco process both IPv4 options and IPv6 options on
the software slow-path (i.e. not inside an ASIC) even today,
to the best of my knowledge.  As far as I know, no modern IP
router drops packets just because the packet contains an option.

(There is at least one IPv6 implementation that handles packets
with options inside the ASIC, with no negative performance impact. :-)

> But in any case, if IPv6, then an IPv6-style option (where the HIP
> header containing an I1 comes after the IPv6 header but before the
> normal TCP header) seems like the right thing to do.

It might be that an IPv6 End-to-End Option is best suited.

Yours,

Ran
[email-masked]

PS:    "IP" by itself means "IPv4 and/or IPv6" in the text above. :-)

From: [email-masked] (Wesley Eddy)
Date: Wed Aug 10 10:30:02 2005
Subject: [Hipsec-rg] Opportunistic HIP and TCP options
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

--KuLpqunXa7jZSBt+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 10, 2005 at 10:18:52AM -0400, Michael Richardson wrote:
> >>>>> "Pekka" =3D=3D Pekka Nikander <[email-masked]> write=
s:
>     >> Alas, many firewalls drop packets with TCP options.
>=20
>     Pekka> Do you have any numbers of how usual that is?
>=20
>   Ask the ECN folks.
>   (There isn't just the ECN bit in the TOS, but also the TCP option to us=
e it

Actually it's a TCP *flag*, NOT an option.  The paper that Lars has
cited has some numbers on deployed ECN capabilities, if you're
interested.  It also shows pretty definitively that we're actually quite
safe to use new TCP options without fear of them causing packet drops.
0.2% of connections break with an "Option Y" tacked onto the SYN, and
only 3% break when such an option is suddenly used mid-connection.

-Wes

--=20
Wesley M. Eddy
Verizon FNS / NASA GRC
http://roland.grc.nasa.gov/~weddy

--KuLpqunXa7jZSBt+
Content-Type: application/pgp-signature
Content-Disposition: inline

--KuLpqunXa7jZSBt+--

From: [email-masked] (Tim Shepard)
Date: Wed Aug 10 10:26:01 2005
Subject: [Hipsec-rg] Opportunistic HIP and TCP options
In-Reply-To: Your message of Wed, 10 Aug 2005 14:13:00 +0200. <[email-masked]>
Message-ID: <[email-masked]>

> AFAIK (and I may well be wrong here), IP options require the packet  
> to take the slow path in most current routers, causing problems.   
> Furthermore, many firewalls and even some routers tend to drop  
> packets with IP options.

Make that IPv4 options.  And I'm not so sure that it is still true.
Routers these days have to be robust against DoS attacks, and you
don't want your router to be vulnerable to having its "slow path"
clogged up by a bunch of IPv4 packets with options.

But in any case, if IPv6, then an IPv6-style option (where the HIP
header containing an I1 comes after the IPv6 header but before the
normal TCP header) seems like the right thing to do.  

But thinking about how to defend against downgrade attacks will be
tricky, and you might not want to reveal the TCP port numbers in the
clear if you can avoid it, so an additional round trip's delay in
getting things started might be warrented.

(Sorry I missed the HIPRG meeting, but I had to leave for the airport
 Friday morning.)

			-Tim Shepard
			 [email-masked]

From: [email-masked] (Michael Richardson)
Date: Wed Aug 10 10:15:00 2005
Subject: [Hipsec-rg] Opportunistic HIP and TCP options
In-Reply-To: Message from Pekka Nikander <[email-masked]> of "Wed, 10 Aug 2005 16:09:47 +0200." <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>  <[email-masked]>
Message-ID: <[email-masked]>

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Pekka" == Pekka Nikander <[email-masked]> writes:
    >> Alas, many firewalls drop packets with TCP options.

    Pekka> Do you have any numbers of how usual that is?

  Ask the ECN folks.
  (There isn't just the ECN bit in the TOS, but also the TCP option to use it)
  
- -- 
] Michael Richardson          Xelerance Corporation, Ottawa, ON |  firewalls  [
] mcr @ xelerance.com           Now doing IPsec training, see   |net architect[
] http://www.sandelman.ca/mcr/    www.xelerance.com/training/   |device driver[
]                    I'm a dad: http://www.sandelman.ca/lrmr/                 [

From: [email-masked] (Lars Eggert)
Date: Wed Aug 10 10:13:03 2005
Subject: [Hipsec-rg] Opportunistic HIP and TCP options
In-Reply-To: <[email-masked]>
References: <[email-masked]>  <[email-masked]>  <[email-masked]>
Message-ID: <[email-masked]>

--Apple-Mail-59--652646770
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

On Aug 10, 2005, at 14:55, Michael Richardson wrote:
>   Alas, many firewalls drop packets with TCP options.
>
>   For this reason, I suggest that the HIT be in the TCP SYN/ACK,  
> and the
> subsequent ACK. I.e:

This has recently been discussed on TCPM for a new TCP option we're  
proposing. It turns out that this is not a big problem anymore, see  
http://www.icir.org/floyd/papers/tbit-Aug2004.pdf

Lars
--
Lars Eggert                                     NEC Network Laboratories

--Apple-Mail-59--652646770
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

--Apple-Mail-59--652646770--

From: [email-masked] (Lars Eggert)
Date: Wed Aug 10 10:13:01 2005
Subject: [Hipsec-rg] Opportunistic HIP and TCP options
In-Reply-To: <[email-masked]>
References: <[email-masked]>  <[email-masked]>  <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

--Apple-Mail-58--652662517
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

On Aug 10, 2005, at 16:09, Pekka Nikander wrote:
>>   Alas, many firewalls drop packets with TCP options.
>
> Do you have any numbers of how usual that is?

Same paper that I pointed you at already - about 0.2%.
http://www.icir.org/floyd/papers/tbit-Aug2004.pdf

Lars
--
Lars Eggert                                     NEC Network Laboratories

--Apple-Mail-58--652662517
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

--Apple-Mail-58--652662517--

From: [email-masked] (Pekka Nikander)
Date: Wed Aug 10 10:06:01 2005
Subject: [Hipsec-rg] Opportunistic HIP and TCP options
In-Reply-To: <[email-masked]>
References: <[email-masked]>  <[email-masked]>  <[email-masked]>
Message-ID: <[email-masked]>

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-4--653100238
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

>   Alas, many firewalls drop packets with TCP options.

Do you have any numbers of how usual that is?

--Pekka

--Apple-Mail-4--653100238
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-4--653100238--

From: [email-masked] (Michael Richardson)
Date: Wed Aug 10 09:45:02 2005
Subject: [Hipsec-rg] Opportunistic HIP and TCP options
In-Reply-To: Message from Pekka Nikander <[email-masked]> of "Wed, 10 Aug 2005 14:13:00 +0200." <[email-masked]>
References: <[email-masked]>  <[email-masked]>
Message-ID: <[email-masked]>

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Pekka" == Pekka Nikander <[email-masked]> writes:
    Pekka> AFAIK (and I may well be wrong here), IP options require the
    Pekka> packet to take the slow path in most current routers, causing
    Pekka> problems.  Furthermore, many firewalls and even some routers
    Pekka> tend to drop packets with IP options.

  Alas, many firewalls drop packets with TCP options.

  For this reason, I suggest that the HIT be in the TCP SYN/ACK, and the
subsequent ACK. I.e:

		initiator	--TCP SYN port 80---> responder
		           <--TCP SYN/ACK + HIT------
                           ---TCP ACK + HIT--------->
			   ********* PRIVACY ********

  The reason for this is that a responder that is behind a firewall that
is TCP option intolerant, it can, well, turn off HIP.

  If we do it the other way, then all million customers of
stupid-bank<tm> have to figure out that the bank's firewall is TCP
option intolerant.

- -- 
] Michael Richardson          Xelerance Corporation, Ottawa, ON |  firewalls  [
] mcr @ xelerance.com           Now doing IPsec training, see   |net architect[
] http://www.sandelman.ca/mcr/    www.xelerance.com/training/   |device driver[
]                    I'm a dad: http://www.sandelman.ca/lrmr/                 [

From: [email-masked] (Pekka Nikander)
Date: Wed Aug 10 09:35:02 2005
Subject: [Hipsec-rg] Opportunistic HIP and TCP options
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Putting lower-layer information into TCP options doesn't seem very  
> clean, hence my comment that the TCP folks won't like it. You'd  
> also need to modify all transport protocols similarly.

Well, some people take the stance that HIP lies between IP and TCP ;-)
So it may not be that wrong :-)

Yes, you need to modify other transport protocols in a similar way.
In IPv6 we can imaging a Destination Option, but for IPv4 I couldn't  
find out any cleaner solution but using TCP options.

>> Hence, to me it looks like that writing a spec that defines how  
>> you MAY send your HIT in a TCP option, basically causing the  
>> equivalent of sending an opportunistic I1, should be relatively easy.
>>
>
> As mentioned above, I don't think a transport option is the right  
> place to carry network-layer information around. Given that new IP  
> options are pretty much useless these days, it may be the only  
> possible way to achieve the desired behavior, but it doesn't strike  
> me as particularly clean.

I agree it is wacky, but

   - this is mainly a performance optimisation, and

   - The whole Opportunistic HIP concept is quite hacky and should  
not be needed...

--Pekka

From: [email-masked] (Lars Eggert)
Date: Wed Aug 10 09:16:01 2005
Subject: [Hipsec-rg] Opportunistic HIP and TCP options
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

--Apple-Mail-56--656122932
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Hi,

On Aug 10, 2005, at 14:13, Pekka Nikander wrote:
> AFAIK (and I may well be wrong here), IP options require the packet  
> to take the slow path in most current routers, causing problems.   
> Furthermore, many firewalls and even some routers tend to drop  
> packets with IP options.

yup. However, the slow path is still faster than what I understand  
the current method for opportunistic HIP to be, i.e, sending an I1,  
waiting, and then falling back to IP. Or do you propose to send the  
I1 in parallel to the first data packets and leaving them unprotected  
until the base exchange completes? (I haven't been able to find a  
concise description of opportunistic HIP.)

Since the meeting, I've looked around some more, and the biggest  
drawback of the IP option is that recent measurements (http:// 
www.icir.org/floyd/papers/tbit-Aug2004.pdf) find that 70% of SYN  
packets with unknown IP options are dropped by routers. That pretty  
much kills this proposal.

> I don't understand the comments about transport people not liking  
> TCP options; there are even relatively new ones like RFC2385 and  
> 2883.  But maybe I am missing something here.

Putting lower-layer information into TCP options doesn't seem very  
clean, hence my comment that the TCP folks won't like it. You'd also  
need to modify all transport protocols similarly.

> Another thing that I don't understand at all is the remark about  
> TCP options being only 14 bits.

I think this was misquoted in the minutes, we cleared that up in the  
meeting. There's 40 bytes of TCP option space available, as you  
explain below.

>   Maybe it was bytes, but even if so it is still wrong?  The  
> maximum size of the TCP header is 15 words, and the default size is  
> 5, leaving 10 words or 40 bytes for options.

Right.

> Hence, to me it looks like that writing a spec that defines how you  
> MAY send your HIT in a TCP option, basically causing the equivalent  
> of sending an opportunistic I1, should be relatively easy.

As mentioned above, I don't think a transport option is the right  
place to carry network-layer information around. Given that new IP  
options are pretty much useless these days, it may be the only  
possible way to achieve the desired behavior, but it doesn't strike  
me as particularly clean.

Lars
--
Lars Eggert                                     NEC Network Laboratories

--Apple-Mail-56--656122932
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

--Apple-Mail-56--656122932--

From: [email-masked] (Pekka Nikander)
Date: Wed Aug 10 08:09:01 2005
Subject: [Hipsec-rg] Opportunistic HIP and TCP options
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> Eggert: here=92s a crazy idea -- on opportunistic HIP. There is very =20=

> little contained in the I1 packet. What if you put that into an IP =20
> option that you just send to the peer -- if you know it, read it? =20
> Otherwise ignore.
> Lindquist: Nikander has suggested about using as TCP option, =20
> similar to I1, and we have been thinking about it in the InfraHIP =20
> option. We=92ll likely make a draft and implementation in the near =20
> future.
> Has many tough questions. TCP options field only has 14 bits, so it =20=

> cannot fit there.
> Gurtov: clarification please
> Eggert: they want to put it in a TCP option, yes
> TCP piggybacking
> Gurtov: sounds a little cautious to me, what about SCP, UDP -- =20
> transport might not be best place
> McGregor: point of putting it here -- you can if you want treat =20
> this as an opportunistic I1. It is possible to do an opportunistic =20
> exchange where neither end knows the HIT
> Lindquist: one motivation is we could fall back, we just use TCP
> Gurtov: I like the IP option more
> Eggert: TCP people won't like TCP option. Will you write something =20
> down on this?
> Lindquist: yes.

AFAIK (and I may well be wrong here), IP options require the packet =20
to take the slow path in most current routers, causing problems.  =20
Furthermore, many firewalls and even some routers tend to drop =20
packets with IP options.

I don't understand the comments about transport people not liking TCP =20=

options; there are even relatively new ones like RFC2385 and 2883.  =20
But maybe I am missing something here.

Another thing that I don't understand at all is the remark about TCP =20
options being only 14 bits.  Maybe it was bytes, but even if so it is =20=

still wrong?  The maximum size of the TCP header is 15 words, and the =20=

default size is 5, leaving 10 words or 40 bytes for options.  All you =20=

need to include is the sender's HIT, which takes 16 bytes, plus 2 =20
bytes option header.  MSS takes 4 bytes, WSS 4, and timestamp 12, =20
totalling in 38. So, I don't quite understand what is the problem.  =20
See RFC2385 Section 4.3 for a more detailed analysis for the MD5 option.

Hence, to me it looks like that writing a spec that defines how you =20
MAY send your HIT in a TCP option, basically causing the equivalent =20
of sending an opportunistic I1, should be relatively easy.

--Pekka

From: [email-masked] (Andrei Gurtov)
Date: Wed Aug 10 03:47:01 2005
Subject: [Hipsec-rg] [Fwd: minutes for the HIP RG meeting]
Message-ID: <[email-masked]>

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_courier-8449-1123660274-0001-2
Content-Type: multipart/mixed;
 boundary="------------090707010008050501060206"

This is a multi-part message in MIME format.
--------------090707010008050501060206
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Thanks to Jeff for taking the minutes!

Andrei

--------------090707010008050501060206
Content-Type: text/plain;
 name="080505-hiprg-notes.txt"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
 filename="080505-hiprg-notes.txt"

HIP RG
Host Identity Protocol RG minutes by Jeff Ahrenholz

FRIDAY, August 5 at 0900-1130
=============================
Room 341

CHAIRS:  Andrei Gurtov ([email-masked])
         Tom Henderson ([email-masked])
         (Tom is not attending this time)

1. Agenda, attendance sheets, note-taker, jabber scribe
   5 min
Welcome by Andrei. Pink sheets.

2. HIP experiment report (Andrei Gurtov)
   draft-irtf-hip-experiment-01.txt
   10 min
update on the HIP exp report.
Tom and I have submitted the update.
objective; __ out of scope of this RG
not too much content yet
mostly pointers to literature, document needs a lot of work
list of names requested by IRTF - showing that there is sufficient interest and progress 
sections which do not have any text
need more practical experiments with HIP
need non-trivial deployments >100 nodes or so
for example an agreement with people in China to put HIP in many hosts, but need a stable implementation that is easy to install. once WG completes documents, hopefully that will help with that
Telecom Italia has an important contribution that will be added to this report

3. HIP-OpenDHT Interface (Jeff Ahrenholz)
   draft-boeing-hiprg-opendht-00.txt (sic)
   15 min
Eggert: comment about caching - may not want to cache the values once we get fast lookup services

move to item 6 since Pekka is not present

4. Using HIP with Legacy Applications (Pekka Nikander)
   draft-henderson-hip-applications-01.txt
   10 min
Nikander:
using HIP with legacy applications
mostly Tom's work
personal view -- we need to converge on this
deemed outside of scope of the WG
implementation experience on many of these areas

Gurtov: kind of an LSI used by OCALA proxy 1.0.0.0 something
Nikander:
would like to get response from RG - what are we missing?
personal feeling: exp report is a couple of years away, maybe this belongs separate draft
background slides explained by Pekka

Eggert: basically it's a NAT inside the box; what do you do on the incoming side? how do you decide which IP address to put in there ... 
how do you predict which IP address to use for the receiver? Defeats the multihoming and mobility?
Ahrenholz: we use IP address from ESP input, locators used on the wire; checksum is rewritten based on HITs
McGregor: you could configure the services to listen on localhosts
Nikander: this is how Ericsson does it...
<continues>
Gurtov: have you considered reverse mapping from IP and HIT? 
*** Please check with Tom about reverse mapping in the draft. ***
Nikander: The biggest longer term problem, if different implementations use different methods, then we will have problems with referrals, and not full interoperability. Premature to make a decision at this point in time.
Gurtov: how about an appendix describing what legacy applications don't work?
Nikander: webpage would be appropriate for that. it changes, you need to know versions of app, HIP, OS, etc. Most applications are supposed to work
Need more reviews. Please read it. If you do read it send comments, send comments that even say "I've read it and have no comments."
Eggert: so I haven't read it. are we ready to recommend certain ways for applications
Nikander: I have my opinion and Tom has his.
Unknown: idea is to go informational? yes.

5. Migrating HIP application in the Internet using Xen (Pekka Nikander)
   Ongoing work with T. Koponen and A. Gurtov
   15 min
He was supposed to send slides but didn't. Basically I made one a couple of minutes ago. Point of Xen is that you can migrate those virtual machines from one to the other. Replaced IP level handover with HIP. Not transferring HIT/public keys. the VM have different HITs, we are doing delegation. One box creates a delegation certificate that says from now on this box represents me. full proxy of the initial HIT.
Gurtov: since HIT doesn't have a binding, we should stop calling it HIT?
Nikander: it's still a host identifier, but for the instance of the virtual host
work on next layer: how do you use public keys for sessions or applications.
status: it works. we are thinking of clever tricks so you can have virtual handover times of 0.
McGregor: why not just allow the keys to move?
Nikander: you can do that. but part of me is a security geek, even though security people may not acknowledge that. From that point of view, it's not such a good idea to move your keys around. In my personal opinion, from security architecture this is what you want to do.
McGregor: relates to previous presentation, using an opaque LSI that is not bound to the HIT
Nikander: <explanation>
McGregor: interesting alternative to simply allowing keys to move. In most cases, I think you would probably allow the keys to move anyway (using local Ethernet) but halfway across the Internet this is a better way.

6. NAT problem statement (Martin Stiemerling)
   draft-stiemerling-hip-nat-05.txt
   10 min
Eggert:
been through quite a few revisions
problem statement - want is not going to work if you want to run the currently specified drafts
now a pure problem statement
URL of old document is pretty stable at this point
what to do with this document - is that fine with you?
hum to adopt as a research group item
(no hums against)

7. Traversal of HIP aware NATs and Firewalls (Hannes Tschofenig)
   draft-tschofenig-hiprg-hip-natfw-traversal-02.txt
   10 min
Hannes actually had to run away to current NSIS WG meeting. He left me the slides which I haven't seen yet, so I am going to show them on his behalf.
Lars has presented draft - problem statement for legacy NAT traversal, this is the case for middleboxes designed with HIP in mind.
Originally included a lot of specific proposal, has been moved to the appendix, maybe could be removed altogether.
How many have read? A couple. We need more people to read and post comments to the mailing list.
Any comments on the draft?
Eggert: my only comment is that I don't see why this is an issue right now, are people going to build HIP aware NAT/firewalls right now?
McGregor: I am intending to do some firewall work.
Gurtov: we have implemented HIP-aware firewall, good to see how well it follows this draft, maybe not very well because they evolved concurrently (thesis will be available soon)

8. Using SRTP transport format with HIP (Hannes Tschofenig)
   draft-tschofenig-hiprg-hip-srtp-00.txt
   draft-tschofenig-hiprg-host-identities-02.txt
   15 min
Andrei:
First draft was a generic discussion between HIP and SIP.
The idea is to use HIP associations as a platform for SIP.
Eggert: channel binding again. if you don't know ___. specific example of generic problem. 
Camarillo: we are using so called K field in the draft. It has a set of problems. Maybe we will use a new mechanism, we need to do more research here
secure STRP problem, is that wireless devices do not want to use IPsec, you want to use header compression. SRTP over IPsec, not how ESP should be applied
In my opinion, these are two open issues in the draft.
Gurtov: question ???
Camarillo: last document in the SIP working group was approved. There is no deployment experience.
controversial HIP does not go through middleboxes
please send comments to mailing list

9. Privacy extentions (Alfredo Matos)
   draft-matos-hip-privacy-extensions-00
   15 min
Matos:
We focused on location privacy since it is a growing requirement
for example, last Tuesday, they are focusing on the problem
current arch provides no privacy at all
fairly easy to track a node's position through the network
no location privacy is provided w with HIP
good thing is it decouples the locator and the identifier
example topology.
we introduce 3 elements, 2 new -
extend RVS concept.
identity of HIP mobile node translates to RVA identity. RVA assigns global IP to each mobile node.
size of RVA determines amount of geographical information revealed.
focus on network mobility, which is difficult with the additional level of hierarchy
how to do signaling delegation - since CERT is no longer in the draft

Questions: is this an interesting topic for HIPRG? In/Out of scope? are there additional proposals for more in-scope items?

Vogt: yes, it definitely makes sense. in MIP there is hierarchical MIP and it works very similar to this, so it seems to be a good approach. question, do we use current mobility approach? 
yes ... so you get CBA also.
<discussion on what mechanisms they are doing>
whether you use existing hip-mm to register IPs with RVA? yes.

Mathis: stunned by the power of this -- brings something to the net, I think this is very important. This underscores some of Steve Bellovin’s comments last night (plenary). If locators tell you nothing about who people are, how do you know if your mappings are correct. Imagine having good ... 

Gurtov: prototype?
we are looking at it, we make no promises

Gurtov: Yes, is a very interesting item for the RG

10. Implementation status of BEET and PATH (Andrei Gurtov)
   draft-nikander-esp-beet-mode-03.txt
   draft-nikander-hip-path-00.txt
   10 min
BEET - mostly done by Diego from HIIT.
BSD was easy - done in three days. hard because XFRM has little documentation.
support for auth header
Ahrenholz: comment on using tunnel mode -- you really want to bind the SA to the inner address, not the outer address, to implement BEET; otherwise you have problems with mobility.

PATH draft
optimistic case -- NAT traversal for HIP in early September.
PATH draft has not been recently updated; PATH does not have enough details...
Eggert: update the draft or write a new one whatever is quicker
*** Need discussion on mailing list about this. ***

11. Hi3 implementation and experimental results (Andrei Gurtov)
   draft-nikander-hiprg-hi3-00.txt
   10 min
This infrastructure could be used to bootstrap HIP experimentation
Eggert: do you have an idea why traffic fluctuates a lot, while IP traffic does not?
Gurtov: why is IP getting less throughput that HIP traffic occasionally?

12. Hi3 scalability analysis (Dmitry Korzun)
   draft-nikander-hiprg-hi3-00.txt
   15 min
Korzun:
use distributed rendezvous server - i3
using some theory to look at what should happen, cannot do experiment with millions of nodes
Main result: latency is a result of these two factors: size of infrastructure and node to node forwarding cost. O(logN) results

Zhang: question - where you use hi3, are you using it in the control plane or the data plane? how can it work through middleboxes
Zhang: there are always some tradeoffs. example: if you only do mapping at first time you send data, it may be hard to support mobility. Like DNS today, you may have to use caching, how do you know about such movement? I’m afraid of limitations in performance with Hi3. What about a router which has simple forwarding mechanism - I don't see how you can achieve this goal with Hi3... they will find it hard to implement in actual hardware routers 10G or 40G etc
Gurtov: not quite there yet, with anyone thinking about
Dmitry: we use only for control plane, double jump problem, not for the data plane. The double jump problem performs quite well -- better than MIP
Zhang: there are always some tradeoffs. Supporting privacy and forwarding, you have to pay. Perhaps 90% user uses key functions -- must choose whether you will receive requirements from 10% of user, hard to choose.... we must be cautious in adding a new feature to a NAT -- we maybe can't use the model here.

Zhang: How can you mitigate DoS attack with Hi3 architecture? End users or servers?
Dmitry: we are working with this issue. we need some extra assumptions for this.
Need to estimate its origin using some assumptions about attacker. My estimates are too rough to make a statement.
Zhang: Hi3 not related to ___
Gurtov: if receiver notices lots of traffic, it can tell i3 to stop sending data
Zhang: what about for a public server that is accessible?
Gurtov: explains how i3 works w/private triggers
Zhang: <gives an example>
Gurtov: difficult problem to distinguish flash crowd traffic vs legitimate.
Zhang: even without i3, we can add a feature to the IP header to do DoS?
Gurtov:
Zhang: people don't consider performance enough with i3 architecture. in my opinion it is quite hard to perform well. we must note that there are limitations with this technology.
Gurtov: to serve a reasonably large amount of nodes, current Hi3 arch will even support it. Pure i3 has much higher requirements due to forwarding control + data.

13. Native HIP API (Andrei Gurtov)
draft-mkomu-hip-native-api-00.txt
feedback summary - may need something more generic. OTOH, can't be too generic or you will never finish it.
Eggert: you need an API for the WG, but you need a clean API for the new stuff that the RG, it is not clear where it should be. Maybe it should be two drafts, i don't know.
Gurtov: perhaps one option is basic functionality to the WG, advanced to the RG
something to discuss w/Miika
*** Please send ideas to the list. ***
McGregor: some feedback for some app area meeting people. For a minimally-aware application, using new resolver functions is not a particularly good idea, better to add extra codepoints through getaddrinfo(), a better interface for adapting things.
Gurtov: legacy, HIP-aware, minimally aware HIP apps.
McGregor: relatively rare function is loading host ids, etc
Gurtov: can't implement HIP naming resolution. app happens to be pretty HIP aware
McGregor: take it to the list
This is not very compatible with opportunistic mode. No comment from Ericsson.
Might be able to be solved through new OCALA architecture

14. Open Discussion.
Any new ideas for the RG, etc?

Eggert: RG is supposed to throw over ideas to WG. What are some of the low-hanging apples that we can do here and throw over to the WG?
Gurtov: legacy NAT traversal... pretty trivial thing to do. Once finished w/base draft, that's a good thing to move there.
McGregor: privacy extensions are a good thing to move there. But first they should stay here for a little while.
Gurtov:  what about BEET? hanging in MobIKE somewhere?
Eggert: any new feedback about BEET?
Gurtov: haven't heard anything too angry from them. People like Jari Arkko are fond of it. It may be useful in areas other than HIP.
McGregor: maybe we should just last call it

Eggert: here’s a crazy idea -- on opportunistic HIP. There is very little contained in the I1 packet. What if you put that into an IP option that you just send to the peer -- if you know it, read it? Otherwise ignore.
Lindquist: Nikander has suggested about using as TCP option, similar to I1, and we have been thinking about it in the InfraHIP option. We’ll likely make a draft and implementation in the near future.
Has many tough questions. TCP options field only has 14 bits, so it cannot fit there.
Gurtov: clarification please
Eggert: they want to put it in a TCP option, yes
TCP piggybacking
Gurtov: sounds a little cautious to me, what about SCP, UDP -- transport might not be best place
McGregor: point of putting it here -- you can if you want treat this as an opportunistic I1. It is possible to do an opportunistic exchange where neither end knows the HIT
Lindquist: one motivation is we could fall back, we just use TCP
Gurtov: I like the IP option more
Eggert: TCP people won't like TCP option. Will you write something down on this?
Lindquist: yes.

Gurtov: what about the DHT draft?
Ahrenholz: probably keep it in RG for now. It’s still too researchy, need more implementation experience and interop'ing with it.
McGregor: people need to play with it for a while see where the DHTs break. It will work to the extent that OpenDHT is... we don't kwow what deployability is, we may need to design a DHT from scratch. i.e., what if you want to use XMLRPC over HIP. That remains researchy yes.
Gurtov: probably need more time. We are working w/Sean Rea at UC Berkeley, improving latency
Eggert: I like it a lot, but it is something to experiment with, too specific. 
The more general case is interesting: what are the tables, lookup steps
Gurtov: I think vice versa. Draft the specific implementation uses to WG, more generic to RG.

Do we like the Friday time slot?
yes

--------------090707010008050501060206--

--=_courier-8449-1123660274-0001-2
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--=_courier-8449-1123660274-0001-2--

From: [email-masked] (=?ISO-8859-1?Q?V=E4is=E4nen_Teemu?=)
Date: Tue Aug  9 06:41:00 2005
Subject: [Hipsec-rg] Kernel compiling with HIP
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi, I have couple of questions about compiling new UML-kernel and Hipl.

Do I need download and compile new 2.6.10 kernel with
linux-2.6.10-hipl-0.1.2.patch HIPL-patch or can I just use that
hipl-complete-0.1.2.tar.gz? What's the difference between these ways?
I assume that I don't need patches with hipl-complete-0.1.2.tar.gz.

I copied one config file:
# cp ../test/configs/config-2.6.10-1.770_FC3_HIP .config

# grep HIP .config
shows for example:
...
CONFIG_HIP=3Dm
CONFIG_HIP_RVS=3Dy
CONFIG_HIP_DEBUG=3Dy
...

When trying to edit .config file
# make xconfig ARCH=3Dum

There are really many problems, like
...
.config:2716: trying to assign nonexisting symbol X86_BIOS_REBOOT
.config:2717: trying to assign nonexisting symbol PC

After that qconf starts, but I can't find those options (HIP,
PREEMPT...) anymore. So they seem to disappear.

If saving .config, for example command
# grep HIP .config
shows nothing, so somehow lines really disappear from .config -file.=20

" "'s are from http://infrahip.hiit.fi/hipl/manual/ch04.html

"Compile the kernel with at least the following options:
...
 Processor type and features
 [*] Preemptible Kernel
...
 <M> Host Identity Protocol
 [*] HIP: debugging (NEW)
"

So problem is, that I can't find these necessary options from .config
-file after I am trying to edit them.

Could someone give some help, please?

-Teemu V=E4is=E4nen

From: [email-masked] (Andrew McGregor)
Date: Wed Aug  3 05:23:01 2005
Subject: [Hipsec-rg] draft-irtf-hip-experiment-01.txt link
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

--Apple-Mail-17-872467904
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

On 3/08/2005, at 9:50 AM, Pekka Nikander wrote:
>
> Personally, I am looking forward to someone completing a Mac OS X  
> implementation, at which point I am planning to move from my  
> current SSH and IPsec tunnels to HIP as soon as possible.
>
> --Pekka

Same here, although I'm also interested in using HIP on our wireless  
mesh.  That'll have to wait till we have the integration time, which  
is the bottleneck in getting new code onto that platform.

Andrew
--Apple-Mail-17-872467904
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><BR><DIV><DIV>On 3/08/2005, at =
9:50 AM, Pekka Nikander wrote:</DIV><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">Personally, I am looking forward to someone completing a Mac OS X =
implementation, at which point I am planning to move from my current SSH =
and IPsec tunnels to HIP as soon as possible.</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">--Pekka</DIV></BLOCKQUOTE></DIV><FONT class=3D"Apple-style-span" =
color=3D"#0000DD"><BR class=3D"khtml-block-placeholder"></FONT><DIV><FONT =
class=3D"Apple-style-span" color=3D"#0000DD">Same here, although I'm =
also interested in using HIP on our wireless mesh.=A0 That'll have to =
wait till we have the integration time, which is the bottleneck in =
getting new code onto that platform.</FONT></DIV><DIV><FONT =
class=3D"Apple-style-span" color=3D"#0000DD"><BR =
class=3D"khtml-block-placeholder"></FONT></DIV><DIV><FONT =
class=3D"Apple-style-span" =
color=3D"#0000DD">Andrew</FONT></DIV></BODY></HTML>=

--Apple-Mail-17-872467904--

From: [email-masked] (Petri Jokela)
Date: Wed Aug  3 04:04:00 2005
Subject: [Hipsec-rg] draft-irtf-hip-experiment-01.txt link
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Pekka Nikander wrote:
> Andrei,
> 
>> Have you been thinking of installing HIP in a wider scale in  Nomadiclab?
>  
> I'll let others to answer; I am not the right person to answer this  
> question.

We haven't yet planned to do so, we have HIP only on few hosts at the 
moment.

/petri

From: [email-masked] (Pekka Nikander)
Date: Wed Aug  3 03:48:01 2005
Subject: [Hipsec-rg] draft-irtf-hip-experiment-01.txt link
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Andrei,

> .... There is an agreement to create a HIP deployment on some  
> CERNET hosts in China, but before we can do it, we should get a  
> stable implementation that is easy to install.

Great, and I agree.

> Have you been thinking of installing HIP in a wider scale in  
> Nomadiclab?

I'll let others to answer; I am not the right person to answer this  
question.

Personally, I am looking forward to someone completing a Mac OS X  
implementation, at which point I am planning to move from my current  
SSH and IPsec tunnels to HIP as soon as possible.

--Pekka

From: [email-masked] (Andrei Gurtov)
Date: Wed Aug  3 03:28:00 2005
Subject: [Hipsec-rg] draft-irtf-hip-experiment-01.txt link
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_courier-765-1123054245-0001-2
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Pekka,

Thanks for comments, I completely agree with them. There is an agreement 
to create a HIP deployment on some CERNET hosts in China, but before we 
can do it, we should get a stable implementation that is easy to install.

Have you been thinking of installing HIP in a wider scale in Nomadiclab?

Andrei

Pekka Nikander wrote:

> Andrei and Thomas,
>
>
>> http://www.ietf.org/internet-drafts/draft-irtf-hip-experiment-01.txt
>>
>
> Thanks for working on this draft.  I think it makes a pretty useful  
> summary of what is going on right now and what are the small scale  
> problems and issues that people are looking at.  As such, keeping the  
> document up to date clearly provides value to the community.
>
> However, if we consider further future, when we hopefully have some  
> limited real experience from using HIP in the Internet, I think we  
> should focus then on more large scale issues.  Both practical ones  
> (does HIP work through existings NATs?) and more fundamental ones  
> (does the proposed DHT-based system really scale?  What are its  
> security properties).
>
> Hence, I think keeping the draft up to date in its current format is  
> good, but I would also see it to evolve into a more substantial  
> *experience* report in the future.  More answering to the question of  
> what works, what does not, and what are the potential practical  
> consequences if people started to widely use HIP in the Internet.
>
> --Pekka
>
>

--=_courier-765-1123054245-0001-2
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--=_courier-765-1123054245-0001-2--

From: [email-masked] (Tschofenig, Hannes)
Date: Mon Aug  1 05:12:01 2005
Subject: AW: [Hipsec-rg] What is the most important packet in HIP base exchange? R2!
Message-ID: <[email-masked]>

hi pekka,=20

in <draft-tschofenig-hiprg-hip-natfw-traversal-02.txt> we certainly saw =
a need to attach authorization information into I2. once the =
authorization is done then the middlebox responds with the R2. the fact =
that the end host receives a valid R2 indicates that he is authorized to =
access the network. would you like to add some information about what =
you are authorized?=20

ciao
hannes

> -----Urspr=FCngliche Nachricht-----
> Von: [email-masked]=20
> [mailto:[email-masked]] Im Auftrag von=20
> Pekka Nikander
> Gesendet: Montag, 1. August 2005 09:26
> An: [email-masked]
> Betreff: [Hipsec-rg] What is the most important packet in HIP=20
> base exchange? R2!
>=20
>=20
> Folks,
>=20
> I have been thinking about some issues related to potential future =20
> Internet architecture during the last few days, and feel that=20
> I reach =20
> some level of partial enlightenment (w.r.t. HIP) last night,=20
> and like =20
> to share it with you.
>=20
> If we considers the HIP base exchange, the initial impression (at =20
> least to me) is that I2 is the most important packet.  It requires a =20
> major piece of work to have been done by the initiator, it creates =20
> state at the responder, etc.
>=20
> However, if we look at the situation from a future point of view, R2 =20
> seems to have even more important role than I2.  All kinds of bad =20
> traffic are likely to be much more prevalent than today.  =20
> Consequently, if HIP gets widely deployed, it is likely that many =20
> hosts will allow only I1 and I2 packets from unknown hosts, and =20
> filter/verify even those at some front end, e.g., a firewall.
>=20
> Now, it is the R2 packet that the local front end boxes (and maybe =20
> the routing infrastructure in some far future) use to authorise =20
> incoming traffic.  R2 indicates that the responder has
>    - authenticated the initiator (at least at the level of HIs)
>    - authorised the initiator to send (at least some) traffic to the =20
> responder
>=20
> Hence, R2 is not just an acknowledgement that completes the base =20
> exchange, but a message that potentially carries much more=20
> importance =20
> to the network than the other base exchange packets.
>=20
> --Pekka
>=20
> _______________________________________________
> Hipsec-rg mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec-rg
>=20

From: [email-masked] (Pekka Nikander)
Date: Mon Aug  1 03:23:01 2005
Subject: [Hipsec-rg] What is the most important packet in HIP base exchange? R2!
Message-ID: <[email-masked]>

Folks,

I have been thinking about some issues related to potential future  
Internet architecture during the last few days, and feel that I reach  
some level of partial enlightenment (w.r.t. HIP) last night, and like  
to share it with you.

If we considers the HIP base exchange, the initial impression (at  
least to me) is that I2 is the most important packet.  It requires a  
major piece of work to have been done by the initiator, it creates  
state at the responder, etc.

However, if we look at the situation from a future point of view, R2  
seems to have even more important role than I2.  All kinds of bad  
traffic are likely to be much more prevalent than today.   
Consequently, if HIP gets widely deployed, it is likely that many  
hosts will allow only I1 and I2 packets from unknown hosts, and  
filter/verify even those at some front end, e.g., a firewall.

Now, it is the R2 packet that the local front end boxes (and maybe  
the routing infrastructure in some far future) use to authorise  
incoming traffic.  R2 indicates that the responder has
   - authenticated the initiator (at least at the level of HIs)
   - authorised the initiator to send (at least some) traffic to the  
responder

Hence, R2 is not just an acknowledgement that completes the base  
exchange, but a message that potentially carries much more importance  
to the network than the other base exchange packets.

--Pekka