[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ESP revisions straw poll
Folks,
I have a few comments on the recent postings.
First, a procedural issue.
> a) the implementors at Memphis decided against it
It is my understanding that consensus includes more than implementers
who were able to make it to an IETF meeting. It includes the whole
working group, whether or not they were able to get to a face to face
meeting.
Second, there also seems to be a strong feeling that the working group
should "Do The Right Thing" to provide the best security services we
are collectively able to standardize for the users of the IP layer,
i.e., our customers. This philosophy implies that whether or not
something is hard to export should not be of primary concern. Thus
arguments like:
> By its nature, ESP is "encryption enabling technology" and is
> therefore not exportable w/o jumping through various hoops. Even if
> your product is only using encryptionless ESP, it may still have to
> jump through hoops.
do not belong in our technical arena. If we do not like what our
politicians have decided, we can (more or less easily :-) change the
politicians. If they want to provide incentives for businesses in
other countries to develop their own IPSEC code, so be it. But if
they implement the IETF's IPSEC architecture, they'll be using a good
architecture, not one designed around export/import laws.
As an example of this philosophy, the decision was made to mandate ESP
as MUST be implemented for IPv6, even though ESP might be hard to
export. From RFC 1883, "IPv6 Specification",
Security Considerations
This document specifies that the IP Authentication Header [RFC-1826]
and the IP Encapsulating Security Payload [RFC-1827] be used with
IPv6, in conformance with the Security Architecture for the Internet
Protocol [RFC-1825].
Many have commented on not wanting an encryptionless ESP. One reason
given is that AH is fine, and the extra work to munge headers is not
very expensive, relative to the crypto code. That argument sounds
correct, and if moving the bits were the only issue, that would be
fine.
I think that the main reason AH, as defined, is not a suitable
replacement for an encryptionless ESP is that it does not provide an
application with a way to perform end-to-end authentication of a payload
without also trying protect other header fields whose value can be
predicted a priori. I think that relying on such prediction is a big
impediment to further internet growth and evolution. Just because we
can predice what an IP base header will look like does not mean that
we will be able to predict what, e.g., Routing Extension Header
versions 1, 2, ... will look like in the future. I do not think that
our customers will appreciate the argument that they can no longer use
AH until they and their peers upgrade their systems, because they
bought a NAT box or because of a change in the routing system needed
to provide additional services or deal with exponential growth.
Thus I think AH, as defined, places unnecessary restrictions on the
evolution of the internet routing system, which needs all the freedom
it can get to get our packets delivered. After all, except for the
community using security labels, what additional security is provided
by trying to protect the outer headers? In tunnel mode they are
discarded. In end-to-end mode, if I get a packet, and verify that it
is authentic because the body was processed by someone who shares a
secret with me, I don't care what the header looks like.
I am willing to leave the "try to protect the outer header" AH
functionality for the community that thinks it is useful, if others
are willing to provide a mechanism that allows another community to
protect bodies without concern for headers.
One way this mechanism could be provided would be to use a bit in the
AH Reserved field to indicate that the authenticated information
begins at the start of the AH header and ends at the end of the IP
frame. This would permit evolution while not encountering the export
problems folks feel is associated with ESP.
Another reason for not trying to protect the IP addresses is that
doing so encourages their use as security related identifiers. One
of the lessons that I thought was learned from the IPv4 experience
was that requiring security to be based on network attachment point
identifiers, such as IP, NSAP, or ATM addresses, is a Bad Idea.
Given the requirement for plug and play and dynamic address
assignment that IPv6 is trying to meet, it seems like promoting the
use of the IP address as a security identifier will make it more
difficult for our IPSEC customers in the future when the identifiers
change and certificates have to be replaced (and, I suspect,
associated CRLs updated, etc.). I do not think that this is the
direction we want to be going.
Third, based on the email that I have seen, most folks agree with moving
the IV out of the ESP header and into the beginning of the Payload
Data area. I agree that this is a reasonable thing to do. But it
has a hidden cost for IPv6. In IPv6 tunnel mode, the inner IPv6
header, which must be aligned on a 64-bit boundary, follows the
64-bit aligned ESP header and the algorithm dependent and negotiated
IV. (Some have argued that this alignment is not strictly required.
Others that it is. The "be conservative in what you send and liberal
in what you accept" argues we follow the strict viewpoint.) Thus the
space occupied by the IV field has to be a multiple of 64 bits to
meet the IPv6 requirements. It seems this requires that, if the size
of the IV is a function of the algorithm or is negotiated, then the
negotiation protocol would have to be aware during the negotiation
process of the IP version being protected. That seems rather
complicated to me. I would instead suggest the architecture or ESP
doc require that IV field size MUST be a multiple of 64 bits, and
also specify how to pad IVs of other sizes to a multiple of 64 bits.
Since most algorithms that I am aware of already use 64-bit IVs, this
would not cause any additional processing. It would make it so that
(some vendor's) deployed software would not suddenly break when a new
algorithm which uses other sized IVs is deployed in the future. What
do others think about making this a requirement?
In summary:
Removal of optional IV from ESP header:
Yes, but require any IV field to be a multiple of 64 bits.
AR field (both AH and ESP):
Independent of any decisions about authentication with ESP:
Always present, starts at 1 and always set by the sender.
Receiver may process or ignore, with a window size selected by
the receiver, minimum of 32 packets. I do not see a need for the
sender to be informed of the actual size, but have no objections
to it.
Encryptionless ESP:
In favor, but willing to accept equivalent functionality in AH.
Charlie
Follow-Ups: