[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
returning ICMP messages
-----BEGIN PGP SIGNED MESSAGE-----
Consider the following situation:
company1 company2
A---Gw1----Gw2---E
<*VPN**>
Now assume that the VPN SA is a A<->E only SA. (e.g. ANX Simple test
#3, see ... oops page fault finding ANX list archives).
Okay, so things have high latency on this setup for some reason, and
somewhat smart user on A does:
traceroute E
Gw1 sees that TTL = 1 on the about to be tunnelled packet, and
generates an ICMP message.
Traceroute increments the TTL, and then Gw2 sees that TTL=1 on a
packet about to be forwarded and generates an ICMP to A. Gw2 is very
smart, and makes sure that, despite whatever filters it has to
establish what policy to apply packets, when generating ICMP's it
should really reverse the SA's that were used to get that packet, and
apply them.
[i.e. Gw2 uses the existing VPN tunnel to get the ICMP back]
Now, Gw1, being under very clear instructions about who at company2
may send packets to A, decrypts the packet from Gw2, realizes that it
violates the policy on the SA it arrived on, drops the packet and does:
vpn_partner_is_violating_policy[gw2]++
and perhaps refuses to talk to gw2 after it reaches some threshold.
What can we do? Gw1 could realize that if gw2 wanted to send spoofed
packets, it could spoof them as E anyway, so we might as well accept
packets from gw2. Okay, now what about:
company1 company2
A---Gw1----Gw2-----Gw3-----E
<*VPN*> <*VPN*>
So, the sequence is now:
A--->E TTL=1
A<--Gw1
A--->E TTL=2
A<--Gw2 [Gw2 is okay, because Gw1 has an SA with it]
A--->E TTL=3
A<--Gw3 OOPS! Gw1 doesn't know who Gw3.
Is this a realistic scenario? I think it might be.
Imagine that Gw3 is a portable bump-in-the-cord encryptor providing
road-warrior services to notebook E, and that the SA between
Gw1<->Gw2 could even be generally permissive about company1<->company2
packets.
Some of Gw3's IP addresses might even be dynamically assigned. Since
the encrypted packet came from the PPP interface, it might be
reasonable to send the ICMP back with the src address set to that
interface's address. The wire between Gw3 and E might be included in
the SA from Gw1/Gw2, so using the destination interface's address in
the ICMP might be more productive.
Should Gw3 and Gw1 negotiate their own SA? They might be able to do
that in the road-warrior case.
If Gw3 was actually a bump-in-the-stack or host based tunnel there
is no problem, since the packet isn't forwarded, so TTL isn't
decremented.
We might just forget about making traceroute work, but perhaps the
TCP people have something to say about be unable to receive source
quench messages, or the advantages of having prompt unreachable
messages? (unlike some PC stacks...)
So, my recommendation:
1. send ICMP with the source address set to the destination
interface, rather than the one on which the tunneled
packet was received.
Now, what happens when the destination is another tunnel?
What do current routers do? The router requirements doc
(RFC1812) says:
4.3.2.4 ICMP Message Source Address
Except where this document specifies otherwise, the IP source address
in an ICMP message originated by the router MUST be one of the IP
addresses associated with the physical interface over which the ICMP
message is transmitted. If the interface has no IP addresses
associated with it, the router's router-id (see Section [5.2.5]) is
used instead.
[Strangely, 5.2.5 is not about the router-id, section 2.2.7 is]
Also, section 4.2.2.2 says:
Routers are called upon to insert their address into Record Route,
Strict Source and Record Route, Loose Source and Record Route, or
Timestamp Options. When a router inserts its address into such an
option, it MUST use the IP address of the logical interface on which
the packet is being sent. Where this rule cannot be obeyed because
the output interface has no IP address (i.e., is an unnumbered
interface), the router MUST instead insert its router-id. The
router's router-id is one of the router's IP addresses. The Router
ID may be specified on a system basis or on a per-link basis. Which
of the router's addresses is used as the router-id MUST NOT change
(even across reboots) unless changed by the network manager.
Relevant management changes include reconfiguration of the router
such that the IP address used as the router-id ceases to be one of
the router's IP addresses. Routers with multiple unnumbered
interfaces MAY have multiple router-id's. Each unnumbered interface
MUST be associated with a particular router-id. This association
MUST NOT change (even across reboots) without reconfiguration of
the router.
DISCUSSION
This specification does not allow for routers that do not have at
least one IP address. We do not view this as a serious
limitation, since a router needs an IP address to meet the
manageability requirements of Chapter [8] even if the router is
connected only to point-to-point links.
IMPLEMENTATION
One possible method of choosing the router-id that fulfills this
requirement is to use the numerically smallest (or greatest) IP
address (treating the address as a 32-bit integer) that is
assigned to the router.
.......
So, this would seem to answer the question about what source IP to
use. The recommendation could then be amended to say that the
"router-id" must be used when negotiating the SA, and therefore it
becomes an acceptable address that can appear in *any* SA. So, filter
code had better know about this.
] The sun rarely sets on Helsinki | one quark [
] Michael Richardson, Sandelman Software Works, Ottawa, ON | two quark [
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | red q blue q[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQB1AwUBM8PH9smxxiPyUBAxAQGFYwL9Gag2yapy6r/NIwJHdvjCgPs4itJB2QUB
mlAqteZ7mDiNJRDvSJZsYxco9PARi68yULcKu2ah71KtgGztqCnNneSujRnDnFZq
THpQvor9FJlehKYzgYY3g9afvEPh7nqg
=ktYU
-----END PGP SIGNATURE-----