possible rsync validation dos vuln

[Randy Bush]

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

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-

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

[Amir Herzberg]

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).

Basically we want to measure if the overlap (and non-overlap) btw such
`suspect' prefixes and ROV-Invalid prefixes.

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).

thanks and regards... Amir
-- 
Amir Herzberg

Comcast professor of Security Innovations, Computer Science and
Engineering, University of Connecticut
Homepage: https://sites.google.com/site/amirherzberg/home
`Applied Introduction to Cryptography' textbook and lectures:
 https://sites.google.com/site/amirherzberg/applied-crypto-textbook

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

[Musa Stephen Honlue]

Personally I recommend dropping them invalids.

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.

But, honestly there is no point in ROV if you will allow invalids…

> 
> On 29 Oct 2021, at 00:20, Lukas Tribus  wrote:
> 
> Hello,
> 
> 
>> On Thu, 28 Oct 2021 at 21:35,  wrote:
>> Given that some routes may have mistaken ROAs that resolve to an
>> invalid state, is there a standard/best practice for processing exceptions?
> 
> There is no point in ROV, unless you are dropping invalid routes.
> 
> Not dropping invalid routes is something you'd do during transitional
> phases, when you are not yet sure about the impact. But if you keep it
> that way, you may as well not deploy it in the first place.
> 
> 
> Refer to the BGP Filterguide at NLNOG for some low level details:
> https://bgpfilterguide.nlnog.net/guides/reject_invalids/
> 
> 
> Lukas

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

[Lukas Tribus]

Hello,


On Thu, 28 Oct 2021 at 21:35,  wrote:
> Given that some routes may have mistaken ROAs that resolve to an
> invalid state, is there a standard/best practice for processing exceptions?

There is no point in ROV, unless you are dropping invalid routes.

Not dropping invalid routes is something you'd do during transitional
phases, when you are not yet sure about the impact. But if you keep it
that way, you may as well not deploy it in the first place.


Refer to the BGP Filterguide at NLNOG for some low level details:
https://bgpfilterguide.nlnog.net/guides/reject_invalids/


Lukas

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

[ssw]

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? Or, do transit providers that implement ROAs drop all 
routes that are invalid?

Thanks,

Steve



smime.p7s
Description: S/MIME cryptographic signature

Re: S.Korea broadband firm sues Netflix after traffic surge

[Justin Streiner]

On Wed, Oct 20, 2021 at 3:41 PM Matthew Walster  wrote:
The user initiates the connection to the CDN. The user is paying for a
level of access to the internet via the BT network, with varying tiers of
speed at particular costs. They are advertised as "Unlimited broadband: With
no data caps or download limits, you can do as much as you like online." on
their website. Many CDNs bring the data closer to the customer, either
embedded within their network, or meeting at various PoPs/IXPs around the
country.

Seems pretty disingenuous to now say the called party has to pay as well,
in stark contrast to decades of precedent with their telephone product,
just because their customers are actually using what they were sold.

All in all, this raises an interesting question. Is British Telecom running
> their networks so hot, that just keeping the lights on requires capacity
> upgrades or are they just looking for freebies?


What happened is pretty clear, and not just for BT or SK.  Those providers,
as a business decision, built their business models around a certain level
of oversubscription that would strike a balance between customers not being
unhappy and squeezing as much headroom out of the network before upgrades
are required (beefier routers/switches, fatter pipes, more peering/transit,
etc).  That business model got upended when that acceptable level of
oversubscription changed.  Video streaming was the puddle of
gasoline/petrol on the floor, and the change in user traffic patterns was
the lit match.

By asking content providers to hand over money to those carriers in
exchange for (better) access to their customers, many of the ISPs could in
fact be triple-dipping because they already get revenue from their
customers and some also get various government subsidies to provide certain
types of service or services in certain areas.

Definitely doesn't pass the sniff test.

Thank you
jms

>

Re: S.Korea broadband firm sues Netflix after traffic surge

[Jared Brown]

I don't know what they are putting in the water in Korea, but strange things 
are reported from there.

In addition to the SK Telecom shenanigans, apparently KT can't tell the 
difference between a DDoS and a routing error.

https://en.yna.co.kr/view/AEN20211025006253320


- Jared