Re: [P2PSIP] Re: a modular approach for integrating HIP for P2PSIP

[Miika Komu <[e-mail]>]

On Mon, 31 Dec 2007, Gonzalo Camarillo wrote:

Hi Ali and Gonzalo,

sorry for catching up late.

> Hi Ali,
>
> HIP includes an ICE-based NAT traversal mechanism. If two nodes use HIP, 
> they will perform ICE at the HIP level, not at the application level. 
> Using application-level ICE to negotiate the use of HIP between nodes, 
> per your email below, is cumbersome. The use of HIP can be negotiated in 
> simpler ways.
>

Basically I agree with Gonzalo here, but to be more specific...

In a "normal" (no overlay, no extra mods to ICE or HIP) HIP scenario, 
sending some data to a HIT would trigger an I1. Either with or without UDP 
encapsulation, depending on local policies. When I1 is sent without UDP, 
the hipd could speed up the connection set-up in the case there are no 
NATs between the two machines. However, the ICE module would not know 
when to stop the connectivity tests, because it wasn't HIP-aware in this 
case. Also, this "optimization" would be unnecessary in the case there are 
NATs between the two hosts because the HIP messages would be just dropped.

In another non-overlay scenario, where ICE is HIP-aware, we could define 
that ICE and HIP module can interact with each other. Sending STUN 
messages to a HIT would trigger a I1 packet without UDP encapsulation and 
upon success the HIP module could abort the ICE connectivity tests 
gracefully. One benefit of this would be that we would skip the UDP 
encapsulation altogether, but the benefit is neglectible.

As indicated by the other discussion thread, applying HIP-aware ICE in 
HIP-enabled overlays may have some caveats related to handling of multiple 
overlays. Anyway, there should be a distinction between getting a direct 
connection to the peer (using ICE) vs. routing through the overlay. I 
think this could be implemented e.g. using a socket option.

> With regards to the use of HIP in overlays, the simplest way would be to 
> deploy overlays where all nodes use HIP and overlays where none of the 
> nodes use HIP. However, some people have expressed interest in having 
> mixed overlays where some nodes use HIP while others don't. If people 
> are interested in doing this, we will have to look into ways to 
> negotiate its use within the overlay.
>
> With regards to the use of HIP in overlays, the simplest way would be to 
> deploy overlays where all nodes use HIP and overlays where none of the 
> nodes use HIP. However, some people have expressed interest in having 
> mixed overlays where some nodes use HIP while others don't. If people 
> are interested in doing this, we will have to look into ways to 
> negotiate its use within the overlay.

Regarding to Ali's original suggestion on detecting localhost and peer 
support, I think localhost support would be easy. Connecting to a HIT is 
one way detect it, but it may include a timeout. Other ways are to go 
through the addresses of host using e.g. getaddrinfo() and check if there 
are any ORCHIDs there. Perhaps the quickest way is to create a socket with 
PF_HIP family and check for errors in the return value.

-- 
Miika Komu                                       http://www.iki.fi/miika/

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