Re: Reaching out to ARIN members about their RPKI INVALID prefixes

[Christopher Morrow]

On Tue, Sep 18, 2018 at 6:22 PM Owen DeLong  wrote:

>
>
> > On Sep 18, 2018, at 15:07 , Job Snijders  wrote:
> >
> > On Tue, Sep 18, 2018 at 02:44:30PM -0700, Owen DeLong wrote:
> >> ROAs are useful for one hop level validation. At the second AS hop
> >> they are 100% useless.
> >
> > This conversation cannot be had without acknowledging there are multiple
> > layers of defense in securing BGP. We should also acknowledge that the
> > majority of Internet traffic passes over AS_PATHs that are only one hop.
> > Networks that exchange significant amounts of traffic, tend to peer
> > directly with each other.
>
> Actually, I don’t buy that at all.
>
> Without going into too much detail, I know of at least one former employer
> who is quite
> well peered, distributes a great deal of traffic and sends a tremendous
> amount of it
> via multiple ASNs.
>
>
an IP resource holder can sign multiple ROA for a single prefix, it's
perfectly valid to have:
  157.130.0.0/16 AS112
  157.130.0.0/16 AS113
  157.130.0.0/16 AS701

So 'peered well via multiple ASN isn't really a problem here'. Are you
making an argument of the form: "1% of the problems are not solved so this
solution can't possibly work" ?

Using ROA from the RPKI system tied through/to the IRR data and applied as
filters on the bgp sessions of a network should provide that ASN with more
assurance that they will not accept and propagate a route hijack or
mistake. Adding in validation is nice as well, and may allow you to be a
little less diligent about route filtering... I think more than 1
protection is a good plan though (OV + filters seems sane to me, especially
in a world where you can automate that whole lot)

 >

> >>> In other words, RPKI and the Prefix-to-AS validation procedure give
> >>> us much more definitive inputs for routing policies compared to what
> >>> can be derived from the IRR.
> >>
> >> Please explain to me how you distinguish good from bad in the
> >> following scenario… You peer with AS6939. You receive routes for
> >> 2001:db8:f300::/48 with the following AS Paths
> >>
> >>  1. 6939 1239 54049 2312 1734
> >>  2. 6939 44046 12049 174 1734
> >>
> >> Which one is valid? Which one is not? How did the ROA tell you this?
> >
> > Both path 1 and 2 are invalid, because of peerlock we'd never accept
> > 1239 behind 6939, or 174 behind 6939. AS_PATH filtering combined with
> > Origin Validation is where the magic is.
>
> OK, poor examples crafted at random. Point is there are plenty of valid AS
> Paths
> out there that you can’t actually validate.
>

I think Job's point is that there really are note that many... perhaps
that's an NTT particular view? I know that my production network's view is
similar in 'shorter as  paths'. I expect that in large-isp-land it's more
prevalent than not.



> >>> RPKI is useful in context of a defense in depth strategy. If one
> >>> combines "peerlock" AS_PATH filters with origin validation the end
> >>> result is bullet proof. Even if NTT is the only one to deploy this
> >>> combination, the benefits are notable.
> >>
> >> Indeed, if peerlock gets wider deployment, it might prove useful. But
> >> unless I’m really misunderstanding peerlock, I don’t see that RPKI
> >> brings much else to the table in addition.
> >
> > Wide deployment is not relevant, this is a unilateral defense mechanism,
> > so I fear there may indeed be a degree of misunderstanding.
>
> Point being that there are very very few ASNs using peer lock. Peer lock
> alone AIUI pretty well covers the issue. RPKI provides very little (if any)
> verification.
>
>
I suppose if you are happy just doing peer lock on/for your network and
customers then cool!
The RPKI system isn't being forced on you. It seems like a helpful addition
to me, but that may not be your outlook.

-chris

RE: Console Servers

[Erik Sundberg]

Perle IOLAN SCS series is great. We have them all over the United States.



From: NANOG  On Behalf Of Jun Tanaka
Sent: Tuesday, September 18, 2018 10:52 AM
To: nanog@nanog.org; Alan Hannan ; NANOG 
Subject: Re: Console Servers

How about SMART CS series by Seiko solutions?
https://www.seiko-sol.co.jp/en/products/console-server/
--
Jun Tanaka - NetComBB/S.N.I



CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or 
previous e-mail messages attached to it may contain confidential information 
that is legally privileged. If you are not the intended recipient, or a person 
responsible for delivering it to the intended recipient, you are hereby 
notified that any disclosure, copying, distribution or use of any of the 
information contained in or attached to this transmission is STRICTLY 
PROHIBITED. If you have received this transmission in error please notify the 
sender immediately by replying to this e-mail. You must destroy the original 
transmission and its attachments without reading or saving in any manner. Thank 
you.

Re: Reaching out to ARIN members about their RPKI INVALID prefixes

[Owen DeLong]

> On Sep 18, 2018, at 15:07 , Job Snijders  wrote:
> 
> On Tue, Sep 18, 2018 at 02:44:30PM -0700, Owen DeLong wrote:
>> ROAs are useful for one hop level validation. At the second AS hop
>> they are 100% useless.
> 
> This conversation cannot be had without acknowledging there are multiple
> layers of defense in securing BGP. We should also acknowledge that the
> majority of Internet traffic passes over AS_PATHs that are only one hop.
> Networks that exchange significant amounts of traffic, tend to peer
> directly with each other.

Actually, I don’t buy that at all.

Without going into too much detail, I know of at least one former employer who 
is quite
well peered, distributes a great deal of traffic and sends a tremendous amount 
of it
via multiple ASNs.

> 
>>> In other words, RPKI and the Prefix-to-AS validation procedure give
>>> us much more definitive inputs for routing policies compared to what
>>> can be derived from the IRR.
>> 
>> Please explain to me how you distinguish good from bad in the
>> following scenario… You peer with AS6939. You receive routes for
>> 2001:db8:f300::/48 with the following AS Paths
>> 
>>  1. 6939 1239 54049 2312 1734
>>  2. 6939 44046 12049 174 1734
>> 
>> Which one is valid? Which one is not? How did the ROA tell you this?
> 
> Both path 1 and 2 are invalid, because of peerlock we'd never accept
> 1239 behind 6939, or 174 behind 6939. AS_PATH filtering combined with
> Origin Validation is where the magic is.

OK, poor examples crafted at random. Point is there are plenty of valid AS Paths
out there that you can’t actually validate.

>>> RPKI is useful in context of a defense in depth strategy. If one
>>> combines "peerlock" AS_PATH filters with origin validation the end
>>> result is bullet proof. Even if NTT is the only one to deploy this
>>> combination, the benefits are notable.
>> 
>> Indeed, if peerlock gets wider deployment, it might prove useful. But
>> unless I’m really misunderstanding peerlock, I don’t see that RPKI
>> brings much else to the table in addition.
> 
> Wide deployment is not relevant, this is a unilateral defense mechanism,
> so I fear there may indeed be a degree of misunderstanding.

Point being that there are very very few ASNs using peer lock. Peer lock
alone AIUI pretty well covers the issue. RPKI provides very little (if any)
verification.

Owen

Re: Reaching out to ARIN members about their RPKI INVALID prefixes

[Owen DeLong]

> On Sep 18, 2018, at 14:58 , Job Snijders  wrote:
> 
> On Tue, Sep 18, 2018 at 02:35:44PM -0700, Owen DeLong wrote:
>>> "rir says owen can originate route FOO"
>>> "ROA for 157.130.1.0/24 says OWEN can originate"
>> 
>> Nope… ROA says (e.g.) AS1734 (or anyone willing to impersonate AS1734)
>> can originate 192.159.10.0/24.
> 
> I'd phrase slightly different (assuming there is only one ROA): the ROA
> says ONLY AS1734 (or anyone willing to impersonate AS1734) can originate
> 192.159.10.0/24.
> 
> With IRR, the crucial addition of the word "ONLY" in the above sentence
> is not possible.

That depends. If you ONLY allow the maintainer of NET-192.159.10.0/24 to
update the route objects for it, then the word ONLY is effectively present by
the lack of any other route objects.

> 
>>> those seem like valuable pieces of information. Especially since I
>>> can know this through some machine parseable fashion.
>> 
>> I would agree if you had some way to distinguish AS1734 originating
>> FOO from AS174 originating FOO with a prepend of AS1734.
> 
> In the common scenario you can distinguish those with today's
> technology. As mentioned before - dense peering (having the shortest
> AS_PATH) or the peerlock approach for all *practical* intents solve the
> issue of path validation. You can try spoofing AS 7018 - you'll notice
> that your announcements won't make it into NTT. Having just that
> validated path (which is only one hop) is a very strong defense
> mechanism.

You chopped out my example, which had equal AS Path lengths.

Sure, I might not be able to announce something to you for an AS that you’re 
directly
peered with, but I can still spoof pretty much anything that’s more than one 
hop away
as long as I can get one of your peers to pass it along.

> Let's take another example: Google offers access to one of the world's
> largest DNS resolver services, Cloudflare hosts lots of authoritative
> DNS. According to PeeringDB they have quite some locations in common
> with each other so let's assume they directly peer with each other. If
> both sides create ROAs for their prefixes, and ROAs for the prefixes
> that host the auth side, and both sides perform RPKI Origin Validation;
> an attacker cannot inject itself between the two. 

Again, you’re reducing the problem set to single hop which I admit RPKI solves
(though I’d argue that if someone has access to insert themselves between
the two physically, RPKI does little to help)

> One can argue "this only helped google and cloudflare" - but on the
> other hand anno 2018 the Internet experience for the average end user is
> composed from services hosted by a relatively small number of providers.
> Preventing disruptions of communication between just those few players
> has significant implications for all of us.

So RPKI is great if we can just reduce the internet diameter to 1, in which
case MD5 passwords on your BGP sessions pretty much accomplishes the
same thing with a lot less kerfuffle.

Owen

Re: Piter-IX and GOOGLE (AS15169)

[Christopher Morrow]

On Tue, Sep 18, 2018 at 3:34 PM A.T  wrote:

> Hello,
>
> I see AS15169 announcements from Piter-IX
> (https://www.peeringdb.com/ix/2149), but Google PeeringDB entry don't seem
> include Piter-IX.
> Any idea, is PeeringDB out of date here or should I be worried?
>
>
sorry, looks like peeringdb needs an update, I will ask the 15169 folk to
update.

Re: Piter-IX and GOOGLE (AS15169)

[Christopher Morrow]

On Tue, Sep 18, 2018 at 3:34 PM A.T  wrote:

> Hello,
>
> I see AS15169 announcements from Piter-IX
> (https://www.peeringdb.com/ix/2149), but Google PeeringDB entry don't seem
> include Piter-IX.
> Any idea, is PeeringDB out of date here or should I be worried?
>
>
send me an as-path you see please?



> Best regards
> A.T
>
>
>
>
>
>
>

Re: Reaching out to ARIN members about their RPKI INVALID prefixes

[Christopher Morrow]

On Tue, Sep 18, 2018 at 4:54 PM nusenu  wrote:

> > Christopher Morrow wrote:
> >>> Yes that is what I had in mind (notification via email to the tech
> >>> contact).
> >>>
> >>>
> >> i'm positive that will end in sadness.
> >
> > we can also send snail mail :)
> > after all ~80 or so entities is a manageable amount of organizations to
> > notify in the ARIN region.
>
> correction: in the ARIN region there are just about 30 organizations to
> contact
> (~80 was for APNIC)
>
>
cool, sounds like you are all done in just ~20 USD of stamps.

Re: Reaching out to ARIN members about their RPKI INVALID prefixes

[nusenu]

> Christopher Morrow wrote:
>>> Yes that is what I had in mind (notification via email to the tech
>>> contact).
>>>
>>>
>> i'm positive that will end in sadness.
> 
> we can also send snail mail :)
> after all ~80 or so entities is a manageable amount of organizations to
> notify in the ARIN region.

