Subject: [pcp] pcp-base-25

From: "Dan Wing" <[email-masked]>
Date: Mon, 21 May 2012 11:04:40 -0700

draft-ietf-pcp-base-25 was just submitted.  The major changes to the
document
are introduction of Mapping Nonce to MAP and PEER opcodes, which protects 
against spoofing of the PCP server, and the restriction of the THIRD_PARTY 
option to networks with ACLs that prevent spoofing of the PCP client.

Other changes are summarized in the changes section, which is copied below
for convenience.

Version -25 is available at
http://tools.ietf.org/html/draft-ietf-pcp-base-25

And side-by-side diffs between -24 and -25 are at
http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcp-base-25.txt

If you have feedback, please change the Subject line to something
meaningful.

-d

-----

   o  Clarified the port used by the PCP server when sending unsolicited
      unicast ANNOUNCE.

   o  Removed parenthetical comment implying ANNOUNCE was not a normal
      Opcode; it is a normal Opcode.

   o  Explain that non-PCP-speaking host-based and network-based
      firewalls need to allow incoming connections for MAP to work.

   o  For race condition with PREFER_FAILURE, clarified that it is the
      PCP client's responsibility to delete the mapping if the PCP
      client doesn't need the mapping.

   o  For table, the NAT64 remote peer is IPv4 (was IPv6).

   o  Added a Mapping Nonce field to both MAP and PEER requests and
      responses, to protect from off-path attackers spoofing the PCP
      server's IP address.

   o  Security considerations: added 'PCP is secure against off-path
      attackers who can spoof the PCP server's IP address', because of
      the addition of the Mapping Nonce.

   o  Removed reference to DS-Lite from Security Considerations, as part
      of the changes to THIRD_PARTY from IESG review.

   o  Rapid Recovery is now a SHOULD implement.

   o  Clarify behavior of PREFER_FAILURE with zeros in Suggested
      External Port or Address fields.

   o  PCP server is now more robust and insistent about informing PCP
      client of state changes.

   o  When PCP server sends Mapping Update to a specific PCP client, and
      gets an update for a particular mapping, it doesn't need to send
      reminders about that mapping any more.

   o  THIRD_PARTY is now prohibited on subscriber PCP clients.

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Fri, 25 May 2012 14:32:42 +0200

Dan,

Can we not add the Nonce in an option iso in the MAP/PEER messages? This will provide easier backward compatibility with existing implementations.

Cheers,
Wim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Wing
Sent: maandag 21 mei 2012 20:05
To: [email-masked]
Cc: [email-masked]
Subject: [pcp] pcp-base-25

-d

-----

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

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 25 May 2012 08:25:04 -0700

> From: Henderickx, Wim (Wim) [mailto:[email-masked]]
> Sent: Friday, May 25, 2012 5:33 AM
> To: Dan Wing; [email-masked]
> Subject: RE: [pcp] pcp-base-25
> 
> Dan,
> 
> Can we not add the Nonce in an option iso in the MAP/PEER messages?
> This will provide easier backward compatibility with existing
> implementations.

It's mandatory in order to make it difficult for an off-path attacker
to spoof the PCP server.  If it's optional in the specification, it
will be optional in implementations -- weakening the protocol (bad)
and adding permanent, long-term interop complexity (bad).

I do understand there are pre-RFC implementations in the field, and
I believe they can be accommodated by a PCP server that understands
both -24 and -25.

A PCP server, which supports -24 and -25, can differentiate a PCP
request as being from a -24 or -25 PCP client by using a heuristic.
The heuristic examines bits 192-224 of the MAP opcode request.  In 
-24, those bits are the protocol number and 24 reserved bits which 
must be 0.  In -25, those bits are the first 32 bits of the Mapping 
Nonce.

A -24 client, supporting only TCP and UDP (which I am sure is all
that are supported today), will always set those bits to three
different values,

   0000011000000000000000000000 = protocol=6=TCP
   0010001000000000000000000000 = protocol=17=UDP
   0000000000000000000000000000 = protocol=wildcard

any other values in that 32 bit field means it's from a -25 PCP
client, because bits 192-224 are the first 32 bits of the Mapping
Nonce, which is a random value.  This heuristic will fail if the PCP
client happens to choose a random value where the first 32 bits are
those three values above.

A similar heuristic can be used for the PEER opcode.

-d

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Fri, 25 May 2012 21:15:38 +0200

Dan, if a PCP-25 client is using a nonce which has these 192-224 bits set as one of those heuristic values the PCP-24 server would interpret the packet wrongly.

The option is much better for backward compatibility and lets make it mandatory to ensure it is included in the MAP/PEER opcodes

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: vrijdag 25 mei 2012 17:25
To: Henderickx, Wim (Wim); [email-masked]
Cc: [email-masked]
Subject: RE: [pcp] pcp-base-25

-d

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 25 May 2012 13:02:42 -0700

> Sent: Friday, May 25, 2012 12:16 PM
> Dan, if a PCP-25 client is using a nonce which has these 192-224 bits
> set as one of those heuristic values the PCP-24 server would interpret
> the packet wrongly.

Yes, that is what I meant when I wrote "This heuristic will fail if the PCP
client happens to choose a random value where the first 32 bits are
those three values above."

I am sure there are additional heuristics that can improve the detection,
such as packet length, looking for a legal Option code value where it's
expected for -24, or -- if these pcp-base-24 clients are IPv4 clients -- 
looking for their 96 bit ::FFFF pattern in the Suggested External IP 
Address field.

> The option is much better for backward compatibility and lets make it
> mandatory to ensure it is included in the MAP/PEER opcodes

I am hard pressed to provide backward compatibility with pre-RFC 
implementations, especially by making a security mechanism optional
to accommodate those pre-RFC implementations.  This would create 
permanent harm to PCP, whereas pre-25 versions are temporary.

-d

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 25 May 2012 16:33:01 -0400

Is there actually deployed base of PCP at this point that we need to be backwards compatible with?

I am concerned about the idea that we would need to be backwards compatible with PCP-24, which doesn't even exist in an easily accessible form now that PCP-25 has been published.  

Margaret

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Sat, 26 May 2012 12:51:56 +0200

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]] 
Sent: vrijdag 25 mei 2012 22:33
To: Henderickx, Wim (Wim)
Cc: Dan Wing; [email-masked]; [email-masked]
Subject: Re: [pcp] pcp-base-25

WH> yes

Margaret

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Sat, 26 May 2012 12:54:21 +0200

There is other options to make this in the MAP/PEER header.

Take one of the reserved bits and indicate that a nonce is embedded, put this bit to 1 and append the nonce at the end of the MAP/PEER opcode

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: vrijdag 25 mei 2012 22:03
To: Henderickx, Wim (Wim); [email-masked]
Cc: [email-masked]
Subject: RE: [pcp] pcp-base-25

-d

---

From: Keith Moore <[email-masked]>
Date: Sat, 26 May 2012 07:51:52 -0400

That's not a valid reason to standardize a specification with serious identified security flaws.

Companies that deploy a protocol before the first standard RFC is approved should realize that they're taking a gamble that they're very likely to lose.

Keith

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Sat, 26 May 2012 13:55:17 +0200

Sure and we do it for good reasons. Originally this spec should have been done as per original goal and this was not accomplished. So why would we not try to make it backward compatible if it is easy and possible as I suggested.

Cheers,
Wim
_________________
sent from blackberry

----- Original Message -----
From: Keith Moore [mailto:[email-masked]]
Sent: Saturday, May 26, 2012 01:51 PM
To: Henderickx, Wim (Wim)
Cc: Margaret Wasserman <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [pcp] pcp-base-25

Keith

---

From: Keith Moore <[email-masked]>
Date: Sat, 26 May 2012 08:01:32 -0400

Sorry, no.    There is NOTHING about a spec that is merely an Internet-Draft that says that it's suitable for deployment.   If you deploy prior to standardization, you deserve whatever you get.  

I've seen this used to delay or even hijack specifications too many times.  It's simply not acceptable.

Keith

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Sat, 26 May 2012 14:02:52 +0200

I am not trying to delay anything I am trying to solve a problem.

Cheers,
Wim
_________________
sent from blackberry

----- Original Message -----
From: Keith Moore [mailto:[email-masked]]
Sent: Saturday, May 26, 2012 02:01 PM
To: Henderickx, Wim (Wim)
Cc: [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
Subject: Re: [pcp] pcp-base-25

Keith

---

From: Sam Hartman <[email-masked]>
Date: Wed, 30 May 2012 13:45:29 -0400

>>>>> "Henderickx," == Henderickx, Wim (Wim) <[email-masked]> writes:

    Henderickx,> Dan, Can we not add the Nonce in an option iso in the
    Henderickx,> MAP/PEER messages? This will provide easier backward
    Henderickx,> compatibility with existing implementations.

Hi.  I support Margaret's concern.  In addition, we want the nonce for
all message types defined in the future not just peer/map.
It's possible that some future message we'll define will not have  a
need for a nonce because there is no value at all to being able to
generate it off-path.
However, performing that security analysis  is tricky, tends to miss
possible attack vectors.

Architecturally I don't think an option is the right approach for a
field that we want in all messages.

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Wed, 30 May 2012 19:48:25 +0200

Sam, look at some later emails. I agree that doing an option is probably the wrong solution. What I proposed is using a bit of the reserved field (nonce bit) and keep the nonce where it is.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 30 May 2012 14:13:35 -0400

>>>>> "Henderickx," == Henderickx, Wim (Wim) <[email-masked]> writes:

    Henderickx,> Sam, look at some later emails. I agree that doing an
    Henderickx,> option is probably the wrong solution. What I proposed
    Henderickx,> is using a bit of the reserved field (nonce bit) and
    Henderickx,> keep the nonce where it is.  -----Original Message-----

I saw that mail  but  didn't understand it until this explanation.

I neither object to nor support that solution. I think I understand it
well enough that it won't cause any problems. However other than in a
security capacity I haven't been involved in PCP enough that I'd feel
comfortable explicitly supporting it.

--Sam

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Wed, 30 May 2012 21:17:28 +0200

Sam, understand. Lets have the PCP experts comment on the proposal. Sorry for not being clear in the beginning.

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: woensdag 30 mei 2012 20:14
To: Henderickx, Wim (Wim)
Cc: Dan Wing; [email-masked]; [email-masked]
Subject: Re: [pcp] pcp-base-25

--Sam