Re: SOI QUESTIONS: 2.3 Authentication styles

["Chinna N.R. Pellacuru" <pcn@cisco.com>]

I really don't understand the reasoning behing IPsec trying to mandate a
minimal useless 'static packet filtering'. The problem of access control
and intrusion detection, as far as I can see belongs in the firewall
functionality.

The philosophy that if I am not having a problem, in my implementation,
and if you are having a problem in your implementation and deployment,
then it is probably an implemetation defect, rather than a larger problem,
is a recurring theme in this WG. I guess the assumption is that all IPsec
implemetations are being deployed in exactly the same way that your
implementation is being deployed/not deployed.

We have seen it a lot for a very very long time WRT IKE. Now for some
reason the IKE fort was brought down (kink?), and we are actually
discussing a successor to IKE after a long period of denial, and
accusations and flaming.

I hope the RFC 2401 fort also comes down sometime in the near future, and
there is some acknowlegement to practical problems and deployment
headaches.

    chinna

On Thu, 20 Jun 2002, Chinna N.R. Pellacuru wrote:

> On Thu, 20 Jun 2002, Stephen Kent wrote:
>
> > 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.
>
> It is optional in IPsec, not optional on the whole. It is not necessary to
> do it in IPsec if we do it elsewhere. Doing it in IPsec is inefficient for
> the minimal benefit.
>
> >
> > >  > 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
>
> Acknwoledging that the minimal 'static packet filtering' provided by IPsec
> is useless is much better than saying that IPsec mandates this minimal
> 'static packet filtering' and everyone has to do it in IPsec.
>
>     chinna
> __
> chinna narasimha reddy pellacuru
> "Moral Clarity: Def. When you do it, it is moral relativism, when I do it,
> it is the repudiation of moral equivalence."
>
>

__
chinna narasimha reddy pellacuru
"Moral Clarity: Def. When you do it, it is moral relativism, when I do it,
it is the repudiation of moral equivalence."