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
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
* 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
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
- 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
- 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
- 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
- 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
>>
* 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
* 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
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
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
* 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
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>
...@cisco.com>, Eliot Lear writes:
> This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
> --dWOXeq1OLTVjQNjObs7KPBUAPtMRfKIWN
> From: Eliot Lear <l...@cisco.com>
> To: Laszlo Hanyecz <las...@heliacal.net>, nanog@nanog.org
> Message-ID: <b6c3cf8f-7e41-fd98-3ba1-
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:
>
>
>
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
* 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
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
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.
>>>
>>> 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
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
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)
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
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:
>>
>>-
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
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
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
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
>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
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
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 &
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
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
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
> 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 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
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
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
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
40 matches
Mail list logo