[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Death to AH (was Re: SA identification)
RFC2401 includes a requirement to support manually keyed SAs yet there
are lots of VPN vendors that either don't support it or disabled it in
their products because customers got confused or demanded it be disabled
or some combination of the two. All of these vendors claim they are
"IPsec compliant". (I'm reminded of Claude Reins in Casablanca being
shocked that gambling was taking place at Rick's-- vendors claiming
compliance when they are not 100% compliant!)
My experience with IPsec compliance organizations is that they do not
test full compliance with the RFCs. They test a small subset and then
incrementally add things to justify the pound (ton actually) of flesh
they take each year for vendors to remain "compliant".
I think the decision to remove the MUST language for AH from the RFCs
should not be influenced either by vendors desire to claim compliance--
they will anyway-- or the business models of the various compliance
organizations-- they will not test full compliance anyway or they'd go
out of business.
And Steve's memory is the same as mine. It was an end-system vendor, Peter
Ford "from the Microsoft Corporation", who argued quite strongly for the
removal of AH.
Dan.
VPN vendors claim compliance to RFC2401 yet
On Wed, 04 Apr 2001 11:51:34 EDT you wrote
>
> >>>>> "Stephen" == Stephen Kent <kent@bbn.com> writes:
> Stephen> RFC 2401 states that compliant implementations MUST support AH i
>n
> Stephen> several places. This language is present because the WG strongly
>
> Stephen> endorsed it. Fejj Schiller took a straw poll after Peter Ford (M
>S)
>
> 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"
>
> since there aren't any PKI requirements stated in that list, they have to
> add those from the appropriate PKIX work, etc.
>
> 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!")
>
> 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.
>
> 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).
>
> The water will get even more muddy as IPSP and IPSRA work goes to PS. What
> will "IPsec compliant" mean then?
>
> Stephen> but I am surprised by the form of your question. It seemed to su
>ggest
> Stephen> that a desire to claim compliance with the IETF standard for the
>
> Stephen> IPsec architecture was not sufficient motivation, whereas compli
>ance
> Stephen> with industry test programs that are not aligned with IETF stand
>ards
> Stephen> was a good motivation. if you really feel this way, perhaps you
> Stephen> should focus more on contributing to ICSA and related efforts, v
>s.
> 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.
>
> ] Train travel features AC outlets with no take-off restrictions|gigabit is n
>o[
> ] Michael Richardson, Solidum Systems Oh where, oh where has|problem wit
>h[
> ] mcr@solidum.com www.solidum.com the little fishy gone?|PAX.port 110
>0[
> ] panic("Just another NetBSD/notebook using, kernel hacking, security guy");
> [
>
>
>
Follow-Ups:
References: