Subject: [pcp] discuss: open ICMP as side-effect

From: "Dan Wing" <[email-masked]>
Date: Tue, 7 Dec 2010 11:35:52 -0800

(Sorry, resending this one because I neglected to CC the BEHAVE working
group.  Please direct replies to [email-masked])

This is one of the PCP discussion points.

This question is CC'd to BEHAVE, as it was suggested BEHAVE should
provide input on this question.

The question is simple:  when PCP is used to open a UDP/TCP port,
should the NAT, as a side effect:

  (a) also allow ICMP messages associated with that UDP/TCP
      flow.  For example, allow ICMP packet-too-big messages
      associated with that flow.
or
  (b) not allow ICMP messages associated with that UDP/TCP
      flow.  This means PCP (the protocol) and the PCP
      client would need to explicitly permit ICMP messages
      associated with the UDP/TCP flow, if the PCP client
      wants those associated ICMP messages.

I read over BEHAVE's " NAT Behavioral Requirements for ICMP", RFC5508,
and it does not say that ICMP messages should be allowed as a 
side effect of a UDP or TCP flow.

It is my *personal* understanding that 
  (a) BEHAVE expects that a TCP/UDP flow would allow 
      the associated ICMP messages to be NATed.
and 
  (b) Based on (a), I feel PCP should mimic that behavior,
      and should allow the associated ICMP messages as
      a side-effect of opening a TCP/UDP flow.

-d

_______________________________________________
pcp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcp

---

From: Simon Perreault <[email-masked]>
Date: Tue, 07 Dec 2010 15:54:11 -0500

>       a side-effect of opening a TCP/UDP flow.

Fully agreed.

BEHAVE documented this in the specification of NAT64. A NAT64 device
implementing PCP should not need to differentiate between PCP flows and
regular flows. They should all be the same: allow translation of
associated ICMP messages implicitly.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Dave Thaler <[email-masked]>
Date: Tue, 7 Dec 2010 20:55:03 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan
> Wing
> Sent: Tuesday, December 07, 2010 11:36 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [pcp] discuss: open ICMP as side-effect
> 
> (Sorry, resending this one because I neglected to CC the BEHAVE working group.
> Please direct replies to [email-masked])
> 
> This question is CC'd to BEHAVE, as it was suggested BEHAVE should provide
> input on this question.
> 
> The question is simple:  when PCP is used to open a UDP/TCP port, should the
> NAT, as a side effect:
> 
> I read over BEHAVE's " NAT Behavioral Requirements for ICMP", RFC5508, and it
> does not say that ICMP messages should be allowed as a side effect of a UDP or
> TCP flow.
> 

Personal opinion: I agree PCP's behavior should match the
behavior resulting from a data packet that creates a mapping.
So my understanding is the same as yours.

-Dave

---

From: <[email-masked]>
Date: Wed, 8 Dec 2010 11:10:20 +0100

Dear Dan,

For the NAT case: once a mapping is instructed using PCP, ICMP  messages associated with that mapping should also be NATed. 

For the firewall case: an explicit request to allow ICMP messages should be issued by the PCP Client, otherwise ICMP messages should be dropped.

Cheers,
Med  

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Dan Wing
Envoyé : mardi 7 décembre 2010 20:36
À : [email-masked]
Cc : [email-masked]
Objet : [pcp] discuss: open ICMP as side-effect

-d

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************