mirjak / draft-kuehlewind-masque-connect-ip Goto Github PK

When using Connect-IP there is an Interface MTU on the external interface which is the largest IP packet that can be created. It can be in some situations be the limiting factor of how big IP packets can be sent through the tunnel and successfully be emitted.

To signal this MTU there exist a couple of potential solutions.

A) Use an HTTP header as the interface MTU is unlikely to change during the CONNECT-IP session.
B) Generate an ICMP in the MASQUE server and send back to the client if the packet can't be emitted.
C) Define a context-ID format that carries the MTU back to the client.

In Tunnel Mode this limit is general and not destination specific. For flow forwarding mode, a path related specific MTU value may be cached due to earlier ICMP PTB message having been received. And for the flow-based this value can change, however we have already defined a way of forwarding the ICMP PTB messages to the client so more solutions don't appear necessary.

So based on limitations that exist a HTTP header may be the simplest solution here.

Section 3.4 states:

However, additional forwarding association can be requested by the client to use the same IP address as a previous request by specifying the stream ID as value in this header. This header can also be used to ensure that a "new", not yet for this client used address is selected by setting a value that is larger than the maximum stream ID.

Using a stream id in a header as an end-to-end identifier is problematic in the presence of HTTP intermediaries. An intermediary would need to understand and rewrite the header for the identifier to be meaningful for the receiving endpoint.

It is not clear how Tunnel mode allows forwarding of incoming IP packets to the client while flow forwarding mode does not do that. The IP-Connect method is always client initiated with a target server to the proxy. Then the proxy creates connection towards the target server. Hence it is always going to work for know target server. Why and how the tunnel mode will allow forwarding of IP packets from unknown target server to the client?

In the section describing the Masque server behavior for datagram there is not information about how to calculate and send the MTU information to the client. The section with IP header creation only mentions the Masque server should provide MTU (to whom?)

In the section Receiving IP packet, shall we be more specific about the additional identifier information required.

The draft currently does not really discuss the different models of IP address handling that would be possible, nor how they would interact with the protocol mechanisms. For example the IP-Address header is allowed in request. If that included in a tunnel-mode or in a first request for a flow mode, is this allowed or disallowed, and what does it mean.

In tunnel mode is the default mode to borrow an address from the proxy?

The IP version can be derived from the address supplied in the authority pseudo header and the IP-Address header.
A parser would need to validate those values as valid v4 or v6 addresses anyway so I am not sure this header provides any new information.