On Jul 17, 2011, at 1:32 PM, William Herrin wrote:
> On Sun, Jul 17, 2011 at 1:35 PM, Jeff Wheeler wrote:
>> On Sun, Jul 17, 2011 at 11:42 AM, William Herrin wrote:
>>> My off-the-cuff naive solution to this problem would be to discard the
>>> oldest incomplete solicitation to fit the new one a
On Jul 17, 2011, at 1:17 PM, Jeff Wheeler wrote:
> On Sun, Jul 17, 2011 at 3:40 PM, Owen DeLong wrote:
>> Basically an ND entry would have the following states and timers:
>
> I've discussed what you have described with some colleagues in the
> past. The idea has merit and I would certainly no
On Sun, Jul 17, 2011 at 1:35 PM, Jeff Wheeler wrote:
> On Sun, Jul 17, 2011 at 11:42 AM, William Herrin wrote:
>> My off-the-cuff naive solution to this problem would be to discard the
>> oldest incomplete solicitation to fit the new one and, upon receiving
>> an apparently unsolicited response t
On Sun, Jul 17, 2011 at 3:40 PM, Owen DeLong wrote:
> Basically an ND entry would have the following states and timers:
I've discussed what you have described with some colleagues in the
past. The idea has merit and I would certainly not complain if
vendors included it (as a knob) on their boxes
On Jul 17, 2011, at 10:35 AM, Jeff Wheeler wrote:
> On Sun, Jul 17, 2011 at 11:42 AM, William Herrin wrote:
>> My off-the-cuff naive solution to this problem would be to discard the
>> oldest incomplete solicitation to fit the new one and, upon receiving
>> an apparently unsolicited response to
On Sun, Jul 17, 2011 at 11:42 AM, William Herrin wrote:
> My off-the-cuff naive solution to this problem would be to discard the
> oldest incomplete solicitation to fit the new one and, upon receiving
> an apparently unsolicited response to a discarded solicitation,
> restart the process flagging
On Mon, Jul 11, 2011 at 8:17 PM, Karl Auer wrote:
> RFC3756 IPv6 Neighbor Discovery (ND) Trust Models and Threats
>
> In this attack, the attacking node begins fabricating addresses with
> the subnet prefix and continuously sending packets to them. The last
> hop router is obligated to reso
* Mikael Abrahamsson:
> On Sun, 17 Jul 2011, Florian Weimer wrote:
>
>> Interesting, thnaks. It's not the vendors I would expect, and it's
>> not based on SEND (which is not surprising at all and actually a
>> good thing).
>
> Personally I think SEND is never going to get any traction.
Last time
On Sun, 17 Jul 2011, Florian Weimer wrote:
> Interesting, thnaks. It's not the vendors I would expect, and it's not
> based on SEND (which is not surprising at all and actually a good
> thing).
Personally I think SEND is never going to get any traction.
> Is this actually secure in the sense
* Mikael Abrahamsson:
> On Sun, 17 Jul 2011, Florian Weimer wrote:
>
>> Others use tunnels, PPPoE or lots of scripting, so certainly
>> something can be done about it. To my knowledge, SAVI SEND is still
>> at a similar stage. Pointers to vendor documentation would be
>> appreciated if this is n
On Sun, 17 Jul 2011, Florian Weimer wrote:
> Others use tunnels, PPPoE or lots of scripting, so certainly something
> can be done about it. To my knowledge, SAVI SEND is still at a similar
> stage. Pointers to vendor documentation would be appreciated if this is
> not the case.
--
Mikael
* Mikael Abrahamsson:
> On Sun, 17 Jul 2011, Florian Weimer wrote:
>
>> In practice, the IPv4 vs IPv6 difference is that some vendors
>> provide DHCP snooping, private VLANs and unicast flood protection in
>> IPv4 land, which seems to provide a scalable way to build Ethernet
>> networks with addre
On Sun, 17 Jul 2011, Florian Weimer wrote:
> In practice, the IPv4 vs IPv6 difference is that some vendors provide
> DHCP snooping, private VLANs and unicast flood protection in IPv4 land,
> which seems to provide a scalable way to build Ethernet networks with
> address validation---but there i
On Jul 17, 2011, at 4:15 PM, Florian Weimer wrote:
> In practice, the IPv4 vs IPv6 difference is that some vendors provide DHCP
> snooping, private VLANs and unicast flood protection in IPv4
> land, which seems to provide a scalable way to build Ethernet networks with
> address validation---but
On Jul 15, 2011, at 10:24 AM, Jimmy Hess wrote:
> In most cases if you have a DoS attack coming from the same Layer-2 network
> that a router is attached to,
> it would mean there was already a serious security incident that occured to
> give the attacker that special point to attack fr
This s
* Jared Mauch:
> Solving a local attack is something I consider different in scope
> than the current draft being discussed in 6man, v6ops, ipv6@ etc...
That's not going to happen because it's a layering violation between
the IETF and IEEE. It has not been solved during thirty years of IPv4
over
On Thu, Jul 14, 2011 at 9:47 PM, Owen DeLong wrote:
>
> Very true. This is where Mr. Wheeler's arguments depart from reality. He's
> right
> in that the problem can't be truly fixed without some very complicated code
> added
> to lots of devices, but, it can be mitigated relatively easily and m
On Thu, 14 Jul 2011 23:13:03 PDT, Owen DeLong said:
> On Jul 14, 2011, at 8:24 PM, Jimmy Hess wrote:
> > In most cases if you have a DoS attack coming from the same Layer-2
> > network that a router is attached to,
> > it would mean there was already a serious security incident that
> > occured to
On Jul 14, 2011, at 8:24 PM, Jimmy Hess wrote:
> On Thu, Jul 14, 2011 at 9:35 PM, Jared Mauch wrote:
>> On Jul 14, 2011, at 10:06 PM, Fernando Gont wrote:
>> Anyone on a layer-2 network can do something interesting like flood all f's
>> and kill the lan. Trying to keep the majority of thoughts
On 07/15/2011 12:24 AM, Jimmy Hess wrote:
> A similarly hazardous situation exists with IPv4, and it is basically
> unheard of for IPv4's Layer 2/ARP security weaknesses to be exploited
> to create a DoS condition, even though they can be (very easily),
IMO, the situation is different, in that
On Thu, Jul 14, 2011 at 9:35 PM, Jared Mauch wrote:
> On Jul 14, 2011, at 10:06 PM, Fernando Gont wrote:
> Anyone on a layer-2 network can do something interesting like flood all f's
> and kill the lan. Trying to keep the majority of thoughts here for layer-3
> originated attacks, even if the t
http://tools.ietf.org/html/draft-gashinsky-v6nd-enhance-00
Sent from my iThing
On Jul 14, 2011, at 10:57 PM, Fernando Gont wrote:
> On 07/14/2011 11:35 PM, Jared Mauch wrote:
>
>>> Well, unless there's some layer-2 anti-spoofing mitigation in
>>> place, with /64 subnets the "local attacker" ty
On 07/14/2011 11:35 PM, Jared Mauch wrote:
>> Well, unless there's some layer-2 anti-spoofing mitigation in
>> place, with /64 subnets the "local attacker" typically *will* have
>> enough addresses.
>
> Solving a local attack
Well, I was talking about not *introducing* ;-) one.
> is something
On Jul 14, 2011, at 10:06 PM, Fernando Gont wrote:
>> It should be possible to mitigate this, so long as the attack does not
>> actually
>> originate from a neighbor on the same subnet as a router IP interface on
>> an IPv6 subnet with sufficient number of IPs.
>
> Well, unless there's some
On 07/14/2011 10:24 PM, Jimmy Hess wrote:
>> In this particular case, if the implementation enforces a limit on the
>> number of entries in the "INCOMPLETE" state, then only nodes that have
>> never communicated with the outside world could be affected by this
>> attack. And if those entries that a
On Jul 14, 2011, at 6:24 PM, Jimmy Hess wrote:
> On Thu, Jul 14, 2011 at 7:29 PM, Fernando Gont wrote:
>> On 07/11/2011 09:17 PM, Karl Auer wrote:
>> Vulnerability to this specific issues has a great deal to do with the
>> implementation. After all, whenever there's a data structure that can
> Y
On Thu, Jul 14, 2011 at 7:29 PM, Fernando Gont wrote:
> On 07/11/2011 09:17 PM, Karl Auer wrote:
> Vulnerability to this specific issues has a great deal to do with the
> implementation. After all, whenever there's a data structure that can
Yes
> In this particular case, if the implementation enf
On 07/11/2011 09:17 PM, Karl Auer wrote:
> I realise this is not "specific implementations" as you requested, but
> it seems to me that the problem is generic enough not to require that.
>
> The attack is made possible by the design of the protocol, not any
> failing of specific implementations. S
On Mon, 2011-07-11 at 18:48 -0500, Jimmy Hess wrote:
> It would be useful to at least have the risk properly described, in
> terms of what kind of DoS condition could arise on specific implementations.
RFC3756 IPv6 Neighbor Discovery (ND) Trust Models and Threats
Section 4.3.2
In this attack,
29 matches
Mail list logo
