Re: Networks ignoring prepends?

[Jay Borkenhagen]

William Herrin writes:
 > 
 > The best path to me from Centurylink is: 3356 1299 20473 11875
 > 
 > The path Centurylink chose is: 3356 47787 47787 47787 47787 53356
 > 11875 11875 11875
 > 
 > Do you want to tell me again how that's a reasonable path selection,
 > or how I'm supposed to pass communities to either 20473 or 53356 which
 > tell 3356 to behave itself?
 > 

What you want to do is pass communities to 3356 so they apply the same
local-pref to routes from both paths, enabling as-path-length-based
path selection to work.  That means lowering their local-pref on the
currently-chosen customer path via 47787 to match the local-pref on
the their 1299 peer path.

as3356's TE communities are listed in their IRR aut-num: AS3356
object: 

remarks: 
remarks: customer traffic engineering communities - LocalPref
remarks: 
remarks:3356:70 - set local preference to 70
remarks:3356:80 - set local preference to 80
remarks:3356:90 - set local preference to 90
remarks: 

Those communities look like RFC1998.  Thus presumably 3356's peer
local-pref is 80, and you'll want to signal using 3356:80.  As you
make signaling changes you should use as3356's looking glass to
confirm.

as47787 and as53356 should pass your 3356:80 community along to
as3356.  If they don't do so, complain to them or vote with your
feet. 

Jay B.

Re: Changes to ARIN Online - Routing Security Dashboard - RPKI & IRR integration (was: Fwd: [arin-announce] New Features Added to ARIN Online)

[Jay Borkenhagen]

Job Snijders via NANOG writes:
 > >
 > > > Would it not be advantageous to create at a minimum the 256 of the
 > > > 'least-specific' objects?
 > > 
 > > MK: That may be a reasonable approach. Do you see any adverse effects
 > > in simplifying the IRR Route creation logic to just have
 > > least-specific?
 > 
 > I don't think I see a downside of mapping a single VRP to a single IRR
 > route/route6 object.
 > 

I agree that in ARIN's RPKI-->IRR synthesis, the set of route[6]
objects created should not depend on the maxlength used.  In Mark's
phrasing, "just have least-specific."

Ideally, discussion about details such as this should have occurred on
some ARIN technical mailing list in the months leading up to ARIN
deploying this change to production.

Thanks.

Jay B.

Re: AWS issues with 172.0.0.0/12

[Jay Borkenhagen]

I'm surprised that no one else has corrected this, so allow me to do
so for the record.

No, Mehmet's public IP was _not_ from the RFC 1918 172.16.0.0/16
range. 

One of the public ipv4 ranges that AT assigns subscriber addresses
from is 172.0.0.0/12: [ 172.0.0.0 - 172.15.255.255 ]

 https://whois.arin.net/rest/net/NET-172-0-0-0-1

One of the private ipv4 ranges set aside by RFC 1918 is the
neighboring 172.16.0.0/12: [ 172.16.0.0 - 172.31.255.255 ]

 https://whois.arin.net/rest/net/NET-172-16-0-0-1



We notice more mis-originations of our 172.0.0.0/12 space and its
more-specifics than any of our other ipv4 blocks, probably because
other folks are similarly confused.  So please, if you intend to use
RFC1918 space, please check your filters to make sure you're using
172.16.0.0/12 and not our 172.0.0.0/12.

Jay B.


Mehmet Akcin writes:
 > Yes
 > 
 > On Wed, Oct 9, 2019 at 20:46 Javier J  wrote:
 > 
 > > I'm just curious, was the ip in the RFC 1918 172.16.0.0/16 range?
 > >
 > > https://tools.ietf.org/html/rfc1918
 > >
 > >
 > >
 > > On Mon, Oct 7, 2019 at 6:01 PM Mehmet Akcin  wrote:
 > >
 > >> To close the loop here (in case if someone has this type of issue in the
 > >> future), I have spoken to AT instead of trying to work it out with AWS
 > >> Hosted Vendor, Reolink.
 > >>
 > >> AT Changed my public IP, and now I am no longer in that 172.x.x.x
 > >> block, everything is working fine.
 > >>
 > >> mehmet
 > >>
 > >> On Thu, Oct 3, 2019 at 2:54 PM Javier J 
 > >> wrote:
 > >>
 > >>> Auto generated VPC in AWS use RFC1819 addresses. This should not
 > >>> interfere with pub up space.
 > >>>
 > >>> What is the exact issue? If you can't ping something in AWS chances are
 > >>> it's a security group blocking you.
 > >>>
 > >>>
 > >>>
 > >>> On Tue, Oct 1, 2019, 7:00 PM Jim Popovitch via NANOG 
 > >>> wrote:
 > >>>
 >  On October 1, 2019 9:39:03 PM UTC, Matt Palmer 
 >  wrote:
 >  >On Tue, Oct 01, 2019 at 04:50:33AM -0400, Jim Popovitch via NANOG
 >  >wrote:
 >  >> On 10/1/2019 4:09 AM, Christopher Morrow wrote:
 >  >> > possible that this is various AWS customers making
 >  >iptables/firewall mistakes?
 >  >> >"block that pesky rfc1918 172/12 space!!"
 >  >>
 >  >> AWS also uses some 172/12 space on their internal network (e.g. the
 >  >network
 >  >> that sits between EC2 instances and the AWS external firewalls)
 >  >
 >  >Does AWS use 172.0.0.0/12 internally, or 172.16.0.0/12?  They're
 >  >different
 >  >things, after all.
 >  >
 > 
 >  I don't know their entire operations, but they do use some
 >  172.16.0.0/12
 >  addresses internally. And yes, that is very different than 172/12, sorry
 >  for the confusion.
 > 
 >  -Jim P.
 > 
 >  --
 > Mehmet
 > +1-424-298-1903

Re: AS4134/AS4847 - Appear to be hijacking some ip space.

[Jay Borkenhagen]

Hi Chris,

It would be great if the Google Fiber / AS16591 folks could publish a
ROA in ARIN's hosted RPKI authorizing exactly 136.32.0.0/11 to be
originated only in AS16591.  That ROA would have addressed this matter
from AS7018's point of view.

In the interim, I have added a temporary whitelist (slurm) entry into
our RPKI caches, causing the AS7018 network to disregard the
more-specific /24s under 136.32.0.0/11.

Good luck.
Jay B.


Christopher Morrow writes:
 > Howdy gentle folks:
 > 
 > It looks like AS4847 - "China Networks Inter-Exchange"
 > 
 > Is taking some time to announce reachability for at least:
 >   136.38.33.0/24
 > 
 > which they ought not, given that this /24 is part of a /11 assigned to
 > AS16591 (google fiber)... Looking at routeviews data, I see the
 > following as-paths for this one /24:
 > $ grep -A1 Refresh /tmp/x | grep 4847
 >   1239 174 4134 4847
 >   3549 3356 174 4134 4847
 >   701 174 4134 4847
 >   4901 6079 3257 4134 4847
 >   20912 174 4134 4847
 >   1221 4637 4134 4847
 >   1351 11164 4134 4847
 >   6079 1299 4134 4847
 >   6079 3257 4134 4847
 >   7018 4134 4847
 >   6939 1299 4134 4847
 >   3561 209 4134 4847
 >   3303 4134 4847
 >   3277 39710 9002 4134 4847
 >   2497 4134 4847
 >   4826 1299 4134 4847
 >   54728 20130 23352 2914 4134 4847
 >   19214 3257 4134 4847
 >   101 101 11164 4134 4847
 >   1403 6453 4134 4847
 >   852 6453 4134 4847
 >   1403 6453 4134 4847
 >   286 4134 4847
 >    1273 4134 4847
 >   57866 3491 4134 4847
 >   3267 1299 4134 4847
 >   49788 174 4134 4847
 >   53767 3257 4134 4847
 >   53364 3257 4134 4847
 >   8283 57866 3491 4134 4847
 >   7660 2516 4134 4847
 > 
 > >From that I think the following AS should have filtered this prefix and are 
 > >not:
 > $ grep -A1 Refresh /tmp/x | grep 4847 | sed 's/ 4134 4847//' | awk
 > '{print $NF}' | sort -n | uniq
 > 
 > 174  - Cogent
 > 209 - Qwest
 > 286 - KPN
 > 1273 - Vodafone
 > 1299 - Telia
 > 2497 - IIJ
 > 2516 - KDDI
 > 2914 - NTT
 > 3257 - GTT
 > 3303 - Swisscom
 > 3491 - PCCW
 > 4637 - Telstra
 > 6453 - TATA
 > 7018 - ATT
 > 9002 - RETN
 > 11164 - Internet2
 > 
 > It'd be great if the listed folk could filter AS4134 :)
 > 
 > -Chris

