Re: [Lsr] Solicit feedback on draft-ietf-lsr-pce-discovery-security-support-01

["Adrian Farrel" <[e-mail]>]

Hi Qin,

I didn't see any response to this email, so I thought I should chip in with
some (old, old, old) memories and context.

tl;dr I am generally supportive of this work, but I think a little
fine-tuning is needed.

If I recall correctly, the situation when 5088 and 5089 were produced was
that there was mission creep. The initial idea was to discover the existence
of PCE-capable routers in the network, but it was quickly realised a
specific address might be preferable for reaching the PCE, so there was need
for the PCE Discovery TLV to contain an address, and it was decided to
encode it as a TLV. Then the rot set in and we determined there were some
other useful pieces of information to encode. And then we thought that it
would be helpful to have an array of capability bits.

At this point the IGP working groups started to get worried. As Les and Acee
noted, the concern was that we would be carrying "large" amounts of data in
the IGP that was not directly related to the primary purpose of the IGP
(packet routing) or even the secondary purpose (TE). We had a bit of a fight
on our hands at this stage because the PCE implementers had already built
stuff, and the IGP "purists" were digging in. So we agreed to stabilise with
"this far and no further" and the lines in 5088/9 that say:
   No additional sub-TLVs will be added to the PCED TLV in the future.
   If a future application requires the advertisement of additional PCE
   information in OSPF, this will not be carried in the Router
   Information LSA.
The idea was that it would be OK to define new capability bits, but not to
add more TLVs.

I don't recall being delighted by this outcome at the time, but it certainly
allowed us to move forward. It seemed to me that PCEs were not the only
devices exchanging non-routing information in the IGP, and if there was a
concern about volume of data or convergence time, then this seemed a bigger
problem that needed a more general resolution. On the other hand, IETF
consensus is what it is.

The approach that others have taken in this situation is to add flags as
needed, but to put the additional discovery information in the PCEP Open
message. Thus, at a high level, a PCC can decide whether there is any point
in opening a PCEP session with a PCE, but may have to try the session to
find out exactly what options are available and might, at that time,
discover that the PCE is not suitable.

Looking at your draft, the addition of the two bit flags is easy and
uncontroversial. 

It is the addition of the Key-ID and Key-Chain-Name sub-TLVs that cause you
to want to change the RFCs. And I think you have a special case here because
using the TCP security mechanism, the PCEP Open message would come too late
to exchange the relevant information. That is, you need the security
information to set up the secure TCP session before the PCEP Open messages
can be exchanged.

This point could usefully be made more clear in the document. That is, why
you cannot use the alternate mechanism for exchanging PCE characteristics
and capabilities. After that has been done, I think that it would be
reasonable to allow the approach you are describing subject to LSR WG
consensus. (The alternative, which is perfectly acceptable within the
architecture and within some operational environments, is configuration. But
configuration doesn't work in the larger use cases, and another mechanism
would constitute a third way of exchanging PCE information, and that sounds
ridiculous.)

However, while I think that you should be allowed through the doorway, I
don't think you should leave the door open behind you. That means that you
should update 5088/9 to allow your new sub-TLVs, but you should leave in
place the ruling that no more new sub-TLVs are allowed. I *think* that is
what you're trying to do, but I don't think your Section 4 is the right way
to do that - it is not necessary to make edits to the old documents to make
this change, you can simply say... 
Section 4 of [RFC5088] states that no new sub-TLVs will be added to the PCED
TLV, and no new PCE information will be carried in the Router Information
LSA. This document updates RFC 5088 by allowing the two new sub-TLVs defined
in this document to be carried in the PCED TLV of the for use in the Router
Information LSA.
Section 4 of [RFC5089] states that no new sub-TLVs will be added to the PCED
TLV, and no new PCE information will be carried in the Router CAPABLITY TLV.
This document updates RFC 5089 by allowing the two new sub-TLVs defined in
this document to be carried in the PCED TLV of the for use in the Router
CAPABILITY TLV.

Along the way, we're also going to need to do some work on Section 7. The
whole point of your draft is to exchange information about security
features, and that makes it highly sensitive if it can be attacked. For
example, just toggling the two new capability bits can be a downgrade
attack. And tweaking the content of the new TLVs would, I imagine, enable
man-in-the-middle attacks. At the least, I think you have to use "MUST" to
insist that the IGP is protected for authentication and integrity of the
PCED TLV if the mechanism described in your draft is used. And I think you
should try to describe some of the risks.

I'm not sure how sensitive the new TLVs are to snooping, but you should note
that section 8 of RFC 5088/9 points out that "OSPF/IS-IS provides no
encryption mechanism for protecting the privacy of LSAs" and that if access
to this information can make the secure TCP session any less secure then the
approach is at risk.

Best,
Adrian

-----Original Message-----
From: Lsr <[e-mail]> On Behalf Of Qin Wu
Sent: 04 June 2019 05:18
To: [e-mail]; [e-mail]
Subject: [Lsr] Solicit feeback on
draft-ietf-lsr-pce-discovery-security-support-01

Hi, Folks:
Draft-ietf-lsr-pce-discovery-security-support was adopted by LSR WG in
December 2018 due to security importance for routing protocol.
Julien shared his comments and also help look for comments and feedback from
PCE WG on this draft during poll adoption call in LSR WG.
Recently we made a quick update to
draft-ietf-lsr-pce-discovery-security-support without technical content
changes.
We would like to solicit comments and feedback again on this draft. Thanks
in advance!

-Qin