Draft: draft-ietf-masque-connect-ip

Commentary: What is the behavior when an endpoint sends a packet for which it did n’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  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 does n'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 , should n'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 do n't think that would be helpful for the client at all ... 
 This issue got closed with merging PR however I do n't think it 's fully resolved yet . Should we re - open ? 
 I think the broader issue of ICMP is resolved , can you filed another issue for your more specific point ? That way it 'll have a cleaner history .
Paragraph (version B):
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.