Process for deploying new BGP attributes (experimentally or otherwise)
Amir Herzberg
amir.lists at gmail.com
Sun Jan 27 16:06:38 UTC 2019
Following our recent attempts to experiment with potential use of BGP
attributes,
I would like to understand better the desired process for using new BGP
attributes.
As mentioned earlier, we investigate currently one usage of BGP attributes
for improving BGP security - specifically, adoption of RPKI. I also have
some future ideas on other ways BGP attributes may be useful to improve BGP
security; and surely other applications, security or otherwise, may exist.
So I think we need an acceptable process to do it.
Indeed, while we aborted that experiment, I doubt that the right conclusion
is that one should simply never use a new BGP attribute... And I even hope
that the community would want us to complete our research, to see if the
particular approach we evaluate may indeed be beneficial. I think that
these sentiments were also expressed by many members of this community.
So:
- Is there some document discussing the desired (best practice) process?
[if not, maybe such document should be written?]
- We used unassigned attribute. Should one always assign an attribute
before using it? That's a possibility, but has some `costs' - and may yet
fail to prevent problems to some non-conforming networks.
- Is there an agreed-upon list of the forums and mailing lists on which one
should warn in advance about such planned announcements, and the details
that should be included?
Thanks, Amir
--
Amir Herzberg
Comcast professor for security innovation
Dept. of Computer Science and Engineering, University of Connecticut
Homepage: https://sites.google.com/site/amirherzberg/home
Publications and projects:
https://www.researchgate.net/profile/Amir_Herzberg/contributions
<https://www.researchgate.net/profile/Amir_Herzberg/publications>
Lecture notes in intro to cyber:
https://www.researchgate.net/project/Lecture-notes-on-Introduction-to-Cyber-Security
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190127/9ab2b79d/attachment.html>
More information about the NANOG
mailing list