> From our (Nicira's) standpoint, using a more flexible encap
> makes sense when we own both sides of the communication since
> we are often often evolving our control plane (header bits
> are useful for all sorts of stuff, datapath state versioning,
> multi-hop logical topologies, carrying additional information
> like logical inport, or logical output port, etc.). Also,
> it is generally only deployed in the datacenter fabric, so
> abusing TCP isn't a huge issue since no middleboxes should be
> on route.
For what it is worth, from a transport layer point of view abusing TCP can
cause harm even without middleboxes. For instance, mis-configured STT could
inject erroneous data into existing TCP connections on non-STT hosts if they
happen to use the same 5-tuple. If the SEQ and ACK fields are modified ("header
bits are useful for all sorts of stuff"), this could even be a kind of scan for
the relevant window range in that connection. The risk might be small in fully
controlled environments, but apparently STT can have similar effects like
spoofed TCP segment attacks.
Michael (TCPM co-chair)
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
