Subject: [IPsec] Inconsistent usage of SA

From: "Gunduzhan, Emre" <[email-masked]>
Date: Fri, 22 May 2009 10:11:26 -0400

Greetings,

I am new to this group, so I hope I am not raising an issue which was addressed earlier. I was reading draft-ietf-ipsecme-ikev2bis, and I came across some inconsistent terminology which I believe also exists in RFC 4306.

RFC 4301 defines a SA as a simplex "connection", and states that (section 4.1):
"To secure typical, bi-directional communication between two IPsec-enabled systems, a pair of SAs (one in each direction) is required. IKE explicitly creates SA pairs in recognition of this common usage requirement."

However in an example scenario in section 2.9.1 of draft-ietf-ipsecme-ikev2bis, it seems that an SA can be used to carry traffic in both directions:
" Suppose that host A has a policy whose effect is that traffic to 192.0.1.66 is sent via host B encrypted using AES, and traffic to all other hosts in 192.0.1.0/24 is also sent via B, but must use 3DES.  Suppose also that host B accepts any combination of AES and 3DES.

 If host A now proposes an SA that uses 3DES, and includes TSr containing (192.0.1.0-192.0.1.255), this will be accepted by host B. Now, host B can also use this SA to send traffic from 192.0.1.66, but those packets will be dropped by A since it requires the use of AES for those traffic.  Even if host A creates a new SA only for 192.0.1.66 that uses AES, host B may freely continue to use the first SA for the traffic.  In this situation, when proposing the SA, host A should have followed its own policy, and included a TSr containing ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead."

Because of the same issue, when RFC 4306 or draft-ietf-ipsecme-ikev2bis talks about creating an IKE SA, this would imply that the IKE SA would be a simplex "connection". Similarly, it is not clear from RFC 4306 or draft-ietf-ipsecme-ikev2bis whether a CREATE_CHILD_SA exchange (or, the initial IKE_AUTH exchange) creates a single SA, i.e. a simplex "connection", or a pair of SAs.

Can someone please clarify which usage is correct? Would the workgroup consider resolving this ambiguity in the revision to IKEv2?

Thanks and best regards,
Emre

--
Emre Gunduzhan, Ph.D
The Johns Hopkins University Applied Physics Laboratory
Applied Information Sciences Department
Communication and Networking Systems Group (VCS)

---

From: Raj Singh <[email-masked]>
Date: Mon, 25 May 2009 08:38:49 +0530

Hi Emre,

IKE SA is bi-directional i.e. one SA is used in both directions, initiator
to responder and responder to initiator.
CHILD_SAs i.e. IPsec SAs (AH, ESP) are uni-directional, one in each
direction. So we 2 IPsec SAs per connection.

Thanks,
Raj

On Fri, May 22, 2009 at 7:41 PM, Gunduzhan, Emre
<[email-masked]>wrote:

>  Greetings,
>
> I am new to this group, so I hope I am not raising an issue which was
> addressed earlier. I was reading draft-ietf-ipsecme-ikev2bis, and I came
> across some inconsistent terminology which I believe also exists in RFC
> 4306.
>
> "To secure typical, bi-directional communication between two IPsec-enabled
> systems, a pair of SAs (one in each direction) is required. IKE explicitly
> creates SA pairs in recognition of this common usage requirement."
>
> However in an example scenario in section 2.9.1 of draft-ietf-ipsecme-ikev2bis,
> it seems that an SA can be used to carry traffic in both directions:
> " Suppose that host A has a policy whose effect is that traffic to
> 192.0.1.66 is sent via host B encrypted using AES, and traffic to all other
> hosts in 192.0.1.0/24 is also sent via B, but must use 3DES.  Suppose also
> that host B accepts any combination of AES and 3DES.
>
>  If host A now proposes an SA that uses 3DES, and includes TSr containing
> (192.0.1.0-192.0.1.255), this will be accepted by host B. Now, host B can
> also use this SA to send traffic from 192.0.1.66, but those packets will be
> dropped by A since it requires the use of AES for those traffic.  Even if
> host A creates a new SA only for 192.0.1.66 that uses AES, host B may freely
> continue to use the first SA for the traffic.  In this situation, when
> proposing the SA, host A should have followed its own policy, and included a
> TSr containing ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead."
>
> Because of the same issue, when RFC 4306 or draft-ietf-ipsecme-ikev2bis
> talks about creating an IKE SA, this would imply that the IKE SA would be a
> simplex "connection". Similarly, it is not clear from RFC 4306 or
> draft-ietf-ipsecme-ikev2bis whether a CREATE_CHILD_SA exchange (or, the
> initial IKE_AUTH exchange) creates a single SA, i.e. a simplex "connection",
> or a pair of SAs.
>
> Can someone please clarify which usage is correct? Would the workgroup
> consider resolving this ambiguity in the revision to IKEv2?
>
> Thanks and best regards,
> Emre
>
> --
>  Emre Gunduzhan, Ph.D
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>