SOLVED (was Re: request for help: 192.139.135.0/24)

[Jay Borkenhagen]

Hi nanog,

With help from China Unicom (as4837) and from folks in other key
places around the 'net, I am happy to report that this route
mis-origination has now been successfully resolved.  Thanks, all!

I urge folks facing similar problems to publish RPKI ROAs for their IP
resources.  I started on this mission after I noticed a discrepancy
regarding the validation state of this prefix in the as7018 network.
Someday when more networks perform RPKI route origin validation more
broadly this kind of issue will be addressed automatically, but even
prior to that happening, the verifiable statements in RPKI ROAs can be
attributed to you as the actual resource holder, thus helping folks
base their response actions on your intent.

If you are not facing similar problems today, you could be tomorrow:
so publish your ROAs now!

Thanks.

Jay B.


Smith, Courtney writes:
 > Any luck reaching AS4837?  
 > 
 > route-views>show ip bgp 192.139.135.0/24 longer-prefixes
 > BGP table version is 103101215, local router ID is 128.223.51.103
 > Status codes: s suppressed, d damped, h history, * valid, > best, i - 
 > internal,
 >   r RIB-failure, S Stale, m multipath, b backup-path, f 
 > RT-Filter,
 >   x best-external, a additional-path, c RIB-compressed,
 > Origin codes: i - IGP, e - EGP, ? - incomplete
 > RPKI validation codes: V valid, I invalid, N Not found
 > 
 >  Network  Next HopMetric LocPrf Weight Path
 >  *   192.139.135.0208.51.134.254   0 0 3549 3356 
 > 4837 4808 i
 >  *194.85.40.15 0 0 3267 3356 
 > 4837 4808 i
 >  *193.0.0.56 0  1273 
 > 4837 4808 i
 >  *37.139.139.0   0 57866 6762 
 > 4837 4808 i
 >  *12.0.1.63  0 7018 1299 
 > 53292 63251 ?
 >  *140.192.8.16   0 54728 20130 
 > 6939 4837 4808 i
 >  *91.218.184.60  0 49788 1299 
 > 53292 63251 ?
 >  *203.181.248.1680 7660 2516 
 > 4837 4808 i
 >  *154.11.12.2120 0 852 4837 4808 
 > i
 >  *134.222.87.1   700 0 286 1299 
 > 53292 63251 ?
 >  *209.124.176.2230 101 101 3356 
 > 4837 4808 i
 >  *137.39.3.550 701 3356 4837 
 > 4808 i
 >  *94.142.247.3 0 0 8283 1299 
 > 53292 63251 ?
 >  *162.251.163.2  0 53767 3257 
 > 1299 53292 63251 ?
 >  *212.66.96.126  0 20912 1267 
 > 3356 4837 4808 i
 >  *198.58.198.255 0 1403 6461 
 > 4837 4808 i
 >  *198.58.198.254 0 1403 6461 
 > 4837 4808 i
 >  *>   202.232.0.20 2497 4837 
 > 4808 i
 >  *203.62.252.83  0 1221 4637 
 > 4837 4808 i
 >  *132.198.255.2530 1351 6939 
 > 4837 4808 i
 >  *206.24.210.80  0 3561 209 4837 
 > 4808 i
 >  *195.208.112.1610 3277 39710 
 > 9002 3356 4837 4808 i
 >  *217.192.89.50  0 3303 4837 
 > 4808 i
 >  *173.205.57.234 0 53364 3257 
 > 1299 53292 63251 ?
 >  *207.172.6.20 0 0 6079 3356 
 > 4837 4808 i
 >  *207.172.6.1  0 0 6079 3356 
 > 4837 4808 i
 >  *208.74.64.40   0 19214 174 
 > 3356 4837 4808 i
 >  *144.228.241.130240 0 1239 4837 
 > 4808 i
 >  *162.250.137.2540 4901 6079 
 > 3356 4837 4808 i
 >  *    114.31.199.1   0 4826 1299 
 > 53292 63251 i
 >  *64.71.137.241  0 6939 4837 
 > 4808 i
 > route-views> 
 > 
 > On 4/1/19, 1:30 PM, "NANOG on behalf of Jay Borkenhagen" 
 >  wrote:
 > 
 > [No attempts at 01-April humor will be attempted in this message.]
 > 
 > 
 > Seeking help from routing engineers around the 'net:
 > 
 > 
 > ARIN documents that 192.139.135.0/24 has

