Subject: [IPsec] I-D ACTION:draft-ietf-ipsecme-ikev2bis-10.txt

From: [email-masked]
Date: Wed, 14 Apr 2010 15:15:04 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF.

	Title		: Internet Key Exchange Protocol: IKEv2
	Author(s)	: C. Kaufman, P. Hoffman, Y. Nir, P. Eronen
	Filename	: draft-ietf-ipsecme-ikev2bis-10.txt
	Pages		: 130
	Date		: 2010-4-14
	
This document describes version 2 of the Internet Key Exchange (IKE)
   protocol.  IKE is a component of IPsec used for performing mutual
   authentication and establishing and maintaining security associations
   (SAs).  This document replaces and updates RFC 4306, and includes all
   of the clarifications from RFC 4718.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2bis-10.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Sean Turner <[email-masked]>
Date: Wed, 14 Apr 2010 19:57:37 -0400

> implementation to automatically retrieve the ASCII version of the

I added this ID to the May 6th IESG telechat.  I would have added it to 
the 4/22 agenda, but there are already 20+ documents on the agenda.

spt

---

From: "V Jyothi-B22245" <[email-masked]>
Date: Thu, 22 Apr 2010 12:28:46 +0530

Hi,

In section 2.9.  Traffic Selector Negotiation,

The SINGLE_PAIR_REQUIRED error indicates that a CREATE_CHILD_SA
   request is unacceptable because its sender is only willing to accept
   traffic selectors specifying a single pair of addresses.  The
   requestor is expected to respond by requesting an SA for only the
   specific traffic it is trying to forward.

Above paragraph gives the clarity of what action to take when
SINGLE_PAIR_REQUIRED notify type received in case of CREATE_CHILD_SA
exchanges.

Suppose if the SINGLE_PAIR_REQUIRED notify type is received in AUTH
response, how initiator should act upon it?
Can initiator resend AUTH request with different TSi and TSr payloads or
it should establish IKE SA and then start CREATE_CHILD_SA exchange?

Thanks
Jyothi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Thursday, April 15, 2010 3:45 AM
To: [email-masked]
Cc: [email-masked]
Subject: [IPsec] I-D ACTION:draft-ietf-ipsecme-ikev2bis-10.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the IP Security Maintenance and Extensions
Working Group of the IETF.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 22 Apr 2010 14:09:12 +0300

> it should establish IKE SA and then start CREATE_CHILD_SA exchange?

It will establish IKE SA even when the Child SA creation failed.

What it does next depends on the implementation. Normal implementation
will simply do CREATE_CHILD_SA with better traffic selectors, and
create Child SA that way. Some implementation might simply mark the
specific rule so that it requires exact traffic selectors, and wait
for next packet hitting that rule before starting CREATE_CHILD_SA
(this is needed if the first Child SA creation in the IKE_AUTH was
done because of auto-start rule, i.e. there is no traffic yet, thus
the initiator does not know the exact traffic selectors).
-- 
[email-masked]

---

From: "V Jyothi-B22245" <[email-masked]>
Date: Thu, 22 Apr 2010 18:12:27 +0530

Hi,

I find an issue in case of minimal implementations.
Minimal implementations may not support CREATE_CHILD_SA exchanges, CHILD
SA gets created as part of AUTH exchange.

In this case, if the responder sends SINGLE_PAIR_REQUIRED, minimal
implementations cannot start CREATE_CHILD_SA exchange and minimal
implementation should not establish IKE SA because CHILD SA is not yet
established and it may not be right solution to maintain the
SINGLE_PAIR_REQUIRED notify reception information to use it in new IKEv2
exchange.
Instead initiator can try sending AUTH request with single traffic
selectors.

Thanks
Jyothi

-----Original Message-----
From: Tero Kivinen [mailto:[email-masked]] 
Sent: Thursday, April 22, 2010 4:39 PM
To: V Jyothi-B22245
Cc: [email-masked]
Subject: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-ikev2bis-10.txt

V Jyothi-B22245 writes:
> Can initiator resend AUTH request with different TSi and TSr payloads 
> or it should establish IKE SA and then start CREATE_CHILD_SA exchange?

What it does next depends on the implementation. Normal implementation
will simply do CREATE_CHILD_SA with better traffic selectors, and create
Child SA that way. Some implementation might simply mark the specific
rule so that it requires exact traffic selectors, and wait for next
packet hitting that rule before starting CREATE_CHILD_SA (this is needed
if the first Child SA creation in the IKE_AUTH was done because of
auto-start rule, i.e. there is no traffic yet, thus the initiator does
not know the exact traffic selectors).
--
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Thu, 22 Apr 2010 16:01:09 +0300

Hi.

It's true that the standard is more geared to full implementations than those minimal implementations, but in this case there really is no solution.

The minimal implementation can delete the IKE SA that was created and start fresh with a single pair. But since the responder is also not fully-functional - it cannot handle complex selectors - there is no way that you can get to a state where you cover all the selectors in the initiator's policy. The responder requires multiple SAs, while the initiator requires just one for the same policy.

On Apr 22, 2010, at 3:42 PM, V Jyothi-B22245 wrote:

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Scanned by Check Point Total Security Gateway.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 22 Apr 2010 16:15:19 +0300

> SA gets created as part of AUTH exchange.

Minimal implementation most likely do not understand
SINGLE_PAIR_REQUIRED either, so it will most likely simply get the IKE
SA up, and then delete it as it does not have any useful things to do
with it. 

> SINGLE_PAIR_REQUIRED notify reception information to use it in new IKEv2

Even the minimal implementation is required to set up the IKE SA even
when the Child SA exchange in the IKE_AUTH failed:
----------------------------------------------------------------------
1.2.  The Initial Exchanges
...
   If creating the Child SA during the IKE_AUTH exchange fails for some
   reason, the IKE SA is still created as usual.  
----------------------------------------------------------------------

So the IKE SA is up, but the next question is what the minimal
implementation can do next. If it does not support CREATE_CHILD_SA and
it does not have Child SA up, it will most likely tear down the IKE SA
by sending delete notification. If it is really minimal
implementation, then it most likely does not have any special handling
for SINGLE_PAIR_REQUIRED, and it might not even support such traffic
selectors (or they might not be allowed by policy), so most likely
some kind of policy change is required before it can connect to the
server.

In this case the IKEv2 does not always fix mismatched policy
situations automatically, and policy needs to be changed manually. I
do not consider this a problem. 

> Instead initiator can try sending AUTH request with single traffic

If it does that, it needs to start from the beginning i.e. from
IKE_SA_INIT as the previous IKE SA is already up and running, and it
cannot have any more IKE_AUTH exchanges, as one of them is already
finished. 
-- 
[email-masked]