Subject: [v6ops] new draft: draft-gashinsky-v6ops-v6nd-problems

From: <[email-masked]>
Date: Fri, 7 Oct 2011 06:55:00 -0700 (PDT)

A new draft has been posted, at http://tools.ietf.org/html/draft-gashinsky-v6ops-v6nd-problems. Please take a look at it and comment.

---

From: Fred Baker <[email-masked]>
Date: Sat, 8 Oct 2011 04:23:18 -0400

> A new draft has been posted, at http://tools.ietf.org/html/draft-gashinsky-v6ops-v6nd-problems. Please take a look at it and comment.

FYI, an rfcdiff of draft-gashinsky-v6nd-enhance and draft-gashinsky-v6ops-v6nd-problems indicates that, apart from minor edits, it is the older draft without sections 7.3 and 7.4, which specify changes to Neighbor Discovery. I would expect that the authors will follow up with a separate draft in 6man regarding their proposed changes.

What we're looking for here is ratification - folks think this is a real problem and a good description of it - and next steps. Opinions?

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 08 Oct 2011 08:22:39 -0400

Having read this, I believe it describes a real problem.
It does a good job describing that problem.
It would seem that for now we should adopt it as a working group 
document, and then work out with 6man what document or documents need to 
be published as RFCs.

Yours,
Joel M. Halpern

On 10/8/2011 4:23 AM, Fred Baker wrote:
>
> On Oct 7, 2011, at 9:55 AM,<[email-masked]>  <[email-masked]>  wrote:
>
>>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Fred Baker <[email-masked]>
Date: Sat, 8 Oct 2011 10:29:26 -0400

On Oct 8, 2011, at 8:22 AM, Joel M. Halpern wrote:

> It would seem that for now we should adopt it as a working group document, and then work out with 6man what document or documents need to be published as RFCs.

I'm willing to do that if there is consensus behind it. I personally am not sure that we actually need to discuss it in Taipei, as the non-protocol content hasn't materially changed. We should be able to discuss it on the list and deal with it. The remaining two sections (the ones this draft removes) are, AFAIK, moving to 6man, as they are a revision of RFC 4861.

Question to the assembled hoards...

1) shall we adopt this as a WG draft?
2) shall we take it directly to WGLC?

You can reply to [email-masked]

---

From: Joel jaeggli <[email-masked]>
Date: Sat, 08 Oct 2011 09:41:50 -0700

On 10/8/11 05:22 , Joel M. Halpern wrote:
>>> A new draft has been posted, at
>>> http://tools.ietf.org/html/draft-gashinsky-v6ops-v6nd-problems.
>>> Please take a look at it and comment.
>>
>> FYI, an rfcdiff of draft-gashinsky-v6nd-enhance and
>> draft-gashinsky-v6ops-v6nd-problems indicates that, apart from minor
>> edits, it is the older draft without sections 7.3 and 7.4, which
>> specify changes to Neighbor Discovery. I would expect that the authors
>> will follow up with a separate draft in 6man regarding their proposed
>> changes.

That is are more or less accurate assement. the only salt to the text
was to strip the enhancements, and standards action text from the draft.

>> What we're looking for here is ratification - folks think this is a
>> real problem and a good description of it - and next steps. Opinions?

---

From: Randy Bush <[email-masked]>
Date: Sat, 08 Oct 2011 20:31:59 -0400

> real problem and a good description of it

i have read it enough times i don't even see it any more.  i like.

randy

---

From: Jared Mauch <[email-masked]>
Date: Sat, 8 Oct 2011 21:04:20 -0400

My only comment is appendix a should be removed.

Otherwise I support adoption and wglc

Sent from my iThing

---

From: Arturo Servin <[email-masked]>
Date: Sun, 9 Oct 2011 01:36:50 -0200

I have read this draft and I support it as WG document.

Regards,
as

Sent from my mobile device
(please excuse typoss and brevit.)

---

From: Victor Kuarsingh <[email-masked]>
Date: Sat, 08 Oct 2011 23:38:50 -0400

I too support this as a WG Document.  This captures an important issue
which requires attention.

Regards,

Victor K

On 11-10-08 11:36 PM, "Arturo Servin" <[email-masked]> wrote:

>>>document, and then work out with 6man what document or documents need
>>>to be published as RFCs.
>> 
>> I'm willing to do that if there is consensus behind it. I personally am
>>not sure that we actually need to discuss it in Taipei, as the
>>non-protocol content hasn't materially changed. We should be able to
>>discuss it on the list and deal with it. The remaining two sections (the
>>ones this draft removes) are, AFAIK, moving to 6man, as they are a
>>revision of RFC 4861.
>>

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Sun, 09 Oct 2011 11:59:12 +0300

