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

Re: Auto filter rule generation for Phase 2 tunnels

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Charles" == Charles Lynn <clynn@BBN.COM> writes:
    Charles> Yes, I think there is.  The security policy has to be
    Charles> configured, and anything that will contribute to making
    Charles> the specification of that policy less error prone will
    Charles> increase the level of security being provided.  The

  But, this is a requirements document on the protocol, not on the
user interface. My understanding from this is that each "filter rule"
(and remember: not all of us necessarily have filter "rules" at the
low level. There are numerous techniques) should have a precedence
that is user configurable.

  This is a very new requirement IMHO.

    >> In general, I feel that the architecture document has gone
    >> beyond being a functional specification and gone into being a
    >> design specification.

    Charles> IMHO, there are places where the document does not
    Charles> specify things completely enough (always good for
    Charles> ipsecond :-).  On the other hand, I doubt that many of
    Charles> the folks who end up implementing the code will have the
    Charles> level of security expertise available in this group, so I

  Will there be faulty implementations of IPsec? Yes. And they won't
be at the level of "bugs" but rather of "design flaws" --- as Marcus
Leech might say: "this isn't rocket science, and I should know, I'm a
rocket scientist. It is much harder." 

    Charles> do not think that giving a few hints and pointing out a
    Charles> few catch-22s is unreasonable.  (Just because we're
    Charles> paranoid doesn't mean that the box we buy and install to
    Charles> protect our assets (and have no way of subjecting to a
    Charles> security vulnerability review), will protect us. :-)

  Don't buy a box that you can't subject to a security vulnerability
review. This is an ongoing discussion in the security community. It
just doesn't matter what the specifications say: it still has to be
reviewed. 
  I am not opposed to this amount of content, I am just not certain
that it belongs in the architecture document. I think a shorter base
architecture document, and a BCP from IPsecond might be better. I am
not convinced that we have the operational experience on the ICMP
stuff to really understand what should be done, for instance. I am
happy that some text has been written.
  I think that in ten years we will look back on this document and
think "why were we that  narrow minded?" --- there are, I think, a lot
of advice that could be given to host IPsec implementors, but because
the community is doing VPN first, we know those gotchas now, but the
host stuff is unknown.

  The real question is: who is going to organize the
end-of-the-IPsec-WG party?

]       ON HUMILITY: to err is human. To moo, bovine.           |  SSH IPsec  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |international[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [




-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQB1AwUBNHLshcmxxiPyUBAxAQFaEQMAkWABW0ytHd/B+dnhgbnmc2OYEn4H1kAO
7CbL/Fvtpk6qnyoY8Wdwhg/H/yxOqMrSFcObRcbpV4iqGRpEJvhkBfen6Hh7Am4H
Hy1IC3CSmzkeoWCJtt3lCEHV6L5ghDhk
=luF3
-----END PGP SIGNATURE-----