From zorz at isoc.org Fri Jul 5 07:16:57 2013 From: zorz at isoc.org (Jan Zorz - ISOC) Date: Fri, 5 Jul 2013 07:16:57 +0200 Subject: [bcop] Some ideas In-Reply-To: <8889DC743021D34399AB2D4981985CFB2C3CAB19EE@MBX21.EXCHPROD.USA.NET> References: <8889DC743021D34399AB2D4981985CFB2C3CAB19EE@MBX21.EXCHPROD.USA.NET> Message-ID: <51D656C9.4090509@isoc.org> On 6/18/13 8:58 AM, Nash, Steve wrote: > As a very early starting point, having scanned the ietf BCPs, I table the following. Hi, Thnx for this ideas (and sorry for late reply, vacations tie in Europe ;) ) > I believe we need to consider both what the requirements should be, > and also what incentives there might be for compliance. Good point. > I suggest the emphasis should be on satisfying the world at large > that the Internet community encourages its members to behave responsibly. responsibility in behavior is crucial point. > A secondary objective might be education for new operators. ...and this would make life of many other "old" operators quite easier, would it? > > ========================================== > RIPE Implementation Requirements > > 1. INHIBIT ADDRESS SPOOFING > > 1.1 BCP 38 (rfc 2827) with BCP 84 (rfc 3704) Ingress Filtering Implemented at every access router and switch as appropriate for: > 1. Single host > 2. Non-Transit subnet > 3. Registered sub-network transit (tell ISP of additional address spaces) > 4. Open Transit (restrict to BGP?) > 5...... I think something like this is already on the table and a group forming around that (Dave Freedman, Merike Kaeo, ...) after the antispoofing roundtable at RIPE66 in Dublin. > > 1.2 Install RIPE supplied anti-spoofing probe at 10% of access PoPs This is going to be a long discussion... Technically it's doable, but the community needs to say "we wand spoofing on the probes". > > 1.3 [Consider] TCP/UDP/SCTP.... port filtering > > Accept DNS replies (src port 53) only from customers requesting DNS > support. Block dest port 53 toward non-hosting clients. This should be a separate document, describing just the DNS best practices - how to setup DNS server as an ISP and how to secure it. > > > > 2. POLICIES FOR PEERING > > Register External Routing Policy in RIPE Db. Ask Peers to comply > with this doc (? Inter-RIR ?) ? Apply route filtering Wondering how many networks uses RPSL for creating filters... > > At IX ask Peers to maintain AS-MAC mapping, in order to facilitate back-tracking > > > 3. DNS POLICIES > ?rfc 2870 (BCP 40) > ?rfc 2219 BCP 17 > ?rfc 2182 BCP 16 > > > 4. POLICIES FOR EMAIL > ?rfc 2505 (BCP 30) Email server BCOP should be a separate document and I believe we have quite an extensive knowledge and experience on this topic in this group, do we? :) Cheers, Jan From hlk at solido.net Mon Jul 8 15:22:14 2013 From: hlk at solido.net (=?iso-8859-1?Q?Henrik_Lund_Kramsh=F8j?=) Date: Mon, 8 Jul 2013 15:22:14 +0200 Subject: [bcop] First email to BCOP discussion list... In-Reply-To: <51BDD798.1040209@isoc.org> References: <51BDD798.1040209@isoc.org> Message-ID: On 16/06/2013, at 17.19, Jan Zorz - ISOC wrote: > Hi all, > > Finally we have a mailing list (thnx to staff @RIPE-NCC) that we identified as one of the first next steps at BOF in Dublin RIPE meeting. > > Please send emails to: bcop at ripe.net > > This is the place, where we can discuss how to move forward with the Best Current Operational Practices work, how to maybe move it forward towards more official status, who is willing to participate and start the documents - but first of all - we agreed that we need to identify the topics of discussion. > > First few that I heard were: > > - source addr antispoofing operational practices > - peering good practices > - how to implement IPv6 at ISP (different network types and flavors) > - DNSsec how-to and practices > ... > > I would like to invite all to send suggestions so we can identify the topics - and then we can see later where we can start some effort and form a groups that would start producing a documentation. In no particular order, and based on stuff I do myself. *) DNS in auth and recursive, I always suggest keeping them in too separate "servers" (might be VMs) to ensure not opening up auth server for recursion etc. *) Perhaps best current practice documents that even present BGP policies in general, like the old book "Cisco ISP Essentials (Cisco Press Networking Technology)[Paperback]" from 2002 available in free and open format would be great for getting more secure and robust networking. Having examples in some popular variants would be great Juniper, Cisco, BIRD, OpenBGPD - I also myself used the cymru web site a lot for similar stuff, http://www.team-cymru.org/ReadingRoom/Templates/ *) a small subject I would like see also is ICMP filtering. We want people to know that blocking all of ICMP is bad for them and the internet. It prevents PMTU from working and is required for a lot of testing. So maybe some re-iteration of the ICMP and presenting also the pingable attribute in whois? (I dont use pingable myself yet, but perhaps receiving a nice BCOP doc would make me add some) I wonder if testing is also part of this? *) How to test your network performance, recommending some starting point for common testing inside networks, in my end of the world it seems to be iperf and smokeping that rules the land. I was pretty inspired by Jen Linkova at the RIPE65 meeting talking about creating stacked packet for testing MPLS Best regards Henrik -- Henrik Lund Kramsh?j, Follower of the Great Way of Unix internet samurai cand.scient CISSP hlk at kramse.org hlk at solidonetworks.com +45 2026 6000 http://solidonetworks.com/ Network Security is a business enabler From zorz at isoc.org Tue Jul 9 13:01:35 2013 From: zorz at isoc.org (Jan Zorz - ISOC) Date: Tue, 9 Jul 2013 13:01:35 +0200 Subject: [bcop] First email to BCOP discussion list... In-Reply-To: References: <51BDD798.1040209@isoc.org> Message-ID: <51DBED8F.7000803@isoc.org> On 7/8/13 3:22 PM, Henrik Lund Kramsh?j wrote: > In no particular order, and based on stuff I do myself. > > *) DNS in auth and recursive, I always suggest keeping them in too > separate "servers" (might be VMs) to ensure not opening up auth > server for recursion etc. Hi, This could be a great and useful document. I also heard that some operators also use different HW/OS platforms and different DNS server combinations (and anycast resolvers in their network) to minimize the probability that one vulnerability (OS or server) brings down all their resolvers. I think that this is also one of the good practices that could be useful to many. > > > *) Perhaps best current practice documents that even present BGP > policies in general, like the old book "Cisco ISP Essentials (Cisco > Press Networking Technology)[Paperback]" from 2002 available in free > and open format would be great for getting more secure and robust > networking. Having examples in some popular variants would be great > Juniper, Cisco, BIRD, OpenBGPD - I also myself used the cymru web > site a lot for similar stuff, > http://www.team-cymru.org/ReadingRoom/Templates/ This is a good resource and should be included in a BCOP document about BGP practices in general. > > > *) a small subject I would like see also is ICMP filtering. We want > people to know that blocking all of ICMP is bad for them and the > internet. It prevents PMTU from working and is required for a lot of > testing. With practical filter examples for different firewalls from different vendors? Agree :) > > So maybe some re-iteration of the ICMP and presenting also the > pingable attribute in whois? (I dont use pingable myself yet, but > perhaps receiving a nice BCOP doc would make me add some) Wow, nice suggestion. > > > I wonder if testing is also part of this? > > *) How to test your network performance, recommending some starting > point for common testing inside networks, in my end of the world it > seems to be iperf and smokeping that rules the land. I was pretty > inspired by Jen Linkova at the RIPE65 meeting talking about creating > stacked packet for testing MPLS That is a good topic, that should be documented - and also reminds me of another one - how to measure and understand the global visibility/performance of your network. Many people don't entirely understand, that visibility from the Internet is an issue - they connect to upstreams, announce their resources and live happily ever after. Nice, practical and clear document on how to measure their visibility from other parts of the world would also help many people. Adding Job Sneiders to cc: (not sure he's on the mailinglist), Job would you be interested in adding some experience on this topic (or maybe even start a BCOP document?)? Cheers, Jan Zorz P.S: BCOP ml subscription link: https://www.ripe.net/mailman/listinfo/bcop From hlk at solido.net Tue Jul 9 14:20:59 2013 From: hlk at solido.net (=?iso-8859-1?Q?Henrik_Lund_Kramsh=F8j?=) Date: Tue, 9 Jul 2013 14:20:59 +0200 Subject: [bcop] First email to BCOP discussion list... In-Reply-To: <51DBED8F.7000803@isoc.org> References: <51BDD798.1040209@isoc.org> <51DBED8F.7000803@isoc.org> Message-ID: On 09/07/2013, at 13.01, Jan Zorz - ISOC wrote: > On 7/8/13 3:22 PM, Henrik Lund Kramsh?j wrote: >> In no particular order, and based on stuff I do myself. >> ... >> >> I wonder if testing is also part of this? >> >> *) How to test your network performance, recommending some starting >> point for common testing inside networks, in my end of the world it >> seems to be iperf and smokeping that rules the land. I was pretty >> inspired by Jen Linkova at the RIPE65 meeting talking about creating >> stacked packet for testing MPLS > > That is a good topic, that should be documented - and also reminds me of another one - how to measure and understand the global visibility/performance of your network. > > Many people don't entirely understand, that visibility from the Internet is an issue - they connect to upstreams, announce their resources and live happily ever after. > > Nice, practical and clear document on how to measure their visibility from other parts of the world would also help many people. > > Adding Job Sneiders to cc: (not sure he's on the mailinglist), Job would you be interested in adding some experience on this topic (or maybe even start a BCOP document?)? I am not sure it belongs here, would be nice to have a list of this though. Off the top of my head, we use the following external resources to demonstrate visibility: https://stat.ripe.net/ - with all the nice widgets for embedding etc. Cyclops BGP http://cyclops.cs.ucla.edu/ BGPmon.net http://routeviews.org/ and http://bgplay.routeviews.org/ - note bgplay is also integrated into RIPEstat traceroute.org - I use this less now that http://RING.nlnog.org has expanded so nicely, but for non-ring-users pingdom (has no IPv6, and it really is becoming a problem, where to monitor IPv6 services from outside?) Best regards Henrik -- Henrik Lund Kramsh?j, Follower of the Great Way of Unix internet samurai cand.scient CISSP hlk at kramse.org hlk at solidonetworks.com +45 2026 6000 http://solidonetworks.com/ Network Security is a business enabler From ayourtch at cisco.com Tue Jul 9 15:17:56 2013 From: ayourtch at cisco.com (Andrew Yourtchenko) Date: Tue, 9 Jul 2013 15:17:56 +0200 (CEST) Subject: [bcop] First email to BCOP discussion list... In-Reply-To: References: <51BDD798.1040209@isoc.org> <51DBED8F.7000803@isoc.org> Message-ID: On Tue, 9 Jul 2013, Henrik Lund Kramsh?j wrote: > pingdom (has no IPv6, and it really is becoming a problem, where to monitor IPv6 services from outside?) http://www.v6sonar.com/ has some interesting capabilities, which may or may not fit what you need - anyway if there's something you need that it does not do - you can ping Chip - he's very very open to feedback. --a > > > > > Best regards > > Henrik > > -- > Henrik Lund Kramsh?j, Follower of the Great Way of Unix > internet samurai cand.scient CISSP > hlk at kramse.org hlk at solidonetworks.com +45 2026 6000 > http://solidonetworks.com/ Network Security is a business enabler > > > From alexsaroyan at gmail.com Fri Jul 19 15:10:40 2013 From: alexsaroyan at gmail.com (Alex Saroyan) Date: Fri, 19 Jul 2013 17:10:40 +0400 Subject: [bcop] First email to BCOP discussion list... In-Reply-To: References: <51BDD798.1040209@isoc.org> <51DBED8F.7000803@isoc.org> Message-ID: <51E93AD0.20502@gmail.com> Hi, I think BCOP regarding BGP configuration can be interesting for many companies especially covering topic about "community controlled policies/route-maps for BGP" Regards. /Alex On 07/09/2013 05:17 PM, Andrew Yourtchenko wrote: > On Tue, 9 Jul 2013, Henrik Lund Kramsh?j wrote: > >> pingdom (has no IPv6, and it really is becoming a problem, where to >> monitor IPv6 services from outside?) > > http://www.v6sonar.com/ has some interesting capabilities, which may > or may not fit what you need - anyway if there's something you need > that it does not do - you can ping Chip - he's very very open to > feedback. > > --a > > > > >> >> >> >> >> Best regards >> >> Henrik >> >> -- >> Henrik Lund Kramsh?j, Follower of the Great Way of Unix >> internet samurai cand.scient CISSP >> hlk at kramse.org hlk at solidonetworks.com +45 2026 6000 >> http://solidonetworks.com/ Network Security is a business enabler >> >> >> From zorz at isoc.org Wed Jul 24 11:35:22 2013 From: zorz at isoc.org (Jan Zorz - ISOC) Date: Wed, 24 Jul 2013 11:35:22 +0200 Subject: [bcop] First email to BCOP discussion list... In-Reply-To: <51E93AD0.20502@gmail.com> References: <51BDD798.1040209@isoc.org> <51DBED8F.7000803@isoc.org> <51E93AD0.20502@gmail.com> Message-ID: <51EF9FDA.7030706@isoc.org> On 7/19/13 3:10 PM, Alex Saroyan wrote: > Hi, > > I think BCOP regarding BGP configuration can be interesting for many > companies especially covering topic about "community controlled > policies/route-maps for BGP" Hi, thnx for a great suggestion. Added to the list of identified topics: http://www.internetsociety.org/deploy360/about/bcop/topics/ One of the much needed documents that I heard of lately is also: "IPv6 basics and troubleshooting for helpdesks around the world" It should be some sort of lowest-common-denominator document of common issues helpdesks around the world are encountering and used as a template to translate it and use it. I see this as a next speed-bump in IPv6 deployment, as operations configures and tests the IPv6-everything, but then the company is afraid of "releasing it into the wild" because of fear of helpdesk not being able to cope with it. Should I add it as one of the topics? I submitted the lightning-talk and BOF proposal to RIPE PC for Athens meeting, hope to see you all there to move this process a step forther towards some results. Cheers, Jan