Subject: [pcp] -06 review: third-party

From: Paul Selkirk <[email-masked]>
Date: Mon, 07 Mar 2011 22:39:51 +0000

I thought I understood how third-party mapping requests were supposed
to work, until I read the current text.  Now I'm all kinds of confused.

Changes for -06 say
   o  used "target" instead of "internal", in the hopes that clarifies
      internal address used by PCP itself (for sending its packets)
      versus the address for MAPpings.

However, I think it de-clarifies, and in any case the terms are used
interchangeably or even together:
    internal host (21 uses)
    internal address (9 uses)
    target host (4 uses, including 2 "internal target host")
    target addr (15 uses, including 3 "internal target address")
    internal target (implied "host", 3 uses)

Given that we're still using "external address" for the NAT-assigned
public IP address, I'd feel more comfortable continuing to refer to
the originating source address as the "internal address".  De gustibus
non est disputandum...

3.  Terminology
   Target Address, External Address, Remote Peer Address:
      The address of an Internal Host served by a NAT gateway (typically
      a private address [RFC1918]) or an Internal Host protected by a
      firewall.

This sentence should contain the words "target address", since it's in
a section that defines multiple address types.

10.  THIRD_PARTY Option for MAP and PEER OpCodes
   For Dual-Stack Lite deployments, the PCP server
   only supports this option if the source IPv4 address is the B4's
   source IP address.

Do you mean the source *IPv6* address?  The B4 is only provisioned
with IPv6.  It can proxy requests (in which case the IPv4 source is in
192.0.0.0/29), or it can encapsulate requests (in which case, the IPv4
source is usually a RFC1918 address, and the IPv4 destination is
usually 192.0.0.1).

   For other scenarios, the subscriber has only one
   IPv4 address and this Option serves no purpose (and will only
   generate error messages from the server).

Looking at my (cursory, albeit official) notes from the last interim, we
appear to have removed support for the webcam scenario, where I could
send a request on behalf of a non-PCP-capable device in my
authentication domain (whatever that may be).  Is that correct?

   If a subscriber has more
   than one IPv4 address, the ISP MUST determine its own policy for how
   to identify the trusted device within the subscriber's home.  This
   might be, for example, the lowest- or highest-numbered host address
   for that user's IPv4 prefix.

In other words, we don't know how to deal with multi-homed CPE.
But we already ruled multi-homed CPE out of scope in 6.4.

   Mapping Internal IP Address:  Internal IP address of the mapping.  If
      the length of this Option is 1, this is a 32-bit IPv4 address.  If
      the length of this Option is 4, this is a 128-bit IPv6 address.

This should have the same AF as the source addr of the request.  In
the case of an AF mismatch, the server should return MALFORMED_OPTION.

   51 UNAUTH_TARGET_ADDRESS, indicting the target IP address specified
      is not permitted (e.g., the address does not belong to this
      subscriber, or is otherwise prohibited.).  If this is a MAP
      request, this is a long-term error.

Whereas if this is a PEER request, it's a short-term error?

   A PCP server is configured to permit or to restrict the use of the
   THIRD_PARTY option.  If this option is permitted, any host on a
   subscriber's network network can create, modify, or destroy mappings
   for another host on the network, which is generally undesirable.

I sense a great ambivalence about supporting this option.  Should we
just remove it from the base spec??

   If
   third party mappings are restricted, only a certain host on the
   subscriber's network can perform these operations.

Uh, what?  That's not what I thought we were doing.

   If a PCP server
   is configured to restrict third party mappings, and receives a PCP
   MCP request with a Target Address that does not match the source IP
   address of that request, it MUST generate a UNAUTH_TARGET_ADDRESS
   response.

s/MCP/MAP/

More to the point, if I read this correctly, it says that a PCP client
can only send THIRD_PARTY requests on behalf of itself, which is
completely pointless.  Unless there is some other meaning of the word
"match" of which I am unaware.

   It is RECOMMENDED that PCP servers embedded into customer premise
   equipment be configured to restrict third party mappings.  With this
   configuration, if a user wants to create a third party mapping, the
   user needs to interact out-of-band with their customer premise router
   (e.g., using its HTTP administrative interface).

