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