Subject: [secdir] Secdir Review of draft-ietf-pcp-third-party-id-option-04

From: Tina TSOU <[email-masked]>
Date: Wed, 11 Nov 2015 04:14:03 +0000

Dear all,

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.

** Technical **

* Section 7, page 11:

I think you should make comments regarding the (privacy) implications of employing identifiers such as MAC addresses when essentially any other value -- e.g. a long-enough random number would do.

Besides, you should comment on how the ID can be somehow validated, and what could happen if a client were able to predict the ID employed by other clients.

** Editorial **

* Section 1, page 2:

>    The IETF has specified the Port Control Protocol (PCP) [RFC6887] to

>    control how packets are translated and forwarded by a PCP-controlled

>    device such as a network address translator (NAT) or firewall.

Please replace "and" with "and/or", since a firewall will not translate packets.

* Section 1, page 2:

>    This document focuses on the scenarios where the PCP client sends

>    requests that concern internal addresses other than the address of

>    the PCP client itself.

s/the scenarios/scenarios/

(since at least at this point in the text you have not yet mentioned what those scenarios are about)

* Section 1, page 2:

>    There is already an option defined for this purpose in the RFC 6887

>    [RFC6887] called the THIRD_PARTY option.

Please rephrase as:

"There is already an option defined for this purpose in [RFC6887], called the THIRD_PARTY option."

* Section 1, page 3:

> CGN deployments

Please expand the acronym on first usage.

* Section 1, page 3:

>    This applies to some of the PCP deployment scenarios that are listed

>    in Section 2.1 of RFC 6887 [RFC6887],

Just remove "RFC 6887" (the rfc number is already included by the ref).

* Section 1, page 3:

>    in particular to a Layer-2

>    aware NAT which is described in more detail in Section 3, or GI-DS-

>    Lite [RFC6674] and ds-extra-lite [RFC6619].

You refer to RFC6619 as "ds-extra-lite", but such RFC does not even

include that term. Thoughts?

* Section 3, page 4:

>   The scenarios serve as examples.  This document does not restrict the

>    applicability of the THIRD_PARTY_ID to certain scenarios.

Please replace "THIRD_PARTY_ID" with "THIRD_PARTY_ID option" (here, and

in other places)

* Section 3, page 4:

> The THIRD_PARTY_ID

>    can also be used for the firewall control

Please remove the "the".

* Section 3.2, page 7:

> tunnel ID of tunnel(BRAS, CGN)

(two instances of this). Please rephrase as "ID of the tunnel (BRAS, CGN)".

* Section 4, page 9:

Why use "TBD" and "TBD-1" if there's a single value to be assigned?

* Section 4, page 9:

> are to be set As

s/As/as/

Thank you,
Tina

---

From: joel jaeggli <[email-masked]>
Date: Mon, 16 Nov 2015 21:41:07 -0800

On 11/10/15 8:14 PM, Tina TSOU wrote:
> Dear all,
> 
>  
> 
> 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.
> 
>  
> 
>  
> 
> ** Technical **
> 
>  
> 
> * Section 7, page 11:
> 
> I think you should make comments regarding the (privacy) implications of
> employing identifiers such as MAC addresses when essentially any other
> value -- e.g. a long-enough random number would do.
> 

Thank you Tina, thank is quite useful review.

joel

> 
> Besides, you should comment on how the ID can be somehow validated, and
> what could happen if a client were able to predict the ID employed by
> other clients.
> 
>  
> 
>  
> 
> ** Editorial **
> 
>  
> 
> * Section 1, page 2:
>

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 17 Nov 2015 10:58:17 +0000

Dear Tina,
Thank you very much for your thorough review.
Please find replies inline.

> -----Original Message-----
> From: Tina TSOU [mailto:[email-masked]]
> Sent: Mittwoch, 11. November 2015 05:14
> To: The IESG; [email-masked]; [email-masked]
> Subject: Secdir Review of draft-ietf-pcp-third-party-id-option-04
> 
> Dear all,
> 
> 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.
> 
> ** Technical **
> 
> * Section 7, page 11:
> 
> employing identifiers such as MAC addresses when essentially any other value -
> - e.g. a long-enough random number would do.
> 
> what could happen if a client were able to predict the ID employed by other
> clients.

