#4 Dynamically decide which packet fields to mask

open
Andrew Chin
None
5
2008-08-24
2008-08-19
Peter Eckersley
No

Currently, there are a few variables in Packet.py which determine what parts of a packet are zeroed/masked out before the packet is hashed. Some fields (TTL, checksums) are always masked; others (IP Type of Service) may or may not be masked out.

As of 0.0.7, we have some variables in Packet.py which control the masking of some fields. However, they need to be set consistently for all of the Switzerland clients (which means that changing them for live clients would break compatibility and therefore requires increasing Protocol.version!)

One way to handle field masking is to set these variables in the "new-members" messages that the server sends to the clients (grep for it). A dict could be added to that message saying which Packet fields should be masked out (currently we just send a list of [("ip", firewalled)] as the arguments to "new-members" messages, but we will also add hash keys in there in the future).

If new-members messages start controlling which fields are masked, the server has the option of following up after spotting forgeries by sending "farewell" messages to stop the two clients being aware of each other momentarily and then re-welcoming them with "new-members" messages that change the masking rules to ignore whatever field was just reported as modified.

(Another way to handle field masking would be to control it on a per-flow basis. That has some attractions, but it might be a bit harder).

(This will be our first Protocol.version change in live deployment. It would be great if the server can keep track of protocol versions and not break old clients when this rolls out.)

Discussion

    • assigned_to: nobody --> eminence32