Re: [P2PSIP] New version of draft-matthews-p2psip-id-loc

[Philip Matthews <[e-mail]>]

[Private reply]

Tom:

I am not quite sure now what the direction forward is for ID-LOC. The  
comments we got in the P2PSIP group meeting is that this work might  
not be appropriate for P2PSIP, and this should perhaps be pursued in  
the transport area. I don't know if I totally agree, because I think  
a P2P overlay has the advantage that both ends must implement  
whatever the agree protocol is. But we certainly got push-back, and  
people don't see this as similar to HIP.

- Philip

On Thu, 13-Mar-08, at 01:27 , Henderson, Thomas R wrote:

> Philip and all,
>
> Below are some further comments on the Id/Loc draft.
>
> Overall, you will probably guess from my previous comments that
> I am sympathetic to this approach for supporting legacy applications.
> However, there is also a large body of prior and concurrent related  
> work
>
> and I think it would be an easier path to try to see whether an  
> approach
> like HIP or shim6 could be tailored in this way (to better match
> P2PSIP requirements) rather than starting from scratch.  Of course,
> I realize that you are quite active in the HIP NAT traversal design
> team work, so maybe this is anyway your goal as well.
>
> - Tom
>
>
>>
>>                  An ID/Locator Architecture for P2PSIP
>>                     draft-matthews-p2psip-id-loc-01
>>
>>
>> 1.  Introduction
>>
>>    This document describes a scheme whereby the applications running
> on
>>    a peer can use a special IP addresses, called "LSIs" (Locally
>>    Significant Identifiers), to identify other peers in the
> peer-to-peer
>>    overlay, rather than using real IP addresses or peer IDs.  Using
>>    these LSIs brings the following advantages:
>>
>>    o  An LSI is unique, unlike the real IP address of most peers
> (which
>>       is often a private IP address);
>
> "locally unique"?
>
>>
>> 3.  Terminology
>>
>>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL  
>> NOT",
>>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
> this
>>    document are to be interpreted as described in RFC 2119 [RFC2119].
>>
>>    Readers are expected to be familar with [I-D.ietf-p2psip-concepts]
>>    and the terms defined there.
>>
>>    This document defines the following terms:
>>
>>    LSI:  An IP address uses to identify a peer in the overlay.
>
> I think you may need to be careful about calling an LSI an IP address.
> Rather, it is masquerading as an IP address.  It does not denote a  
> point
> of attachment to an IP network.
>
>>
>> 4.  Details
>>
>
> One detail that will need to be addressed is what to do about LSI
> lifetime management.  Applications (presumably unmodified) may cache
> the resolver response for a longer time than the peer protocol decides
> that it must hold the bindings.  This could provide new failure modes
> or aliasing.
>
>>
>> 9.  Appendix: Discussion of Design Choices
>>
>>    This appendix discusses the thinking around some of the design
>>    choices made.
>>
>> 9.1.  LSIs have Local Significance
>>
>>    In the design presented here, the LSIs presented to applications
> have
>>    local significance only.  For IPv4, this seems to be the only
>>    reasonable choice, as it would be difficult to get an IPv4  
>> block of
>>    addresses large enough to be of wider significance.  However, for
>>    IPv6, a wider scope would be possible, and that option was
>>    considered.  In particular, it would have been possible to use a
>>    globally scoped identifier, like the HIT of HIP.  At first blush,
> it
>>    seems that using a globally scoped identifier would allow an
>>    applications to send the identifier (embedded in protocol  
>> messages)
>>    to an application on other nodes and have that identifier make
> sense.
>>
>>    However, an examination of the details shows that there are
> problems
>>    with this approach.  Say a node X has an indentifier for node Z
>>    (e.g., a HIT) and sends its to node Y. For Y to be able to use  
>> this
>>    identifier, it must know how to establish a connection with  
>> node Z.
>>    If node Y is in multiple overlays, then Y has no idea which  
>> overlay
>>    to search to find node Z. It is this difficulty that led us to the
>>    decision to make LSI have local significance only.
>>
>
> I am not sure about this argument.  I think it is a valid point that
> a naked HIT passed to a third-party in an application referral may
> not be resolvable, but it will be as bad or worse for an LSI.  An
> advantage to using HITs over LSIs is that since there are semantics on
> the HIT (that it must match a key) then at least one will not have
> the possible aliasing problems mentioned above.
>
> I think the main reason for using an LSI is to support IPv4  
> applications
> without modification, and there just aren't enough bits to ensure
> security or statistical global uniqueness.
>
>
>>
>>
>>
>> Cooper, et al.           Expires August 28, 2008               [Page
> 12]
>>
>
>> Internet-Draft                   ID/Loc                    February
> 2008
>>
>>
>> 10.  Relationship to HIP
>>
>>    The fundamental concept in this document, that of an identifier  
>> for
> a
>>    node which is distinct from the node's real addresses, has been
>>    adopted from HIP.  In HIP, this identifier (known as a HIT
>>    [I-D.ietf-hip-base]) is always an IPv6 identifier, and has global
>>    scope and cryptographic properties, making it computationally hard
>>    for an second node to steal a node's identity.  (Current HIP
>>    implementations also implement an IPv4 identifier as a local
>>    identifier, but the properties of this IPv4 identifier are not
>>    currently specified anywhere).
>>
>
> In many ways, this draft describes how our HIP implementation for IPv4
> works, except of course that ESP is the encapsulation, there is
> no ICE or NAT traversal (yet), and there is no support for multiple
> overlays.
>
>
>>
>> 11.  References
>
>
> I suggest to add a number of references.
>
> The HIP LSI is introduced in RFC 4423.  In the hip-base draft, credit
> is given to Noel Chiappa for providing the framework for it.
>
> The idea of returning an LSI to overlay-based applications has been
> around and implemented in several projects.  For instance, the  
> Berkeley
> OCALA project was the inspiration for our use of this technique in
> our HIP implementation.
> http://ocala.cs.berkeley.edu/
>
> There is a draft in the HIP WG that is specifically concerned with
> how to allow legacy applications to run over HIP stacks, using LSIs
> and other techniques:
> http://www.ietf.org/internet-drafts/draft-ietf-hip-applications-02.txt
>
> The HIP BONE draft is also concerned with this topic:
> http://www3.tools.ietf.org/wg/hip/draft-camarillo-hip-bone-01.txt
>
> I suggest also to look at Erik Nordmark's ESD draft:
> http://tools.ietf.org/wg/shim6/draft-nordmark-shim6-esd-01.txt
>
>

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