[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Last Call for IPSEC (repeat post)
Sorry for sending this again (It did not make
it back to me so I figured, others may not have
received it).
Baiju
-----Original Message-----
From: Patel, Baiju V
Sent: Thursday, April 09, 1998 2:28 PM
To: 'iesg@ietf.org'; 'ipsec@tis.com'
Cc: Patel, Baiju V
Subject: RE: Last Call for IPSEC
Here is my analysis of why AH adds no security
value over ESP with NULL encryption in case of
IP v4. I do believe that similar story
exists for IP v6. Therefore, unless one can clearly
identify the value of using AH over ESP with NULL
encryption, we MUST not define two standards with are
functionally equivalent and yet are different
(AH is more complex to implement and is
a layering violation).
Basics:
1. Any node/system/router/firewall cannot
associate any IPSEC security properties to a packet
unless it knows of the security association.
2. The failed integrity check does not
provide any information on why it failed.
All that can be determined is, did
the packet pass the integrity check or
not.
3. When the integrity check fails, the
prudent action is to discard the
packet and possibly log information.
If any part of IP payload is compromised,
both IPSEC AH or ESP with NULL encryption
will result in failed integrity check by
any entity that has knowledge of SA.
Therefore, AH may have additional value
when parts of IP header (non-mutable part)
are modified. In the following, I am
going to consider each part of the IP packet
that is protected only by AH and not by
ESP with NULL encryption and show that
the end results are same. And therefore,
establish that there is no additional
value of using AH over ESP.
The following analysis assumes
that a packet protected with
ESP using NULL encryption is
being processed by a node
that knows of SA. This covers
all parts of IP packet
that are protected by AH and
not by ESP.
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).
3. IP Version: When changed, it will be
processed by non-IP v4 part of stack.
So, it will be dropped because of incorrect
version number, or lack of SA for that
version number, or failure to process
packet.
4. IP Header length: If just the length
is changed, it will not be possible to
find SPI and therefore, SA lookup will
fails, and thus, packet will not be
accepted. If options are added, (e.g., trace
route, source route etc.), any router
that does not know SA will process them
anyway (ESP or AH) because they cannot
detect. The systems that know SA will
not know if these options are added
when ESP is used while AH is used,
only detection is that integrity cannot
be verified. I do not see a security
advantage here to mandate AH because of this.
5. If total length is changed, put not
the packet, it will be detected because
either lengths do not add up or
data is changed.
6. Identification: If ID of a packet is
changed, but packet is not fragmented,
it has no security threat because ID
has value in reassmebly. If packet
is fragmented, then reassembly of
packets may be flawed. In that case
the integrity check on the packet will
fail.
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.
8. Immutable Options:
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).
b. router alert: again, if a router
also knows the SA for some reason, it
may be able to detect that someone
has modified this option. Does that
improve security (frankly, look at
who uses these and then determine
the value. Note that protocols such
RSVP use router alerts but they also
define their own security protocol.
c. If sender directed multidestination
delivery option is modified, such that the
packet is delivered to a destination
that does not know of SA, SA lookup
will fail and packet will be dropped.
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.
Baiju
--------------------
PS: By the way, ESP in tunnel mode
actually protects all the fields of
the inner IP header. Therefore, it
does protect everything that AH protects.
So, there are three ways of achieving
same security objectives:
1. AH
2. ESP with NULL encryption
3. ESP in tunnel mode (inner and
outer headers are identical)
Why so many standard but different
ways to skin the cat!