Re: RFC 2893 Question - Ingress Filtering of IPv6-in-IPv4

[Pekka Savola <pekkas@netcore.fi>]

Hi,

On Fri, 17 Oct 2003, Fred Templin wrote:
> > 1) "node receives packets from an unknown ("unconfigured") tunnel endpoint"
> >
> >  ==> the node should _not_ "acknowledge" the existence of the tunnel,
> > otherwise this could be used to probe the acceptable tunnel endpoint
> > addresses.  That is, node should either silently discard the packet, or
> > send an ICMPv4 Protocol Unreachable message.
>  
> My question is, why should the node send ICMPv4 *Protocol* Unreachable
> instead of ICMPv4 *Port* Unreachable? To send "Protocol Unreachable" would
> seem a bit disingenuous in that it would seem to indicate to the peer that
> the node's IPv6 stack is down and that future attempts to establish a tunnel
> with the node would be unsuccessful. "Port Unreachable" would indicate
> that the node's IPv6 stack is up, but that the tunnel endpoint was not
> configured.

My reasoning here was simple: the tunneling uses ip-proto-41, so obviously
"port unreachable" would seem to be wrong, as ip-proto-41 doesn't use
_ports_ in the first place.  The issue would be different if IPv6 was
encapsulated on top of UDP, of course.

Of course, I'm not saying a message needs to be sent, necessarily .. it
depends on what implementations do when they receive an unknown protocol
packets.  The treatment should probably be the same. I guess most discard
them without any further consideration.
  
I think returning a port unreachable would just be overloading a special
case semantics into an ICMP message, like "port unreachable in this very
specific case implies X", while "protocol unreachable would imply Y" --
I'm not sure that's wise or reasonable considering that port unreachable
doesn't *seem* to be directly related to the matter at hand (again, the
port vs protocol argument..).

> In either case (Protocol vs. Port Unreachable), malicious nodes can probe
> for acceptable tunnel endpoints, so I see no little value in sending
> Protocol Unreachable from a security standpoint and the potential for
> interoperability issues if a legitimate peer wrongly infers that the node's
> IPv6 stack is down.

The point here is that the attacker should not, by sending a packet or 
two, be able to distinguish whether the ip-proto-41 tunneling has been 
enabled in the node in the first place or not.  Sending the same ICMP 
packets as with an unrecognized IP protocol packet would imply that.

Another level of "invisibility" would be that the admin of the node would
find it's acceptable to say that "yes, I do have a tunnel here, but I just
don't tell you what the endpoint is".  Maybe that would be acceptable too,
I don't know.

The other dimension to this debate is, of course, also having the same 
external behaviour whether the tunnel endpoint was unconfigured, ingress 
filtering failed, TTL hop limit was wrong, or whatever reasons.  This is 
typical.

If the "default" behaviour is to silently discard, this would help in the 
sense that the attacker would not be able to deduce even:
 - whether the ip-proto-41 is implemented (if regular behaviour regarding
unrecognized protocols is to discard the packets)
 - whether the tunnel endpoint was configured correctly or not
 - whether the packet passed the ingress filter
 - whether the packet passed all the other tests
 - etc.

Yet another angle seems to be the tradeoffs in treatment when the source
address of the packet is forged; perhaps sending back ICMP errors would be
just what the attacker wants as well, and it might be better to stay
silent?  (In co-operative environments, this has its downsides as well.)

So, I think one could state that not revealing the reason why the packet
is dropped and keeping consistent external behaviour seem to be the most
important things to consider if one values the "security" tradeoff in this
debate.
 
-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings