Subject: Rogue RA WGLC

From: Fred Baker <[email-masked]>
Date: Tue, 18 Nov 2008 13:22:02 -0600

This is to initiate a two week working group last call of draft-chown- 
v6ops-rogue-ra-02.txt and draft-ietf-v6ops-ra-guard-01.txt. Please  
read these drafts now. If you find nits (spelling errors, minor  
suggested wording changes, etc), comment to the authors; if you find  
greater issues, such as disagreeing with a statement or finding  
additional issues that need to be addressed, please post your comments  
to the list.

We are looking specifically for comments on the importance of the  
document as well as its content. If you have read the document and  
believe it to be of operational utility, that is also an important  
comment to make.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Nov 2008 08:23:54 +0200 (EET)

On Tue, 18 Nov 2008, Fred Baker wrote:
> This is to initiate a two week working group last call of 
> draft-chown-v6ops-rogue-ra-02.txt and draft-ietf-v6ops-ra-guard-01.txt.

At least according to the I-D tracker, the former is not even a WG 
document yet, so it's not clear how we could have a WG LC on it. Is 
this an omission in I-D tracker document state or something else?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Tim Chown <[email-masked]>
Date: Wed, 19 Nov 2008 10:05:53 +0000

> this an omission in I-D tracker document state or something else?

That was my mistake - I believe it was agreed to be adopted in Dublin, 
but I submitted it as a personal -02 rather than a WG -00 text.

If it helps, I can resubmit it as a WG -00, just let me know.

-- 
Tim

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Nov 2008 14:22:46 +0200 (EET)

> If it helps, I can resubmit it as a WG -00, just let me know.

OK.  The secretariat can also mark non-draft-ietf-<wg> drafts as WG 
documents and then they show up properly in I-D tracker (and probably 
also on tools.ietf.org).  I know some WG chairs use this feature if 
the time between acceptance and submitting a WG -00 is long, or folks 
don't want to rename a draft.

---

From: Fred Baker <[email-masked]>
Date: Wed, 19 Nov 2008 17:08:25 -0600

On Nov 19, 2008, at 6:22 AM, Pekka Savola wrote:

> documents and then they show up properly in I-D tracker (and  
> probably also on tools.ietf.org).  I know some WG chairs use this  
> feature if the time between acceptance and submitting a WG -00 is  
> long, or folks don't want to rename a draft.

I have simply presumed that Ron can advance it accordingly. If he  
wants it resubmitted-or-whatever, so be it.

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Thu, 20 Nov 2008 02:30:55 +0200

Hello,

As promised, here is my review.

I am a bit concerned that the document seems (at least in certain places) to 
focus solely on getting an incorrect default gateway. Rogue RAs cause hosts 
to assume wrong prefixes for their SLAAC addresses. In case of mixing "good" 
and "bad" RAs, the host might keep on using the "good" default gateway, but 
pick a wrong source address. This is highly likely to break, due to ingress 
filtering or lack of return routability.

Because of this, I am even more suspicious about the usefulness of the DHCPv6 
solution than the authors are.

Last, please s/Courmant/Courmont/ :)

-- 
Rémi Denis-Courmont

---

From: Fred Baker <[email-masked]>
Date: Thu, 20 Nov 2008 10:14:41 -0600

So I understand your comment as less than supportive of the document.  
In what ways do you believe it needs to change?

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Thu, 20 Nov 2008 18:40:18 +0200

> In what ways do you believe it needs to change?

I am just dubious about the DHCPv6 solution. I think it needs to be better 
studied, so that we understand what (if anything) it would solve.

-- 
Rémi Denis-Courmont

---

From: Fred Baker <[email-masked]>
Date: Thu, 20 Nov 2008 17:22:24 -0600

On Nov 20, 2008, at 10:40 AM, Rémi Denis-Courmont wrote:

>> So I understand your comment as less than supportive of the  
>> document. In what ways do you believe it needs to change?
>
> I am just dubious about the DHCPv6 solution. I think it needs to be  
> better studied, so that we understand what (if anything) it would  
> solve.

I think operational folks can tell you pretty quickly what it solves.  
It enables an operator to specify an address for an end system as  
opposed to letting the end system dream one up. There are a set of  
people who think that is important. In this context, it also allows  
them to specify to a host what default gateway to choose with a view  
to not choosing others.

