site: Extra info in name fields for MSG1, clearer processing
We change the parsing of the names in MSG1 packets to align it with
that used for MSG2..4, abolishing the simple memcmp-based "setupsig"
arrangement.
This means that MSG1 packets, like MSG2..4, can contain extra
information in the name fields.
This results in the following table of behaviours (where "old secnet"
is the version before we introduced additional data at all):
MSG Sent name Old secnet New secnet
1 expected ok ok
1 expected\0extra rejected ok, extra data
1 expected/suffix rejected rejected
1 expect rejected rejected
2-4 expected ok ok
2-4 expected\0extra ok, extra ignored ok, extra data
2-4 expected/suffix wrongly accepted rejected
2-4 expect read overrun rejected
After the new secnet is widely deployed, we will be able to use the
extra data field in MSG1 for public key algorithm agility and public
key rollover.
Also, intend to introduce a new packet which (like MSG1) is addressed
by name rather than the site id; this change makes that easier too.
In detail, we:
* Make site_incoming extract the message type earlier, and use
the message type to choose how to check the address.
* Abolish st->setupsig and st->setupsiglen;
* Break out a function named_for_us, which uses unpick_msg
and then checks the names;
* Arrange to keep the unpicked message from named_for_us and
reuse it in process_msg1.
* Eliminate checking dest==0 for name-addressed packets.
This last point constitutes a change to the implemented protocol. The
old code would treat a packet as name-addressed iff the destination
"index" was zero. However, the requirement to send a zero in this
field is not documented. After this patch, peers which send MSG1 with
a non-zero destination index will have their messages honoured rather
than discarded. But we do document the restriction.
There is no other significant functional implication of this last
point. Peers which send non-MSG1s with zero destination index will
have their packets rejected both before and afterwards (although there
may be a change in whether a NAK is sent and in logging) but anyway
those peers are broken because all of our generated indexes are
nonzero.
A downside of this change is that we will now unpick an incoming MSG1
repeatedly until we find which site instance wants it. But this
unpicking is not particularly arduous.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>