From: Church, Chuck (cchurch@wamnetgov.com)
Date: Sat Apr 24 2004 - 01:28:24 GMT-3
True, but the problem discussed on the NSP list was that now you could
become a victim of a CPU DOS, where you're getting hit with large
amounts of MD5 packets, having to do a decryption of each one to see if
it's legitimate or not. A lot of people on that list were leery of MD5
for that reason. If everyone's using a different random DSCP instead of
the standard precedence 6, it's another level of security. I suppose
you could combine the MD5 with the DSCP, assuming re-writing the DSCP
doesn't break the MD5 hash. Then you could filter out most hack
attempts with a CPU-friendly ACL, and then get the rest with the MD5
authentication. Not sure if Juniper has this functionality, so maybe
it's a moot point...
Chuck Church
Lead Design Engineer
CCIE #8776, MCNE, MCSE
Wam!Net Government Services - Design & Implementation Team
13665 Dulles Technology Dr. Ste 250
Herndon, VA 20171
Office: 703-480-2569
Cell: 703-819-3495
cchurch@wamnetgov.com
PGP key:
http://pgp.mit.edu:11371/pks/lookup?op=index&search=cchurch%40wamnetgov.
com
-----Original Message-----
From: Scott Morris [mailto:swm@emanon.com]
Sent: Saturday, April 24, 2004 12:15 AM
To: Church, Chuck; 'Group Study'
Subject: RE: BGP TCP vulnerability - possible solution??
Well... Ok, but we'd have to work that out with every one of our own
providers in a unique fashion.
If we all do the same thing, it would become predictable, therefore not
much help.
If we have to talk to each of our BGP feeds anyway, why not set up a
password? :)
Just a thought!
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713,
CISSP, JNCIS, et al.
IPExpert CCIE Program Manager
IPExpert Sr. Technical Instructor
swm@emanon.com/smorris@ipexpert.net
http://www.ipexpert.net
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Church, Chuck
Sent: Friday, April 23, 2004 11:13 PM
To: Group Study
Subject: BGP TCP vulnerability - possible solution??
All,
Been brainstorming a bit, came up with this. How about setting
either the IP precedence or DSCP with a route map and local policy, and
allowing only BGP to and from your router with this particular
precedence set? BGP defaults to precedence 6, so I used something else:
RTR1:
ip local policy route-map setprec
!
access-list 100 permit tcp any eq bgp host 192.168.0.1 range 11000 65525
access-list 100 permit tcp any range 11000 65535 host 192.168.0.1 eq bgp
access-list 120 permit tcp host 192.168.0.1 eq bgp host 192.168.0.11
range 11000 65535 precedence flash-override access-list 120 permit tcp
host
192.168.0.1 range 11000 65535 host
192.168.0.11 eq bgp precedence flash-override
access-list 120 deny tcp host 192.168.0.1 eq bgp host 192.168.0.11
range 11000 65535
access-list 120 deny tcp host 192.168.0.1 range 11000 65535 host
192.168.0.11 eq bgp
access-list 120 permit ip any any
!
route-map setprec permit 10
match ip address 100
set ip precedence flash-override
RTR2:
ip local policy route-map setdscp
!
access-list 100 permit tcp any range 11000 65525 host 192.168.0.11 eq
bgp access-list 100 permit tcp any eq bgp host 192.168.0.11 range 11000
65535
access-list 120 permit tcp host 192.168.0.11 eq bgp host 192.168.0.1
range 11000 65535 precedence flash-override access-list 120 permit tcp
host
192.168.0.11 range 11000 65535 host
192.168.0.1 eq bgp precedence flash-override
access-list 120 deny tcp host 192.168.0.11 eq bgp host 192.168.0.1
range 11000 65535
access-list 120 deny tcp host 192.168.0.11 range 11000 65535 host
192.168.0.1 eq bgp
access-list 120 permit ip any any
route-map setdscp permit 10
match ip address 100
set ip precedence flash-override
With these two setup as eBGP peers, it works fine. But if you disable
the local policy routing on one side, the access lists block the packets
as expected, which would block a rogue SYN/RST. If you can take the
performance hit on an interface or on the control plane of a router,
this might help. This example used precedence, but with DSCP, you've
got what,
64 different combinations? Certainly makes it much harder for a hacker
to get it right.
Just a thought...
Chuck Church
Lead Design Engineer
CCIE #8776, MCNE, MCSE
Wam!Net Government Services - Design & Implementation Team
13665 Dulles Technology Dr. Ste 250
Herndon, VA 20171
Office: 703-480-2569
Cell: 703-819-3495
cchurch@wamnetgov.com
PGP key:
http://pgp.mit.edu:11371/pks/lookup?op=index&search=cchurch%40wamnetgov.
com
This archive was generated by hypermail 2.1.4 : Mon May 03 2004 - 19:48:54 GMT-3