src/sys/netinet/ip_output.c -- flawed determination of transportmode?

[Christian Schlatter-2]

http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/ip_output.c.diff?r1=1.183&r2=1.184&f=h

introduced a new check for transport mode SAs. In my opinion, the code

transportmode = (tdb->tdb_dst.sa.sa_family == AF_INET) &&
                            (tdb->tdb_dst.sin.sin_addr.s_addr ==
                            ip->ip_dst.s_addr);

is wrong since it is possible that IP packets are destined for the end
of a VPN tunnel, so that the condition as written above is true for a
tunnel mode SA.

This has the effect that PMTU doesn't work for IP traffic that shares
the destination address with an established VPN tunnel. Instead, the
next-hop-MTU of destination-unreachable/frag_needed ICMP messages is set
to the VPN tunnel interface MTU.

/Christian

[Markus Friedl-2]

On Wed, Jul 23, 2008 at 05:53:57PM +0200, Christian Schlatter wrote:
> This has the effect that PMTU doesn't work for IP traffic that shares
> the destination address with an established VPN tunnel.

I don't see how PMTU would work in this case, even with this change
backed out. Without this change, the kernel would install a
PMTU route for the inner IP address. However, the outter IP address
is the same, so the MTU intended for the inner packet is also
applied to the outer address and PMTU will be broken, too.

> [...] Instead, the
> next-hop-MTU of destination-unreachable/frag_needed ICMP messages is set
> to the VPN tunnel interface MTU.

-m

[Christian Schlatter-2]

Markus Friedl wrote:
> On Wed, Jul 23, 2008 at 05:53:57PM +0200, Christian Schlatter wrote:
>> This has the effect that PMTU doesn't work for IP traffic that shares
>> the destination address with an established VPN tunnel.
>
> I don't see how PMTU would work in this case, even with this change
> backed out. Without this change, the kernel would install a
> PMTU route for the inner IP address. However, the outter IP address
> is the same, so the MTU intended for the inner packet is also
> applied to the outer address and PMTU will be broken, too.

Yes, that's exactly what I observe when I revert this change. Does that
mean that we cannot support PMTU for IP traffic destined for the end of
a VPN tunnel?

Or, could a possible solution look like:

- keep transportmode check (maybe rename it to better reflect its purpose)

- in ip_output() after transportmode check, if icmp_mtu (==
tdb->tdb_mtu) is smaller than mtu, return EMSGSIZE (as currently done)
but somehow signal back icmp_mtu for destination-unreachable/frag_needed
ICMP message
--> the next-hop MTU size would be correct and the PMTU route would
contain the correct MTU

I just don't see an easy way how to signal back icmp_mtu to ip_input().

/Christian


>
>> [...] Instead, the
>> next-hop-MTU of destination-unreachable/frag_needed ICMP messages is set
>> to the VPN tunnel interface MTU.
>
> -m
>

--
Christian Schlatter
MSc Computer Science ETH
System Architect - Communications Systems

Ascom (Schweiz) AG
Gewerbepark, CH-5506 Maegenwil

mailto:christian.schlatter@...
http://www.ascom.ch

----------------------------------------------------------------------
Diese E-Mail kvnnte vertrauliche und/oder rechtlich gesch|tzte
Informationen enthalten. Wenn Sie nicht der richtige Adressat sind
oder diese E-Mail irrt|mlich erhalten haben, informieren Sie bitte
sofort den Absender und vernichten Sie diese Mail. Das unerlaubte
Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht
gestattet.

This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail
in error) please notify the sender immediately and destroy this
e-mail. Any unauthorised copying, disclosure or distribution of the
material in this e-mail is strictly forbidden.
----------------------------------------------------------------------