Re: [IPsec] Avoiding Authentication Header (AH)

[Nico Williams <[e-mail]>]

On Mon, Jan 2, 2012 at 7:34 PM, RJ Atkinson <[e-mail]> wrote:
> On 02  Jan 2012, at 20:06 , Nico Williams wrote:
>> On Mon, Jan 2, 2012 at 6:45 PM, RJ Atkinson <[e-mail]> wrote:
>> With tunnel mode you effectively repeat the options inside and outside
>> the tunnel.
>
> One could repeat the headers; some implementations don't.
> It doesn't help transit devices to repeat the headers
> if they can't validate them before acting upon them.
>
>> Routers can't validate the integrity protection
>> regardless of whether AH or ESP-NULL in tunnel mode is used,
>
> Disagree.  Intermediate authentication can be performed
> by routers/firewalls, at least when AH is used.  The
> router/firewall could then act on the options in the
> packet having reasonable assurance that the option itself,
> and its contents, were valid for that packet.

OK, so you have networks using manually keyed SAs with
routers/firewalls sharing the same SAs.  I hadn't considered that as
it isn't exactly scalable.  But fair enough.


>> but assuming that an attacker can only modify options at one place in the
>> path then the recipient can see that options were modified.
>
> Unfortunately, it is not really a generally valid assumption
> that there is only 1 potential attack point along a path.

I elided the point that an attacker who can modify the packets close
to the sender and recipient could hide any in-flight changes from the
recipient.  But if there are middle-boxes with access to the SAs' keys
then that doesn't apply.

>>> Sadly, at present there is still no 100% reliable
>>> method for parsing past an ESP header with NULL encryption.
>>> There are various documents describing methods which
>>> have various success probabilities, but none that is
>>> 100% reliable.
>>
>> Sure, this is necessarily true until any replacement for AH is
>> universally deployed and that indicates that only integrity
>> protection is provided.
>
> If some such mechanism exists, and if it provides 100% reliable
> ability to parse-past/parse-into, and if it is plausibly efficient
> to parse-into/parse-past in real-time for high-performance
> switches/routers/firewalls, then this discussion might be
> more useful than it is at present.  That is rather a lot
> of IFs, however, none of which seem true today.

Fair enough.

Nico
--