[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IBM VPN Bakeoff Issues



Tim,


<excerpt>In response to some of the list of issues and questions raised
at the IBM VPN interoperability workshop:


> 9. Should the order of protocols dictate the order of security

> association or should AH, ESP, IPComp always be processed in a

> certain order?  Most vendors agreed with the latter


If we consider that a fixed order is assumed, and that we will never
support ESP and ESP, there are only 4 kinds of bundles possible:
IPCOMP+ESP, IPCOMP+AH, ESP+AH, and IPCOMP+ESP+AH.


</excerpt>The arch doc limits the combinations of protocols that MUST
be supported, and specifies explicit ordering for the transport mode
combination of AH+ESP.  (ICOMP must be applied first, as Roy noted, and
it's not intrinsic to IPsec, so it is not called out explicitly.)
Nested transport or iterated tunnel mode options are not supported,
except as explicitly defined in section 4.5, because implementors
complained about the complexity of supporting such combinations and
because nobody felt there was a legitimate requirement for them. 


<excerpt>

We should conceptually think of bundles as a single SA that provides
multiple services. This means that all three services expire at the
same time and are re-keyed at the same time. Further, when being
negotiated, they all functionally use the same encapsulation (even
though implementations may consider the outer headers as always being
in transport mode). This means that a gateway always offers tunnel mode
for all three services, since the bundle as a whole is in tunnel mode.

</excerpt>

<excerpt>The SAs that make up a bundle are intended to provide a
unified set of services for the traffic associated with the bundle, so
I agree that one ought to terminate the whole bundle at the same time. 
In practice, it may be best to do this via purely local mechanisms.

</excerpt>

<excerpt>Therefore, for the current version version of IPSec, make the
following statements:


1) The order of application of services, from inner header to outer,
MUST be IPCOMP, ESP and AH when more than one service is present.

</excerpt>

This certainly applies for transport mode.  For tunnel mode, use of
both AH and ESP is not currently supported in SAs with the same
endpoints.  One can have tunnels terminating at different endpoints,
but then the ordering is determined by the termination points for the
SAs.


<excerpt>2) The encapsulation mode of all services offered MUST match
that encapsulation mode of the bundle as a whole.

</excerpt>

As noted above, this is currently required for transport, and not
applicable to tunnel mode, but future inclusion of iterated tunnels
(with common endpoints) could benefit from a convention of this sort,
if no further IKE enhancements arise to clarify the ordering.  However,
we should still ask what benefit arises from these configurations.


<excerpt>

3) The order of the services in the ANDed offer is not required to be
any particular order. Responders may change the order when selecting
the bundle.


4) The entire bundle expires when any one of the services within the
bundle expires.


For IPSecond:


In order to reduce any ambiguity of implementation, I would suggest
that we consider picturing these four combinations as their own
protocols, with a single header that contains only the necessary
information: 1 SPI, one sequence number, one next header field and one
payload length field, each formatted based on the services it
provides.

</excerpt>

Whoa!  This is a major architectural change.  Remember that we elected
not to call for support of arbitrary combinations and nesting because
nobody had good reasons to construct such combinations.  Unless the
thinking on this has evolved, along with good exaples of why this is
needed, why are we proposing such a radical change?



<excerpt>


A closer examination suggests that this 'super' header could be
identical to the AH protocol header, since it already is a superset of
the header information of all other headers.


    0                   1                   2                   3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   | Next Header   |  Payload Len  |          RESERVED             |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                 Security Parameters Index (SPI)               |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                    Sequence Number Field                      |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                                                               |

   +    Authentication Data (variable, 0 for IPCOMP+ESP)           |

   |                                                               |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


The advantages of the use of this header are:

 1) reduced ambiguity about application and negotiation of services.

 2) reduced network bandwidth.

 3) possible reduction in packet servicing time.

</excerpt>

This header structure has a disadvantage too, i.e., by placing the auth
data up front, streaming doesn't work.  Given the likely pressure for
increased performance in IPsec gateways, I'd be very reluctant to make
such a change. Also, this header exposes the next protocol data, which
ESP does not.  For AH this is not an issue, but it may be for some ESP
users.  Also, this header is not quite accurate, in that it omits the
trailer data needed for padding, including the pad length field.


Steve

References: