Re: [Pce] Genart last call review of draft-ietf-pce-pceps-14

[Dhruv Dhody <[e-mail]>]

Hi Dale,

Thanks for your further comments, please see inline..

> -----Original Message-----
> From: Dale R. Worley [mailto:[e-mail]]
> Sent: 31 July 2017 06:26
> To: Dhruv Dhody <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: [Pce] Genart last call review of draft-ietf-pce-pceps-14
> 
> Dhruv Dhody <[e-mail]> writes:
> 
> The bulk of these items I either agree with completely or am willing to
> defer to your judgment.  The items that seem to merit further discussion
> are below.  Most of these items are consolidations of several remarks I
> made that seem to be the same fundamental question.
> 
> >> section 3.2: whether error TBA2/2 is distinct from error 1/1
> 
> > [[Dhruv Dhody]] The context of these error are different, one is
> > before TLS establishment (startTLS) and another is during PCEP session
> > establishment (which is after TLS has been established). IMHO it is
> > better to keep them distinct.
> 
> It's more complicated than that:  If a PCE does not like the first message
> it receives, if it implements PCEPS, it replies TBA2/2.  But if it does
> not implement PCEPS, it replies 1/1.  Similarly, a PCC may reject an
> initial message with either of these error codes, depending on the
> situation.  If the other endpoint does not implement PCEPS, it might be
> surprised by receiving TBA2/2, which it has no way of understanding in
> detail (although it will probably simply disconnect, which is what it
> would do in reaction to a 1/1).
> 
[[Dhruv Dhody]] You are right about this case, which I have clarified now -  

   If the PCEP speaker that only supports PCEPS connection (as a local
   policy), receives an Open message, it MUST treat it as an unexpected
   message and reply with a PCErr message with Error-Type set to 1 (PCEP
   session establishment failure) and Error-value set to 1 (reception of
   an invalid Open message or a non Open message).

In your description you mentioned the error TBA2/2, but the description of TBA2/2 is  - 

   A PCEP
   speaker receiving any other message apart from StartTLS, Open, or
   PCErr as the first message, MUST treat it as an unexpected message
   and reply with a PCErr message with Error-Type set to [TBA2 by IANA]
   (PCEP StartTLS failure) and Error-value set to 2 (reception of any
   other message apart from StartTLS, Open, or PCErr message), and MUST
   close the TCP connection.

So receiving of open message would not trigger this error. The new text above would take care of that. 

> A non-implementing endpoint rejects an initial message only with 1/1.
> 
> OTOH, once TLS has been established, then both endpoints can only object
> to the first encrypted message with 1/1.
> 
> There's nothing intrinsically incorrect about this, but it is rather
> complicated, particularly in the upward-compatibility case where the PCC
> is willing to accept either PCEPS-implementing or non-PCEPS-implementing
> connections.
> 
[[Dhruv Dhody]] I have created a table that describe all the cases as part the updated text.  
See https://github.com/dhruvdhody-huawei/ietf/raw/master/Compare.pdf 

> >> section 3.3: the distinction between StartTLSWait and OpenWait
> 
> > [[Dhruv Dhody]] Both timers are wait timers but they wait for
> > different messages and used in different context. Also the values can
> > be set differently based on the deployment.
> 
> There's a complication if a PCE allows both PCEPS and PCEP connections.
> In that case, it does not send its initial message until it receives a
> message from the PCC.  If the message is StartTLS, the PCC wants to
> connect using PCEPS and the PCE sends StartTLS; if the message is Open,
> the PCC wants to connect using PCEP and the PCE sends Open.
> 
> The question is, what timeout does the PCE use while waiting for the
> initial message?  If the connection *will be* PCEPS, it should use
> StartTLSWait (per draft-ietf-pce-pceps), if the connection *will be* PCEP,
> it should use OpenWait (per RFC 5440).  But it does not have the
> information to choose the timer.  The difficulty is that initially, the
> PCE is simulating both a PCEP and a PCEPS device, and using the message it
> receives from the PCC to disambiguate its situation.  But the timeout
> values prescribed for the two situations are different.
> 
> My feeling is that the two situations -- waiting for Open and waiting for
> StartTLS -- are not sufficiently distinguishable to allow prescribing two
> different timers.  Of course, this could be cured by proper configuration
> -- giving the same value to StartTLSWait and OpenWait.
> 
> OTOH, once TLS has been established and the Open messages are awaited,
> both endpoints use OpenWait.  However, this situation is not really the
> same as when the TCP connection has been just been established.  And yet,
> a PCE may be obligated to use the same timer for both situations.
> 
[[Dhruv Dhody]] You have noted something important, thanks for that. 

I would like to fix this by making sure that a PCEP speaker that supports PCEPS does not start OpenWait timer immediately after TCP session, it uses StartTLSWait timer instead. 
I would clarify that the OpenWait timer should be started after TLS establishment only. 

So a PCE that supports connection with TLS only or with/without TLS, it would use StartTLSWait timer initially, the OpenWait timer is started once the TLS is established. 
I also state the StartTLSWait should never be set less than OpenWait timer. 

Please see the diff, I hope these changes should solve the issue.  

> >> 3.2.  Initiating the TLS Procedures
> ...
> > Do you feel strongly about changing this?
> 
> Of course, I'm only a reviewer, you needn't defer to my opinion about
> anything.
> 
> >> Is there a well-defined way for a participant in a TLS connection
> >> start to receive *either* a PCErr message in the clear *or* whatever
> >> comes next in TLS setup -- and know which case has happened?  Is
> >> there a way to use popular modular TLS libraries and have the
> >> application above the library receive such a PCErr message?  I don't
> >> understand TLS nearly well enough to know the answer to this, but it
> >> would probably help implementors if answers were given to these
> questions.
> >
> > [[Dhruv Dhody]] If the TLS handshake is successful, both local and
> > remote parties are aware of this. Same is the case for TLS failure. So
> > receiving an error message in clear will not be a surprise.
> >
> > Also, I checked some of the other documents that describe the use of
> > TLS, but did not find any such handling.
> 
> OK, I think I understand now; my previous comment was based on a
> misunderstanding.  The correct sequence of operations for PCEPS setup is:
> Both endpoints send a StartTLS to each other.  After that, the initiator
> starts the TLS setup.  Alternatively, the PCC sends StartTLS and the non-
> PCEPS-implementing PCE sends a PCErr.  In either case, the PCC sends a
> StartTLS and then listens for a PCEP message in response.
> In any case, neither endpoint is ever in a situation where it could
> receive either a PCEP message or a TLS setup message.
> 
> >> 5.  Backward Compatibility
> ...
> > [[Dhruv Dhody]] Updated.
> >
> >    If a PCEP implementation that does not support PCEPS receives a
> >    StartTLS message, ...
> 
> I think this is a significant improvement, as you can never be too careful
> about upward-compatibility issues, especially when security is involved.
> 
> --
> 
> Concerning the figures:
> 
>                   +-+-+                 +-+-+
>                   |PCC|                 |PCE|
>                   +-+-+                 +-+-+
>                     |                     | Does not send
>                     |      StartTLS       | StartTLS as
>                     |-------------------->| cannot establish
>                     |                     | TLS
>                     |                     |
>                     |<--------------------| Send Error
>                     |      PCErr          | Error-Value 3/4
>                     |                     |
> 
> 
>    Figure 2: Both PCEP Speaker supports PCEPS, But cannot establish TLS
> 
> 
>                   +-+-+                 +-+-+
>                   |PCC|                 |PCE|
>                   +-+-+                 +-+-+
>                     |                     |  Does not support
>                     | StartTLS            |  PCEPS and thus
>                     | msg                 |  sends Open
>                     |-------              |
>                     |       \   Open      |
>                     |        \  msg       |
>                     |         \  ---------|
>                     |          \/         |
>                     |          /\         |
>                     |         /  -------->|
>                     |        /            |
>                     |<------              |
>                     |                     |
>                     |<--------------------| Send Error
>                     |       PCErr         | (non-Open message
>                     |                     |  received)
> 
> 
>              Figure 3: One PCEP Speaker does not support PCEPS
> 
> IIUC, in Figure 2 the error has error-value 3/4 and is "Not supported
> object" ... is that right?  I'd think it would be TBA2/4, "Failure,
> connection without TLS possible" (or TBA2/3, depending on circumstances).
> And in Figure 3, the error is 1/1.  It seems like it would be clearer if
> both the number and the text were shown for the error messages in both the
> figures.
> 
[[Dhruv Dhody]] Error-Value 3/4 meant Error TBA2/3 and Error TBA2/4 as I was focusing only on the error-values and not on error-type, but I agree this could be confusing and I have updated the figures. Also I have added some more figures. 

> Is there also this flow?
> 
>                   +-+-+                 +-+-+
>                   |PCC|                 |PCE|
>                   +-+-+                 +-+-+
>                     |                     |  Does not support
>                     | StartTLS            |  PCEPS and thus
>                     | msg                 |  sends Open
>                     |-------              |
>                     |       \   Open      |
>                     |        \  msg       |
>                     |         \  ---------|
>                     |          \/         |
>                     |          /\         |
>                     |         /  -------->|
>                     |        /            |
>                     |<------              |
>                     |                     |
>                     |-------------------->|
>                     |       PCErr         |
>                     |                     |
> 
> Where the error indicates "Expecting a StartTLS but received an Open"?
> Or is this situation always signaled by the receiver (as in Figure 3)
> rather than the initiator?

 [[Dhruv Dhody]] The text has been added which is generic and works for both PCC/PCE.  

I don't think we need a figure for that :)

Thanks again for your reviews. 

The diff between the last update and this is attached. 

Working copy, Diff: https://github.com/dhruvdhody-huawei/ietf

Regards,
Dhruv 
  
> 
> Dale