draft-chown-v6ops-rogue-ra-03 (Re: Agenda issue)

[JINMEI Tatuya / 神明達哉 <Jinmei_Tatuya@isc.org>]

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.