Here is a proposal for improving this section:
OLD
   As this option is related to the use of the THIRD_PARTY option the
   corresponding security considerations in Section 18.1.1 of RFC 6887
   [RFC6887] apply.  Especially, the network on which the PCP messages
   are sent must be fully trusted.  The THIRD_PARTY_ID option might
   carry privacy information like location or profile information.
   Means to protect unauthorized access to this information should be
   put in place.
NEW
   As this option is related to the use of the THIRD_PARTY option the
   corresponding security considerations in Section 18.1.1 of RFC 6887
   [RFC6887] apply.  Especially, the network on which the PCP messages
   are sent must be fully trusted.  The THIRD_PARTY_ID option might
   carry privacy sensitive information like location or profile information. 
   Where possible, randomly assigned numbers should be preferred to 
   privacy sensitive information to be carried as values by the 
   THIRD_PARTY_ID option. Random numbers should be assigned such 
   That an attacker cannot guess which number is assigned to which 
   third party. Anyway, means to protect unauthorized access to 
   values carried by the THIRD_PARTY_ID option should be put in place.
END
Would this address your concerns?

> Please replace "and" with "and/or", since a firewall will not translate packets.

In the past, the RFC Editor used to remove occurrences of "and/or" in RFCs. 
What about the following alternative, which is semantically equivalent to and/or: 
"such as a network address translator (NAT), a firewall, or a combination of both"?

> s/the scenarios/scenarios/

Agreed.

> "There is already an option defined for this purpose in [RFC6887], called the

Agreed.

> Please expand the acronym on first usage.

Agreed.

> Just remove "RFC 6887" (the rfc number is already included by the ref).

Agreed.

> include that term. Thoughts?

Here is a proposal that addresses your issue:
OLD
   This applies to some of the PCP deployment scenarios that are listed 
   in Section 2.1 of RFC 6887 [RFC6887], in particular to a Layer-2 
   aware NAT which is described in more detail in Section 3, or GI-DS- 
   Lite [RFC6674] and ds-extra-lite [RFC6619]. 
NEW
   This applies to some of the PCP deployment scenarios that are listed
   in Section 2.1 of [RFC6887], in particular to a Layer-2 aware NAT
   which is described in more detail in Section 3, as well as in other
   scenarios where overlapping address spaces occur like in [RFC6674] or
   [RFC6619].
END
Would this solve your issue?

