Re: [anonsec] I-D Action:draft-ietf-btns-connection-latching-06.txt

[Nicolas Williams <[e-mail]>]

On Fri, Mar 14, 2008 at 06:53:24AM +0100, Daniel Migault wrote:
> Hi,
> 
> Here are my comments on the draft. I tried to sum up the exchange I had with
> Nico.

Thanks.  My comments follow as well.

> < Although it adds almost nothing to the introduction and it is mainly a
> re-writing of the introduction, it might bring some clarification to the
> paper and to the connection latching concept:

Your proposed new intro text seems to do three things: summarize the
IPsec architecture (RFC4301), restate part of the intro that's already
there and, importantly, restates a constraint that is not clearly stated
in the intro (though it is stated elsewhere).  That constraint is this:
that under no circumstance does connection latching cause persistent
changes to IPsec policy databases.

I don't think it's safe to try to summarize the IPsec architecture here,
so I will not take that text, but I think it's crucial that sa

So I will add text like this:

> < The changes are requested from applications and not from the network
> administrator, which means that the ULP must not systematically overwrite
> the IPsec policies established by the network administrator. For example
> policy requests must not survive to crash, must not establish lower security
> as defined by the network administrator. One way not to survive to crash is
> to disable any modification in the user land.
> <
> < This lead us to consider a new object that will define security rules with
> specific characteristics : the Connection Latching Objects.
> <
> < This document defines :
> <    - What is a connection latching object (Section 2 Introduction).
> <    - The behavior of a latching object (that is to say its state machine
> section 2.1).
> <    - The interface of the Latching object with key managers and ULP
> (section 2.2).
> <    - Interaction between LD and traditional IPsec databases (section 4).

to the intro.

I will also add a sentence to the abstract (I'll also delete a redundant
sentence from the abstract) to the same efffect:

    Connection latching is layered on top of IPsec and does not modify
    the underlying IPsec architecture.

Additionally I'll add text to the security considerations section about
this.  Something like:

   Connection latching adds a new, non-persisting database to IPsec and
   new functionality to the IPsec key manager.  Stripped of all optional
   features, connection latching is really about protecting established
   packet flows from SPD and SAD changes that are not consistent with
   what the application and/or ULP would like.  This protection is
   achieved by tracking latched connections and synchronizing changes to
   the SPD and SAD with alerts to the ULPs that are responsible for
   affected latched connections.

   Excluding all optional features connection latching is simply a
   passive feature bolted to the side of the IPsec key manager.  When a
   connection latch cannot be guaranteed the only action to be taken is
   to synchronously inform the affected ULPs and applications.
   
   Including all optional features connection latching also involves
   dynamic modifications to the "logical SPD," which do not persist
   across reboots nor past the lifetime of latched packet flows, and it
   also optionally involves IKEv2 CHILD SA narrowing.

   That connection latching state never persists beyond the lifetime of
   associated packet flows, nor across events which necessarily
   terminate such state (including reboots), derives from the fact that
   the very state of those packet flows is also non-persistent.

   We believe that this construction of connection latching achieves the
   desired goal -- protecting applications from dynamic IPsec policy or
   too permissive an IPsec policy -- without doing violence to the IPsec
   architecture.

> < The considered model can be thus represented by the figure below:

I like your ASCII art, but I'm going to modify it somewhat.

Following our conversation I think we need to clearly delineate "kernel"
and "user" mode execution, even though it's mostly irrelevant in a
document like this one, because it'd relevant to most implementors; your
figure almost does this.

Also I think the ULP needs to be a box, as should be the key manager.
And rather than refer to decorrelated and non-decorrelated SPD I'd
rather speak of SPD and "logical SPD," where the latter is in the
kernel.  This last change is important because we want to demonstrate
that connection latching, even with all OPTIONAL features, never
modifies persistent IPsec policy.

> <    The ULP interfaces to the IPsec LD database are as follows:
> ---
> >    The ULP interfaces to the IPsec PAD database are as follows:

Good catch.  I'll make it "The ULP interfaces to the key manager ..."

> 648,659d584
> <    The IPsec to ULP interfaces is as follows:
> <
> <    o  POP_MESSAGE(5-tuple, message) -> latch handle
> <
> <          Pop up a message (code) to the ULP.

Yes, I'd described the IPsec->ULP interface rather informally.

I think we want something like:

   o INFORM(5-tuple, BREAK | SUSPEND)

There's no return value for this function.

> < The State diagram with functions can be represented by the figure below:
> < [I removed mine]

Er, could you send it again?

I'll review your "Interaction between LD and other IPsec Databases"
section next.

Thanks!

Nico
-- 
_______________________________________________