On Tue, Dec 15, 2015 at 05:38:25PM +0900, Masataka Ohta wrote:
> Jared Mauch wrote:
>
> > The workarounds we’ve been slowly moving to is shifting services to alternate
> > ports that aren’t damaged by these transparent and helpful devices.
>
> That is not a workaround, but the only proper solution, because, we can
> do nothing against behavior of ALGs unknown to users, operators
> or even manufactures of the ALG, other than avoiding the ALG.
>
> And it can be automated if browsers support SRV, a DNS RR type to
> specify non-default port numbers.
I'm not talking about a browser.
> That's what I proposed in a position paper for an IAB workshop
> of SEMI, but the paper was rejected with the following review comment:
>
> : SRV in particular may work to confound assumptions about ports along
> : the path, but many of the port-linked behaviors are under the control
> : of the server operators anyway, so it is hart to see how this on its
> : own would do much to restore end-to-endness.
>
> That is, IAB is actively rejecting the idea of alternate ports.
There is the constant problem of the internet is viewed
through the lens of a TCP{80,443} transport, but that's another topic.
I'm talking about ALG that actively breaks things or exposes
the end devices to increased attack surfaces due to devices that will
never be properly maintained or are impossible to report defects against.
I look at the work in DNSOP to document that queries over
TCP are acceptable, but you end up with devices where they will never
be upgraded and do this:
https://www.cloudshark.org/captures/273da18d3057
Returning REFUSED is certainly not the right policy choice here
for a home gateway device.
- Jared
--
Jared Mauch | pgp key available via finger from jared@xxxxxxxxxxxxxxx
clue++; | http://puck.nether.net/~jared/ My statements are only mine.