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

[[e-mail] (Dale R. Worley)]

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).

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.

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

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

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?

Dale