correction: in the ARIN region there are just about 30 organizations to contact
(~80 was for APNIC)


-- 
https://twitter.com/nusenu_
https://mastodon.social/@nusenu



signature.asc
Description: OpenPGP digital signature

Piter-IX and GOOGLE (AS15169)

[A.T]

Hello,

I see AS15169 announcements from Piter-IX
(https://www.peeringdb.com/ix/2149), but Google PeeringDB entry don't seem
include Piter-IX.
Any idea, is PeeringDB out of date here or should I be worried?

Best regards
A.T

Re: Console Servers

[Jun Tanaka]

How about SMART CS series by Seiko solutions?
https://www.seiko-sol.co.jp/en/products/console-server/
-- 
Jun Tanaka - NetComBB/S.N.I

Re: Reaching out to ARIN members about their RPKI INVALID prefixes

[Job Snijders]

On Tue, Sep 18, 2018 at 02:44:30PM -0700, Owen DeLong wrote:
> ROAs are useful for one hop level validation. At the second AS hop
> they are 100% useless.

This conversation cannot be had without acknowledging there are multiple
layers of defense in securing BGP. We should also acknowledge that the
majority of Internet traffic passes over AS_PATHs that are only one hop.
Networks that exchange significant amounts of traffic, tend to peer
directly with each other.

> > In other words, RPKI and the Prefix-to-AS validation procedure give
> > us much more definitive inputs for routing policies compared to what
> > can be derived from the IRR.
> 
> Please explain to me how you distinguish good from bad in the
> following scenario… You peer with AS6939. You receive routes for
> 2001:db8:f300::/48 with the following AS Paths
> 
>   1. 6939 1239 54049 2312 1734
>   2. 6939 44046 12049 174 1734
> 
> Which one is valid? Which one is not? How did the ROA tell you this?

Both path 1 and 2 are invalid, because of peerlock we'd never accept
1239 behind 6939, or 174 behind 6939. AS_PATH filtering combined with
Origin Validation is where the magic is.

> > RPKI is useful in context of a defense in depth strategy. If one
> > combines "peerlock" AS_PATH filters with origin validation the end
> > result is bullet proof. Even if NTT is the only one to deploy this
> > combination, the benefits are notable.
> 
> Indeed, if peerlock gets wider deployment, it might prove useful. But
> unless I’m really misunderstanding peerlock, I don’t see that RPKI
> brings much else to the table in addition.

Wide deployment is not relevant, this is a unilateral defense mechanism,
so I fear there may indeed be a degree of misunderstanding.

Kind regards,

Job

Re: Reaching out to ARIN members about their RPKI INVALID prefixes

[nusenu]

Christopher Morrow:
>> Yes that is what I had in mind (notification via email to the tech
>> contact).
>>
>>
> i'm positive that will end in sadness.

we can also send snail mail :)
after all ~80 or so entities is a manageable amount of organizations to
notify in the ARIN region.



-- 
https://twitter.com/nusenu_
https://mastodon.social/@nusenu



signature.asc
Description: OpenPGP digital signature

Re: Reaching out to ARIN members about their RPKI INVALID prefixes

[Job Snijders]

On Tue, Sep 18, 2018 at 02:35:44PM -0700, Owen DeLong wrote:
> > "rir says owen can originate route FOO"
> > "ROA for 157.130.1.0/24 says OWEN can originate"
> 
> Nope… ROA says (e.g.) AS1734 (or anyone willing to impersonate AS1734)
> can originate 192.159.10.0/24.

I'd phrase slightly different (assuming there is only one ROA): the ROA
says ONLY AS1734 (or anyone willing to impersonate AS1734) can originate
192.159.10.0/24.

With IRR, the crucial addition of the word "ONLY" in the above sentence
is not possible.

> > those seem like valuable pieces of information. Especially since I
> > can know this through some machine parseable fashion.
> 
> I would agree if you had some way to distinguish AS1734 originating
> FOO from AS174 originating FOO with a prepend of AS1734.

In the common scenario you can distinguish those with today's
technology. As mentioned before - dense peering (having the shortest
AS_PATH) or the peerlock approach for all *practical* intents solve the
issue of path validation. You can try spoofing AS 7018 - you'll notice
that your announcements won't make it into NTT. Having just that
validated path (which is only one hop) is a very strong defense
mechanism.

Let's take another example: Google offers access to one of the world's
largest DNS resolver services, Cloudflare hosts lots of authoritative
DNS. According to PeeringDB they have quite some locations in common
with each other so let's assume they directly peer with each other. If
both sides create ROAs for their prefixes, and ROAs for the prefixes
that host the auth side, and both sides perform RPKI Origin Validation;
an attacker cannot inject itself between the two. 

One can argue "this only helped google and cloudflare" - but on the
other hand anno 2018 the Internet experience for the average end user is
composed from services hosted by a relatively small number of providers.
Preventing disruptions of communication between just those few players
has significant implications for all of us.

Kind regards,

Job

Re: Reaching out to ARIN members about their RPKI INVALID prefixes

[Owen DeLong]

> On Sep 18, 2018, at 2:34 PM, Job Snijders  wrote:
> 
> On Tue, Sep 18, 2018 at 12:04:19PM -0700, Owen DeLong wrote:
>>> Perhaps said another way: 
>>> 
>>> "How would you figure out what prefixes your bgp peer(s) should be sending 
>>> you?"
>>>   (in an automatable, and verifiable manner)
>> 
>> In theory, that’s what IRRs are for.
> 
> You may be overlooking the fact that the semantics of an IRR route
> object are subtly different than those of a RPKI ROA. The Prefix-to-AS
> Mapping Database concept as introduced Section 2 of RFC 6811 is a huge
> step forward compared to the (somewhat loosely defined) semantics of IRR
> route objects.
> 
> RPKI ROAs are more than "IRR with crypto": IRR objects are basically a
> list of unverifiable attestations with no proof of termination. Whereas

Right… Hence my call for IRRs with stronger authentication and validation.
(i.e. IRRs run by RIRs that have the same level of maintenance authentication 
and
authorization requirements as current RPKI implementations).

> when that same information is published through the RPKI, we now know
> two things: (1) the owner of the resource consented to the creation of
> the object and (2) any BGP UPDATE that conflicts with covering RPKI ROAs
> is invalid.

Yes, but, what you don’t know is whether any BGP UPDATE that contains the valid
origin ASN as origin came from the origin ASN it claims.

Instead, you provided a cryptographically signed recipe for believable spoofing.

Actually, they’re quite a bit less… They provide no path data.

ROAs are useful for one hop level validation. At the second AS hop they are 
100% useless.

> In other words, RPKI and the Prefix-to-AS validation procedure give us
> much more definitive inputs for routing policies compared to what can be
> derived from the IRR.


Please explain to me how you distinguish good from bad in the following 
scenario…

You peer with AS6939.

You receive routes for 2001:db8:f300::/48 with the following AS Paths

1. 6939 1239 54049 2312 1734
2. 6939 44046 12049 174 1734

Which one is valid? Which one is not? How did the ROA tell you this?

With the IRR, I can (theoretically) compare an AS Path to the valid set of path
associations documented in RPSL. (modulo lack of participation/implementation,
which RPKI likewise suffers from). With RPKI, I can’t tell anything.

> I simply view RPKI as a successor to the IRR system with some much
> needed improvements.

Your view is, IMHO, very distorted.

>> In practice, while they offer better theoretical capabilities if
>> stronger authentication were added, the current implementation and
>> acceptance leaves much to be desired.
> 
> Luckily multiple projects are passing through the pipeline to reduce the
> risk some IRRs represented.
> 
> https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-implementation
> https://teamarin.net/2018/07/12/the-path-forward/
> 
> Considering that RPKI and IRR will co-exist in one form or another for a
> wihle it is encouraging to see success in patching loopholes.

Yep… Properly implemented and adopted, IRRs show some progress for actual path
validation abilities, including origin.

>> However, even in theory, RPKI offers nothing of particular benefit
>> even in its best case of widespread implementation.
> 
> I can't really wrap my head around how you can arrive at such a
> conclusion in light of all the information that has been provided to
> you. So perhaps we'll have to agree to disagree.

See above. What is it you believe RPKI offers beyond 1 hop that is anything 
more than
a cryptographically signed recipe for believable spoofing?

> RPKI is useful in context of a defense in depth strategy. If one
> combines "peerlock" AS_PATH filters with origin validation the end
> result is bullet proof. Even if NTT is the only one to deploy this
> combination, the benefits are notable.

Indeed, if peerlock gets wider deployment, it might prove useful. But unless I’m
really misunderstanding peerlock, I don’t see that RPKI brings much else to
the table in addition.

Owen

Re: Reaching out to ARIN members about their RPKI INVALID prefixes

[Christopher Morrow]

On Tue, Sep 18, 2018 at 2:32 PM Owen DeLong  wrote:

>
>
> On Sep 18, 2018, at 2:15 PM, Christopher Morrow 
> wrote:
>
>
>
> On Tue, Sep 18, 2018 at 1:33 PM nusenu  wrote:
>
>> Christopher Morrow wrote:
>> > Perhaps this was answered elsewhere, but: "Why is this something
>> > ARIN (the org) should take on?"
>>
>> Thanks for this question, I believe this is an important one.
>>
>> I reasoned about why I think RIRs are in a good position to send these
>> emails here: [1]
>> but I will quote from it for convenience:
>>
>> > Notifying affected IP Holders
>> >
>> > The natural next step (and that was our initial intention when
>> > looking at INVALIDs) would be to send out emails to affected IP
>> > holders and ask them to address the INVALIDs but although that could
>> > be automated, we believe the impact would be better, if that email
>> > came from some trusted entity like the RIR relevant to the affected
>> > IP holder instead of a random entity they never had any contact
>> > before (us).
>> >
>> > Asking RIRs to reach out to their members also scales better since
>> > every RIR would only have to take care of their own members.
>> [...]
>>
>>
> i don't know that the contacts the RIR has for the entity is necessarily
> the one that controls/deals-with the RPKI data though.
>
>
> It sort of has to be, as managing your RPKI data (at least in the ARIN
> region) involves doing it through your ARIN On-Line account which must be
> associated with the ORG associated with the resources in question.
>
>
I think I can manage my employer's RPKI data, and I'm not on the
tech/admin/etc handles...
I think I can also ask the person(s) who are to do it and they may have no
idea what I'm asking beyond: "click these 5 things, type that thing,
thanks!"



