RE: BCP38 For BGP Customers

/chat/0/0?users=athomp...@merlin.mb.ca> From: NANOG On Behalf Of Mike Hammett Sent: November 8, 2022 2:29 PM To: William Herrin Cc: nanog@nanog.org; Grant Taylor Subject: Re: BCP38 For BGP Customers "Reverse path filtering literally says don't accept a packet from somewhere that is

Re: BCP38 For BGP Customers

On Thu, Nov 10, 2022 at 10:27:02AM -0800, William Herrin wrote: > On Thu, Nov 10, 2022 at 10:08 AM Grant Taylor via NANOG > wrote: > > I wonder if Feasible Path uRPF or Enhanced Feasible Path uRPF might help > > the situation. However I suspect they both suffer from the FIB != RIB > > problem an

Re: BCP38 For BGP Customers

On Thu, Nov 10, 2022 at 10:08 AM Grant Taylor via NANOG wrote: > I wonder if Feasible Path uRPF or Enhanced Feasible Path uRPF might help > the situation. However I suspect they both suffer from the FIB != RIB > problem and associated signaling. Hi Grant, That's a fairly good way to think about

Re: BCP38 For BGP Customers

On 11/8/22 10:53 PM, William Herrin wrote: Hi Grant, Hi Bill, and everyone else who replied. Two problems here: Thank you for taking the time to reply and help me understand the shortcomings of uRPF better. I wonder if Feasible Path uRPF or Enhanced Feasible Path uRPF might help the sit

Re: BCP38 For BGP Customers

- Original Message - > From: "Joel Halpern" > To: "Brian Turnbow" > Cc: nanog@nanog.org > Sent: Tuesday, November 8, 2022 10:03:20 AM > Subject: Re: BCP38 For BGP Customers > There is work a tthe IETF on an addon to RPKI called ASPA.  The

Re: BCP38 For BGP Customers

On Tue, Nov 8, 2022 at 9:08 PM Grant Taylor via NANOG wrote: > This thread has made me wonder if there isn't a need for a 3rd type of > uRPF or comparable filtering wherein the incoming interface is a viable > route in the RIB even if it's not the best route in the FIB. Hi Grant, Two problems he

Re: BCP38 For BGP Customers

On 11/8/22 2:01 PM, Matthew Petach wrote: You're thinking about it from the upstream perspective, where a route could be accepted but depreferenced and thus not actively used. Think about it from the downstream network's perspective, though. If you're my upstream, and I don't want to use your l

Re: BCP38 For BGP Customers

. This seems to be predicated on /strict/ uRPF enforcement. As for loose mode, it's basically useless in a BCP38 discussion. Loose mode only filters bogons. It doesn't prevent impersonation of any IP address currently routed in the system and doesn't do anything at all on a router

Re: BCP38 For BGP Customers

On Tue, Nov 8, 2022 at 5:28 AM Douglas Fischer wrote: > Another important point to note is that you MUST NOT drop everything else > that doesn't match this Prefix-List. > But put a bandwidth and PPS control on what doesn't match the prefix-list, > and block what exceeds. > Among other reasons, i

Re: BCP38 For BGP Customers

le that could help me after several months. Thankfully it's not a lot of bits but was still annoying to diagnose and triage. - Jared > On Mon, Nov 7, 2022 at 2:22 PM Charles Rumford via NANOG > wrote: > > > Hello - > > > > I'm are currently

Re: BCP38 For BGP Customers

On Tue, Nov 8, 2022 at 8:44 AM Grant Taylor via NANOG wrote: > [...] > > I don't understand why you would want to allow packets that couldn't > return the same path. > > As for asymmetrically routed packets, I would still expect a return path > to exist, even if it's not utilized. > > Grant, You

Re: BCP38 For BGP Customers