If the argument is "I just think people should be using  
autoconfiguration", I have no problem with autoconfiguration, but I  
know network managers that do. "I don't like it" is no where near as  
useful a comment as "I have identified a problem".

Given that context, what do you believe needs to change in the document?

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 21 Nov 2008 02:12:42 +0200

On Friday 21 November 2008 01:22:24 Fred Baker, you wrote:
> people who think that is important.

That I understand, and I don't question.

*But*, in the face of a rogue RA specifying autoconfiguration, SLAAC is 
re-enabled, regardless of the legitimate RA and DHCPv6 processing. If I'm 
mistaken and the DHCPv6 solution work, then the document should clearly say 
so. If, as I suspect, it does not solve the problem, then that should also be 
stated.

> Given that context, what do you believe needs to change in the document?

I am not very happy with "[DHCPv6] ramifications remain unclear, and such a 
fundamental change to the IPv6 model of autoconfiguration would need very 
careful consideration."

But if everybody else thinks that's fine, then I will simply shut up.

-- 
Rémi Denis-Courmont

---

From: james woodyatt <[email-masked]>
Date: Thu, 20 Nov 2008 19:19:27 -0600

On Nov 20, 2008, at 17:22, Fred Baker wrote:
> I think operational folks can tell you pretty quickly what it  
> solves. It enables an operator to specify an address for an end  
> system as opposed to letting the end system dream one up.

Strictly speaking, it enables an operator to translate the MAC address  
of an endpoint interface into its assigned IPv6 interface address.   
It's ICMPv6 RA that specifies that an endpoint interface isn't allowed  
to dream up its own address.  I mention this distinction because it's  
important to the point I make below.

> useful a comment as "I have identified a problem".

Network managers who think it's important to be able to control the  
assignment of IPv6 interface addresses to physical interfaces often  
make the mistake of assuming that MAC addresses are fixed on hardware  
manufacturing lines and cannot be changed in user software.

I'm here to say that's a painfully stupid mistake.

Whatever could possibly be the point of disabling address self- 
assignment on a subnet when the network management system cannot be  
certain either A) that the device presenting a specific MAC address to  
the network is the same device that presented it last time, or B) that  
the device presenting you a particular MAC address this time will ever  
present that MAC address to you again in the future?

If you deploy a network management system that insist on pairing a MAC  
address with a specific managed entity [especially, a *billable*  
entity], then you will be forcing people like me to make MAC address  
cloning even easier to do than it already is... (and don't think I'm  
at a loss for ideas about how to do that).

Is encouraging MAC address cloning what we are trying to do here?   
Because I have a hard time believing it.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Fred Baker <[email-masked]>
Date: Fri, 21 Nov 2008 09:05:59 -0600

On Nov 20, 2008, at 7:19 PM, james woodyatt wrote:

> make the mistake of assuming that MAC addresses are fixed on  
> hardware manufacturing lines and cannot be changed in user software.
>

Well...

So I use a Mac at work. When NAC first came out, my network managers  
asked me to change my MAC address to one they had chosen to identify  
the device as a Mac. That wasn't too hard on Jaguar or Tiger,  
whichever it was, for the fixed interface; for the wireless interface,  
it was impossible. And btw, on the fixed interface it would  
occasionally revert to the hardware address even though it had been  
changed in the configuration files.

I would be careful about painting people as stupid. There is a lot of  
paint in that can.

---

From: Fred Baker <[email-masked]>
Date: Fri, 21 Nov 2008 09:02:08 -0600

OK, thanks. Those are two comments that Tim and Stig can clean up.

---

From: james woodyatt <[email-masked]>
Date: Fri, 21 Nov 2008 10:21:46 -0600

On Nov 21, 2008, at 09:05, Fred Baker wrote:
>
> I would be careful about painting people as stupid. There is a lot  
> of paint in that can.

Point taken.  I'd like to take it back and use "shortsighted"  
instead.  I'd like to leave the qualifying word "painfully" in place,  
however...

---

From: Ralph Droms <[email-masked]>
Date: Fri, 21 Nov 2008 15:10:36 -0500