> Please replace "THIRD_PARTY_ID" with "THIRD_PARTY_ID option" (here, and

Agreed.

> >    can also be used for the firewall control

Agreed.

> (two instances of this). Please rephrase as "ID of the tunnel (BRAS, CGN)".

Agreed.

> Why use "TBD" and "TBD-1" if there's a single value to be assigned?

There was no space for "-1" in the figure. All other TBDs are numbered as "TBD-X". We will make sure that the RFC Editor gets the right message.

> s/As/as/

Agreed.

Thanks and best regards,
    Juergen

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Nov 2015 11:04:07 +0000

Hi Juergen,

(Caveat: I've yet to read this, but I have a question nonetheless:-)

> Would this address your concerns?

Can you say why the value ever needs to be a long lived identifier
and why a random number that changes periodically isn't always good
enough?

Ta,
S.

> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 17 Nov 2015 11:27:36 +0000

Hi Stephen,

The common use case that we foresee for the THIRD_PARTY_ID which is the one we have used in all trials so far is the use for encoding a tunnel ID that is needed to identify a third party in addition to the IP address of the third party that is carried by the THIRD_PARTY option. In these cases the IP address in not unique and an additional tunnel ID is needed to uniquely identify the third party. 

The standard for the THIRD_PARTY option (RFC 6887) mandates that it carries the IP address of the third party. There is no alternative specified that would allow replacing it by a random number. The THIRD_PARTY_ID is open to this option, but since it is usually used in combination with the THIRD_PARTY option, the use of a short-lived identifier does not always seem to be recommendable, particularly since this would require additional exchange between PCP client and PCP server to agree on the mapping between actual tunnel IDs and randomly chosen IDs. 

Best regards,
    Juergen

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Dienstag, 17. November 2015 12:04
> To: Juergen Quittek; Tina TSOU; The IESG; [email-masked]; draft-ietf-pcp-third-
> [email-masked]
> Subject: Re: [secdir] Secdir Review of draft-ietf-pcp-third-party-id-option-04
> 
> 
> Hi Juergen,
> 
> value -
> >> (since at least at this point in the text you have not yet mentioned what
> those
> >> scenarios are about)
> >>
> >> * Section 1, page 2:
> > There was no space for "-1" in the figure. All other TBDs are numbered as
> "TBD-X". We will make sure that the RFC Editor gets the right message.
> >
> >>
> >> * Section 4, page 9:
> >>> are to be set As
> >>
> >> s/As/as/
> >
> > Agreed.
> >
> > Thanks and best regards,
> >     Juergen
> >
> >
> >>
> >> Thank you,
> >>
> >> Tina
> >>
> >>
> >

---

From: Tina TSOU <[email-masked]>
Date: Thu, 19 Nov 2015 13:21:28 +0000

Dear Juergen,

Yes, that seems to address it.

Thank you,
Tina

-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]] 
Sent: Tuesday, November 17, 2015 6:58 PM
To: Tina TSOU; The IESG; [email-masked]; [email-masked]
Subject: RE: Secdir Review of draft-ietf-pcp-third-party-id-option-04

Dear Tina,

> To: The IESG; [email-masked]; 
> [email-masked]
> I think you should make comments regarding the (privacy) implications 
> of employing identifiers such as MAC addresses when essentially any 
> other value -
> Besides, you should comment on how the ID can be somehow validated, 
> and what could happen if a client were able to predict the ID employed 
> by other clients.

Agreed.

Agreed.

Agreed.

Agreed.

> Please replace "THIRD_PARTY_ID" with "THIRD_PARTY_ID option" (here, 
> and in other places)

Agreed.

Agreed.

Agreed.

Agreed.

Thanks and best regards,
    Juergen

---

From: Tina TSOU <[email-masked]>
Date: Thu, 19 Nov 2015 13:22:45 +0000

Dear Juergen,

It'd be great to have some analysis that differentiates cases in which including some privacy-sensible information is warranted vs cases where some randomly defined ID would do.

Including a tunnel ID is fine (if it's just a "small" number). Including a MAC address results in more serious privacy implications.

Thank you,
Tina

-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]] 
Sent: Tuesday, November 17, 2015 7:28 PM
To: Stephen Farrell; Tina TSOU; The IESG; [email-masked]; [email-masked]
Subject: RE: [secdir] Secdir Review of draft-ietf-pcp-third-party-id-option-04

Hi Stephen,

Best regards,
    Juergen

> To: Juergen Quittek; Tina TSOU; The IESG; [email-masked]; 
> draft-ietf-pcp-third- [email-masked]
> >> These comments were written primarily for the benefit of the 
> >> security area directors. Document editors and WG chairs should 
> >> treat these comments
> just
> >> I think you should make comments regarding the (privacy) 
> >> implications of employing identifiers such as MAC addresses when 
> >> essentially any other
> value -
> >> and what could happen if a client were able to predict the ID 
> >> employed by other clients.
> >
> Can you say why the value ever needs to be a long lived identifier and 
> why a random number that changes periodically isn't always good 
> enough?
> 
> Ta,
> S.
> 
> 
> >
> >>
> >> ** Editorial **
> >>
> >> * Section 1, page 2:
> >> Please replace "and" with "and/or", since a firewall will not 
> >> translate
> packets.
> >
> > What about the following alternative, which is semantically 
> > equivalent to
> and/or:
> > "such as a network address translator (NAT), a firewall, or a 
> > combination of
> both"?
> >
> >>
> >> * Section 1, page 2:
> and