[194733] in North American Network Operators' Group
Re: BCP38/84 and DDoS ACLs
daemon@ATHENA.MIT.EDU (joel jaeggli)
Fri May 26 20:44:30 2017
X-Original-To: nanog@nanog.org
To: Kody Vicknair <kvicknair@reservetele.com>,
Roland Dobbins <rdobbins@arbor.net>, "nanog@nanog.org" <nanog@nanog.org>
From: joel jaeggli <joelja@bogus.com>
Date: Fri, 26 May 2017 17:44:18 -0700
In-Reply-To: <3979AE529B56AB47942E2423B707F16E64C0285A@RTC-EXCH01.RESERVE.LDS>
Errors-To: nanog-bounces@nanog.org
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--g2VJsFnVETFWeCCJBFaOWggUxURuJJnIC
From: joel jaeggli <joelja@bogus.com>
To: Kody Vicknair <kvicknair@reservetele.com>,
Roland Dobbins <rdobbins@arbor.net>, "nanog@nanog.org" <nanog@nanog.org>
Message-ID: <f41af6e3-9fc4-baa1-a46d-e946b42cb61e@bogus.com>
Subject: Re: BCP38/84 and DDoS ACLs
References: <82C0CE81789FE64D8F4D15263191829715CD0841@MSG6.westman.int>
<7BB753C8-7F99-4129-9E5B-97225866922B@arbor.net>
<3979AE529B56AB47942E2423B707F16E64C0285A@RTC-EXCH01.RESERVE.LDS>
In-Reply-To: <3979AE529B56AB47942E2423B707F16E64C0285A@RTC-EXCH01.RESERVE.LDS>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
On 5/26/17 10:24, Kody Vicknair wrote:
> When I was doing some research in regards to the same subject I ran acr=
oss this doc. I've found it to be very helpful.
>
> http://nabcop.org/index.php/DDoS-DoS-attack-BCOP
Causally applied RPF checks applied to transit and peer interfaces
especially exchange fabrics have a very high-liklihood of blackholing
traffic you wanted particularly during maintenance if not casually
implemented. A very careful read rfc3704/bcp 84 is a necessary part of
implementing bcp 38 filters.
>
>
> Kody Vicknair
> Network Engineer
>
> Tel: 985.536.1214
> Fax: 985.536.0300
> Email: kvicknair@reservetele.com
>
> Reserve Telecommunications
> 100 RTC Dr
> Reserve, LA 70084
>
> _______________________________________________________________________=
__________________________
>
> Disclaimer:
> The information transmitted, including attachments, is intended only fo=
r the person(s) or entity to which it is addressed and may contain confid=
ential and/or privileged material which should not disseminate, distribut=
e or be copied. Please notify Kody Vicknair immediately by e-mail if you =
have received this e-mail by mistake and delete this e-mail from your sys=
tem. E-mail transmission cannot be guaranteed to be secure or error-free =
as information could be intercepted, corrupted, lost, destroyed, arrive l=
ate or incomplete, or contain viruses. Kody Vicknair therefore does not a=
ccept liability for any errors or omissions in the contents of this messa=
ge, which arise as a result of e-mail transmission. .
>
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces+kvicknair=3Dreservetele.com@nanog.org=
] On Behalf Of Roland Dobbins
> Sent: Friday, May 26, 2017 12:20 PM
> To: nanog@nanog.org
> Subject: Re: BCP38/84 and DDoS ACLs
>
>
> On 26 May 2017, at 22:39, Graham Johnston wrote:
>
>> I am looking for information regarding standard ACLs that operators
>> may be using at the internet edge of their network, on peering and
>> transit connections,
> These .pdf presos may be of interest:
>
> <https://app.box.com/s/ko8lk4vlh1835p36na3u>
>
> <https://app.box.com/s/xznjloitly2apixr5xge>
>
> They talk about iACL and tACL design philosophy.
>
> What traffic you should permit/deny on your network is, of course, situ=
ationally-specific. Depends on what kind of network it is, what servers/=
services/applications/users you have, et. al. You may need one set of AC=
Ls at the peering/transit edge, and other, more specific ACLs, at the IDC=
distribution gateway, customer aggregation gateway, et. al.
>
> -----------------------------------
> Roland Dobbins <rdobbins@arbor.net>
>
--g2VJsFnVETFWeCCJBFaOWggUxURuJJnIC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iEYEARECAAYFAlkoy+MACgkQ8AA1q7Z/VrLsQgCeP7tTG4hWtM61+xnCN+D+VgbI
s2MAn3dpZFNh/19Pw8HL9+xXvJ9clK/a
=yppv
-----END PGP SIGNATURE-----
--g2VJsFnVETFWeCCJBFaOWggUxURuJJnIC--