I have some questions...

> During testing it was concluded that 4 simultaneous
>     nmap sessions from a low-end computer was sufficient to make a
>     router's neighbor discovery process unhappy and therefore forwarding
>     unusable.

Just out of curiosity, are there more details about the 4 nmap sessions characteristics?

Regarding "6. Operational Mitigation Options", is there any particular order, under which 
the 4 mitigation options are presented?

6.1. Filtering of unused address space.
6.2. Appropriate Subnet Sizing.
6.3. Routing Mitigation.
6.4. Tuning of the NDP Queue Rate Limit.

If i was to take into account the ease and efficiency of implementation, i would say 2,1,4,3.

Regarding "6.3. Routing Mitigation", is anyone using it?
Generally, do you have hosts participating in IGP? I have some hosts running BGP for 
anycast reasons, but i don't know if i ever would do such an action.

Also, not exactly a mitigation option, but you could probably add under 6.4, the option of 
logging a warning when a specific limit has been reached.
The same can be done for 7.2 too, which refers to vendors.

Other that that, i agree that this draft provides very useful information and should go 
for WGLC.

--
Tassos

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 9 Oct 2011 10:29:30 -0500

Even in IPv4 when a subnet range on a router is large, the IP scan
attacks bog down the ARP cache and cause similar problems on a router.
ND causes new issues with NUD.  Granted the IPv6 address range happens
to be very large, but the mitigations are already well-known from IPv4.
ND NUD is being changed with the draft-nordmark-nd-impatient document -
the change also affects IP scan attacks.  Why don't we add a new section
to the impatient document and dispense with this document? 

Also, before we LastCall this document or accept the document as a v6ops
WG document, I would like to see one more revision posted.  Some review
comments are included below.

1. In the Abstract what is "simplistic implementations" of ND?  I would
replace by "current implementations".  Otherwise, I ask what
specifically entails a "simplistic ND implementation?  Other places in
the document use simplistic too.  Please make a global replacement of
the term.

2. Why capitalize "IPv4" and use small-case for "ipv6"?

3. Capitalize 'n' and 'd' in "neighbor discovery" in the document.

4. Some places in the document use "ipv6", other places use "IPV6", and
yet some more places use "IPv6" while the document uses "IPv4" in the
Abstract.  Please make all text for v6 as "IPv6".

5. The document starts with the term of join in double quotes.  In other
place, the term is not quoted.   Please be consistent.  Also, in section
2, change "join the net" to "join the network".

6. In the Terminology section, the document says the Forwarding plane
updates checksum.  What IPv6 router touches the checksum? The IPv6
header has no checksum.

7. In the Terminology section, why use "adjacent neighbor" ?  By
definition a neighbor is on the same link and thus there is no need to
say "adjacent neighbor".  Just say "neighbor".

8. RFC 4861 suffices to define the Neighbor Cache.  Why is the
Terminology section defining the Neighbor Cache again?  I would
reference RFC 4861 for Neighbor Cache.

9. Section 1.1 related to Applicability: an important applicability has
been left out.  Which part of the network does the document addresses?
Core/access/edge/data center?  The core has router interfaces addressed
with a /127.  Specifically, for an access network, there are other
mitigation means that are not even mentioned in this document.  

10. Section 2:  I would consider changing the sentence shown below
because some text is redundant.  Traffic is, of course, impacted if
address resolution fails.  

[The result can be network disruption, where existing traffic may be
impacted, and devices that join the net find that address resolutions
fails.]

11. section 4: Replace "ND-Cache" with "Neighbor Cache".

12. Section 5 is not necessary.

13. Section 3.4: With respect to the text below from the section shown
between square braces.

[It is worth noting that this technique is only worth investigationg if
the device has separate queue for resolution of unknown addresses versus
maintaice of existing entries.]

Depending on where the router is in the network (core/access/edge etc.),
how does the router know an unknown address is not a timed out existing
entry?  Also, please spell-check the whole document - there a quite a
few spelling errors in the document.  

14. Section 7: typo in "IPv4 Neighbor Discovery".  Replace IPv4 with
IPv6.

15.  There is other incomplete text (besides Appendix A) in the document
such as "[XXX say more?]".

