On 1/11/10 7:39 PM, Rémi Després wrote:
Mark,
I may have a few more minor points to review with you when we meet as planned,
but the following are for immediate consideration by all.
In 7.2, after
"However, the 6rd IPv4 relay anycast addresses must be advertised in the service
provider's IGP"
I suggest to add,
" and, to avoid undesirable traffic in 6rd border relays (BRs), should not be
advertised outside the 6rd domain (see also security considerations in [section 12])"
The major point is that the BR IPv4 address be unreachable outside the
6rd domain, and this is one way to help restrict that scope. In that
vein, I think it would be OK to recommend this (but its of course not
the only tool at he operators disposal).
In 9.2, after
"Additionally, a CE MUST allow packets sourced by the configured BR IPv4
Address",
I suggest to add, for anti spoofing,
", provided their IPv6 source address doesn't start with the 6rd prefix".
We've had operators interested in at least having the option to send
traffic through the BR even for CE sourced traffic from within the same
domain. Also, it is useful in some possible transition-to-native
scenarios to allow this. So, unless you have an identifiable security
concern that this helps to mitigate, I'd rather not add this kind of
restriction on the CE (and, it's an extra check, adding to complexity).
I will also try to propose something on routing-loop avoidance.
Thanks. Note that I'd rather avoid a detailed discussion on all the
looping possibilities (that's fine for the research paper Ole cited, or
the slides I put together in Hiroshima, or an Internet Draft on 6rd
Operations that I still hope to see some Operators produce, etc.). For
this document, I think it is better to keep the text limited strictly to
the implementation specification necessary to keep the possibilities of
spoofing and looping limited so 6rd cannot be exploited to invoke a
serious attack. I think we've captured that already, but please let me
know if you think we are missing some important normative language.
- Mark
Cheers,
RD
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
