Hi, all,
I raised this issue during the meeting, notably that we need to decide
to what extent we will support middlebox participation.
It's clear we need to support simple NATs. However, there are other
behaviors that are less clearly warranting support, both because they so
extremely violate TCP semantics it would be difficult to do so or
because the middlebox behavior is what we are trying to protect against.
I.e., there are three categories. Here is my view for what MUST, SHOULD,
MAY, and MUST NOT be supported:
MUST - simple NAT
AFAICT, we all assume support for client source port
and address translation (simple NAT)
--------------------------------------------------
SHOULD
- option content modification
this might be allowed to support some performance
middleboxes that modify MTU announcements or timestamps, e.g.
(I didn't list this as a MUST because some connections might
want to protect the TCP options, and that should be allowed
as a per-connection or per-host configuration default)
---------------------------------------------------
MUST NOT
- RST injection
IMO, there is no valid reason for a middlebox to issue a RST
to "help" a connection
- deleting TCPINC
IMO, we have no obligation to succeed in the presence of
a middlebox that rejects the option, because that should be
interpreted the same as the endpoint doing so
- segment rewriting
once a middlebox goes so far as to rewrite the contents, IMO
it *is* the endpoint, and would need to act like an endpoint
(i.e., to terminate TCPINC on the client side and initiate it
on the server side)
-------------------
-
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