16. Section 7.1, bullet 5.  How does the router know what is "never
seen"?  What the rules that define an entry as "never seen"?  Also, the
router reloads and all entries will be "never seen".

As for recommendation for implementers where the draft says prioritize
NS's destined to oneself over the address resolution the router issues
to resolve unknown addresses due to a IP scan attack.  Well, I for a
rogue, will now use the higher prioritized NS destined to oneself
implementation for an attack vector and send many NS messages destined
to the router.  

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Fred Baker (fred)
Sent: Saturday, October 08, 2011 10:29 AM
To: v6ops v6ops WG
Cc: [email-masked]
Subject: Re: [v6ops] new draft: draft-gashinsky-v6ops-v6nd-problems

---

From: Joel jaeggli <[email-masked]>
Date: Sun, 09 Oct 2011 18:21:00 -0700

> Just out of curiosity, are there more details about the 4 nmap sessions

We took some (detail) out in previous iterations. While the low
threshhold for DOSing a given platform varies slightly they're more or
less all vulnerable given a common set if assumptions.

> 
> Regarding "6. Operational Mitigation Options", is there any particular
> order, under which the 4 mitigation options are presented?

The appropriateness of a particular solution will depend on the
application and to some extent the topology of the network...

6.3 for example actually does work for me in data-centera because the
load-balancers can advertise the prefixes they are responsible for as /128s

> If i was to take into account the ease and efficiency of implementation,

Not sure I'd describe that that as ease, certainly 3 is simply
infeasible in a lot of cases. 2,1,4 are more generally usable.

> Regarding "6.3. Routing Mitigation", is anyone using it?

yes, if you consider host in this case to be a load balancer, I do that.
Full L7 http(s) proxy.

> Generally, do you have hosts participating in IGP? 

we do, but actually we use ebgp for what I'd consider the exemplar of this.

> I have some hosts
> running BGP for anycast reasons, but i don't know if i ever would do
> such an action.
> 
> Also, not exactly a mitigation option, but you could probably add under
> 6.4, the option of logging a warning when a specific limit has been
> reached.
> Other that that, i agree that this draft provides very useful
> information and should go for WGLC.
> 
> 
> -- 
> Tassos
> 
> 
>> I'm willing to do that if there is consensus behind it. I personally
>> am not sure that we actually need to discuss it in Taipei, as the
>> discuss it on the list and deal with it. The remaining two sections
>> (the ones this draft removes) are, AFAIK, moving to 6man, as they are
>> a revision of RFC 4861.
>>

---

From: "George, Wes" <[email-masked]>
Date: Mon, 10 Oct 2011 08:42:58 -0400

1) shall we adopt this as a WG draft?
WEG] yes. This is the type of thing I would like to see more of within this WG, as it's based on actual operational experience and presents a real problem rather than "yet another IPv6 *.survey/overview"
2) shall we take it directly to WGLC?
WEG] no. While a lot of Hemant's feedback was nits, I think he's right about needing a revision, hopefully after a few additional substantive reviews. I'm hoping to work on a review this week.

Thanks
Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Fred Baker <[email-masked]>
Date: Mon, 10 Oct 2011 08:49:50 -0400

> WEG] no. While a lot of Hemant's feedback was nits, I think he's right about needing a revision, hopefully after a few additional substantive reviews. I'm hoping to work on a review this week.

I have asked the authors to update the draft with respect to the comments on the list, which will hopefully include yours, and to post the revision as draft-ietf-v6ops-v6nd-problems-00, which is to say as a working group draft.

We'll discuss WGLCs after a round of commentary on that update, probably in December.

---

From: "George, Wes" <[email-masked]>
Date: Mon, 10 Oct 2011 08:54:37 -0400

>From: Hemant Singh (shemant)

>Granted the IPv6 address range happens

WEG] I'm not certain of the point you're trying to make here, whether you're saying that this isn't actually a problem, or that we don't need a new solution, or something else. I'll simply note that if it wasn't a problem and the mitigations were all well-known, we wouldn't be seeing this in production environments.

>to the impatient document and dispense with this document?

WEG] That might be an acceptable suggestion for the portion of draft-gashinsky-v6nd-enhance that is moving to 6man (and I invite you to make it on 6man list), but I think that this document is still necessary for this WG to undertake, as it discusses the problem and several useful mitigation techniques which do not require protocols changes and will therefore be quite important until any protocol refinements are completed and implemented and deployed.

Thanks,
Wes George

---

From: Thomas Narten <[email-masked]>
Date: Mon, 10 Oct 2011 10:24:40 -0400

