Venue: Proceedings of the ACM SIGCOMM workshop on Future directions in network architecture
Summary:
Motivation:
- Senders want to choose paths so they can route around failures/congestion and use "good" paths for some definition of good. These are transmit policies. **JN: Don't they care more about paths to them though?
- Receivers want to filter incoming packets to mitigate DDoS attacks. These are receive policies.
- Today can only control first/last hop which is insufficient.
Mechanism:
- Packet has WRAP shim layer between IP and payload.
- WRAP header has two paths: forward and reverse.
- Sender specifies the path through trusted relays and puts their IP addresses in the forward path. Reverse path is empty.
- The sender also sets the IP dst field to the first relay's IP address and sets the src field to its IP address.
- At each relay, the first hop is popped from the forward path and used as the IP dst address, and the outgoing interface's IP addr is used as the src address. The old src address is put in the reverse path.
- This continues until destination is reached.
The authors claim this is better than IP's LSRR option because:
- They claim it is easier to do in hardware ** JN: Maybe only marginally if anything.
- it does not go into the IP options field which causes packets to go into the router's slow path usually. They claim the issue is that the IP options field is variable length. Conventional wire-speed filters can be used to filter these packets. ** JN: I'm guessing not based on the WRAP header though.
- The src IP address is not that of the original source IP but that of previous relay, and the receiver uses the recorded reverse path rather than reversing the forward path as is done in traditional LSRR. They claim this makes it harder to hijack communication. **JN: I might be missing something here, but this claim seems totally bogus. A bad guy can make a packet look whichever way it wants and just insert its address in the reverse path. I don't see how WRAP helps at all.
For transmit policies, either the provider can choose paths or the end-host can. Obviously. They say that they can use things like FBR (Feedback-based Routing).
For receive policies, they need an additional mechanism which is Active Internet Traffic Filtering (AITF) which becomes more accurate using WRAP.
Other things like MPLS and DiffServ end up becoming sort of like virtual circuits (Stealth Virtual Circuits) and go against the motivation for choosing datagrams for IP over a connection-oriented protocol.
(See comments below by Katerina for rebuttals and clarifications)
Jad,
ReplyDeleteA couple of comments.
- Regarding the claim that WRAP (and LSRR) makes it harder to spoof: Say a bad source sends out a packet with a bogus reverse path [X,Y,Z] and forward path [A,B,C,D], where D is the destination. Assuming A, B and C are non-malicious routers, when the packet reaches D it has reverse path [X,Y,Z,A,B,C,D]. So, even though the first part of the reverse path is bogus, it at least includes the real reverse path as a suffix. In this sense, WRAP does make it harder to spoof, because the receiver knows a big part of the path followed by the packet, even if it does not know the exact source.
- Regarding the claim that conventional filters can be used to filter WRAP packets based on their header: What is meant by "conventional filters" is "conventional filtering mechanisms." I.e., a router would be able to filter a WRAP packet by reading its forward/reverse path (which would be at a fixed location) and looking it up in a TCAM. You cannot do that with IP options -- at least not in any conventional way.