Subject: [v6ops] draft-ietf-v6ops-ra-guard-implementation WGLC

From: Fred Baker <[email-masked]>
Date: Sun, 22 Apr 2012 20:00:05 +0200

This is to initiate a two week working group last call of draft-ietf-v6ops-ra-guard-implementation. Please read it 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: Nick Hilliard <[email-masked]>
Date: Sun, 22 Apr 2012 23:25:10 +0100

On 22/04/2012 19:00, Fred Baker wrote:
> This is to initiate a two week working group last call of
> draft-ietf-v6ops-ra-guard-implementation. Please read it 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.

reading back over this, I wonder would it be useful to make a
recommendation to vendors to implement some form of logging for dropped
packets so that operators can choose to have visibility into this problem
on their networks.  Silently dropping packets is all very well, but many
operators like to feel that if a packet is dropped, they should know about it.

As a tiny nit, the word "basic" appears in consecutive sentences in the
second paragraph of section 1: "The basic concept..." and "The most basic
filtering".

As an L2 IXP operator, I like this draft very much.  It is simply a matter
of time before someone writes a trivial script to mount a DoS attack using
RAs + v6 options, and even though no IXP participant should ever listen to
ipv6 RAs, operator error happens from time to time.

Nick

---

From: Joel jaeggli <[email-masked]>
Date: Sun, 22 Apr 2012 17:50:23 -0700

> operators like to feel that if a packet is dropped, they should know about it.

implementing a drop counter on what's essentially a firewall rule seems
like a good idea, but also an implementation detail. if there's nowhere
to log it and nobody to report it to it's not very useful to count them.
if there are either of those things then yeah it's certainly worthwhile.

> ipv6 RAs, operator error happens from time to time.

Even today inadvertent 6to4 deployments attack consumer networks
including those without ipv6 deployed at a frequency that makes this
useful hygiene.

> Nick
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Ray Hunter <[email-masked]>
Date: Mon, 23 Apr 2012 19:31:33 +0200

I have reviewed this document, and find that it provides important and 
useful advice to the IPv6 operations community.

Fred Baker wrote:
> draft-ietf-v6ops-ra-guard-implementation. Please read it 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: "Bjoern A. Zeeb" <[email-masked]>
Date: Mon, 23 Apr 2012 17:47:45 +0000

> This is to initiate a two week working group last call of draft-ietf-v6ops-ra-guard-implementation. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), com…

I had done so at the mic in v6ops and the same day (March 29) to the list;  the draft has not been changed since to limit the packets dropped by 3.1 to only packets that can actually be RA packets as identifiable in the L3 header already.

I still have concerns as expressed in these emails that we will be dropping things to unreasonable limits that will be put into Silicon and stay around with L2+ devices for at least a decade while not knowing how things like extension headers etc will evolve as development and deployment continues.

/bz

-- 
Bjoern A. Zeeb                                 You have to have visions!
   It does not matter how good you are. It matters what good you do!

---

From: Warren Kumari <[email-masked]>
Date: Mon, 23 Apr 2012 18:21:56 -0400

On Apr 22, 2012, at 2:00 PM, Fred Baker wrote:

> This is to initiate a two week working group last call of draft-ietf-v6ops-ra-guard-implementation.

Yay.

> Please read it now.

No (I read it a while back and it hasn't changed since then :-))

I support publication of this document. I believe it provides useful content and solves an important issue.

W

> 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.
>

---

From: Arturo Servin <[email-masked]>
Date: Tue, 24 Apr 2012 09:57:07 -0300

Support.

.as

---

From: Chuck Anderson <[email-masked]>
Date: Thu, 26 Apr 2012 09:14:03 -0400

> 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 importa…

Support.  This draft is definitely useful operationally.

---

From: james woodyatt <[email-masked]>
Date: Thu, 26 Apr 2012 10:38:20 -0700

> This is to initiate a two week working group last call of draft-ietf-v6ops-ra-guard-implementation. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), com…

I share some of Mr. Zeeb's concerns, but I'm willing to support the draft-- provided that it is updated with an informative reference to "An uniform format for IPv6 extension headers" [RFC6564] in the first numbered paragraph describing the filtering rules in section 3.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: KK <[email-masked]>
Date: Thu, 26 Apr 2012 11:55:56 -0700

I believe that this doc is very useful from an operational point of view. I
support.

On Sun, Apr 22, 2012 at 11:00 AM, Fred Baker <[email-masked]> wrote:

> 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: Fernando Gont <[email-masked]>
Date: Thu, 26 Apr 2012 17:02:15 -0300

On 04/23/2012 02:47 PM, Bjoern A. Zeeb wrote:
>> draft-ietf-v6ops-ra-guard-implementation. Please read it 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.
> 
> I had done so at the mic in v6ops and the same day (March 29) to the
> list;  

And I responded to your e-mail.

> the draft has not been changed since to limit the packets
> dropped by 3.1 to only packets that can actually be RA packets as
> identifiable in the L3 header already.

Clearly, incorporating that would re-introduce the hole of RA-Guard
being trivial to circumvent by means of extension headers and fragmentation.

Packets that do not include the entire IPv6 header chain are not going
to survive in the Internet, because they prevent stateless packet
filtering.