> 1. In the Abstract what is "simplistic implementations" of ND?  I
> would replace by "current implementations".  Otherwise, I ask what
> specifically entails a "simplistic ND implementation?  Other places
> in the document use simplistic too.  Please make a global
> replacement of the term.

Some "current implementations" have already fixed this problem, I
believe...

As the person (I think) who came up with the wording "simplistic", I
think it is actually quite accurate. What this document points out is
that simplistic implementations (those that just process packets in
order and don't consider how to prioritize under overload conditions)
have problems. The way to address the issue is be more sophisticated
in your implementation.

Other nits should be fixed.

> updates checksum.  What IPv6 router touches the checksum? The IPv6

Ah, that text was assuming IPv4 as well..

> say "adjacent neighbor".  Just say "neighbor".

For emphasis. Something saying the same thing three different ways is
sometimes good for reinforcing the point.

> reference RFC 4861 for Neighbor Cache.

So the reader doesn't have to go lookup 4861 to be reminded of what
the Neighbor Cache is.

> router reloads and all entries will be "never seen".

A router could keep state indicating it has seen a neighbor
before. Such state would be smaller than a full NCE that says
"incomplete". 

> implementation for an attack vector and send many NS messages destined

But such attacks will have to come from a neighbor, or be discarded
(quickly?) due to the Hop Count not being 255. So hopefully not as
effective.

Thomas

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 10 Oct 2011 12:31:37 -0500

Thomas,

Good to hear from you.  Please see in line below.

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Monday, October 10, 2011 10:25 AM
To: Hemant Singh (shemant)
Cc: V6ops Chairs; v6ops v6ops WG;
[email-masked]
Subject: Re: [v6ops] new draft: draft-gashinsky-v6ops-v6nd-problems

>have problems. The way to address the issue is be more sophisticated

Why not replace simplistic with rudimentary or basic? 

>sometimes good for reinforcing the point.

OK.

>So the reader doesn't have to go lookup 4861 to be reminded of what

If that is the case, why append the following text to the definition of
the Neighbor Cache in the document because (a) the information is
incorrect, and (b) why add extra text? 

[Thus it is usually implemented in an ASIC .]

A router fast path can maintain the Neighbor Cache data in CAM, TCAM, or
standard memory, none of which are an ASIC.  I would rather where the
v6nd-problems document makes use of the Neighbor Cache the document adds
a reference to RFC 4861.  

>before. Such state would be smaller than a full NCE that says

So how long does the router keep the entry in "seen a neighbor before"
state?  What are garbage collection rules for this new state of "seen a
neighbor before" because what if the router supports 256K ND clients?
There is potential for memory usage bloat.   Further, as I said earlier,
a router reload purges all entries in the Neighbor Cache.  During router
reload, a genuine data packet arrives at the router destined to a host
in the router downstream but an IP scan attack is also going on.  There
is no table built yet on the router with "seen a neighbor before"
entries.  The IP scan totally hoses the router because the router just
won't be able to create NCE entries nor build its new "seen a neighbor
before" table.  I would elide bullet 5 from section 7.1 because I such a
solution needs carefully design in a 6man document. 

>But such attacks will have to come from a neighbor, 

Of course.  In a broadband deployment the home is an un-trusted domain
and hacked modems can generate the NS attack.  I do think sections 6 and
7 need more flushing out. 

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 10 Oct 2011 12:43:42 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of George, Wes
Sent: Monday, October 10, 2011 8:43 AM
To: V6ops Chairs; v6ops v6ops WG
Cc: [email-masked]
Subject: Re: [v6ops] new draft: draft-gashinsky-v6ops-v6nd-problems

>WEG] no. While a lot of Hemant's feedback was nits, I think he's right
about needing a revision, hopefully after a few additional substantive
reviews. I'm hoping >to work on a review this week.

Incidentally, there are my review comments that I do not see as nits.
Thomas has already closed on 6 below. 

entry?  

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 10 Oct 2011 13:11:35 -0500

-----Original Message-----
From: George, Wes [mailto:[email-masked]] 
Sent: Monday, October 10, 2011 8:55 AM
To: Hemant Singh (shemant); V6ops Chairs; v6ops v6ops WG
Cc: [email-masked]
Subject: RE: [v6ops] new draft: draft-gashinsky-v6ops-v6nd-problems

>WEG] I'm not certain of the point you're trying to make here, whether
you're saying that this isn't actually a problem, or that we don't need
a new solution, or >something else. I'll simply note that if it wasn't a
problem and the mitigations were all well-known, we wouldn't be seeing
this in production environments.

