[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Death to AH (was Re: SA identification)
At 11:51 AM -0400 4/4/01, Michael Richardson wrote:
> >>>>> "Stephen" == Stephen Kent <kent@bbn.com> writes:
> Stephen> RFC 2401 states that compliant implementations MUST support AH in
> Stephen> several places. This language is present because the WG strongly
> Stephen> endorsed it. Fejj Schiller took a straw poll after
>Peter Ford (MS)
>
> Yes, I understood the argument at the time, and I agreed with it.
>
> What I am trying to get at, is... when the VPN vendors say that they are
>"compliant", what does that specifically mean. I.e. when marketing says "do
>IPsec", on what basis does engineering translate this to. Does this mean
>"RFC2401" (which wouldn't necessarily mean that you have had IKE, btw), etc.
>
> So, it then falls to the compliance testers to say,
> "IPsec = 2401...2409, plus some PKI subset"
yes, one needs to identify a set of RFCs, but adherence to 2401
includes several other RFCs by reference, because 2401 does mandate
AH, ESP, selected algorithms, etc. The one big thing it misses is a
requirement for automated key management. I would have liked to
include it, but Ran, and a few other folks, were insistent about not
mandating anything more than manual key management. I think this is a
mistake. The KINK folks will argue that IKE should not be mandated,
but I would like to see a requirement for SOME automated key
management. After all, we have made value judgements about other
things to include or exclude based on our perception of whether the
resulting system would be acceptably secure, in principle. One can
argue that, in general, manual key management is likely to be done so
poorly as to undermine the security of the system, and thus should be
discouraged. But, unless the WG agrees with this position, we'll be
stuck with a partial definition of what it means to be IPsec
compliant.
> since there aren't any PKI requirements stated in that list, they have to
>add those from the appropriate PKIX work, etc.
Yes, we are clearly missing a PKI profile, for those who choose to
use certs with IKE. That should be linked to IKE, though, not to the
base IPsec specs.
>
> So, when VPN vendors say that they don't like AH for some set of reasons
>and like to remove it, I ask the question: "who said you had to implement
>it?"
>
> (Recall the joke with the patient who says "Doctor, it hurts when
>I do this!",
> Doctor says "Don't do that!")
I think the answer os because the vendors view 2401 as the base
standard for IPsec [I do :-)] and thus they want to comply with it,
which mandates AH support.
>
> IPsec is a tool to implement many things, including VPNs, but VPN is
>clearly the primary user at present. I would hate to have AH junked for all
>end hosts because it didn't agree with the VPN subset.
> As a precedent, we have different router and end-system requirements at
>present. I think that 2401 speaks to end systems requirements, not gateway
>requirements.
I disagree; 2401 speaks to both. We impose different requirements on
hosts vs. SGs in 2401 and we will try to do an even better job in the
next pass.
>
> It seems that the appropriate thing to do is to write a BCP on the "VPN"
>problem, and then the VPN vendor's can claim compliance to *that* rather than
>to 2401.
>
> The full blown host systems (Sun, KAME, Win2k,...) are the ones that we
>want to be 2401 compliant. I haven't seen any of them argue strongly for
>removing AH (or transport mode).
A security gateway that is not 2401 compliant has a very limited
basis for claiming IPsec compliance, as it's hard to cite what the
device can claim to support, exclusive of 2401, and still be
interoperable and offer a well-defined service.
> The water will get even more muddy as IPSP and IPSRA work goes to PS. What
>will "IPsec compliant" mean then?
I would expect vendors to claim compliance with 2401bis and with
appropriate IPRSA RFCs, for those devices that are intended to
support remote access.
>
> Stephen> but I am surprised by the form of your question. It
>seemed to suggest
> Stephen> that a desire to claim compliance with the IETF standard for the
> Stephen> IPsec architecture was not sufficient motivation,
>whereas compliance
> Stephen> with industry test programs that are not aligned with
>IETF standards
> Stephen> was a good motivation. if you really feel this way, perhaps you
> Stephen> should focus more on contributing to ICSA and related
>efforts, vs.
> Stephen> the IPsec WG :-).
>
> This issue is that the industry test programs are not handing out "IPsec"
>conformance certificates, because
> 1) it is a hard thing (i.e. $$$) to fully test
> 2) the end-customers don't really want all of of what "IPsec"
> could be. They mostly want VPNs.
>
I've always thought that the groups that had out compliance
certificates for IPSec [sic] compliance were engaged in a subtle game
that motivated the misspelling of the protocol suite :-).
Steve
References: