Subject: RFC 5006 and draft-ietf-v6ops-rogue-ra-01

From: "Dale W. Carder" <[email-masked]>
Date: Tue, 08 Jun 2010 16:24:01 -0500

In the latest version of draft-ietf-v6ops-rogue-ra-01, section
5.5 talks about recovering from an invalid configuration state
w.r.t. the M & O bits.  

Should the document also mentioned that the host may also have 
incorrect, non-functional, or potentially malicious DNS 
configuration due to the host believing bogus RFC 5006 
advertisements?  The host may also need to recover from this
as well.

Dale

---

From: Tim Chown <[email-masked]>
Date: Wed, 9 Jun 2010 14:28:24 +0100

> advertisements?  The host may also need to recover from this

So that's a good question.    When the rogue RA draft was first written, RFC5006 was I recall itself a draft in its infancy.     It's pretty clear that a rogue RA may also be an RA with 'bad' DNS resolver information in it.
 
We could add text about this.   That would involve some mention of the problem in Section 1 (introduction), perhaps a brief discussion as an extra point in Section 5, and adding the mitigation mentioned in draft-ietf-6man-dns-options-bis-02 of disabling the host from processing DNS options in the RA (assuming the host implementation supports that of course, which isn't a MUST in the draft as far as I can see).   Other than that, I think the text in the draft about rogue RA 'badness' is generic enough to cover bad DNS information.   I'm happy to work with Stig on such text if it's deemed useful, and won't hold up publication too much more.

I note that draft-ietf-6man-dns-options-bis-02, which passed 6man WG last call, makes no reference to the rogue RA draft in its own security discussion, and also no mention of RA Guard.

Tim

---

From: Roque Gagliano <[email-masked]>
Date: Thu, 10 Jun 2010 11:15:21 +0200

Hi Tim,

> I note that draft-ietf-6man-dns-options-bis-02, which passed 6man WG last call, makes no reference to the rogue RA draft in its own security discussion, and also no mention of RA Guard.

Why would the dns-option be different from any other ICMPv6 option in this draft context? I would keep the text generic on reference to ICMP options.

Roque

---

From: Roque Gagliano <[email-masked]>
Date: Thu, 10 Jun 2010 11:26:42 +0200

Sorry,

I should have said NDP options and not ICMPv6 options.

Roque.

---

From: Tim Chown <[email-masked]>
Date: Thu, 10 Jun 2010 13:33:52 +0100

Hi Roque,

The draft is focused on rogue RAs as that has been an operational issue for us in our dual-stack enterprise for quite some time.   The potential for additional forms of 'badness' to come from RA-based DNS configuration are worth noting, but the mitigations in general are the same.     There may be some additional mitigation methods specific to the DNS option/configuration.

While we do run tools to detect various forms of NDP 'abuse' on our network, e.g. use of the THC toolkit, we don't (yet) see evidence of that.    The rogue RA problem is far more heavily observed and cited and thus having a consolidated informational problem statement that also describes some potential mitigations focused on that problem is, we believe, useful.   Malicious rogue RAs are quite rare - ones caused by Windows ICS, accidental misconfiguration or devices being moved where their role changes (e.g. 6to4 router at home, client at work) are far more common.   But then we're in a CS dept, so our users tend to be more 'creative'.

We released ramond (http://ramond.sourceforge.net/) as an enhancement to rafixd as one tool for people to use.   RA Guard also has good potential.

Tim

---

From: Roque Gagliano <[email-masked]>
Date: Thu, 10 Jun 2010 15:23:44 +0200

Hi Tim,

My comment still stands. You can also have "badness" (just using your words) in other ICMPv6 ND options:  Source link-layer address or MTU or Nonce or Timestamp options.... The rogue RA document up to now only focused on the Prefix Information option.

Probably the core is that the definition in the P2 of section 1 of what a "bogus" or "bad" RA in the context of the document should be improved.

Regards,
Roque.

---

From: Tim Chown <[email-masked]>
Date: Thu, 10 Jun 2010 15:45:25 +0100

Ah OK, I misunderstood your comment.  Noted now.  

If we revise the document to reflect the RFC5006-based comment we can incorporate your comment.   I don't think that would affect the primary thrust of the document, or its validity.

Tim

---

From: Doug Barton <[email-masked]>
Date: Thu, 10 Jun 2010 14:20:24 -0700

On 06/10/10 05:33, Tim Chown wrote:
> The draft is focused on rogue RAs as that has been an operational
> issue for us in our dual-stack enterprise for quite some time.   The
> potential for additional forms of 'badness' to come from RA-based DNS
> configuration are worth noting, but the mitigations in general are
> the same.     There may be some additional mitigation methods
> specific to the DNS option/configuration.

Speaking as a DNS person, I can do a LOT more harm on your network if I 
can successfully direct your clients onto my malicious name server than 
rerouting their prefix information, and the name server hack will be 
much harder to detect.

Doug

-- 

	... and that's just a little bit of history repeating.
			-- Propellerheads

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/

---

From: Tim Chown <[email-masked]>
Date: Thu, 10 Jun 2010 22:43:23 +0100

On 10 Jun 2010, at 22:20, Doug Barton wrote:
> 
> Speaking as a DNS person, I can do a LOT more harm on your network if I can successfully direct your clients onto my malicious name server than rerouting their prefix information, and the name server hack will be much harder to detect.

Doug, would be good to make these comments on the [email-masked] list where final comments on the RFC5006-bis text are being sought, at the very least wrt the Security Considerations.

Tim