|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Date: Thu, 31 Mar 2005 00:17:36 +0100 (BST) From: "Stephen J. Wilcox" <steve@telecomplete.co.uk> To: Pekka Savola <pekkas@netcore.fi> Cc: John Kristoff <jtk@northwestern.edu>, <nanog@merit.edu> In-Reply-To: <Pine.LNX.4.61.0503310033110.3194@netcore.fi> Errors-To: owner-nanog@merit.edu without wishing to repeat what can be googled for.. putting acls on your edge to protect your ebgp sessions wont work for obvious reasons -- to spoof data and disrupt a session you have to spoof the srcip which of course the acl will allow in Steve On Thu, 31 Mar 2005, Pekka Savola wrote: > > On Wed, 30 Mar 2005, John Kristoff wrote: > [on bgp/md5 and acl's] > > ACLs are often used, but vary widely depending on organization. > > It can be difficult to manage ACLs on a box with a large number > > of peers that uses many local BGP peering addresses. I'm sure > > some organizations reviewed and updated their ACLs as a result > > of the last scare, but that is a local, private decision and it > > would probably be hard to get good sample of who and what changed. > > I would be double careful here, just to make sure everybody > understands what you're protecting. > > iBGP sessions? ACLs are trivial if you have your borders secured. > > eBGP sessions? GTSM is your friend (if supported). Practically, if > you know your peer and you also protect your borders, ACLs are rather > trivial as well. > > What you seem to be saying is using ACLs to enumerate the valid > endpoints for eBGP sessions. That goes further than the above but > indeed is also a pain to set up and maintain. > > There are other attacks you can make against TCP sessions (protected > by MD5 or not) using ICMP, though. (see > draft-gont-tcpm-icmp-attacks-03.txt). > >
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |