Comments on draft-nakibly-v6ops-tunnel-loops

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

Hi Gabi & Fred,

Some comments/questions on/about the aforementioned I-D:

**** 1) Page 3. The I-D states:

" Ref. [USENIX09] pointed out the existence of a
   vulnerability in the design of IPv6 automatic tunnels."

I've read the aforementioned reference ([USENIX09]), and while it is an
interesting read, it seems misleading in some aspects. First of all, I'd
argue that the vulnerabilities that it discusses may be real, they do
not really have to do with "vulnerabilities in the design of IPv6
automatic tunnels". I'd argue that they have to do either with poor
operations practices, or with dumb implementation practices (although
possibly still IETF-spec-compliant).

Please let me exemplify (these a)-e) comments are really about the
Nakibly & Arov paper, but clearly related to this I-D) :

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.


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.


c) Attack #3: ISATAP Router to ISATAP Router

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


**** 2) Section 1:
   "This assumption poses a
   security vulnerability since it may result in an inconsistency
   between a tunnel's overlay IPv6 routing state and the native IPv6
   routing state there by allowing a routing loop to be formed."

I'm not sure this terminology is clear. i.e., overlay IPv6 routing state
vs. native IPv6 routing state.


**** 3) Section 1 (nit):
  "The loop terminates only when
   the Hop Limit field in the IPv6 header of the packet is zeroed out."

s/zeroed out/is decremented to zero/  (sounds better to me)


**** 4) Section 1 (nit):
"SP network"

s/SP/Service Provider (SP)/


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


**** 6) Section 2, page 4 (nit):

"....   they are either both public or both private and belong to the
same internal network."

It might make snse to insert a comma between "public" and "or".


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


**** 8) Section 2, Figure 1:

It would be of much help to have a network diagram. I read this document
before reading [USENIX09], and needed to draw a network diagram myself
to better understand the issues you're discussing. Providing such a
diagram in the I-D would be a plus. (native IPv6 network, IPv4 network
over which packets are tunneled, etc.)


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


**** 10) Sections 3.1/3.1.1

It's not clear to me if the advice in Section 3.1 is supposed to be
different from that in Section 3.1.1. Is Section 3.1.1. simply being
more detailed than Section 3.1?


**** 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"?


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