Subject: [secdir] SECDIR Review of draft-ietf-pcp-description-option-02

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 14 Nov 2013 19:56:49 -0500

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The document adds a 'description' option to the PCP protocol. The
description does not have defined semantics in PCP. As such the Security
Considerations relies on the considerations in the PCP specification.

This seems ill advised to me. Even though the field has no semantics in PCP
it is essentially the equivalent of a TXT RR in the DNS, possibly the most
over-used and abused RR in the DNS protocol.

If the description option is added then people are going to start using it
to define site local semantics unless there is some other mechanism for
that purpose. I suggest that the draft authors either add a description of
how to use the PCP mechanisms for this purpose (if applicable) or describe
a mechanism to support this use and preferably providing some sort of
protection against collisions.

Such a mechanism needs to consider the authenticity of the data provided
and the risk that it might disclose data to another application.

-- 
Website: http://hallambaker.com/

---

From: <[email-masked]>
Date: Fri, 15 Nov 2013 08:39:54 +0100

Dear Phillip,

Thank you for the review.

The option as defined in the document does not influence the decision-making process of the PCP Server. Furthermore, a PCP client is not allowed to retrieve a description associated with a state maintained by the server; all what it can do is to erase it, add one or update an existing one.

Given this clarification, do you still think there is an issue that should be addressed? Thanks.

Cheers,
Med

De : Phillip Hallam-Baker [mailto:[email-masked]]
Envoyé : vendredi 15 novembre 2013 01:57
À : [email-masked]; [email-masked]
Objet : SECDIR Review of draft-ietf-pcp-description-option-02

The document adds a 'description' option to the PCP protocol. The description does not have defined semantics in PCP. As such the Security Considerations relies on the considerations in the PCP specification.

This seems ill advised to me. Even though the field has no semantics in PCP it is essentially the equivalent of a TXT RR in the DNS, possibly the most over-used and abused RR in the DNS protocol.

If the description option is added then people are going to start using it to define site local semantics unless there is some other mechanism for that purpose. I suggest that the draft authors either add a description of how to use the PCP mechanisms for this purpose (if applicable) or describe a mechanism to support this use and preferably providing some sort of protection against collisions.

Such a mechanism needs to consider the authenticity of the data provided and the risk that it might disclose data to another application.

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Fri, 15 Nov 2013 04:24:34 +0000

Hello Phillip,

Thanks for the review. Inline with [RP]

From: Phillip Hallam-Baker <[email-masked]<mailto:[email-masked]>>
Date: Thursday, November 14, 2013 4:56 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: SECDIR Review of draft-ietf-pcp-description-option-02
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Cisco Employee <[email-masked]<mailto:[email-masked]>>
Resent-Date: Thursday, November 14, 2013 4:57 PM

If the description option is added then people are going to start using it to define site local semantics unless there is some other mechanism for that purpose.

[RP] Different from DNS a PCP client can not query the description of its mappings.  Can you give me an example of such site local semantics so I can understand better your concern?  I found this:

https://support.google.com/a/answer/2716800?hl=en

But it relies on the fact that DNS clients can query such information.

I suggest that the draft authors either add a description of how to use the PCP mechanisms for this purpose (if applicable) or describe a mechanism to support this use and preferably providing some sort of protection against collisions.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 15 Nov 2013 22:18:27 -0500

On Thu, Nov 14, 2013 at 11:24 PM, Reinaldo Penno (repenno) <
[email-masked]> wrote:

>   From: Phillip Hallam-Baker <[email-masked]>
> To: "[email-masked]" <[email-masked]>, "
> [email-masked]" <
> [email-masked]>
> Resent-From: <[email-masked]>
> Resent-To: <[email-masked]>, "[email-masked]" <
> [email-masked]>, Cisco Employee <[email-masked]>
>  This seems ill advised to me. Even though the field has no semantics in
> PCP it is essentially the equivalent of a TXT RR in the DNS, possibly the
> most over-used and abused RR in the DNS protocol.
>
>  If the description option is added then people are going to start using
> it to define site local semantics unless there is some other mechanism for
> that purpose.
>
>  [RP] Different from DNS a PCP client can not query the description of
> its mappings.  Can you give me an example of such site local semantics so I
> can understand better your concern?  I found this:
>
>    I suggest that the draft authors either add a description of how to
> use the PCP mechanisms for this purpose (if applicable) or describe a
> mechanism to support this use and preferably providing some sort of
>    Such a mechanism needs to consider the authenticity of the data
> provided and the risk that it might disclose data to another application.
>
>
I presume that the reason that information is being fed into this system is
that it is expected that there will be parties that read it out.

Those may not be PCP clients but it is surely not the empty set or what
would be the point of the feature?

If you provide a communication channel between two pieces of apparatus
which has no defined function then expect it to be used in lots of
unexpected ways.

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Sat, 16 Nov 2013 22:23:46 +0000

From: Phillip Hallam-Baker <[email-masked]<mailto:[email-masked]>>
Date: Friday, November 15, 2013 7:18 PM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: SECDIR Review of draft-ietf-pcp-description-option-02

On Thu, Nov 14, 2013 at 11:24 PM, Reinaldo Penno (repenno) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Phillip,

I presume that the reason that information is being fed into this system is that it is expected that there will be parties that read it out.

[RP2] Yes, an admin can see the description associated with each mapping for troubleshooting purposes.

Those may not be PCP clients but it is surely not the empty set or what would be the point of the feature?

If you provide a communication channel between two pieces of apparatus which has no defined function then expect it to be used in lots of unexpected ways.

[RP2] I see it as a troubleshooting tool for admins since client knows its own description or can override if it wants.

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Thu, 21 Nov 2013 10:59:19 +0000

…Crickets..

From: Cisco Employee <[email-masked]<mailto:[email-masked]>>
Date: Saturday, November 16, 2013 at 2:23 PM
To: Phillip Hallam-Baker <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: SECDIR Review of draft-ietf-pcp-description-option-02
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Cisco Employee <[email-masked]<mailto:[email-masked]>>
Resent-Date: Saturday, November 16, 2013 at 2:24 PM