request for help: 192.139.135.0/24

[Jay Borkenhagen]

[No attempts at 01-April humor will be attempted in this message.]


Seeking help from routing engineers around the 'net:


ARIN documents that 192.139.135.0/24 has been allocated to Metro
Wireless International:

 https://whois.arin.net/rest/net/NET-192-139-135-0-1

Further, the party to whom 192.139.135.0/24 has been allocated has
published a ROA in ARIN's hosted RPKI asserting that bgp announcements
for that prefix are valid only when originating in AS63251.  To view
this, go to your favorite RPKI vantage point that uses ARIN's TAL.  If
you don't yet have a favorite, feel free to telnet to
route-server.ip.att.net and run:

 show validation database record 192.139.135.0/24 


Unfortunately, as may be seen at route-views, etc, most of the
Internet now prefers an invalid path that's mis-originated in as4808:


 Network  Next Hop  Path
 *   192.139.135.0208.51.134.2543549 3356 4837 4808 i
 *194.85.40.15  3267 3356 4837 4808 i
 *193.0.0.56 1273 4837 4808 i
 *37.139.139.0  57866 6762 4837 4808 i
 *12.0.1.63 7018 1299 53292 63251 ?
 *140.192.8.16  54728 20130 6939 4837 4808 i
 *91.218.184.60 49788 1299 53292 63251 ?
 *203.181.248.168   7660 2516 4837 4808 i
 *154.11.12.212 852 4837 4808 i
 *134.222.87.1  286 1299 53292 63251 ?
 *209.124.176.223   101 101 3356 4837 4808 i
 *137.39.3.55   701 4837 4808 i
 *94.142.247.3  8283 1239 4837 4808 i
 *162.251.163.2 53767 3257 1299 53292 63251 ?
 *212.66.96.126 20912 1267 3356 4837 4808 i
 *198.58.198.2551403 6461 4837 4808 i
 *198.58.198.2541403 6461 4837 4808 i
 *>   202.232.0.2   2497 4837 4808 i
 *203.62.252.83 1221 4637 4837 4808 i
 *132.198.255.253   1351 6939 4837 4808 i
 *206.24.210.80 3561 209 4837 4808 i
 *195.208.112.161   3277 39710 9002 3356 4837 4808 i
 *217.192.89.50 3303 4837 4808 i
 *173.205.57.23453364 3257 1299 53292 63251 ?
 *207.172.6.20  6079 3356 4837 4808 i
 *207.172.6.1   6079 3356 4837 4808 i
 *208.74.64.40  19214 174 4837 4837 4808 i
 *144.228.241.130   1239 4837 4808 i
 *162.250.137.254   4901 6079 3356 4837 4808 i
 *114.31.199.1  4826 1299 53292 63251 i
 *64.71.137.241 6939 4837 4808 i


