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>
*To:* Mary Barnes <mary.ietf.bar...@gmail.com>
*Cc:* 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:* 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:
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
