* 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 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
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 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 is
* 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 address
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 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 not the
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:
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, I was
On Mon, Jul 11, 2011 at 8:17 PM, Karl Auer ka...@biplane.com.au 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
On Sun, Jul 17, 2011 at 11:42 AM, William Herrin b...@herrin.us 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
On Jul 17, 2011, at 10:35 AM, Jeff Wheeler wrote:
On Sun, Jul 17, 2011 at 11:42 AM, William Herrin b...@herrin.us 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
On Sun, Jul 17, 2011 at 3:40 PM, Owen DeLong o...@delong.com 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 Sun, Jul 17, 2011 at 1:35 PM, Jeff Wheeler j...@inconcepts.biz wrote:
On Sun, Jul 17, 2011 at 11:42 AM, William Herrin b...@herrin.us 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
On Jul 17, 2011, at 1:17 PM, Jeff Wheeler wrote:
On Sun, Jul 17, 2011 at 3:40 PM, Owen DeLong o...@delong.com 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
On Jul 17, 2011, at 1:32 PM, William Herrin wrote:
On Sun, Jul 17, 2011 at 1:35 PM, Jeff Wheeler j...@inconcepts.biz wrote:
On Sun, Jul 17, 2011 at 11:42 AM, William Herrin b...@herrin.us wrote:
My off-the-cuff naive solution to this problem would be to discard the
oldest incomplete
On Jul 14, 2011, at 8:24 PM, Jimmy Hess wrote:
On Thu, Jul 14, 2011 at 9:35 PM, Jared Mauch ja...@puck.nether.net wrote:
On Jul 14, 2011, at 10:06 PM, Fernando Gont ferna...@gont.com.ar wrote:
Anyone on a layer-2 network can do something interesting like flood all f's
and kill the lan.
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 give
On Thu, Jul 14, 2011 at 9:47 PM, Owen DeLong o...@delong.com 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
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.
On Thu, Jul 14, 2011 at 7:29 PM, Fernando Gont ferna...@gont.com.ar 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
On Jul 14, 2011, at 6:24 PM, Jimmy Hess wrote:
On Thu, Jul 14, 2011 at 7:29 PM, Fernando Gont ferna...@gont.com.ar 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
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 are in the
On Jul 14, 2011, at 10:06 PM, Fernando Gont ferna...@gont.com.ar 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
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 I consider
http://tools.ietf.org/html/draft-gashinsky-v6nd-enhance-00
Sent from my iThing
On Jul 14, 2011, at 10:57 PM, Fernando Gont ferna...@gont.com.ar 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
On Thu, Jul 14, 2011 at 9:35 PM, Jared Mauch ja...@puck.nether.net wrote:
On Jul 14, 2011, at 10:06 PM, Fernando Gont ferna...@gont.com.ar 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
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 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