Please help the Metro Wireless International folks get this cleared up
so their 192.139.135.0/24 can once again be usable.  In particular,
help is sought from 4837 and their transit providers:

 1239
 701
 3356

(Yes, I am trying to reach folks at those networks in other ways, too.)
 

Thanks.

Jay B.

Re: Analysing traffic in context of rejecting RPKI invalids using pmacct

[Jay Borkenhagen]

Sriram, Kotikalapudi (Fed) writes:
 > 
 > >When we (as7018) were preparing to begin dropping invalid routes
 > >received from peers earlier this year, that is exactly the kind of
 > >analysis we did.  In our case we rolled our own with a two-pass
 > >process: we first found all the traffic to/from invalid routes by a
 > >bgp community we gave them, then outside of our flow analysis tool we
 > >further filtered the traffic for invalid routes which were covered by
 > >less-specific not-invalid routes.  What remained was the traffic we
 > >would lose once invalid routes were dropped.  Had the pmacct
 > >capability existed at that time, we would have used it.
 > 
 > We (NIST) did a detailed analysis of Invalid routes (with Routeviews data)
 > that was presented at IETF 101:
 > [foo]
 > See slides 10-13. We tried to drill down on Invalid routes which were 
 > covered by
 > less-specific not-invalid routes. We examined questions like:
 > how often does the less-specific route have the same origin AS (OAS) as the 
 > Invalid,
 > and, if not, then how frequently is the OAS of the less specific route
 > a transit provider of the OAS of the Invalid route?
 > We plan to update the results periodically.

Sriram,

Please note that this thread is about "Analysing traffic", not
routes.  

Prior to dropping invalid routes, had we seen that we were exchanging
any significant amount of traffic with destinations covered only by
invalid routes, we would have tried to do something about it.  First
we would have attempted to contact the holder of the resources in
question.  If we were not able to resolve the issue that way, then we
would have at least considered deploying a temporary whitelist entry,
while continuing attempts to fix things the right way.

Fortunately it did not come to that.  The volume of the invalid-only
traffic we were carrying then was insignificant.

Of course, traffic volume is not the only thing one should consider
prior to dropping invalid routes, but it should be one piece of one's
due diligence.

Jay B.

Re: Analysing traffic in context of rejecting RPKI invalids using pmacct

[Jay Borkenhagen]

On 12-March-2019, Steve Meuse writes:
 > >
 > > ps. Dear Kentik & Deepfield, please copy+paste this feature! We'll
 > > happily share development notes with you, you can even look at pmacct's
 > > source code for inspiration. :-)
 > 
 > Thanks Job, I just wanted to reach back out to you and the NANOG community
 > that we've implemented this feature. Currently Kentik can match flow data
 > with the following validation state:
 > 
 > - VALID = Prefix fits in ROA, and ROA ASN and Prefix Origin Match
 > - UNKNOWN = we haven't found any matching ROA
 > - INVALID - ASN mismatch = BGP prefix fits in the ROA prefix's length BUT
 > the ROA ASN differs from the Prefix Origin ASN
 > - INVALID - Prefix length out of bounds = the BGP prefix doesn't have an
 > ROA with large enough Max-Length to refer to
 > - INVALID - ASN 0 specified = there is a matching ROA w/ the right
 > max-length but the ASN associated w/ it is 0 (explicit invalid)
 > 

Hi Steve,

Thanks for the update, but based on that description I'm not certain
that you implemented the same thing that pmacct built, which IMO is
what is needed by those considering deploying a drop-invalids policy.
(Perhaps you omitted mentioning that ability in your description but
included it in your implementation.)

