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@xxxxxxxxxx]
> 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@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/ietf
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf