Hi Joel,
In response to your questions below, 6rd can only be handled by explicit
configuration of known 6rd prefixes. As you indeed mention, there is no
meaningful rule that captures all 6rd prefixes. Regarding ISATAP, indeed
there is a chance of 2^-32 that a non-ISATAP address will be recognized
as an ISATAP-address. In this case, an erroneous drop will occur only if
the lower 32 bits of the IID will be equal to the IP address of the
current host.
The chance of that happening is 2^-32, if the IID is random. This means that
an erroneous drop will occur with a chance of 2^-64, which is very slim
(albeit possible).
Fred and Gabi
*From:* Joel M. Halpern<j...@joelhalpern.com>
*To:* Fred Templin<fltemp...@yahoo.com>
*Cc:* Mary Barnes<mary.ietf.bar...@gmail.com>; gen-art@ietf.org; Joel
Jaeggli<joe...@bogus.com>; Ron Bonica<rbon...@juniper.net>;
draft-ietf-v6ops-tunnel-lo...@tools.ietf.org; IPv6 Operations
<v6...@ops.ietf.org>
*Sent:* Fri, January 7, 2011 12:49:49 PM
*Subject:* Re: [Gen-art] review: draft-ietf-v6ops-tunnel-loops-01.txt
I do not see how 6rd can be handled. There is not really any meaningful
"domain" to use to figure out who is using what 6rd prefix.
And what token does ISATAP use? I presume that I missed something when
the only token I could find was in the lower 64 bits (and tehrefore
could be accidentally duplicated elsewhere.
Thanks,
Joel
On 1/7/2011 3:43 PM, Fred Templin wrote:
> Hi Joel,
>
> Thank you for your time in reviewing this work. In Section 3.1, under
> this proposed
> mitigation the tunnel router ideally indeed must check for all
> encapsulation formats in
> which an IPv4 address may be embedded within an IPv6 address. This means
> that
> the router must check for all known protocol-41 encapsulation formats
> and must be
> modified to check for any new formats should new ones be specified. In
> practice, if
> a router is configured to check only a subset of encapsulation formats,
> then it will be
> immune only to attacks in which the attacker uses the configured
> encapsulation
> formats in the source/destination address of the attack packet.
>
> Certain IPv6 address formats (e.g., 6to4, ISATAP, etc.) include a
well-known
> "token" indicating that an IPv4 address is embedded. Other formats
> (e.g., 6rd)
> do not include such a token and hence would require special
configuration at
> the router to indicate which IPv6 prefixes within the routing domain are
> 6rd ones.
>
> Do you feel there are any additional clarifications on this needed
> beyond what
> already appears in Section 3.1?
>
> Fred and Gabi
>
> *From:* Joel M. Halpern<j...@joelhalpern.com
<mailto:j...@joelhalpern.com>>
> *To:* Mary Barnes<mary.ietf.bar...@gmail.com
<mailto:mary.ietf.bar...@gmail.com>>
> *Cc:* gen-art@ietf.org<mailto:gen-art@ietf.org>; Joel Jaeggli
<joe...@bogus.com<mailto:joe...@bogus.com>>; Ron Bonica
> <rbon...@juniper.net<mailto:rbon...@juniper.net>>;
draft-ietf-v6ops-tunnel-lo...@tools.ietf.org
<mailto:draft-ietf-v6ops-tunnel-lo...@tools.ietf.org>;
> IPv6 Operations<v6...@ops.ietf.org<mailto:v6...@ops.ietf.org>>
> *Sent:* Tue, December 28, 2010 1:43:14 PM
> *Subject:* [Gen-art] review: draft-ietf-v6ops-tunnel-loops-01.txt
>
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document: draft-ietf-v6ops-tunnel-loops-01.txt
> Routing Loop Attack using IPv6 Automatic Tunnels:
> Problem Statement and Proposed Mitigations
> Reviewer: Joel M. Halpern
> Review Date: 28-Dec-2010
> IETF LC End Date: 29-Dec-2010
> IESG Telechat date: 06-Jan-2011)
>
> Summary: Nearly ready for publication as an Informational RFC
>
> Major issues: It is unclear in the document what assumptions section 3.1
> makes about the relationship between supported tunnels and checked
> embedded addresses. Is there an assumption that the router only has to
> check for addresses in the format and prefix it supports? I hope so.
> Otherwise, a router seems to be expected to look at an arbitrary IPv6
> addresses, guess whether it has an embedded IPv4 addresses, and perform
> filter checks on that guessed addresses against its own addresses.
> If indeed their is a relationship, then it would really help if section
> 3.1 said that.
> Unfortunately, I am afraid no such relationship is assumed. If not, I
> would like to see significantly better explanation of how the router is
> to reliably know that there is a 6rd or ISATAP address embedded in the
> v6 address.
>
> Minor issues:
>
> Nits/editorial comments:
