Re: Comments on draft-nakibly-v6ops-tunnel-loops

[Fernando Gont <fernando@gont.com.ar>]

Hi, Gabi,

Thanks so much for your response. Please find my comments inline....

>> a) "Attack #1: 6to4 Relay to ISATAP Router" discussed in [USENIX09]
>> implies that an ISATAP router will receive an encapsulated IPv6 packet
>> on its *external* interface, destined to an IPv6 address that does not
>> belong to that site, but nevertheless forward it on the native IPv6 network.
>>
>> The rule here should be simple: tunneled packets should only be received
>> on the internal interface. Furthermore, ingress filtering should prevent
>> processing a packet with an *internal* src addr that was received on an
>> *external* interface.
>>
> 
> We agree with your observation. However, please note that the ISATAP router will
> not always receive the attack packet (packet #0) on its external interface.
> The packet may enter the inside network through a border router which is not the
> ISATAP router.  Let's take for example a network with two border routers. The
> first border router is an ISATAP router that borders with a native IPv6 network
> and a second border router that borders with an IPv4 network. The attack packet
> may enter the network through the second router and the ISATAP router may
> receive it on its *internal* interface. The rule you propose can not mitigate
> the attack in this case.

In this scenario, the second router should be doing ingress filtering.
I'd argue that having such a scenario and not doing ingress filtering is
opening the door to lots of trouble -- not just this only issue.

Nevertheless, it should be clarified in the I-D this possible scenario.
Because for other scenarios, the check I've mentioned would solve this
issue.

(Note, nevertheless, that ingress filtering on the second router, plus
the check I've mentioned fix this potential problem, with no magic)



> 
>> b) "Attack #2: ISATAP Router to 6to4 Relay"
>>
>> This one implies that the ISATAP router will send a tunneled packet on
>> its *external* interface. Being ISATAP an *Intra-site* tunneling
>> protocol, this clearly shouldn't happen (but Fred Templin is certainly
>> in a much better position than me to correct me if I'm wrong).
>>
>> Both in this case and in Attack #1 above, there should never be a case
>> in which a packet is received on the external physical interface, and
>> forwarded back on that external physical interface.
> 
> Similarly to the case we described above, the packet will indeed be forwarded by
> the ISATAP router over its internal interface, but the packet will find its way
> out through the second border router and loop will continue.

This scenario should be clearly explained, then. -- Even then, being a
border router the ISATAP router probably knows the IP address block
that's used within the site. Therefore, it should probably filter those
packets that would need to be tunneled off-site.

But, again: it should be made clear that you're thinking about a
two-border-router scenario.



>> c) Attack #3: ISATAP Router to ISATAP Router
>>
>> Same as above.
>>
> 
> Same as above.

Same as above. :-)



>> d) "Attack #4: Teredo Client to NAT"
>>
>> This not only implies that a Teredo client will accept packets on its
>> Teredo interface, but also that it will forward them. Both behaviors
>> seem to be ill-advised (despite the fact that Windows allegedly
>> implements them).
>>
>> The countermeasure here is straightforward: drop packets received on the
>> Teredo interface that are not received to your nodes. Never forward
>> packets on the Teredo interface that have not originated in your own node.
>>
>> e) "E. Attack #5: Teredo Server"
>>
>> This one is probably trickier. Although one should probably argue that
>> packets received on a physical interface for a unicast address, with a
>> src addr that belongs to the host should be dropped. (such packets would
>> typically be forwarded internally).
>
> 
> Regarding the last two Teredo attacks, please note that the draft does NOT
> address them. The nature of these two attacks are different from the previous
> ones, hence to make the draft more coherent and simple it only addresses
> protocol-41 tunnel-based loops.
> As to the countermeasure you proposed for attack #4, I think that it may not be
> suitable for Teredo clients that do need to forward packets.

Are there any of these available? For instance, does RFC 4380 support
this? - I don't think that's the case (of the top of my head, though)


> For example, a
> router that serves as a gateway to an internal IPv6 network while the router's
> external IPv6 connectivity is achieved via Teredo. 

This setup would be really broken. If there's an IPv6 island, then the
border router of that island should be doing 6to4, or a configured
tunnel or the like.



> However, we do agree that a
> simple countermeasure similar to the one you proposed can be devised.
> But, again, this is not related to the draft. If the list feels that these 
> attacks should be addressed, suitable updates to Teredo can be proposed. If yes, 
> I welcome any comments.

IMHO, if you mention the attack, you should probably point a possible
way to fix this. -- although I understand that in this particular case
this would be more in the scope of 6man than v6ops.



>> **** 5) Section 2, first para:
>> "  In this section we shall denote an IPv6 address of a node reached via
>>   a given tunnel by the prefix of the tunnel and the IPv4 address of
>>   the node, i.e., Addr(Prefix, IPv4)."
>>
>> This seems misleading. the IPv4 address (IPv4) corresponds to the tunnel
>> end-point, and not to the node that is reachable by the given tunnel.
> 
> Good point, but to be more precise the IPv4 address corresponds to an 
> (IPv4) interface associated with the tunnel endpoint. The tunnel endpoint 
> may associate multiple such interfaces with the tunnel endpoint, however, 
> so the proposed resolution is to change "the IPv4 address" to "an IPv4 address".
> We will change this to make it clearer.

Looking at the text again, I realize that I looked confusion to me in
this aspect: "node reached via a given tunnel" sounded to me more like
e.g. a  node in a network that was accessed through a tunnel (this
"node" was different from the node/router that was the tunnel endpoint)
-- hence the confusion.

Again, a network diagram would be helpful here.


> 
>> **** 7) Section 2 (nit):
>> "  The source address of the packet is a T1
>>   address with Prf1 as the prefix and IP2 as the embedded IPv4 address,
>>   i.e., Addr(Prf1, IP2)."
>>
>> While I do understand what you're talking about, this is the first time
>> you mention that of "embedded address". Therefore, that of "embedded
>> addresses" should be clarified/explained.
>>
> 
> OK. By way of clarification, the third sentence of Section 1 will be changed to 
> the following:
> 
>  "Automatic tunnels form a category of tunnels in which a
>   packet's egress node's IPv4 address is embedded within the
>   destination IPv6 address of the packet."

Great.



>> **** 9) Section 3.1 (meta-comment):
>>
>> See the "counter-measures" I suggested when discussing each of the
>> attack vectors above. They seem to be simpler than the ones you're
>> proposing here....
> 
> Yes, but only if it can be operationally assured that the case we described 
> above is avoided. 
> 
> We will add these countermeasures in the draft with this reservation.

Ok.



>> **** 11) Section 3.2.1
>>
>> This section talks about the "Neighbor Cache Check". Does such a thing
>> necessarily exist for, e.g., ISATAP?
>>
>> I guess that in the case of Teredo, you're really talking about the
>> "List of recent Teredo peers"?
> 
> As mentioned above, Teredo is not addressed by the draft.

What about ISATAP?

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1