> I also think that generally if folk set all that up they probably know
>
>

> (or will soon enough) that they have a mistake.
>
>
> You overestimate some things here.
>
>
probably, but ... eventually if your internet gets very small you'll look
at why.


> Generally speaking, I think "folk should fix themselves, and
> maintain/monitor their configuration", that ARIN (or anyone else sending
> 'unsolicited email') here is going to end badly in the worst case and 'not
> have any effect' in the majority of cases.
>
>
> Agreed.
>
>
perhaps this is really my point: "I have no confidence that ARIN doing this
(or anyone else except an upstream network/peer) is going to effect change"


>
>
>> [1]
>> https://medium.com/@nusenu/towards-cleaning-up-rpki-invalids-d69b03ab8a8c
>>
>>
>> > Why can't (or why isn't) this something that 'many'
>> > monitoring/alerting companies/orgs are offering?
>>
>> There are companies offering BGP monitoring including RPKI ROAs, but
>> the affected IP holders are unlikely customers of those monitoring
>> services or generally aware of the problem.
>>
>>
> ok, maybe they should though? :)
>
>
> I love a good tautology.
>
>
I'm glad you enjoyed it... you found the easter-egg!
Generally speaking though (and trying to be constructive) people who use
BGP to manage reachability to their network resources really should monitor
what their resources look like externally... and folk do offer services
which do these things.

"As seen on TV  bgp monitoring for you!" :)


>
>
>> > it's unclear, to me, why ARIN is in any better position than any
>> > other party to perform this sort of activity? I would expect that, at
>> > the base level, "I just got random/unexpected email from ARIN?" will
>> > get dropped in the spam-can, while: "My monitoring company to which I
>> > signed up/contracted emailed into my ticket-system for action..
>> > better go do something!" is the path to incentivize.
>>
>> The problem is how do you make operators aware of the problem in the
>> first place.
>>
>>
> ideally they are aware of thier own config, have a person(s) responsible
> for managing that configuration and care about reachability...  if they
> don't have that today, they will soon enough.
>
>
> Optimist!
>
>
yea... it's probably as optimistic as your hope that irr data will get
better? :)
I think as more things depend on reachability the state will improve... or
that's my hope, yes.


> Owen
>
>

Brovade/Foundry VLAN translation

[Mike Hammett]

I'm not thinking so, but I figured I'd ask here.

Is there any way to do VLAN translation on the Brocade VDX-6720 or the Foundry 
FESX424?

Worst case, I'll burn a couple ports looping out and then back in.

We are looking to replace the Foundrys with Arista 7050s at some point.

-Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe 
Brothers WISP

Re: Reaching out to ARIN members about their RPKI INVALID prefixes

[Owen DeLong]

> 
> "rir says owen can originate route FOO"
> "ROA for 157.130.1.0/24  says OWEN can originate"
> 

Nope… ROA says (e.g.) AS1734 (or anyone willing to impersonate AS1734)  can 
originate 192.159.10.0/24.

> those seem like valuable pieces of information. Especially since I can know 
> this through some machine parseable fashion.

I would agree if you had some way to distinguish AS1734 originating FOO from 
AS174 originating FOO with a prepend of AS1734.

Owen

Re: Reaching out to ARIN members about their RPKI INVALID prefixes

[Job Snijders]

On Tue, Sep 18, 2018 at 12:04:19PM -0700, Owen DeLong wrote:
> > Perhaps said another way: 
> > 
> > "How would you figure out what prefixes your bgp peer(s) should be sending 
> > you?"
> >(in an automatable, and verifiable manner)
> 
> In theory, that’s what IRRs are for.

You may be overlooking the fact that the semantics of an IRR route
object are subtly different than those of a RPKI ROA. The Prefix-to-AS
Mapping Database concept as introduced Section 2 of RFC 6811 is a huge
step forward compared to the (somewhat loosely defined) semantics of IRR
route objects.

RPKI ROAs are more than "IRR with crypto": IRR objects are basically a
list of unverifiable attestations with no proof of termination. Whereas
when that same information is published through the RPKI, we now know
two things: (1) the owner of the resource consented to the creation of
the object and (2) any BGP UPDATE that conflicts with covering RPKI ROAs
is invalid.

In other words, RPKI and the Prefix-to-AS validation procedure give us
much more definitive inputs for routing policies compared to what can be
derived from the IRR.

I simply view RPKI as a successor to the IRR system with some much
needed improvements.

> In practice, while they offer better theoretical capabilities if
> stronger authentication were added, the current implementation and
> acceptance leaves much to be desired.

Luckily multiple projects are passing through the pipeline to reduce the
risk some IRRs represented.

https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-implementation
https://teamarin.net/2018/07/12/the-path-forward/

Considering that RPKI and IRR will co-exist in one form or another for a
wihle it is encouraging to see success in patching loopholes.

> However, even in theory, RPKI offers nothing of particular benefit
> even in its best case of widespread implementation.

I can't really wrap my head around how you can arrive at such a
conclusion in light of all the information that has been provided to
you. So perhaps we'll have to agree to disagree.

RPKI is useful in context of a defense in depth strategy. If one
combines "peerlock" AS_PATH filters with origin validation the end
result is bullet proof. Even if NTT is the only one to deploy this
combination, the benefits are notable.

Kind regards,

Job

Re: Reaching out to ARIN members about their RPKI INVALID prefixes

[Christopher Morrow]

On Tue, Sep 18, 2018 at 12:04 PM Owen DeLong  wrote:

>
>
> On Sep 18, 2018, at 11:06 AM, Christopher Morrow 
> wrote:
>
>
>
> On Tue, Sep 18, 2018 at 10:36 AM Job Snijders  wrote:
>
>> Owen,
>>
>> On Tue, Sep 18, 2018 at 10:23:42AM -0700, Owen DeLong wrote:
>> > Personally, since all RPKI accomplishes is providing a
>> > cryptographically signed notation of origin ASNs that hijackers should
>> > prepend to their announcements in order to create an aura of
>> > credibility, I think we should stop throwing resources down this
>> > rathole.
>> I think you underestimate how valuable RPKI based Origin Validation
>> (even just by itself) is in today's Internet landscape.
>>
>> If you are aware of other efforts or more fruitful approaches please let
>> us know.
>>
>>
> Perhaps said another way:
>
> "How would you figure out what prefixes your bgp peer(s) should be sending
> you?"
>(in an automatable, and verifiable manner)
>
> -chris
>
>
> In theory, that’s what IRRs are for.
>
>
it's not worked out so far.
there's no real authorization/authentication of note on the data set via
the irr.
you have no real way of knowing that 'as12 should be announcing
157.130.0.0/16' ... except by chasing the arin/ripe/etc records today,
something that those orgs stamp and which machines could validate without
people using eyeballs would sure be nice... Oh, that's what RPKI is
supposed to provide.


> In practice, while they offer better theoretical capabilities if stronger
> authentication were added, the current implementation and acceptance leaves
> much to be desired.
>

and has for approximately 30 yrs... I don't imagine magically it's going to
get better in the next 30 either.


>
>
However, even in theory, RPKI offers nothing of particular benefit even in
> its best case of widespread implementation.
>
>
"rir says owen can originate route FOO"
"ROA for 157.130.1.0/24 says OWEN can originate"

those seem like valuable pieces of information. Especially since I can know
this through some machine parseable fashion.

-chris

> Owen
>
>

Re: Reaching out to ARIN members about their RPKI INVALID prefixes

[Owen DeLong]

> On Sep 18, 2018, at 2:15 PM, Christopher Morrow  
> wrote:
> 
> 
> 
> On Tue, Sep 18, 2018 at 1:33 PM nusenu  > wrote:
> Christopher Morrow wrote:
> > Perhaps this was answered elsewhere, but: "Why is this something
> > ARIN (the org) should take on?"
> 
> Thanks for this question, I believe this is an important one.
> 
> I reasoned about why I think RIRs are in a good position to send these emails 
> here: [1]
> but I will quote from it for convenience:
> 
> > Notifying affected IP Holders
> > 
> > The natural next step (and that was our initial intention when
> > looking at INVALIDs) would be to send out emails to affected IP
> > holders and ask them to address the INVALIDs but although that could
> > be automated, we believe the impact would be better, if that email
> > came from some trusted entity like the RIR relevant to the affected
> > IP holder instead of a random entity they never had any contact
> > before (us).
> > 
> > Asking RIRs to reach out to their members also scales better since
> > every RIR would only have to take care of their own members.
> [...]
> 
> 
> i don't know that the contacts the RIR has for the entity is necessarily the 
> one that controls/deals-with the RPKI data though.

It sort of has to be, as managing your RPKI data (at least in the ARIN region) 
involves doing it through your ARIN On-Line account which must be associated 
with the ORG associated with the resources in question.

> I also think that generally if folk set all that up they probably know (or 
> will soon enough) that they have a mistake.

You overestimate some things here.

> Generally speaking, I think "folk should fix themselves, and maintain/monitor 
> their configuration", that ARIN (or anyone else sending 'unsolicited email') 
> here is going to end badly in the worst case and 'not have any effect' in the 
> majority of cases.

Agreed.

>  
> [1] https://medium.com/@nusenu/towards-cleaning-up-rpki-invalids-d69b03ab8a8c 
> 
> 
> 
> > Why can't (or why isn't) this something that 'many' 
> > monitoring/alerting companies/orgs are offering?
> 
> There are companies offering BGP monitoring including RPKI ROAs, but
> the affected IP holders are unlikely customers of those monitoring
> services or generally aware of the problem.
> 
> 
> ok, maybe they should though? :) 

I love a good tautology.

>  
> > it's unclear, to me, why ARIN is in any better position than any
> > other party to perform this sort of activity? I would expect that, at
> > the base level, "I just got random/unexpected email from ARIN?" will
> > get dropped in the spam-can, while: "My monitoring company to which I
> > signed up/contracted emailed into my ticket-system for action..
> > better go do something!" is the path to incentivize.
> 
> The problem is how do you make operators aware of the problem in the first 
> place.
> 
> 
> ideally they are aware of thier own config, have a person(s) responsible for 
> managing that configuration and care about reachability...  if they don't 
> have that today, they will soon enough.

Optimist!

Owen

Re: Reaching out to ARIN members about their RPKI INVALID prefixes

[Owen DeLong]

> On Sep 18, 2018, at 12:09 PM, Jared Mauch  wrote:
> 
> 
> 
>> On Sep 18, 2018, at 3:04 PM, Owen DeLong  wrote:
>> 
>> 
>> 
>>> On Sep 18, 2018, at 11:06 AM, Christopher Morrow  
>>> wrote:
>>> 
>>> 
>>> 
>>> On Tue, Sep 18, 2018 at 10:36 AM Job Snijders  wrote:
>>> Owen,
>>> 
>>> On Tue, Sep 18, 2018 at 10:23:42AM -0700, Owen DeLong wrote:
 Personally, since all RPKI accomplishes is providing a
 cryptographically signed notation of origin ASNs that hijackers should
 prepend to their announcements in order to create an aura of
 credibility, I think we should stop throwing resources down this
 rathole.
>>> I think you underestimate how valuable RPKI based Origin Validation
>>> (even just by itself) is in today's Internet landscape.
>>> 
>>> If you are aware of other efforts or more fruitful approaches please let
>>> us know.
>>> 
>>> 
>>> Perhaps said another way: 
>>> 
>>> "How would you figure out what prefixes your bgp peer(s) should be sending 
>>> you?"
>>>   (in an automatable, and verifiable manner)
>>> 
>>> -chris
>> 
>> In theory, that’s what IRRs are for.
>> 
>> In practice, while they offer better theoretical capabilities if stronger 
>> authentication were added, the current implementation and acceptance leaves 
>> much to be desired.
> 
> Judging a global ecosystem just by what ARIN does is perhaps some of the 
> issue.  ARIN seems to be the outlier here as has been measured.  An ARIN 
> prefix ROA is less valuable than the other regions and this is IMO deliberate 
> on the part of ARIN.
> 
>> However, even in theory, RPKI offers nothing of particular benefit even in 
>> its best case of widespread implementation.
> 
> Disagree, but that’s ok.  I know at $dayJob I’m preparing the way, but it’s 
> much harder than it should be due to the nature of our business.
> 
> - Jared

What does RPKI offer other than a way to know what to spoof in a prepend for 
your forged announcement?

Owen

Re: Reaching out to ARIN members about their RPKI INVALID prefixes

[Christopher Morrow]

On Tue, Sep 18, 2018 at 1:33 PM nusenu  wrote:

> Christopher Morrow wrote:
> > Perhaps this was answered elsewhere, but: "Why is this something
> > ARIN (the org) should take on?"
>
> Thanks for this question, I believe this is an important one.
>
> I reasoned about why I think RIRs are in a good position to send these
> emails here: [1]
> but I will quote from it for convenience:
>
> > Notifying affected IP Holders
> >
> > The natural next step (and that was our initial intention when
> > looking at INVALIDs) would be to send out emails to affected IP
> > holders and ask them to address the INVALIDs but although that could
> > be automated, we believe the impact would be better, if that email
> > came from some trusted entity like the RIR relevant to the affected
> > IP holder instead of a random entity they never had any contact
> > before (us).
> >
> > Asking RIRs to reach out to their members also scales better since
> > every RIR would only have to take care of their own members.
> [...]
>
>
i don't know that the contacts the RIR has for the entity is necessarily
the one that controls/deals-with the RPKI data though.
I also think that generally if folk set all that up they probably know (or
will soon enough) that they have a mistake.

Generally speaking, I think "folk should fix themselves, and
maintain/monitor their configuration", that ARIN (or anyone else sending
'unsolicited email') here is going to end badly in the worst case and 'not
have any effect' in the majority of cases.


> [1]
> https://medium.com/@nusenu/towards-cleaning-up-rpki-invalids-d69b03ab8a8c
>
>
> > Why can't (or why isn't) this something that 'many'
> > monitoring/alerting companies/orgs are offering?
>
> There are companies offering BGP monitoring including RPKI ROAs, but
> the affected IP holders are unlikely customers of those monitoring
> services or generally aware of the problem.
>
>
ok, maybe they should though? :)


> > it's unclear, to me, why ARIN is in any better position than any
> > other party to perform this sort of activity? I would expect that, at
> > the base level, "I just got random/unexpected email from ARIN?" will
> > get dropped in the spam-can, while: "My monitoring company to which I
> > signed up/contracted emailed into my ticket-system for action..
> > better go do something!" is the path to incentivize.
>
> The problem is how do you make operators aware of the problem in the first
> place.
>
>
ideally they are aware of thier own config, have a person(s) responsible
for managing that configuration and care about reachability...  if they
don't have that today, they will soon enough.


> > The question I asked ARIN was specifically:
> >>> Would you be open to reach out to your affected members to
> >>> inform them about their affected IP prefixes?
> >>
> >>
> > 'how?' (email to the tech-contact? etc? did they sign up for said
> > monitoring and point to the right destination email catcher?)
>
> Yes that is what I had in mind (notification via email to the tech
> contact).
>
>
i'm positive that will end in sadness.


> kind regards,
> nusenu
>
> --
> https://twitter.com/nusenu_
> https://mastodon.social/@nusenu
>
>

RE: Reaching out to ARIN members about their RPKI INVALID prefixes

[Michel Py]

> nusenu wrote :
> What do you think about the idea that ARIN actively informs their affected 
> members about prefixes that are unreachable in an RPKI ROV environment?

Support, although I doubt it would achieve the desired result. I support it for 
the following reason : when someone starts to block invalid prefixes, they 
would not have the excuse to say "we did not know about it".

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: [proj-bgp] adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor?

[Michel Py]

Doug,

> Douglas Montgomery wrote :
> You should follow the discussion of draft-ietf-sidrops-validating-bgp-speaker 
> which proposed standardizing an approach to doing
> what you suggest.  Many on this thread think that it is a counterproductive 
> idea to do this.  See discussion starting here:
> https://mailarchive.ietf.org/arch/msg/sidrops/6lDz5dI-jg-OhpGR4xKRZ6lYZRA

I'm looking at adoption numbers, especially in the ARIN region. RPKI is 
practically inexistant, and some respected members are already saying it's a 
rathole.

At 2% deployment, we are far away from the critical mass it needs. If the 
deployment strategy does not change, I don't see how that critical mass will 
happen. Until someone actually starts to discard invalid  RPKI prefixes and 
assesses the actual inconvenience, this is not going anywhere. If you want to 
promote it, you have to do something not just analyze.


> Second, in general our mission is limited to supporting the development and 
> promulgation of consensus standards and the development of test / measurement 
> methods
> and guidanceto accelerate their adoption.  In particular we are not well 
> positioned to provide operational Internet services of the nature you 
> describe.

You provide critical time services, this would be nothing compared to it.


> 2. There are some legal issues regarding the redistribution of machine 
> readable RPKI data/results to third parties.  See below section 5 Prohibited 
> Conduct:
> https://www.arin.net/resources/rpki/rpa.pdf


As always (and rightfully so) ARIN is trying to avoid legal liability. Better 
to remove the possibility of getting sued than having to deal with it. There 
are ways around that.

My $0.02,

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

Re: Reaching out to ARIN members about their RPKI INVALID prefixes

[nusenu]

Christopher Morrow wrote:
> Perhaps this was answered elsewhere, but: "Why is this something
> ARIN (the org) should take on?"

Thanks for this question, I believe this is an important one.

I reasoned about why I think RIRs are in a good position to send these emails 
here: [1]
but I will quote from it for convenience:

> Notifying affected IP Holders
> 
> The natural next step (and that was our initial intention when
> looking at INVALIDs) would be to send out emails to affected IP
> holders and ask them to address the INVALIDs but although that could
> be automated, we believe the impact would be better, if that email
> came from some trusted entity like the RIR relevant to the affected
> IP holder instead of a random entity they never had any contact
> before (us).
> 
> Asking RIRs to reach out to their members also scales better since
> every RIR would only have to take care of their own members.
[...]

[1] https://medium.com/@nusenu/towards-cleaning-up-rpki-invalids-d69b03ab8a8c

 
> Why can't (or why isn't) this something that 'many' 
> monitoring/alerting companies/orgs are offering?

There are companies offering BGP monitoring including RPKI ROAs, but
the affected IP holders are unlikely customers of those monitoring
services or generally aware of the problem.

> it's unclear, to me, why ARIN is in any better position than any
> other party to perform this sort of activity? I would expect that, at
> the base level, "I just got random/unexpected email from ARIN?" will
> get dropped in the spam-can, while: "My monitoring company to which I
> signed up/contracted emailed into my ticket-system for action..
> better go do something!" is the path to incentivize.

The problem is how do you make operators aware of the problem in the first 
place.

> The question I asked ARIN was specifically:
>>> Would you be open to reach out to your affected members to
>>> inform them about their affected IP prefixes?
>> 
>> 
> 'how?' (email to the tech-contact? etc? did they sign up for said 
> monitoring and point to the right destination email catcher?)

Yes that is what I had in mind (notification via email to the tech contact).

kind regards,
nusenu

-- 
https://twitter.com/nusenu_
https://mastodon.social/@nusenu



signature.asc
Description: OpenPGP digital signature

Re: Massive Price Increase for X-conns at Telehouse Chelsea, NYC

[Scott Weeks]

--- b...@ufl.edu wrote:
From: Bruce H McIntosh 

I can remember a conversation like this at a Joint Techs meeting 
many years back. Several of us were outgassing about how expensive 
it was to get 100mbps connections off our campuses, until the guy 
from the University of Hawaii told us how much he was paying per 
month for a *T1* to the mainland. :D
---


That was many, many (ancient) years back! :-)

scott

Re: Massive Price Increase for X-conns at Telehouse Chelsea, NYC

[Owen DeLong]

> On Sep 18, 2018, at 12:02 PM, Bruce H McIntosh  wrote:
> 
>>> Current list price for 10G Xconnect at the major colo site in Israel is
>>> $5840/month.   Discounts are available :-)
>>> Keep complaining about $350/mo costs.  You have no idea how lucky you are.
>>> 
>>> -Hank
>> So, you’re arguing that because the prices in Israel are 15*ridiculous, we 
>> should stop complaining about 1*ridiculous?
>> You have no idea how distorted your perspective is.
> 
> It's not necessarily distorted, it's just a different frame of reference. I 
> can remember a conversation like this at a Joint Techs meeting many years 
> back. Several of us were outgassing about how expensive it was to get 100mbps 
> connections off our campuses, until the guy from the University of Hawaii 
> told us how much he was paying per month for a *T1* to the mainland. :D

Sure, but in this case, we’re not comparing transaoceanic circuits to local 
loops, we’re comparing single pair fiber cross connects between two points in 
the same datacenter or datacenter campus.

I’d argue that the difference between reasonable (≤$500 one-time and ≤$50 MRC) 
and $300 MRC is within range of argument, but I cannot see any way in which an 
argument can be made that $5840 MRC is not a distortion in that same 
circumstance.

Owen

Re: Reaching out to ARIN members about their RPKI INVALID prefixes

[Jared Mauch]

> On Sep 18, 2018, at 3:04 PM, Owen DeLong  wrote:
> 
> 
> 
>> On Sep 18, 2018, at 11:06 AM, Christopher Morrow  
>> wrote:
>> 
>> 
>> 
>> On Tue, Sep 18, 2018 at 10:36 AM Job Snijders  wrote:
>> Owen,
>> 
>> On Tue, Sep 18, 2018 at 10:23:42AM -0700, Owen DeLong wrote:
>> > Personally, since all RPKI accomplishes is providing a
>> > cryptographically signed notation of origin ASNs that hijackers should
>> > prepend to their announcements in order to create an aura of
>> > credibility, I think we should stop throwing resources down this
>> > rathole.
>> I think you underestimate how valuable RPKI based Origin Validation
>> (even just by itself) is in today's Internet landscape.
>> 
>> If you are aware of other efforts or more fruitful approaches please let
>> us know.
>> 
>> 
>> Perhaps said another way: 
>> 
>> "How would you figure out what prefixes your bgp peer(s) should be sending 
>> you?"
>>(in an automatable, and verifiable manner)
>> 
>> -chris
> 
> In theory, that’s what IRRs are for.
> 
> In practice, while they offer better theoretical capabilities if stronger 
> authentication were added, the current implementation and acceptance leaves 
> much to be desired.

Judging a global ecosystem just by what ARIN does is perhaps some of the issue. 
 ARIN seems to be the outlier here as has been measured.  An ARIN prefix ROA is 
less valuable than the other regions and this is IMO deliberate on the part of 
ARIN.

> However, even in theory, RPKI offers nothing of particular benefit even in 
> its best case of widespread implementation.

Disagree, but that’s ok.  I know at $dayJob I’m preparing the way, but it’s 
much harder than it should be due to the nature of our business.

- Jared

Re: Reaching out to ARIN members about their RPKI INVALID prefixes

[Owen DeLong]

> On Sep 18, 2018, at 10:35 AM, Job Snijders  wrote:
> 
> Owen,
> 
> On Tue, Sep 18, 2018 at 10:23:42AM -0700, Owen DeLong wrote:
>> Personally, since all RPKI accomplishes is providing a
>> cryptographically signed notation of origin ASNs that hijackers should
>> prepend to their announcements in order to create an aura of
>> credibility, I think we should stop throwing resources down this
>> rathole.
> 
> 1/ You may be overlooking the fact that many networks peer directly with
> what (for them) are the important sources/destinations. The semantics of
> RPKI ROAs help block illegitimate more-specifics, and the short AS_PATH
> between players prevents a hijacker from inserting themself. In other
> words - the most important AS_PATHs are 1 hop. The Internet's dense
> interconnectedness is saving its bacon.

While this may be true for a handful of well peered ASNs, it’s certainly not 
common
around the wider internet.

> 2/ Another approach to achieve path validation for 1 hop is through
> mechanisms such what NTT calls 'peerlock'.
> https://www.youtube.com/watch?v=CSLpWBrHy10 
> 

Single hop is relatively easy. It’s 2+ hop where things get far more 
interesting.

It’s convenient to reduce the problem set to the one you can easily solve, but 
ignoring
the rest of the problem set smacks of hand-waving and “insert magic here”.

> 3/ Lastly, some folks are innovating in this space to help automate
> concepts such as peerlock through what is called ASPA. ASPA is intended
> as an out-of-band, deployable alternative to BGPSec.

OK, but IIRC, it’s rather orthogonal to RPKI.

> https://tools.ietf.org/html/draft-azimov-sidrops-aspa-profile
> https://tools.ietf.org/html/draft-azimov-sidrops-aspa-verification
> 
> I think you underestimate how valuable RPKI based Origin Validation
> (even just by itself) is in today's Internet landscape.

I think you overestimate it.

Owen

Re: Reaching out to ARIN members about their RPKI INVALID prefixes

[Owen DeLong]

> On Sep 18, 2018, at 11:06 AM, Christopher Morrow  
> wrote:
> 
> 
> 
> On Tue, Sep 18, 2018 at 10:36 AM Job Snijders  > wrote:
> Owen,
> 
> On Tue, Sep 18, 2018 at 10:23:42AM -0700, Owen DeLong wrote:
> > Personally, since all RPKI accomplishes is providing a
> > cryptographically signed notation of origin ASNs that hijackers should
> > prepend to their announcements in order to create an aura of
> > credibility, I think we should stop throwing resources down this
> > rathole.
> I think you underestimate how valuable RPKI based Origin Validation
> (even just by itself) is in today's Internet landscape.
> 
> If you are aware of other efforts or more fruitful approaches please let
> us know.
> 
> 
> Perhaps said another way: 
> 
> "How would you figure out what prefixes your bgp peer(s) should be sending 
> you?"
>(in an automatable, and verifiable manner)
> 
> -chris

In theory, that’s what IRRs are for.

In practice, while they offer better theoretical capabilities if stronger 
authentication were added, the current implementation and acceptance leaves 
much to be desired.

However, even in theory, RPKI offers nothing of particular benefit even in its 
best case of widespread implementation.

Owen

Re: Massive Price Increase for X-conns at Telehouse Chelsea, NYC

[Bruce H McIntosh]

Current list price for 10G Xconnect at the major colo site in Israel is
$5840/month.   Discounts are available :-)
Keep complaining about $350/mo costs.  You have no idea how lucky you are.

-Hank


So, you’re arguing that because the prices in Israel are 15*ridiculous, we 
should stop complaining about 1*ridiculous?

You have no idea how distorted your perspective is.


It's not necessarily distorted, it's just a different frame of reference. I can 
remember a conversation like this at a Joint Techs meeting many years back. 
Several of us were outgassing about how expensive it was to get 100mbps 
connections off our campuses, until the guy from the University of Hawaii told 
us how much he was paying per month for a *T1* to the mainland. :D


--

Bruce H. McIntosh
Network Engineer II
University of Florida Information Technology
b...@ufl.edu
352-273-1066

Re: Massive Price Increase for X-conns at Telehouse Chelsea, NYC

[Owen DeLong]

> On Sep 17, 2018, at 9:42 PM, Hank Nussbacher  wrote:
> 
> On 17/09/2018 23:26, Phil Lavin wrote:
>>> $350/mo seems to be standard. Our DCs are at $250.Seems more like they 
>>> held onto out of date pricing for a long time then realized it.
>> For what it's worth, Telehouse London is around 30 USD/month for an 
>> x-connect within the same building. Our US datacentre (not Telehouse) on the 
>> other hand is around 200 USD/month. It's always felt disproportionally 
>> expensive but maybe those kind of prices are expected for the North America 
>> region.
> Current list price for 10G Xconnect at the major colo site in Israel is
> $5840/month.   Discounts are available :-)
> Keep complaining about $350/mo costs.  You have no idea how lucky you are.
> 
> -Hank

So, you’re arguing that because the prices in Israel are 15*ridiculous, we 
should stop complaining about 1*ridiculous?

You have no idea how distorted your perspective is.

Owen

Re: Reaching out to ARIN members about their RPKI INVALID prefixes

[Christopher Morrow]

(popping back to the top of the thread.. sorry)

On Tue, Sep 18, 2018 at 7:58 AM nusenu  wrote:

> Dear NANOG,
>
> when I approached ARIN about how they feel about reaching out to their
> members about
> prefixes that are unreachable in a route origin validation (ROV)
> environment,
> John Curran (CEO ARIN) referred me to you (see email bellow - quoted with
> permission).
>
>
Perhaps this was answered elsewhere, but:
  "Why is this something ARIN (the org) should take on?"

Why can't (or why isn't) this something that 'many' monitoring/alerting
companies/orgs are offering?
it's unclear, to me, why ARIN is in any better position than any other
party to perform this sort of activity?
I would expect that, at the base level, "I just got random/unexpected email
from ARIN?" will get dropped in the spam-can, while: "My monitoring company
to which I signed up/contracted emailed into my ticket-system for action..
better go do something!" is the path to incentivize.

The question I asked ARIN was specifically:
> > Would you be open to reach out to your affected members to inform them
> about
> > their affected IP prefixes?
>
>
'how?' (email to the tech-contact? etc? did they sign up for said
monitoring and point to the right destination email catcher?)

Re: Reaching out to ARIN members about their RPKI INVALID prefixes

[Christopher Morrow]

On Tue, Sep 18, 2018 at 10:36 AM Job Snijders  wrote:

> Owen,
>
> On Tue, Sep 18, 2018 at 10:23:42AM -0700, Owen DeLong wrote:
> > Personally, since all RPKI accomplishes is providing a
> > cryptographically signed notation of origin ASNs that hijackers should
> > prepend to their announcements in order to create an aura of
> > credibility, I think we should stop throwing resources down this
> > rathole.
> I think you underestimate how valuable RPKI based Origin Validation
> (even just by itself) is in today's Internet landscape.
>
> If you are aware of other efforts or more fruitful approaches please let
> us know.
>
>
Perhaps said another way:

"How would you figure out what prefixes your bgp peer(s) should be sending
you?"
   (in an automatable, and verifiable manner)

-chris

Re: Reaching out to ARIN members about their RPKI INVALID prefixes

[Job Snijders]

Owen,

On Tue, Sep 18, 2018 at 10:23:42AM -0700, Owen DeLong wrote:
> Personally, since all RPKI accomplishes is providing a
> cryptographically signed notation of origin ASNs that hijackers should
> prepend to their announcements in order to create an aura of
> credibility, I think we should stop throwing resources down this
> rathole.

1/ You may be overlooking the fact that many networks peer directly with
what (for them) are the important sources/destinations. The semantics of
RPKI ROAs help block illegitimate more-specifics, and the short AS_PATH
between players prevents a hijacker from inserting themself. In other
words - the most important AS_PATHs are 1 hop. The Internet's dense
interconnectedness is saving its bacon.

2/ Another approach to achieve path validation for 1 hop is through
mechanisms such what NTT calls 'peerlock'.
https://www.youtube.com/watch?v=CSLpWBrHy10

3/ Lastly, some folks are innovating in this space to help automate
concepts such as peerlock through what is called ASPA. ASPA is intended
as an out-of-band, deployable alternative to BGPSec.

https://tools.ietf.org/html/draft-azimov-sidrops-aspa-profile
https://tools.ietf.org/html/draft-azimov-sidrops-aspa-verification

I think you underestimate how valuable RPKI based Origin Validation
(even just by itself) is in today's Internet landscape.

If you are aware of other efforts or more fruitful approaches please let
us know.

Kind regards,

Job

Re: Reaching out to ARIN members about their RPKI INVALID prefixes

[Owen DeLong]

Personally, since all RPKI accomplishes is providing a cryptographically signed 
notation of origin ASNs that hijackers should prepend to their announcements in 
order to create an aura of credibility, I think we should stop throwing 
resources down this rathole.

Owen


> On Sep 18, 2018, at 4:56 AM, nusenu  wrote:
> 
> Dear NANOG,
> 
> when I approached ARIN about how they feel about reaching out to their 
> members about
> prefixes that are unreachable in a route origin validation (ROV) environment,
> John Curran (CEO ARIN) referred me to you (see email bellow - quoted with 
> permission).
> 
> The question I asked ARIN was specifically:
>> Would you be open to reach out to your affected members to inform them about
>> their affected IP prefixes?
> 
> John Curran (CEO ARIN) wrote:
>> If there is evidence of community
>> Interest, then ARIN can conduct a community consultation to determine
>> our best role in this area, but you first should encourage discussion
>> within the network operator community at appropriate forums.
> 
> So here is my question to the network operator community in the ARIN region to
> gather if there are any (dis)agreements/opinions about such a notification by 
> ARIN:
> 
> What do you think about the idea that ARIN actively informs their affected 
> members
> about prefixes that are unreachable in an RPKI ROV environment?
> 
> The goal of that outreach/notification would be 
> - to reduce the number of broken legacy ROAs from the past
> - reduce the negative impact on reachability of affected members.
> 
> looking forward to receiving your feedback!
> 
> kind regards,
> nusenu
> 
> 
> 
> 
> [1] https://medium.com/@nusenu/towards-cleaning-up-rpki-invalids-d69b03ab8a8c
> 
> John Curran wrote:
>> Subject: Reaching out to ARIN members about their RPKI INVALID prefixes
>> 
>> Nusenu -
>> 
>> Thank you for writing us - the project (and Medium post on same) are
>> quite interesting.
>> 
>> I think you’ve got several options for pursuing your objectives,
>> including –
>> 
>> 1) Reaching out to parties that already track and report on Internet
>> routing hygiene (e.g. Geoff Huston at http://bgp.potaroo.net, the
>> RPKI validator team at RIPE, the NIST RPKI Deployment monitor -
>> https://rpki-monitor.antd.nist.gov) to see if of them would like to
>> report on this information and/or contact those with invalids)
>> 
>> 2) Raising the issue in the ARIN region via the NANOG operator forum
>> - this would make an excellent lightening talk for you (or someone
>> else familiar with it already attending) to speak about at the
>> upcoming NANOG Vancouver meeting.  If there is evidence of community
>> Interest, then ARIN can conduct a community consultation to determine
>> our best role in this area, but you first should encourage discussion
>> within the network operator community at appropriate forums.  It is
>> not appropriate for ARIN staff to be proposing this additional role
>> for the organization, as we within the ARIN staff follow community
>> direction rather than set it.
>> 
>> Thanks! /John
>> 
>> John Curran President and CEO ARIN
>> 
> 
> 
> 
> -- 
> https://twitter.com/nusenu_
> https://mastodon.social/@nusenu
> 

RE: Console Servers

[Ryan Hamel]

I just use a Raspberry Pi with USB to Serial adapters or old servers with 
PCI(-E) 8 port serial cards. They make it so easy to adapt to any environment, 
and it phones home to my conserver (https://www.conserver.com/) gateway. The 
total cost for hardware is less than $150.

Ryan

From: NANOG  On Behalf Of Christopher Morrow
Sent: Tuesday, September 18, 2018 9:04 AM
To: Sameer Khosla 
Cc: nanog list 
Subject: Re: Console Servers

a vote for (so far so good) the nodegrid ZPE devices.

On Tue, Sep 18, 2018 at 8:54 AM Sameer Khosla 
mailto:skho...@neutraldata.com>> wrote:
My favorite are the lantronix SLC console servers.  Fairly bullet-proof, they 
are one of those devices that just work.  Can usually be picked up used ~$300 
for 32 or 48 port varieties in good condition if you aren’t in the biggest 
hurry.

Sk.


From: NANOG mailto:nanog-boun...@nanog.org>> On Behalf 
Of Alan Hannan
Sent: Tuesday, September 18, 2018 9:37 AM
To: NANOG mailto:nanog@nanog.org>>
Subject: Console Servers

I'd like your input on suggestions for an alternate serial port manager.

Long ago I used Cisco 2511/2611 and was fairly happy.  A little later I used 
portmaster and was less so.  Recently I've been using Opengear and they work 
fairly well but the price is fairly high.   I use the CM7100 and IM7100.

General specs I'm looking for are:

 * 8 to 48 or more rs232 serial ports on rj45
 * nice-to-have software selectable pinouts (cisco v. straight)
 * gig-e ethernet port (100mbps ok)
 * 1U form factor
 * redundant AC power
 * access physical serial connections via local port #
 * access physical serial connections via local IP alias (nice to have)

Can you recommend a serial port server/concentrator that I could use in place 
of opengear for a better value and/or lower cost?

I'm just ignorant about the current market for serial port concentrators and so 
far web searches have not revealed ideas, so your input is appreciated!

Thanks!

-alan

RE: Console Servers

[Matthew Huff]

If anyone is looking for a product that is reasonably priced and is still being 
produced/update, the ADVA Optical (aka MRV, aka Xyplex) console servers still 
work great

https://www.advaoptical.com/en/products/network-infrastructure-assurance/lx-series

From their specs:
4, 8, 16, 32 and 48 serial ports
V.92 modem option
Single or dual power
120-240VAC, 50/60Hz: 0.5A per system
36-72VDC dual feed: 0.75A per system
2 x Ethernet
NEBS Level 3 certified

Re: Console Servers

[Christopher Morrow]

a vote for (so far so good) the nodegrid ZPE devices.

On Tue, Sep 18, 2018 at 8:54 AM Sameer Khosla 
wrote:

> My favorite are the lantronix SLC console servers.  Fairly bullet-proof,
> they are one of those devices that just work.  Can usually be picked up
> used ~$300 for 32 or 48 port varieties in good condition if you aren’t in
> the biggest hurry.
>
>
>
> Sk.
>
>
>
>
>
> *From:* NANOG  *On Behalf Of *Alan Hannan
> *Sent:* Tuesday, September 18, 2018 9:37 AM
> *To:* NANOG 
> *Subject:* Console Servers
>
>
>
> I'd like your input on suggestions for an alternate serial port manager.
>
>
>
> Long ago I used Cisco 2511/2611 and was fairly happy.  A little later I
> used portmaster and was less so.  Recently I've been using Opengear and
> they work fairly well but the price is fairly high.   I use the CM7100 and
> IM7100.
>
>
>
> General specs I'm looking for are:
>
>
>
>  * 8 to 48 or more rs232 serial ports on rj45
>
>  * nice-to-have software selectable pinouts (cisco v. straight)
>
>  * gig-e ethernet port (100mbps ok)
>
>  * 1U form factor
>
>  * redundant AC power
>
>  * access physical serial connections via local port #
>
>  * access physical serial connections via local IP alias (nice to have)
>
>
>
> Can you recommend a serial port server/concentrator that I could use in
> place of opengear for a better value and/or lower cost?
>
>
>
> I'm just ignorant about the current market for serial port concentrators
> and so far web searches have not revealed ideas, so your input is
> appreciated!
>
>
>
> Thanks!
>
>
>
> -alan
>

Re: Massive Price Increase for X-conns at Telehouse Chelsea, NYC

[Brandon Butterworth]

On Tue Sep 18, 2018 at 08:19:35AM +, Scott Christopher wrote:
> Hank Nussbacher wrote:
> 
> > On 18/09/2018 08:02, Christopher Morrow wrote: 
> >> 
> >> it's funny/possible that x-connect costs affect where peering appears
> >> in the landscape, right?> Not this time.  Just price gouging since moving 
> >> a number of cabinets
> > to a different location is a nightmare.
> Sure - but at least they have competitors.
> 
> Look at prices from telecoms like China's CN1. Would you rather have
> prices set by  government-controlled monopolies, or by private
> competition?
> --S.C.

It's more like a loose cartel with some leading to see
how far they can push it and the rest following in step. As long
as they don't go too fast nobody will see a large enough difference
to be worth changing location.

Equinix were a leader in bringing this to the UK, they have said they
want to get the UK charges to US levels (so >10x increase still to
come). US pricing already matches metro waves so we face paying
twice the cost of the wave to the DCs for the short interconnects.

Telehouse (UK) was one of the good ones with no MRC, the risers got
full due to the popularity of no MRCs (they sold out of rack
space repeatedly too). They started charging but I can't attribute
the growing empty rack space to that, more likely AWS is the cause of
that and a driver for increasing xcon fees to make up revenue.

brandon 

RE: Console Servers

[Sameer Khosla]

My favorite are the lantronix SLC console servers.  Fairly bullet-proof, they 
are one of those devices that just work.  Can usually be picked up used ~$300 
for 32 or 48 port varieties in good condition if you aren’t in the biggest 
hurry.

Sk.


From: NANOG  On Behalf Of Alan Hannan
Sent: Tuesday, September 18, 2018 9:37 AM
To: NANOG 
Subject: Console Servers

I'd like your input on suggestions for an alternate serial port manager.

Long ago I used Cisco 2511/2611 and was fairly happy.  A little later I used 
portmaster and was less so.  Recently I've been using Opengear and they work 
fairly well but the price is fairly high.   I use the CM7100 and IM7100.

General specs I'm looking for are:

 * 8 to 48 or more rs232 serial ports on rj45
 * nice-to-have software selectable pinouts (cisco v. straight)
 * gig-e ethernet port (100mbps ok)
 * 1U form factor
 * redundant AC power
 * access physical serial connections via local port #
 * access physical serial connections via local IP alias (nice to have)

Can you recommend a serial port server/concentrator that I could use in place 
of opengear for a better value and/or lower cost?

I'm just ignorant about the current market for serial port concentrators and so 
far web searches have not revealed ideas, so your input is appreciated!

Thanks!

-alan

Re: Console Servers

[Tim Pozar]

I have been deploying Cyclades TS3000 boxes that I can sometimes find
for about $75 each on eBay.  The down side is the firmware is a bit old
so the SSH daemon doesn't really support current ciphers.  The other
downside is the CLI ia a bit cumbersome.

Tim

On 9/18/18 8:43 AM, Andrew Latham wrote:
> Alan
> 
> There are maybe too many options out there. The used Cyclades are the
> lowest cost entry point. An ideal solution might
> be https://freetserv.github.io/ but some assembly required. I have
> Lantronix OOB solutions in my lab. Most modern servers come with some
> SOL options so I will assume this is for networking equipment. The
> modern HTML5 interfaces are great and really do drop all the legacy Java
> requirements.
> 
> On Tue, Sep 18, 2018 at 8:38 AM Alan Hannan  > wrote:
> 
> I'd like your input on suggestions for an alternate serial port manager.
> 
> Long ago I used Cisco 2511/2611 and was fairly happy.  A little
> later I used portmaster and was less so.  Recently I've been using
> Opengear and they work fairly well but the price is fairly high.   I
> use the CM7100 and IM7100.
> 
> General specs I'm looking for are:
> 
>  * 8 to 48 or more rs232 serial ports on rj45
>  * nice-to-have software selectable pinouts (cisco v. straight)
>  * gig-e ethernet port (100mbps ok)
>  * 1U form factor
>  * redundant AC power
>  * access physical serial connections via local port #
>  * access physical serial connections via local IP alias (nice to have)
> 
> Can you recommend a serial port server/concentrator that I could use
> in place of opengear for a better value and/or lower cost?
> 
> I'm just ignorant about the current market for serial port
> concentrators and so far web searches have not revealed ideas, so
> your input is appreciated!
> 
> Thanks!
> 
> -alan
> 
> 
> 
> -- 
> - Andrew "lathama" Latham -

Re: Console Servers

[Andrew Latham]

Alan

There are maybe too many options out there. The used Cyclades are the
lowest cost entry point. An ideal solution might be
https://freetserv.github.io/ but some assembly required. I have Lantronix
OOB solutions in my lab. Most modern servers come with some SOL options so
I will assume this is for networking equipment. The modern HTML5 interfaces
are great and really do drop all the legacy Java requirements.

On Tue, Sep 18, 2018 at 8:38 AM Alan Hannan  wrote:

> I'd like your input on suggestions for an alternate serial port manager.
>
> Long ago I used Cisco 2511/2611 and was fairly happy.  A little later I
> used portmaster and was less so.  Recently I've been using Opengear and
> they work fairly well but the price is fairly high.   I use the CM7100 and
> IM7100.
>
> General specs I'm looking for are:
>
>  * 8 to 48 or more rs232 serial ports on rj45
>  * nice-to-have software selectable pinouts (cisco v. straight)
>  * gig-e ethernet port (100mbps ok)
>  * 1U form factor
>  * redundant AC power
>  * access physical serial connections via local port #
>  * access physical serial connections via local IP alias (nice to have)
>
> Can you recommend a serial port server/concentrator that I could use in
> place of opengear for a better value and/or lower cost?
>
> I'm just ignorant about the current market for serial port concentrators
> and so far web searches have not revealed ideas, so your input is
> appreciated!
>
> Thanks!
>
> -alan
>


-- 
- Andrew "lathama" Latham -

Re: Console Servers

[Louis Kowolowski]

++ for Opengear. Been happily using them for >10yrs.


> On Sep 18, 2018, at 9:26 AM, Merritt, Channing via NANOG  
> wrote:
> 
> Look into OpenGear, we’ve tested out a couple different products that we’ve 
> implemented in remote offices to replace our 2800’s.
>  
>  
> From: NANOG  On Behalf Of Mike Hammett
> Sent: Tuesday, September 18, 2018 9:49 AM
> To: Alan Hannan 
> Cc: NANOG 
> Subject: [EXTERNAL] Re: Console Servers
>  
> I'm deploying new to me Cisco 2811s for console and OOB access.
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> 
> Midwest Internet Exchange
> 
> The Brothers WISP
> 
> From: "Alan Hannan" 
> To: "NANOG" 
> Sent: Tuesday, September 18, 2018 8:36:33 AM
> Subject: Console Servers
> 
> I'd like your input on suggestions for an alternate serial port manager.
>  
> Long ago I used Cisco 2511/2611 and was fairly happy.  A little later I used 
> portmaster and was less so.  Recently I've been using Opengear and they work 
> fairly well but the price is fairly high.   I use the CM7100 and IM7100.
>  
> General specs I'm looking for are:
>  
>  * 8 to 48 or more rs232 serial ports on rj45
>  * nice-to-have software selectable pinouts (cisco v. straight)
>  * gig-e ethernet port (100mbps ok)
>  * 1U form factor
>  * redundant AC power
>  * access physical serial connections via local port #
>  * access physical serial connections via local IP alias (nice to have)
>  
> Can you recommend a serial port server/concentrator that I could use in place 
> of opengear for a better value and/or lower cost?
>  
> I'm just ignorant about the current market for serial port concentrators and 
> so far web searches have not revealed ideas, so your input is appreciated!
>  
> Thanks!
>  
> -alan

--
Louis Kowolowskilou...@cryptomonkeys.org
Cryptomonkeys:   http://www.cryptomonkeys.com/

Making life more interesting for people since 1977

Re: Console Servers

[Matt Harris]

I'm a big fan of Raritan's DSX2 gear.  Access to serial via ssh or web
interface, and the web interface is HTML5, not Java, which is a big
advantage if you ever want to use that.  I use a bunch of them in
production as well and they've been rock solid when I've needed them for
managing Cisco, Juniper, Ubiquiti, and other gear via serial.

Take care,
Matt

Re: Console Servers

[William Herrin]

On Tue, Sep 18, 2018 at 9:36 AM, Alan Hannan  wrote:
> Long ago I used Cisco 2511/2611 and was fairly happy.

On Tue, Sep 18, 2018 at 9:49 AM, Mike Hammett  wrote:

> I'm deploying new to me Cisco 2811s for console and OOB access.
>

Agree. 2811, 2850s and 3845's are dirt cheap on ebay, the nm-32a's (and
HWIC-16a's) work just like you remember in the 2611s and the 2800 series
has enough processor and a new enough IOS to handle ssh acceptably.

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

RE: Console Servers

[Merritt, Channing via NANOG]

Look into OpenGear, we've tested out a couple different products that we've 
implemented in remote offices to replace our 2800's.





From: NANOG  On Behalf Of Mike Hammett
Sent: Tuesday, September 18, 2018 9:49 AM
To: Alan Hannan 
Cc: NANOG 
Subject: [EXTERNAL] Re: Console Servers



I'm deploying new to me Cisco 2811s for console and OOB access.



-
Mike Hammett
Intelligent Computing Solutions

Midwest Internet Exchange

The Brothers WISP


  _

From: "Alan Hannan" mailto:a...@routingloop.com>>
To: "NANOG" mailto:nanog@nanog.org>>
Sent: Tuesday, September 18, 2018 8:36:33 AM
Subject: Console Servers

I'd like your input on suggestions for an alternate serial port manager.



Long ago I used Cisco 2511/2611 and was fairly happy.  A little later I used 
portmaster and was less so.  Recently I've been using Opengear and they work 
fairly well but the price is fairly high.   I use the CM7100 and IM7100.



General specs I'm looking for are:



 * 8 to 48 or more rs232 serial ports on rj45

 * nice-to-have software selectable pinouts (cisco v. straight)

 * gig-e ethernet port (100mbps ok)

 * 1U form factor

 * redundant AC power

 * access physical serial connections via local port #

 * access physical serial connections via local IP alias (nice to have)



Can you recommend a serial port server/concentrator that I could use in place 
of opengear for a better value and/or lower cost?



I'm just ignorant about the current market for serial port concentrators and so 
far web searches have not revealed ideas, so your input is appreciated!



Thanks!



-alan

Reaching out to ARIN members about their RPKI INVALID prefixes

[nusenu]

Dear NANOG,

when I approached ARIN about how they feel about reaching out to their members 
about
prefixes that are unreachable in a route origin validation (ROV) environment,
John Curran (CEO ARIN) referred me to you (see email bellow - quoted with 
permission).

The question I asked ARIN was specifically:
> Would you be open to reach out to your affected members to inform them about
> their affected IP prefixes?

John Curran (CEO ARIN) wrote:
> If there is evidence of community
> Interest, then ARIN can conduct a community consultation to determine
> our best role in this area, but you first should encourage discussion
> within the network operator community at appropriate forums.

So here is my question to the network operator community in the ARIN region to
gather if there are any (dis)agreements/opinions about such a notification by 
ARIN:

What do you think about the idea that ARIN actively informs their affected 
members
about prefixes that are unreachable in an RPKI ROV environment?

The goal of that outreach/notification would be 
- to reduce the number of broken legacy ROAs from the past
- reduce the negative impact on reachability of affected members.

looking forward to receiving your feedback!

kind regards,
nusenu




[1] https://medium.com/@nusenu/towards-cleaning-up-rpki-invalids-d69b03ab8a8c

John Curran wrote:
> Subject: Reaching out to ARIN members about their RPKI INVALID prefixes
> 
> Nusenu -
> 
> Thank you for writing us - the project (and Medium post on same) are
> quite interesting.
> 
> I think you’ve got several options for pursuing your objectives,
> including –
> 
> 1) Reaching out to parties that already track and report on Internet
> routing hygiene (e.g. Geoff Huston at http://bgp.potaroo.net, the
> RPKI validator team at RIPE, the NIST RPKI Deployment monitor -
> https://rpki-monitor.antd.nist.gov) to see if of them would like to
> report on this information and/or contact those with invalids)
> 
> 2) Raising the issue in the ARIN region via the NANOG operator forum
> - this would make an excellent lightening talk for you (or someone
> else familiar with it already attending) to speak about at the
> upcoming NANOG Vancouver meeting.  If there is evidence of community
> Interest, then ARIN can conduct a community consultation to determine
> our best role in this area, but you first should encourage discussion
> within the network operator community at appropriate forums.  It is
> not appropriate for ARIN staff to be proposing this additional role
> for the organization, as we within the ARIN staff follow community
> direction rather than set it.
> 
> Thanks! /John
> 
> John Curran President and CEO ARIN
> 



-- 
https://twitter.com/nusenu_
https://mastodon.social/@nusenu



signature.asc
Description: OpenPGP digital signature

Re: Massive Price Increase for X-conns at Telehouse Chelsea, NYC

[Scott Christopher]

Hank Nussbacher wrote:

> On 18/09/2018 08:02, Christopher Morrow wrote: 
>> 
>> it's funny/possible that x-connect costs affect where peering appears
>> in the landscape, right?> Not this time.  Just price gouging since moving a 
>> number of cabinets
> to a different location is a nightmare.
Sure - but at least they have competitors.

Look at prices from telecoms like China's CN1. Would you rather have
prices set by  government-controlled monopolies, or by private
competition?
--S.C.

Re: [proj-bgp] adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor?

[Montgomery, Douglas (Fed)]

Michel,

First, thanks for your continued support as a taxpayer.

Second, in general our mission is limited to supporting the development and 
promulgation of consensus standards and the development of test / measurement 
methods and guidance to accelerate their adoption.   In particular we are not 
well positioned to provide operational Internet services of the nature you 
describe.

Of course what you describe would not be hard to do if some commercial or other 
organization wished to do so  with the following caveats:

1.  You should follow the discussion of 
draft-ietf-sidrops-validating-bgp-speaker which proposed standardizing an 
approach to doing what you suggest.  Many on this thread think that it is a 
counterproductive idea to do this.  See discussion starting here:

https://mailarchive.ietf.org/arch/msg/sidrops/6lDz5dI-jg-OhpGR4xKRZ6lYZRA

2. There are some legal issues regarding the redistribution of machine readable 
RPKI data/results to third parties.  See below section 5 Prohibited Conduct:

https://www.arin.net/resources/rpki/rpa.pdf


What we can do is continue to contribute to the development of standards, 
produce prototypes and test and measurement tools and publish deployment 
guidance to help foster adoption.  For example see the follow draft publication:
https://www.nccoe.nist.gov/projects/building-blocks/secure-inter-domain-routing

You mention other suggestions of how we can improve test and measurement 
services.  We welcome all input on that.  Maybe contact me off list and we can 
discuss the other ideas.


Thanks,
dougm
--
Doug Montgomery, Manager Internet  & Scalable Systems Research @ NIST
 

On 9/17/18, 11:04 PM, "Michel Py"  wrote:

Doug,

> Montgomery, Douglas wrote :
> The new monitor has significant additions in the areas of diagnostics, 
and highlights issues of
> interest such as path / customer cone analysis of prefixes that cover 
invalid originations.

