Re: [anonsec] Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt)

Black_David@emc.com Tue, 08 January 2008 22:43 UTC

Return-path: <anonsec-bounces@postel.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCNAB-0002Yd-9F for btns-archive-waDah9Oh@lists.ietf.org; Tue, 08 Jan 2008 17:43:15 -0500
Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCNAA-0001lU-6z for btns-archive-waDah9Oh@lists.ietf.org; Tue, 08 Jan 2008 17:43:15 -0500
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m08MX8Ao027717; Tue, 8 Jan 2008 14:33:09 -0800 (PST)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m08MVodx027436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <anonsec@postel.org>; Tue, 8 Jan 2008 14:31:51 -0800 (PST)
Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m08MVmmH016871; Tue, 8 Jan 2008 17:31:48 -0500 (EST)
Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor); Tue, 8 Jan 2008 17:31:47 -0500
Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m08MVLTB021657; Tue, 8 Jan 2008 17:31:43 -0500 (EST)
From: Black_David@emc.com
Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jan 2008 17:31:40 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 8 Jan 2008 17:31:39 -0500
Message-ID: <8CC6CEAB44F131478D3A7B429ECACD91085EB3@CORPUSMX20A.corp.emc.com>
In-Reply-To: <20080108211846.GT22538@Sun.COM>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [anonsec] Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt)
thread-index: AchSPBgT47rmKQpST0uH+scIgywjkAACGVhA
References: <8CC6CEAB44F131478D3A7B429ECACD91085EA3@CORPUSMX20A.corp.emc.com> <20080108211846.GT22538@Sun.COM>
To: <Nicolas.Williams@sun.com>
X-OriginalArrivalTime: 08 Jan 2008 22:31:40.0829 (UTC) FILETIME=[3D376CD0:01C85246]
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115
X-PerlMx-Spam: Gauge=, SPAM=1%, Reason='EMC_FROM_0+ -3, NO_REAL_NAME 0, __CP_NAME_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FRAUD_419_REFNUM 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'
X-Tablus-Inspected: yes
X-Tablus-Classifications: public
X-Tablus-Action: allow
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: black_david@emc.com
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m08MVodx027436
Cc: anonsec@postel.org, tsv-dir@ietf.org
Subject: Re: [anonsec] Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt)
X-BeenThere: anonsec@postel.org
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Discussions of anonymous Internet security." <anonsec.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/anonsec>, <mailto:anonsec-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/anonsec>
List-Post: <mailto:anonsec@postel.org>
List-Help: <mailto:anonsec-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/anonsec>, <mailto:anonsec-request@postel.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: anonsec-bounces@postel.org
Errors-To: anonsec-bounces@postel.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cbb41f2dbf0f142369614756642005e3

Nico,

Some quick responses:

> > -- Service Orientation
> > 
> > The introduction considerably undersells the architectural
> > impact of this draft.  [...]
> 
> I agree, ...
> 
> ... but connection latching is one of a multi-prong approach to
closing
> that gap.  The other main prong is IPsec APIs.  A third, optional
prong,
> is channel binding.

Describing this overall multi-prong structure and connection
latching's role in it would be a "good thing" to do in the
introduction and should position the connection latching draft
correctly.

> > -- NATs
> > 
> > p.5 says:
> > 
> >    o  Implementations that provide such programming interfaces
> > 	SHOULD make available to applications any available
> > 	NAT-related information about the peer: whether it is
> > 	behind a NAT and, if it is, the inner and outer tunnel
> > 	addresses of the peer.
> > 
> > Is that serious?  I don't think inflicting NAT awareness on
> > additional protocols and applications is a good idea unless
> > it's absolutely necessary (i.e., protocol/app won't work through
> > a NAT that it doesn't know about).  In general, IPsec NAT
> > traversal ought to work transparently with respect to
> > connection latching, and (IMHO), this transparency should
> > be the preferred approach whenever feasible.
> 
> Well, does it hurt to have this?  I suppose this could be a MAY, if
> implementors object (or it could be downgraded to MAY or removed
> altogether when in the progression to Standard).
> 
> I don't feel too strongly about it, but I also don't feel too strongly
> about discouraging the use of NATs (face it: NATs are here to stay, at
> least in the IPv4 world).