"restrict" = "refuse"?

   This is because the service provider's PCP server only
   allows a PEER or MAP request containing the THIRD_PARTY option if it
   has the IP address of the subscriber's customer premise router.

s/IP address/source IP address/

   In many common deployments, there is only one IPv4 address
   assigned to a subscriber, and thus the Target Address will always
   match the source address of the PCP message.

Uh, no, the "Target Address" is the Internal Address, which is a host
behind the CPE.  If the CPE proxies the PCP request, and inserts a
THIRD_PARTY option, then the source address is the CPE, and the
"target" address is the originating client.  Again, if the "target"
address is the same as the source address, then the THIRD_PARTY option
is pointless.

   If there are multiple
   IPv4 or multiple IPv6 addresses assigned to a subscriber, the PCP
   server allows the highest-numbered address to use the THIRD_PARTY
   option.  Thus, on a network supporting PCP with multiple addresses
   assigned to a subscriber, the highest-numbered host SHOULD be the
   subscriber's customer premise router.  Upon receiving a MAP or PEER
   request where the Target Address does not match the source IP address
   of the request, the PCP server determines if the source IP address of
   the request is the subscriber's highest numbered address, following
   the procedure above.

Again, we have no idea how to deal with multi-homing, and we're just
making this stuff up.

13.3.  Validating Target Address
   The THIRD_PARTY Option contains a Target Address field, which allows
   a PCP client to create an explicit dynamic mapping for another host.
   Hosts within a subscriber's network cannot create, modify, or delete
   mappings of other hosts, except by using the administrative interface
   of the customer premise router (e.g., HTTP interface), as described
   in Section 10.

So the THIRD_PARTY option is only to be used a) by the CPE, b) when it
is proxying or interworking on behalf of one of its client hosts.  So
the webcam scenario is totally out the window.

If a source address is authorized to make PCP requests, then it should
be authorized to make THIRD_PARTY requests, subject to provider-
specific ingress filtering rules.  e.g. In DS-Lite, the source address
of the encapsulating packet is the IPv6 address of the B4, which is
subject to normal DS-Lite ingress filtering (must be the address of an
authorized subscriber); the source address of the encapsulated request
packet is the internal host, which is also subject to normal DS-Lite
ingress filtering (RFC 1918 address, or other manually configured
authorized address).

				paul

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 7 Mar 2011 18:18:49 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Selkirk
> Sent: Monday, March 07, 2011 2:40 PM
> To: [email-masked]
> Subject: [pcp] -06 review: third-party
> 

Yes, should be IPv6 address.  Will be fixed in -07.

> authentication domain (whatever that may be).  Is that correct?

It still exists, but is limited to only allowing the CPE to do third
party mappings -- this means the user has to authenticate to their 
CPE (e.g., using HTTP).

> But we already ruled multi-homed CPE out of scope in 6.4.

This isn't related to multi-homing at all.  I will clarify with

OLD:
   If a subscriber has more than one IPv4 address,

NEW:
   If a subscriber has more than one IPv4 address (from the same ISP, often 
   called "business-class")

> This should have the same AF as the source addr of the request. 

Don't we need to allow a PCP message sent over IPv6 to refer to an
IPv4 host?
 
> In

Only MAP responses can indicate the duration of the error.  I pointed
out I didn't like that in the Changes, but that's what the WG
requested:

  "o  tightened up text (which was inaccurate) about how long general
      PCP processing is to delay when receiving an error and if it
      should honor OpCode-specific error lifetime.  Useful for MAP
      errors which have an error lifetime.  (This all feels awkward to
      have only some errors with a lifetime.)"

I added "This error can be returned for both MAP and PEER requests."
to make it clear that it can be returned for both MAP and PEER, so
it now reads:

  "51 UNAUTH_TARGET_ADDRESS, indicting the target IP address specified 
   is not permitted (e.g., the address does not belong to this 
   subscriber, or is otherwise prohibited.).  This error can be 
   returned for both MAP and PEER requests.  If this is a MAP 
   request, this is a long-term error."

> just remove it from the base spec??

The functionality is necessary if a user has multiple IP addresses,
such as with Dual-Stack Lite, if the B4 element does either UPnP IGD 
interworking or PCP proxying.

