[Sidrops] Re: [WGLC] draft-ietf-sidrops-rrdp-same-origin-00 - Ends 1/July/2024

[Alberto Leiva <[e-mail]>]

Well,

I noticed the latest version of the draft doesn't elaborate on some of
the notes raised in the other thread, which I think are important.

Tim proposed

> and possible disallowing the use of get parameters
> in URIs, seems prudent.

I understand that this was ultimately agreed against, but I feel the
RFC should explain why, because the problem explained in section 2
aggressively invites this solution.

And Ties mentioned:

>> This solution means that if the adversary wants to feed large files into
>> RPs, they have to host the data themselves, and pay for the network
>> bandwidth cost themselves. This seems reasonable to me.
>
> This is a good mitigation and we should make sure that this line of reasoning is captured somewhere.

As far as I can tell, the draft does not capture this reasoning.

------------------------------

> RPs cannot avoid scheduling a new download per Section 3.4.1 of
> [RFC8182] because Delta file, Snapshot file, session_id and serial
> are significant only in scope of the referring SIA AccessDescription.
> In other words, SIAs are globally unique and can be deduplicated
> before scheduling fetches, but RRDP session_ids are not globally
> unique, contrary to what Section 3.1 of [RFC8182] suggests.

I still have some beef with this paragraph. I imagine part of this is
just my lack of creativity, and I apologize for that, but I would
prefer if the RFC's reasoning didn't leave holes for the reader to
fill.

1. Why "Delta *file*" and "Snapshot *file*"?

If an RP wants an index to prevent a file redownload... wouldn't using
the *file* itself as an index defeat the entire purpose?

Don't you mean "Delta URL" and "Snapshot URL"?

2. The tissue that connects this paragraph to the surrounding ones is
camouflaged by the SIA detour, which doesn't seem very relevant to me,
and raises a question.

I feel like the document should elaborate on "SIAs are globally unique
and can be deduplicated before scheduling fetches" at some point. The
sentence sounds incorrect without context, and the entire paragraph
seems to orbit around it.

What is enforcing SIAs to be globally unique? Suppose:

- Certificate A has rpkiNotify SIA "https://example.com/a/notif.xml"
- Certificate B (elsewhere in the tree, or even in another tree) has
rpkiNotify SIA "https://example.com/a/notif.xml?a=b"

Given that the draft seems reluctant to advocate for parameter
removal... how do you deduplicate those?

3. I'm not actually sure if we understand the same concept from the
word "deduplicate," because it's not defined in the draft, and it's
also not defined in any of the RFCs it references. (I didn't search
deeper, though.)
4. Isn't there a "the" missing between "in" and "scope"?
5. The "in other words" second half of the paragraph doesn't seem
equivalent to the first, adding more confusion.

It's not equivalent because it only elaborates on session_id, leaving
"Snapshot file," "Delta file" and serial in limbo. Furthermore, the
logic that explains why session_id is not indexable doesn't seem to
extend to the other fields.

--------------------

Maybe I should propose an alternate version of the paragraph:

> RPs cannot recognize they have already downloaded the file, because
> the attacker has effectively morphed the Snapshot's URL into a
> different Uniform Resource Identifier [URI], and nothing enforces
> session_id (and/or serial) to be globally unique (despite what Section
> 3.1 of [RFC8182] suggests).

And then maybe explain the SIA quirk in a separate paragraph:

> This is all in contrast to the SIA AccessDescription field, which
> doesn't suffer this problem because [...].

---------------------------

> If the adversary increments the serial in tandem with RIPE NCC
> incrementing their RRDP serial, every next request to
> _https://badhost/notification.xml_ causes another large file download
> on the RIPE NCC servers, exacerbating the issue.

Aaaaaaah. I don't like this paragraph either.

(First: Maybe change "another large file download" into "another large
snapshot download," because otherwise it kind of sounds like you're
talking about the notification.)

The paragraph seems to imply that, if the adversary doesn't increment
the serial along with RIPE, the RP will not download the file again.
That the adversary needs to keep incrementing the serial to sustain
the attack. Ok, makes sense.

But it invites a deformation of the argument: If the adversary
increments the serial *regardless* of RIPE, what's stopping the RP
from downloading the snapshot again? Is there a requirement somewhere
that states that the RP has to detect this type of RRDP session
desynchronization? (Different serial, same snapshot.)

(Yes, I'm aware rpki-client will discard the snapshot as soon as it
notices the serial mismatch during transfer, but I'm talking about a
generic RFC-compliant RP here. I know the "streaming RRDP file"
feature is outside of the scope of your draft, but my point is that
the paragraph doesn't really make sense in the context of the present
RFC ecosystem as I understand it.)

Alternate (slightly more generic) attack proposal:

Making sure the serial always matches the snapshot, point to a
different available snapshot every time. The serial will always
change, which means RPs will always have to download the snapshot,
either because a new one is available (and there are no deltas), or
because the lower serial will trigger an RRDP reset. You will not
attack RIPE when they switch snapshots, you will guarantee RPs attack
RIPE during every validation cycle.

Proposal:

> If the adversary keeps changing the notification's session metadata,
> every next request to _https://badhost/notification.xml_ causes
> another large snapshot download on the RIPE NCC servers, exacerbating
> the issue. (For several popular RP implementations, this presently
> requires that the malicious notification's session metadata always
> matches the snapshot's session metadata.)

Sorry for being so pedantic
Alberto

On Mon, Jun 17, 2024 at 6:20 PM Nimrod Levy <[e-mail]> wrote:
>
>
> On Sun, Jun 16, 2024 at 6:12 PM Keyur Patel <keyur=[e-mail]> wrote:
>>
>> Hi Folks,
>>
>>
>>
>> A working group last call has been issued for  “Same-Origin Policy for the RPKI Repository Delta Protocol (RRDP)” https://datatracker.ietf.org/doc/draft-ietf-sidrops-rrdp-same-origin/.
>>
>>
>>
>> Please send your comments to the list. The adoption call will end on July 1, 2024.
>>
>>
>> Job please reply indicating whether you’re aware of any relevant IPR that hasn’t been disclosed.
>>
>>
>>
>> Best Regards,
>>
>> Chris, Russ & Keyur
>>
>> _______________________________________________
>> Sidrops mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>
>
> I have read the draft and support publication.
>
> Nimrod
> _______________________________________________
> Sidrops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]