Resolving inner ICMP connections

Resolving inner ICMP connections

[Mark Huang]

Hi all,

Is it a bug that 
net/ipv4/netfilter/ip_conntrack_proto_icmp.c:icmp_error_message()
associates ICMP error message packets with the connection specified in 
the inner IP packet, even if the direction of that connection makes no 
sense?

I found a router in France that accidentally swaps the direction of the 
inner IP packet, instead of preserving it verbatim inside the ICMP error 
message. So, for instance, if you (A) traceroute it (B):

IP: A -> B
   UDP: a -> b

You get back an ICMP destination unreachable message that looks like:

IP: B -> A
   ICMP: type 3, code 3
     IP: B -> A
     UDP: b -> a

Instead of:

IP: B -> A
   ICMP: type 3, code 3
     IP: A -> B
     UDP: a -> b

Obviously there's something seriously wrong with this router. What 
happens is that the ICMP error message gets associated with the original 
side of the connection (as in IP_CT_DIR_ORIGINAL), not the reply side, 
messing up a few assumptions I was making in my NF_IP_LOCAL_IN hook.

Thanks,

--Mark

Re: Resolving inner ICMP connections

[Patrick McHardy]

Mark Huang wrote:
> Hi all,
> 
> Is it a bug that 
> net/ipv4/netfilter/ip_conntrack_proto_icmp.c:icmp_error_message()
> associates ICMP error message packets with the connection specified in 
> the inner IP packet, even if the direction of that connection makes no 
> sense?

That depends. What do you mean with "makes no sense"?

> I found a router in France that accidentally swaps the direction of the 
> inner IP packet, instead of preserving it verbatim inside the ICMP error 
> message. So, for instance, if you (A) traceroute it (B):

Maybe an old version of linux? :) NAT used to do stange things to
locally generated ICMP packets until about a year ago.

> IP: A -> B
>   UDP: a -> b
> 
> You get back an ICMP destination unreachable message that looks like:
> 
> IP: B -> A
>   ICMP: type 3, code 3
>     IP: B -> A
>     UDP: b -> a
> 
> Instead of:
> 
> IP: B -> A
>   ICMP: type 3, code 3
>     IP: A -> B
>     UDP: a -> b
> 
> Obviously there's something seriously wrong with this router. What 
> happens is that the ICMP error message gets associated with the original 
> side of the connection (as in IP_CT_DIR_ORIGINAL), not the reply side, 
> messing up a few assumptions I was making in my NF_IP_LOCAL_IN hook.

What are these assumptions?

Re: Resolving inner ICMP connections

[Patrick McHardy]

Mark Huang wrote:
> Patrick McHardy wrote:
> 
>> That depends. What do you mean with "makes no sense"?
> 
> 
> Well, in the case of the French router, plain wrong.

The question is, how can conntrack know its "wrong"? There is
no relationship between the inner and the outer addresses that
we could rely on.

> But I can imagine a 
> few other scenarios as well. The inner IP packet could be completely 
> unrelated to any current connection, or it could be a cracker trying to 
> break some current connection on the machine by spoofing inner ICMP 
> packets. I'm just speculating and don't have any tests to back this 
> claim up, but I might try it just to see what happens.

It its completely unrelated it will be tracked as state INVALID.
Spoofed ICMP packets don't affect conntrack directly, ICMP replies
are only tracked to make filtering easier and to correctly reverse
NAT the inner packet. It doesn't affect the connection state.

>> Maybe an old version of linux? :) NAT used to do stange things to
>> locally generated ICMP packets until about a year ago.
> 
> 
> Do you mean on the French router or on my box? I don't know what's 
> running on the French router, but I'm running a 2.6.12ish kernel.

The router.

>> What are these assumptions?
> 
> Well, the worst assumption was that
> 
> conntrack->tuplehash[dir].tuple.dst.ip == skb->nh.iph->ipaddr
> 
> I.e., the conntrack associated with the packet I received on the local 
> IN hook, has the same destination IP address as the packet itself, which 
> in retrospect is probably a bad assumption. When the French router 
> returned the inverted ICMP error message, the conntract dst.ip was that 
> of the French router, not my IP address!

OK, thats weird. I don't think this can be used to confuse conntrack
itself, but I'm going to check.