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

Request Review of draft-ietf-p2psip-drr
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-09-30
Requested 2013-09-19
Authors Ning Zong, XingFeng Jiang, Roni Even, Yunfei Zhang
Draft last updated 2013-10-03
Completed reviews Genart Last Call review of -10 by Francis Dupont (diff)
Genart Telechat review of -11 by Francis Dupont
Secdir Last Call review of -10 by Brian Weis (diff)
Secdir Telechat review of -11 by Brian Weis
Assignment Reviewer Brian Weis 
State Completed
Review review-ietf-p2psip-drr-10-secdir-lc-weis-2013-10-03
Reviewed rev. 10 (document currently at 11)
Review result Has Issues
Review completed: 2013-10-03

Review
review-ietf-p2psip-drr-10-secdir-lc-weis-2013-10-03

[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