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