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

["Henderson, Thomas R" <[e-mail]>]

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