-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/13/2012 02:02 PM, André Becker wrote: > Hi, > > there's an ambiguity in the current draft concerning the ConfigUpdate > mechanism. It remains unclear which node is responsible for checking the > configuration_sequence number (and, additionally, to generate the > appropriate error and the ConfigUpdateReq). Section 5.5.4 states: > > The ConfigUpdate method is used to push updated configuration data across > the overlay. Whenever a node detects that another node has old > configuration data, it MUST generate a ConfigUpdate request. > > A ConfigUpdate request must be generated if an old configuration_sequence > number is detected, but when does a node check it? In section 5.3.2.1 it > says: > > When a destination node receives a request, it MUST check that the > configuration_sequence field is equal to its own configuration sequence > number. If they do not match, it MUST generate an error, either > Error_Config_Too_Old or Error_Config_Too_New. In addition, if the > configuration file in the request is too old, it MUST generate a > ConfigUpdate message to update the requesting node. > > The critical term now is "destination node". If you search the document, > you'll find this term also in section 5.3.4. Here it is used for the node > that reassembles the fragments and checks the signature, meaning the last > node on the message's route. There are several reasons why this node cannot > or should not be meant by section 5.3.2.1. I'm pretty sure that the > configuration_sequence number must be checked by EACH peer, including > intermediate nodes. If only the last node checked the > configuration_sequence number, it would take significantly longer time for > new configuration data to spread in the overlay. Additionally, security > problems would arise, which is even more important. So my suggestion would > be to change the text of section 5.3.2.1 cited above to something > equivalent to the following: > > Whenever a destination node or intermediate node receives a message, it > MUST check that the configuration_sequence field is equal to its own > configuration sequence number. If they do not match, it MUST generate an > error, either Error_Config_Too_Old or Error_Config_Too_New. In addition, if > the configuration file in the request is too old, it MUST generate a > ConfigUpdate message to update the last node that forwarded the message. >
There was a similar discussion last year: https://www.ietf.org/mail-archive/web/p2psip/current/msg06040.html - -- Marc Petit-Huguenin Personal email: [email protected] Professional email: [email protected] Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJPX9QdAAoJECnERZXWan7Elu0QAJj2mAhH3SHuMcwkHk+2pd0K LKdwC2stROdXeEcDkw5pmI3OR2t7StjZTgSgOPNzYsCv6O6qH3ZGtPFAbL6K6gqp IZjj1EvuRd4508B/Ju5gkexKAw2ZpCBsiMtJ0D7xE3b4ZI8PMiPY3mP3CtY5b7pG DLtmkZGzKqXepiUehNUUaxsgaPntRgYvDKmw6hX2pN30KkdWZVaJVNKiOce5iwuz 5VE3TUV6JDJ5BiEFr9EtDCyYjAdnA/CzlULtrUhPxdrzUl5852WjCYXz2J6RrKcy UW4Ag6dk8tVsI8d7kuYeBJIVMPQCJlXaeHpYxYFGIrXTwM7hj0s5zCbnjDn+kCS8 SsLhcnsVcsr9ykYaqdMdOR1FliGQppJcxwbw5FNdzcL2paeLX3tEMDodZAIYFCkH D4mK3SQI1SWqhLu0u3qaC4UOF8c6gSQGMj2YC3BTFnGCTYpzonMszIFpCbDSfgQk FDUdpslw+1nytYdtNggN0aF8OwqW4sIh+k+J3W3l73Ac7ja5UBKmsKLZE21lGbmZ 73JV1O3I8xtV/cVMO1cE9dS4oTlcZuxDc6mHzcNYz5TJnoO9bDB6uhFRR2JY82PP ZEplULT8gNCnGEwLsBScTM0zmP5fGhQNxm//gJXKzswqCJ+9nBkACPGHA8BYcfG3 I7cSxAFpgVkmvf5KJjuI =lhlC -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