That said, the filtering rules also take into account the Hop Limit, and
the Source Address, so even in those pathological scenarios, the false
positives would be reduce to something very close to nil.

> I still have concerns as expressed in these emails that we will be
> dropping things to unreasonable limits that will be put into Silicon
> and stay around with L2+ devices for at least a decade while not
> knowing how things like extension headers etc will evolve as
> development and deployment continues.

Are you really expecting packets with 1280B+ headers, with the headers
split into multiple fragments??

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Thu, 26 Apr 2012 18:15:40 -0300

Hi, James,

On 04/26/2012 02:38 PM, james woodyatt wrote:
> I share some of Mr. Zeeb's concerns, but I'm willing to support the
> draft-- provided that it is updated with an informative reference to
> "An uniform format for IPv6 extension headers" [RFC6564] in the first
> numbered paragraph describing the filtering rules in section 3.

Just double-cheking: what would be the purpose of such reference? Noting
that even if there's an extension header that they don't support, they
can still parse the packets?

-- I thought this was implicit. But if you think this would be
appropriate and/or valuable, I have no problem with including the
aforementioned reference.

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: james woodyatt <[email-masked]>
Date: Fri, 27 Apr 2012 12:43:34 -0700

On Apr 26, 2012, at 14:15 , Fernando Gont <[email-masked]> wrote:
> 
> I thought this was implicit. But if you think this would be appropriate and/or valuable, I have no problem with including the aforementioned reference.

RFC 6564 is the reason that following the extension header chain all the way to the transport protocol is even *decidable* under the latest standards track documentation.  The principle reason we wrote RFC 6564 in the first place was so that it could be cited in drafts like this one.  It would be a shame if all the effort required to get an update to RFC 2460 for this purpose were to go to waste here.

My worry is that implementors may overlook the uniform extension header specification and encode naïve algorithms in hardware deployments with very long lifespan that incorrectly drop normal packets and/or pass rogue router advertisement packets with otherwise unidentifiable, yet uniform, extension headers.

I'm pleased that you're willing to make this editorial change during WGLC.  Thank you.

---

From: Fernando Gont <[email-masked]>
Date: Sat, 28 Apr 2012 09:38:00 -0300

On 04/27/2012 04:43 PM, james woodyatt wrote:
>> I thought this was implicit. But if you think this would be
> RFC 6564 is the reason that following the extension header chain all
> the way to the transport protocol is even *decidable* under the
> latest standards track documentation. 

Agreed.

> My worry is that implementors may overlook the uniform extension
> header specification and encode naïve algorithms in hardware
> deployments with very long lifespan that incorrectly drop normal
> packets and/or pass rogue router advertisement packets with otherwise
> unidentifiable, yet uniform, extension headers.

Fair enough.

> I'm pleased that you're willing to make this editorial change during
> WGLC.

I've added this parenthetical note right below Filtering Rule #1 of
version -02 of the document:

[RFC6564] specifies a uniform format for IPv6 Extension Headers, thus
meaning that an IPv6 node should be able to parse an IPv6 header chain
even if it contains Extension Headers that are not currently supported
by that node.

Please let me know if this addresses your concern.

Thanks!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 28 Apr 2012 11:01:59 -0300

> if there are either of those things then yeah it's certainly worthwhile.

So... should I add a small comment about this? A "MAY"? (I think
"SHOULD" would be too strong). Or maybe a note without RFC2119-language?

What do you folks think?

Thanks!

Best regards,

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 28 Apr 2012 15:20:39 +0100

> "SHOULD" would be too strong). Or maybe a note without RFC2119-language?

I was thinking along the lines of SHOULD actually. Silently black holing traffic is pretty unforgivable. 

Nick

---

From: Fernando Gont <[email-masked]>
Date: Sat, 28 Apr 2012 11:36:19 -0300

> I was thinking along the lines of SHOULD actually. Silently black holing traffic is pretty unforgivable. 

I was just thinking considering Joel's notes, and considering that if we
were to incorporate this as a SHOULD, and an implementation didn't have
the ability to provide this logging facility, it wouldn't be compliant
with this document. -- but this is just me thinking out loud (of course,
I agree that logging would be useful... just wondering how to actually
incorporate this in the document).

Can others weigh in? -- FWIW, I have no problem incorporating this as a
MAY, SHOULD, or whatever the wg thinks is more appropriate.

Thanks!

Best regards,

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 28 Apr 2012 18:07:56 +0100

> incorporate this in the document).

No, actually: you can omit SHOULDs from an implementation and still be
fully compliant with the rfc.   SHOULD is a recommendation;  MUST is a
requirement.

Nick

---

From: Fernando Gont <[email-masked]>
Date: Sat, 28 Apr 2012 15:35:02 -0300

On 04/28/2012 02:07 PM, Nick Hilliard wrote:
> fully compliant with the rfc.   

I've re-checked, and you're right: such an implementation would be
called: "compliant" or "conditionally compliant". -- I've looked this up
in RFC 2119, and it's not there, so it might be just "common practice"
(similar wording is in many RFCs).. but since I've not got any sleep for
24hs, I will try to find later (hopefully with better luck :-) ).

Thanks!

Best regards,

---

From: james woodyatt <[email-masked]>
Date: Mon, 30 Apr 2012 11:43:08 -0700

> Please let me know if this addresses your concern.

It does, thanks!