Re: [Pce] Ben Campbell's Discuss on draft-ietf-pce-pceps-15: (with DISCUSS and COMMENT)

[Ben Campbell <[e-mail]>]

Thanks, please also see inline. I will remove sections that do not seem to need further comment.

> On Aug 3, 2017, at 8:35 AM, Dhruv Dhody <[e-mail]> wrote:
> 
> Hi Ben, 
> 
> Thanks for your review. See inline..
> 
>> -----Original Message-----
>> From: Pce [mailto:[e-mail]] On Behalf Of Ben Campbell
>> 

[…]

>> 
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> -3.4, step 2: "Peer validation always SHOULD include a check on whether
>>   the locally configured expected DNS name or IP address of
>>   the peer that is contacted matches its presented
>>   certificate."
>> 
>> Why is that not a MUST? As it is, this need to at least discuss the risks
>> involved if you don't check the identity of the peer cert (here or in the
>> security considerations.)
>> 
> [[Dhruv Dhody]] Reworded to say - 
> 
>          +  Implementations MUST follow the rules and guidelines for
>             peer validation as defined in [RFC6125].  If an expected
>             DNS name or IP address for the peer is configured, then the
>             implementations MUST check them against the values in the
>             presented certificate.

Thanks, that would resolve my DISCUSS position.


>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> Substantive:
>> 
>> - I share Warren's question about why you chose STARTTLS over a dedicated
>> port, especially since the 2nd to last paragraph in 3.2 goes out of its
>> way to mention that. What were the tradeoffs involved that made adding the
>> additional protocol machinery more attractive than allocating a port
>> number?
>> 
> [[Dhruv Dhody]] I have added this text - 
> 
>   This document uses the standard StartTLS procedure in PCEP, instead
>   of using a different port for the secured session.  This is done to
>   avoid requesting allocation of another port number for the PCEPS.
>   The StartTLS procedure makes more efficient use of scarce port
>   numbers and allow simpler configuration of PCEP.

That’s helpful, but it only shows the benefits side of the tradeoff. I assume people thought the additional protocol complexity was a reasonable cost to bear?


> 
>> - 3.2: "Implementations MUST support SHA-256 as defined by [SHS] as
>>          the hash algorithm for the fingerprint."
>> Do you really intend "MUST support" (meaning you have to be able to handle
>> sha-256, but could allow other hashes) vs "MUST use"?
>> 
> [[Dhruv Dhody]] Yes, additional hash algorithm MAY also be supported/used.
> 

Is there an expectation people will use multiple hash algorithms side-by-side? Or is this for purposes of hash agility?

>> - 3.5: "Implementations
>>   that want to support a wide variety of trust models SHOULD expose as
>>   many details of the presented certificate to the administrator as
>> possible
>>   so that the trust model can be implemented by the administrator."
>> "as much as possible" is pretty vague for the a 2119 SHOULD. Since the
>> following sentences also include a SHOULD along with considerably more
>> detail, I suggest dropping the SHOULD in this sentence, and leaving the
>> one in the following sentence.
>> 
> [[Dhruv Dhody]] Ack. 
> 
>> - 3.6: Is the exponential backoff requirement part of the procedures in
>> 5440?
>> The wording suggests that it is not. If so, it needs elaboration here.
>> 
> [[Dhruv Dhody]] It is part of RFC5440, text updated to - 
> 
>   The initiator SHOULD follow the procedure listed in [RFC5440] to
>   retry session setup as per the exponential back-off session
>   establishment retry procedure.
> 
>> Editorial:
>> 
>> - 3.2, paragraph 8: s/"... PCE MUST responds with..."/ "...PCE MUST
>> respond with..."
>> 
> [[Dhruv Dhody]] Ack
> 
>> - 3.4 : "Negotiation of mutual authentication is REQUIRED."
>> Does that mean that the peers must elect to use mutual authentication, or
>> that if they want to use it, they must agree to do so? (The pattern
>> persists throughout the section, but the meaning seems more obvious for
>> some of the
>> others.)
>> 
> [[Dhruv Dhody]] I am also not sure, this was added keeping RFC6614 as our reference. 
> Since TLS supports multiple authentication mode, this might be a say mutual as well as server-only authentication should be supported. But not sure about the word negotiation here. I think we can remove this statement, will do so once you confirm. he 

The important thing is that the intent of the WG is clear. Do you mean to say that the working group intended to allow both server-only and mutual authentication, or do you mean to say the working group did not think about it?

[…]
Thanks!

Ben.