I am saying this IPv6 problem of IP scan by a hacker is a problem we
have seen in IPv4 networks as well.  Thus mitigations applied to the
problem in IPv4 should be well-known (at least to router vendors) and
also applicable to IPv6.  Certainly since the problem in IPv4 is a
serious problem, the problem is equally serious for IPv6 networks as
well.  Grossly speaking, the only new solution we need is related to NUD
because ARP does not have NUD.   Then I said, the
draft-nordmark-6man-nud-impatient-01 is looking at NUD and the Remedy in
draft-nordmark-6man-nud-impatient-01 is also applicable to the IP scan
problem and NUD.

>WEG] That might be an acceptable suggestion for the portion of
draft-gashinsky-v6nd-enhance that is moving to 6man (and I invite you to
make it on 6man list), >but I think that this document is still
necessary for this WG to undertake, as it discusses the problem and
several useful mitigation techniques which do not >require protocols
changes and will therefore be quite important until any protocol
refinements are completed and implemented and deployed.

I already sent an email today that sections 6 and 7 need flushing out.
If these two sections need more work, let's see what else exists in the
draft-gashinsky-v6ops-v6nd-problems to accept the document as a WG
document for v6ops?  Then the document is only left with the Problem
Definition.  I am fine shipping the document with just a Problem
Definition.  Here is why I am pessimistic on Mitigation options in
section 6.

Option 6.1: The authors already acknowledge this is not a manageable
option.
Option 6.2: Backbone routers can be assigned a /127.  What happens when
a router has to use a /64?  Other IETF documents that discuss /127
already mention attack vectors due to a /64 address on such routers -
see RFC 6164.  So why do we need a new document to document an already
documented fact?
Option 6.3: Which host will implement a routing daemon?
Option 6.4: Tuning NDP queue will affect legitimate users and thus it's
not a viable option.

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 10 Oct 2011 18:53:15 -0500

Some more review comments.  Sorry, I did not get to such comments in my
earlier emails.  Thereafter I have one general comment on the document.

Why does the document need bullet 3 in section 7?  Bullet 3 says the
following (copied below between squared braces).

[Neighbor Discovery activity related to traffic sourced by the router
(as opposed to traffic being forwarded by the router) should be given
high priority.]

Well, each of bullet 1 and 2 source traffic from the router and each of
bullet 1 and 2 already stress upon higher priority to traffic sourced by
the router.   So bullet 3 is repeating the same fact and thus bullet 3
could be removed from section 7.

The general comment is: the document in several places stresses upon
sophisticated ND behavior at a router, so why not knock a stake in the
ground and make the document router specific.  If yes, then why does
bullet 4 of section 7 even need to consider RA received by the router?
Most places of the document discuss of router behavior (such as fast
path, etc.) so is there any intent in the document that a host also
follow any recommendation of this document?  If the document intends to
only address router ND behavior, then the Abstract should also reflect
the fact.

Lastly, you may want to hold off on this statement in the security
section.  Do also end the sentence in a period.

[It is not believed that these techniques create additional security or
DOS exposure]

This is what I said earlier for a new attack vector:

"Well, I for a rogue, will now use the higher prioritized NS destined to
oneself implementation for an attack vector and send many NS messages
destined to the router."

Section 7.2 is ok.

Hemant

---

From: Joel jaeggli <[email-masked]>
Date: Mon, 10 Oct 2011 22:19:12 -0700

> only address router ND behavior, then the Abstract should also reflect

it's advice for the operator of networks, and the NDP queue in question
is located in layer 3 forwarding devices. that said the ehancements the
the ND protocol proper, were to ehance availability of ND under duress
are to capture host related behavior (gratuitious NA NDP refreshes)

