Until 2007-07-28 (Australian time, some of which is July 27 in the RAM list archives) I believed that ICMP messages including:
ICMP
Destination Unreachable messages (type 3) such as code 4 for Path MTU
Discovery and codes 0, 1, 2, 3, 5 etc. for detecting (not very
reliably) unreachable hosts etc., and
ICMP Echo Reply (type 0) message for ping responses, and
ICMP Time Exceeded (type 11) messages (such as from traceroute or genuine routing loops),
would
be received OK by the sending host when the ICMP message was generated
by routers in the tunneled part of the path - as long as the ITR
encapsulates packets by using the original sending host's address as
the Source Address (SA) of the outer header. (As I propose for
Ivip.)
I thought this because these ICMP messages would be
addressed to the sending host, not the ITR. However, I now think
that the ICMP messages will not be recognised by a correctly
implemented sending host, since they contain details of the tunneled
packet's outer header, which was generated by the ITR, and is unrelated
to the packet the sending host sent.
I still think that
"outer SA = inner SA" is the best approach, despite it being unorthodox
and in some ways unfriendly. (UDP encapsulation could be used, to have
the ITR's address in the packet which traverses the tunneled portion of
the path, if this was considered worthwhile.)
The first reason
is that I think that only with "outer SA = inner SA" is it practical to
have the ETR do some simple filtering which ensures that decapsulated
packets from outside the provider network (and so from potential
attackers) will not be forwarded if they have an SA which matches one
of the provider's own prefixes. I discuss this in "14.1.2.1
Preventing SA spoofing when outer SA = inner SA" in
draft-whittle-ivip-arch-00.
Secondly, while in theory using the
conventional (as used in LISP and eFIT-APT) "outer SA = ITR's address"
can be made to support ICMP messages originated by routers in the
tunneled portion of the path, I think this would be highly impractical
or impossible to achieve in a secure manner in any high-volume
ITR. I discuss this in RAM list messages
msg01766.html and
msg01769.html - and in
../quick-intro/critique-01/
- including the large number of bytes which need to be stored for every
single encapsulated packet (more for those with DF set) and the intense
CPU operations which would be required for every received ICMP packet
in order to test its validity.
Thirdly, relying on the network
to return an ICMP DU message when a packet is sent to an
unreachable router or host is not currently a reliable way of
determining reachability of that router or node, so any system which
relies on this is not going to be very robust at present anyway.
Filtering of ICMP messages is apparently quite common, and this
already clobbers ping and traceroute as well as messages due to
unreachability sending a packet to a host's port which wasn't expecting
it etc.
As best I understand them, LISP and eFIT-APT rely on
getting back an ICMP DU message if they tunnel packets to an address
which does not actually have a suitable ETR. This is a crucial part of
the ITR determining reachability, which is a central part of how the
ITR (and Default Mapper for eFIT-APT) makes decisions about multihoming
service restoration. I think this is extremely unreliable unless
there are strict rules about all ITRs and ETRs being close enough to
the Internet's core that they are not affected by any blocking of ICMP
messages - and that would probably require changes to current filtering
arrangements in some networks.
So broadly speaking:
- Any system which really relies upon ICMP messages is not completely reliable at present.
- The
problem only affects the generation of ICMP messages in the tunneled
part of the path, and there may be no problem if the ITR or the ETR
themselves (or at least parts of them) generate the ICMP message.
So the ICMP messages generated by the destination host or at
least by something at or beyond the ETR should still be received fine
by the sending host even when tunneling is used between the ITR and ETR.
- Tunneled parts of a path, as far as I know, are not always expected to behave like non-tunneled parts.
- The
only way around this problem in general seems to be an inordinately
complex - and probably impossible to implement - amount of state in the
ITR, with impractical amounts of CPU work to do every time an ICMP
message arrives.
- I think the "outer SA = inner SA" benefits
regarding ETR filtering of packets with spoofed local source addresses
are really substantial - that it is probably completely impractical to
do it any other way when the local network has many prefixes.
However this still leaves us with a big problem regarding Path MTU Discovery . . .