Subject: Re: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques"

From: "S. Moonesamy" <[email-masked]>
Date: Wed, 01 Jul 2020 06:09:06 -0700

Hello,

Section 1 of draft-irtf-pearg-censorship-01 states that the "document 
describes the technical mechanisms that censorship regimes around the 
world use to block or degrade Internet traffic ..."  There is the 
following statement in Section 3.1: "Regional/Local Internet 
Registries (RIRs) that issue Route Origination Authorizations (ROAs) 
to BGP operators can be forced to issue rogue certificates that may 
allow compromises in confidentiality guarantees".

Is there any information about a Regional Internet Registry which was 
forced the issue a Route Origin Authorization to compromise 
"confidentiality guarantees"?

Regards,
S. Moonesamy

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Wed, 1 Jul 2020 17:51:45 +0000

(I'm slowly getting back into this set of conversations, sorry PEARG! The close of the second quarter is a tough time.)

S., are you asking for an example of this happening or for clarification on how such a thing might compromise such guarantees? I'm not sure if we have an example but you'll notice that a whole slew of those thing are hypothetical in that we haven't seen certain kinds of interventions.
________________________________
From: Pearg <[email-masked]> on behalf of S. Moonesamy <[email-masked]>
Sent: Wednesday, July 1, 2020 09:09
To: [email-masked] <[email-masked]>
Subject: Re: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques"

Hello,

Regards,
S. Moonesamy

--
Pearg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/pearg

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Wed, 1 Jul 2020 18:59:41 +0000

On Jul 1, 2020, at 2:51 PM, S. Moonesamy <[email-masked]<mailto:[email-masked]>> wrote:

Dear Joseph,
At 10:51 AM 01-07-2020, Joseph Lorenzo Hall wrote:
(I'm slowly getting back into this set of conversations, sorry PEARG! The close of the second quarter is a tough time.)

Thank you for the quick response.

I was asking for an example of it happening.  For what it is worth, I read RFC 6482 and I didn't find anything about ROAs being a potential issue.

Section 5 of the RFC states that: "There is no assumption of confidentiality for the data in a ROA".  I also took a quick look at RFC 6480 in case I missed anything.  Where does the "confidentiality guarantees" come from?

I think what the wording of the draft is trying to do there is to point out that if you can compel a signed route, ASs will tend to start sending traffic that direction, potentially compromising the confidentiality and integrity of the traffic, not the ROA. I’m happy to make that clear. Also, feel free to push back and say that it’s out of place… this part is trying to catalog entities in positions of power that could affect the ability of two ends to communicate.

--
Joseph Lorenzo Hall, Senior Vice President, Strong Internet
[email-masked]<mailto:[email-masked]> | +1-703-483-9504
internetsociety.org<http://internetsociety.org> | @internetsociety
pgp: https://josephhall.org/gpg-key
3CA28D7B9F6DDBD34B1016075F86698740A9A871

---

From: "S. Moonesamy" <[email-masked]>
Date: Wed, 01 Jul 2020 11:51:33 -0700

Dear Joseph,
At 10:51 AM 01-07-2020, Joseph Lorenzo Hall wrote:
>(I'm slowly getting back into this set of conversations, sorry 
>PEARG! The close of the second quarter is a tough time.)

>S., are you asking for an example of this happening or for 
>clarification on how such a thing might compromise such guarantees? 
>I'm not sure if we have an example but you'll notice that a whole 
>slew of those thing are hypothetical in that we haven't seen certain 
>kinds of interventions.

I was asking for an example of it happening.  For what it is worth, I 
read RFC 6482 and I didn't find anything about ROAs being a potential issue.

Section 5 of the RFC states that: "There is no assumption of 
confidentiality for the data in a ROA".  I also took a quick look at 
RFC 6480 in case I missed anything.  Where does the "confidentiality 
guarantees" come from?

Regards,
S. Moonesamy

---

From: "S. Moonesamy" <[email-masked]>
Date: Wed, 01 Jul 2020 15:14:10 -0700

Dear Joseph,
At 11:59 AM 01-07-2020, Joseph Lorenzo Hall wrote:
>I think what the wording of the draft is trying 
>to do there is to point out that if you can 
>compel a signed route, ASs will tend to start 
>sending traffic that direction, potentially 
>compromising the confidentiality and integrity 
>of the traffic, not the ROA. I'm happy to make 
>that clear. Also, feel free to push back and say 
>that it's out of place… this ppart is trying to 
>catalog entities in positions of power that 
>could affect the ability of two ends to communicate.

I'll explain what I understood.  Please do 
correct me if you or anyone believes that it is 
incorrect:  The Introduction section states that 
the document describes technical mechanisms that 
censorship regimes around the world use for 
blocking or impairing Internet traffic.  In my 
opinion, the reader would expect that the points 
of control (Section 3.1) are/were used for impairing Internet traffic.

Section 3 is about the identification of 
"technical" points of control.  One of the 
examples given is that of a Regional Internet 
Registry which issues a Route Origination 
Authorization when it is requested to do so by 
one of the members of the Registry.  The argument 
is that the Registry can be compelled by law to 
issue a Route Origination Authorization which is 
not compliant with its practices.  The traffic 
for the "prefix" would then be redirected to another entity.

Given the above, the two ends would not 
communicate as expected (there are RFCs which 
discuss end-to-end).  Would that happen without a 
Route Origination Authorization?

The example at the end of the paragraph about 
"Certificate Authorities" mentions "TLS 
interception".  Wouldn't that be detected when 
the certificate is verified by the receiving side?

I suggest reviewing the issue which you described 
and the text instead of saying that the text is out of place.

Regards,
S. Moonesamy

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Thu, 23 Jul 2020 22:05:52 +0000

Hi, sorry for not following up sooner (going through things making slides for next Monday!).

I'm unclear as to what you'd like the draft to say differently here. Happy to work on making it more clear but I think what you've outlined is what I understand the ability for an RIR to be compelled to sign routes that misdirect traffic. best, Joe
________________________________
From: S. Moonesamy <[email-masked]>
Sent: Wednesday, July 1, 2020 18:14
To: Joseph Lorenzo Hall <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques"

Dear Joseph,

Regards,
S. Moonesamy

---

From: "S. Moonesamy" <[email-masked]>
Date: Thu, 23 Jul 2020 15:55:01 -0700

Dear Joe,
At 03:05 PM 23-07-2020, Joseph Lorenzo Hall wrote:
>I'm unclear as to what you'd like the draft to say differently here. 
>Happy to work on making it more clear but I think what you've 
>outlined is what I understand the ability for an RIR to be compelled 
>to sign routes that misdirect traffic. best, Joe

I provided an opinion of the technical aspects based on my 
understanding of how RPKI and TLS works.  RFC 8446 describes the 
properties of the secure channel defined in that document and states 
that "These properties should be true even in the face of an attacker 
who has complete control of the network ..."  My reading of the text 
in Section 3 is that those properties (Authentication, 
Confidentiality, Integrity) would no longer be true if a route was 
incorrectly "signed".

I would suggest verifying whether my interpretation (please see 
above) is correct or not.

Regards,
S. Moonesamy