[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D ACTION:draft-ietf-shim6-reach-detect-00.txt

On 19-jul-2005, at 11:31, Erik Nordmark wrote:

I worry that the argument
"one ULP works => others should work too" may not
hold in all cases. What if one ULP is TCP:xxxx->80, which
happens to work over this crappy firewalled network that
you are using, but it doesn't let through, say, TCP:xxxx->23?
The shim could be making the wrong decision here.

And this supposedly works today without a shim? 

:-)

Unless we take the rather radical approach of making the shim a TCP option (hard to do with such limited option space available) the shim negotiation and initial reachability verification packets need to get through in the first place or the path won't be used, because as far as the shim cal tell, it doesn't work.

It is of course possible that an enterprising firewall admin cooks up a config that lets through shim and http packets, but not other important protocols.

I guess the thing to do here is note the negative advice / lack of positive advice from the affected upper layer/sessions and keep looking for an alternative path.

If you believe some firewalls today are causing non-transparency problems, the workaround seems to be to encapsulate in some general connectivity protocol (http, ipsec/esp, ssh, ...) end to end.

I disagree. If a firewall gets in the way, this can either be because there is a valid reason, and then sneaking by is bad, or there is no valid reason, so the firewall should be fixed. Adding additional complexity and overhead to award people for laziness is very bad.