[P2PSIP] Comments on draft-jennings-p2psip-security-00

[Philip Matthews <[e-mail]>]

Hi Cullen:

I read your draft on security draft-jennings-p2psip-security-00.
and thought it had some interesting ideas.
Here are some comments and questions that I have.
I have adopted Spencer's style of mixing paragraphs from the document
with embedded comments prefixed by "Philip:"

- Philip

------------
[snip]
    When a client wants to store some information in a record, they sent
    a request that has:  their AOR, the record type name, the time, the
    data to store in the record, and MUST include a signature over all
    that information.  When a peer goes to store the information, it  
MUST

Philip: When you say "client" and "peer", are you using these terms as
defined in the P2PSIP Concepts document? My guess is that you
are using the word "client" in the SIP meaning, not in the P2PSIP  
meaning.

    check that the signature is correct.  It SHOULD also check that the
    data looks appropriate for this type of record given by checking
    things like the size of the data is in an appropriate range.  When a
    client retrieves data out of the DHT, it retrieves all the
    information that was signed and SHOULD verify the signature on the
    data.

Philip: This seems similar to the proposal in draft-singh-p2p-sip-01.
Can you comment on this?

    Open Issue:  how do we want to deal with checking time and also does
    the data have a Time To Live (TTL).

    Open Issue:  do we pass the certificate with the signature or do we
    provide some alternative scheme to get the certificates.  I am
    leaning towards pass the certificate along with the signature.  A
    problem with this is the message size.  A possible problem with not

Philip: Are your worried about size in sending the message or in storing
the data?  That is, if we used for example TCP transport (i.e., not  
UDP),
then would your concerns go away?

    doing it is that the signature are used to verify the constructions
    of the routing architecture and assuming that the routing
    architecture is in place before a signature can be checked may lead
    to problems.


4.  Routing Protection Architecture

    The goal of protecting the routing is stopping attacker from
    performing a DOS attack on they system by misrouting requests in the
    DHT.  The data is already protected by the data protection scheme
    above so an attacker can't tamper with the data in a way the user
    can't detect but an attacker can make it look like no data is
    available.  There are a few obvious observation to make about this.
    First, it is easy to ensure that attacker at least has to have an
    valid enrollment with this particular DHT.  Second, this is a DOS
    attack and the value of successfully executing it is fairly low.
    Third, if a larger percentage of the peers on the DHT are controlled
    by the attacker, it is probably impossible to perfectly secure this.

    When a peer sends a request that modifies the routing in the DHT, it
    MUST sign the request on behalf of a user that is currently
    responsible for the peer using that users certificate.  A peer that
    is changing the routing state based on this request to check the
    signature before performing the request.

Philip: There are a number of things I don't understand here.
Can you give some examples of what you mean by
"a request that modified the routing"?  For example, do you mean
"setting up a new Peer Protocol connection"?
And how does signing such requests help prevent DOS attacks?
I can see how it might help us catch the peer that did the attack,
but this is very much after the fact.
Finally, why sign this with a user's certificate? Why not sign this
with the certificate of the peer? (As documented in Concepts-04,
we have already agreed that peers must have certificates to
join the overlay.)


    To reduce attacks on routing, the design tries to limit the ability
    of an attacker to place peers at arbitrary locations in the DHT.
    Some possible ways to do this are:

    L1:  Limiting IP addresses:  Other systems have done this by forcing
         the peer id to be a hash of a combination of the peers IP and
         port however this approach does not work with IPv6 where the
         users have an arbitrary number of IP addresses and the  
scheme is
         also difficult to make work with IPv4 and NATs.
    L2:  Limiting by AOR:  The first step to doing this is limiting the
         number of AORs an attacker can enroll in the system.  How to do
         this is out of scope.  The next step would be forcing a peer ID
         to have the high order bits formed from an hash of the AOR and
         some low order bits chosen randomly or hashed from the IP
         address and port.  Peers would check the Peer ID was  
appropriate
         for the given users that signed the request.

Philip: What do you see as the AOR of a peer? Are you thinking of
the scheme you, Bruce, and David are using in the dSIP draft?
If so, I don't quite see how this would work. It seems that your peer-id
would depend on itself.
[For other readers of this message, those URIs look like:
           peer@<hostport>; peer-id=<peerid>
where <hostport> is an IP address and port and <peerid> is a peer-id].
Moreover, the other unique part is the <hostport>, so this falls back to
option L1.

    L3:  Limited by assignment at enrollment:  When enrolling, the user
         would be given a small set of peer IDs for their use.  This is
         effectively equivalent to Limited by AOR but has the addition
         complexity of the certificates become more complex as a peer
         would need to sign with the appropriate peer id as well as the
         AOR.



5.  Mapping to SIP

    There are several ways this could be mapped to SIP.

Philip: Is this section making the assumption that the Peer Protocol
is SIP? Otherwise, I don't understand what this has to do with SIP.




































Jennings                 Expires August 28, 2007                [Page 6]
Internet-Draft               P2PSIP Security               February 2007


Full Copyright Statement

    Copyright (C) The IETF Trust (2007).

    This document is subject to the rights, licenses and restrictions
    contained in BCP 78, and except as set forth therein, the authors
    retain all their rights.

    This document and the information contained herein are provided  
on an
    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE  
REPRESENTS
    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST  
AND
    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE  
USE OF
    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

    The IETF takes no position regarding the validity or scope of any
    Intellectual Property Rights or other rights that might be  
claimed to
    pertain to the implementation or use of the technology described in
    this document or the extent to which any license under such rights
    might or might not be available; nor does it represent that it has
    made any independent effort to identify any such rights.   
Information
    on the procedures with respect to rights in RFC documents can be
    found in BCP 78 and BCP 79.

    Copies of IPR disclosures made to the IETF Secretariat and any
    assurances of licenses to be made available, or the result of an
    attempt made to obtain a general license or permission for the  
use of
    such proprietary rights by implementers or users of this
    specification can be obtained from the IETF on-line IPR  
repository at
    http://www.ietf.org/ipr.

    The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights that may cover technology that may be required to implement
    this standard.  Please address the information to the IETF at
    [e-mail].


Acknowledgment

    Funding for the RFC Editor function is provided by the IETF
    Administrative Support Activity (IASA).





Jennings                 Expires August 28, 2007                [Page 7]


_______________________________________________
P2PSIP mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/p2psip