Re: SOI QUESTIONS: 2.3 Authentication styles

[Stephen Kent <kent@bbn.com>]

Title: Re: SOI QUESTIONS: 2.3 Authentication styles

At 7:19 PM -0700 6/19/02, Chinna N.R. Pellacuru wrote:

> On Wed, 19 Jun 2002, Stephen Kent
> wrote:
>
> > If the features are all in the same box, and SA information is
> used to
> > maintain the binding between packets and the negotiated SAs, then
> that
> > counts as an IPsec security gateway and we have no argument.
> >
> > Steve
>
> So, the limited 'static packet filtering' in IPsec is optional (if
> the
> binding can be maintained between the data source authentication and
> the
> packet, untill the firewall does the access control
> checks).

No, it is not optional. If a product (which I would usually define as a device or collection of software sold by one vendor as a distinct entity) performs all of the operations that IPsec requires, crypto and otherwise, then that product can rightfully claim to implement IPsec.  If the functions are spread across multiple products, then none of these products can individually, claim to implement IPsec.  

> > P.S.  You still have not
> answered my question, so I assume the answer
> > is not one that supports your
> suggestion that IPsec delegate
> > responsibility for remote access security to the L2TP WG.
> >
>
> In the L2TP+IPsec scenario the above observation was what we decided
> on
> and I think we convinced you then too,
> that we have no argument.

Convinced me? No. I have steadfastly maintained that vague assertions about what most L2TP products may do is not a substitute for an RFC that mandates the functionality of IPsec re packet filtering in this context. If two distinct products were used, one for IPsec and one for L2TP, and if standard interfaces are used between them, the overall functionality would not be equivalent to that of a single product implementing IPsec, for the reasons I articulated long ago.

Steve