Re: [secdir] secdir review of draft-ietf-ppsp-peer-protocol

[Arno Bakker <[e-mail]>]

Hello David and SecDir

thanks for your review. Please see our responses inline. To focus the
discussion, we would like to respond to the editorial issues later.


On 30/06/2014 22:56, David Harrington wrote:
> 
> I will say that, being both an opsdir and secdir reviewer, I was
> greatly encouraged by the table of contents, which shows that a lot
> of consideration was given to security and ops and mgmt. But then I
> started reading the text in the main part of the document, and was
> severely disappointed by what I found. I chose to sample sections of
> the document to see if maybe it was just the opening text that was
> problematic. I don’t think so.
>

Would you be willing to help us with a full review to remove the
ambiguities you observe?


> 6) tech: I feel uncomfortable with section 2 containing examples that
> describe the overall flow. Examples are non-normative text, usually
> contained in a non-normative appendix. These examples describe the
> order of messages, and it is
>

(Some text appears to be lost here.) We want to give the reader an
impression of the operation of the protocol before providing the
details. Is there any acceptable way to do this without resorting to an
appendix?


> 7) in example 2.2, the integrity hash is provided by the peer that is
> providing the (potentially maliciously modified) content. Isn’t that
> like asking the fox to verify that the henhouse is safe?
>

No. The hashes provided by untrusted peers can be verified against the
trusted swarm ID, by virtue of the Merkle hash tree used, as explained
in Section 5 and 6.


> 9) in 3, paragraph 1, it says “this behavior”, but I’m not sure which
> behavior it is referencing. It is unclear whether not sending error
> messages, or discarding messages, or stopping communication, or
> classifying peers is the behavior that allows a peer to deal with
> slow, crashed, or silent peers. I don’t understand HOW any of the
> behaviors mentioned would allow a peer to deal with slow, crashed, or
> silent peers. I do not understand on what basis peers are judged
> “good” or “bad”.
>

A peer that responds with chunks is classified as good, a peer that does
not respond, or does not respond in time is classified as bad, as it
does not help the requester progress. The idea is that in a peer-to-peer
system the content is available from multiple sources (unlike HTTP), so
a peer should not invest too much effort in trying to obtain it from one
particular one.


> 10) in 3, paragraph 2, it says, "Multiple messages are multiplexed
> into a single datagram for
> 
> transmission.  Messages in a single datagram MUST be processed in
> the strict order in which they appear in the datagram.” While this
> might be true for UDP, is this also accurate for TCP or other
> non-datagram transports?
> 

This version of the protocol describes just an UDP encapsulation. If in
the future, TCP would be enabled as a transport, the TCP encapsulation
will address this.


> 11) in 3, paragraph 3, the second sentence seems to contradict the
> first sentence, and since neither is written using RFC2119 keywords,
> it seems to really leave the whole question open to implementer
> interpretation.
>

Perhaps we should rephrase this. We do not prescribe the container
format for the audio/video content, so a content publisher can choose to
use a format that contains multiple assets, or versions of an asset.
A higher-level layer with knowledge of this format should then instruct
the peer protocol on which chunks to download when.


> “ I find “MUST use UDP” inconsistent with “”can also run over other 
> transport protocols”, and “MUST use LEDBAT” inconsistent with “or
> use different congestion control protocols”.
>

The peer protocol was designed with multiple transports in mind. At this
point in time we only define one mapping/encapsulation: UDP. This may be
us not knowing how to convey this multi-protocol intent right. Can you
propose alternative phrasing?


> [jumping ahead …] In 8.3, there is a discussion of multiple swarms
> sharing a UDP port. I’m unsure whether this would work, but since UDP
> is stateless, it might. Do channels work for protocols like TCP?
> 

It does (cf. the two implementations that exist and are in use). The
concept of channels as a way of multiplexing communication over a single
port also has benefit for TCP. It allows you to maximize the usefulness
of the existing TCP connection that may have been complex to set up in a
NAT environment.


> "A SIGNED_INTEGRITY message (type 0x07) consists of a chunk 
> specification, a 64-bit NTP timestamp [RFC5905] and a digital 
> signature encoded as a Signature field in a RRSIG record in DNSSEC 
> without the BASE-64 encoding [RFC4034].”
> 
> Can this work in an implementation with no NTP support?
>

Yes, we are just using the NTP format. We can change the phrasing to
make that more clear.


> 8.14 describes a keep alive message format, but no processing
> instructions.
> 
> Are receiving implementations required to do anything with this
> message? are they supposed to respond somehow?
> 

No, they are not. More people have remarked on this, we will make it
more clear.


> How does the sender of a keep alive determine that the connection is
> still live?
>

By monitoring the incoming traffic from its peer, as per Section 8.15.


> There is no message type for keep alive. If the first octet of the
> keep alive happens to be 0x0a, how does the receiver know whether
> this is a keep alive or a CHOKE message?
> 

Keep alives "are just simple datagrams consisting of the 4-byte channel
ID of the destination only." (Sec. 8.14). By definition, they are only
sent when there are no other messages to send (Sec. 3.12)


> I think this document would be well served by describing the message
> types and formats and their processing in a transport-neutral manner,
> and then describing the transport-specific mapping details, so it is
> clear and unambiguous how the mapping of message sequences to
> datagrams is handled for UDP and DCCP, and how the mapping of message
> sequences should be handled for stream-based protocols like TCP.
> There are some message types, notably keep alive, that I am not sure
> apply in the same way to different transports.
> 

That has been our intention by describing the messages in abstract in
Section 3 and providing a section on how they are mapped to UDP in
Section 8. But apparently this is not clear? What are you missing to put
you on the right foot?


> Multiple messages are multiplexed in a datagram. How are the messages
> delimited? If there is any corruption in one message, how does the
> receiver find the end of the message and the start of the next
> message? If I understand correctly, invalid messages are discarded
> and no error code is sent. If one of the messages are found to be
> invalid, are all messages in that datagram discarded? or are all
> subsequent messages in that datagram discarded? or is it valid to
> process the remaining messages in the datagram after an invalid
> message is detected? If so, would that conflict with the rule that
> all messages must be processed in order?
>

Messages are fixed size, or contain size fields. The phrase
"Invalid messages are discarded, and further communication with the peer
SHOULD be stopped." is supposed to imply that a datagram is discarded as
soon as one offending message is found in it. We will make this more clear.

Regards,
      Arno Bakker et al.