Date: Sun, 01 Mar 2020 04:05:22 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 244514] "reply-to" function in pf breaks RFC 1122 section 3.3.1.1 Local/Remote Decision Message-ID: <bug-244514-227-mB3us0AoIw@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-244514-227@https.bugs.freebsd.org/bugzilla/> References: <bug-244514-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D244514 --- Comment #3 from ctminime@yahoo.com --- (In reply to Kristof Provost from comment #2) As far as I can tell, you are wrong about dropping packets violates RFC. I couldn't find anything of the sorts in RFC 793 or RFC 1122. What I did find= , is some commentary in RFC 3360 under "The history of TCP resets". Go ahead and read it yourself. However, if you you can find that in an RFC, I would be interested to read it. I can't think of a single way that making "reply-to" RFC compliant (by defa= ult) would break any setup. It would only fix the couple of use case that it bre= aks.=20 It is my personal opinion that the default behavior of a function should be= RFC compliant. Then it could be up to the administrator if he chooses to violate RFC to accomplish whatever he wants. It could be done like this: "reply-to" sends all traffic, except local subn= et traffic, to the gateway. (FYI, this is how pfSense behaves.) But if an administrator wanted to, for some unfathomable reason, there could be an op= tion like "reply-to absolute" that would be specifically for violating RFC and s= end all traffic to the gateway. Just because this is the way it has worked for a decade+, doesn't mean it is right or should stay that way. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-244514-227-mB3us0AoIw>