NTAC Peering Working Group

[Ryan Harden <>]

All,

After typing a response with anecdotes and hypotheticals then deleting it two 
times, I’ll just add that, I’m firmly in the camp of, "thou shall not 
announce a prefix to a destination thou cannot guarantee delivery to.” A 
router can only match the longest prefixes it knows about and has no 
mechanism to consider prefix lengths it hasn’t received. So when a router 
receives only the aggregate, that is the “only valid route” for it to chose 
from, regardless of the intent of the originator of that prefix and/or a 
longer prefix announced elsewhere.

Let’s not forget that BGP exchanges NLRI or "Network Layer Reachability 
Information”. If you’re announcing a prefix via BGP, you are asserting that 
you, by definition, have _reachability_ to the destination.

Rule #1: Only announce prefixes you can reliable deliver service to.
Rule #2: Know the consequences of announcing a more specific to a subset of 
your peers.
Rule #3: The world only knows _what_ you announced, not _why_. It’s on you to 
announce in a way to ensures reachability to your services.

In the case of Apple/TR-CPS, they should be pressured to either only announce 
the prefixes they can provide reachability to, or ensure reachability via an 
aggregate. Seriously, in what world does Apple think it’s a good idea to 
announce an aggregate into TR-CPS that blackholes the longer prefixes of that 
aggregate that aren’t in that local data center? They could easily fix this 
by only announcing the longer prefixes that are reachable via that peering. 
We shouldn’t have to reverse-engineer their routing decisions to ensure we 
can reach their destinations.

In the case of DDoS scrubbing services, this is essentially sanctioned BGP 
hijacking by a third party. If you subscribe to and employ their services, 
you should be aware of and understand the consequences of doing so, good and 
bad.

/Ryan

Ryan Harden
Research and Advanced Networking Architect
University of Chicago - ASN160
P: 773.834.5441




> On Apr 20, 2017, at 2:57 PM, Steven Wallace 
> <>
>  wrote:
> 
> Here’s a draft of something that might provide some context/answers:
> 
> 
> There’s a network reachability problem (i.e., certain sites can’t be 
> reached despite an apparent valid network path) that may also cause 
> problems for users of DDoS cloud-based scrubbing services. The underlying 
> cause is how IP packets are routed, and how the routing information is 
> distributed.
> 
> Internet routers receive routing information from other routers and their 
> local configuration.  The routing information is compiled into a table, 
> known as the routing table, or more formally the routing information base 
> (RIB). Understanding this next part is important, as it’s the core of the 
> problem. The router looks for the longest prefix match to find the valid 
> route for a packet. Suppose the router has to route a packet to 129.79.1.4. 
> A routing table might contain two routes that match this destination: 
> 129.79.0.0/16 (e.g., matches everything that starts with “129.79”) and 
> 129.79.1.0/24 (e.g., matches everything starting with “129.79.1.”) Both of 
> these routes match 129.79.1.4, however only the “longest match” is valid.
> 
> When a network is multihomed (is peering with two or more upstream 
> providers), it should receive routing information from all of its peers. 
> Unfortunately existing router equipment may not have the memory to 
> accommodate a complete routing table. In such cases, a network may decide 
> to receive routing information from a subset of their peers, and send 
> packets for which there is no match to their Internet transit provider.
> 
> If a network isn’t able to accept all routes from its peers, the following 
> can cause network reachability problems. If a peer is sending the route for 
> 129.79.0.0/16, then you’d think a packet addressed to 129.79.1.4 would 
> match that route. However, if another peer had the route for 129.79.1.0/24, 
> but your router wasn’t accepting that peer’s routes, the ONLY VALID ROUTE 
> for 129.79.1.4 would be ignored, and the packet would be sent along the 
> wrong path.
> 
> Sometimes packets sent along the wrong path will still arrive at their 
> destination, however sometimes they won’t.
> 
>> On Apr 20, 2017, at 3:54 PM, Pete Siemsen 
>> <>
>>  wrote:
>> 
>> Ok, I forwarded these notes to some colleagues, and got back "Please 
>> explain item 6 in more detail. Why does traffic get "blackholed by TR-CPS 
>> or its peer," and why are connectors with full routes immune to this 
>> issue?.
>> 
>> I had to admit that I'd zoned out during actual call, attempting to do two 
>> things at once, and learning once again that I can't :-)
>> 
>> Anyone care to enlighten me, please?
>> 
>> 
>> 
>> -- Pete
>> 
>> 
>> On Wed, Apr 19, 2017 at 9:02 AM, Matt Mullins 
>> <>
>>  wrote:
>> Here are the notes from yesterday’s meeting. Please feel free to correct 
>> any mistakes I have made.
>> 
>> 
>> 
>> 1. Agenda Bash
>> 
>> 2. Update on peering and TR-CPS/I2
>> 
>> ·         Move Charter from 1GE to 10GE in Ashburn/Chicago/Dallas. Seattle 
>> to move to public exchange.
>> 
>> ·         Capacity updates for Amazon for TR-CPS in Ashburn/Chicago for 
>> Amazon.
>> 
>> 
>> 
>> 3. Network Weather Update
>> 
>> §  Nothing to update.
>> 
>> 
>> 
>> 4. RPKI Update
>> 
>> ·         Not much progress to report.
>> 
>> ·         Will be a BoF at Global Summit.
>> 
>> 
>> 
>> 5. Network DDoS Scrubbing Service Update
>> 
>> ·         Close to signing contracts with Zenedge.
>> 
>> ·         Pilots starting early-mid May.
>> 
>> ·         Will be a Bof at Global Summit.
>> 
>> 
>> 
>> 6. How to deal with the lack of a full routing table on TR-CPS (was: lack 
>> of transit on TR-CPS)
>> 
>> ·         Issue Occurrence
>> 
>> o    only an issue with connectors/members that receive only a default 
>> route from their transit provided and more specifics from I2/TR-CPS
>> 
>> o    some times traffic gets blackholed  by TR-CPS or its peer
>> 
>> o    other times the peer will use their transit to deliver the traffic
>> 
>> ·         Possible solutions:
>> 
>> o    members/connectors get full table from their provider.
>> 
>> §  Concern with requiring members/connectors having hardware needed for 
>> full table.
>> 
>> o    TR-CPS gets full routes from a transit provider. Don't advertise 
>> table to customers or advertise customer routes to provider.
>> 
>> §   Internet2 is in talks with Level(3) on increasing capacity to 10GE 
>> ports at Los Angeles/Chicago/Washington.
>> 
>> o    KanREN willing to provide full routes to TR-CPS as long as use is of 
>> limited occurrence and issues addressed with the I2 member. Possible issue 
>> is KanREN provider having filters in place which might drop the traffic 
>> from prefixes other than KanREN's. Brad to check with his Executive on 
>> that possibility and verify with KanREN's upstreams that prefixes are not 
>> being filtered.
>> 
>> §  Brad to hear back from Charter on ACL removal. All other KanREN transit 
>> providers will have no issue.
>> 
>> §  Could be setup quickly and used to get data for how common the issue is.
>> 
>> §  If KanREN is unable to provide, Dave Farmer can ask Big 10 Academic 
>> Alliance.
>> 
>> ·         Concern with making sure the DDoS scrubbing service is taken 
>> into consideration.
>> 
>> o    Steve Wallace to write up a proposal.
>> 
>> 7. AOB
>> 
>> 
>> 
>> 
>

Attachment: signature.asc
Description: Message signed with OpenPGP