[nsp-sec] DDoS-RS and LG visibility
Pekka Savola
pekkas at netcore.fi
Tue Dec 14 03:01:46 EST 2010
On Mon, 13 Dec 2010, Tim Wilde wrote:
> My understanding is that you should be able to use some appropriate
> route maps to keep the routes from the DDoS-RS tagged with some type of
> community that has meaning to you within your IGP - rather than making
> them identical to any other null routes you may have, keep them separate
> this way, and then in the looking glass you can simply discard any
> routes tagged with that community (or on your peering sessions with the
> looking glass from other routers, filter out those routes from even
> being sent). This should (in my admittedly limited understanding of
> these things :)) relatively seamlessly and simply keep those routes out
> of the public eye.
You're right that you implement LG by separate peerings (and not
proxied access to routers), you will be able to control what's
visible. (Though then you couldn't run other typical LG lookups e.g.
related to multicast at all.)
Otherwise, this seems difficult to do reliably. I'll try to
demonstrate that below (I think it's very common to implement LG in
this fashion).
My argument really boils down to this: if the only reasonable way to
implement DDoS-RS LG visibility requirement is by using dedicated
peerings to an LG host or having to resort to various somewhat
unreliable or complicated screen-scraping (or even remove+replace)
techniques, it's really impeding the applicability of DDoS-RS. I
would then go on to question if the LG visibility requirement could be
revisited to make it more widely and easily deployable.
.......................
A regular LG query for an IP could for example result in the
following output:
inet.0: 336740 destinations, 683024 routes (335596 active, 11 holddown, 1172 hidden)
+ = Active Route, - = Last Active, * = Both
193.166.4.96/29 *[BGP/170] 2w4d 23:23:26, localpref 400
AS path: 65000 I
> to 193.166.255.134 via ge-1/0/2.0
[BGP/170] 2w4d 23:07:35, MED 100, localpref 400
AS path: 65000 I
> to 193.166.187.174 via ge-11/0/6.0
.. you will note that matching the output by communities is not
possible, though matching by the private ASN would be. That would
require screen-scraping in case multiple matching routes are returned
(example below).
Of course YMMV on whether you consider modifying the output difficult,
but it can be complicated by factors such as default routes or
aggregates. So if I normally ask for a bogon IP I get back the default
route, and really this would mean that filtering out DDoS-RS IP is not
sufficient, I would need to substitute it with a bogus default route
in order to conceal it fully:
inet.0: 336757 destinations, 682828 routes (335392 active, 231 holddown, 1174 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 [BGP/170] 15w4d 19:29:03, MED 10, localpref 100, from 193.166.5.21
AS path: I
> to 193.166.255.94 via xe-1/3/0.0
With a 'terse' argument, you could get a different kind of output:
inet.0: 336749 destinations, 682922 routes (335485 active, 131
holddown, 1173 hidden)
+ = Active Route, - = Last Active, * = Both
A Destination P Prf Metric 1 Metric 2 Next hop AS path
* 193.166.4.96/29 B 170 400 >193.166.255.134 65000 I
B 170 400 100 >193.166.187.174 65000 I
With 'detail' or 'extensive' argument, you get even different form
(community is listed here, but issue above holds):
inet.0: 336754 destinations, 683041 routes (335601 active, 20
holddown, 1173 hidden)
193.166.4.96/29 (2 entries, 1 announced)
*BGP Preference: 170/-401
Next hop type: Router, Next hop index: 1133
Next-hop reference count: 196
Source: 193.166.255.134
Next hop: 193.166.255.134 via ge-1/0/2.0, selected
State:
Local AS: 1741 Peer AS: 65000
Age: 2w4d 23:24:57
Task: BGP_65000.193.166.255.134+55220
Announcement bits (3): 0-KRT 3-RT 7-BGP RT Background
AS path: 65000 I
AS path: Recorded
Communities: 1741:1
Accepted
Localpref: 400
Router ID: 193.166.5.26
BGP Preference: 170/-401
Next hop type: Router, Next hop index: 625
Next-hop reference count: 165
Source: 193.166.187.174
Next hop: 193.166.187.174 via ge-11/0/6.0, selected
State:
Inactive reason: Not Best in its group - Route Metric or MED comparison
Local AS: 1741 Peer AS: 65000
Age: 2w4d 23:09:06 Metric: 100
Task: BGP_65000.193.166.187.174+179
AS path: 65000 I
AS path: Recorded
Communities: 1741:1 1741:7
Accepted
Localpref: 400
Router ID: 193.166.5.35
...
This all is prone to breaking if the output format would change.
Instead of asking for a specific IP, you could ask for a bigger set of
routes, e.g.: (again, with all the different output format variants)
A Destination P Prf Metric 1 Metric 2 Next hop AS path
* 193.166.0.0/24 B 170 400 >193.166.255.134 65000 I
B 170 400 100 >193.166.187.174 65000 I
* 193.166.1.0/24 B 170 400 >193.166.255.94 65000 65005 I
B 170 200 >193.166.255.134 65000 65005 I
B 170 200 >193.166.187.174 65000 65005 I
* 193.166.2.0/24 B 170 400 >193.166.255.94 65000 65005 I
B 170 200 >193.166.255.134 65000 65005 I
B 170 200 >193.166.187.174 65000 65005 I
* 193.166.3.0/28 D 0 >xe-1/2/0.5
* 193.166.3.14/32 L 0 Local
* 193.166.3.16/28 D 0 >ge-11/1/6.0
* 193.166.3.30/32 L 0 Local
* 193.166.3.32/28 D 0 >ge-11/1/6.0
* 193.166.3.46/32 L 0 Local
* 193.166.3.64/27 D 0 >xe-1/2/0.3
....
You could also ask specifically to return routes that match a given
community or as-path (in case information about these had been
leaked). The use of these arguments could be blocked easily enough.
(e.g. 'show route protocol bgp 0.0.0.0/0 community 1741:111')
More information about the nsp-security
mailing list