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

[joel jaeggli <[e-mail]>]

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:
> 
>>    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
> 
>  
>