Hi,
Thanks for the work. Very nearly converged on everything.
Section 3.2
Are you sure that you want to send an Error message in response to a
bad PCMonRep?
Sending an Error in response to a PCMonReq is useful because it
cancels the request and means the sender does not continue to wait
or a PCMonRep. But sending an Error in response to a PCMonRep does
not seem to have any use except to load the network. For example,
what is the state of the outstanding PCMonReq in this situation?
What is the sender of the PCMonRep supposed to do when it receives
the Error message?
More appropriate would be for the receiver of the bad PCMonRep to
raise an alert to the operator and to put the sender of the bad
message on a blacklist so that it never send it another PCMonReq.
Well yes but ... error message are not only useful for the PCC to
clean states but for troubleshooting on both sides, especially on the
PCC side where the absence of reply can either be interpreted as a
lost request, overloaded PCE, malformed request, .... Furthermore, it
is inline with the general approach taken by PCEP when a message is
received that does not carry a mandatory object.
Well, in fact there is no state to be cleaned by this error message.
The error is sent in response to a PCMonRep. The PCMonRep has already
cleaned the state.
I agree the error message can be used for trouble shooting, but not in the
way you say. You say:
the absence of reply can either be interpreted as a
lost request, overloaded PCE, malformed request
but there is no absent reply in this case. There is not normally a positive
response to a PCEMonRep, so there is nothing expected.
Furthermore, you say: "Furthermore..."
But what does PCEP do with a malformed PCErr?
Section 6.7 of PCEP says:
The PCErr message is sent by a PCC or a PCE in response to a request
or in an unsolicited manner.
So, here it says implicitly that it is not sent in response to a response.
But I believe we had this same "discussion" about Error-Type 8. :-)
My biggest concerns are:
1. Broken system such that bad PCMonRep is sent in every case
or sporadically (or even as part of an attack). This will always
trigger an error response.
This is not so important, so perhaps the text in this I-D can stand.
[Which means I am not demanding you change this I-D.]
2. A tight loop where a PCC and PCE object to each other's PCErr
messages and respond with a new PCErr message which is objected
to with a PCErr message, etc.
But perhaps this should have been in the PCEP spec.
Section 4.4
- You need to explain that setting the C bit and a congestion
duration of zero has meaning. If it has no meaning, you don't
need the C bit.
It is stated in the text: "When cleared this indicates that the PCE is
not congested and the "Congestion Duration" field MUST be set to
0x0000".
C=0 means "no congestion on the PCE".
Hmm, yes. I saw that in the I-D.
This says:
C=0 means CD MUST be 0x0000
What is meant by:
C=1, CD=0x0000 ?
If this has meaning, what is it?
If it has no meaning, then we do not need the C bit since:
CD=0x0000 is equivalent to C=0
and
CD!=0x0000 is equivalent to C=1
And anyway, why is the Congestion object present with the C bit clear?
Surely the object should simply be absent?
That removes the duplication between the C bit in the Congestion object and
the C bit in the Monitoring object.
- Although it verges on telling the implementer how to write code
I think some advice is needed on what to do when a
CONGESTION object is received with the C bit set. There
are two aspects...
- How long has the CONGESTION object taken to propagate
from the reporting PCE to the PCC (might not be one hop)?
- What should the receiver do with the Congestion Duration
value?
You already know what I think about this ;-))) It is in my opinion
very much implementation dependent, don't you think ?
First of all, specifying what the PCC should be in this document is a
bit awkward. Indeed, it could be for pure management
purposes (out of band) or in the context of a particular path
computation request (e.g. after a PCreq local timeout). Even
in that latter case, the PCC may decide to back-off and retry or
select another PCE, depending on the urgency of the request
which is usually context dependent (the PCC may decide to select
another PCE for an already retransmitted request if the
priority is > X, ....). Furthermore the PCC may also be a function of
the reported congestion value, ...
I would argue that documenting this behavior is out of scope (not a
monitoring issue) and very much implementation/application specific.
Well...
There is very little in the draft about the meaning of the Congestion
Duration field. In fact, *all* we have is:
Congestion duration - 16 bits: This field indicates in seconds the
estimated congestion duration.
Maybe we can address my concerns by beefing this text up a bit. For
example...
Congestion duration - 16 bits: This field indicates in the amount of time
in seconds that the responding PCE expects that it may continue to be
congested from the time that the response message was generated. The
receiver MAY use this value to decide whether or not so send further
requests to the same PCE.
Section 6, case 2)
You should refer back to Section 5.
Yes.
But note also that you have an explicit case (section 4.3) where
policy causes the message to be processed but an object to be left
out of the reply.
Not sure to see which case you're referring to ?
Section 4.3 says...
If allowed by policy, the PCE includes a PROC-TIME object within a
PCMonRep or a PCRep message
That means that you can set a policy that causes the object to be left out
even if requested by setting the P bit of the MONITORING object.
So, part of the request is prohibited by policy, but a response (not an
error) is still generated.
Perhaps add a note:
Compare this case with that in Section 4.3 where part of the request is
prohibited by policy, but the request is still processed.
Section 9
Does the information gathered by monitoring represent any additional
vulnerability? Could an attacker gain interesting information by
snooping this?
I think the Congestion object is a good and lightweight way to
attack a PCE deployment.
Yes indeed but similarly to regular PCReq messages for which we have
suggested security mechanism.
You should note this and suggest that this makes the use of security
mechanisms important. You may also need to node that there is a
chain of trust model here such that even if one PCE ensures that it
uses security, the information it supplies can be changed on a hop
further upstream. Therefore, a consistent security model across all
cooperating PCEs is desirable.
Right but again this is true for regular PCRep message.
Text Added (let me know if you think that this is sufficient):
Yes this is good.
The point is not to provide additional security techniques, but to explain
to the deployer the additional vulnerabilities that might make them want to
turn on the existing security techniques. You now have this covered.
Just a couple of points to reach agreement on then:
- spell-check
- IPR boilerplate
- idnits
- post
Cheers,
Adrian
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
