Subject: [pcp] WG status on PCP authentication

From: Dave Thaler <[email-masked]>
Date: Wed, 12 Sep 2012 22:48:01 +0000

Just to circle back on this now that the minutes are posted.

Relevant snippets from the minutes:
> Francis Dupont: How does this compare to just running PCP over DTLS?
>
> Margaret Wasserman: There is currently no draft written to specify how it
>    would work.  You can't "just run" anything over DTLS. It's not that simple.

Summary: we have not explicitly called a question about DTLS.   Mainly
because there's no proposal on the table.   Lacking one with real support,
the WG will go ahead with a proposal that has energy/interest behind it.

> Alain Durand called for show of hands:
> For single port: 23
> For two separate ports: 0

Clear consensus within the room, and I've seen no indication on the list that this
consensus can't be considered confirmed based on the list discussion thus far.

> Alain Durand called for show of hands:
> PCP-specific messages (PCP-specific encoding of authentication information): 5
> Tunneled PANA (embed PANA data within PCP options): 6/7
> Side-by-side (multiplex raw PANA packets and PCP packets over same port): 5/6
> Don't care: 15

Room was basically evenly split between the approaches above, so no
consensus yet, but only about half the WG cares.

> Alain Durand called for show of hands:
> PCP-specific encoding of authentication information: 5
> Some kind of PANA encapsulation: 10 or 11

In my view there was a rough consensus of the room, and so far the list discussion
hasn't changed this ratio in my view.

> Dan Wing: request an interim meeting to discuss solutions, once they've been
>    fleshed out a little

And that's the step we're doing next.   The main comparison point we know about
is between Tunneled PANA vs Side-by-side PANA/PCP.   We can also compare
PCP-specific though it appears to already be in the minority.  If there are other new
proposals to consider (DTLS or whatever) by then, we can, but so far the inertia
seems to be primarily between the PANA variants.   There does seem to be
uncertainty about how they would actually work, so it's important that they be
fleshed out in enough detail that we can have informed discussion at the interim
meeting.

-Dave

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alper Yegin
Sent: Friday, August 17, 2012 1:09 AM
To: Margaret Wasserman
Cc: [email-masked]
Subject: Re: [pcp] Comparison of PCP authentication

On Aug 16, 2012, at 2:38 PM, Margaret Wasserman wrote:

Hi Dacheng,

The conclusion from the meeting was that we will document all three approaches in our document:

Could the chairs please declare what the meeting conclusions and next steps are.

Thanks.

Alper

- PCP Specific
- PANA Encapsulated in PCP
- PANA Demultiplexed with PCP on the same port

Then, we will have an interim PCP conference call to discuss the trade-offs and hopefully decide between them.

Margaret

On Aug 15, 2012, at 10:47 PM, Zhangdacheng (Dacheng) wrote:

Have we got any conclusions on two approaches?  Or we can just support the two options in the draft for the moment and briefly compare their pros and cons, can we?

Cheers

Dcheng

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Margaret Wasserman
Sent: Friday, August 10, 2012 3:21 AM
To: Dan Wing
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [pcp] Comparison of PCP authentication

On Aug 9, 2012, at 2:32 PM, Dan Wing wrote:

If I'm updating security policy on a firewall I want to be able to
audit whether that actually happened.  That requires authentication.

You are saying a PCP client would only want to update firewall policies
if the PCP server supports authentication, otherwise it would tell the
user that it cannot enable the webcam, Internet-connected NAS,
Internet-connected printer, etc.?

I wont presume to guess what Sam is thinking...

However, I am thinking that there will be some clients  that are configured to perform authentication for every request.  For example, there is no reason for a PCP proxy, running in an environment where authentication is required to do a THIRD-PARTY request, to perform a useless round-trip for every THIRD-PARTY request it issues.

Margaret

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

---

From: Alper Yegin <[email-masked]>
Date: Thu, 13 Sep 2012 12:13:24 +0300

Hi Dave,

Thank you for the summary.

> The main comparison point we know about
> is between Tunneled PANA vs Side-by-side PANA/PCP.

Yoshi and I had an offline discussion and concluded that the so-called side-by-side PANA/PCP (or, running PANA over PCP port) is simple and straightforward, compared to tunneled PANA (carrying PANA header and payloads as PCP options -- more like PANA over PCP). So, we diverted our energy to the former and produced http://tools.ietf.org/html/draft-ohba-pcp-pana-02. 

I don't see problems with PANA over PCP port, or benefits with PANA over PCP to motivate me to work the details of PANA over PCP. 
Does anyone see? 
If not, then we'd only have PANA over PCP port to show people in the call.

