Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
On 8/Sep/20 23:22, Douglas Fischer via NANOG wrote: > Exactly Mike! > > The Idea would be to define some base levels, to make the creations of > route-filtering simpler to everyone in the world. > And what comes beyond that, is in charge of each autonomous system. > > It would make the scripting and templates easier and would avoid > fat-fingers. Are we saying that what individual operators design for their own networks is "complicated", and that coalescing around a single "de facto" standard would simplify that? Mark.
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
On 8/Sep/20 22:02, Tom Beecher via NANOG wrote: > I also get that intent from the OP. However I disagree that there > should be a 'de facto' standard created for such things. All flavors > of BGP community specifications are designed to be flexible so that > different networks can design a system that is tailored to their needs. > > Having 'de facto' standards does not simplify in my opinion. I > believe it just creates more work for operators trying to navigate > around different opinions of what 'de facto' means. Indeed. Consider a new ISP starting operations in Myanmar, with little or no global peering, having to wade through tons of information to design their BGP community structure based on a "de facto" standard defined by a group of ISP's half-way around the world. What's the real value? Mark.
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
On 8/Sep/20 20:35, Mike Hammett via NANOG wrote: > How I see the OP's intent is to create a BCP of what defined > communities have what effect instead of everyone just making up > whatever they draw out of a hat, simplifying this process for everyone. Which only matters if you are extending a community outside of your own network to someone else's. If the communities are to be used internally, then it doesn't matter what definition an operator uses. Mark.
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
On 8/Sep/20 20:15, Robert Raszuk wrote: > This does not require any more trust for say directly connected peers > more then today when you publish communities on the web page. I'd tend to disagree. Trusting your direct peer to not send you default or to have a 24/7 NOC to handle connectivity issues is not the same level of trust I'd afford them to send me a community that told my network what to announce to my other eBGP neighbors or not. Of course, I am probably less trusting than most, so I'm not recommending anyone follow my advice :-). > It is not about opening up your network. It is about expressing your > policy in a common way in the exact say amount as you would open up > your network today. I can express my policy, publicly. But I can also indicate who has the power to implement that expression on my side. > Notice that in addition to common types there is equal amount of > space left for operator's define types. It is just that the structure > of community can take number of arguments used during execution - > that's all. That is all good and well, and works beautifully within an operator's network, which is the point of the capability. Extending that to non-customer networks is not technically impossible. It's just a question of trust. It's not unlike trusting your customers to send you FlowSpec instructions. No issues technically, but do you want to do it? Mark.
Re: Consolidation of Email Platforms Bad for Email?
I find this question interesting (obviously because I'm responding to the list) and have done for decades. Providing a reasonable email solution has become more and more complex while public perception is that email should be, and is, free. I see lots of sides to this debate, some have already been covered by many of you already. * Stuff has to be secure * When stuff becomes insecure it starts to cause headaches for others. * Keeping stuff secure gets harder and harder * Customers want more and more features * Customers should pay for some features/service * Some IT folk are standing up systems to help others reduce costs - again causing headaches for others * Some IT folk have set up expensive systems, funded by data mining and not customers. * Some IT folk simply object to data mining - some folk act on that objection. * There's a lot of 'activism' in the email space and has been for a very long time. * Some of the 'big providers' take some of the heat out of the activism, which only winds up some IT folk even more. * Knowledge and skills with people who can, and will, set up small systems is thinning as demand is growing. * Some want to grow and drive others to rise up their skills. * Some of those "drivers", I think [1], 'attack' learners, not unlike throwing the Apollo crew in a rocket simulator, hoping they will rise up their skills. * With limited revenue, and constant 'driver training', some eventually abandon the game. * Some view that driving training is important if you want to have skin in the game, but quickly forget their time is funded and they're not funding idealism. * Some see their lunch being taken by a rise of good 'free' software. Some react by [1] driving more updates, features and improvements 'help', which just overwhelms small operators. * Some had no choice but to stand up small systems but 'now free offerings' have empowered them to abandon the space. * Some have no thought around the issues, others simply don't care - some days there are just bigger fish. Personally, I identify with some of these issues, and perhaps there's more, but it's the 'fish' question that right now connects with me the most... https://scontent.fhlz1-1.fna.fbcdn.net/v/t1.0-9/118984848_10158758280448988_8560408895957059983_n.jpg?_nc_cat=105&_nc_sid=8bfeb9&_nc_ohc=VvSoKwD8SqkAX8hIeXE&_nc_ht=scontent.fhlz1-1.fna=69fc9c56a2e95fabe5cb637ba294ab35=5F7F5EB4 In a country of 5 million people, this graphic says we have ~18,000 people waiting for social housing. The idealist in me has turned it's attention, and while I still operate my own mail systems (mainly because I like to able to back it up and add capacity more quickly and I have trust issues with big providers changing the rules mid-stream), I to am leaning closer and closer to calling time... ...anyway, thanks for your eye balls, I'm off to put some paint on a building ready to launch a community housing trust to address that graphic. [1] - Tin Foil Hat time. D On 2020-09-09 05:25, Barry Shein via NANOG wrote: This is being portrayed a little too "either/or", that if you get spam etc from $BIGEMAIL you, service provider, block them. What goes on is multi-layer spam blocking using various tools rather than host/server blocking except as a last resort. So we'll block/toss/etc a lot of the malmail from $BIGEMAIL w/o generally blocking their servers. If we get a huge attack we have thresholds at which point we might block them for two hours (whatever) hoping it stops on its own or $BIGMAIL stops it. But those are pretty high thresholds and obviously can cause problems for our customers in delayed email but so can our mail servers being pounded on. Those $BIGMAIL delivery servers have a lot more computrons than we do. Aside: What's astounding to me is how little any of this has changed, other than consolidation perhaps -- remember when AOL's servers pounding you with spam could bring you to your knees? I do -- in over 20 years. -- Don Gould 5 Cargill Place Richmond Christchurch, New Zealand Mobile/Telegram: + 64 21 114 0699 www.bowenvale.co.nz
Any Wave Business clue on the list?
If so, can you shoot me an email offlist? Thank You, Mike
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
Per cidr-report.org, there are almost 70k ASes in the public routing table. I can't imagine there would be more than 20 different ways those networks should use BGP communities to interface with the outside world. The 95th (maybe even 99th) percentile would probably fit in 1 or 2 ways. Also, no one's going to jail for not adopting whatever standard may or may not emerge. Hell, we can't even get people to police their own traffic (BCP 38). - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: "Mike Hammett via NANOG" To: "Tom Beecher" Cc: "NANOG" Sent: Tuesday, September 8, 2020 5:56:22 PM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' The operators are snowflakes. Are the networks really snowflakes? - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: "Tom Beecher" To: "Mike Hammett" Cc: "NANOG" , "Douglas Fischer" Sent: Tuesday, September 8, 2020 3:36:22 PM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' Every network is a snowflake already. Everyone has different needs and operational considerations, which will also change over time. My community structure would not fit your needs, and yours would not fit mine. The current structure of regular and extended allows us to come up with something that works well for each of us, which is good. On Tue, Sep 8, 2020 at 4:06 PM Mike Hammett < na...@ics-il.net > wrote: Is there more desire to be flexible because people are snowflakes and their idea is the only way it should be or real, document-able reasons? - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From: "Tom Beecher" To: "Mike Hammett" < na...@ics-il.net > Cc: "NANOG" < nanog@nanog.org >, "Douglas Fischer" < fischerdoug...@gmail.com > Sent: Tuesday, September 8, 2020 3:02:37 PM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' I also get that intent from the OP. However I disagree that there should be a 'de facto' standard created for such things. All flavors of BGP community specifications are designed to be flexible so that different networks can design a system that is tailored to their needs. Having 'de facto' standards does not simplify in my opinion. I believe it just creates more work for operators trying to navigate around different opinions of what 'de facto' means. On Tue, Sep 8, 2020 at 2:35 PM Mike Hammett < na...@ics-il.net > wrote: How I see the OP's intent is to create a BCP of what defined communities have what effect instead of everyone just making up whatever they draw out of a hat, simplifying this process for everyone. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From: "Tom Beecher via NANOG" < nanog@nanog.org > To: "Douglas Fischer" < fischerdoug...@gmail.com > Cc: "NANOG" < nanog@nanog.org > Sent: Tuesday, September 8, 2020 1:30:19 PM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' BGP Large Communities ( https://tools.ietf.org/html/rfc8195 ) already provides for anyone to define the exact handling you wish. On Tue, Sep 8, 2020 at 11:57 AM Douglas Fischer via NANOG < nanog@nanog.org > wrote: Most of us have already used some BGP community policy to no-export some routes to some where. On the majority of IXPs, and most of the Transit Providers, the very common community tell to route-servers and routers "Please do no-export these routes to that ASN" is: -> 0: So we could say that this is a de-facto standard. But the Policy equivalent to "Please, export these routes only to that ASN" is very varied on all the IXPs or Transit Providers. With that said, now comes some questions: 1 - Beyond being a de-facto standard, there is any RFC, Public Policy, or something like that, that would define 0: as "no-export-to" standard? 2 - What about reserving some 16-bits ASN to use : as "export-only-to" standard? 2.1 - Is important to be 16 bits, because with (RT) extended communities, any ASN on the planet could be the target of that policy. 2.2 - Would be interesting some mnemonic number like 1000 / 1 or so. -- Douglas Fernando Fischer Engº de Controle e Automação
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
The operators are snowflakes. Are the networks really snowflakes? - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: "Tom Beecher" To: "Mike Hammett" Cc: "NANOG" , "Douglas Fischer" Sent: Tuesday, September 8, 2020 3:36:22 PM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' Every network is a snowflake already. Everyone has different needs and operational considerations, which will also change over time. My community structure would not fit your needs, and yours would not fit mine. The current structure of regular and extended allows us to come up with something that works well for each of us, which is good. On Tue, Sep 8, 2020 at 4:06 PM Mike Hammett < na...@ics-il.net > wrote: Is there more desire to be flexible because people are snowflakes and their idea is the only way it should be or real, document-able reasons? - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From: "Tom Beecher" To: "Mike Hammett" < na...@ics-il.net > Cc: "NANOG" < nanog@nanog.org >, "Douglas Fischer" < fischerdoug...@gmail.com > Sent: Tuesday, September 8, 2020 3:02:37 PM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' I also get that intent from the OP. However I disagree that there should be a 'de facto' standard created for such things. All flavors of BGP community specifications are designed to be flexible so that different networks can design a system that is tailored to their needs. Having 'de facto' standards does not simplify in my opinion. I believe it just creates more work for operators trying to navigate around different opinions of what 'de facto' means. On Tue, Sep 8, 2020 at 2:35 PM Mike Hammett < na...@ics-il.net > wrote: How I see the OP's intent is to create a BCP of what defined communities have what effect instead of everyone just making up whatever they draw out of a hat, simplifying this process for everyone. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From: "Tom Beecher via NANOG" < nanog@nanog.org > To: "Douglas Fischer" < fischerdoug...@gmail.com > Cc: "NANOG" < nanog@nanog.org > Sent: Tuesday, September 8, 2020 1:30:19 PM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' BGP Large Communities ( https://tools.ietf.org/html/rfc8195 ) already provides for anyone to define the exact handling you wish. On Tue, Sep 8, 2020 at 11:57 AM Douglas Fischer via NANOG < nanog@nanog.org > wrote: Most of us have already used some BGP community policy to no-export some routes to some where. On the majority of IXPs, and most of the Transit Providers, the very common community tell to route-servers and routers "Please do no-export these routes to that ASN" is: -> 0: So we could say that this is a de-facto standard. But the Policy equivalent to "Please, export these routes only to that ASN" is very varied on all the IXPs or Transit Providers. With that said, now comes some questions: 1 - Beyond being a de-facto standard, there is any RFC, Public Policy, or something like that, that would define 0: as "no-export-to" standard? 2 - What about reserving some 16-bits ASN to use : as "export-only-to" standard? 2.1 - Is important to be 16 bits, because with (RT) extended communities, any ASN on the planet could be the target of that policy. 2.2 - Would be interesting some mnemonic number like 1000 / 1 or so. -- Douglas Fernando Fischer Engº de Controle e Automação
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
Douglas On 08.09.2020 17:55, Douglas Fischer via NANOG wrote: > Most of us have already used some BGP community policy to no-export some > routes to some where. > > On the majority of IXPs, and most of the Transit Providers, the very > common community tell to route-servers and routers "Please do no-export > these routes to that ASN" is: > > -> 0: > > So we could say that this is a de-facto standard. > > > But the Policy equivalent to "Please, export these routes only to that > ASN" is very varied on all the IXPs or Transit Providers. > > > With that said, now comes some questions: > > 1 - Beyond being a de-facto standard, there is any RFC, Public Policy, > or something like that, that would define 0: as > "no-export-to" standard? > > 2 - What about reserving some 16-bits ASN to use : > as "export-only-to" standard? > 2.1 - Is important to be 16 bits, because with (RT) extended > communities, any ASN on the planet could be the target of that policy. > 2.2 - Would be interesting some mnemonic number like 1000 / 1 or so. > you may want to have a look at https://www.euro-ix.net/en/forixps/large-bgp-communities/ Cheers Arnold -- Keep calm, keep distance, keep connected! Arnold Nipper email: arn...@nipper.de mobile: +49 172 2650958 signature.asc Description: OpenPGP digital signature
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
Exactly Mike! The Idea would be to define some base levels, to make the creations of route-filtering simpler to everyone in the world. And what comes beyond that, is in charge of each autonomous system. It would make the scripting and templates easier and would avoid fat-fingers. Em ter., 8 de set. de 2020 às 15:35, Mike Hammett escreveu: > How I see the OP's intent is to create a BCP of what defined communities > have what effect instead of everyone just making up whatever they draw out > of a hat, simplifying this process for everyone. > > > > - > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > -- > *From: *"Tom Beecher via NANOG" > *To: *"Douglas Fischer" > *Cc: *"NANOG" > *Sent: *Tuesday, September 8, 2020 1:30:19 PM > *Subject: *Re: BGP Community - AS0 is de-facto "no-export-to" marker - > Any ASN reserved to "export-only-to"?' > > BGP Large Communities ( https://tools.ietf.org/html/rfc8195 ) already > provides for anyone to define the exact handling you wish. > > > > On Tue, Sep 8, 2020 at 11:57 AM Douglas Fischer via NANOG > wrote: > >> Most of us have already used some BGP community policy to no-export some >> routes to some where. >> >> On the majority of IXPs, and most of the Transit Providers, the very >> common community tell to route-servers and routers "Please do no-export >> these routes to that ASN" is: >> >> -> 0: >> >> So we could say that this is a de-facto standard. >> >> >> But the Policy equivalent to "Please, export these routes only to that >> ASN" is very varied on all the IXPs or Transit Providers. >> >> >> With that said, now comes some questions: >> >> 1 - Beyond being a de-facto standard, there is any RFC, Public Policy, or >> something like that, that would define 0: as "no-export-to" >> standard? >> >> 2 - What about reserving some 16-bits ASN to use : >> as "export-only-to" standard? >> 2.1 - Is important to be 16 bits, because with (RT) extended communities, >> any ASN on the planet could be the target of that policy. >> 2.2 - Would be interesting some mnemonic number like 1000 / 1 or so. >> >> -- >> Douglas Fernando Fischer >> Engº de Controle e Automação >> > > -- Douglas Fernando Fischer Engº de Controle e Automação
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
Every network is a snowflake already. Everyone has different needs and operational considerations, which will also change over time. My community structure would not fit your needs, and yours would not fit mine. The current structure of regular and extended allows us to come up with something that works well for each of us, which is good. On Tue, Sep 8, 2020 at 4:06 PM Mike Hammett wrote: > Is there more desire to be flexible because people are snowflakes and > their idea is the only way it should be or real, document-able reasons? > > > > - > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > -- > *From: *"Tom Beecher" > *To: *"Mike Hammett" > *Cc: *"NANOG" , "Douglas Fischer" < > fischerdoug...@gmail.com> > *Sent: *Tuesday, September 8, 2020 3:02:37 PM > *Subject: *Re: BGP Community - AS0 is de-facto "no-export-to" marker - > Any ASN reserved to "export-only-to"?' > > I also get that intent from the OP. However I disagree that there should > be a 'de facto' standard created for such things. All flavors of BGP > community specifications are designed to be flexible so that different > networks can design a system that is tailored to their needs. > > Having 'de facto' standards does not simplify in my opinion. I believe it > just creates more work for operators trying to navigate around different > opinions of what 'de facto' means. > > > > > On Tue, Sep 8, 2020 at 2:35 PM Mike Hammett wrote: > >> How I see the OP's intent is to create a BCP of what defined communities >> have what effect instead of everyone just making up whatever they draw out >> of a hat, simplifying this process for everyone. >> >> >> >> - >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> >> -- >> *From: *"Tom Beecher via NANOG" >> *To: *"Douglas Fischer" >> *Cc: *"NANOG" >> *Sent: *Tuesday, September 8, 2020 1:30:19 PM >> *Subject: *Re: BGP Community - AS0 is de-facto "no-export-to" marker - >> Any ASN reserved to "export-only-to"?' >> >> BGP Large Communities ( https://tools.ietf.org/html/rfc8195 ) already >> provides for anyone to define the exact handling you wish. >> >> >> >> On Tue, Sep 8, 2020 at 11:57 AM Douglas Fischer via NANOG < >> nanog@nanog.org> wrote: >> >>> Most of us have already used some BGP community policy to no-export some >>> routes to some where. >>> >>> On the majority of IXPs, and most of the Transit Providers, the very >>> common community tell to route-servers and routers "Please do no-export >>> these routes to that ASN" is: >>> >>> -> 0: >>> >>> So we could say that this is a de-facto standard. >>> >>> >>> But the Policy equivalent to "Please, export these routes only to that >>> ASN" is very varied on all the IXPs or Transit Providers. >>> >>> >>> With that said, now comes some questions: >>> >>> 1 - Beyond being a de-facto standard, there is any RFC, Public Policy, >>> or something like that, that would define 0: as "no-export-to" >>> standard? >>> >>> 2 - What about reserving some 16-bits ASN to use : >>> as "export-only-to" standard? >>> 2.1 - Is important to be 16 bits, because with (RT) extended >>> communities, any ASN on the planet could be the target of that policy. >>> 2.2 - Would be interesting some mnemonic number like 1000 / 1 or so. >>> >>> -- >>> Douglas Fernando Fischer >>> Engº de Controle e Automação >>> >> >> >
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
Is there more desire to be flexible because people are snowflakes and their idea is the only way it should be or real, document-able reasons? - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: "Tom Beecher" To: "Mike Hammett" Cc: "NANOG" , "Douglas Fischer" Sent: Tuesday, September 8, 2020 3:02:37 PM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' I also get that intent from the OP. However I disagree that there should be a 'de facto' standard created for such things. All flavors of BGP community specifications are designed to be flexible so that different networks can design a system that is tailored to their needs. Having 'de facto' standards does not simplify in my opinion. I believe it just creates more work for operators trying to navigate around different opinions of what 'de facto' means. On Tue, Sep 8, 2020 at 2:35 PM Mike Hammett < na...@ics-il.net > wrote: How I see the OP's intent is to create a BCP of what defined communities have what effect instead of everyone just making up whatever they draw out of a hat, simplifying this process for everyone. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From: "Tom Beecher via NANOG" < nanog@nanog.org > To: "Douglas Fischer" < fischerdoug...@gmail.com > Cc: "NANOG" < nanog@nanog.org > Sent: Tuesday, September 8, 2020 1:30:19 PM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' BGP Large Communities ( https://tools.ietf.org/html/rfc8195 ) already provides for anyone to define the exact handling you wish. On Tue, Sep 8, 2020 at 11:57 AM Douglas Fischer via NANOG < nanog@nanog.org > wrote: Most of us have already used some BGP community policy to no-export some routes to some where. On the majority of IXPs, and most of the Transit Providers, the very common community tell to route-servers and routers "Please do no-export these routes to that ASN" is: -> 0: So we could say that this is a de-facto standard. But the Policy equivalent to "Please, export these routes only to that ASN" is very varied on all the IXPs or Transit Providers. With that said, now comes some questions: 1 - Beyond being a de-facto standard, there is any RFC, Public Policy, or something like that, that would define 0: as "no-export-to" standard? 2 - What about reserving some 16-bits ASN to use : as "export-only-to" standard? 2.1 - Is important to be 16 bits, because with (RT) extended communities, any ASN on the planet could be the target of that policy. 2.2 - Would be interesting some mnemonic number like 1000 / 1 or so. -- Douglas Fernando Fischer Engº de Controle e Automação
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
I also get that intent from the OP. However I disagree that there should be a 'de facto' standard created for such things. All flavors of BGP community specifications are designed to be flexible so that different networks can design a system that is tailored to their needs. Having 'de facto' standards does not simplify in my opinion. I believe it just creates more work for operators trying to navigate around different opinions of what 'de facto' means. On Tue, Sep 8, 2020 at 2:35 PM Mike Hammett wrote: > How I see the OP's intent is to create a BCP of what defined communities > have what effect instead of everyone just making up whatever they draw out > of a hat, simplifying this process for everyone. > > > > - > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > -- > *From: *"Tom Beecher via NANOG" > *To: *"Douglas Fischer" > *Cc: *"NANOG" > *Sent: *Tuesday, September 8, 2020 1:30:19 PM > *Subject: *Re: BGP Community - AS0 is de-facto "no-export-to" marker - > Any ASN reserved to "export-only-to"?' > > BGP Large Communities ( https://tools.ietf.org/html/rfc8195 ) already > provides for anyone to define the exact handling you wish. > > > > On Tue, Sep 8, 2020 at 11:57 AM Douglas Fischer via NANOG > wrote: > >> Most of us have already used some BGP community policy to no-export some >> routes to some where. >> >> On the majority of IXPs, and most of the Transit Providers, the very >> common community tell to route-servers and routers "Please do no-export >> these routes to that ASN" is: >> >> -> 0: >> >> So we could say that this is a de-facto standard. >> >> >> But the Policy equivalent to "Please, export these routes only to that >> ASN" is very varied on all the IXPs or Transit Providers. >> >> >> With that said, now comes some questions: >> >> 1 - Beyond being a de-facto standard, there is any RFC, Public Policy, or >> something like that, that would define 0: as "no-export-to" >> standard? >> >> 2 - What about reserving some 16-bits ASN to use : >> as "export-only-to" standard? >> 2.1 - Is important to be 16 bits, because with (RT) extended communities, >> any ASN on the planet could be the target of that policy. >> 2.2 - Would be interesting some mnemonic number like 1000 / 1 or so. >> >> -- >> Douglas Fernando Fischer >> Engº de Controle e Automação >> > >
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
Douglas,
On Tue, 8 Sep 2020 at 17:55, Douglas Fischer via NANOG wrote:
>
> Most of us have already used some BGP community policy to no-export some
> routes to somewhere.
>
> On the majority of IXPs, and most of the Transit Providers, the very common
> community tell to route-servers and routers "Please do no-export these routes
> to that ASN" is:
>
> -> 0:
>
> So we could say that this is a de-facto standard.
>
>
> But the Policy equivalent to "Please, export these routes only to that ASN"
> is very varied on all the IXPs or Transit Providers.
>
>
> With that said, now comes some questions:
>
> 1 - Beyond being a de-facto standard, there is any RFC, Public Policy, or
> something like that, that would define 0: as "no-export-to"
> standard?
>
> 2 - What about reserving some 16-bits ASN to use : as
> "export-only-to" standard?
> 2.1 - Is important to be 16 bits, because with (RT) extended communities, any
> ASN on the planet could be the target of that policy.
> 2.2 - Would be interesting some mnemonic number like 1000 / 1 or so.
Please see:
- https://www.euro-ix.net/en/forixps/large-bgp-communities/
- https://tools.ietf.org/id/draft-adkp-grow-ixpcommunities-00.html
If you use large communities (yes, I know the standard is NOT 100%
unilaterally supported by all vendors just yet).
Using the combination of RS${ASN}:0:0 (Don't announce to any peer) and
RS${ASN}:1:${PEERAS} (Advertise to PEERAS) you can do what you are
asking for. Announcing routes to only select peers.
Most major IXP's will support most of the mentioned large
communities. For ISP's in general. It's thou a different story that is
not mine to speak about.
Using 2-byte communities in today's age of explosive "assignment" of
4-byte ASN's is similar to the price-hike of IPv4 space. In the long
term. Standard BGP communities and IPv4 will not be worth the required
effort/investment (unless you want to "cripple" yourself from the
get-go). And IPv6 and Large BGP Communities is "slowly" gaining traction
as the way to go.
--
Cheers,
Chriztoffer
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
How I see the OP's intent is to create a BCP of what defined communities have what effect instead of everyone just making up whatever they draw out of a hat, simplifying this process for everyone. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: "Tom Beecher via NANOG" To: "Douglas Fischer" Cc: "NANOG" Sent: Tuesday, September 8, 2020 1:30:19 PM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' BGP Large Communities ( https://tools.ietf.org/html/rfc8195 ) already provides for anyone to define the exact handling you wish. On Tue, Sep 8, 2020 at 11:57 AM Douglas Fischer via NANOG < nanog@nanog.org > wrote: Most of us have already used some BGP community policy to no-export some routes to some where. On the majority of IXPs, and most of the Transit Providers, the very common community tell to route-servers and routers "Please do no-export these routes to that ASN" is: -> 0: So we could say that this is a de-facto standard. But the Policy equivalent to "Please, export these routes only to that ASN" is very varied on all the IXPs or Transit Providers. With that said, now comes some questions: 1 - Beyond being a de-facto standard, there is any RFC, Public Policy, or something like that, that would define 0: as "no-export-to" standard? 2 - What about reserving some 16-bits ASN to use : as "export-only-to" standard? 2.1 - Is important to be 16 bits, because with (RT) extended communities, any ASN on the planet could be the target of that policy. 2.2 - Would be interesting some mnemonic number like 1000 / 1 or so. -- Douglas Fernando Fischer Engº de Controle e Automação
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
BGP Large Communities ( https://tools.ietf.org/html/rfc8195 ) already provides for anyone to define the exact handling you wish. On Tue, Sep 8, 2020 at 11:57 AM Douglas Fischer via NANOG wrote: > Most of us have already used some BGP community policy to no-export some > routes to some where. > > On the majority of IXPs, and most of the Transit Providers, the very > common community tell to route-servers and routers "Please do no-export > these routes to that ASN" is: > > -> 0: > > So we could say that this is a de-facto standard. > > > But the Policy equivalent to "Please, export these routes only to that > ASN" is very varied on all the IXPs or Transit Providers. > > > With that said, now comes some questions: > > 1 - Beyond being a de-facto standard, there is any RFC, Public Policy, or > something like that, that would define 0: as "no-export-to" > standard? > > 2 - What about reserving some 16-bits ASN to use : > as "export-only-to" standard? > 2.1 - Is important to be 16 bits, because with (RT) extended communities, > any ASN on the planet could be the target of that policy. > 2.2 - Would be interesting some mnemonic number like 1000 / 1 or so. > > -- > Douglas Fernando Fischer > Engº de Controle e Automação >
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
Mark, This does not require any more trust for say directly connected peers more then today when you publish communities on the web page. It is not about opening up your network. It is about expressing your policy in a common way in the exact say amount as you would open up your network today. Notice that in addition to common types there is equal amount of space left for operator's define types. It is just that the structure of community can take number of arguments used during execution - that's all. Thx, R. On Tue, Sep 8, 2020 at 8:10 PM Mark Tinka wrote: > > > On 8/Sep/20 18:41, Robert Raszuk wrote: > > > I don't think this is the ask here. > > > > Today NO_EXPORT takes no parameters. I think it would be of benefit to > > all to be able to signal NO_EXPORT TO ASN_X in a common (std) way > > across all of my peers connected to ASN_X. Moreover policy on all > > vendors could understand it too without you worrying to match > > YOUR_STRING and translate into some local policy. > > > > That is by no means taking away anything you have at your fingertips > > .. it just adds an option to talk common policy language. > > This already happens today, but mostly in a commercial relationship > (customer and provider). > > While not technically impossible, I struggle to see operators opening up > their networks to peers they hardly personally (or commercially) know > with such a feature, custom or standardized. > > I suppose the bigger question is - can we trust each other, as peers, > with such access to each other's networks? > > Mark. >
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
On 8/Sep/20 18:41, Robert Raszuk wrote: > I don't think this is the ask here. > > Today NO_EXPORT takes no parameters. I think it would be of benefit to > all to be able to signal NO_EXPORT TO ASN_X in a common (std) way > across all of my peers connected to ASN_X. Moreover policy on all > vendors could understand it too without you worrying to match > YOUR_STRING and translate into some local policy. > > That is by no means taking away anything you have at your fingertips > .. it just adds an option to talk common policy language. This already happens today, but mostly in a commercial relationship (customer and provider). While not technically impossible, I struggle to see operators opening up their networks to peers they hardly personally (or commercially) know with such a feature, custom or standardized. I suppose the bigger question is - can we trust each other, as peers, with such access to each other's networks? Mark.
Re: Consolidation of Email Platforms Bad for Email?
This is being portrayed a little too "either/or", that if you get spam etc from $BIGEMAIL you, service provider, block them. What goes on is multi-layer spam blocking using various tools rather than host/server blocking except as a last resort. So we'll block/toss/etc a lot of the malmail from $BIGEMAIL w/o generally blocking their servers. If we get a huge attack we have thresholds at which point we might block them for two hours (whatever) hoping it stops on its own or $BIGMAIL stops it. But those are pretty high thresholds and obviously can cause problems for our customers in delayed email but so can our mail servers being pounded on. Those $BIGMAIL delivery servers have a lot more computrons than we do. Aside: What's astounding to me is how little any of this has changed, other than consolidation perhaps -- remember when AOL's servers pounding you with spam could bring you to your knees? I do -- in over 20 years. -- -Barry Shein Software Tool & Die| b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
Re: PTP/Syncronized Ethernet maturity
Hi Geir, Can we say, from your production network experiences across Asia and Europe, that getting synchronization clock signal via GNSS receiver directly on each cell site is a much more reliable, stable, and simpler way than getting it by network-based PTP? Especially when there is WDM link used in between the BC and Slave Clock? Why does WDM link cause path asymmetry? I thought the optical fibers carry forward link and reverse link are almost equal in length (distance). Aren't they? What are your solutions to overcome the PTP synchronization instability problems in your TDD 4G/5G networks? Thanks and best regards, Taichi On Tue, Sep 8, 2020 at 11:09 PM geir egeland via NANOG wrote: > We have mobile NWs in both Asia and Europe and also experience a lot of > issues with PTP, - almost with every vendor. > The instabilities, SW-bugs etc. related to PTP seems to indicate that very > little testing of this code has been done in production networks. In some > deployments we have been able to produce a clock service by installing GNSS > on the cell-site. However, in other countries there are regulatory > directives that the phase sync must be PTP/Network based. > > Currently, the optical domain is causing us huge problems when we try to > engineer a T-BC/PTP solution. This is due to the path asymmetry that exist > in the WDM/fiber domain. In some networks we have a lot of DCF in the fiber > path and the only way we can get visibility in the asymmetry on these fiber > hops is to measure in both direction:( > Also, running T-BC over WDM/OTN will simply not work as the phase error > introduced more or less eats up the phase error budget for 4G/5G > TDD-service. > > best regards, > Geir > > On 5 Sep 2020, at 00:17, Macho Pellegrini via NANOG > wrote: > > Hello everybody, > > We have deployed PTP in our mobile NW since late 2019 as a part of the > 4G/5G, however we are seeing a lots of instabilities and interop issues, a > lot of the issues have ended up with SW bugs in the OS, I have no specific > question, however I got the impression that the technology/protocol is not > yet mature, anybody here got his hands dirty with PTP? > > Thanks, > MP > > >
Spoofer Report for NANOG for Aug 2020
In response to feedback from operational security communities, CAIDA's source address validation measurement project (https://spoofer.caida.org) is automatically generating monthly reports of ASes originating prefixes in BGP for systems from which we received packets with a spoofed source address. We are publishing these reports to network and security operations lists in order to ensure this information reaches operational contacts in these ASes. This report summarises tests conducted within usa, can. Inferred improvements during Aug 2020: ASNName Fixed-By 10965 MRNET 2020-08-15 60068 CDN77 2020-08-27 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Aug 2020: ASNName First-Spoofed Last-Spoofed 209CENTURYLINK-US-LEGACY-QWEST 2016-08-16 2020-08-28 6128 CABLE-NET-1 2016-09-03 2020-08-30 20412 CLARITY-TELECOM 2016-09-30 2020-08-28 6181 FUSE-NET 2016-10-10 2020-08-31 174COGENT-1742016-10-21 2020-08-18 32440 LONI 2016-11-03 2020-08-30 12083 WOW-INTERNET 2016-11-09 2020-08-31 20473 AS-CHOOPA 2017-01-08 2020-08-25 63296 AWBROADBAND 2017-09-01 2020-08-24 546PARSONS-PGS-1 2017-11-20 2020-08-05 8100 ASN-QUADRANET-GLOBAL 2018-04-06 2020-08-18 16837 VABB 2018-06-22 2020-08-07 20448 VPNTRANET-LLC 2018-09-20 2020-08-31 63275 RADIOWIRE 2019-02-07 2020-08-10 8047 GCI 2019-04-11 2020-08-27 11650 PLDI 2020-05-25 2020-08-28 393397 LREC-LRT 2020-08-02 2020-08-02 40156 THEOPT-HOU2020-08-13 2020-08-13 3 GTCOMM2020-08-24 2020-08-24 46816 DSNETWORKS-0012020-08-24 2020-08-24 4986 INTERSTAR 2020-08-24 2020-08-24 32489 AMANAHA-NEW 2020-08-24 2020-08-24 11051 CYBERVERSE2020-08-25 2020-08-25 398019 DYNU 2020-08-25 2020-08-25 61317 ASDETUK 2020-08-31 2020-08-31 27257 WEBAIR-INTERNET 2020-08-31 2020-08-31 7040 NETMINDERS2020-08-31 2020-08-31 Further information for these tests where we received spoofed packets is available at: https://spoofer.caida.org/recent_tests.php?country_include=usa,can_block=1 Please send any feedback or suggestions to spoofer-i...@caida.org
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
Mark, > The standard already exists... "NO_EXPORT". I don't think this is the ask here. Today NO_EXPORT takes no parameters. I think it would be of benefit to all to be able to signal NO_EXPORT TO ASN_X in a common (std) way across all of my peers connected to ASN_X. Moreover policy on all vendors could understand it too without you worrying to match YOUR_STRING and translate into some local policy. That is by no means taking away anything you have at your fingertips .. it just adds an option to talk common policy language. Cheers, R. On Tue, Sep 8, 2020 at 6:23 PM Mark Tinka via NANOG wrote: > > > On 8/Sep/20 17:55, Douglas Fischer via NANOG wrote: > > Most of us have already used some BGP community policy to no-export some > routes to some where. > > On the majority of IXPs, and most of the Transit Providers, the very > common community tell to route-servers and routers "Please do no-export > these routes to that ASN" is: > > -> 0: > > So we could say that this is a de-facto standard. > > > But the Policy equivalent to "Please, export these routes only to that > ASN" is very varied on all the IXPs or Transit Providers. > > > With that said, now comes some questions: > > 1 - Beyond being a de-facto standard, there is any RFC, Public Policy, or > something like that, that would define 0: as "no-export-to" > standard? > > 2 - What about reserving some 16-bits ASN to use : > as "export-only-to" standard? > 2.1 - Is important to be 16 bits, because with (RT) extended communities, > any ASN on the planet could be the target of that policy. > 2.2 - Would be interesting some mnemonic number like 1000 / 1 or so. > > > The standard already exists... "NO_EXPORT". Provided ISP's or exchange > points can publish their own local values to match that within their > network, I believe they can do whatever they want, since it's > locally-significant. > > I'm not sure we want to go down the trail of standardizing a "de facto" > usage. Just like QoS, it may be doomed as different operators define what > it means for them. > > Mark. >
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
On 8/Sep/20 17:55, Douglas Fischer via NANOG wrote: > Most of us have already used some BGP community policy to no-export > some routes to some where. > > On the majority of IXPs, and most of the Transit Providers, the very > common community tell to route-servers and routers "Please do > no-export these routes to that ASN" is: > > -> 0: > > So we could say that this is a de-facto standard. > > > But the Policy equivalent to "Please, export these routes only to that > ASN" is very varied on all the IXPs or Transit Providers. > > > With that said, now comes some questions: > > 1 - Beyond being a de-facto standard, there is any RFC, Public Policy, > or something like that, that would define 0: as > "no-export-to" standard? > > 2 - What about reserving some 16-bits ASN to use > : as "export-only-to" standard? > 2.1 - Is important to be 16 bits, because with (RT) extended > communities, any ASN on the planet could be the target of that policy. > 2.2 - Would be interesting some mnemonic number like 1000 / 1 or so. The standard already exists... "NO_EXPORT". Provided ISP's or exchange points can publish their own local values to match that within their network, I believe they can do whatever they want, since it's locally-significant. I'm not sure we want to go down the trail of standardizing a "de facto" usage. Just like QoS, it may be doomed as different operators define what it means for them. Mark.
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
Hi Douglas, Just FYI I have tried to capture most common use cases of communities and register them as part of a wide-community effort in IANA. https://tools.ietf.org/html/draft-ietf-idr-registered-wide-bgp-communities-02 That draft is pending standardization of wide-communities itself. You are obviously very welcome to either reuse some of this work or support it :) Kind regards, R. On Tue, Sep 8, 2020 at 5:58 PM Douglas Fischer via NANOG wrote: > Most of us have already used some BGP community policy to no-export some > routes to some where. > > On the majority of IXPs, and most of the Transit Providers, the very > common community tell to route-servers and routers "Please do no-export > these routes to that ASN" is: > > -> 0: > > So we could say that this is a de-facto standard. > > > But the Policy equivalent to "Please, export these routes only to that > ASN" is very varied on all the IXPs or Transit Providers. > > > With that said, now comes some questions: > > 1 - Beyond being a de-facto standard, there is any RFC, Public Policy, or > something like that, that would define 0: as "no-export-to" > standard? > > 2 - What about reserving some 16-bits ASN to use : > as "export-only-to" standard? > 2.1 - Is important to be 16 bits, because with (RT) extended communities, > any ASN on the planet could be the target of that policy. > 2.2 - Would be interesting some mnemonic number like 1000 / 1 or so. > > -- > Douglas Fernando Fischer > Engº de Controle e Automação >
Re: Consolidation of Email Platforms Bad for Email?
On 08.09.20 16:59, Matt Harris wrote: The positive is that it a small club can establish ground rules for how they will handle various forms of attacks, including BGP hijacking, DKIM, SPF, and other forms of validation to identify fraudulent mail, etc. [...] They can also very quickly spot new attack trends. > In theory, but the current state of what's coming out of sendgrid > implies otherwise. It's not theory but history. They have spotted those sorts of trends quickly in the past (see below). They may not tell you they have spotted the trends. > Once you get into that small club, it's just as hard to get kicked > out, and unfortunately that means that if abuse, UCE, etc is coming > from those hosts, they've got an even higher chance of hitting your > inbox. This depends on the nature of the incident, but if their evil bit gets set and if their size is Size XL, then it is indeed hard to give them the boot. > So while in theory it might work the way you're thinking, in practice > it hasn't because once you are in that club, a lot of the financial > motivation to prevent abuse of your service - that is, inbox > deliverability for your client base - goes away. I disagree, but we aren't going to debate incentive models here. Suffice it to say that the big guys spending money on this, as they do, belies your point. A good example was one such very large provider tracking hijacked BGP announcements and then releasing that information to shut down a huge swathe of sources all at once. However... > That deliverability isn't likely to change for the negative on any > scale that you care about once you're "in". But to be "in" you have to > be at a huge scale. The small players are the ones who get hurt, and > spam still gets through just fine only now via different means. Yes. That was why I said that there is good and bad. Were we to take this to extremes, we see why FB can curate their messages and keep spam to a bear minimum, as they really do control the horizontal and the vertical (two sided market). > > Also oligopolies in general are bad for everyone except the owners > thereof and should be discouraged on principle. Not that I disagree (this comes to you by way of my dinky little VM), but that's not the topic at hand. Eliot OpenPGP_0x87B66B46D9D27A33_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
Most of us have already used some BGP community policy to no-export some routes to some where. On the majority of IXPs, and most of the Transit Providers, the very common community tell to route-servers and routers "Please do no-export these routes to that ASN" is: -> 0: So we could say that this is a de-facto standard. But the Policy equivalent to "Please, export these routes only to that ASN" is very varied on all the IXPs or Transit Providers. With that said, now comes some questions: 1 - Beyond being a de-facto standard, there is any RFC, Public Policy, or something like that, that would define 0: as "no-export-to" standard? 2 - What about reserving some 16-bits ASN to use : as "export-only-to" standard? 2.1 - Is important to be 16 bits, because with (RT) extended communities, any ASN on the planet could be the target of that policy. 2.2 - Would be interesting some mnemonic number like 1000 / 1 or so. -- Douglas Fernando Fischer Engº de Controle e Automação
Re: Consolidation of Email Platforms Bad for Email?
On 9/8/2020 10:59 AM, Matt Harris via NANOG wrote: Once you get into that small club, it's just as hard to get kicked out, and unfortunately that means that if abuse, UCE, etc is coming from those hosts, they've got an even higher chance of hitting your inbox. So while in theory it might work the way you're thinking, in practice it hasn't because once you are in that club, a lot of the financial motivation to prevent abuse of your service - that is, inbox deliverability for your client base - goes away. +1 Likewise, we're at a point now where if a criminal phish or virus comes from the largest few email hosters, and you provide them emails with full headers - the accounts do NOT get shut down. They literally don't think this is their problem. And likewise, data storage sites (GoogleDrive, OneDrive, etc) from the largest providers often will host malware for weeks or months without being shut down - or the malware at least persists for many days after being reported. The same is often true for their redirectors. Wwhat is frustrating is that the long-standing industry standard of "you're responsible both for what you both send and host - even if the malware wasn't intended" - seems to be lost. Likewise, back in the spring months of 2018, google's "goo[.]gl" shortner went crazy for a few months, and was being MASSIVELY abused by spammers, and was being used as an "end run around" URI DNSBLs (SURBL, URIBL, ivmURI, DBL). I collected 15K examples of abused shortners that were "live", and sent those to Google. At the time I sent those, only about 500 of that 15K had been shut down. What was infuriating was that 80% of these 15K shortners were pointing to only 12 spammer's domains. These should have been trivial to prevent! The OTHER infuriating thing was that my INITIAL response from my contacts at Google was - (I paraphrase) "other spam filters should just follow the redirect, and block these spams based on the URI it redirects to" - WOW! I sent them a very stern email about that. (and for comparison, abused Bitly shortners were mostly getting shut down within 2 hours - so "everyone does it" was NOT a decent excuse!) Like I said - the long-standing industry standard of "you're response both for what you both send and host - even if the malware wasn't intended" - seems to be lost on some of these large providers. Thankfully, this had a happy ending. After some "tough love" - Google replied back and said (I paraphrase), "we were planning on shutting that down - or at least shutting down the ability to add new ones - and due to your feedback - we're going to push that up a few months" - and so soon afterwards, they finally did terminate those 15K shortners - and stopped allowing new ones. So this is to Google's credit - but the problem had persisted for months - and it seemed like a lot of cultural/industry standards in the Internet Security industry seemed lost on them. Sadly, while this situation had a good ending - similar problems with the largest providers persist. At the same time, they sure can be draconian in how they block smaller providers who had a rare and short-lived security incident. The hypocrisy is incredible. For example, Microsoft will sometimes *permanently* block a small email hoster for a short one or two hour compromised email account situation that caused spam to be sent from that small hosters - but that was quickly fixed - even if that hoster sends MUCH legit email. It almost FEELS like extortion - since many of the IT people running those small-ish servers sometimes get frustrating - and move their email to the cloud - and then guess who OFTEN gets their email hosting business? -- Rob McEwen, invaluement
Re: Consolidation of Email Platforms Bad for Email?
In many ways I see this similarly to the consolidation of browsers, but less consolidated. I think about the advantages and disadvantages of the prominence of Chrome (65%), Safari (20%), Firefox/Samsung/Edge/Opera/etc (15%). With Chrome we’ve seen Google move the browser and related standards forward through sheer marketshare. CSS/HTML/JS standards live and die by Chrome support and that’s both good and bad. They have made great and opinionated strides when it comes to SSL/TLS. For example, Google effectively killed Symantec’s certificate business because it was mismanaged. They also effectively got rid of EV certs and pushed secure-by-default web server design where HTTPS appeared normal, but warnings all over the place for non-encrypted connections. On the other hand, Google is fairly disliked in the privacy community and those communities prefer independent Firefox. For email, I can see similar issues, mostly around security. If Microsoft were to decide security mechanism X is not worth the effort they can effectively decide to not implement it. What will internet users do, block all Microsoft email services? Conversely they could come up with their own security mechanisms and effectively force the rest of the world to adopt it. I do think centralization of email providers provides little potential for negative impact aside from operational issues. For example, outages probably have a wider impact due to number of users, but I can’t realistically see a scenario where Microsoft/Google does something “bad” with their email platform that affects the rest of the ecosystem. Caesar Kabalan From: NANOG Date: Tuesday, September 8, 2020 at 4:47 AM To: Mike Hammett , NANOG Subject: Re: Consolidation of Email Platforms Bad for Email? I'm sure Dave Crocker has thoughts about this, but it has come up elsewhere. There are both positives and negatives about having such a consolidation. The positive is that it a small club can establish ground rules for how they will handle various forms of attacks, including BGP hijacking, DKIM, SPF, and other forms of validation to identify fraudulent mail, etc. Also, if you have a whole lot of postfixes and sendmails running around, that's a whole lot of code to patch when things go wrong. A small number of MSPs can devote a lot of time and paid eyes on code. They can also very quickly spot new attack trends. On the other hand, that means that it becomes difficult to become a new entrant, because one doesn't easily get one's mail accepted. Lots of grey/blacklisting (forgive the use of the term). Also, when one of those systems fails, it takes down a vast number of customers. Furthermore, it represents a massive concentration of private information that can be monetized. Eliot On 08.09.20 00:27, Mike Hammett via NANOG wrote: I originally asked on mailops, but here is a much wider net and I suspect there's a lot of overlap in interest. I had read an article one time, somewhere about the ongoing consolidation of e-mail into a handful of providers was bad for the Internet as a whole. It was some time ago and thus, the details have escaped me, so I was looking to refresh my recollection. Have any of you read a similar article before? If so, can you link me to it? - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com [https://www.gore.com/sites/g/files/ypyipe116/files/2017-03/Gore_logo_0.png] This email may contain trade secrets or privileged, undisclosed or otherwise confidential information. If you have received this email in error, you are hereby notified that any review, copying or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.
Re: PTP/Syncronized Ethernet maturity
We have mobile NWs in both Asia and Europe and also experience a lot of issues with PTP, - almost with every vendor. The instabilities, SW-bugs etc. related to PTP seems to indicate that very little testing of this code has been done in production networks. In some deployments we have been able to produce a clock service by installing GNSS on the cell-site. However, in other countries there are regulatory directives that the phase sync must be PTP/Network based. Currently, the optical domain is causing us huge problems when we try to engineer a T-BC/PTP solution. This is due to the path asymmetry that exist in the WDM/fiber domain. In some networks we have a lot of DCF in the fiber path and the only way we can get visibility in the asymmetry on these fiber hops is to measure in both direction:( Also, running T-BC over WDM/OTN will simply not work as the phase error introduced more or less eats up the phase error budget for 4G/5G TDD-service. best regards, Geir > On 5 Sep 2020, at 00:17, Macho Pellegrini via NANOG wrote: > > Hello everybody, > > We have deployed PTP in our mobile NW since late 2019 as a part of the 4G/5G, > however we are seeing a lots of instabilities and interop issues, a lot of > the issues have ended up with SW bugs in the OS, I have no specific question, > however I got the impression that the technology/protocol is not yet mature, > anybody here got his hands dirty with PTP? > > Thanks, > MP
Re: Consolidation of Email Platforms Bad for Email?
Matt Harris|Infrastructure Lead Engineer 816-256-5446|Direct Looking for something? Helpdesk Portal|Email Support|Billing Portal We build and deliver end-to-end IT solutions. On Tue, Sep 8, 2020 at 6:43 AM Eliot Lear via NANOG wrote: > The positive is that it a small club can establish ground rules for how > they will handle various forms of attacks, including BGP hijacking, DKIM, > SPF, and other forms of validation to identify fraudulent mail, etc. [...] > They can also very quickly spot new attack trends. > In theory, but the current state of what's coming out of sendgrid implies otherwise. Once you get into that small club, it's just as hard to get kicked out, and unfortunately that means that if abuse, UCE, etc is coming from those hosts, they've got an even higher chance of hitting your inbox. So while in theory it might work the way you're thinking, in practice it hasn't because once you are in that club, a lot of the financial motivation to prevent abuse of your service - that is, inbox deliverability for your client base - goes away. That deliverability isn't likely to change for the negative on any scale that you care about once you're "in". But to be "in" you have to be at a huge scale. The small players are the ones who get hurt, and spam still gets through just fine only now via different means. Also oligopolies in general are bad for everyone except the owners thereof and should be discouraged on principle.
Re: Consolidation of Email Platforms Bad for Email?
I'm sure Dave Crocker has thoughts about this, but it has come up elsewhere. There are both positives and negatives about having such a consolidation. The positive is that it a small club can establish ground rules for how they will handle various forms of attacks, including BGP hijacking, DKIM, SPF, and other forms of validation to identify fraudulent mail, etc. Also, if you have a whole lot of postfixes and sendmails running around, that's a whole lot of code to patch when things go wrong. A small number of MSPs can devote a lot of time and paid eyes on code. They can also very quickly spot new attack trends. On the other hand, that means that it becomes difficult to become a new entrant, because one doesn't easily get one's mail accepted. Lots of grey/blacklisting (forgive the use of the term). Also, when one of those systems fails, it takes down a vast number of customers. Furthermore, it represents a *massive* concentration of private information that can be monetized. Eliot On 08.09.20 00:27, Mike Hammett via NANOG wrote: > I originally asked on mailops, but here is a much wider net and I > suspect there's a lot of overlap in interest. > > > I had read an article one time, somewhere about the ongoing > consolidation of e-mail into a handful of providers was bad for the > Internet as a whole. It was some time ago and thus, the details have > escaped me, so I was looking to refresh my recollection. > > Have any of you read a similar article before? If so, can you link me > to it? > > > > - > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > OpenPGP_0x87B66B46D9D27A33_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