On Tue, Nov 8, 2022 at 12:29 PM Mike Hammett wrote: >> "Reverse path filtering literally says don't accept a packet from >> somewhere that isn't currently the next hop for that packet's source >> address." > > FIB or RIB? > > I knew of uRPF as available over an interface, per the routing table, no

Re: BCP38 For BGP Customers

implementation dependent? - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: "William Herrin" To: "Grant Taylor" Cc: nanog@nanog.org Sent: Tuesday, November 8, 2022 2:0

Re: BCP38 For BGP Customers

nterface). Even if a particular router happens to have RIB entries for all the valid paths to a host (a sketchy proposition at best), only one such entry will be stored in the FIB where uRPF looks to make its filtering decision. As for loose mode, it's basically useless in a BCP38 di

Re: [EXTERNAL] Re: BCP38 For BGP Customers

The Internet Draft is at: https://datatracker.ietf.org/doc/html/draft-sriram-sidrops-bar-sav-01 Some slides that will be used to present thematerial on Friday are at:https://datatracker.ietf.org/meeting/115/materials/slides-115-savnet-lowering-improper-block-and-improper-admit-for-sav-the-bar-s

Re: [EXTERNAL] Re: BCP38 For BGP Customers

Hi Joel, can you please point us to the IETF draft document that describes how a "combination of ASPA and RPKI can be used to help with DDoS prevention". I was not able to find it. Thanks! -Rich On 11/8/22, 8:05 AM, "NANOG on behalf of Joel Halpern" wrote: CAUTION: The e-mail below is

Re: BCP38 For BGP Customers

On 11/8/22 6:28 AM, Douglas Fischer wrote: I also have this concern about Spoofing coming from Downstreams. +1 And after a lot of struggle I can say that using uRPF in strict mode per interface doing FIB lookup is not a good idea! Maybe it's the lack of caffeine, but would someone please re

Re: BCP38 For BGP Customers

There is work a tthe IETF on an addon to RPKI called ASPA.  There is a draft that describes how the combiantion of ASPA and RPKI can be used to help with DDOS prevention. There is also a working group at the IETF called SAVNET that is looking at what technological additions can be made to addr

RE: BCP38 For BGP Customers

Hi Mike > This may not exist yet, but what about a uRPF-like feature that uses RPKI, > IRR, etc. instead of current BGP feed? There is rfc8704 that extends urpf But I do not know of any commercial available solutions Brian

Re: BCP38 For BGP Customers

only hardware based filtering scenarios will handle this. Em seg., 7 de nov. de 2022 às 16:23, Charles Rumford via NANOG < nanog@nanog.org> escreveu: > Hello - > > I'm are currently working on getting BCP38 filtering in place for our BGP > customers. My current plan is to

RE: BCP38 For BGP Customers

handoff. Ryan From: NANOG On Behalf Of Mike Hammett Sent: Monday, November 7, 2022 3:17 PM To: Charles Rumford Cc: nanog@nanog.org Subject: Re: BCP38 For BGP Customers This may not exist yet, but what about a uRPF-like feature that uses RPKI, IRR, etc. instead of current BGP feed

Re: BCP38 For BGP Customers

d via NANOG" To: nanog@nanog.org Sent: Monday, November 7, 2022 10:47:54 AM Subject: BCP38 For BGP Customers Hello - I'm are currently working on getting BCP38 filtering in place for our BGP customers. My current plan is to use the Juniper uRPF feature to filter out spoofed traff

Re: BCP38 For BGP Customers

On Mon, Nov 7, 2022 at 12:30 PM Tony Wicks wrote: > use prefix lists to prevent your customer networks being received > anywhere but directly from your customers to prevent them using > your capacity without paying for it however. Hi Tony, Do not do this either as it will render your entire netw

RE: BCP38 For BGP Customers

>For large BGP customers who service many BGP downstreams, the bottom line is >that BCP 38 cannot be reasonably implemented. It's one of the weaknesses in >the system. Yes, from personal experience BCP 38 should never be implemented buy a transit provider as it will inevitably cause breakage on