Alper

On Sep 13, 2012, at 1:48 AM, Dave Thaler wrote:

> because there’s no proposal on the table.   Lacking one with real support,
> Clear consensus within the room, and I’ve seen no indication on the list that this
> consensus can’t be considered confirmed based on the list discussion thus far.
>  
> hasn’t changed this ratio in my view.
>  
> And that’s the step we’re doing next.   The main comparison point we know about
> uncertainty about how they would actually work, so it’s important that they be
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Margaret Wasserman
> [email-masked]
> [email-masked]

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 13 Sep 2012 07:06:58 -0400

Hi Alper,

I understand that you and Yoshi have done some analysis amongst yourselves and come to a conclusion, but my understanding of the direction from IETF 84 was that the WG wanted to go through this analysis together and come to a conclusion about which approach was preferred.

Could you share your reasoning with the rest of us, instead of just your conclusions?  What do you see as the points in favor of the side-by-side (demultiplexing) approach vs. the tunneled PANA (AKA encapsulation) approach?  Are there weaknesses to the encapsulation approach that make the demultiplexing approach more desirable?

Thanks,
Margaret

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 14 Sep 2012 15:51:31 +0900

Last month I posted a rough comparison on the two PANA approaches to
the PCP ML.  I would like to update the comparison after working in
detail on the demultiplexing approach as follows:

Encapsulation/tunneling approach:
- Pros: ???
- Cons:
 -- Encapsulation overhead
 -- Tight coupling of PCP and PANA is needed.  One issue is that some
workaround is needed to carry a PCI (PANA-Client-Initiation) message
which does not fit PCP's request-response type messaging.
Another issue is that double integrity protection can happen after
establishing a PCP SA, where a PANA message carried in the PCP message
is protected by a PANA AUTH AVP and the PCP message itself is
protected by a PCP Authentication Tag.  Double integrity protection
can be considered as overhead.

Demultiplexing/port-sharing approach:
- Pros:
 -- No encapsulation overhead
 -- Loose coupling of PCP and PANA

- Cons: ???

Yoshihiro Ohba

(2012/09/13 20:06), Margaret Wasserman wrote:
> 
> Hi Alper,
> 
> I understand that you and Yoshi have done some analysis amongst 
> yourselves and come to a conclusion, but my understanding of the 
> direction from IETF 84 was that the WG wanted to go through this 
> analysis together and come to a conclusion about which approach was 
> preferred.
> 
> Could you share your reasoning with the rest of us, instead of just 
> your conclusions?  What do you see as the points in favor of the 
> side-by-side (demultiplexing) approach vs. the tunneled PANA (AKA 
> encapsulation) approach?  Are there weaknesses to the encapsulation 
> approach that make the demultiplexing approach more desirable?
> 
> Thanks,
> Margaret
> 
> 
>> Yoshi and I had an offline discussion and concluded that the 
>> so-called side-by-side PANA/PCP (or, running PANA over PCP port) is 
>> simple and straightforward, compared to tunneled PANA (carrying PANA 
>> header and payloads as PCP options -- more like PANA over PCP). So, 
>> we diverted our energy to the former and produced 
>> http://tools.ietf.org/html/draft-ohba-pcp-pana-02.
>>
>> I don't see problems with PANA over PCP port, or benefits with PANA 
>> over PCP to motivate me to work the details of PANA over PCP.
>> Does anyone see?
>>> *From:[email-masked] 
>>> <mailto:[email-masked]>[mailto:[email-masked]]*On 
>>> Behalf Of*Alper Yegin
>>> *Sent:*Friday, August 17, 2012 1:09 AM
>>> *To:*Margaret Wasserman
>>> *Cc:[email-masked] <mailto:[email-masked]>
>>> *Subject:*Re: [pcp] Comparison of PCP authentication
>>> Then, we will have an interim PCP conference call to discuss the 
>>> trade-offs and hopefully decide between them.
>>> Margaret
>>> Have we got any conclusions on two approaches?  Or we can just 
>>> support the two options in the draft for the moment and briefly 
>>> compare their pros and cons, can we?
>>> Cheers
>>> Dcheng
>>> *From:[email-masked] 
>>> <mailto:[email-masked]>[mailto:[email-masked]] 
>>> <mailto:[mailto:[email-masked]]>*On Behalf Of*Margaret Wasserman
>>> *Sent:*Friday, August 10, 2012 3:21 AM
>>> *To:*Dan Wing
>>> *Cc:[email-masked] <mailto:[email-masked]>
>>> *Subject:*Re: [pcp] Comparison of PCP authentication
>>> However, I am thinking that there will be some clients  that are 
>>> configured to perform authentication for every request.  For 
>>> example, there is no reason for a PCP proxy, running in an 
>>> environment where authentication is required to do a THIRD-PARTY 
>>> request, to perform a useless round-trip for every THIRD-PARTY 
>>> request it issues.
>>> Margaret
>>> [email-masked] <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: Alper Yegin <[email-masked]>
Date: Fri, 14 Sep 2012 10:02:55 +0300

Let me add few other things as well.

> can be considered as overhead.

- PANA state machine is aligned (in fact, designed in accordance with) EAP state machine.
Now if we mix PCP into that, is PCP state machine aligned with EAP state machine? This probably would impact the PCP design.

- Defining how PANA header and payloads get encapsulated within PCP (as opposed to over UDP) would require changes to the PANA spec. And those changes are certainly more than simple assignment of few reserved bits as we are doing for the port-sharing approach.

> -- Loose coupling of PCP and PANA

In fact, there has to be a strong justification to invent protocol nesting when the two natively runs separately and do the job already.

Alper

---

From: "Zhangzongjian (Thomas)" <[email-masked]>
Date: Fri, 14 Sep 2012 08:17:01 +0000

Dear all

In charter 11.3 of draft draft-ietf-pcp-base-26, it said: 

The PCP server MUST NOT create mappings for the PCP ports themselves
   (5350 and 5351), and SHOULD have a policy control to deny mappings
   for other ports.  In these cases, the error NOT_AUTHORIZED SHOULD be
   returned.

We need to clarify: 
1.
What kinds port that 5350 and 5351 ports must not be used for mapping?  Internal ports ,  external ports or both?

2.
What kinds protocol that the ports must not be used for mapping?  UDP and others?

3.
It also seems that different scenarios have different result. Such as,  PCP server knows public interfaces and private interfaces in box,  Only PCP server in a box or both PCP server and PCP client.

Regards
Thomas

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Fri, 14 Sep 2012 08:30:44 +0000

Hi, Yoshihiro:

I remember that in one of your previous emails you mentioned that a con of the de-multiplexing approach is its Impact on PANA specification (an Update of RFC 5191 is needed on the use of "Reserved" field.). But you didn't mentioned it here. Maybe I have missed some important discussion. Could you please tell me whether you have find some way to avoid it?

Cheers

Dacheng

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Yoshihiro Ohba
> Sent: Friday, September 14, 2012 2:52 PM
> To: [email-masked]
> Subject: Re: [pcp] WG status on PCP authentication
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 14 Sep 2012 21:29:57 +0900

Hi Dacheng,

A good question.  Actually both approaches has some impact on RFC 5191
to allow PANA to run over a non-PANA port (which would require
updating RFC 5191).  This made me think that the need for updating RFC
5191 to use the Reserved field in the demultiplexing approach is not
considered as a cons.

Regards,
Yoshihiro Ohba

---

From: Sam Hartman <[email-masked]>
Date: Fri, 14 Sep 2012 10:26:41 -0400

Yoshihiro> Hi Dacheng, A good question.  Actually both approaches
    Yoshihiro> has some impact on RFC 5191 to allow PANA to run over a
    Yoshihiro> non-PANA port (which would require updating RFC 5191).
    Yoshihiro> This made me think that the need for updating RFC 5191 to
    Yoshihiro> use the Reserved field in the demultiplexing approach is
    Yoshihiro> not considered as a cons.

Hi.
I have two questions about your comparison:

1) How the encapsulation approach requires tight coupling 

2) Why tight coupling is a bad thing given that we've ruled relays out
of scope.

--Sam

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 15 Sep 2012 00:03:00 +0900

> 1) How the encapsulation approach requires tight coupling

As I mentioned in my comparison, I see the following two issues:

"One issue is that some workaround is needed to carry a PCI
(PANA-Client-Initiation) message which does not fit PCP's
request-response type messaging.  Another issue is that double
integrity protection
can happen after establishing a PCP SA, where a PANA message carried
in the PCP message is protected by a PANA AUTH AVP and the PCP message
itself is protected by a PCP Authentication Tag.  Double integrity
protection can be considered as overhead."

To add more to the 2nd issue, tight coupling of PCP and PANA would be
 needed to avoid double integrity protection (e.g., omitting AUTH AVP
when there is a PCP Authentication Tag, etc...)

> 2) Why tight coupling is a bad thing given that we've ruled relays out

As far as I understand, we ruled out relays to deal with EAP channel
binding without need to tightly couple PCP and PANA (such as carrying
PCP-specific information in a PANA message).  Tight coupling is better
to avoid, IMO.

