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

[Gonzalo Camarillo <[e-mail]>]

Hi,

this was a secdir review. So, I am adding [e-mail] to the cc:

Cheers,

Gonzalo

On 26/11/2013 9:48 AM, Zongning wrote:
> Hi, Brian,
> 
> Just want to check if you are happy with the new revision (http://www.ietf.org/internet-drafts/draft-ietf-p2psip-drr-11.txt), which we believe addressed your original review comments - as below.
> 
> ==============================================================
> 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 3rd comment:
> [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.
> [Ning] Section 5.1 discuss only the routing of the response message. That's why in DRR it goes through one hop.
> 
> For the 4th comment:
> [Ning] This flag is about routing state.
> 
> For the 5th comment:
> [Ning] This is routing decision in order to verify that the initiator can supply a routable address.
> 
> For the 6th comment:
> [Ning] We agree that the line starting with "Instead" doesn't provide any value in this section, then we can delete it.
> ===============================================================
> 
> Thanks.
> 
> -Ning
> 
>>> -----Original Message-----
>>> From: Brian Weis [mailto:[e-mail]]
>>> Sent: Tuesday, October 22, 2013 7:04 AM
>>> To: Zongning
>>> Cc: Roni Even; 'yunfei zhang'; jiangxingfeng 00215458
>>> Subject: Re: Secdir review of draft-ietf-p2psip-drr-10
>>>
>>> Hi Ning,
>>>
>>> Thanks for the note ... I'll look at the new draft and reply soon.
>>>
>>> Brian
>>>
>>> On Oct 21, 2013, at 12:47 AM, Zongning <[e-mail]> wrote:
>>>
>>>> Hi, Brian,
>>>>
>>>> Could you please review the updated version to confirm if your
>>> comments/suggestions have been appropriately resolved?
>>>>
>>>> URL:
>>> http://www.ietf.org/internet-drafts/draft-ietf-p2psip-drr-11.txt
>>>> Status:          http://datatracker.ietf.org/doc/draft-ietf-p2psip-drr
>>>> Htmlized:        http://tools.ietf.org/html/draft-ietf-p2psip-drr-11
>>>> Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-drr-11
>>>>
>>>> Thanks,
>>>>
>>>> -Ning
>>>>
>>>>> -----Original Message-----
>>>>> From: Brian Weis [mailto:[e-mail]]
>>>>> Sent: Wednesday, October 02, 2013 8:16 AM
>>>>> To: [e-mail]; The IESG
>>>>> Cc: [e-mail]
>>>>> 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.
>>>>>
>>>>> 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
>>>
>>> --
>>> Brian Weis
>>> Security, Enterprise Networking Group, Cisco Systems
>>> Telephone: [phone]
>>> Email: [e-mail]
>