Subject: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward

From: [email-masked] (Ahrenholz, Jeffrey M)
Date: Fri Oct 1 11:12:02 2004

A couple of questions about this nonce:

- Does including the nonce in R1 affect the R1 properties of being
stateless, precomputed?

- One motivation for the nonce is for allowing parallel SA creation.
Yogesh's example was having 3 different SAs between the same hosts at
the same time, for three different TCP connections. How does this work
after all of the HIP SAs are set up? It seems you need to use port
numbers then to disambiguate which packets flow into which SAs/SPI.
Would the port numbers need to be included in the HIP exchange, or how
does the responding side (for example) know the specifics of how to set
up its SAs and policies?

-Jeff

> > I have also added nonce-I and nonce-R in all these message. This is
> > important to allow parallel SA creation, and allow cases where both
> > initiator and responder choose pre computed g^i and g^r (this can
> > happen, unless the draft explicitly prevents it). The nonce should
> > be used in deriving the session keys.
>=20
> Currently we have the ECHO REQ/REPLY in R1/I2. This nonce=20
> would replace=20
> it. Any opinions on this list?

---

From: [email-masked] (Petri Jokela)
Date: Thu Oct 7 02:45:01 2004

> - Does including the nonce in R1 affect the R1 properties of being

As far as I can see, it doesn't affect.

> does the responding side (for example) know the specifics of how to set

So, creating multiple SAs would require some information change between 
the hosts about the usage of the connections. I think that it is not 
feasible to include it in HIP v1.

A "hack" would be to use multiple HIs (HITs) for creating separate SAs 
between the hosts. Not a nice solution and solves the problem only from 
the Initiator point of view, but it wouldn't require any additional 
negotiation between the hosts.

There are not too many opinions on this issue on the list? What shall we 
do with it: 1) add the NONCE parameter and remove ECHO REQ/RESP, 2) 
leave the draft as it is now and think this again in HIP v2.

/petri

---

From: [email-masked] (Julien Laganier)
Date: Thu Oct 7 03:25:01 2004

On Thursday 07 October 2004 09:51, Petri Jokela wrote:
> > - Does including the nonce in R1 affect the R1 properties of
> > being stateless, precomputed?
>
> > - One motivation for the nonce is for allowing parallel SA
> > creation. Yogesh's example was having 3 different SAs between the
> > same hosts at the same time, for three different TCP connections.
> > How does this work after all of the HIP SAs are set up? It seems
> > you need to use port numbers then to disambiguate which packets
> > flow into which SAs/SPI. Would the port numbers need to be
> > included in the HIP exchange, or how does the responding side
> > (for example) know the specifics of how to set up its SAs and
> > policies?
>
> So, creating multiple SAs would require some information change
> between the hosts about the usage of the connections. I think that
> it is not feasible to include it in HIP v1.

I agree.

> A "hack" would be to use multiple HIs (HITs) for creating separate
> SAs between the hosts. Not a nice solution and solves the problem
> only from the Initiator point of view, but it wouldn't require any
> additional negotiation between the hosts.

You can create separate SAs based on different NONCES, and then the 
hack is when an outbound packet enters ESP, the SA selection is made 
locally, based on Traffic Selectors including TCP/UDP ports for 
example, and not enforced by the ESP receivers, which hence doesn't 
need to be aware of the local TSs used by the ESP sender.

This allows for separation of multiple connexions by the sender, 
without having to negociate TSs with TCP/UDP ports numbers in HIP 
itself.

> There are not too many opinions on this issue on the list? What
> shall we do with it: 1) add the NONCE parameter and remove ECHO
> REQ/RESP, 2) leave the draft as it is now and think this again in
> HIP v2.

I would vote for adding NONCE, as it make HIP SIGMA-compliant, and 
keep ECHO_REQ/REP. 

IMHO this is a minor addition which buys us provable security by 
conforming to the SIGMA core protocol, so I believe we don't need to 
wait until v2 to handle NONCEs.

My 2 cents,

--julien

---

From: [email-masked] (Jan Mikael Melen)
Date: Fri Oct 8 01:46:00 2004

Hi,

> wait until v2 to handle NONCEs.

I would vote for option 1.5 so I don't have anything against renaming ECHO to 
NONCE if it is what makes people to sleep better ;) The functionality is the 
same with NONCE and ECHO as it has been pointed out several times on this 
list (s/ECHO/NONCE/g ;)

But I won't be voting for having multiple SAs with different policies. IMHO 
before we can have multiple SAs with different policies we should be able to 
somehow inform the peer node that I'm going to use this SA only for ssh and 
would like to have the return packets through the SA paired to this one. Now 
if either end wants to use some other protocol they'll know that they'll have 
to create a new SA pair between the hosts or do some policy negotiation. I 
think that this kind of policy issues should be left to HIPv2.

  Regards,
	Jan

