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

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) don't get

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 dos >>> customers. What are

Re: Request for comment -- BCP38

On 09/26/2016 08:47 AM, Laszlo Hanyecz wrote: >> If you have links from both ISP A and ISP B and decide to send traffic >> out ISP A's link sourced from addresses ISP B allocated to you, ISP A >> *should* drop that traffic on the floor. There is no automated or >> scalable way for ISP A to

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 learned by

Re: Request for comment -- BCP38

- Original Message - > From: "Hugo Slabbert" > This seems to have split into a few different sub-threads and had some > cross-talk on which network is being described where (thanks in no small > part to my flub on John's figures and target), but this seems to be exactly

Re: Request for comment -- BCP38

- Original Message - > From: "John Levine" >>If you have links from both ISP A and ISP B and decide to send traffic out >>ISP A's link sourced from addresses ISP B allocated to you, ISP A *should* >>drop that traffic on the floor. There is no automated or scalable way

Re: Request for comment -- BCP38

- Original Message - > From: "Laszlo Hanyecz" >> If you have links from both ISP A and ISP B and decide to send traffic >> out ISP A's link sourced from addresses ISP B allocated to you, ISP A >> *should* drop that traffic on the floor. There is no automated or >>

Re: Request for comment -- BCP38

* Stephen Satchell: > Given a single local inside network with: > * multiple uplink providers (typical multi-home situation) > * multiple edge routers, each connected to an upstream via a public > routeable /30, and each further connected to the downstream inside > network > * 50 subnets

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 significant technical

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 uplink providers

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 output

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

Re: Request for comment -- BCP38

dWOXeq1OLTVjQNjObs7KPBUAPtMRfKIWN From: Eliot Lear <l...@cisco.com> To: Laszlo Hanyecz <las...@heliacal.net>, nanog@nanog.org Message-ID: <b6c3cf8f-7e41-fd98-3ba1-bfb4ae589...@cisco.com> Subject: Re: Request for comment -- BCP38 References: <20160926180355.1229.qm...@ary.lan>

Re: Request for comment -- BCP38

bfb4ae589...@cisco.com> > Subject: Re: Request for comment -- BCP38 > References: <20160926180355.1229.qm...@ary.lan> > <dc13dbd3-051c-2239-1ecb-3f4ab43b0...@heliacal.net> > In-Reply-To: <dc13dbd3-051c-2239-1ecb-3f4ab43b0...@heliacal.net> > Content-Type:

Re: Request for comment -- BCP38

Guys, You're getting wrapped around the axle. Start by solving the 90% problem, and worry about the 10% one later. BGP38 addresses the former very well, and the other 10% requires enough manual labor already that you can charge it back. Eliot On 9/26/16 8:44 PM, Laszlo Hanyecz wrote: > > >

Re: Request for comment -- BCP38

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 looks like a feature request for

Re: Request for comment -- BCP38

* Baldur Norddahl: > Den 26. sep. 2016 18.02 skrev "Mike Hammett" : >> >> The only asymmetric routing broken is when the source isn't in public > Internet route-able space. That just leaves those multi-ISP WAN routers > that NAT it. > > Some of our IP transits implement

Re: Request for comment -- BCP38

Den 26. sep. 2016 18.02 skrev "Mike Hammett" : > > The only asymmetric routing broken is when the source isn't in public Internet route-able space. That just leaves those multi-ISP WAN routers that NAT it. Some of our IP transits implement filtering. All of our transits assigned

Re: Request for comment -- BCP38

On 2016-09-26 18:03, John Levine wrote: If you have links from both ISP A and ISP B and decide to send traffic out ISP A's link sourced from addresses ISP B allocated to you, ISP A *should* drop that traffic on the floor. This is a legitimate and interesting use case that is broken by BCP38.

Re: Request for comment -- BCP38

>>> >>> If you have links from both ISP A and ISP B and decide to send traffic >>> out ISP A's link sourced from addresses ISP B allocated to you, ISP A >>> *should* drop that traffic on the floor. > >> This is a legitimate and interesting use case that is broken by BCP38. > >I don't agree that

Re: Request for comment -- BCP38

On Mon 2016-Sep-26 12:39:21 -0400, John R. Levine wrote: If we're talking about networks with that kind of MRC, is it really that far of a stretch to require PI space for this? Then again: If we're talking about that kind of MRC, then I'm assuming ISP A can be coaxed to

Re: Request for comment -- BCP38

If we're talking about networks with that kind of MRC, is it really that far of a stretch to require PI space for this? Then again: If we're talking about that kind of MRC, then I'm assuming ISP A can be coaxed to allow explicit and well-defined exceptions on the customer's links. Yes. A)

Re: Request for comment -- BCP38

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 space to cover that

Re: Request for comment -- BCP38

tt" <na...@ics-il.net> Cc: "John Levine" <jo...@iecc.com>, nanog@nanog.org Sent: Monday, September 26, 2016 11:21:55 AM Subject: Re: Request for comment -- BCP38 On Mon 2016-Sep-26 11:15:11 -0500, Mike Hammett <na...@ics-il.net> wrote: >> >>-