This isn't about discouraging use of NATs; I completely agree
that NATs are a fact of life for IPv4.  This is about avoiding
encouragement of NAT-specific code in protocols and applications
that don't need it (i.e., work just fine with IPsec NAT traversal).

Think of the goal as "damage containment" - it does hurt to
encourage unnecessary attempts to deal with NATs.  It may be ok
to have the interface if the interface adds value to what apps
already have to do to cope with NATs, but there should be a
rationale for the added value.

> > -- Key Manager/Key Management

[... snip ...]

> >              This is the infamous "dangling SAs" issue
> > applied to connection latch state.
> 
> What is this infamous issue?

Does a CHILD_SA survive termination of the IKE_SA used to create
the CHILD_SA?

[... snip ...]

> It is absolutely desirable that connection latch state survive IKE_SA
> and even child SA expiration.
> 
> The document does describe latch termination, but -05 will do 
> so in much more detail.
> 
> Basically a latch terminates when the ULP requests it (which may be
when
> the application requests it, or when an RST is received protected by a
> suitable SA) and, in the normative model, whenever the key manager
adds
> an SA to the SAD which conflicts with the latch.

I think that's ok, just write it up in -05, and explain why the
disconnection from the IKE_SA lifetime/fate is important.  I
was making intelligent guesses in the absence of detail, and I
guessed wrong :-).

Thanks,
--David

> -----Original Message-----
> From: Nicolas Williams [mailto:Nicolas.Williams@sun.com] 
> Sent: Tuesday, January 08, 2008 4:19 PM
> To: Black, David
> Cc: anonsec@postel.org; tsv-dir@ietf.org
> Subject: Re: [anonsec] Connection Latching draft review 
> (draft-ietf-btns-connection-latching-04.txt)
> 
> On Tue, Jan 08, 2008 at 11:22:54AM -0500, Black_David@emc.com wrote:
> > This message is an attempt to kill two review "birds" with
> > one email "stone" - I meant to review the connection latching
> > draft some time ago, and in addition, this is a transport
> > directorate review of the connection latching draft.
> 
> Thank you.
> 
> > -- Service Orientation
> > 
> > The introduction considerably undersells the architectural
> > impact of this draft.  [...]
> 
> I agree, ...
> 
> > The connection latching draft is aimed at precisely this
> > gap between effective application usage and the logical
> > firewall architecture of IPsec; in essence, the draft is
> > defining the functional service interface through which
> > higher layer applications and protocols should be
> > obtaining IPsec services for themselves instead of setting
> > up SPD (and possibly PAD) entries directly.  This change
> > from logical firewall orientation to service orientation is
> > (IMHO) an important step towards making IPsec effectively
> > usable for protocols such as iSCSI and NFSv4, and should
> > be explained in the Introduction of this draft.
> 
> ... but connection latching is one of a multi-prong approach 
> to closing
> that gap.  The other main prong is IPsec APIs.  A third, 
> optional prong,
> is channel binding.
> 
> I fear that to correct this undersell while the IPsec APIs 
> documents are
> not complete might be to oversell the architectural impact of this
> document.
> 
> Comments?
> 
> > -- NATs
> > 
> > p.5 says:
> > 
> >    o  Implementations that provide such programming interfaces
> > 	SHOULD make available to applications any available
> > 	NAT-related information about the peer: whether it is
> > 	behind a NAT and, if it is, the inner and outer tunnel
> > 	addresses of the peer.
> > 
> > Is that serious?  I don't think inflicting NAT awareness on
> > additional protocols and applications is a good idea unless
> > it's absolutely necessary (i.e., protocol/app won't work through
> > a NAT that it doesn't know about).  In general, IPsec NAT
> > traversal ought to work transparently with respect to
> > connection latching, and (IMHO), this transparency should
> > be the preferred approach whenever feasible.
> 
> Well, does it hurt to have this?  I suppose this could be a MAY, if
> implementors object (or it could be downgraded to MAY or removed
> altogether when in the progression to Standard).
> 
> I don't feel too strongly about it, but I also don't feel too strongly
> about discouraging the use of NATs (face it: NATs are here to stay, at
> least in the IPv4 world).
> 
> > -- Key Manager/Key Management
> > 
> > The draft talks about a key manager.  It should state what
> > functions the key manager is performing with respect to the
> > IPsec architecture (RFC 4301).  While IKEv2 would clearly
> > be inside the key manager, where is responsibility for the
> > SPD and PAD placed and/or how is that responsibility divided?
> 
> RFC4301 does not speak of a key manager, but does speak of key
> management -- see section 4.5.  I'll clarify in the I-D, and here: the
> key manager is the part of the implementation that manages 
> the SAD.  The
> KE protocols (IKEv2, KINK, ...) are associated with the key 
> manager, but
> what really matters here is the component of the system through which
> all SAD updates are done.
> 
> > While not exactly key management, how does connection latch
> > state lifetime relate to the lifetime of the IKE_SA for the
> > latched SA?
> 
> It doesn't.
> 
> >              This is the infamous "dangling SAs" issue
> > applied to connection latch state.
> 
> What is this infamous issue?
> 
> >                                     I think that connection
> > latch state does not survive termination without replacement
> > of the IKE_SA (e.g., key management entity containing
> > IKE/IKEv2 implementation crashes), but ought to survive
> > replacement of the IKE_SA.  In any case, this topic needs to
> > be covered.
> 
> It is absolutely desirable that connection latch state survive IKE_SA
> and even child SA expiration.
> 
> The document does describe latch termination, but -05 will do 
> so in much
> more detail.
> 
> Basically a latch terminates when the ULP requests it (which 
> may be when
> the application requests it, or when an RST is received protected by a
> suitable SA) and, in the normative model, whenever the key 
> manager adds
> an SA to the SAD which conflicts with the latch.
> 
> > -- Nits
> > 
> > ----
> > 
> >   == No 'Intended status' indicated for this document; 
> assuming Proposed
> >      Standard
> 
> Thanks.  I'll fix this.
> 
> >   == The copyright year in the IETF Trust Copyright Line 
> does not match
> > the
> >      current year
> 
> It matches the year in which it was submitted.  -05 will be 
> submitted in
> 2008, so its IETF Trust Copyright notice will say "2008."
> 
> >      (See RFC 3967 for information about using normative 
> references to
> >      lower-maturity documents in RFCs)
> > 
> >   == Unused Reference: 'I-D.bellovin-useipsec' is defined 
> on line 632,
> > but no
> >      explicit reference was found in the text
> 
> If I correct the "undersell" then there will definitely be a 
> mention of
> bellovin-useipsec!
> 
> >   == Unused Reference: 'RFC4322' is defined on line 642, 
> but no explicit
> >      reference was found in the text
> 
> Suggestions?
> 
> >   -- Possible downref: Normative reference to a draft: ref.
> >      'I-D.ietf-btns-abstract-api'  (No intended status 
> found in state
> > file of
> >      draft-ietf-btns-abstract-api)
> 
> That should probably be informative, yes.
> 
> >   == Outdated reference: A later version (-06) exists of
> >      draft-ietf-btns-core-05
> > 
> >   == Outdated reference: A later version (-06) exists of
> >      draft-ietf-btns-prob-and-applic-05
> > 
> >   ** Downref: Normative reference to an Informational draft:
> >      draft-ietf-btns-prob-and-applic (ref.
> > 'I-D.ietf-btns-prob-and-applic')
> > 
> >   ** Downref: Normative reference to an Informational RFC: RFC 2367
> > 
> >   == Outdated reference: A later version (-07) exists of
> >      draft-bellovin-useipsec-06
> > 
> >   == Outdated reference: draft-williams-on-channel-binding has been
> > published
> >      as RFC 5056
> 
> Will fix.
> 
> Thanks!
> 
> Nico
> -- 
> 
> 

_______________________________________________