This doesn't cover all of what middleboxes do, but the part about them
faking responses (e.g., to splice connections), hijacking, or NATing are
covered in RFC1122 sec 3.2.1.3:
When a host sends any datagram, the IP source address MUST
be one of its own IP addresses (but not a broadcast or
multicast address).
I don't see anything in 1812 that prohibits routers from modifying the
contents of an IP datagram, but the term 'forwarding' never permits
modification of the IP payload either.
Joe
Fleischman, Eric wrote:
Friends,
I believe that Keith's first paragraph below is widely accepted by the
IETF. However, after re-reading RFC 3234, RFC 3303, and others I did not
find any text within any RFC to explain our consensus opinion concerning
correct middlebox behavior to be used to guide those outside of our
community. Specifically, can anyone point me to text within any RFC that
states the ideas contained within Keith's first paragraph below?
--Eric
-----Original Message-----
From: Keith Moore [mailto:moore(_at_)cs(_dot_)utk(_dot_)edu]
Subject: Re: Question about the normative nature of IETF RFCs
Most protocols weren't designed to operate with middleboxes.
In the absence of a provision in a protocol specification for
a middlebox, any middlebox that interferes with the
interoperation of a protocol is inherently violating the
protocol standards.
In general, protocol specifications don't (and shouldn't)
try to explicitly enumerate "don't do X" for every possible
"X" that is harmful. And middleboxes are generally harmful.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
signature.asc
Description: OpenPGP digital signature
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf