[GTER] Solicitação de Comentários à Comunidade Técnica da Internet - Programa por uma Internet Segura

[Job Snijders]

On Mon, May 07, 2018 at 06:58:12PM -0300, Rubens Kuhl wrote:
> 2018-05-07 16:54 GMT-03:00 Job Snijders <job at ntt.net>:
> > A BGP speaker which is capable of AS4, should never see AS 23456 in
> > the AS_PATH. Any occurance of AS 23456 visible on a 4-byte ASN
> > capable router is either a misconfiguration, or a software defect.
> > We should not reward misconfigurations by accepting these
> > announcements.
> 
> Imagine the following scenario:
> IX RS - AS4 enabled participant - not-AS4 capable downstream - AS4 capable participant
> 
> The AS Path on the IX RS could look like this, if all of them were AS4
> capable:
> 
>  65000 - 65001 - 65536
> 
> But, since 65001 is not AS4 capable, it will send this path upwards:
> 
> 65000 - 65001 - 23456
> 
> Note that IX RS is AS4 capable, and the IX member (65000) is also AS4
> capable. But, 65000 has a customer that it's not, and they in turn
> have a customer that is an ASN greater than 65535.
> 
> So, this scenario requires no misconfigurations, and still present
> AS_TRANS (23456) in the path.

No, still in that scenario 23456 is not visible on the route server from
a policy perspective, because in that scenario the AS4_PATH attribute is
used to tunnel through the non-AS4-capable ASN and 65536 will be the
visible ASN on the route server.

The AS4/non-AS4 transition mechanism is quite amazing: https://tools.ietf.org/html/rfc6793

> > > Ação 4: Talvez incluir as grandes Web-Scale na mesma lista, como o
> > > Google, Netflix, Facebook, Akamai ?
> >
> > Route server operators should only include such companies in this
> > filter with their explicit permission.
> 
> Why would that differ from Tier-1 operators ? I could see a point for
> doing the same for the same Tier-1 operators, but not for treating
> them differently.

    [side-note: I prefer to use the term 'transit-free' instead of
    'tier-1', because the term 'transit-free' is something we can verify
    to a degree, while 'tier-1' has no well-defined meaning.]

All the "Big Content" providers you mention, have some form of a
distributed CDN approach where they connect independent clusters (as
islands) to the Internet and use the Internet for feeding/filling and
serving cached data. In other words, parts of their ASN are not
transit-free. This is a fundamental difference compared to the
transit-free networks as proposed in the IX.br document, who are
expected to operate as a coherent backbone.

I just want to make sure that the filter, _as proposed_, has a lot of
value too. This type of filter is documented in various places, such as
http://bgpfilterguide.nlnog.net/guides/no_transit_leaks/ Broadening that
filter without the ASN owner's consent might be trickier.

If the community decides that transit-free/transit-using networks should
all be treated the same, and that those networks can simply email IX.br
"never allow announcements that have our ASN anywhere in the AS_PATH on
your route servers", that is fine by me too. I'm supportive on an
approach opt-in approach, and an approach that is open to everyone that
wants to use it. I'm also supportive of the proposed list as-is.

Kind regards,

Job