So looking at the extension mechanism in 5.3.3...is there a reason
that the MessageExtension object (5.3.3) has no length? I may have
just missed something obvious, but it seems it needs to have one, if
you want to allow multiple extensions where intermediate peers might
not understand the opaque data. If for example we had two extensions,
a message (I'll use a join for this example) might look like:
Forwarding Header
Message Contents
message_code
message_body
JoinReq
joining_peer_id (NodeID)
overlay_specific_data (variable length)
extensions
....extension 1....
....extension 2....
Security Block
Let's take a hypothetical case where a peer receiving this understands
extension 2, but not extension 1. Even if extension 1 isn't critical
and it knows the type, since what follows is opaque data, if it
doesn't understand the extension, how does it know how long that block
of opaque data is before getting to extension 2?
Perhaps we need to change MessageExtension in 5.3.3. to include a
length prior to the opaque data?
While we're on this, there are several places where the parser seems
to need to know about overlay specific/generic data just to to parse.
The one above seems like it truly won't work without a length (since
we explicitly want to allow for non-critical extensions), but others,
for example the variable overlay_specific_data in some messages (for
example this join) seem to imply that while it will work, the low
level parser itself needs to know about the overlay specific data
(since this can vary by overlay, not implementation). A parser that
doesn't support that overlay parameter can't even parse the message (I
don't think it can even know where the security block starts, so it
technically can't even verify the signature, unless it reads backwards
from the end or something, correct?)
It seems like you need to have the extension-specific/overlay-specific
code inside the basic parser...or am I missing something? (i.e., you
can't write a generic parser that can parse any message, it needs to
have contextual awareness) If this was a deliberate design decision it
seems problematic. I personally don't really like the idea that a
parser needs to understand the overlay specific data just to parse the
message. Obviously you can do this with plug in code or something, but
then we are forcing a particular implementation/design in the design
of the protocol, and the extra bits (lengths) here and there that
would allow a parser to process a message without the extensions
simply aren't that heavy. It seems like a better design to allow a
basic RELOAD parser to parse any message, passing specific data up to
be decoded by higher levels.
David (as individual)
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