Re: BCP38 For BGP Customers

On Mon, Nov 7, 2022 at 8:47 AM Charles Rumford via NANOG wrote: > I'm are currently working on getting BCP38 filtering in place for our BGP > customers. My current plan is to use the Juniper uRPF feature to filter out > spoofed traffic based on the routing table. The mentality wou

Re: BCP38 For BGP Customers

Once upon a time, Charles Rumford said: > I would like to hear what others are doing for BCP38 deployments for > BGP customers. Are you taking the stance of "if you don't send us > the prefix, then we don't accept the traffic"? Are you putting in > some kind

Re: BCP38 For BGP Customers

Charles Rumford via NANOG wrote: > Hello - > > I'm are currently working on getting BCP38 filtering in place for our BGP > customers. My current plan is to use the Juniper uRPF feature to filter > out > spoofed traffic based on the routing table. The mentality would be: "I

Re: BCP38 For BGP Customers

e: > Hello - > > I'm are currently working on getting BCP38 filtering in place for our BGP > customers. My current plan is to use the Juniper uRPF feature to filter > out > spoofed traffic based on the routing table. The mentality would be: "If > you > don't

BCP38 For BGP Customers

Hello - I'm are currently working on getting BCP38 filtering in place for our BGP customers. My current plan is to use the Juniper uRPF feature to filter out spoofed traffic based on the routing table. The mentality would be: "If you don't send us the prefix, then we don'

RE: BCP38 on public-facing Ubuntu servers

Jean -Original Message- From: NANOG On Behalf Of Fran via NANOG Sent: June 8, 2021 5:39 PM To: nanog@nanog.org Subject: Re: BCP38 on public-facing Ubuntu servers Hey, to my knowledge there is no IPv6 equivalent for net.ipv4.conf.all.rp_filter. Therefore I use netfilter to do the RP filterin

Re: BCP38 on public-facing Ubuntu servers

On 6/8/21 2:38 PM, Fran via NANOG wrote: Hey, to my knowledge there is no IPv6 equivalent for net.ipv4.conf.all.rp_filter. Therefore I use netfilter to do the RP filtering for both address families. ip(6)tables -t raw -I PREROUTING -m rpfilter --invert -j DROP Using the raw tables less reso

Re: BCP38 on public-facing Ubuntu servers

Hey, to my knowledge there is no IPv6 equivalent for net.ipv4.conf.all.rp_filter. Therefore I use netfilter to do the RP filtering for both address families. ip(6)tables -t raw -I PREROUTING -m rpfilter --invert -j DROP Using the raw tables less resources are used, but you could also cho

Re: BCP38 on public-facing Ubuntu servers

Grant Taylor via NANOG wrote: >On 6/3/21 8:44 AM, William Herrin wrote: >> rp_filter is great until your network is slightly less than a perfect >> hierarchy. Then your Linux "router" starts mysteriously dropping packets >> and, as with allow_local, Linux doesn't have any way to generate logs >>

Re: BCP38 on public-facing Ubuntu servers

On 6/3/21 8:44 AM, William Herrin wrote: rp_filter is great until your network is slightly less than a perfect hierarchy. Then your Linux "router" starts mysteriously dropping packets and, as with allow_local, Linux doesn't have any way to generate logs about it so you end up with these mysteri

Re: BCP38 on public-facing Ubuntu servers

On Wed, Jun 2, 2021 at 2:04 PM Grant Taylor via NANOG wrote: > On 6/2/21 4:35 AM, Jean St-Laurent via NANOG wrote: > > Maybe you can explore the in kernel feature call RP filter or reverse > > path filter. In router gear it's called uRPF. > > > > cat /proc/sys/net/ipv4/conf/default/rp_filter > > +

Re: BCP38 on public-facing Ubuntu servers

