[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Last Call for IPSEC



   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: