Re: Comcast? Layer2 / ELAN

[TJ Trout]

I would request an on-site rfc test that should clear things up quickly

On Fri, Oct 29, 2021 at 11:17 AM Joe Carroll  wrote:

> Greetings Fellow Nanog'ers
>
> Are there any Comcast engineers in the group that could help to sort out a
> 10GB layer2 ELAN issue in Florida?
>
> We are short of cancelling this circuit that has been in for a couple of
> days.
>
> We cannot pass above 1GB on this circuit...  10GB SFPs on both ends, 10GB
> price, 1GB service...   the team refuses to investigate, dispatch, or
> otherwise act in any way that is customer oriented.
>
> Regards,
> -Joe
>

Re: Need for historical prefix blacklist (`rogue' prefixes) information

[Amir Herzberg]

(this is an answer to Matthew but also with a question to all NANOGers, see
below, under `is this true?')

Matthew, thanks for your feedback on our paper - always welcome - although
the email I sent wasn't about ROV++ but on our need for historical data on
blacklisted prefixes. (our use is not limited to ROV++ as we are
investigating other attacks and defenses, including our own and proposed by
others).

Anyway let me briefly respond to the issues you raised.

I read your paper. I note "ROV provides disappointing security benefits". I
> think we all know that ROV provides very little in the way of security from
> deliberate hijack without the protection of BGPsec as you later point out
> in your paper.
>

I mostly agree. Not fully, since, actually, there _is_ an advantage to an
attacker to perform prefix-hijack (and esp. subprefix hijack) compared to
path manipulation attacks (which ROV fails against). Basically the reason
is exactly the fact that most paths are short, as you mention. [E.g., see
our `path-end' paper in SigComm'16]


> What you seem to have failed to understand is that most traffic hijacks
> on the internet are not malicious in nature, they are "fat finger" incidents
>

Apparently, I somehow caused you to believe that I think that most hijacks
are due to attacks; never my intention (or belief). I'm well aware that
errors are more common than attacks.


> where someone has accidentally announced something they did not intend to,
> either because of faulty software (the infamous "BGP optimizer") or someone
> leaking internal "blocks" such as the Pakistan/YouTube incident
>

Let's not mix route-leakage here... (but of course, that incident wasn't a
leakage but a hijack - probably meant to be only within Pakistan, so I
guess you could say it was also leakage)


> -- certifying the origin of a prefix allows you to mitigate most of this
> as the origin AS will change. Anyone seen deliberately causing hijacks is
> likely to be depeered very quickly -- commercial pressure rather than
> technical.
>

Now, is this true?  I'm really curious to know if all/most NANOGers agree
that an AS deliberately causing hijacks would be very quickly depeered.

My concern is that providers may not disconnect a customer AS (or even a
peer) `just' due to what may be an intentional hijack. Indeed one advantage
of hijack (cf. to more advanced attacks) is that it may be _excused_ as a
mistake, and there were some (in)famous incidents... And I suspect
depeering is not such a quick response by an admin suspecting foul play;
there are contracts and payments involved... Am I wrong?

>
> Likewise, the core purpose of ROV is not to secure the entire address
> space. It is (as I understand it) to prevent *your* address space from
> being stolen, and
>

Matthew, I know you know this stuff, so I think you mis-typed here, no?
Obviously, you protect your address space by publishing ROAs. The purpose
of ROV is _only_


> to prevent your network from being affected by false advertisements.
>

(we agree on that!)


> The superprefix attacks you mention are pretty much theoretical only at
> this time,
>

I really like to do applied research, but sometimes I also do some research
which is more for fun, and I agree these superprefix attacks are probably
not very practical against _announced_ prefixes. Of course, sometimes we
later find these works `for fun' do have practical importance...

And in this case... superprefix attacks may become practical against
_unannounced_ prefixes (with ROA 0), _if_ ROV is widely deployed (making it
ineffective to hijack them by simple prefix hijack). So, there is
motivation to think about them!

btw, superprefix attacks can also allow foiling of feasible-uRPF, you
know... so, again, could be practical.


> because of the maximum prefix length attribute and the nature of peering
> in that networks either tend to be adjacent (therefore very low AS Path) or
> via transit (and most transit providers deploy ROV validation). It's true
> that traffic could be re-routed if the longer prefixes are not advertised
> to all parties, but that would also come under the AS Path length case.
>

I don't quite see how this is relevant to the superprefix attacks; clearly
the attack fails if a more specific prefix is available, but that's
obvious.

>
> Hijacking a prefix is not useful unless you can do something with it,
> either to hand out to customers (in which case, the prefix is going to be
> sufficiently ignored around the internet that it's not practically useful)
> or to engage in denial of service activities in which case there are far
> easier measures to use.
>

Intentional hijacking has different goals, many of which don't require
universal success.

>
>
>> Any help would be appreciated. I'm not sure the list would be interested
>> so I recommend you respond to me privately; if there are useful responses,
>> I could post a summary to the list after few days (of collecting responses,
>> if any).
>>
>
> I would 

Re: Comcast? Layer2 / ELAN

[Livingood, Jason via NANOG]

I’ll reply off-list in a sec

From: NANOG  on 
behalf of Joe Carroll 
Date: Friday, October 29, 2021 at 14:16
To: nanog list 
Subject: Comcast? Layer2 / ELAN

Greetings Fellow Nanog'ers

Are there any Comcast engineers in the group that could help to sort out a 10GB 
layer2 ELAN issue in Florida?

We are short of cancelling this circuit that has been in for a couple of days.

We cannot pass above 1GB on this circuit...  10GB SFPs on both ends, 10GB 
price, 1GB service...   the team refuses to investigate, dispatch, or otherwise 
act in any way that is customer oriented.

Regards,
-Joe

RE: possible rsync validation dos vuln

[Jean St-Laurent via NANOG]

https://www.ncsc.nl/actueel/nieuws/2021/oktober/29/aanstaande-bekendmaking-cvd-procedure-rpki

-Original Message-
From: NANOG  On Behalf Of Niels Bakker
Sent: October 29, 2021 2:01 PM
To: nanog@nanog.org
Subject: Re: possible rsync validation dos vuln

* nanog@nanog.org (Jean St-Laurent via NANOG) [Fri 29 Oct 2021, 19:57 CEST]:
>The link doesn't work. 404
>
>https://www.ncsc.nl/actueel/nieuws/2021/oktober/29/aanstaande-bekendm

| X-Mailer: Microsoft Outlook 16.0

The posted link works fine here but your MUA mangled it so you'll have to do 
some manual work to put the two parts together again. You're missing 
"aking-cvd-procedure-rpki" at the end.


>What are the specs of that possible dos vuln?

¯\_(ツ)_/¯


>Is is reflection or amplification or something else?

Maybe you missed the bit where the actual vulnerabilities are under embargo?


-- Niels.

Comcast? Layer2 / ELAN

[Joe Carroll]

Greetings Fellow Nanog'ers

Are there any Comcast engineers in the group that could help to sort out a
10GB layer2 ELAN issue in Florida?

We are short of cancelling this circuit that has been in for a couple of
days.

We cannot pass above 1GB on this circuit...  10GB SFPs on both ends, 10GB
price, 1GB service...   the team refuses to investigate, dispatch, or
otherwise act in any way that is customer oriented.

Regards,
-Joe

Re: Need for historical prefix blacklist (`rogue' prefixes) information

[Matthew Walster]

On Fri, 29 Oct 2021, 15:55 A Crisan,  wrote:

> Hi Matthew,
> I was reading the above exchange, and I do have a question linked to your
> last affirmation. To give you some context, the last 2021 ENISA report seem
> to suggest that internet traffic is "casually registered" by X actors to
> apply post Retrospective decryption (excerpt below). This would be at odds
> with your (deescalating) affirmation that hijacks are non-malicious and
> they are de-peered quickly, unless you pinpoint complete flux arrest only.
> Are there any reportings/indicators... that look into internet flux
> constant monitoring capabilities/capacities? Thanks.
>

RPKI uses authentication not confidentiality. There is no encryption taking
place, other than the signatures on the certificates etc.

Excerpt from the introduction: "What makes matters worse is that any cipher
> text intercepted by an attacker today can be decrypted by the attacker as
> soon as he has access to a large quantum computer (Retrospective
> decryption).
>

Which do not exist (yet).

Analysis of Advanced Persistent Threats (APT) and Nation State
> capabilities,
>

Buzzwords.

along with whistle blowers’ revelations
>
 have shown that threat actors can and are casually recording all Internet
> traffic in their data centers
>

No they're not. It's just not possible or indeed necessary to duplicate
everything at large scale. Perhaps with a large amount of filtering,
certain flows would be captured, but in the days of pervasive TLS, this
seems less and less worthwhile.

 and that they select encrypted traffic as interesting and worth
> storing.This means that any data encrypted using any of the standard
> public-key systems today will need to be considered compromised once a
> quantum computer exists and there is no way to protect it retroactively,
> because a copy of the ciphertexts in the hands of the attacker. This means
> that data that needs to remain confidential after the arrival of quantum
> computers need to be encrypted with alternative means"
>

None of this is relevant to RPKI (ROV) at all. In fact, it reads like the
fevered dreams of a cyber security research student. What's your point
regarding your message? ROV does not use (nor needs) encryption.

M

Weekly Global IPv4 Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Global IPv4 Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Global IPv4 Routing Table Report   04:00 +10GMT Sat 30 Oct, 2021

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  870998
Prefixes after maximum aggregation (per Origin AS):  330625
Deaggregation factor:  2.63
Unique aggregates announced (without unneeded subnets):  420290
Total ASes present in the Internet Routing Table: 72185
Prefixes per ASN: 12.07
Origin-only ASes present in the Internet Routing Table:   61995
Origin ASes announcing only one prefix:   25559
Transit ASes present in the Internet Routing Table:   10190
Transit-only ASes present in the Internet Routing Table:349
Average AS path length visible in the Internet Routing Table:   4.4
Max AS path length visible:  53
Max AS path prepend of ASN (265020)  50
Prefixes from unregistered ASNs in the Routing Table:   906
Number of instances of unregistered ASNs:   910
Number of 32-bit ASNs allocated by the RIRs:  37687
Number of 32-bit ASNs visible in the Routing Table:   31261
Prefixes from 32-bit ASNs in the Routing Table:  146011
Number of bogon 32-bit ASNs visible in the Routing Table:23
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:412
Number of addresses announced to Internet:   3071684096
Equivalent to 183 /8s, 22 /16s and 46 /24s
Percentage of available address space announced:   83.0
Percentage of allocated address space announced:   83.0
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.5
Total number of prefixes smaller than registry allocations:  289786

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   232859
Total APNIC prefixes after maximum aggregation:   66598
APNIC Deaggregation factor:3.50
Prefixes being announced from the APNIC address blocks:  228100
Unique aggregates announced from the APNIC address blocks:92707
APNIC Region origin ASes present in the Internet Routing Table:   12077
APNIC Prefixes per ASN:   18.89
APNIC Region origin ASes announcing only one prefix:   3441
APNIC Region transit ASes present in the Internet Routing Table:   1700
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 37
Number of APNIC region 32-bit ASNs visible in the Routing Table:   7251
Number of APNIC addresses announced to Internet:  772994432
Equivalent to 46 /8s, 18 /16s and 245 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-151865
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:255120
Total ARIN prefixes after maximum aggregation:   117865
ARIN Deaggregation factor: 2.16
Prefixes being announced from the ARIN address blocks:   255232
Unique aggregates announced from the ARIN address blocks:122364
ARIN Region origin ASes present in the Internet Routing Table:18931
ARIN Prefixes per ASN: 

Re: possible rsync validation dos vuln

[Niels Bakker]

* nanog@nanog.org (Jean St-Laurent via NANOG) [Fri 29 Oct 2021, 19:57 CEST]:

The link doesn't work. 404

https://www.ncsc.nl/actueel/nieuws/2021/oktober/29/aanstaande-bekendm


| X-Mailer: Microsoft Outlook 16.0

The posted link works fine here but your MUA mangled it so you'll have 
to do some manual work to put the two parts together again. You're 
missing "aking-cvd-procedure-rpki" at the end.




What are the specs of that possible dos vuln?


¯\_(ツ)_/¯



Is is reflection or amplification or something else?


Maybe you missed the bit where the actual vulnerabilities are under 
embargo?



-- Niels.

RE: possible rsync validation dos vuln

[Collider]

I looked on english.ncsc.nl's news section (it's the most recently published 
article) and it seems to be referencing OpenBSD's security page as the reason 
this "CVD" doesn't involve the developers and thus isn't really a CVD.

The link is over linelen characters long and it may have gotten truncated.

On 29 October 2021 17:52:09 UTC, Jean St-Laurent via NANOG  
wrote:
>The link doesn't work. 404
>
>https://www.ncsc.nl/actueel/nieuws/2021/oktober/29/aanstaande-bekendm
>
>What are the specs of that possible dos vuln? 
>
>Is is reflection or amplification or something else?
>
>Thanks
>Jean
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

RE: possible rsync validation dos vuln

[Jean St-Laurent via NANOG]

The link doesn't work. 404

https://www.ncsc.nl/actueel/nieuws/2021/oktober/29/aanstaande-bekendm

What are the specs of that possible dos vuln? 

Is is reflection or amplification or something else?

Thanks
Jean

Re: PCH Peering Survey 2021

[Bill Woodcock]

> On Oct 29, 2021, at 6:55 PM, Denis Fondras  wrote:
> Le Fri, Oct 29, 2021 at 01:47:37PM +0200, Bill Woodcock a écrit :
>> If you’re peering with an MLPA route-server, you’re welcome to include just
>> the route-server’s ASN, if that’s easiest, rather than trying to include each
>> of the peer ASNs on the other side of the route-server. Either way is fine.
> 
> I have an agreement with the RS owner (IXP) but not with each participant.
> Should the contractual relationship be true or false ?

Sorry, we should have been more clear about that…  This is just whether a 
bilateral contract exists between the two peering ASes.

We’re looking at multilateral agreements separately, because two ASes may peer 
directly in some locations and via multilateral route-servers elsewhere.

So with that question we just want to know whether there’s a bilateral contract.

Thanks,

-Bill



signature.asc
Description: Message signed with OpenPGP

Re: possible rsync validation dos vuln

[Randy Bush]

> there's a public statement about this from NCSC-NL:
>> https://www.ncsc.nl/actueel/nieuws/2021/oktober/29/aanstaande-bekendmaking-cvd-procedure-rpki

blah blah blah

bottom line.  they gave first notice to devs 4 days before threatened
disclosure.  that they then asked to embargo was just adding insult to
injury.

https://en.wikipedia.org/wiki/Responsible_disclosure

we will remember their names.  like the herzberg incident, "the internet
has two weeks to upgrade all microtiks globally before we intentionally
break it again."

would they do the same to the electric grid or other scada network?  the
internet's openness and kindness has led them to think we can be abused
willy nilly.

we will remember their names.

randy

Re: PCH Peering Survey 2021

[Denis Fondras]

Le Fri, Oct 29, 2021 at 01:47:37PM +0200, Bill Woodcock a écrit :
> If you’re peering with an MLPA route-server, you’re welcome to include just
> the route-server’s ASN, if that’s easiest, rather than trying to include each
> of the peer ASNs on the other side of the route-server. Either way is fine.
> 

I have an agreement with the RS owner (IXP) but not with each participant.
Should the contractual relationship be true or false ?

Re: possible rsync validation dos vuln

[Nick Hilliard]

Barry Greene wrote on 29/10/2021 13:15:
"The NCSC will try to resolve the security problem that you have 
reported in a system within 60 days. Once the problem has been resolved, 
we will decide in consultation whether and how details will be published.”


I would have expected you to council the researchers on responsible 
disclosure principles.


there's a public statement about this from NCSC-NL:


https://www.ncsc.nl/actueel/nieuws/2021/oktober/29/aanstaande-bekendmaking-cvd-procedure-rpki


"In dit proces is een afweging gemaakt om de ontwikkelaar van 
RPKI-client pas later te informeren. Deze afweging is gemaakt op basis 
van het publieke standpunt van deze ontwikkelaars, namelijk steun voor 
‘full disclosure’. De ontwikkelaars van RPKI-client hebben het NCSC 
laten weten dat zij niet akkoord gaan met betrokkenheid onder embargo."


"During this process, a decision was made to inform the developer of 
RPKI-client at a later stage.  This decision was made on the basis of 
the public standpoint of these developers, namely support for 'full 
disclosure.  The developers of RPKI-client have let the NCSC know that 
they do not agree with involvement under embargo."


Looks like the NCSC got confused about OpenBSD's internal security vuln 
management  process, which involves full disclosure on their terms, and 
the way they operate with disclosures from third parties / multiparty 
engagement, which involves co-operation with the disclosing party / CERT 
about mutually acceptable terms, including co-ordinated disclosure, i.e. 
standard industry practice.  Some public clarity from the openbsd people 
would help here.


+ there was a screwup with the rcynic developers.

It's a bit much to claim that the openbsd (+ rcynic) people didn't agree 
with involvement under embargo when the terms were apparently: we're 
releasing details in 4 days and will only tell you what the problem is 
if you agree to this.


Regardless of how this misunderstanding came about, this style of 
approach doesn't form part of an acceptable vulnerability management 
process.


Nick

Re: Need for historical prefix blacklist (`rogue' prefixes) information

[A Crisan]

Hi Matthew,


What you seem to have failed to understand is that most traffic hijacks on
> the internet are not malicious in nature, they are "fat finger" incidents
> where someone has accidentally announced something they did not intend to,
> either because of faulty software (the infamous "BGP optimizer") or someone
> leaking internal "blocks" such as the Pakistan/YouTube incident --
> certifying the origin of a prefix allows you to mitigate most of this as
> the origin AS will change. Anyone seen deliberately causing hijacks is
> likely to be depeered very quickly -- commercial pressure rather than
> technical.
>
>
I was reading the above exchange, and I do have a question linked to your
last affirmation. To give you some context, the last 2021 ENISA report seem
to suggest that internet traffic is "casually registered" by X actors to
apply post Retrospective decryption (excerpt below). This would be at odds
with your (deescalating) affirmation that hijacks are non-malicious and
they are de-peered quickly, unless you pinpoint complete flux arrest only.
Are there any reportings/indicators... that look into internet flux
constant monitoring capabilities/capacities? Thanks.

Excerpt from the introduction: "What makes matters worse is that any cipher
text intercepted by an attacker today can be decrypted by the attacker as
soon as he has access to a large quantum computer (Retrospective
decryption). Analysis of Advanced Persistent Threats (APT) and Nation State
capabilities, along with whistle blowers’ revelations have shown that
threat actors can and are casually recording all Internet traffic in their
data centers and that they select encrypted traffic as interesting and
worth storing.This means that any data encrypted using any of the standard
public-key systems today will need to be considered compromised once a
quantum computer exists and there is no way to protect it retroactively,
because a copy of the ciphertexts in the hands of the attacker. This means
that data that needs to remain confidential after the arrival of quantum
computers need to be encrypted with alternative means"

Best to all,
Dora

Re: possible rsync validation dos vuln

[Nick Hilliard]

Barry Greene wrote on 29/10/2021 13:15:
That only happens if the team has the time to get the fix into the code, 
tested, validated, regressed, and deployed. I would say this is a 
classic example of “ego” to publish overruling established principles.


The University of Twente should explore requiring classes for 
responsible disclosure.


NCSC, it seems you threw out your own policy:

"The NCSC will try to resolve the security problem that you have 
reported in a system within 60 days. Once the problem has been resolved, 
we will decide in consultation whether and how details will be published.”


I would have expected you to council the researchers on responsible 
disclosure principles.


Indeed + also manage the vendor disclosure process in a more 
comprehensive / structured way.


An interesting and worthwhile outcome here would be a presentation on 
how the set of inputs into the sausage factory produced the mess that's 
going to be served for lunch on monday.  I.e. let's use this as an 
opportunity to learn from the mistakes that were made here.


Nick

Re: possible rsync validation dos vuln

[Barry Greene]

> On Oct 29, 2021, at 5:26 PM, Nick Hilliard  wrote:
> 
> Because this didn't happen, we now get to look forward to a weekend of 
> elevated risk, followed by people upending their calendars to handle 
> un-coordinated upgrades on monday morning.


That only happens if the team has the time to get the fix into the code, 
tested, validated, regressed, and deployed. I would say this is a classic 
example of “ego” to publish overruling established principles.

The University of Twente should explore requiring classes for responsible 
disclosure.

NCSC, it seems you threw out your own policy:

"The NCSC will try to resolve the security problem that you have reported in a 
system within 60 days. Once the problem has been resolved, we will decide in 
consultation whether and how details will be published.”

I would have expected you to council the researchers on responsible disclosure 
principles.


signature.asc
Description: Message signed with OpenPGP

Re: Need for historical prefix blacklist (`rogue' prefixes) information

[Matthew Walster]

Hi,

On Fri, 29 Oct 2021 at 00:48, Amir Herzberg  wrote:

> Hi NANOGers, for our research on ROV (and ROV++, our extension, NDSS'21),
> we need access to historical data of blacklisted prefixes (due to spam,
> DDoS, other), as well as suspect-hijacks list (beyond BGPstream which we
> already have).
>

I read your paper. I note "ROV provides disappointing security benefits". I
think we all know that ROV provides very little in the way of security from
deliberate hijack without the protection of BGPsec as you later point out
in your paper.

What you seem to have failed to understand is that most traffic hijacks on
the internet are not malicious in nature, they are "fat finger" incidents
where someone has accidentally announced something they did not intend to,
either because of faulty software (the infamous "BGP optimizer") or someone
leaking internal "blocks" such as the Pakistan/YouTube incident --
certifying the origin of a prefix allows you to mitigate most of this as
the origin AS will change. Anyone seen deliberately causing hijacks is
likely to be depeered very quickly -- commercial pressure rather than
technical.

Likewise, the core purpose of ROV is not to secure the entire address
space. It is (as I understand it) to prevent *your* address space from
being stolen, and to prevent your network from being affected by false
advertisements. The superprefix attacks you mention are pretty much
theoretical only at this time, because of the maximum prefix length
attribute and the nature of peering in that networks either tend to be
adjacent (therefore very low AS Path) or via transit (and most transit
providers deploy ROV validation). It's true that traffic could be re-routed
if the longer prefixes are not advertised to all parties, but that would
also come under the AS Path length case.

Hijacking a prefix is not useful unless you can do something with it,
either to hand out to customers (in which case, the prefix is going to be
sufficiently ignored around the internet that it's not practically useful)
or to engage in denial of service activities in which case there are far
easier measures to use.


> Any help would be appreciated. I'm not sure the list would be interested
> so I recommend you respond to me privately; if there are useful responses,
> I could post a summary to the list after few days (of collecting responses,
> if any).
>

I would strongly encourage engaging with the IETF (
https://datatracker.ietf.org/wg/sidrops/about/ et al) who are much more
likely to be able to point you in the right direction.

Matthew Walster

Re: possible rsync validation dos vuln

[Randy Bush]

i would not be surprised if email to my previous addresses

   ...!uunet!m2xenix!randy
   ...!uunet!oresoft!randy

bounced, making it difficult for these kiddies to reach me.

https://en.wikipedia.org/wiki/Responsible_disclosure

randy

PCH Peering Survey 2021

[Bill Woodcock]

Background:

Five and ten years ago PCH conducted comprehensive global surveys 
characterizing Internet peering agreements. They are the only ones of their 
kind, and are relied upon by legislators and regulators throughout the world to 
understand the Internet interconnection landscape.

Our write-ups of the prior surveys can be found here:

https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2011.pdf 


https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2016/PCH-Peering-Survey-2016.pdf
 


…and video of the NANOG presentation of the 2016 results is here:

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


At the time of the 2011 survey, we committed to repeating the survey every five 
years, to provide time-series data about the direction peering trends take. 
We’re now conducting the third iteration of the survey.

Among other things, the surveys have helped establish a better understanding of 
trends in:

• The increasingly uniform global norms of interconnection
• National preferences within the network operator community for country of 
governing law
• The long tail of small networks which don’t yet support IPv6 routing
• The significance of multilateral peering agreements in the density of the 
interconnection mesh

These findings, particularly the first, have been invaluable in giving 
regulators in the vast majority of the world’s countries a data-driven basis 
for refraining from prescriptively regulating Internet interconnection. They 
have demonstrated in objective terms that the Internet self-regulates in a way 
that’s more globally uniform and closely harmonized than any coordination of 
national regulatory bodies could accomplish.

Participation:

The survey is global in scope, and our goal is to reflect the diversity of 
peering agreements in the world. Your participation ensures that your norms and 
ways of doing business are represented accurately and proportionately in the 
dataset. If you don’t participate, the way you do business will be less 
well-represented in the data, and will seem less normal to regulators and 
policy-makers. We’re interested in large ISPs and small ISPs, ISPs in 
Afghanistan and in Zimbabwe, bilateral agreements and multilateral, private and 
public. Our intent is to be as comprehensive as possible. In 2011, the 
responses we received represented 4,331 networks in 96 countries, or 86% of the 
world’s ISPs at that time. In 2016, responses represented 10,794 networks in 
148 countries, or 60% of the world’s ISPs in 2016. Our aim is to be equally 
inclusive this year.

Since our principal method of soliciting participation is via NOG mailing 
lists, I’m afraid many of you will see this message several times, on different 
lists, for which we apologize.

Privacy:

In 2011 and 2016, we promised to collect the smallest set of data necessary to 
answer the questions, to perform the analysis immediately, and not to retain 
the data after the analysis was accomplished. In that way, we ensured that the 
privacy of respondents was fully protected. We did as we said, no data was 
leaked, and the whole community benefited from the trust that was extended to 
us. We ask for your trust again now as we make the same commitment to protect 
the privacy of all respondents, using the same process as was successfully 
employed the last two times. We are asking for no more data than is absolutely 
necessary. We will perform the analysis immediately upon receiving all of the 
data. We will delete the data once the analysis has been performed.

The Survey:

We would like to know your Autonomous System Number, and the following five 
pieces of information relative to each other AS you peer with:

• Your peer’s ASN (peers only, not upstream transit providers or downstream 
customers)
• Whether a written and signed peering agreement exists (the alternative being 
a less formal arrangement, such as a "handshake agreement")
• Whether the terms are roughly symmetric (the alternative being that they 
describe an agreement with different terms for each of the two parties, such as 
one compensating the other, or one receiving more or fewer than full customer 
routes)
• Whether a jurisdiction of governing law is defined
• Whether IPv6 routes are being exchanged (this year, we’ll still assume that 
IPv4 are)

The easiest way for us to receive the information is as a tab-text or CSV file 
or an Excel spreadsheet, consisting of rows with the following columns:

Your ASN: Integer
Peer ASN: Integer
Written agreement: Boolean  [true,1,yes,y] or [false,0,no,n]
Symmetric: Boolean  [true,1,yes,y] or [false,0,no,n]
Governing Law: ISO 3166 two-digit country-code, or empty
IPv6 Routes: Boolean [true,1,yes,y] or [false,0,no,n]

For instance:

42  

Re: possible rsync validation dos vuln

[Nick Hilliard]

Randy Bush wrote on 29/10/2021 02:03:

received this vuln notice four days before these children intend to
disclose.  so you can guess how inclined to embargo.


The position doesn't seem to be compatible with e.g.


https://www.first.org/global/sigs/vulnerability-coordination/multiparty/FIRST-Multiparty-Vulnerability-Coordination.pdf


At the top of the FIRST list:


1. Establish a strong foundation of processes and relationships

2. Maintain clear and consistent communications
2.1. All parties should clearly and securely communicate and negotiate 
expectations and timelines.


Because this didn't happen, we now get to look forward to a weekend of 
elevated risk, followed by people upending their calendars to handle 
un-coordinated upgrades on monday morning.


Vulnerability researchers perform a valuable service, but enthusiasm 
needs to be tempered with an understanding that there are real life 
consequences to not handling this sort of thing in a well-structured 
way.  It doesn't need to be said that: "1. we screwed up with your email 
address, and 2. we're disclosing in 4 days and aren't telling you what 
the problem is unless you agree to our terms" is not an appropriate way 
of handling anything, whatever about claiming to speak on behalf of an NCSC.


This won't be the last time a screw-up of this form happens, so maybe 
NCSC-NL's takeaway should be to ensure that co-ordinated vuln management 
and disclosure happens in a reasonable way when engaging with all parties?


As a separate thing, software authors also need to have clearly defined 
security notification points and vulnerability management policies. 
Most have in this situation, but not all.


Nick


randy


From: Koen van Hove 
Subject: CVD: Vulnerabilities in RPKI Validators
To: ra...@psg.com, s...@hactrn.net
Cc: c...@ncsc.nl
Date: Wed, 27 Oct 2021 14:59:21 -0700

Dear Randy Bush and Rob Austein,

Apologies, this email was previously sent to the wrong email address.

On behalf of the University of Twente and the National Cyber Security
Centre of the Netherlands (NCSC-NL) we want to notify you of a Coordinated
Vulnerability Disclosure for RPKI vulnerabilities that also impact rcynic
developed by Dragon Research Labs.

The vulnerabilities were discovered by scientific research on the
implementation of RPKI validators.
Together with you, the NCSC-NL, the University of Twente, and multiple
other parties, we would like to come to a timely solution before the
results of this research will be made public. More information about
Coordinated Vulnerability Disclosure can be found here [1].

The vulnerabilities are classified as a denial of service vulnerability and
impact multiple implementations of RPKI validators including rcynic. Since
RPKI is of international interest we hope that you will work together with
us on this CVD.

The goal is to have fixes available before 1 November which will also be
the date that the results of this research will become public. Before 1
November the information in the CVD, or the fact that a CVD is taking
place, is to be kept strictly confidential. The fixes are to be released
collectively on 1 November.

Please let us know whether you agree to these terms, and want to
participate in this CVD. If so, we will send you the details. We hope to
hear from you.

If there are any further questions, please let us know.

Yours sincerely,

Koen van Hove
University of Twente

[1] https://english.ncsc.nl/contact/reporting-a-vulnerability-cvd

- --
Koen van Hove
-BEGIN PGP SIGNATURE-
Version: FlowCrypt Email Encryption 8.1.5
Comment: Seamlessly send and receive encrypted email

wsDzBAEBCgAGBQJhecu4ACEJEPnqm/++VTh9FiEE5Q3GCKqW0RQyUpA/+eqb
/75VOH1CjwwAq8Hd0psDhfj6mL4X9ybLGogONpzFKYp9Okv9/CKzQvG4AkLR
Cvrz3vHlQRKJP8I2PYSLZvtG9D/HXjjKcU+m24jjl2qbKKuSwprqQhLAqabN
Md+RZFjQGve5Z4vtJsfhXKc4PhaAzMujVc4Mh5Mdbs4sFEdrub1hSnYKlcQV
PvS/O9SpCYU0E0IC1I455HXxSXUtme+KHtzbGIWQe/mz4KpnZD2Me/Cr1LvG
Od9izri0Qx5vF+kdpR51PEiwHgN+QkmnUP6Gkrca8TSC2x3ta9B1/ZprdCoZ
ZYQ7QUFUAkfV+tKCMaBECNOrnDjw8E9GonvzmqpDHBtKBZ3LaxjZX/sxuuTC
+Ele5nVeWW0ZFqrbanbPy9y1q04tFQd8ewdSN40iXdTj7Ha8GadUhcdSLWqJ
cLmf71qUAvdwpp0Bt1nhExpU/bEtAaxfnEcTRDX43yUkZXSqV5BxYEyneSLj
IvFV9AUi56Cx45ESkGRR1ASuCzoc8FCjRH7KOWnaL3fl
=YQZI
-END PGP SIGNATURE-

Re: What are best practices for RPKI ROV in transit networks....

[Job Snijders via NANOG]

On Fri, Oct 29, 2021 at 01:20:33AM +0400, Musa Stephen Honlue wrote:
> Personally I recommend dropping them invalids.

100%

> However, you could set local preferences as follows:
> - Valids routes get the highest local pref
> - unknown routes get a medium local pref 
> - Invalids routes get the lowest local pref
> 
> In this way, if you have competing routes, the one with the higher
> local pref gets preferred. By so doing, you are sure that an invalid
> route will never get preferred over an unknown one or a valid one.

There are two core issues with the above approach:

1/ invalid 'more-specific' routes, regardless of local pref, will 'win',
   so the approach is 'useless'.
2/ modifying BGP path attributes based on the validation state introduces
   needless churn and BGP UPDATE flooding.

Consider the following scenario: someone new to the RPKI ecosystem
decides to create RPKI ROAs. They expect nothing to happen, but under
the hood new BGP UPDATEs are flooded in all directions because the
LOCAL_PREF attributes needs to be updated. Same problem when associating
BGP communities to validation states.

To quote myself from https://bgpfilterguide.nlnog.net/guides/reject_invalids/

"""
It is considered harmful to manipulate BGP Path Attributes (for example
LOCAL_PREF or COMMUNITY) based on the RPKI Origin Validation state.
Making BGP Path Attributes dependent on RPKI Validation states
introduces needless brittleness in the global routing system as
explained here. Additionally, the use of RFC 8097 is STRONGLY ABSOLUTELY
NOT RECOMMENDED. RFC 8097 has caused issues for multi-vendor network
operators.
"""

Nick Hilliard shared similar sentiment:
https://mailarchive.ietf.org/arch/msg/sidrops/dwQi9lgYKRVctdlMAHhtgYkzhSM/

Kind regards,

Job

Re: What are best practices for RPKI ROV in transit networks....

[Ben Maddison via NANOG]

Hi Steve,

On 10/28, s...@iu.edu wrote:
> Greetings,
> 
> We seek input on best practices for implementing RPKI ROV in a transit
> (partial transit) network. The Internet2 network provides partial
> transit for many of the K-12 and higher education institutions in the
> US. Our customer routes number just over 6,000. We work with our
> customers to assist with the adoption of MANRS, including creating
> RPKI ROAs for their resources.
> 
>  At some point in the future, we'd like to implement RPKI route origin
>  validation (e.g., dropping invalids). Given that some routes may have
>  mistaken ROAs that resolve to an invalid state, is there a
>  standard/best practice for processing exceptions?

Yes, SLURM, defined in RFC8416, provides a means of expressing local
policy exceptions. All the RP implementations in common use (that I am
aware of) support it.

However...

>  Or, do transit providers that implement ROAs drop all routes that are
>  invalid?

We have had discard-invalid policy in production on every eBGP adjacency
since April 2019.

In that time, we have had *zero* incidents that could not be resolved
without the creation of local exceptions. My understanding from
colleagues at other operators is that their experience has been similar.

As always, your experience may be different, so it is wise to be
prepared.

Cheers,

Ben


signature.asc
Description: PGP signature