On 1/11/2011 10:57 AM, valdis.kletni...@vt.edu wrote:
The same exact way you currently track down an IP address that some machine has
started using without bothering to ask your DHCP server for an allocation, of
course.
But it's no easier. Especially when you hit the customer equipment. NAT
On Mon, 10 Jan 2011 22:22:32 CST, Jack Bates said:
> Really? Which machine was using the privacy extension address on the
> /64? I don't see how it's made it any easier to track. In some ways, on
> provider edges that don't support DHCPv6 IA_TA and relay on slaac, it's
> one extra nightmare.
T
On Jan 10, 2011, at 8:22 PM, Jack Bates wrote:
> On 1/10/2011 6:33 PM, valdis.kletni...@vt.edu wrote:
>> I'd say on the whole, it's a net gain - the added ease of tracking down
>> the click-here-to-infect machines that are no longer behind a NAT
>> outweighs the little added security the NAT adds
On 1/10/2011 6:33 PM, valdis.kletni...@vt.edu wrote:
I'd say on the whole, it's a net gain - the added ease of tracking down
the click-here-to-infect machines that are no longer behind a NAT
outweighs the little added security the NAT adds (above and beyond
the statefulness that both NAT and a go
On Jan 10, 2011, at 4:22 PM, Jeff Kell wrote:
> On 1/10/2011 6:55 PM, Owen DeLong wrote:
>> Nonetheless, NAT remains an opaque screen door at best.
>>
>> If the bad guy is behind the door, it helps hide him.
>>
>> If the bad guy is outside the door, the time it takes for his knife to cut
>> th
On Mon, 10 Jan 2011 19:22:46 EST, Jeff Kell said:
> It is a decreasing risk, given the typical user initiated compromise of
> today (click here to infect your computer), but a non-zero one.
>
> The whole IPv6 / no-NAT philosophy of "always connected and always
> directly addressable" eliminates t
On 1/10/2011 6:55 PM, Owen DeLong wrote:
> Nonetheless, NAT remains an opaque screen door at best.
>
> If the bad guy is behind the door, it helps hide him.
>
> If the bad guy is outside the door, the time it takes for his knife to cut
> through it is so small as to be meaningless.
For a "server"
On Jan 10, 2011, at 11:52 AM, Lamar Owen wrote:
> On Friday, January 07, 2011 09:25:59 am David Sparro wrote:
>> I find that the security "Layers" advocates tend not to look at the
>> differing value of each of those layers.
>
> Different layers very much have different values, and, yes, this i
On 1/10/2011 5:04 PM, Owen DeLong wrote:
Unless my point-to-point links are originating packets to the outside world
(they should not be, in general), then I should not expect any PMTU-D
responses directed at them.
As such, blocking even those packets TO my point-to-point interfaces
should not
On Jan 10, 2011, at 5:56 AM, Tim Chown wrote:
>
> On 7 Jan 2011, at 15:12, Justin M. Streiner wrote:
>
>> On Thu, 6 Jan 2011, Jeff Wheeler wrote:
>>
>>> On Thu, Jan 6, 2011 at 8:47 PM, Owen DeLong wrote:
1. Block packets destined for your point-to-point links at your
bord
On Mon, Jan 10, 2011 at 02:52:56PM -0500, Lamar Owen wrote:
> On Friday, January 07, 2011 09:25:59 am David Sparro wrote:
> > I find that the security "Layers" advocates tend not to look at the
> > differing value of each of those layers.
>
> Different layers very much have different values, and,
On Friday, January 07, 2011 09:25:59 am David Sparro wrote:
> I find that the security "Layers" advocates tend not to look at the
> differing value of each of those layers.
Different layers very much have different values, and, yes, this is often
glossed over.
> Going back to the physical door
On 7 Jan 2011, at 15:12, Justin M. Streiner wrote:
> On Thu, 6 Jan 2011, Jeff Wheeler wrote:
>
>> On Thu, Jan 6, 2011 at 8:47 PM, Owen DeLong wrote:
>>> 1. Block packets destined for your point-to-point links at your
>>>borders. There's no legitimate reason someone should be
>>
>>
>>
>>
>
> If you define a new protocol version as one that means devices with
> older protocol generations of firmware/software may not interoperate
> reliably with devices with new protocol generations of
> firmware/software, then IPv4 as we know it today is probably at least
> "IPv7" - address
On Fri, 07 Jan 2011 07:11:42 -0500
"Robert E. Seastrom" wrote:
>
> "Kevin Oberman" writes:
>
> >> The next ship will be departing in a hundred years or so, advance
> >> registration for the IPv7 design committee are available over there.
> >
> > Sorry, but IPv7 has come and gone. It was assig
On Fri, 7 Jan 2011 14:53:02 -0800
Owen DeLong wrote:
>
> On Jan 7, 2011, at 1:28 PM, Mark Smith wrote:
>
> > On Fri, 7 Jan 2011 09:38:32 +
> > "Dobbins, Roland" wrote:
> >
> >>
> >> On Jan 7, 2011, at 4:14 PM, Mark Smith wrote:
> >>
> >>> Doesn't this risk already exist in IPv4?
> >>
On Jan 8, 2011, at 4:28 AM, Mark Smith wrote:
> The problem is that somebody on the Internet
> could send 1000s of UDP packets (i.e. an offlink traffic source) towards
> destinations that don't exist on the target subnet.
I meant to type 'ND-triggering stuff', concur 100%.
---
On Jan 7, 2011, at 1:28 PM, Mark Smith wrote:
> On Fri, 7 Jan 2011 09:38:32 +
> "Dobbins, Roland" wrote:
>
>>
>> On Jan 7, 2011, at 4:14 PM, Mark Smith wrote:
>>
>>> Doesn't this risk already exist in IPv4?
>>
>>
>> There are various vendor knobs/features to ameliorate ARP-level issues
On Jan 7, 2011, at 7:12 AM, Justin M. Streiner wrote:
> On Thu, 6 Jan 2011, Jeff Wheeler wrote:
>
>> On Thu, Jan 6, 2011 at 8:47 PM, Owen DeLong wrote:
>>> 1. Block packets destined for your point-to-point links at your
>>>borders. There's no legitimate reason someone should be
>>
On Fri, 7 Jan 2011 09:38:32 +
"Dobbins, Roland" wrote:
>
> On Jan 7, 2011, at 4:14 PM, Mark Smith wrote:
>
> > Doesn't this risk already exist in IPv4?
>
>
> There are various vendor knobs/features to ameliorate ARP-level issues in
> switching gear. Those same knobs aren't viable in IP
On Jan 7, 2011, at 6:23 AM, Tim Chown wrote:
>
> On 6 Jan 2011, at 18:20, Owen DeLong wrote:
>
>>
>> On Jan 5, 2011, at 7:18 PM, Dobbins, Roland wrote:
>>
>>>
>>> On Jan 6, 2011, at 10:08 AM, Joe Greco wrote:
>>>
Packing everything densely is an obvious problem with IPv4; we learned
>
On Thu, 6 Jan 2011, Jeff Wheeler wrote:
On Thu, Jan 6, 2011 at 8:47 PM, Owen DeLong wrote:
1. Block packets destined for your point-to-point links at your
borders. There's no legitimate reason someone should be
Most networks do not do this today. Whether or not that is wise is
q
On Fri, Jan 7, 2011 at 09:56, Dobbins, Roland wrote:
>
> On Jan 7, 2011, at 9:30 PM, TJ wrote:
>
> > Today (IPv4) they may not, but many recommendations for tomorrow (IPv6)
> are to use discrete network allocations for your infrastructure (loopbacks
> and
> > PtP links, specifically) and to filte
On Fri, Jan 7, 2011 at 09:57, Dobbins, Roland wrote:
>
> On Jan 7, 2011, at 9:23 PM, Tim Chown wrote:
>
> > The main operational problem we see is denial of service caused by
> unintentional IPv6 RAs from hosts.
>
> Which is a whole other can of IPv6 worms, heh.
>
But atleast we are finally gett
On Jan 7, 2011, at 9:23 PM, Tim Chown wrote:
> The main operational problem we see is denial of service caused by
> unintentional IPv6 RAs from hosts.
Which is a whole other can of IPv6 worms, heh.
;>
Roland Dobbins //
On Jan 7, 2011, at 9:30 PM, TJ wrote:
> Today (IPv4) they may not, but many recommendations for tomorrow (IPv6) are
> to use discrete network allocations for your infrastructure (loopbacks and
> PtP links, specifically) and to filter traffic destined to those at your
> edges ...
Actually, this
On 1/7/2011 8:17 AM, Tim Chown wrote:
As RFC6018 suggests, this could be done dynamically on any given active subnet.
Unfortunately, I don't see support for it in major router vendors for
service providers. Currently, flow + arp/ND/routing tables are utilized
to determine a variety of situa
On Thu, Jan 6, 2011 at 21:13, Jeff Wheeler wrote:
> On Thu, Jan 6, 2011 at 8:47 PM, Owen DeLong wrote:
> > 1. Block packets destined for your point-to-point links at your
> >borders. There's no legitimate reason someone should be
>
> Most networks do not do this today. Whether or n
On 1/6/2011 6:23 PM, Dobbins, Roland wrote:
On Jan 6, 2011, at 9:29 PM, Joe Greco wrote:
Sorry, but I see this as not grasping a fundamental security concept.
I see it as avoiding a common security misconception.
I find that the security "Layers" advocates tend not to look at the
differi
On 6 Jan 2011, at 18:20, Owen DeLong wrote:
>
> On Jan 5, 2011, at 7:18 PM, Dobbins, Roland wrote:
>
>>
>> On Jan 6, 2011, at 10:08 AM, Joe Greco wrote:
>>
>>> Packing everything densely is an obvious problem with IPv4; we learned
>>> early on that having a 48-bit (32 address, 16 port) space
On 6 Jan 2011, at 17:17, Jack Bates wrote:
>
> A randomly setup ssh server without DNS will find itself brute force
> attacked. Darknets are setup specifically for detection of scans. One side
> effect of v6, is determining how best to deploy darknets, as we can't just
> take one or two blocks
"Kevin Oberman" writes:
>> The next ship will be departing in a hundred years or so, advance
>> registration for the IPv7 design committee are available over there.
>
> Sorry, but IPv7 has come and gone. It was assigned to the TUBA proposal,
> basically replacing IP with CLNP. IPv8 has also bee
On Jan 7, 2011, at 4:14 PM, Mark Smith wrote:
> Doesn't this risk already exist in IPv4?
There are various vendor knobs/features to ameliorate ARP-level issues in
switching gear. Those same knobs aren't viable in IPv6 due to the way ND/NS
work, and as you mention, the ND stuff is layer-3-ro
On Thu, 6 Jan 2011 21:13:52 -0500
Jeff Wheeler wrote:
> On Thu, Jan 6, 2011 at 8:47 PM, Owen DeLong wrote:
> > 1. Block packets destined for your point-to-point links at your
> > borders. There's no legitimate reason someone should be
>
> Most networks do not do this today. Whether
On Jan 6, 2011, at 7:13 PM, Jeff Wheeler wrote:
> On Thu, Jan 6, 2011 at 9:24 PM, Joe Greco wrote:
>> With today's implementations of things? Perhaps. However, you
>> show yourself equally incapable of grasping the real problem by
>> looking at the broader picture, and recognizing that problem
Hey Lamar, long time no talk.
On 1/6/2011 10:16 AM, Lamar Owen wrote:
Standards are written by people, of course, and most paragraphs have reasons to
be there; I would find it interesting to hear the rationale for a router
filling a slot in its neighbor table for a host that doesn't exist. F
On Thu, Jan 6, 2011 at 9:24 PM, Joe Greco wrote:
> With today's implementations of things? Perhaps. However, you
> show yourself equally incapable of grasping the real problem by
> looking at the broader picture, and recognizing that problematic
> issues such as finding hosts on a network are ve
On Thu, Jan 6, 2011 at 9:31 PM, Owen DeLong wrote:
>> You must understand that policing will not stop the NDCache from
>> becoming full almost instantly under an attack. Since the largest
>> existing routers have about 100k entries at most, an attack can fill
>> that up in *one second.*
>>
> If t
>
> On Thu, Jan 6, 2011 at 6:46 PM, Owen DeLong wrote:
> > On Jan 5, 2011, at 9:17 PM, Joe Greco wrote:
> >> However, that's not the only potential use! =A0A client that initiates
> >> each new outbound connection from a different IP address is doing
> >> something Really Good.
> > If hosts start
>
> On Jan 5, 2011, at 9:17 PM, Joe Greco wrote:
>
> >>> It has nothing to do with "security by obscurity".
> >>=20
> >> You may wish to re-read what Joe was saying - he was positing sparse =
> addres=3D
> >> sing as a positive good because it will supposedly make it more =
> difficult f=3D
> >>
On Thu, Jan 6, 2011 at 8:47 PM, Owen DeLong wrote:
> 1. Block packets destined for your point-to-point links at your
> borders. There's no legitimate reason someone should be
Most networks do not do this today. Whether or not that is wise is
questionable, but I don't think those netw
On Jan 6, 2011, at 3:32 PM, Dobbins, Roland wrote:
>
> On Jan 7, 2011, at 1:20 AM, Owen DeLong wrote:
>
>> You are mistaken... Host scanning followed by port sweeps is a very common
>> threat and still widely practiced in IPv4.
>
> I know it's common and widely-practiced. My point is that if
>
>
> On Thu, Jan 6, 2011 at 1:20 PM, Owen DeLong wrote:
>> And there are ways to mitigate ND attacks as well.
>
> No, Owen, there aren't. The necessary router knobs do not exist. The
> "Cisco approach" is currently to police NDP on a per-interface basis
> (either with per-int or global confi
This would break dead-neighbor detection, but, I'm not sure that's necessarily
a problem for end hosts at the local router level.
It is touted as one of the IPv6 features, but, I'm not sure how valuable it is
as
a feature.
Owen
On Jan 6, 2011, at 7:37 AM, Marcel Plug wrote:
> Perhaps we're rea
On Thu, Jan 6, 2011 at 6:46 PM, Owen DeLong wrote:
> On Jan 5, 2011, at 9:17 PM, Joe Greco wrote:
>> However, that's not the only potential use! A client that initiates
>> each new outbound connection from a different IP address is doing
>> something Really Good.
> If hosts start cycling their ad
On Jan 5, 2011, at 9:17 PM, Joe Greco wrote:
>>> It has nothing to do with "security by obscurity".
>>
>> You may wish to re-read what Joe was saying - he was positing sparse addres=
>> sing as a positive good because it will supposedly make it more difficult f=
>> or attackers to locate endpoin
On Jan 7, 2011, at 1:20 AM, Owen DeLong wrote:
> You are mistaken... Host scanning followed by port sweeps is a very common
> threat and still widely practiced in IPv4.
I know it's common and widely-practiced. My point is that if the host is
security properly, this doesn't matter; and that if
On Jan 6, 2011, at 11:48 PM, Jack Bates wrote:
> It is not the intentional that we should fear, but the unintentional.
This is the single largest issue with IPv6 and the whole ND mess in a nutshell
- unintentional DoS becomes much more likely.
--
On Jan 6, 2011, at 11:28 PM, wrote:
> Playing devil's advocate for a moment...
I don't see this as devil's advocacy, since I've said a) we're already hosed
(i.e., what you said) and b), we're going to get even more hosed with IPv6.
;>
-
On Jan 6, 2011, at 9:29 PM, Joe Greco wrote:
> Sorry, but I see this as not grasping a fundamental security concept.
I see it as avoiding a common security misconception.
> Making a host harder to find (or more specifically to address from remote) is
> a worthwhile goal.
As I've stated repeat
On Thu, Jan 6, 2011 at 7:34 AM, Robert E. Seastrom wrote:
> I continue to believe that the "allocate the /64, configure the /127
> as a workaround for the router vendors' unevolved designs" approach,
As a point of information, I notice that Level3 has deployed without
doing this, e.g. they have d
On 1/6/2011 2:47 PM, William Allen Simpson wrote:
Google tells me that draft-ietf-sip-discovery-03.txt is still on-line.
I've not found my -04, -05, or -06 on-line, so I've occasionally been
looking through old backups lately as time allows. Sadly, those systems
are long dead, and finding actual
On 1/6/11 1:47 AM, Paul Ferguson wrote:
As someone who has been immersed in security for many years now, and having
previously been very intimately involved in the network ops community for
equally many years, I have to agree with Roland here. Just because a lot of
smart people have worked on IPv
On 1/6/2011 2:17 PM, TJ wrote:
Again, off the top of my head, maybe - when under duress - age out the
incomplete ND table entries faster.
Given that the incomplete age is to protect the L2 network from
excessive broadcast/multicast, I agree that aging them out fast would be
a wiser solution
On Wed, Jan 5, 2011 at 13:14, Jeff Wheeler wrote:
> On Wed, Jan 5, 2011 at 1:02 PM, TJ wrote:
> > Many would argue that the version of IP is irrelevant, if you are
> permitting
> > external hosts the ability to scan your internal network in an
> unrestricted
> > fashion (no stateful filtering or
On Wed, Jan 5, 2011 at 17:44, Dobbins, Roland wrote:
>
> On Jan 6, 2011, at 1:02 AM, TJ wrote:
>
> > if you are permitting external hosts the ability to scan your internal
> network in an unrestricted
> > fashion
>
> DCN aside, how precisely does one define 'internal network' in, say, the
> cont
On Jan 5, 2011, at 7:18 PM, Dobbins, Roland wrote:
>
> On Jan 6, 2011, at 10:08 AM, Joe Greco wrote:
>
>> Packing everything densely is an obvious problem with IPv4; we learned early
>> on that having a 48-bit (32 address, 16 port) space to scan made
>> port-scanning easy, attractive, producti
On 1/6/2011 10:44 AM, Joe Greco wrote:
On the flip side, however, I would point out that attackers have had vastly
more resources made available to them in part *because* IPv4 has been so
easily scanned and abused. To be sure, a lot of viruses have spread via
e-mail spam and drive-by downloads,
On 1/6/2011 10:28 AM, valdis.kletni...@vt.edu wrote:
And the "ZOMG they can overflow the ARP/ND/whatever table" is a total red
herring - you know damned well that if a script kiddie with a 10K node botnet
wants to hose down your network, you're going to be looking at a DDoS, and it
really doesn'
> On Jan 6, 2011, at 1:51 PM, Joe Greco wrote:
> > There are numerous parallels between physical and electronic security.
> > Let's just concede that for a moment.
>
> I can't, and here's why:
>
> 1.In the physical world, attackers run a substantial risk of being
> caught,=
> and of tangibl
On Thu, 06 Jan 2011 07:50:17 GMT, "Dobbins, Roland" said:
> In my view, an IPv6 Internet is considerably less secure, and inherently less
> securable, than the present horribly insecure and barely securable IPv4
> Internet;
Playing devil's advocate for a moment...
Even if an IPv6 network is 10 ti
On Thursday, January 06, 2011 10:51:27 am Jack Bates wrote:
> There have been many implementations, mostly for
> security reasons, but also helping with this problem by implementing a
> "router MUST NOT send unsolicited arp requests". It's important that
> routers learn their table in another fa
On Thursday, January 06, 2011 10:27:54 am you wrote:
> On Thu, 6 Jan 2011, Lamar Owen wrote:
> > Ok, perhaps I'm dense, but why is the router going to try to find a host
> > that it already doesn't know based on an unsolicited outside packet?
> Because the standard says it should do that.
Since
On 1/6/2011 9:52 AM, Mikael Abrahamsson wrote:
In the DHCP case this is easy, yes.
I perfer to have only LL on the link towards the customer operated CPE,
thus I don't really need to keep lots of ND state per customer.
I use RBE and unnumbered vlans in most areas, which keeps some state,
but
In article you
write:
>On Thu, Jan 6, 2011 at 4:32 AM, Joel Jaeggli wrote:
>> Which at a minimum is why you want to police the number of nd messages
>> that the device sends and unreachable entries do not simply fill up the
>> nd cache, such that new mappings in fact can be learned because there
On Thu, 6 Jan 2011, Jack Bates wrote:
Not stateful firewalls. He's referring to neighbor learning based on
incoming traffic to the router from the trusted side. ie, I received a
packet from the server, so I will add his MAC to my neighbor table.
There are many methods for learning MAC addresse
On 1/6/2011 9:37 AM, Marcel Plug wrote:
Perhaps we're reaching the point where we can say "We don't need an ND
table for a /64 network". If the ethernet MAC is embedded in the IPv6
address, we don't need to discover it because we already know it. If
the IPv6 address has been manually configured
On 1/6/2011 9:27 AM, Mikael Abrahamsson wrote:
On Thu, 6 Jan 2011, Lamar Owen wrote:
Ok, perhaps I'm dense, but why is the router going to try to find a
host that it already doesn't know based on an unsolicited outside
packet? Why is the router trusting the outside's idea of what
addresses are
Perhaps we're reaching the point where we can say "We don't need an ND
table for a /64 network". If the ethernet MAC is embedded in the IPv6
address, we don't need to discover it because we already know it. If
the IPv6 address has been manually configured on a host, perhaps that
host should now a
On Thu, 6 Jan 2011, Lamar Owen wrote:
Ok, perhaps I'm dense, but why is the router going to try to find a host
that it already doesn't know based on an unsolicited outside packet?
Why is the router trusting the outside's idea of what addresses are
active, and why isn't the router dropping pack
On 6 Jan 2011, at 15:10, Lamar Owen wrote:
>
> Ok, perhaps I'm dense, but why is the router going to try to find a host that
> it already doesn't know based on an unsolicited outside packet? Why is the
> router trusting the outside's idea of what addresses are active, and why
> isn't the rout
On Thu, Jan 6, 2011 at 5:54 AM, Jeff Wheeler wrote:
> On Thu, Jan 6, 2011 at 5:20 AM, Owen DeLong wrote:
>>> You must also realize that the stateful firewall has the same problems
>> Uh, not exactly...
>
> Of course it does. The stateful firewall must either 1) be vulnerable
> to the same form o
On 1/6/2011 12:26 AM, Joe Greco wrote:
A bunch of very smart people have worked on IPv6 for a very long
time, and justification for /64's was hashed out at extended length
over the period of years.
NDP should have been better designed. It still has the same problems we
had with ARP except the
On Wednesday, January 05, 2011 10:42:25 pm George Bonser wrote:
> I don't think you are understanding the problem. The problem comes from
> addressing hosts that don't even exist. This causes the router to
> attempt to find that host. The v6 equivalent of ARP. At some point
> that table becomes
On 1/5/2011 11:31 PM, Owen DeLong wrote:
Why shouldn't I use /64 for links if I want to? I can see why you can say you
want /126s, and that's fine, as long as
you are willing to deal with the fall-out, your network, your problem, but, why
tell me that my RFC-compliant network
is somehow wrong?
> On Jan 6, 2011, at 2:03 PM, Matthew Petach wrote:
> > I think what people are trying to say is that it doesn't matter whether o=
> r not your host is easily findable or not, if I can trivially take out your
> > upstream router.
A good reason to see if there's a way to solve that (which there
is,
> On Wed, Jan 5, 2011 at 10:51 PM, Joe Greco wrote:
> >> On Jan 6, 2011, at 12:54 PM, Joe Greco wrote:
> ...
> > To say that "the endpoint *will be found*" is a truism, in the same
> > way that a bank *will* be robbed. =A0You're not trying to guarantee that
> > it will never happen. =A0You're tryi
On 06/01/11 16:01, John Levine wrote:
>> Still, the idea that "nobody will scan a /64" reminds me of the days
>> when 640K ought to be enough for anybody, ...
>
> We really need to wrap our heads around the orders of magnitude
> involved here. If you could scan an address every nanosecond, which
On Wed, 5 Jan 2011 18:57:50 +0100
Phil Regnauld wrote:
> Jeff Wheeler (jsw) writes:
> > are badly needed. The largest current routing devices have room for
> > about 100,000 ARP/NDP entries, which can be used up in a fraction of a
> > second with a gigabit of malicious traffic flow. What happen
Owen DeLong writes:
> Personally, I think /64 works just fine.
I continue to believe that the "allocate the /64, configure the /127
as a workaround for the router vendors' unevolved designs" approach,
which Igor and I discovered we were in violent agreement on when on a
panel a few NANOGs ago,
On Thu, Jan 6, 2011 at 4:32 AM, Joel Jaeggli wrote:
> Which at a minimum is why you want to police the number of nd messages
> that the device sends and unreachable entries do not simply fill up the
> nd cache, such that new mappings in fact can be learned because there
Your solution is to break
Owen DeLong (owen) writes:
>
> But, Jeff, if the router has a bunch of /24s attached to it and you scan
> them all, the problem is much larger than 250 arp entries.
>
> I think that's what Phil was getting at.
And so did Joel. If you've got a crapload of VLANs attached to a box,
On Jan 5, 2011, at 9:44 AM, Jeff Wheeler wrote:
> On Wed, Jan 5, 2011 at 12:26 PM, Phil Regnauld wrote:
>> Jeff Wheeler (jsw) writes:
>>> Not good, but also does not affect any other interfaces on the router.
>>You're assuming that all routing devices have per-interface ARP
>> tables.
>
>
> On Wed, Jan 5, 2011 at 9:39 AM, Iljitsch van Beijnum
> wrote:
>> A (relatively) easy way to avoid this problem is to either use a stateful
>> firewall that only allows internally initiated sessions, or a filter that
>> lists only addresses that are known to be in use.
>
> It would certain
On 1/6/11 12:24 AM, Jeff Wheeler wrote:
> On Thu, Jan 6, 2011 at 2:42 AM, Joel Jaeggli wrote:
>> icmp6 rate limiting both reciept and origination is not rocket science.
>> The attack that's being described wasn't exactly dreamed up last week,
>> is as observed not unique to ipv6, and can be mitiga
On Thu, Jan 6, 2011 at 2:42 AM, Joel Jaeggli wrote:
> icmp6 rate limiting both reciept and origination is not rocket science.
> The attack that's being described wasn't exactly dreamed up last week,
> is as observed not unique to ipv6, and can be mitigated.
That does not solve the problem. Your
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Jan 5, 2011 at 11:46 PM, Joel Jaeggli wrote:
> On 1/5/11 10:36 PM, Dobbins, Roland wrote:
>>
>> On Jan 6, 2011, at 1:26 PM, Joe Greco wrote:
>>
>>> A bunch of very smart people have worked on IPv6 for a very long
>>> time, and justification f
On Jan 6, 2011, at 1:51 PM, Joe Greco wrote:
> There are numerous parallels between physical and electronic security.
> Let's just concede that for a moment.
I can't, and here's why:
1. In the physical world, attackers run a substantial risk of being
caught, and of tangible, severe penalt
On Jan 6, 2011, at 2:42 PM, Joel Jaeggli wrote:
> icmp6 rate limiting both reciept and origination is not rocket science.
But it's *considerably* more complex and has far more potential implications
than ICMP rate-limiting in IPv4 (which in and of itself is more complex and has
more implicati
On 1/5/11 10:36 PM, Dobbins, Roland wrote:
>
> On Jan 6, 2011, at 1:26 PM, Joe Greco wrote:
>
>> A bunch of very smart people have worked on IPv6 for a very long
>> time, and justification for /64's was hashed out at extended
>> length over the period of years.
>
> Very smart people can and do c
On 1/5/11 11:03 PM, Matthew Petach wrote:
> On Wed, Jan 5, 2011 at 10:51 PM, Joe Greco wrote:
> Hi Joe,
>
> I think what people are trying to say is that it doesn't matter whether
> or not your host is easily findable or not, if I can trivially take out your
> upstream router. With your upstream
On Jan 6, 2011, at 2:03 PM, Matthew Petach wrote:
> I think what people are trying to say is that it doesn't matter whether or
> not your host is easily findable or not, if I can trivially take out your
> upstream router.
That's part of it - the other part is that the host will be found, irresp
On Wed, Jan 5, 2011 at 10:51 PM, Joe Greco wrote:
>> On Jan 6, 2011, at 12:54 PM, Joe Greco wrote:
...
> To say that "the endpoint *will be found*" is a truism, in the same
> way that a bank *will* be robbed. You're not trying to guarantee that
> it will never happen. You're trying to *deter* th
> On Jan 6, 2011, at 12:54 PM, Joe Greco wrote:
>
> > Generally speaking, security professionals prefer for there to be more ro=
> adblocks rather than fewer. =20
>
> The soi-disant security 'professionals' who espouse layering unnecessary mu=
> ltiple, inefficient, illogical, and iatrogenic road
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Jan 5, 2011 at 10:36 PM, Dobbins, Roland
wrote:
>
> On Jan 6, 2011, at 1:26 PM, Joe Greco wrote:
>
>> A bunch of very smart people have worked on IPv6 for a very long time,
>> and justification for /64's was hashed out at extended length over
On Jan 6, 2011, at 1:26 PM, Joe Greco wrote:
> A bunch of very smart people have worked on IPv6 for a very long time, and
> justification for /64's was hashed out at extended length
> over the period of years.
Very smart people can and do come up with bad ideas, and IPv6 is a textbook
example
> On Thu, Jan 6, 2011 at 12:17 AM, Joe Greco wrote:
> > However, that's not the only potential use! =A0A client that initiates
> > each new outbound connection from a different IP address is doing
> > something Really Good.
>
> No, Joe, it is not doing anything Good. =A0This would require the
> s
On Thu, Jan 6, 2011 at 12:54 AM, Joe Greco wrote:
> I'm starting off with the assumption that knowledge of the host
> address *might* be something of value. If it isn't, no harm done.
> If it is, and the address becomes virtually impossible to find, then
> we've just defeated an attack, and it's
On Jan 6, 2011, at 12:54 PM, Joe Greco wrote:
> Generally speaking, security professionals prefer for there to be more
> roadblocks rather than fewer.
The soi-disant security 'professionals' who espouse layering unnecessary
multiple, inefficient, illogical, and iatrogenic roadblocks in pref
> From: Joe Greco
> Date: Wed, 5 Jan 2011 21:27:14 -0600 (CST)
>
> >
> > On Wed, Jan 5, 2011 at 8:57 PM, Joe Greco wrote:
> > >> > This is a much smaller issue with IPv4 ARP, because routers generally
> > >> > have very generous hardware ARP tables in comparison to the typical
> > >> > size of
1 - 100 of 142 matches
Mail list logo
