Re: [pcp] draft-ietf-pcp-proxy-01

Hi Tiru,

Please see inline.

Cheers,
Med 

>-----Message d'origine-----
>De : Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] 
>Envoyé : jeudi 17 janvier 2013 13:27
>À : BOUCADAIR Mohamed OLNC/OLN; pcp@ietf.org
>Objet : RE: [pcp] draft-ietf-pcp-proxy-01
>
>Hi Med,
>
>Please see inline [Tiru]
>
>> -----Original Message-----
>> From: mohamed.boucadair@orange.com 
>[mailto:mohamed.boucadair@orange.com]
>> Sent: Wednesday, January 16, 2013 7:00 PM
>> To: Tirumaleswar Reddy (tireddy); pcp@ietf.org
>> Subject: RE: [pcp] draft-ietf-pcp-proxy-01
>> 
>> Hi Tiru,
>> 
>> Many thanks for the comments.
>> 
>> Please see inline.
>> 
>> Cheers,
>> Med
>> 
>> >-----Message d'origine-----
>> >De : Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]
>> >Envoyé : vendredi 21 décembre 2012 07:43
>> >À : BOUCADAIR Mohamed OLNC/OLN; pcp@ietf.org
>> >Objet : Re: [pcp] draft-ietf-pcp-proxy-01
>> >
>> >Hi Med,
>> >
>> >Comments
>> >
>> >[1] Section 3 PCP Server Discovery and Provisioning :
>> >You may also want to add details that PCP Proxy would use
>> >similar mechanism just like PCP client to discover the PCP server.
>> 
>> Med: I updated the text with an explicit ref to Section 8.1 
>of draft-ietf-pcp-
>> base.
>> 
>> >
>> >[2] Section 5 Control of the Firewall :
>> >Firewall rules would be typically to block any unsolicited
>> >traffic from outside to inside. For PCP request/response this
>> >will not be a problem, but would have issues with unsolicited
>> >ANNOUNCE. In this case PCP Authentication looks mandatory to
>> >handle man-in-middle attacks trying to act as PCP Server.
>> 
>> Med: is that a problem even if the pcp server is known to 
>the pcp proxy ?
>
>The PCP server could be in a different administrative domain 
>that may or may have IP source guard; attacker can spoof the 
>well-known IP address of the PCP server and send ANNOUNCE. PCP 
>authentication looks mandatory.

Med: Why is this specific to PCP Proxy case? In this leg, the PCP Proxy is acting as a PCP Client. Security considerations discussed in the base spec apply here.

>
>> 
>> >
>> >[3] Section 5 : Replace REMOTE_PEER_FILTER with FILTER option
>> 
>> Med: Fixed. Thanks.
>> 
>> >
>> >[4] Section 8 MAP/PEER handling : you may also want to clarify
>> >PCP proxy behavior when PCP client uses THIRD_PARTY option.
>> 
>> Med: I updated the text to explicitly require the PCP server 
>follows the pcp
>> server recommendations detailed in section 13.1 of 
>draft-ietf-pcp-base.
>> 
>> >
>> >[5] Section 10.1 Multiple PCP servers : There could be another
>> >scenarios that PCP proxy would forward the PCP request to one
>> >of the PCP servers depending on the fields set in PCP request
>> >(for specific use cases please refer to
>> >http://tools.ietf.org/html/draft-rpcw-pcp-pmipv6-serv-discovery
>> >-00 ,
>> >http://tools.ietf.org/html/draft-chen-pcp-mobile-deployment-02#
>> >section-8)]
>> >
>> 
>> Med: what change you want to see in that section? Thanks.
>
>The PCP proxy based on various fields set in the PCP request, 
>client identity will forward the PCP request to different PCP 
>servers. For example in the case of PMIPv6 based on the UE 
>subscription traffic offload rules will be installed on the 
>MAG. MAG acting as PCP proxy can either handle the PCP request 
>in the local access network itself or relay the PCP request to 
>the PCP server in the home network. I guess similar mechanism 
>would be needed in 3GPP network with SIPTO.

Med: I added this sentence: 

"The PCP Proxy MAY rely on some fields (e.g., Zone ID [I-D.penno-pcp-zones] in the PCP request to redirect the request to a given PCP Server."

>
>> 
>> >[6] How is it ensured that only the PCP proxy can communicate
>> >with the PCP server and not any other PCP client ?
>> 
>> Med: Should this be part of the PCP Proxy spec ?
>
>This can be solved by simple techniques like ACL to block PCP 
>client from communicating directly with the PCP server. You 
>can mention it in security considerations.

Med: I added this sentence to the security section: 

"The device embedding the PCP Proxy MAY block PCP requests directly sent to the PCP Server. This control can be enforced using access control list."

>
>--Tiru.
>
>> 
>> >
>> >--Tiru.
>> >
>> >> -----Original Message-----
>> >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] 
>On Behalf Of
>> >> mohamed.boucadair@orange.com
>> >> Sent: Friday, August 17, 2012 5:33 PM
>> >> To: pcp@ietf.org
>> >> Subject: [pcp] draft-ietf-pcp-proxy-01
>> >>
>> >> Dear all,
>> >>
>> >> A new version is now available online:
>> >> http://tools.ietf.org/html/draft-ietf-pcp-proxy-01
>> >>
>> >> The main changes in -01 are as follows:
>> >>
>> >> * The reference architecture is updated: the PCP proxy is
>> >not restricted to
>> >> the CP router deployment case.
>> >> * Add a new section to specify the behaviour when the PCP
>> >Proxy is not
>> >> co-located with a NAT function
>> >> * Add a new section for mappings repair
>> >> * More discussion for the multiple PCP Servers scenario
>> >> * Text is cleanup
>> >>
>> >> A detailed diff is available here:
>> >>
>> >>  http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-proxy-01
>> >>
>> >> Please review this new version and provide input.
>> >>
>> >> Cheers,
>> >> Med
>> >> _______________________________________________
>> >> pcp mailing list
>> >> pcp@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/pcp
>> >
>> >
>