Wonder if anyone else notices the irony of these adjectives coming  
from a company that refuses to deploy any DHCPv6 service with its  
products?

- Ralph, who takes a size 40R asbestos suit...

On Nov 21, 2008, at Nov 21, 2008,11:21 AM, james woodyatt wrote:

> instead.  I'd like to leave the qualifying word "painfully" in  
> place, however...
>
>
> --

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 21 Nov 2008 13:49:50 -0800

DHCPv6 would indeed be very nice.

Fred
[email-masked]

>-----Original Message-----
>From: Ralph Droms [mailto:[email-masked]]
>Sent: Friday, November 21, 2008 12:11 PM
>To: james woodyatt
>Cc: Ralph Droms; IPv6 Operations
>Subject: Re: DHCP6 and RA,M=1,PIO,A=0
>

---

From: Mark Smith <[email-masked]>
Date: Sun, 23 Nov 2008 10:01:07 +1030

Hi James,

On Thu, 20 Nov 2008 19:19:27 -0600

> at a loss for ideas about how to do that).

The remedy to that problem or threat already exists in some carrier
equipment. Some ADSL DSLAMs are able to perform MAC
address translation (yes, NAT at layer 2 :-( ), converting customer's
MAC addresses, regardless of what they are, into locally assigned
addresses, unique within the ethernet backhaul network. 

Of course, the same old NAT issues of addresses embedded in the payload
come up. This works fine with PPPoE (no CPE addresses in payload IIRC),
and I think IPv4 ARP (they translate the MAC addresses in the payload),
but I don't think layer 2 NAT is supported for IPv6 ND/RA yet. I don't
really like the idea, but with people like you around ... :-)

> Because I have a hard time believing it.

Regards,
Mark.

---

From: Bob Hinden <[email-masked]>
Date: Sat, 22 Nov 2008 16:22:58 -0600

Hi,

Some comments on <draft-chown-v6ops-rogue-ra-02.txt>.

Bob

----------

A class of solution that is missing from the draft is NAC (Network  
Access Control) devices that look for bogus traffic (RAs in this case)  
and have the ability to disable or quarantine the device by  
controlling the appropriate switch port.  This is a hybrid of some of  
the methods suggested in the draft.

I think the discussion in the document of using DHCPv6 as a solution  
to rogue RA problem overstates the utility of this as a possible  
solution as it only moves the problem.  DHC has the same class of  
problems rogue DHC servers, misconfigured DHC servers, etc., etc.  We  
haven't seen this as much in DHCPv6, but it's only a matter of time as  
it's very common in IPv4.  Just ask a university ISP what happens when  
the students appear in the fall and plug in their own WLAN AP in the  
their dorm room.  A zillion rogue DHC servers.

It would be nice to make this clearer in the draft.

I think it would make sense to expand the draft to cover both Rogue  
RAs and Rouge DHCPv6 servers as I think we will need solutions for  
both protocols and the problems are very similar.

Bob

---

From: Thomas Narten <[email-masked]>
Date: Wed, 26 Nov 2008 15:04:01 -0500

I agree with Bob's comments.

Upleveling, the difficulty I have with this document is that it mostly
just expands on the obvious -- namely that RAs do bad things when they
come from intruders or misconfigured sources.

About SEND, it says:

   3.2.  Secure Neighbor Discovery

   The SeND [4] protocol provides a method for hosts and routers to
   perform secure Neighbor Discovery.  At present there are very few
   SeND implementations available, and SeND is perceived as a complex
   protocol to deploy.  It is also likely that not all scenarios will be
   able to use SeND, for various reasons.  In particular SeND may be
   best suited for fully managed enterprise networks, rather than those
   where administrative control is not present.

This really needs to be expanded upon. The document later suggests that
SEND is really the best/most promising fix.

Consequently, we really should have a better technical explanation
than "perceived as complex", which is a non-technical way of
dismissing something without having to actually justify the statement.

If SEND has real issues with getting implemented/deployed, we should
explain what they are so we can figure out what to do about
them. Otherwise, this document should more strongly encourage people
to implement SEND, as the best way to fix the problems outlined in the
document.

