Draft: draft-ietf-masque-connect-ip

Commentary: 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 .
Paragraph (version A):
In order to receive these errors, endpoints need to be prepared to
receive ICMP packets.  If an endpoint sends ROUTE_ADVERTISEMENT
capsules, its routes SHOULD include an allowance for receiving ICMP
messages.  If an endpoint does not send ROUTE_ADVERTISEMENT capsules,
such as a client opening an IP flow through an IP proxy, it SHOULD
process proxied ICMP packets from its peer in order to receive these
errors.  Note that ICMP messages can originate from a source address
different from that of the IP proxying peer.
Paragraph (version B):
In order to receive these errors, endpoints need to be prepared to
receive ICMP packets.  If an endpoint does not send
ROUTE_ADVERTISEMENT capsules, such as a client opening an IP flow
through an IP proxy, it SHOULD process proxied ICMP packets from its
peer in order to receive these errors.  Note that ICMP messages can
originate from a source address different from that of the IP
proxying peer.