Hi Manav,
I agree that for an already negotiated SA, the SPD lookup detects IP source
address spoofing. So in that case ESP detects the address spoofing during
the SPD check whereas AH would detect it while checking the signature check.
However SAD lookup is done with the longest match rule, and section 4.1 of
RFC4301 specifies :
"3. Search the SAD for a match on only SPI if the receiver has
chosen to maintain a single SPI space for AH and ESP, and on
both SPI and protocol, otherwise."
This seems to enable a ESP or AH datagram with spoofed IP addresses to match
the SAD and SPD. If we consider a middleboxe that changes the IP address,
then using ESP will not detect the IP address spoof. On the other hand using
AH the spoofing attack will be detected.
There are some cases you want to protect the IP address header with IP
addresses and options. The example I have in mind is when you are a mobile
or a multihomed node, you are changing you IP address and want to notify
your peer with a IPsec protected signalling message.
- MIPv6 [RFC3776] uses ESP to protects the BU message. The information
to be carried is the new CoA. Since ESP does not protects the IP header, the
BU datagram carries the IP address in its Payload, thus carrying twice this
information. It seems that AH would avoid repeating information.
- MOBIKE [RFC4555] MOBIKE does not protect the new IP value which is
taken from the IP header. In some cases this can lead to traffic redirecting
attacks. The main purpose of this attack seems to be DoS.
Thus I would not consider AH as ESP_NULL equivalent, and thus feel AH should
not be removed. Nevertheless, AH has a major drawback which is NAT. For now
we can only hope IPv6 will bring an end-to-end connectivity. At least AH
would take considerable advantage of this statement!
IMO, rather then removing AH I would see if future use of the Internet make
it "historical" or not. For now it might be too soon to take such a
decision. Furthermore, AH does not cause "problems" with other protocols,
since they can chose not to use it.
Regards,
Daniel
Regards,
Daniel
On Fri, Nov 13, 2009 at 2:18 AM, Bhatia, Manav (Manav) <
manav.bha...@alcatel-lucent.com> wrote:
> Daniel,
>
> > AH is a security feature we need to keep for header authentication
>
> Am really not sure about the value that AH adds even in case of header
> authentication.
>
> So what fields does AH protect:
>
> Version, Payload length, Next Header, Source IP and dest IP
>
> The only field worth modifying is the source and the dest IP. Now note that
> an IPSec SA is established between a pair of source IP and dest IP. Upon
> receipt of a packet containing an AH header, the receiver determines the
> appropriate (unidirectional) SA, based on the dest IP, security protocol
> (AH), and the SPI (it could also include the source IP). If the attacker
> modifies (or spoofs) either of the source or the dest IP, the SA lookup will
> fail and the receiver will regardless discard the packet. So what are we
> gaining by AH "header authentication"?
>
> AH can only add value over ESP-NULL if there are instances where despite
> address spoofing we erroneously process the IPSec packet. I don't see that
> happening, so is this really an issue?
>
> Cheers, Manav
> ________________________________
>
> From: Daniel Migault [mailto:mglt.i...@gmail.com]
> Sent: Thursday, November 12, 2009 11.14 AM
> To: Jack Kohn
> Cc: Stephen Kent; ipsec@ietf.org; Bhatia, Manav (Manav); Merike
> Kaeo
> Subject: Re: [IPsec] WESP - Roadmap Ahead
>
> On Thu, Nov 12, 2009 at 5:30 AM, Jack Kohn <kohn.j...@gmail.com>
> wrote:
> >
> > Whoops, I was wrong. I looked at 4552 and they do cite
> ESP-NULL (although
> > they never refer to it that way) as a MUST, and AH as a
> MAY.
>
> Ok, so can we work on deprecating AH? This way new standards
> defined
> in other WGs dont have to provide support for AH.
>
>
> AH is a security feature we need to keep for header authentication.
> Other WG may chose not to deal with AH and only consider ESP. I don't see
> what's wrong with that?
>
> Regards
>
> Daniel
> --
> Daniel Migault
> Orange Labs -- Security
> +33 6 70 72 69 58
>
>
>
--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
