Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question about the router: bound-checking for hop fields possibly missing #4482

Closed
jcp19 opened this issue Mar 8, 2024 · 2 comments · Fixed by #4483
Closed

Question about the router: bound-checking for hop fields possibly missing #4482

jcp19 opened this issue Mar 8, 2024 · 2 comments · Fixed by #4483
Labels
bug Something isn't working

Comments

@jcp19
Copy link
Contributor

jcp19 commented Mar 8, 2024

Hi everyone,

First, I apologize if this report/question is a bit too hand-wavy at times, but while proving the correctness of the router in the context of VerifiedSCION, I noticed that something looks weird.

More concretely, in file pkg/slayers/path/scion/decoded.go, there are the following definitions, together with comments expressing a few assumptions about the structure of the scion packets:

const (
	// MaxINFs is the maximum number of info fields in a SCION path.
	MaxINFs = 3
	// MaxHops is the maximum number of hop fields in a SCION path.
	MaxHops = 64
)

While the restriction on MaxINFs looks OK, the restriction that we have at most 64 hop fields seems to not be enforced: when we decode a Base, we store in the field NumHops the sum of the lengths of all segments. The length of each segment cannot exceed 64, but their sums can. As far as I can tell, there is no check performed while forwarding a packet that NumINFs is less than 64. While processing a SCION packet, we eventually call IncPath, which has the effect of incrementing the field CurrHF in PathMeta. As far as I can tell, nothing so far prohibits this field from getting to value 64 (if its original value was 63). The problem here is that, when we serialize the output packet (including its packet), if its value is at least 64, we will only serialize its 6 least significant bits, instead of storing its full value (the operation that serializes the CurrHF is uint32(m.CurrHF&0x3F)<<24). As such, I believe that, as is, the router would allow sending packets whose paths are too long until a point when they become invalid and are dropped. Is my understanding correct?

@jcp19 jcp19 added the bug Something isn't working label Mar 8, 2024
@jcp19 jcp19 changed the title Question about router: bound-checking for hop fields possibly missing Question about the router: bound-checking for hop fields possibly missing Mar 8, 2024
@jiceatscion
Copy link
Contributor

Due to the headers definitions, a scion packet with more than 64 hop fields cannot actually exist. It is just a packet with 64 hop fields plus stuff that looks like hop fields at the beginning of the payload. I guess this means that we're missing a check for the sum of segment lengths, since that's the only thing that indicates the packet is broken before actually reaching the end of the path. I'll try and produce this and fix it if needed.

@jiceatscion
Copy link
Contributor

Hem... I take that back. It is possible to fit up to 80 hops fields in a maximum header. So, may be more checks required.

jiceatscion added a commit that referenced this issue Mar 18, 2024
…path (#4483)

Added check and added unit tests for deserialization and for router ingress.

Fixes #4482
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants