[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Last Call for IPSEC
- To: "Patel, Baiju V" <baiju.v.patel@intel.com>
- Subject: Re: Last Call for IPSEC
- From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
- Date: Thu, 16 Apr 1998 23:29:17 -0400
- Address: 1 Amherst St., Cambridge, MA 02139
- Cc: "'iesg@ietf.org'" <iesg@ietf.org>, "'ipsec@tis.com'"<ipsec@tis.com>, "Patel, Baiju V" <baiju.v.patel@intel.com>
- In-Reply-To: Patel, Baiju V's message of Thu, 9 Apr 1998 14:28:21 -0700,<199804161414.KAA11087@portal.ex.tis.com>
- Phone: (617) 253-8091
- Sender: owner-ipsec@ex.tis.com
From: "Patel, Baiju V" <baiju.v.patel@intel.com>
Date: Thu, 9 Apr 1998 14:28:21 -0700
1. Destination address: The destination address is part of SA.
Therefore, it is not possible for the recipient of the packet to
correctly identify SA used to protect the packet, and thus, ESP
integrity check will fail.
2. Source address: As defined in the IPSEC Arch document, SA database
includes this information, and therefore, when compared with expected
source address for the SA, any change in the source address will be
detected (thus, integrity violation will be detected).
The destination and source addresses in the SA may be a wildcard, or a
range of addresses, not just a single address. Hence, changes to source
and destination addresses may not be detected unless you are using
something like AH to integrity protect these header values.
7. If protocol field is changed, SA lookup will result in the SA that
was used to protect the packet. So, integrity will not be verified.
The protocol field is not used to lookup the SA. The SPI is used to do
that.
a. Internet security options: (these are obsolete but still in use,
as specified in AH document). IPSEC is designed to meets security
needs at IP layer, so, what is the additional security value of using
these options? Moreover, if these options are compromised, and that
can result in weaker security, are they really providing security?
(also note they are obsolete). In conclusion, While using IPSEC, if
we still need these options, and they need to be protected, IPSEC is
not meeting security requirements. I do believe that IPSEC does meet
the security requirements and therefore, there is no additional value
in protecting these options. (note that in tunnel mode they will be
protected anyway).
There are other security services which are orthagnonal to those which
are provided by IPSEC. For example, IPSEC does not provide
classification labeling. Whether or not such options are useful in
general is another debate, although historically there have been a
number of communities which have found such services useful. Your
claim that IPSEC obsoletes all other IP Security options does not seem
to make a prima facie case.
Unless technical flaws are identified with above analysis, it is my
recommendation that we do not standardize two security protocols at
the same time and burden the community with this legacy. We drop AH
from IPSEC for IP v4 and possibly from IP v6.
At least a number of your arguments have very obvious flaws.
In any case, this is an item which the working group has now revisited
*three* times, most recently at the last IETF meeting in Los Angelos,
where Jeff Schiller took a straw poll and found a clear consensus of the
working group to not change the status of AH at this date. One would
think that we have dealt with this issue enough at this point. It is
hard, nay impossible, to make progress when we have to revisit an issue
over and over again. At some point we have to say "enough" and move on.
- Ted
References: