[69359] in North American Network Operators' Group
RE: BGP TTL check in 12.3(7)T
daemon@ATHENA.MIT.EDU (Blaine Christian)
Thu Apr 8 11:03:30 2004
From: "Blaine Christian" <blaine.christian@mci.com>
To: "'vijay gill'" <vgill@vijaygill.com>
Cc: <nanog@merit.edu>
Date: Thu, 8 Apr 2004 11:02:49 -0400
In-reply-to: <20040408144129.GA31258@vijaygill.com>
Errors-To: owner-nanog-outgoing@merit.edu
> The TTL mechanism is just a way to distinguish at low cost=20
> between good for_us traffic and junk. So more of a classifer=20
> than a security layer, though it can be argued both ways. =20
> And even though it does have security in the title, it is=20
> _not_ a panacea for "securing" bgp or any routing information.
>=20
http://www.faqs.org/rfcs/rfc3682.html
I agree that it is not a panacea... But, you must admit, it provides an
incredible level of comfort. It would be wonderful to only allow =
internally
generated traffic to talk to the core of your network with a simple TTL
filter. Versus anti-spoofing filters from hell.
Now, when do we get it at line speed on engine 0 cards?
I hope some other vendors are listening to this conversation!
> -----Original Message-----
> From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On=20
> Behalf Of vijay gill
> Sent: Thursday, April 08, 2004 10:41 AM
> To: Hank Nussbacher
> Cc: nanog@merit.edu
> Subject: Re: BGP TTL check in 12.3(7)T
>=20
>=20
>=20
> On Thu, Apr 08, 2004 at 11:30:38AM +0200, Hank Nussbacher wrote:
> >=20
> >=20
> <http://www.cisco.com/en/US/products/sw/iosswr> =
el/ps5207/prod_bulletin0
> > 9186a00801abfda.html#wp55584>
> >=20
> > From Dave Meyer's NANOG 27 presentation:=20
> > http://www.nanog.org/mtg-0302/hack.html
> >=20
> > Not bad - Feb 2003 till April 2004 to code, test and implement a=20
> > change
> > driven by NANOG :-)
> >=20
> > Interesting that it is listed under the Routing=20
> enhancements and not=20
> > under
> > the Security enhancements of 12.3(7)T.
>=20
> The TTL mechanism is just a way to distinguish at low cost=20
> between good for_us traffic and junk. So more of a classifer=20
> than a security layer, though it can be argued both ways. =20
> And even though it does have security in the title, it is=20
> _not_ a panacea for "securing" bgp or any routing information.
>=20
http://www.faqs.org/rfcs/rfc3682.html
/vijay
/vijay
