Re: [Gen-art] Gen-art review of draft-ietf-btns-connection-latching-08.txt

[Nicolas Williams <[e-mail]>]

On Tue, Feb 24, 2009 at 04:31:00PM +0000, Elwyn Davies wrote:
> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Thanks you for your review and comments.  Replies to the API issues are
below.  I'll reply to the other issues separately.

> Summary:
> Not ready.  I don't have any problems with the latching concept and how
> it is set out here.  I think the major concern is that the draft seems
> to be saying that it is addressing the application API needed to support
> the connection whereas it only addresses linkage between the ULP and
> IPsec within the protocol stack.  If I understand correctly it is
> effectively supporting the real application API defined in
> draft-ietf-btns-abstract-api, but this is only mentioned in the very
> last lines of the draft, and there is no apparent attempt to coordinate
> with that draft.  At the moment that draft is in a very rudimentary
> form, and I feel that it would be extremely premature to turn this draft
> into an RFC: of course the WG and the ADs may have different ideas, in 
> which case their views will prevail.

I've answered the concern about the API separately:

 - In a reply to Chris Newman:

|I tend to agree, but note that lack of abstract APIs and programming
|language bindings hasn't stopped TLS nor SASL.
|
|Also, IMO there's enough of a sketch of an abstract API in this draft
|now.
|...
|
|I don't think this I-D should wait for an API I-D.


 - In a reply to Cullen Jennings:

|Solaris already has connection latching today.  It requires no APIs to
|use because it does it by default.  There are APIs available, but they
|are not complete enough.
|
|Solaris does not comply entirely because it only latches IPsec policy
|and does not latch IKE IDs (but it could).

I.e., it's not necessary to have an API in order to benefit from
connection latching.

It's necessary to have an API in order to:

 - do channel binding to IPsec
 - use IPsec for authentication (i.e., use the IDs authenticated by IKE
   for application purposes)

I should add that there are references in the I-D to both, proposed and
actual connection latching APIs.  If the IESG or IETF agree we could
always turn the reference to [I-D.ietf-btns-abstract-api] into a
normative reference and then we could let this I-D block on that (but I
don't think this is necessary).

> In relation to coordination I think that it is necessary to examine
> more closely how the application and the ULP work together to control
> and integrate with the IPsec component - at the moment there are some
> rather vague statements that indicate that the application will get some
> notification even when the ULP is doing the active control of the
> connection.

That's an API issue.

> Major issues
> General: The abstract claims that the draft abstractly  defines how to
> interface ULPs *and applications* to IPsec.  Para 3 of s1 seems to imply
> that we should expect to see here defined an abstract interface that
> could be converted into a implementation that an *application* could use
> to control/monitor the usage of IPsec in creating 'channels'.  In

It was not my intention to imply that this I-D provides an abstract API
for applications, but it does actually outline what it looks like in
that there are plenty of requirements for what such an API must provide.

> actuality, the interfaces that are defined are linkages between the ULPs
> in the kernel and the IPsec implementation in the kernel.  It is not

Interfaces for applications are described, just not in as much detail as
the interfaces between the ULPs and IPsec key management.

There's a good reason for this: this I-D focuses on correctness of the
connection latching concept, and that requires a focus on the interfaces
between ULPs and IPsec.  The application APIs follow from the
requirements in the I-D, but the actual specification of application
APIs is left for a different document.

> clear how this would be extended to the application itself, although
> some of the definitions imply that the notifications will be propagated
> to the application and the latch creation functions pass security
> parameters to the latch machine.  The existing (basic) socket AP doesn't
> provide any help here. The implication is that the semantics of some of
> the socket interface will be extended, but I believe this draft misses
> its avowed aim of defining/improving the API for *applications* to make
> use of IPsec.  But then I read right to the end and find that maybe this
> isn't the aim after all, but just to support the main API  document in
> draft-ietf-btns-abstract-api.  It maybe that coordination with this
> draft (and more mention of it) is what is needed.

Solaris has a socket option interface to connection latching.  This
shows that a a socket-based connection-latching API is feasible.  See
the [IP_SEC_OPT.man] reference.

Nico
--