mjoras / SCONE-PROTOCL

Repository for files related to the topic formerly known as SADCDN.
Other
7 stars 6 forks source link

Add resilience to NAT rebinding as a property #40

Closed SpencerDawkins closed 4 months ago

SpencerDawkins commented 4 months ago

closes #9

danwing commented 4 months ago

SCONE isn't doing rate limiting, though; rather, it is informing the client of the network's preferred rate for that subscriber (or more generally, that "class" of subscriber: gold/silver/bronze). This network's rate policy is the same even if the client's source IP address changes; the network's rate policy only changes if the subscriber upgrades/downgrades to a different class.

fluffy commented 4 months ago

I get what you are saying and that makes sense but I worry about the following. Our security properties are probably going to say we only trust this information if the box can prove that it is in a position where it could shape traffic. So if we want to extend that to all the source ports, then we are in a place where for this to be true, we have to assume no source based routing. However having the source based routing is pretty common for load distribution. So I worry by taking on this requirement, we might make it harder to make our security guarantees.

I have no idea if the protocol will work like this at all and this seems like a good thing for the WG to sort out once it gets going, it just seemed like a level of detail that did not need to be in the charter. Or to put another way, I was not understanding why this needed to be in the charter.

SpencerDawkins commented 4 months ago

Hi, @fluffy,

I get what you are saying and that makes sense but I worry about the following. Our security properties are probably going to say we only trust this information if the box can prove that it is in a position where it could shape traffic. So if we want to extend that to all the source ports, then we are in a place where for this to be true, we have to assume no source based routing. However having the source based routing is pretty common for load distribution. So I worry by taking on this requirement, we might make it harder to make our security guarantees.

That helps me understand what you're thinking. I'm leaning towards what @danwing is thinking, mostly because I wasn't expecting boxes that do rate limiting to have high confidence that a flow with a different port number and IP address is the same flow it's already aware of. But,

I have no idea if the protocol will work like this at all and this seems like a good thing for the WG to sort out once it gets going, it just seemed like a level of detail that did not need to be in the charter. Or to put another way, I was not understanding why this needed to be in the charter.

is EXACTLY what we need to talk about, so we know whether to merge the PR, change it, or abandon it and change the label from "charter" to "InADocument".