Subject: [pcp] PCP server: listen on private side only

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 Mar 2011 20:43:01 -0800

I don't expect this is a surprise, as I believe everyone expects PCP to 
work this way, but pcp-base doesn't currently say anything about if 
the PCP server listens for PCP requests from all interfaces or what.  So
I am adding the following to Section 6.2, "General PCP Server: 
Processing a Request":

   A PCP server MUST only listen for incoming requests from its internal, 
   subscriber-facing interface.  That is, it MUST NOT listen for requests 
   from its public-facing interface (e.g., the Internet).

-d

---

From: Simon Perreault <[email-masked]>
Date: Thu, 10 Mar 2011 09:43:03 -0500

>    from its public-facing interface (e.g., the Internet).

s/MUST/SHOULD/

"Don't tell me what I can't do in my network!" ;)

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: Francis Dupont <[email-masked]>
Date: Thu, 10 Mar 2011 15:57:38 +0100

In your previous mail you wrote:

   
=> this was already proposed (in fact I believed it was in the last
base I-Ds in the Security Considerations) but I had and still have a
concern about the wording (not the idea):
 - the term 'listen' is heavily bound to TCP so IMHO clearly misleading

 - it is not possible to implement this as it is described because
  the 'receive packets from this interface' operation doesn't exist.

I propose to reword it by saying:
 - the PCP server MAY bound sockets to its internal, subscriber-facing
  interface address(es) only
 - the PCP server MUST check the source address of requests and MUST
  drop by default any request coming from the public-facing side
  (e.g., the Internet).
BTW I tried with the notion of incoming interface for received
requests but without a guideline an implementor could try to use
some kind of receiving interface socket options when it is in fact
not the right way, so even you can introduce the requirement at
a higher/formal level with the incoming interface you have to
explain what it means for the implementation.

IMHO this catches the idea.
BTW if you find a better wording please send it to me: we have the
same issue (even more complex so harder to write) for the PCP Proxy
(what I call internally the split-horizon anti-spoofing).

Thanks

[email-masked]

---

From: Alain Durand <[email-masked]>
Date: Thu, 10 Mar 2011 06:48:28 -0800

I think this should be tuned to allow for the PCP server to listen to an administrative interface as well.
What you want to say is that the PCP server MUST NOT listen to queries coming from the Internet side
for obvious security reasons.

  - Alain.

On Mar 10, 2011, at 9:43 AM, Simon Perreault wrote:

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

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 Mar 2011 07:42:49 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, March 10, 2011 6:58 AM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [pcp] PCP server: listen on private side only
> 
> 

'Checking source address' is insufficient, though, if someone
on the Internet spoofs the source address.  I went with:

        <t>A PCP server processes incoming requests on the PCP port
        (44323) from its internal, subscriber-facing interface.  The
        PCP server MUST drop (ignore) requests that arrive on its
        public-facing interface (e.g., the Internet).</t>

-d

---

From: Simon Perreault <[email-masked]>
Date: Thu, 10 Mar 2011 11:00:26 -0500

>         public-facing interface (e.g., the Internet).</t>

What if the PCP server is not colocated with the NAT and has no
public-facing interface?

PCP is a client-server protocol over UDP. I don't even get why we're
talking about "interfaces" in the first place. That's for the NAT to
consider.

Simon

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 Mar 2011 09:46:47 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Simon Perreault
> Sent: Thursday, March 10, 2011 8:00 AM
> To: [email-masked]

        <t>A PCP server processes incoming requests on the PCP port
        (44323) from subscribers.  The PCP server MUST drop (ignore)
        requests that arrive on its public-facing interface (e.g., the
        Internet).</t>

If that doesn't work, please suggest wording.

-d

---

From: Simon Perreault <[email-masked]>
Date: Thu, 10 Mar 2011 12:48:42 -0500

> If that doesn't work, please suggest wording.

An attempt:

        <t>A PCP server processes incoming requests on the PCP port
        (44323) from subscribers.  The PCP server MUST drop (ignore)
        requests from non-subscribers (e.g., the Internet).</t>

Simon

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 Mar 2011 10:14:25 -0800

> From: Simon Perreault [mailto:[email-masked]]
> Sent: Thursday, March 10, 2011 9:49 AM
> To: Dan Wing
> Cc: [email-masked]

Taking that and Alain's suggestion into account, how is this:

        <t>A PCP server processes incoming requests on the PCP port
        (44323) from subscribers or an operator-configured interface
        (e.g., from the ISP's network operations center).  The PCP
        server MUST drop (ignore) requests that arrive from elsewhere
        (e.g., the Internet).</t>

-d

---

From: Simon Perreault <[email-masked]>
Date: Thu, 10 Mar 2011 13:15:05 -0500

>         (e.g., the Internet).</t>

Works for me.

Simon

---

From: Francis Dupont <[email-masked]>
Date: Fri, 11 Mar 2011 00:39:13 +0100

'Checking source address' is insufficient, though, if someone
   on the Internet spoofs the source address.

=> the purpose of the two items I proposed is to eliminate obviously
incorrect requests for topological reasons. Note there are stronger
checks on requests as a security requirement is to not allow a
subscriber (so a priori someone who is not a subscriber) to manage
an explicit dynamic mapping on the behalf of another subscriber.

   I went with:

=> so I raise a concern against this wording as it can't be implemented
using the POSIX standardized socket API.
   
Regards

PS: about the SHOULD question IMHO the best is to add a MUST for
a policy and the default policy is this MUST for the incoming interface
(with appropriate wording). It is stronger than a SHOULD and allows
exceptions.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 11 Mar 2011 00:42:39 +0100

=> what do you think about my proposed wording? IMHO it doesn't show
this problem.

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Fri, 11 Mar 2011 02:00:18 +0100

Works for me.
   
+1 (it doesn't explain how to do it but what to do should be enough)

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 11 Mar 2011 10:02:27 -0800

> Sent: Thursday, March 10, 2011 5:00 PM
> To: Simon Perreault
> Cc: Dan Wing; [email-masked]

Great, thanks.
-d