Citing from Job's description:

 > Pmacct implemented Origin Validation in a cute way: it separates out
 > RPKI invalid BGP announcements into two categories:
 > 
 > a) "invalid with no overlapping or alternative route"
 > (aka will be blackholed if 'invalid == reject')
 > 
 > b) "invalid but an overlapping unknown/valid announcement also
 > exists"
 > (end-to-end connectivity can still work).
 > 

Networks contemplating Origin Validation need to be able to predict
how their traffic with the rest of the Internet would change after
deploying a drop-invalid-routes policy.

When we (as7018) were preparing to begin dropping invalid routes
received from peers earlier this year, that is exactly the kind of
analysis we did.  In our case we rolled our own with a two-pass
process: we first found all the traffic to/from invalid routes by a
bgp community we gave them, then outside of our flow analysis tool we
further filtered the traffic for invalid routes which were covered by
less-specific not-invalid routes.  What remained was the traffic we
would lose once invalid routes were dropped.  Had the pmacct
capability existed at that time, we would have used it.


Regarding the ability to further partition invalid traffic into the
three sub-categories you mentioned: that would not have been of
interest to us at the time we did our analysis, and it's not clear to
me how it would be useful to a network as it contemplates adopting a
drop-invalids policy.  In this context, the reason a route is invalid
is not important; what is important is whether it is covered by a
non-invalid route or not.

Thanks.

Jay B.

Re: AT/as7018 now drops invalid prefixes from peers

[Jay Borkenhagen]

 > Congrats Jay, this is awesome news!

Thanks, Alex!

 > I’m interested to hear what is preventing you from creating ROAs for all of 
 > your announcements. 
 > 
 > > We will publish more ROAs over time.  Thusfar we have been utilizing
 > > ARIN's hosted model, but down the road ARIN's delegated model will be
 > > in our future.
 > > 
 > What are your main drivers for wanting to move to the delegated model?

We can publish ROAs immediately for aggregate address blocks that we
have been allocated if all routes are originated only by our network.
But for our address allocations within which we have further assigned
sub-blocks to our customers as PA space where we allow multihoming
(e.g. within 12.0.0.0/8), we need to offer our downstream customers
the ability to publish ROAs for their specific portions first before
we publish a ROA for the aggregate, or else we'll make their
announcements become invalid.

Setting up that ability for our customers to publish ROAs for the PA
space they receive from us will require tight integration with our
customer software support systems, and perhaps also with our own
certificate authority -- thus the delegated model.

BTW: Alex, do you know where one might be able to get RPKI CA
software? :-)

Thanks.

Jay B.

Re: AT/as7018 now drops invalid prefixes from peers

[Jay Borkenhagen]

Job Snijders writes:
 > Dear Jay, AT,
 > 
 > On Mon, Feb 11, 2019 at 09:53:45AM -0500, Jay Borkenhagen wrote:
 > > The AT/as7018 network is now dropping all RPKI-invalid route
 > > announcements that we receive from our peers.
 > 
 > Thanks for filtering us! :-)

Any time! :-)

 > If you can share more about the experience in terms of load on the
 > support tiers in your organisation, or questions from peering partners,
 > that could perhaps be helpful information for others in their
 > preparations.
 > 

A few reports of resulting connectivity loss have come in through
various channels: on Jared's outages mailing list, on IRC, through our
customer care ticket system, etc.  

Thusfar I have been very pleased with the reactions folks have had
when we described how our policy change caused us to lose their
affected route announcement.  Everyone so far has understood the
purpose of the RPKI, they understood why the affected route
announcements were deemed invalid and thus were dropped, and best of
all -- they understood what they needed to do to fix things.

We got some very good advice watching this video from your most recent
NLNOG day:

 https://www.youtube.com/watch?v=vrzl__yGqLE

