Subject: RE: [Hipsec] NONCE parameter in base exchange?

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 7 Oct 2004 14:58:24 -0700

> -----Original Message-----
> From: Ahrenholz, Jeffrey M 
> 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?
> 
> 
> 
> <snip>
> > 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). 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 
HIPv1.  It 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.

> 
> <snip>
> > I would vote for adding NONCE, as it make HIP SIGMA-compliant, and 
> > keep ECHO_REQ/REP. 
> 
> 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).

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

Agreed.

Tom
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: Julien Laganier <[email-masked]>
Date: Fri, 08 Oct 2004 01:25:22 +0200

On Thursday 07 October 2004 23:58, Henderson, Thomas R wrote:
> > > 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
> >
> > > 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). 

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

> > But I would agree that this 
> > might be more elegant than using multiple HIs.
>
> that managing multiple parallel SAs is a strong requirement to work
> for HIPv1.  It 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 
amongst multiple SAs, he can use kind of "sender-side only" TSs. 

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

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

I dunno.

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

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

--julien