[191636] in North American Network Operators' Group
Re: Krebs on Security booted off Akamai network after DDoS attack
daemon@ATHENA.MIT.EDU (Hugo Slabbert)
Fri Sep 23 21:20:29 2016
X-Original-To: nanog@nanog.org
Date: Fri, 23 Sep 2016 14:39:54 -0700
From: Hugo Slabbert <hugo@slabnet.com>
To: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <41F6A6E6-2545-40D3-8C01-380946E36C00@puck.nether.net>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--dc+cDN39EJAMEtIO
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri 2016-Sep-23 17:29:59 -0400, Jared Mauch <jared@puck.nether.net> wrot=
e:
>
>> On Sep 23, 2016, at 5:24 PM, Hugo Slabbert <hugo@slabnet.com> wrote:
>>
>> Please tell me why I can't spoof source IPs on a stateless protocol like=
GRE. If he specifically meant you can't spoof a source, hit a reflector, a=
nd gain amplification, sure, but I see zero reason why GRE can't have spoof=
ed source IPs. It bothered me sufficiently that I wrote up some spit-ballin=
g ideas about reflecting GRE using double encapsulation[2]. Very rough and =
untested, but apparently I got a bee in my bonnet...
>
>my guess is the GRE traffic was harder to filter because many providers us=
e GRE to deliver =E2=80=98clean=E2=80=99 traffic back to origin sites.
But those tunnels generally wouldn't terminate on addresses within the=20
protected block. If I'm protecting 192.0.22.0/24 for you, things would get=
=20
confused if my GRE tunnel dest is somewhere in 192.0.22.0/24 because I=20
would have a route for 192.0.22.0/24 across the GRE tunnel (either static=
=20
or more conventionally learned via BGP). I'd bank it on either a provider=
=20
touchdown or another unprotected block, otherwise I'd have a recursive=20
routing issue where the tunnel destination would get routed through the GRE=
=20
tunnel. I've been there with bouncy-bouncy tunnels on service turn-up when=
=20
that was flubbed.
Alternatively, I could pin /32s for the tunnel destinations and still learn=
=20
the shorter protected block, but even so I should then know which source=20
(my) and dest (customer's) IPs to exclude explicitly from the GRE=20
filtering.
If the attackers were hitting the GRE tunnel destination and spoofing the=
=20
tunnel source that would make things harder, but that's starting to get=20
into rather intimate knowledge of the scrubber's and customer's setup. I=
=20
could still probably filter on e.g. TTLs or drop GRE further up to the=20
northern edge on input rather than output, but agreed that is starting to=
=20
get trickier...
>
>- Jared
--=20
Hugo Slabbert | email, xmpp/jabber: hugo@slabnet.com
pgp key: B178313E | also on Signal
--dc+cDN39EJAMEtIO
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBCgAGBQJX5aEpAAoJEFsnhBAb2KmAgNEQAJLimIqBEjmmAc92WP1z963s
11nhSVXzF1NSQeDqAJmi9cQTqIn3/w+VOz+fh4w9MNUxmqqeXb3QpvIrTxWIi28q
jEwaJ16LyCFu++LsQmLo8Ru3pjy7h0WehYUTos3hsrulb2pnbdTfpSXNalsoGN2c
QlDEN5VeYVeV2dBXGkJL8A8y3D4qdnyLv0pdUhgJHo/zpn2UiAbISxzCMMsxJPX8
Ff7YIHD4rRc4MkCv5Dm8kvGVF5sx0WPgALDy4xU5QqbW0rerH6CUZpxx9zrkyufG
88cU9e+3w65FgR1xiMmTunsjwNZ/oMHY2WWcOLAwWnJxhtZiSOQ3QO8yfRGzhbDL
gzNGGszQ8b6Eepq75c2DhjvytBIlMoxw1GsOSEghJaSpuzcBeqe5Rr04Qlq1RLIc
+YoPus9XDDrQwj/4tGRsDVE20TzwlUEt7llvuSqhsPcw8EBZXjy8oaWyQSQp8Oqz
cHQo4Wfx/KDwl3wSyDHEwE/T5yR7I1plPumrMtkjs2E7c6MyJmd8dfxaok51jJ8S
DHqpyvYQfbUgjUWFdvgm9EhQGh+Tx69xL5VyQYN+d0aWc9P61E8c3fyeebwet0d8
2EyMD1xVFlLqRUpqtc9uLgW1PexQF0YyKqB8ioPoheEpNv6hJBWVUMM9eWTKQK7m
L1OkOQ3sqbZJvvaxV7R6
=7evb
-----END PGP SIGNATURE-----
--dc+cDN39EJAMEtIO--