> Uh, what?  That's not what I thought we were doing.

That was absolutely my understanding of what we were doing.

If any host on the internal network can adjust mappings for any
other host, it could accidentally or purposefully delete them
or create them.  

There are ways we could prevent 3rd party deletes of a mapping
(e.g., have the PCP server return a token, which must be 
presented by the PCP client to adjust the mapping).  But I
had understood we wanted the B4 element to be involved with
authorizing the creation/modification/deletion of mappings.

> completely pointless. 

That's right.

> Unless there is some other meaning of the word

Tx.  Changed.

> s/IP address/source IP address/

Tx.

> address is the same as the source address, then the THIRD_PARTY option

I'm sorry -- are you arguing that one IPv4 address is not common
for subscribers??

> Again, we have no idea how to deal with multi-homing, and we're just

This isn't multi-homing.

> is proxying or interworking on behalf of one of its client hosts. 

Correct.

> So the webcam scenario is totally out the window.

To configure the webcam, the user needs to interact with their B4
element somehow, using a mechanism that is out of scope of this
document.  For example, using HTTP, CLI, or whatever.

Configuring a webcam is pretty unique (doesn't happen often), and 
doesn't need to be automated with a protocol such as PCP.

> ingress filtering (RFC 1918 address, or other manually configured

It seems the fault, in the current text, is that it doesn't describe
how that is done.  

I propose:

OLD:
   In many common deployments, there is only one IPv4 address
   assigned to a subscriber, and thus the Target Address will always
   match the source address of the PCP message.   If there are multiple
   IPv4 or multiple IPv6 addresses assigned to a subscriber, the PCP
   server allows the highest-numbered address to use the THIRD_PARTY
   option.  Thus, on a network supporting PCP with multiple addresses
   assigned to a subscriber, the highest-numbered host SHOULD be the
   subscriber's customer premise router.  
NEW:
    In many common deployments, there is only one IPv4
    address assigned to a subscriber, and thus the Target
    Address will always match the source address of the PCP
    message -- making the THIRD_PARTY option
    unnecessary. However, in deployments with multiple IPv4 or
    multiple IPv6 addresses assigned to a subscriber, such as
    Dual-Stack Lite or native dual stack, the PCP server needs
    to know which device is authorized to use the THIRD_PARTY
    option.  With Dual-Stack Lite, the B4 element always
    encapsulates PCP messages with its IPv6 address (which means
    all PCP messages have been authorized by the B4 element) so
    in that environment the PCP server SHOULD allow the
    THIRD_PARTY option from the B4's source IPv6 address.  With
    native dual-stack, an agreement between the subscriber and
    their service provider on which host is the authorized host
    is established, such as authorizing the client's
    highest-numbered IP address to use the THIRD_PARTY option
    (e.g., assign the CPE the highest- numbered IP address).

-d

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

---

From: Paul Selkirk <[email-masked]>
Date: Tue, 08 Mar 2011 06:16:55 +0000

> Don't we need to allow a PCP message sent over IPv6 to refer to an

I'm trying to imagine an CPE sending a request over IPv6 to request a
NAT44 mapping on behalf of an internal IPv4 host.  Oh right, that was
DS-Lite "plain IPv6 mode", and we removed support for that.  So, no.

As I understand it, a mapping request for an IPv4 host must be sent over
IPv4, regardless of whether it's sent directly, proxied, or IWF'd.

> authorizing the creation/modification/deletion of mappings.

Okay, I missed that somehow.

> I'm sorry -- are you arguing that one IPv4 address is not common

No, I'm arguing that the Target Address (aka internal address) is not
necessarily the same as the source address of the PCP message (which
will be the source address of the B4 in the case of DS-Lite).  Or is
this section only talking about the non-DS-Lite webcam scenario?

> document.  For example, using HTTP, CLI, or whatever.

I apologize for belaboring this, but it sounds like you're saying the
webcam scenario is out of scope for PCP.  If so, and THIRD_PARTY is only
applicable to DS-Lite, I'd be fine with that, if the doc would say so in
simple words.  As it is, there's a lot of verbiage, and I can't tell if
there are applicable non-DS-Lite scenarios.

				paul