Re: [IPsec] IPsec Digest, Vol 53, Issue 3

[Keith Welter <welterk at us.ibm.com>]

Thanks Yoav.  I have a couple more questions inline below.

> Hi Keith
> 
> On Sep 3, 2008, at 12:34 AM, Keith Welter wrote:
> 
> > Suppose the initiator sends an SA payload that contains both an AH 
> > and ESP proposal.  Before receiviFrom ipsec-bounces at ietf.org  Thu Sep  4 10:23:10 2008
Return-Path: <ipsec-bounces at ietf.org>
X-Original-To: ipsec-archive at megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 739643A6A8F;
	Thu,  4 Sep 2008 10:23:10 -0700 (PDT)
X-Original-To: ipsec at core3.amsl.com
Delivered-To: ipsec at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 8E7B83A6A14
	for <ipsec at core3.amsl.com>; Thu,  4 Sep 2008 10:23:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id sBn5ghlOTLah for <ipsec at core3.amsl.com>;
	Thu,  4 Sep 2008 10:23:08 -0700 (PDT)
Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152])
	by core3.amsl.com (Postfix) with ESMTP id 196793A68C8
	for <ipsec at ietf.org>; Thu,  4 Sep 2008 10:23:08 -0700 (PDT)
Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com
	[9.17.195.106])
	by e34.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m84HNEIn017566
	for <ipsec at ietf.org>; Thu, 4 Sep 2008 13:23:14 -0400
Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id
	m84HNEDq145996 for <ipsec at ietf.org>; Thu, 4 Sep 2008 11:23:14 -0600
Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1])
	by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id
	m84HNEvS000329 for <ipsec at ietf.org>; Thu, 4 Sep 2008 11:23:14 -0600
Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com
	[9.17.195.144])
	by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id
	m84HNET6000326 for <ipsec at ietf.org>; Thu, 4 Sep 2008 11:23:14 -0600
In-Reply-To: <mailman.78.1220468406.17986.ipsec at ietf.org>
To: ipsec at ietf.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Keith Welter <welterk at us.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on Keith Welter/Raleigh/IBM(Release
	7.0 HF277|June 21, 2006) at 09/04/2008 10:23:10 AM,
	Serialize by Notes Client on Keith Welter/Raleigh/IBM(Release 7.0
	HF277|June 21, 2006) at 09/04/2008 10:23:10 AM,
	Serialize complete at 09/04/2008 10:23:10 AM,
	S/MIME Sign failed at 09/04/2008 10:23:10 AM: The cryptographic key was
	not found,
	Serialize by Router on D03NM118/03/M/IBM(Build V85_07222008NPHF42 |
	August 5, 2008) at 09/04/2008 11:23:14,
	Serialize complete at 09/04/2008 11:23:14
Message-ID: <OFDF869DDB.06089625-ON882574BA.005CEE16-882574BA.005F82AF at us.ibm.com>
Date: Thu, 4 Sep 2008 10:23:13 -0700
Subject: Re: [IPsec] IPsec Digest, Vol 53, Issue 3
X-BeenThere: ipsec at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ipsec>
List-Post: <mailto:ipsec at ietf.org>
List-Help: <mailto:ipsec-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request at ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1701435515=="
Sender: ipsec-bounces at ietf.org
Errors-To: ipsec-bounces at ietf.org

This is a multipart message in MIME format.

Thanks Yoav.  I have a couple more questions
inline below.

> Hi Keith
> 
> On Sep 3, 2008, at 12:34 AM, Keith Welter wrote:
> 
> > Suppose the initiator sends an SA payload that contains both
an AH  
> > and ESP proposal.  Before receiving the response, the initiator
 
> > decides to close the half-open child SA.  I assume that
the  
> > informational request should include two delete payloads, one
for AH  
> > and one for ESP.  Is that correct?
> 
> There's no such thing as a half-open Child SA. What you describe is
a  
> proposal that the initiator still hasn't received a reply for. There
 
> is no SA yet, at least on the initiator side. In fact the initiator
 
> cannot know at this point whether or not an SA is even going to be
 
> established, because the peer may reject the proposal, or else may
 
> have rebooted.
I'm curious why you say there's no such thing as a
half-open child SA.
If an implementation creates the child SA state in
the process of
sending the CCSA request then it seems like that it
would be reasonable
to call this child SA half-open until the CCSA response
is received.
RFC 4306 section 2.6 uses the term "half-open"
to describe IKE SAs so
I'm confused why the same term couldn't be applied
to a child SA.
Are you implying that an implementation should not
create any child SA
state until the CCSA response is received?

> 
> For this reason, it is not appropriate at this point to begin  
> constructing the Informational message with the DELETE payloads, as
 
> this message will be nonsensical if the CCSA request is rejected.
 
> Instead, the initiator must wait until a response is received. Then
it  
> can either (1) do nothing, if the request was rejected or (2) delete
 
> the one SA that actually got created.
> 
> Doing it as you propose, would definitely result in a DELETE message
 
> for a non-existing SA, which is bad, although I don't see any text
in  
> RFC 4306 or 4306bis about what action the responder should take when
 
> it receives such a request. It's probably not delete-the-ike-sa bad,
 
> but still something you shouldn't do.
Ok, thanks for the clafication.

> 
> > Related to that question, I don't see a requirement that all
 
> > proposals in an SA payload have the same SPI.  So, in this
example,  
> > it would be permissible for the AH and ESP proposals to have
 
> > different SPIs.  Is that correct?
> 
> Yes, that's correct. The SA payload is ready to offer protocols of
 
> variable SPI size, so while both AH and ESP use a 4-byte SPI, maybe
 
> someday we'll have superESP with an 8-byte SPI. In that case, an SA
 
> payload with two proposals, one for AH and the other for superESP
 
> would have to have different SPIs. As it is, it's still possible to
 
> use different values, but it's not a requirement.
Ok, I want to probe a little deeper here.  RFC
4301 section 4.1 says:
   "For
an SA used to carry unicast traffic, the Security Parameters
   Index (SPI) by itself suffices to specify an SA.  (For information
on
   the SPI, see Appendix
A and the AH and ESP specifications
[Ken05b,
   Ken05a].)  However, as a local matter, an implementation may
choose
   to use the SPI in conjunction with the IPsec protocol type (AH
or
   ESP) for SA identification."
Suppose an implementation choses to use the SPI in
conjunction with
the IPsec protocol for IPsec SA identification.  Such
an implementation
could have multiple IPsec SAs with the same SPI but
different protocols.
It seems like this could cause interoperability problems
if these SAs
are negotiated with a peer that uses only the SPI
for SA
identification.  If that assumption is correct,
it seems like an 
implementation should avoid using the same SPI, differentiated
only by
protocol, with a given peer.  In other words,
if an implementation
uses SPI x for an ESP SA it should not attempt to
use SPI x for an AH
SA with the same peer simultaneously.  Would
you agree?
_______________________________________________
IPsec mailing list
IPsec at ietf.org
https://www.ietf.org/mailman/listinfo/ipsec