[191708] in North American Network Operators' Group
BCP38 deployment [ was Re: Krebs on Security booted off Akamai
daemon@ATHENA.MIT.EDU (Hugo Slabbert)
Mon Sep 26 00:19:37 2016
X-Original-To: nanog@nanog.org
Date: Sun, 25 Sep 2016 21:19:31 -0700
From: Hugo Slabbert <hugo@slabnet.com>
To: Stephen Satchell <list@satchell.net>
In-Reply-To: <17c4a69d-127f-6f61-457e-4720bc4c19aa@satchell.net>
Cc: North American Network Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
--44szx323gjjzoljy
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun 2016-Sep-25 15:59:15 -0700, Stephen Satchell <list@satchell.net> wro=
te:
>On 09/25/2016 07:32 AM, Jay R. Ashworth wrote:
>>>From: "Jay Farrell via NANOG" <nanog@nanog.org>
>>>> And of course Brian Krebs has a thing or two to say, not the least is =
which
>>>> to push for BCP38 (good luck with that, right?).
>>>>
>>>> https://krebsonsecurity.com/2016/09/the-democratization-of-censorship/
>>Well, given how few contributions we've gotten at bcp38.info in the last,
>>what, 4 years, yeah, I guess so...
>>
>
>Yeah, right. I looked at BCP38.info, and there is very little=20
>concrete information. I've been slogging through the two RFCs, 2827=20
>and 3794, and find it tough sledding to extract the nuggets to put=20
>into my firewall and routing table. One of the more interesting new=20
>additions to my systems is this, to the routing tables:
>
### snip ###
>
>In short, I have yet to see a "cookbook" for BGP38 filtering, for ANY=20
>filtering system -- BSD, Linux, Cisco.
I am guilty of not yet contributing cookbook-type info to BCP38.info, but:
Cisco:
http://www.bcp38.info/index.php/HOWTO:Cisco points at=20
http://www.cisco.com/c/en/us/about/security-center/unicast-reverse-path-for=
warding.html
Juniper:
https://www.juniper.net/documentation/en_US/junos14.2/topics/usage-guidelin=
es/interfaces-configuring-unicast-rpf.html
http://www.juniper.net/documentation/en_US/junos15.1/topics/topic-map/unica=
st-rpf.html
Linux:
=46rom /etc/sysctl.conf:
# Uncomment the next two lines to enable Spoof protection (reverse-path=20
# filter)
# Turn on Source Address Verification in all interfaces to
# prevent some spoofing attacks
net.ipv4.conf.default.rp_filter=3D1
net.ipv4.conf.all.rp_filter=3D1
Unfortunately, the net.ipv6 equivalents for those do not yet seem to be a=
=20
thing on Linux.
For a belt-and-suspenders approach:
If you're running an edge network and not transiting traffic for any other=
=20
AS, consider using your assigned aggregates prefix lists to filter on=20
egress on your edge for anything not sourced from those aggregates.
I'm curious as to the deployment scope and experiences of various sizes of=
=20
networks in deploying the following:
1. Strict uRPF on customer-facing ports on edge networks
2. Source address filtering on upstream edge egress based on assigned=20
aggregates
3. Destination address filtering on upstream edge ingress based on=20
assigned aggregates
--=20
Hugo Slabbert | email, xmpp/jabber: hugo@slabnet.com
pgp key: B178313E | also on Signal
--44szx323gjjzoljy
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCgAGBQJX6KHNAAoJEFsnhBAb2KmAahUP/0/D2kJ7g+CZEDWZjMUc+uxF
ek+nlGPURfqxb8C/ptbxnpp8jsRUzbHaCMmSd7ROYMRm1ce3kbkpFMdTDRe/IaY2
abA+wmt65pIbcaT7xSAdqFytnFjJjVoefHamhPr6613BYUc4BSJJxpVuloRHyEg9
523HsuwytzsTD9g9BL/UKM74RphGnOnIm6RrwacaKiauww9EC+9AMn9NTFtD38Ex
+w+3m8ihp5iR3j5XWsFT3lQUm3Tp4PsOisjqm5ECxJP9BMYzV3s610oHtw8/FKVZ
etKy2tARVxtTSUw9K7XqhD1hryNm6nlqPAl9afWjGERrhtbGweV42aoyZfD6WIl8
TOiEghhlsTgs10WwdAU7AlxYRH2AVfkcrHmB4RduFJj29pmL7wiOKS++sGIvr5aK
k9TCcKu+bMxR8n6GaCvXVnveR4mqYiJhLSaiP3VE1gSbSRj4MCUNezghD/netcwr
cQdYyh8y869hsXw8ioFK5Uwf3fkRLbtHUCrJKM5SoaYKJGSRaMpoDLErOdSNMI16
0uM2qCVe+01sGTTTAXsekneD/0N2A6Hy7wthybeT+uM+ri5NYQL8x5ioNMLluB4m
6gNSpRDO/1GRRztJgAmFuIVQl+gkhJ3N3rv/UVaLf4dWn3cSh3rI5hegfzSIJ0Fw
wOmTpUL/MvRPABHHOOwR
=Pl4m
-----END PGP SIGNATURE-----
--44szx323gjjzoljy--
