Draft: draft-ietf-masque-connect-ip

Commentary: Addressing the monitoring possibilities that connect request with ICMP scope has if sharing IP address as discussed in . 
 Over email ,   mentioned : When looking into this I noticed that the section states the following about the IP Protocol field : But the section states : This is contradictory . I would recommend removing the recommendation in Error Signalling . 
 I do n't think this is contradictory . The former text says " we will send you traffic whether you like it or not " . The latter says " you should do something useful with it " . Certainly it could be wordsmithed a bit , but I do n't think an outright removal is a good idea as we should still give guidance to users that they are expected to do something if they 're doing ipproto - based routing . 
 That does n't match my understanding . To me , the former says " you do n't need to send a route with ipproto =  because it 's always allowed " but the latter says " you SHOULD send a route with ipproto = ICMP " 
 I think those are compatible ? The former is saying you do n't have to , the latter is signaling you 've acknowledged and will do something useful with it . 
 Is n't that just wasted bytes ? 
 I could imagine a server doing something useful with this information . Maybe having different ratelimits for ICMP traffic for a well - behaved client that will process the messages . But this only applies in the cases where you 're using ipproto scoping , so I am not too worried about the bytes - wasted 
 If we intend to have recipients act on this information , we should clearly define what it 's meant to convey , otherwise we 'll create interoperability issues . 
 That 's fair . To be clear , I do not object to removing the text as you originally suggested . I just wanted to clarify that I did n't consider the current situation a contradiction . 
 I think we need to clarify this a bit as it actually exist three different interpretation depending on what was requested . So if the requester do a Connect request with ipproto=1 scope : I will get all ICMP message for this IP address would be my interpretation . This is fine to ask for , but I think we need a security consideration note on this . This should only be allowed if this external IP address that is assigned is only used by this requesting endpoint . Otherwise it will allow some possibility to overhead what the other endpoint attempt to do when  messages are generated back towards this IP address . So if the connect request is for ipproto=6 ( TCP ): In this case we have two interpretations of what has been written . A ) The IP proxy will send ICMP messages to the requesting endpoint to indicate issues . B ) The IP proxy will match any incoming ICMP messages on the external IP address assgined and forward them to the requestor . So what I expect to happen is that A ) will always happen , but it is unclear if B ) will happen . I think we want to make clear that B ) MAY / SHOULD / MUST be done . I will write a PR for the security consideration for requesting ICMP traffic for an assigned address . 
 Overall I totally agree with this change , but I think the wording needs some work . I 've included a proposal .
Paragraph (version B):
Limiting request scope (see scope) allows two clients to share one of
the proxy's external IP addresses if their requests are scoped to
different IP protocol numbers.  If the proxy receives an ICMP packet
destined for that external IP address, it has the option to forward
it back to the clients.  However, some of these ICMP packets carry
part of the original IP packet that triggered the ICMP response.
Forwarding such packets can accidentally divulge information about
one client's traffic to another client.  To avoid this, proxies that
forward ICMP on shared external IP addresses MUST inspect the
invoking packet included in the ICMP packet and only forward the ICMP
packet to the client whose scoping matches the invoking packet.