Subject: [P2PSIP] Base section 10.4 clarification

From: "Michael Chen" <[email-masked]>
Date: Wed, 21 Sep 2011 17:45:37 -0700

Hi,

A discussion with Marc Petit-Huguenin brings up the issue of "naked
Ping" described in section 10.4 of the base draft:

   If no cached bootstrap nodes are available and the configuration file
   has an multicast-bootstrap element, then the node SHOULD send a Ping
   request over UDP to the address and port found to each multicast-
   bootstrap element found in the configuration document.  This MAY be a
   multicast, broadcast, or anycast address.  The Ping should use the
   wildcard Node-ID as the destination Node-ID.

It should be clarified that this Ping message, wrapped the Frame Header
is sent via UDP without DTLS, thus the term naked Ping. Further
implication is that a RELOAD application that supports UDP must
multiplex among three protocols: STUN, DTLS and framed_naked_Ping.

Marc also raised the issue of anycast, and I'll let him jump in from
here.

Thanks

Michael Chen

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 22 Sep 2011 09:31:54 -0700

> Marc also raised the issue of anycast, and I'll let him jump in from

The problem is that it is a bad idea to establish a DTLS connection to an
anycast address, as there is no guarantee that the subsequent UDP packets will
reach the same host.  It is even no guarantee that the ACK for the Ping answer
will go to the same host, which is why I also think that Framing should not be
used for sending a Ping to an anycast address.

But the problem in the case of anycast is NAT traversal.  We cannot use the
source IP/port of the Ping answer (or Ping request ACK) as an indication of the
unicast address to use for subsequent transactions, because the packet will be
dropped by symmetrical NATs.  The reasonable thing to do would have been to add
an IpAddressPort field in the Ping answer, field that contains the IP
address/port of a unicast bootstrap server (as if retrieved in the configuration
file), but the authors sent a clear message that breaking compatibility is out
of the equation.  So what do the authors propose to fix this problem?

Also I think that the spec should clearly state that a unicast bootstrap server
MUST support both DTLS-UDP-SR-NO-ICE and TLS-TCP-FH-NO-ICE on its public IP
address/port.

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org