[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences
Steve,
Tero Kivinen wrote:
>> The SEND is a user of the AH. ...
A major reason why why SEND currently uses AH is that Bellovin
suggested that at the Yokohama BoF. James and I, as WC chairs,
felt that we should at least *attempt* the way suggested by an AD.
However, as it should be clear from this on-going discussion, it
is far from clear if that is the right way. Personally, I believe
that it indeed is, but others clearly disagree.
Stephen Kent wrote:
> The way you seem to want to use AH is so different from normal IPsec
> processing as to warrant having a different protocol, in my view. You
> can't just appropriate the name of the protocol and its syntax, but
> change the processing model.
I have already addressed this in a separate message. As a summary
of that: if we are speaking about the current WG proposal, I tend to
agree with you , but I also think that the issues can be solved fairly
easily, with just a minor technical change to AHbis.
>> Do we want them to create another protocol replacing their use of AH?
>
> Good question.
Indeed.
>> Is there any use for the AH as it is now specified?
>
> Very little. But, that does not mean that one can redefine it and still
> have it be part of IPsec.
Just out of curiosity: How do you define IPsec? RFC2401?
> The SEND WG can create its own protocol, but there is no technical
> rationale for reusing the AH name. Reuse would only cause confusion.
In my (in this case very) humble opinion, I think that the question
of reusing the AH name depends on the intent of the protocol, not
only on its syntax. If the goal is the same, to provide integrity
and data origin authentication for the whole IP packet, including the
immutable or predictable header fields, then I think that the protocol
could and should be called AH. If it uses public key crypto, and
thereby creates (conceptual) Security Associations that are associated
with the source of the packet rather than the destination, even for
unicast, that does not change the intent.
OTOH, I do agree that embedding KMP functionality into the AH header
does not sound that good an idea. However, it did not appear to me how
to separate the KMP functionality before I started to implement the
current SEND proposal.
AH has a long history. I think it would be better to return to the
some early goals of AH rather than to deprecate it and start anew.
--Pekka Nikander