... but there is one place where I disagree with Niels.  He advised
against lowering the local-pref of invalid routes.  I agree that this
should not be anyone's target policy, but it is a useful step along
the way.  To set invalid routes a lower local-pref, one needs to
establish RTR sessions from routers to relying party servers, and to
configure a policy that takes validation state into account.  The
policy here can also set community based on the validation state,
which can help with flow-based traffic analysis.  Then, when you are
comfortable operating RPs that talk RTR to your routers and you're
ready to implement a meaningful policy, it's a simple matter of
changing from:

 if validation-state = invalid
 then
   local-pref = $LOWER
   community = foo
 fi

 to:

 if validation-state = invalid
 then
   drop
 fi



In short: C'mon in!  The water's fine! :-)


Thanks.

Jay B.

Re: AT/as7018 now drops invalid prefixes from peers

[Jay Borkenhagen]

valdis.kletni...@vt.edu writes:
 > On Mon, 11 Feb 2019 09:53:45 -0500, Jay Borkenhagen said:
 > > The AT/as7018 network is now dropping all RPKI-invalid route
 > > announcements that we receive from our peers.  
 > 
 > Congrats!

Thanks!

 > Are you able to comment on what amount of routes are getting dropped?

In round numbers, we dropped about 5000 invalid prefixes total between
ipv4 and ipv6.  Roughly half of those prefixes were covered by
less-specific non-invalid routes, so connectivity should not have been
affected for those prefixes (assuming an announcement yields
reachability to all destinations within it).  Flow analysis was
showing just a couple Gbps of traffic to all invalid routes all across
the country, and much less than that with those invalids having no
covering less-specifics.

Jay B.

Re: AT/as7018 now drops invalid prefixes from peers

[Jay Borkenhagen]

Compton, Rich A writes:
 > That's great!  Do you guys have plans to publish ROAs for your own 
 > netblocks?  If so, can you please share info on your process (tools, 
 > pitfalls, etc.)?  Thanks!
 > 

Hi Rich,

We do have ROAs published for a not insignificant fraction of our
address space.  For example (and cherry-picking the representation
most favorable to us) we're listed at #6 in the "25 Autonomous Systems
with the most Address Space VALID by RPKI" at this NIST RPKI tracker:

 https://rpki-monitor.antd.nist.gov/#rpki_adopters

We will publish more ROAs over time.  Thusfar we have been utilizing
ARIN's hosted model, but down the road ARIN's delegated model will be
in our future.

 https://www.arin.net/resources/rpki/using_rpki.html

Thanks.

Jay B.

AT/as7018 now drops invalid prefixes from peers

[Jay Borkenhagen]

FYI:

The AT/as7018 network is now dropping all RPKI-invalid route
announcements that we receive from our peers.  

We continue to accept invalid route announcements from our customers,
at least for now.  We are communicating with our customers whose
invalid announcements we are propagating, informing them that these
routes will be accepted by fewer and fewer networks over time.

Thanks to those of you who are publishing ROAs in the RPKI.  We would
also like to encourage other networks to join us in taking this step
to improve the quality of routing information in the Internet.

Thanks!

Jay B.

Re: Bogon ASN Filter Policy

[Jay Borkenhagen]

AT/as7018 is also now in the process of updating its as-path bogon
filters to match those cited below.  We have long employed such
filters, and our changes at this time are primarily to extend them to
prohibit as23456 and the reserved blocks > as65535.

So to Job and Adam and anyone else who deploys such filters: Thanks!
I would like to extend to you this laurel, and hearty handshake...


