Subject: [Hipsec] NONCE parameter in base exchange?

From: [email-masked] (Henderson, Thomas R)
Date: Thu Oct 7 16:55:01 2004

> -----Original Message-----
> From: Ahrenholz, Jeffrey M=20
> Sent: Thursday, October 07, 2004 8:42 AM
> To: Julien Laganier; [email-masked]
> Cc: Petri Jokela; Yogesh Prem Swami
> Subject: RE: [Hipsec] NONCE parameter in base exchange?
>=20
>=20
>=20
> <snip>
> > You can create separate SAs based on different NONCES, and then the=20
> > hack is when an outbound packet enters ESP, the SA=20
> selection is made=20
> > locally, based on Traffic Selectors including TCP/UDP ports for=20
> > example, and not enforced by the ESP receivers, which hence doesn't=20
> > need to be aware of the local TSs used by the ESP sender.
> >=20
> > This allows for separation of multiple connexions by the sender,=20
> > without having to negociate TSs with TCP/UDP ports numbers in HIP=20
> > itself.
>=20
> Using this method, with the receiver not aware of the sender's local
> TSs, you would probably have asymmetric return traffic (i.e.,=20
> returning
> on another SPI)(unless the receiver sets up its own TSs that happen to
> exactly match the sender). But I would agree that this might be more
> elegant than using multiple HIs.

Although HIP does not have any requirements document, I don't think
that managing multiple parallel SAs is a strong requirement to work for=20
HIPv1.  It has been stated in the architecture document that there is=20
less policy granularity in HIP than in other key exchange protocols. =20
Maybe this gets revisited in the future.

>=20
> <snip>
> > I would vote for adding NONCE, as it make HIP SIGMA-compliant, and=20
> > keep ECHO_REQ/REP.=20
>=20
> Do we need both NONCE and ECHO?

I don't see why we can't replace ECHO_REQ/RESP with NONCE.  They are
functionally the same, right?  (and define a NONCE within and outside
of the signature, like ECHO_REQ is presently done).

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

Agreed.

Tom

---

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

On Thursday 07 October 2004 23:58, Henderson, Thomas R wrote:
> > From: Ahrenholz, Jeffrey M
> > > 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.
> >
> > Using this method, with the receiver not aware of the sender's
> > local TSs, you would probably have asymmetric return traffic
> > (i.e., returning
> > on another SPI)(unless the receiver sets up its own TSs that
> > happen to exactly match the sender).=20

But IPsec is asymmetric, isn't it? You need two IPsec SAs, with two=20
SPIs, one in each direction to carry a single TCP connexion. Traffic=20
will return 'asymmetrically' to 'another' SPI, but return packets=20
might well flow 'symmetrically' on the IP network, i.e., on the same=20
path as forward packets (if both peers are using a single net_if wich=20
is assigned a single IP address).

> > But I would agree that this=20
> > might be more elegant than using multiple HIs.
>
> that managing multiple parallel SAs is a strong requirement to work
> for HIPv1. =A0It has been stated in the architecture document that
> there is less policy granularity in HIP than in other key exchange
> protocols. Maybe this gets revisited in the future.

I agree. For now, if one of the peers wants to spread connexions=20
amongst multiple SAs, he can use kind of "sender-side only" TSs.=20

It obtains part of the wanted effect. And if the other peer is willing=20
to play the same game then everything is fine: each TCP connexion=20
flow onto his own two IPsec SAs, on the same IP path, though the SPI=20
are different and it hasn't been specifically negotiated. =20

<snip>

> I don't see why we can't replace ECHO_REQ/RESP with NONCE.  They
> are functionally the same, right?  (and define a NONCE within and
> outside of the signature, like ECHO_REQ is presently done)..=20

I dunno.

BTW, NONCEs might also be useful if we add a CLOSE/CLOSEACK hanshake=20
to HIP: If a host is in state CLOSING but has data to sent, it can=20
initiates another HIP exchange with a newly created state and fresh=20
NONCE-I.=20

This way a responder receiving a packet might be able to differentiate=20
states which otherwise would have appeared to be the same.

=2D-julien