Subject: RE: [midcom] new I-D on "symmetric STUN"

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 17 Nov 2001 03:19:17 -0500

> -----Original Message-----
> From: Mark Taylor [mailto:[email-masked]]
> Sent: Friday, November 16, 2001 9:46 AM
> To: [email-masked]'
> Subject: RE: [midcom] new I-D on "symmetric STUN"
> 
> 
>  The main difference between the Davies and STUN/TURN
> is that one speaks of a firewall strategy while the
> other is effectively silent. The other differences are
> really inconsequential and superficial.

Not really. I think TURN is significantly simpler than the Davies proposal.
It does that by doing fewer things (for example, the Davies draft supports
outbound TCP connections through their tunneling mechanism, outbound TCP is
not provided in TURN. I'll explain that in a separate note).

> 
> What benefits does the Davies firewall strate3gy
> bring?
> 
> In addition, the purpose of STUN is really not clear
> to me. 

It does two main things:

1. helps a device discover what its nat situation is,
2. if the nat situation is full cone, restricted cone, port restricted cone,
allows it to get an ip address it can use in applications.

> The information that it gathers seems to be
> something that would be done only very rarely

Discovery, yes. Item two above would be done for each SIP call, for example.

> and
> could probably be obtained from an inquiry to the
> network designer.

I think that is quite impractical. I can imagine a PC phone app
documentation saying "next, please call your cable provider and ask them the
type of NAT they are running in their network. Enter the value in dialog
box...". I don't think so. 

> Indeed if the answer turns out to be
> a symmetric NAT, a TURN server would have to be
> provided outside of the NAT which is something that
> would have to be done physically. 

Yes.

> STUN and TURN as
> protocols that adapt to network configurations is a
> concept that seems very fuzzy to me. I must be missing
> something about their operation.

I can answer specific questions. Hopefully the new draft on nat scenarios
might clarify some of it.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
midcom mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/midcom

---

From: Mark Taylor <[email-masked]>
Date: Sun, 25 Nov 2001 05:36:32 -0800 (PST)

STUN/TURN and the Davies (FANTOM) proposals are
marked by different emphaisises in achieving the same
objective.

STUN/TURN emphasizes simplicity. Davies emphasizes
security with its addressing of firewall issues. The
other differences between the protocols seem only to
be variations on a theme and not consequential to the
overall problem.

I asked a security specialist about the Davies
proposal's firewall claims. He found them to be
unconvincing with the observation that many people
have inflated ideas about what firewalls can do.

If the Davies firewall strategy is, as with this view,
ineffective, it only adds complexity and cost without
providing real benefit. STUN/TURN will provide the
same level of security with a simpler and less costly
proposal.

Is this view correct?

__________________________________________________
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1

---

From: "Pete Cordell" <[email-masked]>
Date: Mon, 26 Nov 2001 22:14:22 -0000

Mark,

Thanks for raising the security issues.  This is an important subject to us,
and one of the main reasons for getting peer review of FANTOM in the IETF.

(Mind you, security is not the only reason we think FANTOM has more to offer
than TURN - The RTP/RTCP port relationship issue is not security related.
On the other hand, being able to explicitly close a media session is.)

As for what firewalls can do, all we require from the firewall is a few
simple filtering rules.  A firewall that doesn't do that is called a
router!!!  Security is also addressed in a few other ways.

It's hard to address the issues your security specialist perceived without
concrete examples.  I would therefore welcome you enumerating these to
further the discussion.  We can then decide whether they are already
addressed by the protocol, are not important, or the protocol needs
modifying.

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
[email-masked]
+44 1473 635863
=============================================