Yoshihiro Ohba

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 14 Sep 2012 10:41:12 -0700

> Zhangzongjian (Thomas)
> Sent: Friday, September 14, 2012 1:17 AM
> To: [email-masked]
> Subject: [pcp] PCP mapping for 5350 and 5351 ports
> 
> Dear all
> 
> It also seems that different scenarios have different result. Such as,
> PCP server knows public interfaces and private interfaces in box,  Only
> PCP server in a box or both PCP server and PCP client.

During review, this confusion was pointed out.  In -27, the above
is rewritten into a much more general and clear format, and reads
as follows.  I highlighted the specific text regarding the PCP
ports numbers (5350, 5351), and the rest of the new text should 
clarify your questions (2) and (3).  If the new text is still
inadequate, please let me know.

   If no mapping exists for the Internal Address, Protocol, and Port,
   and the PCP server is able to create a mapping using the Suggested
   External Address and Port, it SHOULD do so.  This is beneficial for
   re-establishing state lost in the PCP server (e.g., due to a reboot).
   There are, however, cases where the PCP server is not able to create
   a new mapping using the Suggested External Address and Port:

   o  The Suggested External Address, Protocol, and Port is already
      assigned to another existing explicit or implicit mapping (i.e.,
      is already forwarding traffic to some other internal address and
      port).

   o  The Suggested External Address, Protocol, and Port is already used
      by the NAT gateway for one of its own services.  For example, TCP
      port 80 for the NAT gateway's own configuration web pages, or UDP
      ports 5350 and 5351, used by PCP itself.  A PCP server MUST NOT
................................................^^^^^^^^^^^^^^^^^^^^^
      create client mappings for External UDP ports 5350 or 5351.
......^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

   o  The Suggested External Address, Protocol, and Port is otherwise
      prohibited by the PCP server's policy.

   o  The Suggested External Address, Protocol, or Port is invalid
      (e.g., External Address 127.0.0.1, ::1, a multicast address, or
      the port is not valid for the indicated protocol).

   o  The Suggested External Address does not belong to the NAT gateway.

   o  The Suggested External Address is not configured to be used as an
      external address of the firewall or NAT gateway.

   If the PCP server cannot assign the Suggested External Address,
   Protocol, and Port, then:

   o  If the request contained the PREFER_FAILURE Option, then the PCP
      server MUST return CANNOT_PROVIDE_EXTERNAL.

   o  If the request did not contain the PREFER_FAILURE Option, and the
      PCP server can assign some other External Address and Port for
      that protocol, then the PCP server MUST do so and return the newly
      assigned External Address and Port in the response.  In no case is
      the client penalized for a 'poor' choice of Suggested External
      Address and Port.  The Suggested External Address and Port may be
      used by the server to guide its choice of what External Address
      and Port to assign, but in no case do they cause the server to
      fail to allocate an External Address and Port where otherwise it
      would have succeeded.  The presence of a non-zero Suggested
      External Address or Port is merely a hint; it never does any harm.

-d

---

From: "Zhangzongjian (Thomas)" <[email-masked]>
Date: Mon, 17 Sep 2012 07:46:05 +0000

>       ports 5350 and 5351, used by PCP itself.  A PCP server MUST NOT

1. Internal UPD ports  5350 or 5351 can't be used.
   (1) PCP client and NAT-PMP client use 5350 and 5351 for PCP or NAT-PMP protocol. They will not send a PCP/NAT-PMP mapping request use UDP 5350 or 5351 as internal port. Of cause PCP server can ignore this since no such a request. For security we must not permit use the UDP 5350 and 5351 as internal port in Mapping entry. The attacker behind CGN may send a PCP or NAT-PMP map request with 5350 or 5351 as internal port. If PCP server or NAT-PMP server create a mapping use the 5350 or 5351 as internal UDP port, mass Data packets from public network will be send PCP client or NAT-PMP client.
   (2) As for UPnP, UDP ports 5350 or 5351 may be used as the internal port in UPnP MAP request.  UPnP-PCP interworking send the PCP request with internal UDP port 5350 or 5351 to PCP server and a mapping entry is created by PCP server. Data packet sent to UPnP client from remote will be forward to UPnP-PCP interworking function. The data packets will be discarded by UPnP-PCP interworking device.

2. we can specify the case that Port is already used by the NAT gateway for one of its own services.
  PCP server usually know which interface is internal (from which interface the PCP request is received and private network is behind this interface) or external, such as PCP server in CGN.  That is to say