Thanks for all the work. More visibility will help. I have made some 
private suggestions to how you could enhance the service, and I would add one :
provide a BGP feed available to the public with invalid RPKI prefixes with 
a distinct BGP community describing why the prefix is invalid.

We are in an impossible situation where ISPs don't want to discard invalid 
RPKI prefixes because they can't deal with the customer backshlash of doing it; 
nothing to gain, money to lose. Money wins.

There is another side of this coin, though : you are a government employee. 
I pay you.
As a taxpayer, I think the US governement should provide a better service 
to US companies with theRPKI collected data. Analysis without action is 
interesting, but not always federal funding.

Best regards,

Michel.

TSI Disclaimer:  This message and any files or text attached to it are 
intended only for the recipients named above and contain information that may 
be confidential or privileged. If you are not the intended recipient, you must 
not forward, copy, use or otherwise disclose this communication or the 
information contained herein. In the event you have received this message in 
error, please notify the sender immediately by replying to this message, and 
then delete all copies of it from your system. Thank you!...

Re: Console Servers

[Christopher E. Brown]

2811DC or 2811AC
NM32
modem module
4 octals
32port RJ45 bulkhead



On 9/18/18 05:49, Mike Hammett wrote:
> I'm deploying new to me Cisco 2811s for console and OOB access.
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> Midwest Internet Exchange 
> 
> The Brothers WISP 
> 
> 
> *From: *"Alan Hannan" 
> *To: *"NANOG" 
> *Sent: *Tuesday, September 18, 2018 8:36:33 AM
> *Subject: *Console Servers
> 
> I'd like your input on suggestions for an alternate serial port manager.
> 
> Long ago I used Cisco 2511/2611 and was fairly happy.  A little later I
> used portmaster and was less so.  Recently I've been using Opengear and
> they work fairly well but the price is fairly high.   I use the CM7100
> and IM7100.
> 
> General specs I'm looking for are:
> 
>  * 8 to 48 or more rs232 serial ports on rj45
>  * nice-to-have software selectable pinouts (cisco v. straight)
>  * gig-e ethernet port (100mbps ok)
>  * 1U form factor
>  * redundant AC power
>  * access physical serial connections via local port #
>  * access physical serial connections via local IP alias (nice to have)
> 
> Can you recommend a serial port server/concentrator that I could use in
> place of opengear for a better value and/or lower cost?
> 
> I'm just ignorant about the current market for serial port concentrators
> and so far web searches have not revealed ideas, so your input is
> appreciated!
> 
> Thanks!
> 
> -alan
> 


-- 

Christopher E. Brown  desk (907) 550-8393
 cell (907) 632-8492
IP Engineer - ACS

Re: Console Servers

[Saku Ytti]

On Tue, 18 Sep 2018 at 16:39, Alan Hannan  wrote:

> Long ago I used Cisco 2511/2611 and was fairly happy.  A little later I used 
> portmaster and was less so.  Recently I've been using Opengear and they work 
> fairly well but the price is fairly high.   I use the CM7100 and IM7100.

Out of curiosity, how do you connect them? I see quotes around
200USD/MRC for ethernet in US, implying 12kUSD 5 year cost on just
connectivity, add rack rental, and power and Opengear price is maybe
10% of TCO?

Personally I still prefer Cisco, as not to have new operating system
to automate. Add conserver to connect persistently to each console
port, so that you get persistent logs from console to your NMS, and so
that you can multiplex your console sessions.
It's hard to recover the CAPEX benefit if you need OOB platform
specific OPEX costs.

-- 
  ++ytti

Re: Console Servers

[Alain Hebert]

What we did (and it fits our needs)

    SeaLevel (SeaLink Familly) with a Zotak.

    We got both Win/Linux/BSD debugging/monitoring station (with 2 
1Gbps, 1 MGMT 1 Mirror) and up to 16 serials ports in 1U.


    ( With some DYI )

    I'm sure you can get a better density if you check with them.

-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

On 09/18/18 09:36, Alan Hannan wrote:

I'd like your input on suggestions for an alternate serial port manager.

Long ago I used Cisco 2511/2611 and was fairly happy.  A little later 
I used portmaster and was less so. Recently I've been using Opengear 
and they work fairly well but the price is fairly high.   I use the 
CM7100 and IM7100.


General specs I'm looking for are:

 * 8 to 48 or more rs232 serial ports on rj45
 * nice-to-have software selectable pinouts (cisco v. straight)
 * gig-e ethernet port (100mbps ok)
 * 1U form factor
 * redundant AC power
 * access physical serial connections via local port #
 * access physical serial connections via local IP alias (nice to have)

Can you recommend a serial port server/concentrator that I could use 
in place of opengear for a better value and/or lower cost?


I'm just ignorant about the current market for serial port 
concentrators and so far web searches have not revealed ideas, so your 
input is appreciated!


Thanks!

-alan

Re: Console Servers

[Mike Hammett]

I'm deploying new to me Cisco 2811s for console and OOB access. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Alan Hannan"  
To: "NANOG"  
Sent: Tuesday, September 18, 2018 8:36:33 AM 
Subject: Console Servers 



I'd like your input on suggestions for an alternate serial port manager. 


Long ago I used Cisco 2511/2611 and was fairly happy. A little later I used 
portmaster and was less so. Recently I've been using Opengear and they work 
fairly well but the price is fairly high. I use the CM7100 and IM7100. 


General specs I'm looking for are: 


* 8 to 48 or more rs232 serial ports on rj45 
* nice-to-have software selectable pinouts (cisco v. straight) 
* gig-e ethernet port (100mbps ok) 
* 1U form factor 
* redundant AC power 
* access physical serial connections via local port # 
* access physical serial connections via local IP alias (nice to have) 


Can you recommend a serial port server/concentrator that I could use in place 
of opengear for a better value and/or lower cost? 


I'm just ignorant about the current market for serial port concentrators and so 
far web searches have not revealed ideas, so your input is appreciated! 


Thanks! 


-alan 

RE: Console Servers

[Stan Ouchakov]

Depending on the budget, refurbished Cyclades off ebay do the job well. Very 
solid and proven products, we still run few dated from 2003 …

-Stan

From: NANOG  On Behalf Of Alan Hannan
Sent: Tuesday, September 18, 2018 9:37 AM
To: NANOG 
Subject: Console Servers

I'd like your input on suggestions for an alternate serial port manager.

Long ago I used Cisco 2511/2611 and was fairly happy.  A little later I used 
portmaster and was less so.  Recently I've been using Opengear and they work 
fairly well but the price is fairly high.   I use the CM7100 and IM7100.

General specs I'm looking for are:

 * 8 to 48 or more rs232 serial ports on rj45
 * nice-to-have software selectable pinouts (cisco v. straight)
 * gig-e ethernet port (100mbps ok)
 * 1U form factor
 * redundant AC power
 * access physical serial connections via local port #
 * access physical serial connections via local IP alias (nice to have)

Can you recommend a serial port server/concentrator that I could use in place 
of opengear for a better value and/or lower cost?

I'm just ignorant about the current market for serial port concentrators and so 
far web searches have not revealed ideas, so your input is appreciated!

Thanks!

-alan

Console Servers

[Alan Hannan]

I'd like your input on suggestions for an alternate serial port manager.

Long ago I used Cisco 2511/2611 and was fairly happy.  A little later I
used portmaster and was less so.  Recently I've been using Opengear and
they work fairly well but the price is fairly high.   I use the CM7100 and
IM7100.

General specs I'm looking for are:

 * 8 to 48 or more rs232 serial ports on rj45
 * nice-to-have software selectable pinouts (cisco v. straight)
 * gig-e ethernet port (100mbps ok)
 * 1U form factor
 * redundant AC power
 * access physical serial connections via local port #
 * access physical serial connections via local IP alias (nice to have)

Can you recommend a serial port server/concentrator that I could use in
place of opengear for a better value and/or lower cost?

I'm just ignorant about the current market for serial port concentrators
and so far web searches have not revealed ideas, so your input is
appreciated!

Thanks!

-alan

Re: Massive Price Increase for X-conns at Telehouse Chelsea, NYC

[Radu-Adrian Feurdean]

On Mon, Sep 17, 2018, at 17:30, Daniel Corbe wrote:
> $300 MRC for a once-off cross connect isn’t unreasonable.   There’s costs  

300$ would be (at the limit of) reasonable *M*RC for a 12 FO cable (= 6 duplex 
XCOs). Or the one-off (*N*RC) for one XCO. That's actually close to the rates 
we have on this part of the ocean. 

300$ for one XCO (2 FO) is "robbery in organised band" (word-by-word 
translation of a french legal term). You can get metro waves (some 10-20 km 
distance) for lower than that (again, on my part of the ocean).

--
R-A.F.

Re: netflix OCA in a CG-NAT world

[Radu-Adrian Feurdean]

On Mon, Sep 17, 2018, at 17:48, Jared Mauch wrote:

> I also strongly suggest you look at how to get native IPv6 from your 
> clients behind the CG-NAT rolled out.  I know many folks have had issues 

Getting IPv6 to your customers is good, but they still have to use it. 

If I look at my stats, I can see that the IPv4:IPv6 ratio for Netflix is 5.5:1, 
while for Google it's 1.1:1 and for Facebook 1.33:1 (peak-time ratios, when 
traffic is mostly from residential users) . The best explanation I could get is 
people may use Netflix from devices that do not support IPv6, such as some/most 
(not-so-old) Smart TVs. There's also the issue of some brain-dead wifi APs that 
filter or severely limit traffic required for proper IPv6 operation (multicast 
comes to my mind).

I'm not even mentioning the situation in the "pro"/"enterprise" world (much 
worse) since it doesn't (or it's not supposed to) generate much Netflix traffic 
(still, during the morning IPv4:IPv6 ratio for Netflix can go as low as 3.5:1).

--
R-A.F.

Re: Massive Price Increase for X-conns at Telehouse Chelsea, NYC

[Hank Nussbacher]

On 18/09/2018 08:02, Christopher Morrow wrote:
>
>
> On Mon, Sep 17, 2018 at 9:44 PM Hank Nussbacher  > wrote:
>
> On 17/09/2018 23:26, Phil Lavin wrote:
> >> $350/mo seems to be standard. Our DCs are at $250.    Seems
> more like they held onto out of date pricing for a long time then
> realized it.
> > For what it's worth, Telehouse London is around 30 USD/month for
> an x-connect within the same building. Our US datacentre (not
> Telehouse) on the other hand is around 200 USD/month. It's always
> felt disproportionally expensive but maybe those kind of prices
> are expected for the North America region.
> Current list price for 10G Xconnect at the major colo site in
> Israel is
> $5840/month.   Discounts are available :-)
> Keep complaining about $350/mo costs.  You have no idea how lucky
> you are.
>
>
> it's funny/possible that x-connect costs affect where peering appears
> in the landscape, right? 

Not this time.  Just price gouging since moving a number of cabinets to
a different location is a nightmare.


-Hank