On 02-June-2016, Adam Davenport writes:
 > I personally applaud this effort as initiatives like this that help 
 > prevent the global propagation of Bogons and other "bad things" only 
 > serves to help us all.  With that said, notice went out to potentially 
 > affected GTT / AS3257 customers this week that by the end of June we too 
 > will be filtering prefixes that contain any of the Bogon ASNs listed 
 > below in the in the as-path.  I highly encourage other networks to 
 > follow suit, as again it only helps us all.
 > 
 > Thanks Job for kicking this one off, and I look forward to others to 
 > doing the same!
 > 
 > Adam Davenport / adam.davenp...@gtt.net
 > 
 >   
 > 
 > On 6/2/16 3:41 PM, Job Snijders wrote:
 > > Dear fellow network operators,
 > >
 > > In July 2016, NTT Communications' Global IP Network AS2914 will deploy a
 > > new routing policy to block Bogon ASNs from its view of the default-free
 > > zone. This notification is provided as a courtesy to the network
 > > community at large.
 > >
 > > After the Bogon ASN filter policy has been deployed, AS 2914 will not
 > > accept route announcements from any eBGP neighbor which contains a Bogon
 > > ASN anywhere in the AS_PATH or its atomic aggregate attribute.
 > >
 > > The reasoning behind this policy is twofold:
 > >
 > >  - Private or Reserved ASNs have no place in the public DFZ. Barring
 > >these from the DFZ helps improve accountability and dampen
 > >accidental exposure of internal routing artifacts.
 > >
 > >  - All AS2914 devices support 4-byte ASNs. Any occurrence of "23456"
 > >in the DFZ is a either a misconfiguration or software issue.
 > >
 > > We are undertaking this effort to improve the quality of routing data as
 > > part of the global ecosystem. This should improve the security posture
 > > and provide additional certainty [1] to those undertaking network
 > > troubleshooting.
 > >
 > > Bogon ASNs are currently defined as following:
 > >
 > >  0   # Reserved RFC7607
 > >  23456   # AS_TRANS RFC6793
 > >  64496-64511 # Reserved for use in docs and code RFC5398
 > >  64512-65534 # Reserved for Private Use RFC6996
 > >  65535   # Reserved RFC7300
 > >  65536-65551 # Reserved for use in docs and code RFC5398
 > >  65552-131071# Reserved
 > >  42-4294967294   # Reserved for Private Use RFC6996
 > >  4294967295  # Reserved RFC7300
 > >
 > > A current overview of what are considered Bogon ASNs is maintained at
 > > NTT's Routing Policies page [2]. The IANA Autonomous System Number
 > > Registry [3] is closely tracked and the NTT Bogon ASN definitions are
 > > updated accordingly.
 > >
 > > We encourage network operators to consider deploying similar policies.
 > > Configuration examples for various platforms can be found here [4].
 > >
 > > NTT staff is monitoring current occurrences of Bogon ASNs in the routing
 > > system and reaching out to impacted parties on a weekly basis.
 > >
 > > Kind regards,
 > >
 > > Job
 > >
 > > Contact persons:
 > >
 > >  Job Snijders , Jared Mauch ,
 > >  NTT Communications NOC 
 > >
 > > References:
 > > [1]: https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00
 > > [2]: http://www.us.ntt.net/support/policy/routing.cfm#bogon
 > > [3]: https://www.iana.org/assignments/as-numbers/as-numbers.xhtml
 > > [4]: http://as2914.net/bogon_asns/configuration_examples.txt

Re: www.att.net ipv6 traceroute

[Jay Borkenhagen]

David Hill writes:
  Anyone else noticing odd ipv6 traceroutes to www.att.net
  (2001:1890:1c01:2::40)?
  

David,

We see what's going on.  It currently affects only a portion of the v6
Internet.  Working on a fix...

Jay B.

where are all the IPv6 tools?

[Jay Borkenhagen]

Hi,

I depend on a number of shell tools for manipulating IPv4 addresses,
CIDR blocks, etc. like:

 aggis
 ipsort.pl
 grepcidr
 aggregate

I have not yet found much in terms of similar shell utilities for
IPv6.  I've spoken to authors of some of these tools and they admit
they have not yet produced IPv6-capable versions.  (Not trying to name
and shame: those tools are great, I just want more!)

Do folks here know of IPv6 tools that might provide some of the
functions the above tools provide for IPv4?

Thanks!

   Jay B.