[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 [email protected] https://www.ietf.org/mailman/listinfo/p2psip