I also agree that the vulnerabilities that are highlighted here are
pretty much the same in DHCP. I think one document that covers both
would be better, so as not to give the false impression (if that is
indeed the conclusion) that DHCP has advantages from a security
perspective.

---

From: Thomas Narten <[email-masked]>
Date: Wed, 26 Nov 2008 15:24:10 -0500

Fred Baker <[email-masked]> writes:

> v6ops-rogue-ra-02.txt and draft-ietf-v6ops-ra-guard-01.txt.

What is the intended status of the ra-guard document? Informational?
(I would assume it is not going on standards track, since the proposed
behavior only loosely specified.)

At this point, I lean against publishing this document at all (in
fairness, I also opposed taking it on as WG document at all.)

My overall issue with it is that it offers little utility (IMO) beyond
that provided by simple L2 filtering. E.g., just dropping all RAs from
ports other than those that are authorized to send RAs. I would assume
existing switches support this sort of thing, and I can't think of an
example right off where an IETF document was published to encourage
such behavior. I.e., vendors are generally smart enough to provide
such facilities already, and don't need an IETF document to do so. If,
the IETF were to publish a document, I think it would be more useful
for it to clearly describe what sorts of port blocking filters should
be provided (and why), so vendors would understand the benefits of
doing so. But again, IMO, just simple filtering is sufficient, and
having an RA Guard entity that looks at RAs, compares them against
detailed configuration information for validity (which, btw, is yet
more one place where misconfiguration can mess things up), doesn't
have sufficient benefits to recommend.

On details of the "stateful learning", the LEARNING state seems to me
to be rather simplistic and would be ineffective after, say, a power
failure. Given it's overall lack of robustness, I have doubts it is
worth recommending this.

Thomas

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Wed, 26 Nov 2008 16:03:47 -0500

I consider the main contribution of this draft to be the interaction
with SeND in order to find out whether an RA sent is legitimate or not,
and then automatically configuring the appropriate ACL.  The fact that
this ACL may go away upon reboot, and may have to be reauthorized is not
sufficient IMHO to block this document at WGLC.  I agree with you that
the intended status should be listed on the document.  The only other
addition I would make to the document (if it can be done at WGLC) would
be to elucidate the protocol-level details of the interaction between RA
Guard and SeND.

Pending such additions, I fully support this document at WGLC.

- Wes 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Thomas Narten
Sent: Wednesday, November 26, 2008 3:24 PM
To: Fred Baker (fred)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: WGLC for draft-ietf-v6ops-ra-guard-01.txt (was: Re: Rogue RA
WGLC)

My overall issue with it is that it offers little utility (IMO) beyond
that provided by simple L2 filtering. E.g., just dropping all RAs from
ports other than those that are authorized to send RAs. I would assume
existing switches support this sort of thing, and I can't think of an
example right off where an IETF document was published to encourage such
behavior. I.e., vendors are generally smart enough to provide such
facilities already, and don't need an IETF document to do so. If, the
IETF were to publish a document, I think it would be more useful for it
to clearly describe what sorts of port blocking filters should be
provided (and why), so vendors would understand the benefits of doing
so. But again, IMO, just simple filtering is sufficient, and having an
RA Guard entity that looks at RAs, compares them against detailed
configuration information for validity (which, btw, is yet more one
place where misconfiguration can mess things up), doesn't have
sufficient benefits to recommend.

On details of the "stateful learning", the LEARNING state seems to me to
be rather simplistic and would be ineffective after, say, a power
failure. Given it's overall lack of robustness, I have doubts it is
worth recommending this.

Thomas

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 26 Nov 2008 16:19:21 -0500

failure.  

ACLs created can be saved in non-volatile memory so that the information
is saved across reboots and any ACL after reboot may be removed or
updated based on new information - this is what most routers or switches
do today with ACLs.  It's not like this issue is a bug in the protocol.
A protocol needs to be discussed at the level of what happens if a
network interface on a node is reset, not in terms of what a vendor
saves in non-volatile memory.  Or if this is an nagging issue, then the
information can also be dumped during the router/switch operation, on a
periodic basis, to a network server from which the information can be
retrieved after reboot.

Some edits are needed to the doc, but otherwise it looks OK to me - I
support this draft.

Hemant