> [It is not believed that these techniques create additional security or

Will address.

> oneself implementation for an attack vector and send many NS messages

As a locally attached rogue device your ability to complete the DOS is
not greatly enhanced by having at your disposal a higher priority queue,
it's likely that you'll use the same number of packets as before the
enhancement to blow up the router.

---

From: Joel jaeggli <[email-masked]>
Date: Mon, 10 Oct 2011 23:04:46 -0700

On 10/10/11 05:54 , George, Wes wrote:
>> Granted the IPv6 address range happens to be very large, but the
>> mitigations are already well-known from IPv4.
> 
> you're saying that this isn't actually a problem, or that we don't
> need a new solution, or something else. I'll simply note that if it
> wasn't a problem and the mitigations were all well-known, we wouldn't
> be seeing this in production environments.

best practices in ipv4 tend not to build publicy accessible subnets of a
/20 or larger, if you do you background broadcast load from probe
traffic can become considerable.

but realistically speaking if you want to use subnets as designed in
ipv6 e.g. with RA and stateless autoconfiguration then they need to be
/64s, which makes all subnets that subscribe to that assumption targets
for this sort of attack. that may not be a problem if your subnet is
behind a stateful device that doesn't allow incoming connections, but in
general it's a consideration.

>> ND NUD is being changed with the draft-nordmark-nd-impatient
>> document - the change also affects IP scan attacks.  Why don't we
>> add a new section to the impatient document and dispense with this
>> document?
> 
> draft-gashinsky-v6nd-enhance that is moving to 6man (and I invite you
> to make it on 6man list), but I think that this document is still
> several useful mitigation techniques which do not require protocols
> Thanks, Wes George
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or
> subject to copyright belonging to Time Warner Cable. This E-mail is
> intended solely for the use of the individual or entity to which it
> is addressed. If you are not the intended recipient of this E-mail,
> you are hereby notified that any dissemination, distribution,
> copying, or action taken in relation to the contents of and
> attachments to this E-mail is strictly prohibited and may be
> unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any
> copy of this E-mail and any printout.
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 11 Oct 2011 12:16:57 -0500

Joel,

Good to hear from you.  Thanks much for the closure on my other comments
- I agree with your responses.   Please see in line below.

-----Original Message-----
From: Joel jaeggli [mailto:[email-masked]] 
Sent: Tuesday, October 11, 2011 1:19 AM
To: Hemant Singh (shemant)
Cc: V6ops Chairs; v6ops v6ops WG;

>enhancement to blow up the router.

Agree.  However, my point was that the new higher priority queue can be
exploited and thus what did a new higher priority queue bring to the
table?   

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 11 Oct 2011 12:43:27 -0500

-----Original Message-----
From: Joel jaeggli [mailto:[email-masked]] 
Sent: Tuesday, October 11, 2011 2:05 AM
To: George, Wes
Cc: Hemant Singh (shemant); V6ops Chairs; v6ops v6ops WG;

>traffic can become considerable.

Seem like best practices for a corporate LAN.  In the SP space, one
access concentrator (also a router) can support up to 64K and new
generation concentrators will go up to 128K modems.  Each modem on
average has one host behind the modem.  Thus the number is 128K or 256K
hosts in such a subscriber-edge access concentrator.  IP subnet
allocations are very different in such a deployment and also more
susceptible to IP scan attacks.

ipv6 e.g. with RA and stateless autoconfiguration then they need to be
/64s, which makes all >subnets that subscribe to that assumption targets
for this sort of attack. 

Correct.

>that may not be a problem if your subnet is behind a stateful device
that doesn't allow incoming connections, but in general it's a
consideration.

Right and the consideration for /64's has to be made.  It's good that
the draft-gashinsky-v6ops-v6nd-problems is addressing the /64 as well.

Hemant

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Tue, 11 Oct 2011 20:57:24 +0300

Do you believe that the disabling of ND or defining static neighbors could be considered as a mitigation option?
Both are applicable in combination with "6.2. Appropriate Subnet Sizing", but static definition of neighbors could also 
stand by its own.

--
Tassos

---

From: Joel jaeggli <[email-masked]>
Date: Tue, 11 Oct 2011 11:56:03 -0700

On 10/11/11 10:57 , Tassos Chatzithomaoglou wrote:
> 
> Do you believe that the disabling of ND or defining static neighbors
> could be considered as a mitigation option?

I don't think it's realistic for networks that cannot already reduce
subnet size, e.g. one's that rely on router advertisement. and defeating
neighbor unreachability detection poses problems of it's own for devices
which are not routers.

joel

> Both are applicable in combination with "6.2. Appropriate Subnet
> Sizing", but static definition of neighbors could also stand by its own.
> 
> -- 
> Tassos
>

---

From: Joel jaeggli <[email-masked]>
Date: Fri, 14 Oct 2011 10:35:40 -0700

> exploited and thus what did a new higher priority queue bring to the

in some real sense it's the low priority queue that's new. so if
implemented properly the new innovation is that the items in the low
priority queue cannot preclude the things in the high priority queue
from happening. the high priority queue will crowd out the low priority
queue in degenerate circumstances which is pretty much the same as today.