Last Call Review of draft-ietf-p2psip-drr-10
review-ietf-p2psip-drr-10-secdir-lc-weis-2013-10-03-00

[Resent with proper cc]

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

This document describes a routing mechanism for Peer-to-Peer Session Initiation
Protocol (P2PSIP). The routing mechanism in the base P2PSIP protocol specifies
an initiator sending a request message hop by hop through a DHT to a responder,
with the responder returning a reply using the reverse path. The alternative
routing method defined in this I-D describes a shortcut for the response
message. The response is returned directly to the initiator using an IP address
provided by the initiator. This shortcut method is described as an optimization
that is useful in private networks where a self-reported IP address is likely
to be reliable (i.e., no NAT).

The Security Considerations of this I-D depends entirely upon the Security
Considerations of the base document (draft-ietf-p2psip-base-26). It should
probably be expanded to include some more discussion on DRR so that it is
clear. I have some questions to start a discussion to help understand what
might need to be added.

1. The Security Considerations section states

"According to section 13 of the base drat[sic] the forwarding header MUST be
digitally signed protecting the DRR routing information."

I hope it's actually true that the entire DRR message is signed. If so I would
recommend stating this something like "According to section 13 of the base
draft the entire routing message MUST be digitally signed, including the
forwarding header that specifies the DRR routing information".

2. My interpretation reading Section 13 of draft-ietf-p2psip-base-26 is that
all routing messages must also be protected. For example, Section 13.6.3 in the
base document says:

"... whenever a peer establishes a direct connection to another peer it
authenticates via certificate-based mutual authentication. All messages between
peers are sent over this protected channel and therefore the peers can verify
the data origin of the last hop peer for requests and responses without further
cryptography."

I don't believe that DRR messages should be any exception, since the DRR
request messages would be subject to the Eclipse and Sybil attacks described in
the base document. The Security Considerations section in this I-D does not say
that, even though it makes an effort to point out that the messages are
digitally signed. This I-D should also say that the messages are sent over a
protected channel, or else the section needs to have a good justification as to
why the DRR request messages do not require the same protection as SRR
messages. I can't think of what that justification would be though!

3. Table 1 and the preceding paragraph are a little confusing because sometimes
it says the messages are DTLS protected and sometimes they are not. If all of
the routing messages are required to be encrypted then I'm not sure what the
point of this comparison. The "No. of Hops" and "No. of Msgs" fields in Table 1
are also confusing because they seem to be comparing cases where sometimes DTLS
messages are included in the counts and sometimes they are not.

- If it's true that SRR messages must always be protected by DTLS (or a similar
protocol) then why isn't setting up the DTLS session included in the number of
messages in the SRR row? Is that because the DLTS sessions are persistent
between the hops and are assumed to have already been setup? So are you then
including the DLTS setup messages in DRR(DTLS) because you assume they had not
previously setup?

- The DRR rows shows 1 hop in the No. of Hops column, but that doesn't seem to
be quite right because of the asymmetric nature of the DRR protocol. Shouldn't
it really be "log(N) + 1" to indicate the DRR request is log(N) hops and the
DRR reply is one hop?

Overall this section needs to be clarify these things so a reader understands
the relationship between the DRR routing messages and the DTLS secure
connections.

4. When an intermediate peer receives a DRR message with the
IGNORE-STATE-KEEPING flag in the header, is it supposed to not maintain any
security state or just not maintain routing state?

5. Section 4.2 says:

"using DRR SHOULD be discouraged in the open Internet or if the administrator
does not feel he have enough information about the overlay network topology."

Is this due to any security reason, or just because the initiator's address
reported in the Destination structure might be wrong?

6. Section 5.1 says:

"Note that establishing (D)TLS secure connections for P2P overlay is not
optimal in some cases, e.g. direct response routing where (D)TLS is heavy for
temporary connections. Instead, some alternate security techniques, e.g. using
public keys of the destination to encrypt the messages, and signing timestamps
to prevent reply attacks can be adopted."

It is not valuable to speculate on alternative security technique in this
section, because the I-D does not define that security technique. If you think
an alternative to DTLS is useful, then I think that discussion belongs in a new
draft.

Hope that helps,
Brian