[191739] in North American Network Operators' Group
Re: Request for comment -- BCP38
daemon@ATHENA.MIT.EDU (Hugo Slabbert)
Mon Sep 26 12:35:38 2016
X-Original-To: nanog@nanog.org
Date: Mon, 26 Sep 2016 09:24:34 -0700
From: Hugo Slabbert <hugo@slabnet.com>
To: Mike Hammett <nanog@ics-il.net>
In-Reply-To: <20160926162155.GI16464@bamboo.slabnet.com>
Cc: John Levine <johnl@iecc.com>, nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--1ccMZA6j1vT5UqiK
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon 2016-Sep-26 09:21:55 -0700, Hugo Slabbert <hugo@slabnet.com> wrote:
>
>On Mon 2016-Sep-26 11:15:11 -0500, Mike Hammett <nanog@ics-il.net> wrote:
>
>>>
>>>----- Original Message -----
>>>
>>>From: "John Levine" <johnl@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 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 *shou=
ld*
>>>>drop that traffic on the floor. There is no automated or scalable way f=
or
>>>>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 c=
ases
>>>>of customers X, Y, and Z sourcing traffic into ISP A's network using IPs
>>>>allocated to them by other ISPs?
>>>
>>>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."
>>>
>>>From the conversations I've had with ISPs, the inability to manage
>>>legitimate traffic from dual homed customer networks is the most
>>>significant bar to widespread BCP38. I realize there's no way to do
>>>it automatically now, but it doesn't seem like total rocket science to
>>>come up with some way for providers to pass down a signed object to
>>>the customer routers that the routers can then pass back up to the
>>>customer's other providers.
>>>
>>>R's,
>>>John
>>>
>>>PS: "Illegitimate" is not a synonym for inconvenient, or hard to handle.
>>>
>
>>Are you talking BGP level customers or individual small businesses'=20
>>broadband service?
>
>I myself am talking about the latter...=20
=2E..dammit...obviously "former" here, not "latter". Caffeine injection=20
requisitioned.
>...and included the option of PI space to cover that (although I guess at=
=20
>some point this can be made fly with PA space from another provider if=20
>both providers are willing enough to play ball), though from the $50/mo=20
>figure John listed, I'm assuming he's talking about the latter.
>
>Do people really expect to be able to do this on residential or small=20
>business broadband networks? I can't remember any time in recent=20
>memory where I assumed I could set a source address to any IP I fancy=20
>and have that packet successfully make its way through the SP's=20
>network.
>
>>
>>-----
>>Mike Hammett
>>Intelligent Computing Solutions
>>http://www.ics-il.com
>>
>>Midwest-IX
>>http://www.midwest-ix.com
--=20
Hugo Slabbert | email, xmpp/jabber: hugo@slabnet.com
pgp key: B178313E | also on Signal
--1ccMZA6j1vT5UqiK
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBCgAGBQJX6UvCAAoJEFsnhBAb2KmAWfMP/2AuOGX36nuDibhszcaNSvQJ
dEUFCCAfe3LIOs3cimSX4bcJndNqOjlAq6d/ikEACa+xfSMgV5oyTSj9WDZXXTpm
xPiWtsJ/asMDetBfJdWuVm7grh9QyP4SUtVvuwK72mZ2Tgy3HO8VBgpOsiNi/z0I
uCDJOLD6H+qH6Eps1Aw1Ka7dAXZQYBnOb5s4XPkqyC4WhxoheAFgomL41pq5mswT
l+wEMtwvdK2w0ZZMv6rm91TzkOqfTFv/Q1+Sbvu2KDiU8Sni5q862hpyvgnoH4lu
xbHu8OH9AMGcZlgsuD9dJs1R5uJuFSb1H5Darp1WoYjeB82V2JmEaHS/zQrmf36k
V3RjCQHrwvAoViIzZPDIILEkAAN1HnlG/0yJYnLRTnNgajAVbwESAwSP4xJNb0Td
woQZv+NsRhlJGEuMDNGN1voJ72jBZvyUOEpzXcKtd77LB1faLAQnAfTUJF7G3uON
jwXMrqCGfxjG1aM9MCBFf0tjYC/h3A+wttJeGIoXzeiZW0r72dS/7v8dYuT8ZkbL
V7X4xkLd9LOilIIEdvUjUSfnObzR3GuxROZS2KVDGr90oLthVqCP62adwOkBqdr+
gp9Ezz9vmN6Ite5dlw6MLmA/Pma9abskvUPhM9z+qVcwra/XxZfPO35pUzaW6kls
lRWyF7n9jT6TkoMTU2uz
=ik3L
-----END PGP SIGNATURE-----
--1ccMZA6j1vT5UqiK--