at nanog san jose, steve bellovin presented a simple proposal for bgp tcp/md5 re-keying. it is now rfc 4808 "Key Change Strategies for TCP-MD5." this allows us to install and/or roll keys without disturbing the bgp session. and it is trivial for vendors to implement and for operators to use. imiho, until it is easy for us to use ipsec, or some other wonderful universal solution, that we implement and deploy rfc 4808. it will solve 95% of our problem for the next five years while more sophisticated scheme(s) can be developed. so i propose we ask our vendors to please implement 4808, which should be far simpler than the other hacks they seem to be adding, and that those of us who care enough to use data integrity assurance on our bgp peerings deploy it. kierkegaard nietzsche you are a stoopid schmuck kant :) randy
at the end of nanog, i sent two messages. <http://www.merit.edu/mail.archives/nanog/msg03741.html> was a minor side note re 204/4 , about which we can all really do nothing for many years. it engendered the thread from hell. <http://www.merit.edu/mail.archives/nanog/msg03735.html> was regarding getting vendors to implement rfc 4808, about which we can do something, and which i think would be rather useful in actual operation of our networks. not a single comment ensued. the key chunk of the latter is
at nanog san jose, steve bellovin presented a simple proposal for bgp tcp/md5 re-keying. it is now rfc 4808 "Key Change Strategies for TCP-MD5." this allows us to install and/or roll keys without disturbing the bgp session. and it is trivial for vendors to implement and for operators to use.
imiho, until it is easy for us to use ipsec, or some other wonderful universal solution, that we implement and deploy rfc 4808. it will solve 95% of our problem for the next five years while more sophisticated scheme(s) can be developed.
i again plead for folk to look at rfc 4808 and consider whacking our vendors to implement. randy
participants (1)
-
Randy Bush