[BGPCEP-242] Correct behavior with respect to dynamic password change should be defined Created: 17/Jun/15  Updated: 03/Mar/19  Due: 17/Dec/15  Resolved: 23/Nov/15

Status: Resolved
Project: bgpcep
Component/s: PCEP
Affects Version/s: Bugzilla Migration
Fix Version/s: Bugzilla Migration

Type: Improvement
Reporter: Vratko Polak Assignee: Claudio David Gasparini
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


 Description   

It is possible to re-configure TCPMD5 password for a client during ODL runtime using restconf. See the last URL/data in https://wiki.opendaylight.org/view/BGP_LS_PCEP:TCP_MD5_Guide#PCEP_2

Implementation in Lithium works fine with this dynamic password re-configuration only up to the moment session is established. But the behavior when password is re-configured while session is established is not very secure.

For example, session is not terminated when passwords no longer match.
Another example: After deleting password element, PCC is still able to reconnect using its password.
Note that these examples are not strictly bugs, as there is no documentation on which behavior should be expected.

Thus it would be nice to define the desired behavior for Beryllium.

 Comments   
Comment by Robert Varga [ 08/Sep/15 ]

RFC2385 does not provide a clean protocol for changing keys while retaining sessions. If the session keys do not match, the session will eventually be torn down via TCP channel communication breaking down.

It is perfectly possible for the key change to be synchronized by means of meatware, hence I think the exact policy as to what to do when the key is changed is up to the user of TCP/MD5 (in this case PCEP) to implement a predictable behavior.

I think in this case the server socket key should be changed first and then all the sessions should be torn down. That would be predictable, but unfortunately unforgiving in case of mismatched keys. I guess it is trade-off BGPCEP project can make.

Comment by Vratko Polak [ 05/Nov/15 ]

Links to Robot logs of suites testing one particular scenario for Lithium [0] and Beryllium [1] snapshots. The scenario replaces client configuration with new data without password element (test case Unset_Password) and then it is expected the topology data immediately vanishes (test case Topology_Unauthorized_4).

[0] https://jenkins.opendaylight.org/releng/view/bgpcep/job/bgpcep-csit-1node-userfeatures-only-stable-lithium/lastSuccessfulBuild/robot/report/log.html#s1-s3

[1] https://jenkins.opendaylight.org/releng/view/bgpcep/job/bgpcep-csit-1node-userfeatures-only-beryllium/lastSuccessfulBuild/robot/report/log.html#s1-s3

Comment by Claudio David Gasparini [ 12/Nov/15 ]

Li: https://git.opendaylight.org/gerrit/#/c/29314/
Li: https://git.opendaylight.org/gerrit/#/c/29313/

Working correctly now in Lithium.

https://jenkins.opendaylight.org/releng/view/bgpcep/job/bgpcep-csit-1node-userfeatures-only-stable-lithium/lastSuccessfulBuild/robot/report/log.html#s1-s3

Be: https://git.opendaylight.org/gerrit/#/c/29539/

Comment by Claudio David Gasparini [ 23/Nov/15 ]

be: https://jenkins.opendaylight.org/releng/view/bgpcep/job/bgpcep-csit-1node-userfeatures-only-beryllium/lastSuccessfulBuild/robot/report/log.html#s1-s3

successfully passed

Generated at Wed Feb 07 19:12:27 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.