Subject: [secdir] Secdir review of draft-ietf-p2psip-drr-10

From: Brian Weis <[email-masked]>
Date: Tue, 1 Oct 2013 17:16:29 -0700

[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

---

From: Zongning <[email-masked]>
Date: Tue, 8 Oct 2013 06:18:33 +0000

Hi, Brian,

Thanks for your review.

For the 1st and 2nd comments, we agree that Section 13.6 of the base draft does not provide normative language and we didn't mean to change any of the normative security recommendation of the base draft. Therefore, it maybe good to add the following line "The security recommendations of Section 13 of base draft [] are applicable to this document" in the beginning of the security section of DRR draft since Section 13.2 of the base draft provides the normative language you proposed.

For the rest of the comments, please see inline.

> -----Original Message-----
> From: Brian Weis [mailto:[email-masked]]
> Sent: Wednesday, October 02, 2013 8:16 AM
> To: [email-masked]; The IESG
> Cc: [email-masked]
> Subject: Secdir review of draft-ietf-p2psip-drr-10
> 
> [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.
> 
> "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?

[Ning] Section 5.1 provides comparison of the No. of messages between different routing modes.
DTLS session is persistent and there maybe cases where other security mechanisms will be used. So, the table compares the different options.

> 
> - 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?

[Ning] Section 5.1 discuss only the routing of the response message. That's why in DRR it goes through 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?

[Ning] This flag is about 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?

[Ning] This is routing decision in order to verify that the initiator can supply a routable address.

> 
> 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.

[NIng] We agree that the line starting with "Instead" doesn't provide any value in this section, then we can delete it.