[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ESP revisions straw poll
> From: "Perry E. Metzger" <perry@piermont.com>
>
> Dennis Glatting writes:
> > I thought the purpose here is collaboration. Why do we have to
> > have winners and losers?
>
> Because some things are mutually exclusive. We can't both permit and
> not permit encryptionless ESP, for example. This means that if there
> are groups arguing in favor of both, one of those groups necessarily
> does not see its desires adopted.
As Bill Simpson and others have pointed out, you can't "not permit"
auth-only ESP; the only thing you can do is refuse to include it in
the base ESP specification. Someone can always come along and write
a Rot-13 or Identity encryption transform document, and implementors
can write code to implement it. It becomes a hard sell to claim that
IPSEC implementations which support additional ESP transforms over and
above the minimum requirements are "non-compliant" - implementations
that support both the Standard transforms and value-added transforms
will be common.
Thus the argument becomes where will the null encryption transform
get documented - as a MAY IMPLEMENT component of the base ESP specification
having no effect on compliance, or in a separate transform document.
I don't have any illusions that there is a Platonic Ideal IPSEC Standard
that we mortals can glimpse but dimly - auth-only ESP may be Good, Bad,
both, or neither.
I just think it's silly to write a separate < 1 page RFC to specify
something that:
1) has semantic and performance properties that are useful to some,
2) is short and easy to describe in the base ESP specification,
3) has zero impact on developers' compliance with the standard, and
4) will be implemented if there's market demand and won't be otherwise,
*regardless* of where it is documented.
Follow-Ups: