RE: [P2PSIP] Discussion items for the Tuesday teleconference

Henry,
A few responses below. 

> -----Original Message-----
> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] 
> Sent: Monday, January 07, 2008 5:44 AM
> To: Paine, Richard H; p2psip@ietf.org; hipsec@ietf.org
> Subject: [P2PSIP] Discussion items for the Tuesday teleconference
> 
> The paper on the Boeing HIP implementation along with the I-D:
> draft-camarillo-hip-bone-00.txt is very helpful to SIP oriented people
> like me who are new to HIP. Quite frankly I am close to becoming a
> believer, if only some questions could be addressed and where more
> details would be helpful:
> 
> 1. TCP/IP stack use and implementation
> 
> If and how can the existing PCP/IP stack in Windows, OSX, Symbian and
> LINUX be used or does it have to be rewritten? Is there a 
> workaround and
> if yes, can anyone share what it may look like?

There are HIP implementations that modify the kernel TCP/IP
implementation, and those that do not.  Those that do not use various
techniques to intercept packets and copy them to user-space where they
are further processed and re-injected to the stack.  OpenVPN
(http://openvpn.net) is one such example.

What it may look like in this approach is to create a virtual interface
and assign one or more HIP identifiers (that look like addresses to the
operating system) to that interface.  Packets sent to identifiers in
that identifier space are internally routed to that virtual interface.
This interface is a tap interface (http://en.wikipedia.org/wiki/TUN/TAP)
that directs packets to userspace, where they can be processed further
and written back to the interface or to a raw socket.

Note that this technique is recommended as a deployment crutch for
applications that cannot be easily modified; the eventual goal is that
stacks are upgraded to include HIP and that applications use more
explicit HIP-aware APIs such as:
https://datatracker.ietf.org/drafts/draft-ietf-hip-native-api/

Also note that I do not know about the applicability of the above to
Symbian, only that it has worked for Windows XP, OS X, and Linux.

> 
> Product managers would see the rewriting of the TCP/IP stack to insert
> HIP as a major problem to avoid at any cost. Waiting for these OS to
> support HIP does not seem a good alternative.
> 
> 2. NAT traversal
> 
> VPN implementations have had problems with NAT and as a 
> result most NAT
> vendors have addressed VPN support. What is the experience with HIP
> support in NAT, or how much of a problem is NAT traversal for HIP?
> Are there any measurements or deployment data that can be shared?

To my knowledge, there has been no inbound NAT traversal mechanism
integrated with any of the HIP implementations.  There have been
implementations of UDP encapsulation for outbound NAT traversal for a
few years, according to an expired Internet draft:
http://tools.ietf.org/html/draft-schmitt-hip-nat-traversal-02.  I don't
know how much testing they have undergone; not as much as the non-NAT
variants, I would say.

The HIP WG has a design team working on NAT traversal, and STUN/ICE is
the basic design framework.

Tom

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip