Change:
What is the behavior when an endpoint sends a packet for which it didn’t have an assigned source address or a valid destination route. Is this cause for dropping the packet silently, sending an error capsule, or closing the request stream with an error? Closing the stream too harshly may be problematic if the packet was valid in some previous routing table, but now is not.
I think that's a policy decision that is out of scope for this document. Some deployments will most likely implement BCP38 filtering, but that's not required of all uses of this protocol.
I agree it's a policy decision. In our implementation today we send and ICMP administratively prohibited and drop the packet. I would personally be comfortable with that being a SHOULD recommendation.
This was discussed in the room at IETF 113 and it sounded like ICMP seemed like the most liked option.
I think the decision to send ICMP or not is out of scope for this document. However, we can maybe still have an optional masque error capsule given the packet received doesn't fit the masque request. The question is, can the client do anything useful with this information? I guess the difference to ICMP is that you know this is a MASQUE issue and not something else.
I think that the issue of an IP packet not fitting in an HTTP Datagram is not specific to MASQUE - it's a very standard path MTU issue that can be communicated with ICMP Packet Too Big. I propose we add some text recommending to use ICMP when packets are dropped due to policy, path MTU, etc.
I think ICMP for dropping packets for policies and Packet Too Big etc is fine. However, I would note that we likely should consider recommendations regarding source address validation. But I can open another issue on that as I think this is one security function that should be recommended to be implemented especially for Proxies that intended to let the client reach general Internet.
Regarding source address validation, I propose we recommend deployments follow BCP 38 where applicable. Would that resolve this issue?
Actually I just saw you filed about source address validation, let's discuss BCP 38 there. Based on the discussion here, we can resolve this issue by writing a PR that recommends sending ICMP to signal packet loss due to policy, path MTU, etc.
Yes, lets start with that, as it is likely to resolve this aspect.
Not sure if this covers everything. We can use paceket-too-big and destination-unreachable but what if the source address is not allowed by the proxy?
We use Administratively Prohibited for that in our implementation.
you mean in the client or server? However, if the server receives a packet with a prohibited source IP address, shouldn't you eventually send an error somehow back to the client?
Interesting for client address errors. That could use type 12, Parameter Problem? But not sure.
I don't think that would be helpful for the client at all...
This issue got closed with merging PR however I don't think it's fully resolved yet. Should we re-open?
I think the broader issue of ICMP is resolved, NAME can you filed another issue for your more specific point? That way it'll have a cleaner history.

Discussion:
7. <ins> Since CONNECT-IP endpoints often forward IP packets onwards to other network interfaces, they need to handle errors in the forwarding process.  For example, forwarding can fail if the endpoint doesn't have a route for the destination address, or if it is configured to reject a destination prefix by policy, or if the MTU of the outgoing link is lower than the size of the packet to be forwarded.  In such scenarios, CONNECT-IP endpoints SHOULD use ICMP ICMP to signal the forwarding error to its peer. 8. </ins> CONNECT-IP enables many different use cases that can benefit from IP packet proxying and tunnelling.  These examples are provided to help illustrate some of the ways in which CONNECT-IP can be used. <del> 7.1. </del> <ins> 8.1. </ins> The following example shows a point-to-network VPN setup, where a client receives a set of local addresses, and can send to any remote

case, the advertised route is restricted to 192.0.2.0/24, rather than 0.0.0.0/0. <del> 7.2. </del> <ins> 8.2. </ins> The following example shows an IP flow forwarding setup, where a client requests to establish a forwarding tunnel to

(2001:db8::3456), scoped to SCTP.  The client can send and recieve SCTP IP packets to the remote host. <del> 7.3. </del> <ins> 8.3. </ins> The following example shows a setup where a client is proxying UDP packets through a CONNECT-IP proxy in order to control connection

UDP.  The client can send and recieve UDP IP packets to the either of the server addresses to enable Happy Eyeballs through the proxy. <del> 8. </del> <ins> 9. </ins> There are significant risks in allowing arbitrary clients to establish a tunnel to arbitrary servers, as that could allow bad

they SHOULD follow the guidance in BCP38 to help prevent denial of service attacks. <del> 9. </del> <ins> 10. </ins> <del> 9.1. </del> <ins> 10.1. </ins> This document will request IANA to register "connect-ip" in the HTTP Upgrade Token Registry maintained at <<https://www.iana.org/assignments/http-upgrade-tokens>>. <del> 9.2. </del> <ins> 10.2. </ins> This document will request IANA to add the following values to the "HTTP Capsule Types" registry created by HTTP-DGRAM: