Subject: Re: [pcp] Comments on PCP Extension for Third Party Authorization (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt)

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 9 Jan 2014 09:38:08 +0000

Hi Suresh,

Thanks for the review. Please see inline

From: Suresh Kumar Vinapamula Venkata [mailto:[email-masked]] 
Sent: Tuesday, January 07, 2014 10:19 AM
To: Tirumaleswar Reddy (tireddy); Reinaldo Penno (repenno); Dan Wing (dwing); Prashanth Patil (praspati)
Cc: [email-masked]
Subject: Comments on PCP Extension for Third Party Authorization (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt)

Hi Tiru, 

Interesting draft,  here are my initial comments.

1. Why can't we achieve this with http://tools.ietf.org/html/draft-wasserman-pcp-authentication-02 and RFC6887.

[TR] RFC 6887 does not have any mutual authentication mechanism between the PCP client and PCP server, hence draft-ietf-pcp-authentication-02 is introduced.  draft-ietf-pcp-authentication-02 solves first party auth problem. 

Third party authorization would be required in scenarios where PCP client does have not have authorization to use specific PCP opcodes, but will get temporary authorization from an application server (e.g. WebRTC Server) trusted by the Network. This requirement (REQ-13) is discussed in http://tools.ietf.org/html/draft-reddy-pcp-auth-req-04.

2. What is the significance of third party authorization here? There will anyway be admin configuration rules, whether to honor a PCP request from a client or not.

[TR] Admin configuration rules are static. With PCP third party authorization clients will get time-bound, dynamic permission to send PCP requests to PCP Server.

3. How would applications detect that they are behind NAT and they should contact PCP server for opening ports for the data connections ?

[TR] PCP client can use techniques like draft-ietf-pcp-dhcp to find the PCP Servers in the network.  PCP Servers would be available if  PCP-aware NAT or firewall exists. By using PCP MAP/PEER opcodes or by using any other mechanism like STUN, client can find out if it is behind NAT or not.

4. This draft proposes a mechanism where holes are punched in firewall/NAT using PCP as per application thus eliminating the need of ALGs. Is my understanding correct? 

[TR] No, that's the goal of PCP itself, not this draft.

Applications behind NAT have to use public IP address and port, in the payload so that no pay load translation happens in the NAT box. Wouldn't that not result in rewite of applications and introduce latency? Or, is there another approach? May be a section with migration strategy would be helpful. 

[TR] With or without third party authorization with PCP, applications will have to rewritten to use public IP address and port learnt from PCP MAP response. 
Third party authorization is assisting applications to be deployed in networks with restrictive firewall policies. For example a PCP-aware firewall with a restrictive policy to permit media streams only when call is made using WebRTC/SIP Server trusted by the Enterprise network can use the technique proposed in this draft to open/close firewall mapping thus eliminating the need of ALGs. 
This way media streams will not permitted if the clients use unknown WebRTC/SIP Servers to make a call.

-Tiru.

-Suresh

---

From: Suresh Kumar Vinapamula Venkata <[email-masked]>
Date: Sat, 11 Jan 2014 01:38:30 +0000

Few followup questions. Please see inline.

On 1/9/14 1:38 AM, "Tirumaleswar Reddy (tireddy)" <[email-masked]>
wrote:

>Subject: Comments on PCP Extension for Third Party Authorization
>(http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.t
>xt)
>
>Hi Tiru, 
>
>1. Why can't we achieve this with
>http://tools.ietf.org/html/draft-wasserman-pcp-authentication-02 and
>RFC6887.
>
>[TR] RFC 6887 does not have any mutual authentication mechanism between
>the PCP client and PCP server, hence draft-ietf-pcp-authentication-02 is
>introduced.  draft-ietf-pcp-authentication-02 solves first party auth
>problem. 
>
>Third party authorization would be required in scenarios where PCP client
>does have not have authorization to use specific PCP opcodes, but will
>get temporary authorization from an application server (e.g. WebRTC
>Server) trusted by the Network. This requirement (REQ-13) is discussed in
>http://tools.ietf.org/html/draft-reddy-pcp-auth-req-04.
SV> I don't see REQ-13 in the draft
http://tools.ietf.org/html/draft-reddy-pcp-auth-req-04.

>
>2. What is the significance of third party authorization here? There will
>anyway be admin configuration rules, whether to honor a PCP request from
>a client or not.
>
>[TR] Admin configuration rules are static. With PCP third party
>authorization clients will get time-bound, dynamic permission to send PCP
>requests to PCP Server.
SV> Who and on what basis will give this authorization? You mean
Application server?
>
>3. How would applications detect that they are behind NAT and they should
>contact PCP server for opening ports for the data connections ?
>
>[TR] PCP client can use techniques like draft-ietf-pcp-dhcp to find the
>PCP Servers in the network.  PCP Servers would be available if  PCP-aware
>NAT or firewall exists. By using PCP MAP/PEER opcodes or by using any
>other mechanism like STUN, client can find out if it is behind NAT or not.
>
>4. This draft proposes a mechanism where holes are punched in
>firewall/NAT using PCP as per application thus eliminating the need of
>ALGs. Is my understanding correct?
>
SV> Correct. But, abstract of this draft talks necessity of opening ports
and weakness with algs. So, I initially assumed it is meant for any
existing application. So was asking for the migration path. Looks like in
addition to applications, there has to be a signaling and an oauth server,
which issues tokens on need basis to its clients for them to raise PCP
requests. Is that correct?
What is the communication channel between signaling server and oauth
server? Before that, are they the same are different? In other words, is
application issued token only when the signaling server detect the need?

>
>Applications behind NAT have to use public IP address and port, in the
>payload so that no pay load translation happens in the NAT box. Wouldn't
>that not result in rewite of applications and introduce latency? Or, is
>there another approach? May be a section with migration strategy would be
>helpful. 
>
>[TR] With or without third party authorization with PCP, applications
>will have to rewritten to use public IP address and port learnt from PCP
>MAP response. 
>Third party authorization is assisting applications to be deployed in
>networks with restrictive firewall policies. For example a PCP-aware
>firewall with a restrictive policy to permit media streams only when call
>is made using WebRTC/SIP Server trusted by the Enterprise network can use
>the technique proposed in this draft to open/close firewall mapping thus
>eliminating the need of ALGs.
SV> What if an application granted a token to raise a PEER request, but
raises a MAP request?

SV>If bob is in same network as alice, then you expect hair pin
communication or direct communication between alice or bob, it is left to
application signaling server's discretion?