netdev - Re: [PATCH] xfrm: Accept ESP packets regardless of UDP encapsulation mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1229596531.10402.121.camel@martin>
Date:	Thu, 18 Dec 2008 11:35:31 +0100
From:	Martin Willi <martin@...ongswan.org>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH] xfrm: Accept ESP packets regardless of UDP  encapsulation mode

Hi Herbert,

> This can't work as ESP relies on this check.  Now that it's gone
> ESP may touch a UDP header which doesn't exist.

Hm, this worked perfectly fine in my tests...

> ... when your addresses change
> you have to renegotiate with the other side to ensure that this
> isn't some kind of an attack.  Afterwards you have to recreate
> the SAs at which point you can easily set the encapsulation to
> whatever it should be.

Such address changes are recorded in the IKEv2 daemon and addresses are
updated through MOBIKE (RFC4555). Each peer updates its SA using the new
address. 

> The only time when you need this patch is if the other side
> unilaterally switched from NAT-T to no NAT-T, or vice versa,
> which does not sound like a sane thing to do.

This is a perfectly valid use case. MOBIKE allows you roam your SAs
between different networks, NATed or not. In our implementation, we
switch UDP encapsulation strictly on and off depending on the new NAT
situation. However, other implementations don't [1].

It is a requirement for MOBIKE enabled peers to accept UDP encapsulated
packets in any case (see discussion [2]), and it is currently discussed
to add this requirement to the revised IKEv2 core standard [3]:

> o  Implementations MUST process received UDP-encapsulated ESP packets
>       even when no NAT was detected.

The fact that there is not NAT between peers is no guarantee that the
peer will not use UDP encapsulation.

I don't see any reason to drop ESP packets because of the used UDP
encapsulation mode. What's the point of doing so?

Martin

[1]https://lists.strongswan.org/pipermail/users/2008-December/002936.html
[2]http://www.machshav.com/pipermail/mobike/2006-September/001491.html
[3]http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2bis-01#section-2.23



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html