From robachevsky at isoc.org Tue Sep 2 09:25:36 2014 From: robachevsky at isoc.org (Andrei Robachevsky) Date: Tue, 2 Sep 2014 09:25:36 +0200 Subject: [bcop] Feedback Requested: Routing Resilience Manifesto In-Reply-To: <53B41B18.2040809@NLnetLabs.nl> References: <53B41B18.2040809@NLnetLabs.nl> Message-ID: <540570F0.5070700@isoc.org> Hi, Some of you might have commented on the Manifesto (https://www.routingmanifesto.org/). Thank you for that. BTW, it is going to get a more neutral name - Mutually Agreed Norms for Routing Security - MANRS). We are in the process of incorporating the feedback in order to release the final version. What is currently missing are references to resources providing specific guidance in a form of BCOPs, BCPs, etc. for each of the Actions. Specifically: 1. Prevent propagation of incorrect routing information ? Network defines a clear routing policy and implements a system that ensures correctness of their own announcements and announcements from their customers to adjacent networks with a prefix and as-path granularity. ? Network operator is able to communicate to their adjacent networks which announcements are correct. . Network operator applies due diligence when checking the correctness of their customer's announcements, specifically that the customer legitimately holds the ASN and the address space it announces. 2. Prevent traffic with spoofed source IP address . Network operator implements a system that enables source address validation for at least single-homed stub customer networks, their own end-users and infrastructure. Network operator implements anti-spoofing filtering to prevent packets with incorrect source IP address from entering and leaving the network. 3. Facilitate global operational communication and coordination between the network operators . Network operator maintains globally accessible up-to-date contact information. Any references to stable documents would be appreciated. Thanks, Andrei Benno Overeinder wrote on 02/07/14 16:45: > Posted for Andrei Robachevsky, ISOC. > > Colleagues, > > A small group of network operators has been working on defining a > minimal, but feasible package of recommended measures that, if deployed > on a wide scale, could result in visible improvements to the security > and resilience of the global routing system. > > Many operators are ahead of the curve and already implement much more > than the proposed recommendations. But we believe that gathering support > for these relatively small steps could pave the road to more significant > actions on a global scale. > > We called this set of recommendations a Routing Resilience Manifesto ? > you can find a draft document here: https://www.routingmanifesto.org/. > > This initial version of the Manifesto was drafted by a small group, but > we need a wider community review, your feedback, and, ultimately, your > support to make this initiative fly. It was already presented at several > venues, like RIPE and NANOG, and now we open it for a more detailed > review. Please note that this is very much a work in progress. > > Please review the document and provide your feedback and text > suggestions online or via routingmanifesto at isoc.org by 31 August 2014. > > Regards, > > Andrei Robachevsky > Internet Society > From barry.greene at smartfren.com Tue Sep 2 13:58:08 2014 From: barry.greene at smartfren.com (Barry Greene) Date: Tue, 2 Sep 2014 11:58:08 +0000 Subject: [bcop] Feedback Requested: Routing Resilience Manifesto In-Reply-To: <540570F0.5070700@isoc.org> References: <53B41B18.2040809@NLnetLabs.nl> <540570F0.5070700@isoc.org> Message-ID: Hi Andrei, Please check out a blog I wrote to answer some of the questions I was getting from people: http://www.senki.org/internet-end-500k-routes/ The advice we provide has not changed much over the years. The key thing that the Manifesto needs is a drive toward the human network. "Contact list" have a really high entropy problem. We really need the face to face time at the operator level to have trust established before the "leaks." In essence, the recommendations should be to minimize the risk and speed the recovery when mistakes happen. "Mistakes" will happen. In addition, we have malicious actors injecting routes for criminal gain. Minimizing the risk requires configuration discipline and the human network. My recommendation is to highlight the need for network engineers to meet in forums like NOGs one critical element for "routing resiliency." Barry On Sep 2, 2014, at 2:25 PM, Andrei Robachevsky wrote: > Hi, > > Some of you might have commented on the Manifesto > (https://www.routingmanifesto.org/). Thank you for that. BTW, it is > going to get a more neutral name - Mutually Agreed Norms for Routing > Security - MANRS). > > We are in the process of incorporating the feedback in order to release > the final version. > > What is currently missing are references to resources providing specific > guidance in a form of BCOPs, BCPs, etc. for each of the Actions. > Specifically: > > 1. Prevent propagation of incorrect routing information > ? Network defines a clear routing policy and implements a system > that ensures correctness of their own announcements and announcements > from their customers to adjacent networks with a prefix and as-path > granularity. > ? Network operator is able to communicate to their adjacent > networks which announcements are correct. > . Network operator applies due diligence when checking the > correctness of their customer's announcements, specifically that the > customer legitimately holds the ASN and the address space it announces. > > 2. Prevent traffic with spoofed source IP address > . Network operator implements a system that enables source address > validation for at least single-homed stub customer networks, their own > end-users and infrastructure. Network operator implements anti-spoofing > filtering to prevent packets with incorrect source IP address from > entering and leaving the network. > > > 3. Facilitate global operational communication and coordination between > the network operators > . Network operator maintains globally accessible up-to-date contact > information. > > > Any references to stable documents would be appreciated. > > Thanks, > > Andrei > > > Benno Overeinder wrote on 02/07/14 16:45: >> Posted for Andrei Robachevsky, ISOC. >> >> Colleagues, >> >> A small group of network operators has been working on defining a >> minimal, but feasible package of recommended measures that, if deployed >> on a wide scale, could result in visible improvements to the security >> and resilience of the global routing system. >> >> Many operators are ahead of the curve and already implement much more >> than the proposed recommendations. But we believe that gathering support >> for these relatively small steps could pave the road to more significant >> actions on a global scale. >> >> We called this set of recommendations a Routing Resilience Manifesto ? >> you can find a draft document here: https://www.routingmanifesto.org/. >> >> This initial version of the Manifesto was drafted by a small group, but >> we need a wider community review, your feedback, and, ultimately, your >> support to make this initiative fly. It was already presented at several >> venues, like RIPE and NANOG, and now we open it for a more detailed >> review. Please note that this is very much a work in progress. >> >> Please review the document and provide your feedback and text >> suggestions online or via routingmanifesto at isoc.org by 31 August 2014. >> >> Regards, >> >> Andrei Robachevsky >> Internet Society >> > From robachevsky at isoc.org Tue Sep 2 14:26:02 2014 From: robachevsky at isoc.org (Andrei Robachevsky) Date: Tue, 2 Sep 2014 14:26:02 +0200 Subject: [bcop] Feedback Requested: Routing Resilience Manifesto In-Reply-To: References: <53B41B18.2040809@NLnetLabs.nl> <540570F0.5070700@isoc.org> Message-ID: <5405B75A.9040004@isoc.org> Hi Barry, This is an excellent blogpost and good recommendations, too. I'd love to see what you just said below in the "comments" section on the Manifesto site. So if you can spend some time, please go to https://www.routingmanifesto.org/manifesto/, scroll down and submit your comments. What we are looking for to put in the Manifesto, next to each Action, is a set of references to relevant BCOPs. Something like draft-ietf-opsec-bgp-security, which will become an RFC soon. Are there other documents like this? Thank you again, Andrei Barry Greene wrote on 02/09/14 13:58: > Hi Andrei, > > Please check out a blog I wrote to answer some of the questions I was getting from people: > > http://www.senki.org/internet-end-500k-routes/ > > The advice we provide has not changed much over the years. The key thing that the Manifesto needs is a drive toward the human network. "Contact list" have a really high entropy problem. We really need the face to face time at the operator level to have trust established before the "leaks." In essence, the recommendations should be to minimize the risk and speed the recovery when mistakes happen. "Mistakes" will happen. > > In addition, we have malicious actors injecting routes for criminal gain. Minimizing the risk requires configuration discipline and the human network. > > My recommendation is to highlight the need for network engineers to meet in forums like NOGs one critical element for "routing resiliency." > > Barry > > > > > > On Sep 2, 2014, at 2:25 PM, Andrei Robachevsky wrote: > >> Hi, >> >> Some of you might have commented on the Manifesto >> (https://www.routingmanifesto.org/). Thank you for that. BTW, it is >> going to get a more neutral name - Mutually Agreed Norms for Routing >> Security - MANRS). >> >> We are in the process of incorporating the feedback in order to release >> the final version. >> >> What is currently missing are references to resources providing specific >> guidance in a form of BCOPs, BCPs, etc. for each of the Actions. >> Specifically: >> >> 1. Prevent propagation of incorrect routing information >> ? Network defines a clear routing policy and implements a system >> that ensures correctness of their own announcements and announcements >> from their customers to adjacent networks with a prefix and as-path >> granularity. >> ? Network operator is able to communicate to their adjacent >> networks which announcements are correct. >> . Network operator applies due diligence when checking the >> correctness of their customer's announcements, specifically that the >> customer legitimately holds the ASN and the address space it announces. >> >> 2. Prevent traffic with spoofed source IP address >> . Network operator implements a system that enables source address >> validation for at least single-homed stub customer networks, their own >> end-users and infrastructure. Network operator implements anti-spoofing >> filtering to prevent packets with incorrect source IP address from >> entering and leaving the network. >> >> >> 3. Facilitate global operational communication and coordination between >> the network operators >> . Network operator maintains globally accessible up-to-date contact >> information. >> >> >> Any references to stable documents would be appreciated. >> >> Thanks, >> >> Andrei >> >> >> Benno Overeinder wrote on 02/07/14 16:45: >>> Posted for Andrei Robachevsky, ISOC. >>> >>> Colleagues, >>> >>> A small group of network operators has been working on defining a >>> minimal, but feasible package of recommended measures that, if deployed >>> on a wide scale, could result in visible improvements to the security >>> and resilience of the global routing system. >>> >>> Many operators are ahead of the curve and already implement much more >>> than the proposed recommendations. But we believe that gathering support >>> for these relatively small steps could pave the road to more significant >>> actions on a global scale. >>> >>> We called this set of recommendations a Routing Resilience Manifesto ? >>> you can find a draft document here: https://www.routingmanifesto.org/. >>> >>> This initial version of the Manifesto was drafted by a small group, but >>> we need a wider community review, your feedback, and, ultimately, your >>> support to make this initiative fly. It was already presented at several >>> venues, like RIPE and NANOG, and now we open it for a more detailed >>> review. Please note that this is very much a work in progress. >>> >>> Please review the document and provide your feedback and text >>> suggestions online or via routingmanifesto at isoc.org by 31 August 2014. >>> >>> Regards, >>> >>> Andrei Robachevsky >>> Internet Society >>> >> > From jan at go6.si Tue Sep 9 17:01:03 2014 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 09 Sep 2014 17:01:03 +0200 Subject: [bcop] IPv6 troubleshooting for helpdesks - draft v.01 Message-ID: <540F162F.1040304@go6.si> Dear BCOP community, Just to let you know, the co-authors of "IPv6 troubleshooting for helpdesks" document published the next version of the document with some new and also a bit more fine tuned old content and revised structure. Please find the latest version in attach and also on following URL: http://go6.si/ipv6-troubleshooting-for-helpdesks/ http://go6.si/docs/IPv6-troubleshooting-for-helpdesks-v01.pdf (direct download) As the role of this BCOP TF is to find possible cooperation and further contribution - please read the document and contact the authors if you would like to work together and add some ideas. All other ideas and suggestions also welcome on this list. Cheers and thnx, Jan Zorz -------------- next part -------------- A non-text attachment was scrubbed... Name: IPv6-troubleshooting-for-helpdesks-v01.pdf Type: application/pdf Size: 372907 bytes Desc: not available URL: