Subject: [pcp] Document shepherd re-review of draft-ietf-pcp-base-21

From: Dave Thaler <[email-masked]>
Date: Sat, 14 Jan 2012 01:29:18 +0000

I did a re-review of -21 since the doc shepherd has to sign off

on reviewing "this version" (i.e. the final version submitted

to the IESG) in the proto writeup...

Section 9:

> of this knowledge to decide to which of its PCP servers to send the

> request (e.g., a PCP server on its IPv4 interface or its IPv6

> interface),

The above implies an atypical model where IPv4 and IPv6 are on

separate "interfaces".  The normal (per various RFCs and

implementations) model puts them both on the same interface.

Suggest:

> of this knowledge to decide to which of its PCP server addresses to send the

> request (e.g., an IPv4 address or an IPv6 address),

Similarly in

> If the PCP client has both

> an IPv4 and IPv6 address, and only wants an IPv4 listener, it sends

> one MAP request from its IPv4 interface (if the PCP server supports

> NAT44 or IPv4 firewall) or one MAP request from its IPv6 interface

> (if the PCP server supports NAT64)).

s/interface/address/  (two occurrences)

As worded it doesn't make sense to some readers.

I hadn't noticed this before but in 12.3:
> For IPv4 addresses, which are
> represented using the IPv4-mapped address format (::FFFF:0:0/96), the
> value of the Prefix Length pertains only to the IPv4 portion of the
> address.  Thus, a Prefix Length of 32 with an IPv4-mapped address
> indicates "only this address".  With IPv4-mapped addresses, the
> minimum Prefix length value is 0 and the maximum is 32; for IPv6

> addresses the minimum value is 0 and the maximum is 128.

I personally find the above *really* ugly.  I had expected the change for IPv4-mapped

addrs to also change the prefix length to be consistent with what one would expect

with IPv4-mapped addrs (max is 128 in both cases and starts from the beginning

of the field).

I can't say the spec is "broken" though, just annoying to implement this way and

inconsistent with other RFCs, so maybe we have to just live with it?

Section 16.3.1 typo:

   An attacker, on the path between the PCP client and PCP server, can

   drop PCP requests, drop PCP responses, or spoof a PCP error, all of

   which will effective deny service.  Through such actions, the PCP

   client might not be aware the PCP server might have actually

   processed the PCP request.

s/effective/effectively/

The last sentence quoted actually *vastly* understates the residual vulnerability.

In an earlier review last year I stated "Another DOS vector is via spoofing

a SERVER_OVERLOADED response and sending it to a victim."

Now SERVER_OVERLOADED is called NO_RESOURCES, and the effect is (from 7.3):

   If the result code

   is NO_RESOURCES, PCP client SHOULD NOT send *any* further requests of

   any kind to that PCP server for the indicated error lifetime.

So the effect is not just that the request might have succeeded unbeknownst

to the client, but that an attacker can prevent the PCP client from sending

*any* future requests at all to that server (the attacker can use the

maximum lifetime which is well over 100 years).   Suggest adding after the

paragraph in 16.3.1 quoted above (the one with the typo):

> The PCP client might also be unable to send any further requests of any

> kind to that PCP server.

Also fyi the RFC editor pass will make the following sort of changes...

Section 2.2 uses non-well-known (as defined by the RFC style manual)

acronyms like SCTP and DCCP and those will be expanded on first use,

and probably informational references added.   Optionally you could

do these yourself before the RFC editor asks you to verify their changes.

-Dave

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 18 Jan 2012 19:31:55 -0800

> -----Original Message-----
> From: Dave Thaler [mailto:[email-masked]]
> Sent: Friday, January 13, 2012 5:29 PM
> To: Dan Wing
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Document shepherd re-review of draft-ietf-pcp-base-21
> 
> to the IESG) in the proto writeup.
> 
> 
> 
> Section 9:
> 

Thanks for the suggestion.  Fixed in -22 with that wording.

> s/interface/address/  (two occurrences)

Fixed in -22.

> inconsistent with other RFCs, so maybe we have to just live with it?

This appears to be a carryover from when we had separate OpCodes
(MAP4/MAP6), which had 0-32 (for MAP4) and 0-128 (for MAP6).  I agree 
it is ugly.

Revised to:

        <t>The Prefix Length indicates how many bits of the address
        are used for the filter.  For IPv4 addresses (which are
        encoded using the IPv4-mapped address format (::FFFF:0:0/96)),
        this means valid prefix lengths are between 96 and 128 bits,
        inclusive.  That is, add 96 to the IPv4 prefix length.  For
        IPv6 addresses, valid prefix lengths are between 0 and 128
        bits, inclusive.  Values outside those ranges cause the PCP
        server to return the MALFORMED_OPTION result code.</t>

>    processed the PCP request.

Thanks.

> In an earlier review last year I stated "Another DOS vector is via
> spoofing a SERVER_OVERLOADED response and sending it to a victim."
> 

I went with a closing sentence of:

     An attacker sending a NO_RESOURCES error can cause the PCP
     client to not send messages to that server for a while.</t>

Regarding that attack, -21 had the following text in the MAP
section regarding Lifetime, which protects against excessively
long Lifetimes in responses:

      The PCP client SHOULD impose an upper limit on this
      returned Assigned Lifetime value, and 24 hours is RECOMMENDED.
      This means if the PCP server returns an absurdly long Assigned
      Lifetime (e.g., 5 years), the PCP client will behave as if it
      received a more sane value (e.g., 24 hours).

In -22, I will split this recommendation into 24 hours for MAP success
responses and 30 minutes for MAP error responses.

> Also fyi the RFC editor pass will make the following sort of changes.
> 

Done.

-22 will be posted shortly.

-d