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

["Daniel Migault" <[e-mail]>]

Hi,

Here are my comments on the draft. I tried to sum up the exchange I had with
Nico.

The is the diff file between the commented draft and the original draft. The
commented draft is attached.

1c1
< 
---
>
56,57c56
<
<
---
> 
113,114c112
<
<
---
> 
159,180d156
<
< 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:
<
< IPsec has been designed according to the layered model, and thus leading
the packet treatment to an independent layer. The IPsec layer has three
types of databases, the SAD, the SPD and the PAD. The SAD is storing the
security material for a specific flow which is usually identified by the
5-tuple (SPI, source address, source port , destination address, destination
port). It is generally in the IPsec stack. The SPD is used to provide the
security policy to be applied to the packet, and thus provides a way to
match the corresponding SA index. The SPD is split between the decorrelated
SPD that is in the IPsec stack and the non-decorrelated SPD that is in the
user land. The PAD is providing means to authenticate the peer. It is also
usually in the user land. In the traditional use of IPsec, the network
administrator configures the non-decorrelated SPD and SAs are derived from
SPD loaded into the kernel and the IKE negotiation protocol usually running
in the user land.
< An administrator might eventually configure manually static SAs, and
change the IKE configuration, but the main idea is to let the IPsec protocol
defining automatically how to secure the flows. So basically the network
layer is IPsec configured once, independently of the applications. On the
other hand considering network configuration by taking into account all
different applications, and all different cases might happen to be a real
headache.
<
< With connection latching in this draft [
draft-ietf-btns-connection-latching-06.txt] and new API defines in [
draft-ietf-btns-abstract-api-01.txt][draft-ietf-btns-c-api-03.txt][
draft-ietf-btns-apireq-01.txt], it is expected that IPsec will take more
easily the application requirements into account, and will eventually favor
the deployment of applications that requires security, like iSCSI.
<
< Interactions between application and the IPsec layer described in this
paper enables an application to define what type of IPsec connection it
requires. This is done through a ULP protocol that will need to deal with
the IPsec layer. This ULP is different from the network administrator in the
sense that requests are emitted by applications and not by the network
administrator. In that sense the ULP is considering a new source of IPsec
changes : the applications. Applications can not have the same privilege as
the network administrator in term of IPsec configuration.
<
< 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).
<
<
<
192,193c168
<
<
---
> 
249,250c224
<
<
---
> 
306,307c280
<
<
---
> 
363,364c336
<
<
---
> 
420,421c392
<
<
---
> 
477,478c448
<
<
---
> 
529,559d498
<
< The considered model can be thus represented by the figure below:
<
<   +--------------------------------------------+
<   |   APPLICATION Layer                        |
<   |  ,---------------------.                   |
<   | (  SPD_non decorrelated )                  |
<   |  ,---------.-----------'                   |
<   | (  IKE conf )<-+  ^  +-----+ +-----------+ |
<   |  ,---------.   +--+->| IKE | |Application| |
<   | (  PAD      )<-+     +-----+ +-----------+ |
<   |  `---------'          ^^  ^            ^   |
<   +-----------------------||--|------------|---+
<   |   ULP Layer           ||  +---------+  |   |
<   +-----------------------||------------|--|---+
<   |   IPsec Layer         v|            v  v   |
<   |+-------+     ,---------|-------.    ,--.   |
<   ||ESP/AH |<-->(  SAD     v        )  ( LD )  |
<   |+-------+ |   ,-----------------.    `--'   |
<   |   ^      |->(  SPD_decorrelated )     ^    |
<   |   |      |   ,-----------------.      |    |
<   |   |      +->(  SPD_ULP_driven   )<----+    |
<   |   v          `-----------------'           |
<   +--------------------------------------------+
<   |   IP Layer                                 |
<   +--------------------------------------------+
<
<
<  IKE is represented at the application layer. It has its configuration
file as well as the non-decorrelated SPD and the PAD. Connection latching
objects are stored into the LD within the IPsec layer. IPsec protocols
(AH/ESP) are using the SAD, as well as the correlated SPD and the ULP driven
SPD. Note that the effective SPD is composed of the non decorrelated SPD and
the ULP  driven SPD since the decorrelated SPD is derived from the
non-decorrelated SPD.
<
<
565,566c504
<
<
---
> 
576c514
<    The ULP interfaces to the IPsec LD database are as follows:
---
>    The ULP interfaces to the IPsec PAD database are as follows:
622,623c560
<
<
---
> 
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.
<
<
<
< The State diagram with functions can be represented by the figure below:
< [I removed mine]
<
<
691,692c616
<
<
---
> 
748,749c672
<
<
---
> 
805,806c728
<
<
---
> 
854,855d775
<
<
864,865c784
<
<
---
> 
921,922c840
<
<
---
> 
955,991d872
<  4. Interaction between LD and other IPsec Databases
<
<  This section aims at defining :
<     - How modifications on LD impact IPsec Databases
<     - How modifications on IPsec databases impact the LD.
<
< As mentioned in [rfc 4301] considered IPsec database are SAD,
non-decorrelated SPD, decorrelated SPD, and PAD. This paper is adding a new
type of SPD, the ULP driven SPD, which contains the policies generated by
the ULP.
<
< From the figure 1 in the Introduction section, a few rules have to be
considered.
<    - ULP can only modify the ULP driven SPD (or eventually the non
decorrelated SPD  -- depending on the implementation)
<    - ULP can by no way modify the decorrelated SPD. Otherwise changes will
be persistent to crash.
<    - An SPD look up is a lookup in the ULP driven SPD, then in the
decorrelated SPD, and at last in the non-decorrelated SPD. This enables to
see the SPD changes generated by the connection latching object first and
then the SP set by the network administrator.
<
<
< 4.1 Modification of LD
<
< A modification of the LD is considering the following cases :
<
<     - Creation of a connection latching object
<     - Suspending a connection latching object
<     - Closing a connection latching object
<
< There are two kinds of connection latching objects : listener and non
listener connection latching object. Creation of listener connection
latching object requires only a lookup to the LD to avoid duplicate
listener. No other lookup to any other IPsec database is required.
<
< We will then consider in the following section only non-listener
connection latching objects.
<
< When a latching object is created, a lookup occurs in the SAD to check
whether or not SA have already been created. If a match occurs connection
latching object goes into the BROKEN state and then CLOSE state. If no match
is found in the SAD, then a SPD lookup occurs to check whether or not the
connection latching object matches the security policies. If the requested
security parameters matches security rules defined in the SPD, then the SP
is being added by the ULP into the SPD (SPD ULP-driven), and a new SA is
being added. If no matche is found in the SPD, the connection latching goes
into the SUSPEND state until an agreement between the security policies in
the SPD and  the connection latching object security request is found. If no
agreement is found a timeout will put the connection latching object into
the the CLOSE state.
<
< When a connection latching object is going into the CLOSE state all its
SPs, SAs previously created by the connection latching object (and only
those ones) are removed from the SAD and SPD.In fact SAs should only be
removed from the SAD when corresponding SPD entries are removed.  It is not
necessarily the case that removing a latch will cause associated SAs to be
removed from the SAD.  E.g., if a
< persistent SPD entry exists that matches the latch's 5-tuple then there's
not need to remove SAs from the SAD when the latch is closed --those SAs
will continue to be allowed by/needed for existing, persistent IPsec policy.
<
< The reverse is also true: creation of a latch does not necessarily cause
< SAs to be immediately added to the SAD -- it MAY cause the KE to begin,
< and if not the ULP's eventual sending of a packet on that latch's
< 5-tuple will, and when KE completes the resulting child SAs (if KE
< succeeds) will be added to the SAD. [Nico]
<
993d873
< 4.2 Modification of IPsec databases
995d874
< The considered case is a modification of the SPD or the SAD, that would
affect a connection latching object in a ESTABLISHED state.
997,1003d875
< When the non decorrelated SPD is being updated, the decorrelated SPD is
being recomputed. The latch manager must check if there is any contradiction
with the ULP driven SPD. If there is contradiction there are two possible
solutions:
<    - The ULP driven SPD is not changed and so overrides the SPD.
<    - The SPD overrides the established connections the latch manager must
suspend or close the established connection.
<
< If the ULP driven SPD overrides the SPD, new SP in the ULP driven SPD
might be written in order to minimize the override effect, and to make the 5
tuple matches only thoses of the the current established flow. A similar
operation must be done in the SAD.
<
< Further, connection latching really only modifies the SPD when the SPD is
not compatible with the requested latch's parameters (e.g., a BYPASS entry
exists when the application wants protection) *and* the request is allowed
given the application's privilege.  Otherwise no change to the SPD is
required, but then the latch manager must respond to modifications to or
modification of that matching SPD entry. [Nico]
1024,1025c896
<
<
---
> 
1081,1082c952
<
<
---
> 
1138,1139c1008
<
<
---
> 
1195,1196c1064
<
<
---
> 
1252,1253c1120
<
<
---
> 
1309,1310c1176
<
<
---
> 
1366,1367c1232
<
<
---
> 
1423,1424c1288
<
<
---
> 
1480,1481c1344
<
<
---
> 


-- 
Daniel Migault
Orange Labs / Security Lab
[phone]
[phone]

_______________________________________________