❦ 26 septembre 2016 09:14 CEST, valdis.kletni...@vt.edu :
>> Linux:
>> From /etc/sysctl.conf:
>>
>> # Uncomment the next two lines to enable Spoof protection (reverse-path=20
>> # filter)
>> # Turn on Source Address Verification in all interfaces to
>> # prevent some spoofing attacks
>> net.ipv4.
On Sun, 25 Sep 2016 21:19:31 -0700, Hugo Slabbert said:
> Linux:
> From /etc/sysctl.conf:
>
> # Uncomment the next two lines to enable Spoof protection (reverse-path=20
> # filter)
> # Turn on Source Address Verification in all interfaces to
> # prevent some spoofing attacks
> net.ipv4.conf.defaul
On Sun 2016-Sep-25 15:59:15 -0700, Stephen Satchell wrote:
On 09/25/2016 07:32 AM, Jay R. Ashworth wrote:
From: "Jay Farrell via NANOG"
And of course Brian Krebs has a thing or two to say, not the least is which
to push for BCP38 (good luck with that, right?).
https://krebsonsecurity.com/2
On Thu, Mar 29, 2012 at 07:31:26PM -0400, Jon Lewis wrote:
> On Thu, 29 Mar 2012, Joe Provo wrote:
>
> >uRFP was a trivial, 0-impact feature on the cisco VXR-based CMTS
> >platform. Assert a simple statement in the default config (along
> >with 'ips classless' and all your other standard config el
On Thu, 29 Mar 2012, Joe Provo wrote:
uRFP was a trivial, 0-impact feature on the cisco VXR-based CMTS
platform. Assert a simple statement in the default config (along
with 'ips classless' and all your other standard config elements)
uRPF: or as it's now used in ios,
ip verify unicast source r
On Wed, Mar 28, 2012 at 08:45:12AM -0700, David Conrad wrote:
> Leo,
>
> On Mar 28, 2012, at 8:13 AM, Leo Bicknell wrote:
> >> #1) Money.
> >> #2) Laziness.
>
> > While Patrick is spot on, there is a third issue which is related
> > to money and laziness, but also has some unique aspects.
> >
>
The power of defaults.
The few successful Internet security "best practice" changes have
primarily resulted from changes to default settings, not trying to get
ISPs, operators, sysadmins or users to change.
Smurf attacks - change default directed-broadcast settings in dominant
router vendor
On Wed, 28 Mar 2012 13:36:49 -0700, Leo Bicknell said:
> I think some engineers need to ask some interesting questions, like
> how, in a box doing NAT to an outside IP, does it ever emit a packet
> not from that outside IP? The fact that you can spoof packets
> through some of the NAT implementat
In a message written on Wed, Mar 28, 2012 at 02:49:02PM -0700, David Conrad
wrote:
> On Mar 28, 2012, at 12:03 PM, Leo Bicknell wrote:
> > Tier 1 T640 core network with 10GE handoff
> > Regional Cisco GSR network with 1GE handoff
> > Local1006 to Arris CMTS
> > Subscriber Motor
On Mar 28, 2012, at 12:03 PM, Leo Bicknell wrote:
> Tier 1 T640 core network with 10GE handoff
> Regional Cisco GSR network with 1GE handoff
> Local1006 to Arris CMTS
> Subscriber Motorola Cable Modem to NetGear SOHO Gateway
> User Patron with Airport Express sharing a w
In a message written on Wed, Mar 28, 2012 at 12:44:04PM -0700, Michael Thomas
wrote:
> Except for the small problem that getting cheap home router box
> manufacturers to do just about anything is a pushing on string exercise.
> So if I want to a) protect my network and b) be a good netizen, I'm
>
> 1. Give BCP38 the only practical anti-spoofing technique, can an ISP well
> protect its customers by implementing BCP38? I don't think so, because I
> think BCP38 is accurate near the source but inaccurate near the
> destination, i.e. if its customer is the target of spoofing attack, its
> capabi
On 03/28/2012 12:03 PM, Leo Bicknell wrote:
None of the routers are "trusted" if your perspective is right.
It's easy to find a path like:
"Tier 1 ISP" - Regional ISP - Local Provider - Subscriber - User
Techologically it may look like:
Tier 1 T640 core network with 10GE handoff
Region
In a message written on Wed, Mar 28, 2012 at 09:52:49AM -0700, Michael Thomas
wrote:
> Yeahbut, the CPE isn't trusted. It would be _nice_ for customers
> to be bcp38 clueful as well, but I don't think it's _required_ for
> successful deployment from the ISP's standpoint. Even with a
> system like
2012 1:15 PM
To: Darius Jahandarie
Cc: NANOG list
Subject: Re: BCP38 Deployment
Hi Darius,
Yes, I agree that feasible RPF solves the problem in a lot of scenarios.
However, in some other cases, the asymmetric routing is caused by static
routing, traffic engineering, policy routing, etc., where t
Hi Darius,
Yes, I agree that feasible RPF solves the problem in a lot of scenarios.
However, in some other cases, the asymmetric routing is caused by
static routing, traffic engineering, policy routing, etc., where the
lengths of forward path and reverse path may differ, so feasible RPF
may also
On Wed, 28 Mar 2012, Bingyang LIU wrote:
the provider may not be able to protect its customers, because ingress
filtering (including uRPF) is inefficient when done near the
destination. In other words, an ISP can deploy BCP38 or whatever, but
still cannot well protect its customers from spoofing
On Wed, Mar 28, 2012 at 12:50, David Conrad wrote:
> I would be surprised if this were true.
>
> I'd argue that today, the vast majority of devices on the Internet (and
> certainly the ones that are used in massive D(D)oS attacks) are found hanging
> off singly-homed networks.
Yes, but RPF can
Yeah, "contractual closures" might be a way to force the providers to
deploy BCP38.
However, when the customers become the target of a spoofing attack,
the provider may not be able to protect its customers, because ingress
filtering (including uRPF) is inefficient when done near the
destination. I
On 3/28/12 11:45 AM, David Conrad wrote:
> Actually, given the uptick in spoofing-based DoS attacks, the ease in which
> such attacks can be generated, recent high profile targets of said attacks,
> and the full-on money pumping freakout about anything with "cyber-" tacked on
> the front, I susp
On 03/28/2012 09:16 AM, Leo Bicknell wrote:
In a message written on Wed, Mar 28, 2012 at 08:45:12AM -0700, David Conrad
wrote:
An interesting assertion. I haven't looked at how end-user networks are built
recently. I had assumed there continue to be customer aggregation points
within ISP in
Yep, one way is to give economic penalty.
But how about giving the _good_ ISPs economic reward? Say, some
transit ISPs deploy anti-spoofing techniques (e.g. uRPF), but only
filter those spoofing packets whose destination is the ASes having
purchased their *anti-spoofing service* ?
Bingyang
On We
On Mar 28, 2012, at 9:39 AM, Darius Jahandarie wrote:
> I think the concern of RFC3704/BCP84, i.e., multihoming, is the
> primary reason we don't see ingress filtering as much as we should.
I would be surprised if this were true.
I'd argue that today, the vast majority of devices on the Internet
On Wed, 28 Mar 2012, David Conrad wrote:
Actually, given the uptick in spoofing-based DoS attacks, the ease in
which such attacks can be generated, recent high profile targets of said
attacks, and the full-on money pumping freakout about anything with
"cyber-" tacked on the front, I suspect a l
On Wed, Mar 28, 2012 at 12:16, Leo Bicknell wrote:
> Well, RFC3704 for one has updated the methods and tactics since BCP38
> was written. Remember BCP38 was before even "unicast RPF" as we know it
> existed.
I think the concern of RFC3704/BCP84, i.e., multihoming, is the
primary reason we don't
While I'm a big fan of RFP, it does require that operators be "good
citizens" for it to be effective. Like most of the Internet, it's
built on a "web" of trust.
On Wed, Mar 28, 2012 at 12:10 PM, Bingyang LIU wrote:
> Hi David, Leo, Patrick and all,
>
> Considering the reasons you raised, do yo
In a message written on Wed, Mar 28, 2012 at 08:45:12AM -0700, David Conrad
wrote:
> An interesting assertion. I haven't looked at how end-user networks are
> built recently. I had assumed there continue to be customer aggregation
> points within ISP infrastructure in which BCP38-type filterin
Hi David, Leo, Patrick and all,
Considering the reasons you raised, do you think the following two things
can happen?
1. Give BCP38 the only practical anti-spoofing technique, can an ISP well
protect its customers by implementing BCP38? I don't think so, because I
think BCP38 is accurate near the
Leo,
On Mar 28, 2012, at 8:13 AM, Leo Bicknell wrote:
>> #1) Money.
>> #2) Laziness.
> While Patrick is spot on, there is a third issue which is related
> to money and laziness, but also has some unique aspects.
>
> BCP38 makes the assumption that the ISP does some "configuration"
> to insure on
In a message written on Wed, Mar 28, 2012 at 11:00:39AM -0400, Patrick W.
Gilmore wrote:
> #1) Money.
> Whenever someone asks "why...?", the answer is usually "money". It costs
> money - CapEx if your equipment doesn't support RPF, and OpEx even if it
> does. Plus opportunity cost if your cust
On Mar 28, 2012, at 10:44 , Bingyang LIU wrote:
> I'm Bingyang Liu, a ph.d student in Tsinghua University. My thesis topic is
> on "source address validation".
>
> Although BCP38 was proposed more than ten years ago, IP spoofing still
> remains an attack vector [MIT-Spoofer] [ARBOR-Annual-Report]
Hi all,
I'm Bingyang Liu, a ph.d student in Tsinghua University. My thesis topic is
on "source address validation".
Although BCP38 was proposed more than ten years ago, IP spoofing still
remains an attack vector [MIT-Spoofer] [ARBOR-Annual-Report] [Presentation
on NANOG Meeting] [Discussion in NA
32 matches
Mail list logo