On 6/2/21 4:35 AM, Jean St-Laurent via NANOG wrote: Maybe you can explore the in kernel feature call RP filter or reverse path filter. In router gear it's called uRPF. cat /proc/sys/net/ipv4/conf/default/rp_filter +100 to rp_filter There are 2 modes: Loose or strict. If your server is BGP

Re: BCP38 on public-facing Ubuntu servers

n Satchell wrote: Not every uplink service implements BCP38.  When putting up servers connected more-or-less directly to the Internet through these uplinks, it would be nice if the servers themselves were able to implement ingress and egress filtering according to BCP38.  (Sorry about the t

RE: BCP38 on public-facing Ubuntu servers

e been fix or improve. Finally, can you share with us which provider doesn't filter BCP38 in their uplink? #JustCurious. 😊 Jean -Original Message- From: NANOG On Behalf Of Stephen Satchell Sent: June 2, 2021 12:41 AM To: nanog@nanog.org; sa...@ine.com Subject: BCP38 on publi

BCP38 on public-facing Ubuntu servers

Not every uplink service implements BCP38. When putting up servers connected more-or-less directly to the Internet through these uplinks, it would be nice if the servers themselves were able to implement ingress and egress filtering according to BCP38. (Sorry about the typo in the subject

Re: BCP38/84 and DDoS ACLs

> This doesn't seem quite like it is BCP38 and more like this is > BCP84, but it only talks about use of ACLs in section 2.1 without > providing any examples. Given that it is also 13 years old I thought > there might be fresher information out there. section 2.1 is about permit

Re: BCP38/84 and DDoS ACLs

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear team, > Your bogon list has a few non-bogons, and is missing a few current > bogon. > > Team Cymru keep a good resource for this: http://www.team-cymru. > org/bogon-dotted-decimal.html Thank you, Dave! The full list of formats and styles ca

Re: BCP38/84 and DDoS ACLs

4 192.168.0.0 0.0.255.255 any > deny ipv4 198.18.0.0 0.1.255.255 any > deny ipv4 198.51.0.0 0.0.0.255 any > deny ipv4 203.0.113.0 0.0.0.255 any > deny ipv4 224.0.0.0 31.255.255.255 any > > > For BCP38 and 84 you would want to enable uRPF > https://en.wikipedia.org/wiki/Reverse_

Re: BCP38/84 and DDoS ACLs

air therefore does not accept > liability for any errors or omissions in the contents of this message, which > arise as a result of e-mail transmission. . > > -Original Message- > From: NANOG [mailto:nanog-bounces+kvicknair=reservetele@nanog.org] On > Behalf Of Rolan

Re: BCP38/84 and DDoS ACLs

to be honest, i do not block chargen etc at my borders; i scan hosts and turn off silly services on the hosts. but i do not have myriads of hosts in a soft gooey inside. what i block at my borders are 135-139, 161 (except for holes for measurement stations), 445, 514, stuff such as that. ykmv r

Re: BCP38/84 and DDoS ACLs

On 27 May 2017, at 0:19, Roland Dobbins wrote: > This is the correct URI for the first preso, apologies: --- Roland Dobbins

Re: BCP38/84 and DDoS ACLs

On 27 May 2017, at 0:54, valdis.kletni...@vt.edu wrote: > I'll go out on a limb and suggest that except for a very basic home/SOHO > network, "You may need" should be "You will probably need". Concur, heh. --- Roland Dobbins

Re: BCP38/84 and DDoS ACLs

On Sat, 27 May 2017 00:19:34 +0700, Roland Dobbins said: > servers/services/applications/users you have, et. al. You may need one > set of ACLs at the peering/transit edge, and other, more specific ACLs, > at the IDC distribution gateway, customer aggregation gateway, et. al. I'll go out on a li

RE: BCP38/84 and DDoS ACLs

ssage- From: NANOG [mailto:nanog-bounces+kvicknair=reservetele@nanog.org] On Behalf Of Roland Dobbins Sent: Friday, May 26, 2017 12:20 PM To: nanog@nanog.org Subject: Re: BCP38/84 and DDoS ACLs On 26 May 2017, at 22:39, Graham Johnston wrote: > I am looking for information regarding stand

Re: BCP38/84 and DDoS ACLs

On 26 May 2017, at 22:39, Graham Johnston wrote: I am looking for information regarding standard ACLs that operators may be using at the internet edge of their network, on peering and transit connections, These .pdf presos may be of interest:

Re: BCP38/84 and DDoS ACLs

224.0.0.0 31.255.255.255 any For BCP38 and 84 you would want to enable uRPF https://en.wikipedia.org/wiki/Reverse_path_forwarding https://tools.ietf.org/html/rfc3704 Rich Compton | Principal Eng | 314.596.2828 14810 Grasslands Dr,Englewood, CO80112 On 5/26/17, 11:39 AM

BCP38/84 and DDoS ACLs

gress packets such as those sourced from UDP port 19 for instance. I've found incomplete conceptual discussions about it nothing that seemed concrete or complete. This doesn't seem quite like it is BCP38 and more like this is BCP84, but it only talks about use of ACLs in section 2.1 withou

Re: BCP38 and Red Hat

On Thu, Dec 15, 2016 at 9:48 AM, Stephen Satchell wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=1370963 > > Just a reminder that I have a feature request outstanding with Red Hat > to add support for BCP38, as well as measures for certain protocol-based > amplification ref

BCP38 and Red Hat

https://bugzilla.redhat.com/show_bug.cgi?id=1370963 Just a reminder that I have a feature request outstanding with Red Hat to add support for BCP38, as well as measures for certain protocol-based amplification reflection attacks. My intent for making the suggestion is to stiffen firewalld(8) in

Re: Request for comment -- BCP38

On 9/26/16 9:37 AM, Hugo Slabbert wrote: On Mon 2016-Sep-26 12:25:58 -0400, John R. Levine wrote: I gather the usual customer response to this is "if you don't want our $50K/mo, I'm sure we can find another ISP who does." I myself am talking about the latter and included the option of PI s

Re: Request for comment -- BCP38

On 10/01/2016 06:39 PM, Jay R. Ashworth wrote: You *can* do BCP38 egress filtering on your network, but that filter would *be in control of the Bad Guys* whom we're trying to kill off. I don't see how you arrive at this conclusion. For an aggregating router, the Bad Guys(tm)

Re: Request for comment -- BCP38

* Jay R. Ashworth: > - Original Message - >> From: "Florian Weimer" > >> * Jason Iannone: > >>> Are urpf and bcp38 interchangeable terms in this discussion? It seems >>> impractical and operationally risky to implement two unique ways to

Re: Request for comment -- BCP38

gt; scalable way for ISP A to distinguish this "legitimate" use from >> spoofing; unless you consider it scalable for ISP A to maintain >> thousands if not more "exception" ACLs to uRPF and BCP38 egress >> filters to cover all of the cases of customers X, Y, and Z sour

Re: BCP38 adoption "incentives"?

- Original Message - > From: "Joe Klein" > What would it take to test for BCP38 for a specific AS? There's a tester tool, which I believe I put a link to on the wiki. One of the Cali tech universities; Berkeley? Cheers, -- jra -- Jay R. Ashworth

Re: Request for comment -- BCP38

- Original Message - > From: "Florian Weimer" > * Jason Iannone: >> Are urpf and bcp38 interchangeable terms in this discussion? It seems >> impractical and operationally risky to implement two unique ways to dos >> customers. What are the lessons

Re: Request for comment -- BCP38

bute please poke me or Alain for an account (keeping a MediaWiki despammed is a fulltime job these days, if you allow user created accounts, so we don't). The address to poke at is moderator (at) bcp38.info Cheers, -- jra -- Jay R. Ashworth Baylink j

Re: Request for comment -- BCP38

mated or scalable way for >>ISP A to distinguish this "legitimate" use from spoofing; unless you >>consider it scalable for ISP A to maintain thousands if not more >>"exception" ACLs to uRPF and BCP38 egress filters to cover all of the cases >>of customers X,

Re: Request for comment -- BCP38

tomated or >> scalable way for ISP A to distinguish this "legitimate" use from >> spoofing; unless you consider it scalable for ISP A to maintain >> thousands if not more "exception" ACLs to uRPF and BCP38 egress >> filters to cover all of the cases of cu

Re: BCP38 adoption "incentives"?

Even if the customers are unaware of the spoofed traffic, ISPs should be aware which leaves them open for "aiding and abetting". This doesn't require inspecting the payload of the packets. This is the IP header which they are expected to examine and for which there is a BCP saying to drop spoofed

Re: BCP38 adoption "incentives"?

Well there is money to be made in DDoS protection... See our "friends" still hosting "those" pay sites. Do not expect the vendors to cut themself of that market. - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770

Re: BCP38 adoption "incentives"?

In a message written on Tue, Sep 27, 2016 at 08:44:35PM +, White, Andrew wrote: > This assumes the ISP manages the customer's CPE or home router, which is > often not the case. Adding such ACLs to the upstream device, operated by the > ISP, is not always easy or feasible. Unicast RFP should

Re: BCP38 adoption "incentives"?

Alain Hebert wrote: > Do not forget the "NRA" ways. I do not understand the "NRA" reference.

Re: BCP38 adoption "incentives"?

On Tue, 27 Sep 2016 20:44:35 -, "White, Andrew" said: > This assumes the ISP manages the customer's CPE or home router, which is > often not the case. Adding such ACLs to the upstream device, operated by the > ISP, is not always easy or feasible. Hopefully, if you've been burnt by this, you r

Re: BCP38 adoption "incentives"?

Dne 27.09.16 v 16:30 Mikael Abrahamsson napsal(a): > The first page was completely devoid of any real technical information > until I found the PDF (which from the color choice doesn't even look > like a link). (https://www.nix.cz/cs/file/NIX_RULES_FENIX) > > It's still not obvious what the FENIX

Re: BCP38 adoption "incentives"?

Mike Hammett wrote: > Is that common in CMTSes or just in certain ones? it's a mandatory part of the docsis3 specification. Nick

Re: BCP38 adoption "incentives"?

org Sent: Wednesday, September 28, 2016 10:08:00 AM Subject: Re: BCP38 adoption "incentives"? At least as far as cable is concerned, there is already configuration on the CMTS (e.g. https://www.cisco.com/c/en/us/support/docs/broadband-cable/cable-security/20691-source-verify.html ) that

Re: BCP38 adoption "incentives"?

In article you write: >What would it take to test for BCP38 for a specific AS? Well, if a certain browser vendor let the browser deduce the external IP address, then send out a UDP DNS PTR query for .in-addr.browser-vendor.com to say, a large DNS resolving cluster they also happen to

Re: BCP38 adoption "incentives"?

Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > - Original Message - > > From: "Andrew White" > To: "Mike Hammett" > Cc: nanog@nanog.org > Sent: Tuesday, September 2

Re: BCP38 adoption "incentives"?

hree might be valid method to move the ball. > > Joe Klein > "Inveniam viam aut faciam" > > PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 > > On Tue, Sep 27, 2016 at 10:32 AM, Mikael Abrahamsson > wrote: > >> On Tue, 27 Sep 2016, Joe Kl

RE: BCP38 adoption "incentives"?

On Tue, 27 Sep 2016, White, Andrew wrote: This assumes the ISP manages the customer's CPE or home router, which is often not the case. Adding such ACLs to the upstream device, operated by the ISP, is not always easy or feasible. Which is why the manufacturer should deploy a default config whi

Re: BCP38 adoption "incentives"?

quot; To: "Mike Hammett" Cc: nanog@nanog.org Sent: Tuesday, September 27, 2016 3:44:35 PM Subject: RE: BCP38 adoption "incentives"? Hi Mike, This assumes the ISP manages the customer's CPE or home router, which is often not the case. Adding such ACLs to the upstream d

RE: BCP38 adoption "incentives"?

org Subject: Re: BCP38 adoption "incentives"? It would be incredibly low impact to have the residential CPE block any source address not assigned by the ISP. Done. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Ori

Re: BCP38 adoption "incentives"?

chell" To: nanog@nanog.org Sent: Tuesday, September 27, 2016 7:31:24 AM Subject: BCP38 adoption "incentives"? Does anyone know if any upstream and tiered internet providers include in their connection contracts a mandatory requirement that all directly-connected routers be in c

Re: BCP38 adoption "incentives"?

ue, Sep 27, 2016 at 10:32 AM, Mikael Abrahamsson wrote: > On Tue, 27 Sep 2016, Joe Klein wrote: > > What would it take to test for BCP38 for a specific AS? >> > > Well, you can get people to run https://www.caida.org/projects > /spoofer/#software > > I tried to ge

Re: BCP38 adoption "incentives"?

On Tue, 27 Sep 2016, Mike Jones wrote: Any network operator should know if their network is blocking it or not without having to deploy active probes across their network. Err... I was not referring to the operator doing this on the CPEs they provide to their customers. I was referring to ent

Re: BCP38 adoption "incentives"?

On 27 September 2016 at 15:32, Mikael Abrahamsson wrote: > On Tue, 27 Sep 2016, Joe Klein wrote: > >> What would it take to test for BCP38 for a specific AS? > > > Well, you can get people to run > https://www.caida.org/projects/spoofer/#software > > I tried to

Re: BCP38 adoption "incentives"?

On Tue, 27 Sep 2016, Joe Klein wrote: What would it take to test for BCP38 for a specific AS? Well, you can get people to run https://www.caida.org/projects/spoofer/#software I tried to get OpenWrt to include similar software, on by default, but some people are afraid that they might

Re: BCP38 adoption "incentives"?

On Tue, 27 Sep 2016, Zbyněk Pospíchal wrote: Dne 27.09.16 v 15:17 Mikael Abrahamsson napsal(a): Hm, so the IX operator looks at packets at the IX (sFlow perhaps), see who is sending attack packets, and if they're spoofed, this ISP is then put in "quarantine", ie their IX port is basically now

Re: BCP38 adoption "incentives"?

What would it take to test for BCP38 for a specific AS? Joe Klein "Inveniam viam aut faciam" PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 On Tue, Sep 27, 2016 at 8:31 AM, Stephen Satchell wrote: > Does anyone know if any upstream and tiered internet provide

Re: BCP38 adoption "incentives"?

Dne 27.09.16 v 15:17 Mikael Abrahamsson napsal(a): > Hm, so the IX operator looks at packets at the IX (sFlow perhaps), see > who is sending attack packets, and if they're spoofed, this ISP is then > put in "quarantine", ie their IX port is basically now useless. Definitely not. Try to read first

Re: BCP38 adoption "incentives"?

On Tue, 27 Sep 2016, Zbyněk Pospíchal wrote: The implementation of BCP38 over local market strongly increased after massive DDoS attacks in 2013 affecting major part of the industry thanks to an initiative of the most important local IXP. Hm, so the IX operator looks at packets at the IX

BCP38 -- disabusing misinformation in this discussion

"BCP38 applies only to egress filtering" INCORRECT. The title of the update to BCP38/RFC2827, BCP84/RFC2074, exposes the balderdash on its face. That title? "Ingress Filtering for Multihomed Networks." Oops. This is a short snipping from the Introduction: RFC 2827

Re: Request for comment -- BCP38

gt; * 50 subnets (to pick a number) of routeable IP address space > downstream from the edge routers, with routing announcements to the > world that direct packets back to the edge routers > > BCP38 demands that ANY packet leaving ANY edge router to the upstream > MUST have a source ad

Re: BCP38 adoption "incentives"?

The implementation of BCP38 over local market strongly increased after massive DDoS attacks in 2013 affecting major part of the industry thanks to an initiative of the most important local IXP. There is a special separate last-resort "island mode" network, which is intended to be ac

Re: BCP38 adoption "incentives"?

On Tue, 27 Sep 2016, Stephen Satchell wrote: You have to make their ignorance SUBTRACT from the bottom line. I'd say there is no way to actually achieve this. BCP38 non-compliance doesn't hurt the one not in compliance in any significant amount, it hurts everybody else. The only

BCP38 adoption "incentives"?

Does anyone know if any upstream and tiered internet providers include in their connection contracts a mandatory requirement that all directly-connected routers be in compliance with BCP38? Does anyone know if large ISPs like Comcast, Charter, or AT&T have put in place internal poli

Re: Request for comment -- BCP38

* Jason Iannone: > I have a question regarding language. We've seen bcp38 described as a > forwarding filter, preventing unallocated sources from leaving the AS. I > understand that unicast reverse path forwarding checks support bcp38, but > urpf is an input check with sign

Re: Request for comment -- BCP38

I'm trying to come up with a simple picture that embraces all the comments I've seen thus far on the definition of BCP38. The example scenario I'm about to paint may be over-simplified -- but I like to start simple. Given a single local inside network with: * multiple u

Re: Request for comment -- BCP38

I have a question regarding language. We've seen bcp38 described as a forwarding filter, preventing unallocated sources from leaving the AS. I understand that unicast reverse path forwarding checks support bcp38, but urpf is an input check with significant technical differences from o

Re: Request for comment -- BCP38

* Baldur Norddahl: > This means we can receive some packet on transit port A and then route out >>> a ICMP response on port B using the interface address from port A. But >>> transit B filters this ICMP packet because it has a source address >>> belonging to transit A. >> Interesting. But this lo

Re: Request for comment -- BCP38

rs ingress via another link (either with ISP A or another provider altogether) and so prepends, uses provider communities to depref the advertisement below another path, etc. BCP38 implementation: Feasible Path RPF[1] should work, but AFAIK is not supported on all platforms. Failure modes shou

is someone with BCP38.info update privs summarizing this discussion?

I think some pretty good information has surfaced, that would be WONDERFUL to have on that site.

Re: Request for comment -- BCP38

is an OpenPGP/MIME signed message (RFC 4880 and 3156) > --dWOXeq1OLTVjQNjObs7KPBUAPtMRfKIWN > From: Eliot Lear > To: Laszlo Hanyecz , nanog@nanog.org > Message-ID: > Subject: Re: Request for comment -- BCP38 > References: <20160926180355.1229.qm...@ary.lan> > > In-Repl

Re: Request for comment -- BCP38

p that traffic on the floor. >>>> This is a legitimate and interesting use case that is broken by BCP38. >>> I don't agree that this is legitimate. >>> >>> Also we're talking about typical mom & pop home users here. >> There are SOHO modems tha

Re: Request for comment -- BCP38

because it is a very common setup. There are thousands of networks out there that have the issue and many of them are probably not even realising it. From this follows that BCP38 can break things like traceroute and path MTU discovery in what is a very common setup. That doesn't follow

Re: Request for comment -- BCP38

his ICMP packet because it has a source address > belonging to transit A. Interesting. But this looks like a feature request for the router vendor, and not like an issue with BCP 38 filtering as such. > From this follows that BCP38 can break things like traceroute and path MTU > discovery in

  1   2   3   4   5   >