scionassociation / scion-dp_I-D

Specification of the SCION data plane
https://scionassociation.github.io/scion-dp_I-D/
Other
1 stars 0 forks source link

Clarify MACs (truncation, path splicing) #7

Closed nicorusti closed 2 months ago

nicorusti commented 6 months ago

When dealing with security considerations #1 , we mention that chained MACs prevent path splicing attacks. This should be better explained, since in the draft we describe how chained MACs work, but not how they prevent path splicing.

From Joel Halpern The use of only the lower two bytes of the cryptographic value for chaining seems odd. If you need a 16 bit value, I would have assumed you would at least fold the entire 6 bit signature into thirds, so all the bits have an impact?

Right, this depends on the MAC algorithm. Safely truncating requires certain MAC algorithms, e.g. ones that have properties of a pseudorandom function. We should clarify this.

Both the PCB authentication and the hop authentication use a mechanism that computes the signature over all previous hops. This seems odd. If each hop includes the previous hop, that seems to produce an immutable chain at lower cost. At the very least, an explanation would seem called for.

This is to avoid certain path splicing attacks, we have a brief description in the data plane draft 5.1.3. Path Splicing, but this can be extended.

A path splice would still make the following signature invalid. But what I had missed is that it would not make the final signature invalid. And you want validation at packet forwarding time to be fast. Okay, I see why you are chaining them for the hop signature generation. I guess for the PCB signature you either chain them at generation or you have to validate each one at PCB validation. So again, I see why you are doing it this way. A bit more explanation in the draft would be good. Thanks.

Issue in CP: https://github.com/scionassociation/scion-cp_I-D/issues/23