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.
I'd be glad to read your comments,
André
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