Re: Request for comment -- BCP38

On 26 September 2016 at 16:47, Laszlo Hanyecz wrote: > > On 2016-09-26 15:12, Hugo Slabbert wrote: > >> >> If you have links from both ISP A and ISP B and decide to send traffic >> out ISP A's link sourced from addresses ISP B allocated to you, ISP A >> *should* drop that

Re: Request for comment -- BCP38

26, 2016 11:04:33 AM Subject: Re: Request for comment -- BCP38 If you have links from both ISP A and ISP B and decide to send traffic out ISP A's link sourced from addresses ISP B allocated to you, ISP A *should* drop that traffic on the floor. There is no automated or scalable way for ISP A to

Re: Request for comment -- BCP38

On Mon 2016-Sep-26 11:15:11 -0500, Mike Hammett <na...@ics-il.net> wrote: - Original Message - From: "John Levine" <jo...@iecc.com> To: nanog@nanog.org Sent: Monday, September 26, 2016 11:04:33 AM Subject: Re: Request for comment -- BCP38 If you have links fro

Re: Request for comment -- BCP38

nanog@nanog.org Sent: Monday, September 26, 2016 11:04:33 AM Subject: Re: Request for comment -- BCP38 >If you have links from both ISP A and ISP B and decide to send traffic out >ISP A's link sourced from addresses ISP B allocated to you, ISP A *should* >drop that traffic on the flo

Re: Request for comment -- BCP38

>If you have links from both ISP A and ISP B and decide to send traffic out >ISP A's link sourced from addresses ISP B allocated to you, ISP A *should* >drop that traffic on the floor. There is no automated or scalable way for >ISP A to distinguish this "legitimate" use from spoofing; unless

Re: Request for comment -- BCP38

On 9/26/16 07:47, Stephen Satchell wrote: On 09/26/2016 07:11 AM, Paul Ferguson wrote: No -- BCP38 only prescribes filtering outbound to ensure that no packets leave your network with IP source addresses which are not from within your legitimate allocation. So, to beat that horse to a

Re: Request for comment -- BCP38

Message - From: "Laszlo Hanyecz" <las...@heliacal.net> To: nanog@nanog.org Sent: Monday, September 26, 2016 10:47:43 AM Subject: Re: Request for comment -- BCP38 On 2016-09-26 15:12, Hugo Slabbert wrote: > > On Mon 2016-Sep-26 10:47:24 -0400, Ken Chase &

Re: Request for comment -- BCP38

On 2016-09-26 15:12, Hugo Slabbert wrote: On Mon 2016-Sep-26 10:47:24 -0400, Ken Chase wrote: This might break some of those badly-behaving "dual ISP" COTS routers out there that use different inbound from outbound paths since each is the fastest of either link. As it

Re: Request for comment -- BCP38

On Mon 2016-Sep-26 10:47:24 -0400, Ken Chase wrote: This might break some of those badly-behaving "dual ISP" COTS routers out there that use different inbound from outbound paths since each is the fastest of either link. As it should. If you have links from both ISP A and

Re: Request for comment -- BCP38

On Mon 2016-Sep-26 07:47:50 -0700, Stephen Satchell wrote: On 09/26/2016 07:11 AM, Paul Ferguson wrote: No -- BCP38 only prescribes filtering outbound to ensure that no packets leave your network with IP source addresses which are not from within your legitimate

Re: Request for comment -- BCP38

> On Sep 26, 2016, at 7:47 AM, Stephen Satchell wrote: > > On 09/26/2016 07:11 AM, Paul Ferguson wrote: >> No -- BCP38 only prescribes filtering outbound to ensure that no >> packets leave your network with IP source addresses which are not >> from within your legitimate

Re: Request for comment -- BCP38

Re Stephen, > So, to beat that horse to a fare-thee-well, to be BCP38 compliant I need, on > every interface sending packets out to the internet, to block any source > address matching a subnet in the BOGON list OR not matching any of my > routeable network subnets? Plus add null-route entries

Re: Request for comment -- BCP38

On 09/26/2016 07:11 AM, Paul Ferguson wrote: No -- BCP38 only prescribes filtering outbound to ensure that no packets leave your network with IP source addresses which are not from within your legitimate allocation. So, to beat that horse to a fare-thee-well, to be BCP38 compliant I need, on

Re: Request for comment -- BCP38

This might break some of those badly-behaving "dual ISP" COTS routers out there that use different inbound from outbound paths since each is the fastest of either link. I did this manually when I was messing around with multiple broadband links on a fbsd router years ago, was glad it worked at

Re: Request for comment -- BCP38

No -- BCP38 only prescribes filtering outbound to ensure that no packets leave your network with IP source addresses which are not from within your legitimate allocation. - ferg On September 26, 2016 7:05:49 AM PDT, Stephen Satchell wrote: >Is this an accurate thumbnail

Request for comment -- BCP38

Is this an accurate thumbnail summary of BCP38 (ignoring for the moment the issues of multi-home), or is there something I missed? The basic philosophy of BCP38 boils down to two axioms: Don't let the "bad stuff" into your router Don't let the "bad stuff" leave your router