---

From: [email-masked] (Pekka Nikander)
Date: Fri Oct 8 06:01:01 2004

Just one aspect now, I'll try to return to the rest later.
Sorry for not having had time to take this up earlier.

Supporting multiple parallel SAs between any pair of HIs
has been a non-goal for HIP from the beginning.  The mobility
and multi-homing extension adds such a feature, but _only_
for dealing with replay window problems.

If this non-goal is not clear from the base spec / arch spec,
we need to add explicit text.  And I guess the case is so,
since we've faced this same issue before.

Anyone willing to draft text to be included in both/either of
the drafts, noting that _architecturally_ HIP only considers
host-to-host granularity, and any finer granularity is FFS?

If someone wants to add policy control to HIP so that you could
have multiple parallel SAs for policy purposes, that requires
an extension and DOES NOT belong to the base specification.

 From that point of view, I don't see any need for having
nonces.  There may be other reasons; I haven't had flow time
to contemplate that.

--Pekka

---

From: [email-masked] (Tim Shepard)
Date: Fri Oct 8 06:18:00 2004

> has been a non-goal for HIP from the beginning.

Yes.

And our thinking on this was that HIs can be easily created, as many
as you like, and only one of two hosts would have to use a different
HI in order to have parallel HIP sessions going simultaneously between
two hosts.  We were thinking that typical HIP associations would be
using an ephemeral HI on at least one end (probably the initiator) so
if for some reason you need to open a parallel SA, you just create
another ephemeral HI.   Even if there's a situation where you need
non-ephemeral HIs at both ends, then if you need parallel SAs, you can
probably manage to have a different HI at least at one end.

At least that is what we were thinking, and at this particular moment
I am not convinced that this thinking was in error.

			-Tim Shepard
			 [email-masked]

---

From: [email-masked] (Yogesh Prem Swami)
Date: Sun Oct 10 21:28:01 2004

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

catching up...

> I am not convinced that this thinking was in error.

I wasn't expecting so much discussion on this issue. One can of course
use new HIs for every simultaneous SA creation, but a) this will make
the possibility of HIT collision much higher, b) the user will have to
wait for minutes if HIs are to be generated on the fly (may be one can
cache all the previously generated HIs, still...) and c) If you want
MITM prevention through DNSsec, the DNS database size will explode.

Compared to all this, a nonce is somewhat more efficient.

If I understand right, I guess the traffic selector is the main
objection that people have for not using  nonce. But as Julien pointed 
out, one can use "populate from packets" (PFP) to setup the filters. 
Also, I am not sure how multiple HIs help. If you have a BITW 
implementation of IPsec, you still need some mechanism to tell the IPsec 
filter to select packets based on IP address/port-numbers (the HITs are 
not present in the packets). So we end with the same problem, don't we? 
What am I missing here?

Yogesh

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

--------------enig90A14E5CE55C2CD19A479754--

---

From: [email-masked] (Pekka Nikander)
Date: Mon Oct 11 00:56:01 2004

> objection that people have for not using  nonce. But as Julien
> pointed out, one can use "populate from packets" (PFP) to setup
> the filters.

As far as I have understood the thinking of the community (the
chairs may correct), the current belief is that if someone wants
to have traffic selectors and multiple parallel SAs for policy
reason, the right thing to do is to write an extension, present
it at the RG side, and sense the feeling of the community at the
re-chartering time.  Hence, IMHO, that discussion should be moved
to the RG mailing list.

> implementation of IPsec, you still need some mechanism to tell
> the IPsec filter to select packets based on IP address/port-numbers
> (the HITs are not present in the packets)

At least my understanding has been that iff you are dealing
with legacy hosts and therefore BITW IPsec, you just configure
your host to use either LSIs (1.0.0.0/8) or HITs (4000::0/2)
on the local link.  Contrary what the docs says, in that special
case you do have LSIs or HITs in IP headers on the wire.
Hence, you will have HITs (or at least LSIs) even in a BITW
implementation.  Other than that, properply implementing HIP
support on a BITW box is pretty impossible.

--Pekka

---

From: [email-masked] (Yogesh Prem Swami)
Date: Mon Oct 11 12:45:01 2004

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

Hi Pekka,

I am okay with not using NONCE. Also, as I have said before, it's 
important to get some implementation experience with the present draft.

I'll get to other e-mails later on (in a couple of days).

Yogesh

ext Pekka Nikander wrote:
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec

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

--------------enigFBA5A59C0068240556F1285D--