(1) When only PCP server in NAT gateway, PCP server only listen on UDP port 5351 at internal interfaces. UDP 5350 or 5351 can be used as the external port.
(2)When both PCP server and PCP client in NAT gateway, PCP server will listen on UDP port 5351 at internal interfaces and PCP client will listen on UDP port 5351 and 5350 at external interfaces. UDP 5350 or 5351 can't be used as the external port.
(3)When PCP proxy or UPnP-PCP interworking in NAT gate way, UDP 5350 or 5351 can't be used as the external port. (This out scope of draft-PCP-base)

> From: Dan Wing [mailto:[email-masked]]
> Sent: Saturday, September 15, 2012 1:41 AM
> To: Zhangzongjian (Thomas); [email-masked]
> Subject: RE: [pcp] PCP mapping for 5350 and 5351 ports
>

---

From: "Zhangzongjian (Thomas)" <[email-masked]>
Date: Tue, 18 Sep 2012 02:14:54 +0000

Sorry. 
Disagreed.  Explanation refers to my last mail.

>       ports 5350 and 5351, used by PCP itself.  A PCP server MUST NOT 

The suggested text is :

The Suggested External Address, Protocol, and Port is already used by the NAT gateway for one of its own services.  For example, TCP port 80 for the NAT gateway's own configuration web pages, or UDP ports 5350 and 5351, used by PCP itself.  A PCP server MUST NOT create client mappings for External UDP ports 5350 or 5351. If PCP server knows it's internal (from which interface the PCP request is received and private network is behind this interface) and external interfaces, and there only PCP server lies in NAT gateway, PCP server can create mappings for External UDP ports 5350 or 5351
The UDP ports 5350 or 5351 may be used by PCP client, PCP proxy, UPnP-PCP interworking, it is suggested that the UPD ports 5350 or 5351 MUST NOT be used for creating mapping as the internal UDP port.  

Regards
Thomas

> Sent: Tuesday, September 18, 2012 5:35 AM
> To: Zhangzongjian (Thomas)
> I don't understand if you are agreeing with the text, or disagreeing with
> the text.
> 
> Can you explain what change you want in the text?
> 
> -d
> 
> 
> > From: Zhangzongjian (Thomas) [mailto:[email-masked]]
> > Sent: Monday, September 17, 2012 12:46 AM
> > To: Dan Wing; [email-masked]
> > used
> >    (1) PCP client and NAT-PMP client use 5350 and 5351 for PCP or NAT-
> > PMP protocol. They will not send a PCP/NAT-PMP mapping request use UDP
> > 5350 or 5351 as internal port. Of cause PCP server can ignore this
> > since no such a request. For security we must not permit use the UDP
> > 5350 and 5351 as internal port in Mapping entry. The attacker behind
> > CGN may send a PCP or NAT-PMP map request with 5350 or 5351 as internal
> > port. If PCP server or NAT-PMP server create a mapping use the 5350 or
> > 5351 as internal UDP port, mass Data packets from public network will
> > be send PCP client or NAT-PMP client.
> >    (2) As for UPnP, UDP ports 5350 or 5351 may be used as the internal
> > port in UPnP MAP request.  UPnP-PCP interworking send the PCP request
> > with internal UDP port 5350 or 5351 to PCP server and a mapping entry
> > is created by PCP server. Data packet sent to UPnP client from remote
> > will be forward to UPnP-PCP interworking function. The data packets
> > will be discarded by UPnP-PCP interworking device.
> >
> >   PCP server usually know which interface is internal (from which
> > interface the PCP request is received and private network is behind
> > this interface) or external, such as PCP server in CGN.  That is to say
> > (1) When only PCP server in NAT gateway, PCP server only listen on UDP
> > port 5351 at internal interfaces. UDP 5350 or 5351 can be used as the
> > external port.
> > (2)When both PCP server and PCP client in NAT gateway, PCP server will
> > listen on UDP port 5351 at internal interfaces and PCP client will
> > listen on UDP port 5351 and 5350 at external interfaces. UDP 5350 or
> > 5351 can't be used as the external port.
> > (3)When PCP proxy or UPnP-PCP interworking in NAT gate way, UDP 5350 or
> > 5351 can't be used as the external port. (This out scope of draft-PCP-
> > base)
> >
> >
> >
> >
> >
> >
> >
> > > >    for other ports.  In these cases, the error NOT_AUTHORIZED
> > SHOULD
> > > be
> > > >    returned.
> > > >
> > > > We need to clarify:
> > > > 1.
> > > > What kinds port that 5350 and 5351 ports must not be used for
> > mapping?
> > > > Internal ports ,  external ports or both?
> > > >
> > > > 2.
> > > > What kinds protocol that the ports must not be used for mapping?
> > UDP
> > > > and others?
> > > >
> > > > 3.
> > used