Subject: [Ipsec] Asymmetric Security

From: [email-masked]
Date: Fri, 11 Feb 2005 10:30:22 -0500

Hi All,

I wanted to start a discussion on Asymmetric Security.

Asymmetry can show up in different ways in a secure transmission. For example:
	* we can have asymmetry in the gateways involved in secure transmission. 
	* we can have asymmetry in the tunnels between two possible multihomed 
	  gateways
	* we can have asymmetry in the tunnel endpoints of the a tunnel

(1) Asymmetry in Gateways: 
Let us say there are three gateways A, B, C. In the forward direction secure traffic 
flows from Gateway A to Gateway B. In the reverse direction traffic flows from 
Gateway C to Gateway A.  A Mobile IP End-to-End Security between a 
correspondent node and a mobile node will be an example scenario here.
IKE negotiations between A and B can setup a tunnel and IKE negotiations
between C and A can set up the tunnels. Both the tunnels shall still protect the
same hosts/addresses. [Since IKE negotiations do not allow asymmetry we will
have to have two separate IKE negotiations]

(2) Asymmetry in Tunnels:
Let us say there are two multihomed Gateways. These gateways negotiate TWO 
tunnels, each with different tunnel endpoints (corresponding to multihomed addresses).
But both the tunnels still protecting the same hosts/addresses. This can be a real
life scenario to acheive redundancy/high availability

(3) Asymmetry in Tunnel Endpoints
Let us say there are two multihome Gateways. These gateways negotiate ONE tunnel,
but with different tunnel endpoints in forward and reverse direction. Something recently
discussed in MOBIKE mailing list.

I wanted to ask folks if current efforts (standards, or to-be-standards) solve all the 
Asymmetry needs of Security? Does it make sense to start new efforts to deal 
Asymmetry in Security (ASEC )? 

Should we have a BoF, when we can, to discuss the Asymmetric needs of Security?

Atul

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Mon, 14 Feb 2005 14:24:43 +0200

I would add a fourth scenario, which is actually a variation.

(4) Asymmetry in clustered gateways
Let us say that there are several gateways (call them A1 and A2) that 
appear to be a single gateway (i.e, have one identifier, one 
certificate, one IP address) with some load-sharing clustering hardware 
or software.  Any peer (call it C) must never see anything other than a 
single gateway (call it A).  The problem is that due to performance 
constraints, the two gateways cannot synchronize their state after 
every packet, and because of the retransmission counter of ESP, they 
need to have two SAs, one for A1 and one for A2.  In IKEv1 this was a 
problem, because IKE implementations were not required to support 
multiple redundant SAs (and to C, it looks like the two SAs are 
redundant).  Such implementations always deleted one of the SAs.  In 
IKEv2 C is required to support multiple redundant SAs.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Feb 2005 23:54:40 -0500

At 2:24 PM +0200 2/14/05, Yoav Nir wrote:
>Let us say that there are several gateways (call them A1 and A2) 
>that appear to be a single gateway (i.e, have one identifier, one 
>certificate, one IP address) with some load-sharing clustering 
>hardware or software.  Any peer (call it C) must never see anything 
>other than a single gateway (call it A).  The problem is that due to 
>performance constraints, the two gateways cannot synchronize their 
>state after every packet, and because of the retransmission counter 
>of ESP, they need to have two SAs, one for A1 and one for A2.  In 
>IKEv1 this was a problem, because IKE implementations were not 
>required to support multiple redundant SAs (and to C, it looks like 
>the two SAs are redundant).  Such implementations always deleted one 
>of the SAs.  In IKEv2 C is required to support multiple redundant 
>SAs.

As you noted, it is not generally feasible for two devices to appear 
to be one device, due to sequence number management constraints. 
Also, there is this small matter of synchronizing the keys generated 
for the SAs between the two devices, in a secure fashion.

So, a solution today is to create distinct SAs to each device, and 
recognize that they represent parallel SGs and don't try to make them 
look like one SG.

What would you want IPsec to do differently, and what implications 
have you discovered as a result of any proposed changes?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Feb 2005 00:04:56 -0500

>have to have two separate IKE negotiations]

so, what's the problem? you have separate SAs because you have 
different endpoints. we decided long ago to create SAs in pairs. are 
you concerned that the state maintained for the unused SAs is a 
unacceptable burden?

>life scenario to acheive redundancy/high availability

again, what is the problem here?

>discussed in MOBIKE mailing list.

as I noted in a separate response, this scenario needs a better 
description, given the use of terms above.

>Should we have a BoF, when we can, to discuss the Asymmetric needs 

I think you have a long way to go before you establish the need for a BoF.

Steve

---

From: Jari Arkko <[email-masked]>
Date: Tue, 15 Feb 2005 16:29:34 +0200

I think asymmetric scenarios can be interesting in some
cases. But I would recommend discussing the specific
problems in the context that they came up.

For instance, we are discussing in MOBIKE WG on whether
the two peers must always use the same pair of addresses
or if they can end up using different addresses due to
failures or movements. The answer to this question
has a lot to do with the complexity of the failure
detection and address pair decision algorithms; this
is quite specific to MOBIKE.

I have seen Yoav's cluster scenario pop up several
times, so it looks like a valid requirement. But
exactly how that should be solved (separate gateways
or not) and whether current specifications need
some enhancement for this is something that the
IPsec WG should discuss. (There's perhaps a meta-issue
of how IPsec architecture and IKE maintenance will
happen in the future, if the IPsec WG is shut down
as predicted. But that's a general procedural issue,
and not specific to asymmetry.)

--Jari