At Mon, 9 Mar 2009 22:24:20 +0000,
Tim Chown <tjc@ecs.soton.ac.uk> wrote:
-rw-rw-r-- 1 fred fred 30429 Nov 3 14:26 draft-chown-v6ops-
rogue-
ra-02.txt
Stig and I have released a new version, in which we attempt to
answer the
list comments:
* Switched focus to accidental RAs - Jinmei
* Clarified valid lifetime
* Reworded DHCP gateway text, noted new draft by Thomas
* Added isolation text - Bob H
* SeND deployment issues expanded - Thomas
* DHCPv6 gateway reworded - emphasised shifting problem
Plus other minor edits and reoriganising.
I've read the 03 version, and confirmed that my concern on the
previous version was clearly addressed (thanks!). I don't know the
intended next step of this document, whether to adopt it as a wg item
or to submit it to the IESG, but I support it in either case.
I have some minor (mostly) editorial comments on 03 as follows:
p.8 Section 3.8: I guess the following paragraph were intended to be
out of scope (simply removed?) according to the revised focus of this
document:
In contrast though, an attacker might use such a tool to learn about
prefixes being advertised on a link and to deprecate the 'good'
RA(s)
in favour of their bogus RA(s).
p.11 Section 4: I failed to parse the following part. There is
perhaps missing text between "configuration" and "However"?
[...] On that basis the RA snooping proposal, e.g. RA
Guard, has merit, while approaches like manual configuration However
RA Guard is not yet fully defined or available, while only certain
managed switch equipment may support the required ACLs.
p.12 Section 5.1: I was not sure if the following part is intended to
be out of scope or is just mentioned to compare with the accidental
rogue RA case:
It is
thus possible for an attacker to target one or more hosts on a
shared
medium without (potentially) a rogue multicast RA being observed
elsewhere on the network (e.g. by a monitoring daemon).
If it's the latter, it would be better to clarify the intent.
p.13 Section 5.5: I understand the following text is a revision to
address my previous comment, but technically it's still 100% clear:
e.g. considering the '2
hour rule' of Section 5.5.3 of RFC4862 (though this applies to the
valid lifetime not the router lifetime). We should ensure that
the 2 hour rule only applies to valid "address" lifetime. Although
the prefix lifetime doesn't officially use this qualifier (since
a prefix only has "the lifetime"), it could be confusing as it's
normally configured from the valid lifetime field of an RA prefix
information option. So, I'd clearly say "valid address lifetime".
p.14 Section 6: based on the intent of the revise, I'd rephrase
"security risk" with "robustness issue" or something:
Adding new DHCPv6 Default Gateway and Prefix Options would allow
IPv6
host configuration by DHCP only, and be a method that IPv4
administrators are comfortable with (for better or worse), but this
simply shifts the security risk elsewhere.
And very minor nits follow:
p.4 Section 1: there are duplicate "also"s. I'd remove one of them:
appears more common in shared wireless environments, it is also seen
on wired enterprise networks also.
p.4 Section 1: I don't like undefined acronyms:-)
the RA message. In addition, rogue RAs can cause hosts to assume
wrong prefixes for their SLAAC addresses. In a case where there may
Since this is the only occurrence, I'd simply say "wrong prefixes to
be used for stateless address autoconfiguration".
p.5 Section 2.2: s/an problem/a problem/
bridging two subnets together, causing an problem similar to VLAN
p.7 Section 3.5: s/send/sends/
accidentally send out a rogue RA on the network has configured their
p.8 Section 3.7: s/no thus/thus/
in the filter may become incorrect and no thus no method would be
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.