---

From: Stephen Kent <[email-masked]>
Date: Sun, 24 May 2009 21:37:35 -0400

At 10:11 AM -0400 5/22/09, Gunduzhan, Emre wrote:
>Content-Language: en-US
>Content-Type: multipart/alternative;
> 
>	boundary="_000_068F06DC4D106941B297C0C5F9F446EA3CB241D203aplesstripedo_"
>
>Greetings,
>
>I am new to this group, so I hope I am not raising an issue which 
>was addressed earlier. I was reading draft-ietf-ipsecme-ikev2bis, 
>and I came across some inconsistent terminology which I believe also 
>exists in RFC 4306.
>
>"To secure typical, bi-directional communication between two 
>IPsec-enabled systems, a pair of SAs (one in each direction) is 
>required. IKE explicitly creates SA pairs in recognition of this 
>common usage requirement."
>
>However in an example scenario in section 2.9.1 
>of draft-ietf-ipsecme-ikev2bis, it seems that an SA can be used to 
>carry traffic in both directions:
>192.0.1.66 is sent via host B encrypted using AES, and traffic to 
>all other hosts in 192.0.1.0/24 is also sent via B, but must use 
>3DES.  Suppose also that host B accepts any combination of AES and 
>3DES.
>

4301 is correct. Sometimes folks refer to the pair of SAs that IKE 
always creates as an SA, but that is not the correct terminology.

Steve

---

From: "Gunduzhan, Emre" <[email-masked]>
Date: Tue, 26 May 2009 09:08:40 -0400

Steve,

Thanks for the clarification. So, at the end of the initial IKE_AUTH exchange, there will (typically) be a pair of CHILD SAs created, one in each direction, is this correct? That is, you never create a single SA by IKE_AUTH or CREATE_CHILD_SA, and create another SA in the other direction by a subsequent CREATE_CHILD_SA?

This is really ambiguous in RFC 4306 (at least to me) and would be great if it can be clarified in the revised version.

Thanks,
Emre

________________________________

 From: Stephen Kent [mailto:[email-masked]]
Sent: Sunday, May 24, 2009 9:38 PM
To: Gunduzhan, Emre
Cc: [email-masked]
Subject: Re: [IPsec] Inconsistent usage of SA

4301 is correct. Sometimes folks refer to the pair of SAs that IKE always creates as an SA, but that is not the correct terminology.

Steve

---

From: Raj Singh <[email-masked]>
Date: Tue, 26 May 2009 19:52:42 +0530

Hi Emre,

On Tue, May 26, 2009 at 6:38 PM, Gunduzhan, Emre
<[email-masked]>wrote:

>  Steve,
>
> Thanks for the clarification. So, at the end of the initial IKE_AUTH
> exchange, there will (typically) be a pair of CHILD SAs created, one in each
> direction, is this correct?
>
 Yes.

> That is, you never create a single SA by IKE_AUTH or CREATE_CHILD_SA, and
> create another SA in the other direction by a subsequent CREATE_CHILD_SA?
>
 We create a pair of SA, one for inbound and one for outbound traffic. These
SAs will be uniquely identified on the peer by inside SPI and outside SPI.
The inside SPI on one peer will the outside SPI on other peer and vice
versa.
Yes, we create a pair of SA using CREATE_CHILD_SA. Also, CREATE_CHILD_SA is
used for REKEY of IKE SA, only in that case CREATE_CHILD_SA will create
single SA.

>
> This is really ambiguous in RFC 4306 (at least to me) and would be great if
> it can be clarified in the revised version.
>
> Thanks,
> Emre
>
Thanks,
Raj

>
>
>  ------------------------------
>
>
>  *From:* Stephen Kent [mailto:[email-masked]]
> *Sent:* Sunday, May 24, 2009 9:38 PM
> *To:* Gunduzhan, Emre
> *Cc:* [email-masked]
> *Subject:* Re: [IPsec] Inconsistent usage of SA
>
> of draft-ietf-ipsecme-ikev2bis, it seems that an SA can be used to carry
> traffic in both directions:
>
> 4301 is correct. Sometimes folks refer to the pair of SAs that IKE always
> creates as an SA, but that is not the correct terminology.
>
> Steve
>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 26 May 2009 09:36:36 -0400

At 9:08 AM -0400 5/26/09, Gunduzhan, Emre wrote:
>	boundary="_000_068F06DC4D106941B297C0C5F9F446EA3CB241D43Faplesstripedo_"
>
>Steve,
>
>exchange, there will (typically) be a pair of CHILD SAs created, one 
>in each direction, is this correct?

yes.

>That is, you never create a single SA by IKE_AUTH or 
>CREATE_CHILD_SA, and create another SA in the other direction by a 
>subsequent CREATE_CHILD_SA?

yes.

>
>This is really ambiguous in RFC 4306 (at least to me) and would be 
>great if it can be clarified in the revised version.
>
>Thanks,
>Emre
>
>