Text on ICMP about draft-ietf-masque-connect-ip HOT 5 CLOSED

We definitely need to allow for ICMP from the peer itself.

I imagine the client should also gracefully handle receiving ICMP received from some other address, though? If the proxy receives an ICMP error from a host upstream on particular IP flow that the client did request, why not have it forward along the error? The client can decide what to do for processing at that point.

from draft-ietf-masque-connect-ip.

+1 to what Tommy, said: we should allow ICMP that doesn't come from the peer. The text currently states that. I propose to close with no action

from draft-ietf-masque-connect-ip.

What I saying it that I think receiving ICMP from the masque proxy is a MUST (because this is the only error handling we have) while receiving other ICMP is a should.

Also we do have a mechanism for the client to actually request ICMP scope. That means the client can tell the proxy if it wants to receive those ICMP or not. Why not using it?

from draft-ietf-masque-connect-ip.

I'm not sure what text changes you're proposing, @mirjak. By my read the current text is fine, although we disagree on MUST versus SHOULD. I think receiving ICMP from the masque proxy is a SHOULD, because it's still possible to successfully pass packets if you ignore ICMP. Also we already have a mechanism to request an ICMP scope with the ipproto restriction. In general on the internet we send ICMP no matter what, and if some firewall on-path wants to drop (silently or with notification), that's up to them.

from draft-ietf-masque-connect-ip.

+1 to what Alex said, dropping ICMP is common, so even if we were to use MUST, it would be an RFC 6919 MUST (BUT WE KNOW YOU WON'T). SHOULD is more realistic

from draft-ietf-masque-connect-ip.