[191727] in North American Network Operators' Group
Re: Request for comment -- BCP38
daemon@ATHENA.MIT.EDU (Hugo Slabbert)
Mon Sep 26 11:13:00 2016
X-Original-To: nanog@nanog.org
Date: Mon, 26 Sep 2016 08:12:54 -0700
From: Hugo Slabbert <hugo@slabnet.com>
To: Ken Chase <math@sizone.org>
In-Reply-To: <20160926144724.GD15891@sizone.org>
Cc: North American Network Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
--WRT3RXLOp/bBMgTI
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon 2016-Sep-26 10:47:24 -0400, Ken Chase <math@sizone.org> 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 ISP B and decide to send traffic out=
=20
ISP A's link sourced from addresses ISP B allocated to you, ISP A *should*=
=20
drop that traffic on the floor. There is no automated or scalable way for=
=20
ISP A to distinguish this "legitimate" use from spoofing; unless you=20
consider it scalable for ISP A to maintain thousands if not more=20
"exception" ACLs to uRPF and BCP38 egress filters to cover all of the cases=
=20
of customers X, Y, and Z sourcing traffic into ISP A's network using IPs=20
allocated to them by other ISPs?
If you want to play asymmetry tricks, get some PI space and make=20
arrangements. If that's outside your wheelhouse, get an ISP that will sell=
=20
this to you as a service either with dissimilar links they provide to you=
=20
or over-the-top with tunnels etc.
Playing NAT games with different classes of traffic to e.g. send traffic=20
type 1 over ISP A and traffic type 2 over ISP B *BUT* using the=20
corresponding source addresses in each case and having the traffic return=
=20
back over the same links is fine and dandy. If you send traffic into an=20
ISP-provided link using addresses from another provider, though, that ISP=
=20
*should* be dropping that traffic. If they don't, send them here so we can=
=20
yell at them.
>I did this manually when I was messing around with multiple broadband link=
s on
>a fbsd router years ago, was glad it worked at the time.
>
>/kc
>
>
>On Mon, Sep 26, 2016 at 07:11:42AM -0700, Paul Ferguson said:
> >No -- BCP38 only prescribes filtering outbound to ensure that no packet=
s leave your network with IP source addresses which are not from within you=
r legitimate allocation.
> >
> > - ferg
> >
> >
> >On September 26, 2016 7:05:49 AM PDT, Stephen Satchell <list@satchell.n=
et> wrote:
> >>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
> >>>
> >>> The original definition of "bad stuff" is limited to source-
> >>> address grooming both inbound and outbound. I've expanded on the
> >>> original definition by including rule generation to control
> >>> broadcast address abuse.
> >
> >--
> >Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
>--=20
>Ken Chase - math@sizone.org Toronto Canada
--=20
Hugo Slabbert | email, xmpp/jabber: hugo@slabnet.com
pgp key: B178313E | also on Signal
--WRT3RXLOp/bBMgTI
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBCgAGBQJX6Tr2AAoJEFsnhBAb2KmAeLkP/jL1iBSJ5ArgQh3C8ywbY41W
oPgzNy/tVRcWKgwnHG/0LRSAPRcYJYxdD5RD278EbqJzAhiVah/AEfKWPz7OF9qv
cyJVfnYAgFTjUZMybOegZ+OVnBzHFzLMgnjAQC6i0bjw1T6KXXgbmM3sRh2fb0Oi
dABZOzULLac5MzmcW0L/CN2bCur/2NWbX957Dt1Nxo5keCKoUNWmYLvX/ky310CU
tM01Jj9iAGM+3Y41WPp/TJjx56Zs7GrqUXx62CdcEPqgwERIcl5x98cdiy2/hQDI
rJoCX135ZdwLGe5WRtGWPTbWvRv13Iu02gtVHzTVPwEupJZckHokZTIxpUSDl5y1
GKTKyJZBA4gMrpUmzUFmjTpmt00WZHLEOo/GZ93LjDNNpOwYAcGZbOCI/qSRhxJ4
avWyXTGGkvH6jfVeEKlmUz+4BoRpRd/cx6WBp3JnAp445zNw0sQuJJ7QjDX9pFcL
gUNXiFswsvQlxNlQlsxAmSrh+cMsXU0XsqHG0T7yJNAGM8Rqd18c58dWGDWVFi5D
QUTVONAjgylNdM5Gpd0fyXqpYQxzIuPSUEx5BRWQByK+AMiB6DD82cKAyCYEWZah
HMtoVoyyIfCJloD64RmN9UmLIeWiwMOGaFUd4SSGAsVZxxvbH0M2EYC3mhFzQ8K2
xVqXl3vJZSIva9WwaXNp
=NN6D
-----END PGP SIGNATURE-----
--WRT3RXLOp/bBMgTI--
