Subject: Re: [pcp] base-02 feedback

From: "Dan Wing" <[email-masked]>
Date: Mon, 3 Jan 2011 17:41:14 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Francis Dupont
> Sent: Monday, December 27, 2010 6:36 AM
> To: [email-masked]
> Subject: [pcp] base-02 feedback
> 
> I am implementing PCP for DS-Lite, I found some issues:
>  - we need an error code for too short packets:
>   * packets smaller than 8 bytes should be simply ignored
>   * packets smaller than the corresponding OpCode should raise an
>    'malformed request' fatal error code.
> 
>  - we need a maximal size (I propose 1024 bytes: enough for everything
>   and in general avoiding fragmentation) and a behavior for too large
>   requests (simply ignoring them is not enough).
>   BTW the 'malformed request' error code is usable for this too,
>   the error response should be truncated to 1024.
>   IMHO we need a new tracker item for this point.

Added text to -02 to say maximum is 1024 octets and minimum is 8 
octets.  Added new MALFORMED_REQUEST error code.

>  - HONOR_EXTERNAL_PORT must be a mandatory (code >= 128) option.
>   I understand the reasons to make it optional (code == 6) but this
> means
>   a positive response could be generated without a successfully
> processing.

Done.  It is now 130.

>  - what to do when a mandatory option is in a request where it makes
>   no sense, for instance (mandatory) HONOR_EXTERNAL_PORT in a delete
> request?
>   I propose to use MALFORMED_OPTION or a new fatal error code.

I added:

  If an option with value greater than 128 exists but that option 
  does not make sense (e.g., the HONOR_EXTERNAL_PORT option is 
  included in a request with lifetime=0 (indicating a delete request)), 
  the request is invalid and generates a MALFORMED_OPTION error.

but I would like to say something better; that text is not specific
enough to cause two implementors to do the same sorts of checks.

>  - I'd like to extended the AMBIGUOUS error code to cases where a
> dynamic
>   mapping conflicts with a requested pinhole. The difference with
>   the current meaning is a REMOTE_PEER option won't be enough to solve
> it.
>   BTW the error stays transcient.

I added:

  If a dynamic mapping already exists for the internal IP address 
  and internal port, and the REMOTE_PEER option is not included in 
  the request, it is impossible to establish a pinhole.  In such a 
  case, the PCP server responds with the error AMBIGIUOS.  The client 
  needs to choose a different internal port and send a new PCP request.

>  - I strongly disagree with the client port text (6.1.1 page 13):
>   * there is no reason to require port randomization

There are reasons, as discussed in draft-ietf-tsvwg-port-randomization.
Do you disagree with draft-ietf-tsvwg-port-randomization, or are you
saying PCP is immune from the risks described in
draft-ietf-tsvwg-port-randomization?

>   * to bind for port randomization is a heavy requirement for client
>    implementations

We could water this down to leaving it up to the underlying OS
to choose the source port for PCP requests, I suppose.

>   * the 'single UDP port' wording is bad: we should only recommend
>    a client uses the same source UDP port to (re)transmit a request
>    to a server (BTW this means the UDP socket should be connected).

The server doesn't care what port the PCP request used, so even 
retransmissions shouldn't matter.

>  - same text, minor concerns
>   * The 'repeat 4 times' wording is ambiguous: does it mean there
>    should be up to 4 retransmits or up to 4 transmits?

Adjusted to:

   This is repeated 4 times (for a total of 5 transmissions to each 
   server). If, after these transmissions, no PCP server has responded 
   the PCP client SHOULD abort the procedure.

>   * there is nothing about what to do with transient errors
>    (try another server, restart the whole procedure after XX (I propose
> 60)
>     seconds, etc)

Added this, but not sure if this is entirely what you are asking:
  
  Upon receiving a response (success or error), the PCP client does not 
  change to a different PCP server.  That is, it does not "shop around" 
  trying to find a PCP server to service its (same) request.

-d

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

---

From: Francis Dupont <[email-masked]>
Date: Tue, 04 Jan 2011 13:06:33 +0100

In your previous mail you wrote:

     and internal port,

=> add protocol too

     and the REMOTE_PEER option is not included in 

   
=> PCP is either special so we have to define something stronger like a
nonce mechanism, or not special so it must be considered as a common
application protocol (*).
So I still strongly disagree and at least this should be in the
security considerations.

   
=> yes (BTW draft-ietf-tsvwg-port-randomization doesn't suggest to
bind client sockets)

   
=> the idea was to be able to use the UDP port for delayed response matching.
I don't object to put nothing in the document.

   >    60) seconds, etc)

   
=> I am not convinced it is the right thing on a NETWORK_FAILURE...
And of course it doesn't address my concern.

Regards

PS: I'll print, read and comment the new version for the end of the week.
PPS: (*) in fact both are true according to the context: either any attack
is possible between the client and the server: strong (stronger than port
randomization) security is required, or no attack is possible, e.g.,
DS-Lite & co: port randomization doesn't bring something.
Note I don't say ephemeral port randomization is bad: it is a good idea
but it is orthogonal to PCP security requirements.

---

From: <[email-masked]>
Date: Tue, 4 Jan 2011 13:36:34 +0100

Hi Francis,

Since PCP does not support any security feature to prevent against malicious answers; having randomly generated port number makes the attack harder. Personally, I was advocating for having a random 32 bits (transaction-id) + 16 random bits (port number). But, it seems there was no consensus about this.

I suggest to maintain the text about port randomization as it is.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Francis Dupont
Envoyé : mardi 4 janvier 2011 13:07
À : Dan Wing
Cc : [email-masked]
Objet : Re: [pcp] base-02 feedback

=> add protocol too

   

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Francis Dupont <[email-masked]>
Date: Tue, 04 Jan 2011 16:44:35 +0100

Since PCP does not support any security feature to prevent against
   malicious answers; having randomly generated port number makes the
   attack harder. Personally, I was advocating for having a random 32
   bits (transaction-id) + 16 random bits (port number). But, it seems
   there was no consensus about this.
   
=> if we need a nonce 16 bits are far from to be enough and IMHO
32+16 too. And according to security analysis in fact either no
security feature other than for common traffic is needed (DS_lite case
for instance), or mutual authentication (which includes more than
a nonce mechanism) is required, so port randomization is either
useless or not enough.

=> it makes no sense. I still recommend to avoid to give a false
sense of security with this kind of things. And if we want to talk
about this it should be in the security considerations which are
still empty BTW...

Regards

---

From: Francis Dupont <[email-masked]>
Date: Tue, 04 Jan 2011 18:05:44 +0100

=> I am not satisfied with the new text which is IMHO not enough accurate.
I propose:
 - drop (ignoring or log an error) request and response shorter
  than 8 octets (the idea is one can't do anything with them)
 - return MALFORMED_REQUEST 1024 octets response on a request
  longer than 1024 octets
 - drop (ignoring or log an error) response longer than 1024 octets

Now we have to specify when the second check is done, I propose:
 -1 check length < 8
 -2 check version
 -3 check response bit in opcode
 -4 check supported opcode
 -5 check length > 1024
In 2, 4 and 5 the error response length must be <= 1024
The idea is to get useful errors about bad headers if possible.

I have another point: what to do with message length not
a multiple of 4?

Thanks