RE: TCP/BGP vulnerability - easier than you think
Aditya wrote I sure hope there are no asymmetric paths on the Internet that will bite you when you turn on strict RPF on your peering interfaces </sarcasm> Seriously, if you do turn RPF on on peering interfaces, please let your peers know (plea from circa 1999)
Ah, I was waiting for someone to say something like this and make my point, thank you. In the topic I was arguing earlier (about prefix filtering peers, underlining the fact that imperfect filtering would not cause traffic loss) it does indeed create asymmetry and prohibits the use of RPF. Michel.
On Wed, 21 Apr 2004, Michel Py wrote:
Aditya wrote I sure hope there are no asymmetric paths on the Internet that will bite you when you turn on strict RPF on your peering interfaces </sarcasm> Seriously, if you do turn RPF on on peering interfaces, please let your peers know (plea from circa 1999)
Ah, I was waiting for someone to say something like this and make my point, thank you. In the topic I was arguing earlier (about prefix filtering peers, underlining the fact that imperfect filtering would not cause traffic loss) it does indeed create asymmetry and prohibits the use of RPF.
When discussing RPF towards peers or w/ asymmetric paths, I'd recommend to read RFC 3704 (/plug). If your prefix filter stops a neighbor from advertising a prefix, maybe you would have to revise your prefix filtering policy (e.g., revise it more often, get notice if the peer sends you something you're filtering, tell to peers not to advertise anythnig that's not properly in the routing DB's, etc.)? This doesn't seem so bad to me... -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
participants (2)
-
Michel Py
-
Pekka Savola