Subject: [P2PSIP] Issue: Non-ICE?

From: Cullen Jennings <[email-masked]>
Date: Wed, 16 Jul 2008 12:05:52 -0700

One topic that's come up in a number of implementations that I'm
familiar with is that doing ICE from the get-go imposes a significant
implementation hurdle. Since there are settings in which ICE isn't
necessary, this raises the question of whether it makes sense
to have a trivial version of Attach (previously Connect) which
does not use ICE.

The tricky thing here is that even in situations where full ICE
is not needed it's attractive to offer two addresses, one inside
and one outside the NAT, so now we end up defining some kind of
ICE lite lite, which tends towards the complexity of ICE as we
want to handle just one more case.

A middle ground would be to allow ICE lite support.
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: "Pete Cordell" <[email-masked]>
Date: Wed, 16 Jul 2008 20:45:01 +0100

Being a bit behind on my reading, I've just noticed that RELOAD has a binary 
encoding.  Amazingly I didn't see a blood bath over this!  I would love to 
hear the motivation for this.  Any pointers to decisions or anyone prepared 
to offer a summary would be much appreciated.

Feel free to reply to me off-line as I don't want to open old debates.

In fact, I'm wondering if it's possible to extract the Message Structure and 
define it in a separate RFC so others can use it.  Such re-use can surely 
only be a good thing.  (See my own efforts at: 
http://www.ietf.org/internet-drafts/draft-cordell-lumas-05.txt .  The syntax 
is not important, although there may be ideas there that an initiative might 
want to borrow.)

Thanks and all the best,

Pete.
--
=============================================
Pete Cordell
Codalogic
=============================================

---

From: "David A. Bryan" <[email-masked]>
Date: Thu, 17 Jul 2008 14:22:26 -0400

I also want to add that there are some folks on the list (and I
directly know of a bunch more) who are interested in using this
protocol for special purpose things that are definitely not running on
the Internet. For example, sensor networks, emergency response, ad-hoc
etc. They have an interest in things being very small (mote sized),
low message count (battery/radio issues) and want to be able to run
without ICE (and without certificates or TLS as well, for that
matter).

I definitely think that most people using this for normal environments
need to be using ICE for NAT traversal (for example, folks may say
they will "not need ICE" for an enterprise deployment, but over time,
they very well may need ICE (a remote party, teleworker, whatever) and
they should really go implement ICE).

We should to be continue to very clear that ICE is the mechanism we
use in deployments where there is any chance there will be a NAT. I
just think we should try to keep in mind that, perhaps more than other
WGs, we have some folks who want to do unusual things, and some of
them justifiable don't need ICE.

David (as individual)

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: Enrico Marocco <[email-masked]>
Date: Thu, 17 Jul 2008 21:23:28 +0200

> them justifiable don't need ICE.

I would like to second this. There are also folks who look forward to
adopting the protocol specified here in research projects focused on
overlays and distributed algorithms in general. P2PSIP would benefit
much from such adoption, but probably the burden of implementing (or
debugging or simply dealing with) ICE would impede it in many cases
(think for example of student projects).

-- 
Ciao,
Enrico

---

From: Bruce Lowekamp <[email-masked]>
Date: Thu, 17 Jul 2008 15:53:31 -0400

I would like to propose that we extend the base protocol to support 
direct connections.  However, I'd like to avoid the complexities of 
trying to mix direct connections with ICE negotiation and the challenges 
described in 3.3.1 of having fallbacks etc.  Therefore, if we:

- add to 6.2.2.1 DestinationType a new type for a proto/ip/port 3-tuple
- add a flag in 6.2.2 to specify that a direct return address is being 
used and that the response should be routed to the top of the via list 
regardless of intermediate updates

otherwise, don't change the protocol.  A joining peer learns the 3-tuple 
address of its bootstrap peer and begins its join process just like 
normal.  When it sends an ATTACH, it needs to be using ice-lite, but 
that's not very hard (and extraordinarily simple if you have two 
ice-lites talking with each other).

There is no fallback if you are wrong that you have a publically 
accessible address.  Using a raw address in your via-list and ice-lite 
simply doesn't work if you're wrong, but provides a somewhat lighter 
weight and faster protocol when needed.

I will note that I disagree with implementation simplicity being a major 
factor here.  If you have an ICE implementation (and I think we should 
expect the number of available implementations to continue to grow), 
it's really not hard to use it in the protocol.  I care slightly more 
about low-power devices and distributed-pbx type deployments motivating 
this type of change to the protocol.

Bruce

Enrico Marocco wrote:
> ------------------------------------------------------------------------
>

---

From: Henry Sinnreich <[email-masked]>
Date: Sat, 19 Jul 2008 12:06:50 -0700

There are even more reasons why both David and Enrico are right.
If p2p is used over HIP, the overlay does not have to worry about NAT
traversal, since it is being taken care of by HIP.

HIP may use ICE as has been documented here, but the various p2p and CS
protocols can all run ICE unaware.

Henry

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 20 Jul 2008 12:19:32 -0700

On Jul 17, 2008, at 12:23 PM, Enrico Marocco wrote:

> much from such adoption

+1