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

From: Fred Templin <[email-masked]>
Date: Mon, 06 Oct 2003 14:26:14 -0700

Sorry for letting this thread grow cold, but see below:

Pekka Savola wrote:

>Hi,
>
>Thanks for bringing this up.  The RFC is under revision, and this thing 
>should probably be specified in more detail.
>
>There are two-three distinct cases here (I think):
>
> 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.  (I guess that depends on
>what happens when a node receives a packet of an unknown protocol --
>whether it sends anything back or not.)
>
> 2) "node receives packets from a configured tunnel endpoint, but from the 
>wrong direction (e.g. "internal IP address" from the direction of the 
>Internet), if that kind of policing is implemented/enabled.
>
>  ==> silently discard, I think.
>
> 3) "node receives packets through a valid tunnel which fail IPv6 ingress
>filtering tests"
>
> ==> silently discard, I think (if ingress filtering fails, the error 
>won't probably get back anyway)
>

In case 3) above, send an ICMPv6 DU to the originating source.

It might not get back, but may very well help the situation
in the decapsulator for the next time around...

Fred
[email-masked]

>On Thu, 28 Aug 2003, Follen, Stephen wrote:
>  
>
>>A question related to Ingress Filtering of decapsulated [tunneled]
>>IPv6-in-IPv4 packets:
>> 
>>Section 3.6 of RFC 2893, IPv6 Transition Mechanisms, indicates that "...
>>a decapsulated packet MUST NOT be forwarded unless the node has been
>>explicitly configured to forward such packets ..." and in section 4.3
>>"The decapsulating node MUST verify that the tunnel source address is
>>acceptable before forwarding decapsulated packets ..."
>>(the more recent draft-ietf-v6ops-mech-v2-00.txt, Basic IPv6 Transition
>>Mechanisms provides similar guidance in sections 3.6, 3.9 and 4.1)
>> 
>>The question is what to do in the case that the packets are filtered /
>>not forwarded:
>> 
>>1. silently drop the packet - simple, but provides no feedback of the
>>"broken link" (see below);
>> 
>>2. send a v4 ICMP, Destination Unreachable (DU) - this seems like a poor
>>approach since
>>   (a) the IPv4 [tunnel endpoint] address was reached and
>>   (b) a response may never get back to the originating IPv6 host
>>       (section 3.4 of RFC 2893 indicates that an encapsulating node MAY
>>generate
>>       a v6 ICMP when it gets a v4 ICMP back);
>> 
>>3. send a v6 ICMP DU - this probably won't get back to the originating
>>host either since
>>    its unlikely that there's a path back to it (the do not forward
>>decision occurred because
>>    the tunnel was not set up);
>> 
>>4. send a ICMPv6 DU encapsulated in IPv4 - there is enough information
>>in the incoming
>>    IPv6-in-IPv4 packet to generate this, and it would likely get back
>>to the originating host,
>>    but to do so would effectively send a packet via a tunnel which had
>>not been configured.
>> 
>>"broken link" - [in the case of legitimate traffic] the filtering which
>>would occur here is not
>>the result of a specifically configured ingress filter, rather, it is
>>the result of not fully configuring
>>the tunnel; a tunnel is effectively a link, so I see the filtering to be
>>similar to a broken link.
>> 
>>Any thoughts would be greatly appreciated.  - Thank you
>> 
>>Steve Follen
>>[email-masked]
>> 
>> 
>> 
>> 
>>
>>    
>>
>
>  
>

---

From: Pekka Savola <[email-masked]>
Date: Tue, 7 Oct 2003 08:40:16 +0300 (EEST)

> Pekka Savola wrote:
[...]
> in the decapsulator for the next time around...

Huh?  Which node do you refer by decapsulator -- the one sending ICMPv6 
DU, or the one receiving it (over the tunnel) and decapsulating it?

If the former, I don't really understand how sending a reply would help.  
If the latter, I'm not sure if there is enough of a guarantee to warrant
it because the message would probably never get through.  One special case
in which it _might_ help is host<->router tunnels, as you would know that
the host is responsible for sending such illegitimate packets (and not
just anyone at all behind another router).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Fred Templin <[email-masked]>
Date: Tue, 07 Oct 2003 12:33:46 -0700

>DU, or the one receiving it (over the tunnel) and decapsulating it?

The former (i.e., the one sending ICMPv6 DU). But, you seem
to be assuming that it would be sent back over the bidirectional
tunnel from which the original packet arrived. I am not.

>If the former, I don't really understand how sending a reply would help.

Well, it could elicit an ICMPv6 Redirect from a router that would
provide information satisfying future ingress filter checks in the
decapsulator, it could provide a traceback mechanism to detect
IPv6 source address spoofing attacks, etc.

Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Fri, 10 Oct 2003 10:17:56 +0300 (EEST)

> tunnel from which the original packet arrived. I am not.

What are the scenarios where you wouldn't use bidirectional tunneling?  It 
has been considered to kill unidirectional tunnels from trans-mech-bis, 
and it would be useful to know whether they're really relevant.

> IPv6 source address spoofing attacks, etc.

Do you have more information on these?  I fail to see how Redirects would 
help here, as the source address selection is already done at that phase, 
and Redirects only look at the destination addresses, as far as I've 
understood.

I'd like to understand how useful this would be before going forward with 
it.  Sending packets to ingress-filtered sources may only aggravate the 
problem.

---

From: Fred Templin <[email-masked]>
Date: Fri, 17 Oct 2003 14:40:25 -0700 (PDT)

Pekka,
 
I'd rather not get into specifics on your questions just yet in the interest
of not bringing confusion into the discussion. But, I have one question
relative to a message you posted to this thread on 09/04/2003 where
you said:
 
> 1) "node receives packets from an unknown ("unconfigured") tunnel endpoint"
>
> 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.
 
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.
 
Comments?
 
Fred Templin
[email-masked]    

Pekka Savola <[email-masked]> wrote:

---

From: Pekka Savola <[email-masked]>
Date: Sat, 18 Oct 2003 01:31:16 +0300 (EEST)

Hi,

> that the node's IPv6 stack is up, but that the tunnel endpoint was not

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..).

> interoperability issues if a legitimate peer wrongly infers that the node's

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.

---

From: Fred Templin <[email-masked]>
Date: Fri, 17 Oct 2003 17:07:23 -0700 (PDT)

Pekka,
 
Only a couple of cursory thoughts to add to the debate at this
time; perhaps more later:
 
 1) As to "port unreachable", my thought process is that ip-proto-41 is
    the "protocol" and the set of all tunnels configured by the node would
    be the "ports". Using this logic, an unconfigured tunnel would therefore
    be an "unreachable port". (This does not seem like a showstopper issue
    to get hung up over, however.)
 
 2) Agree that ICMPv4 Port/Protocol Unreachables do not necessarily
    need to be sent; RFC 792, P. 4-5 lists them as a *may*.
 
 3) I don't quite agree with the default behavior of silently discard
    in the case that the tunnel endpoint was correctly configured,
    but ingress filtering failed. That would be analagous to firewall
    filtering, and RFC 2463, section 3.1 says that sending an
    ICMPv6 Destination Unreachable with code 1 (communication
    with destination administratively prohibited) is a SHOULD. 
 
Thanks - Fred
[email-masked]

Hi,

---

From: Pekka Savola <[email-masked]>
Date: Mon, 20 Oct 2003 09:45:51 +0300 (EEST)

Hi,

>     to get hung up over, however.)

This seems like one rather reasonable technical interpretation of this
issue. I'm not sure if I agree with it, but I wouldn't have objections if
folks think this is the best way forward.

[...]
>     with destination administratively prohibited) is a SHOULD. 

Note that sending any messages back from a router or a firewall only makes
sense if there is reasonable guarantee/"hope" that the node really who
sent the triggering will be able to receive the ICMP unreachable message.  
In particular with ingress filtering (based on the source address), this
assumption may not hold.

That is, if the address is spoofed or otherwise wrong, it by definition
does not get back to the *right* source node, and sending a message could
maybe even be considered counter-productive.

On the other hand, if the address is not spoofed, but only comes from a
wrong direction (e.g., consider an ISP ingress filtering a customer that
is connected to two ISPs with two provider-aggregatable prefixes, and the
customer sends a packet using the wrong source address to the wrong ISP),
there *might* be a reason for sending such an unreachable message.

The question then would be whether these two cases can be reasonably 
easily distinguished.

As it is, if we had to put on a requirements language on these, I'd 
probably say "an ICMP message MAY be sent".