Subject: RE: [midcom] pre-midcom candidates

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 24 Oct 2001 01:14:27 -0400

Well, things have been quiet....

Let me give my 2 cents about these three documents, and how they relate to
each other and the problems they are trying to solve.

Both the Sen proposal and the Davies proposal assume the worst case -
symmetric NAT, and involve the use of some kind of provider based
intermediary to deal with that case. The drawback is that there is increased
cost to the provider to deploy these boxes and for the bandwidth in the
co-locs to received the media and turn it back around. There is also
increased voice latencies due to speed of light delays to this intermediary,
whose location is generally uncorrelated with the location of the end users.
The Sen proposal is protocol specific; that is, it works for SIP only. The
general concept could be made to work for other protocols, but that would
need to be documented separately. Its benefit is that there is no need for
further protocol development beyond what we are doing today. The Davies
approach is not protocol specific, and provides a general way to allocate
bindings from a relay server in the provider network. It would work for any
application. The Davies approach is really nothing more than RSIP applied to
the transport layer (UDP and TCP). RSIP works at the IP layer, and thus
requires host IP stack changes. The Davies protocol, by using RSIP concepts
at the transport layer, pushes those functions into the applications, at the
cost of additional protocol mecahnisms (for example, indications of tcp
connection establishment, carried on the control channel, are needed in the
davies protocol, but are not needed in RSIP). There are other issues with
the Davies protocol, primarily having to do with consistency with enterprise
firewall policy, but I will get to that in a separate note.

Stun is a different beast. It tries to optimize media by first figuring out
the type of nat, and in the case of full cone and address-restricted nats,
provides the IP address allocated by the nat. In these cases, there is no
need for the intermediaries that the Sen and Davies protocols use. In the
case where the user is behind a symmetric nat, some kind of intermediary is
needed. Stun, as described, doesn't have capability for allocating an
address from an intermediary. We have done some work on how that might be
done as a simple extension to what stun does now, but with the addition of
some security and load balancing capabilities.

In my opinion, a usable solution requires the ability to avoid the
intermediary when its not needed, and to involve one when it is needed. THis
means that its a two-pronged solution: first, detect the nat situation, and
get addresses if its not symmetric. Stun is the only proposal that does
that. The second stage is, if you find you are behind a symmetric nat,
involve the use of a network intermediary. There are three proposals for
that piece - the sen draft, the davies draft, and the unpublished stun
attributes I have mentioned.

Arguably, handling the symmetric case is the far more complex scenario. It
has more complex security issues, requires more protocol primitives, and so
on. Its also an area richer in solutions. Besides the three we have seen,
there is also pure VPN solutions and even my favorite, rfc3093. 

So, my proposal is to attack the low hanging fruit first, and the harder
stuff next. Lets take stun as documented, finish that, and have a solution
for the detection and for handling the non-symmetric cases. We can then work
on the symmetric case, but I suspect that will take longer.

-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

> -----Original Message-----
> From: Melinda Shore [mailto:[email-masked]]
> Sent: Friday, October 12, 2001 4:58 PM
> To: midcom
> Subject: [midcom] pre-midcom candidates
> 
> 
> I believe we now have three candidate documents for the
> pre-midcom work item, and we need to work quickly towards 
> getting one selected for use as the base document.  Those
> three documents are:
> 
> http://search.ietf.org/internet-drafts/draft-sen-midcom-fw-nat-00.txt
> http://search.ietf.org/internet-drafts/draft-rosenberg-midcom-
> stun-00.txt
> <http://www.ridgewaysystems.com/pdf/Whitepapers/draft-davies-f
> w-nat-traversal-01.txt>http://www.ridgewaysystems.com/pdf/Whit
> epapers/draft-davies-fw-nat-traversal-01.txt 
> 
> Please read these, and let's have some serious discussions about
> this over the next week.  Remember, the ability to compromise is
> a virtue.
> 
> Note, as well, that although the document does not state as much
> there are some intellectual property claims on technology described
> in the Davies draft.  I've appended some text that originally
> appeared on the APPS area web page, giving a rough description of
> the IETF position on IPR (http://www.apps.ietf.org/procedures.html).
> Please read it and take particular note of the second bullet item.
> In the future, if you submit a technology for consideration that
> is encumbered you MUST inform the working group.
> 
> Thanks,
> 
> Melinda
> ======== 
> 
> As all who have been with the IETF for a while know, IPR 
> problems are a pain.
> 
> The most interesting discussions are found in RFC 2026 
> chapter 10; the basic tenets of which are:
> 
>     * All IPR problems known to participants MUST be 
> identified to the WG.
>     * The WG is expected to prefer non-encumbered technology 
> whenever such technology exists and is not significantly 
> worse than the encumbered alternative.
>     * Where licensing is an issue, licensing MUST be 
> available on "reasonable and non-discriminatory terms". The 
> first test is whether 2 independent licenses have in fact 
> been granted under such terms between the Proposed and Draft 
> status for the specification.
>     * Patents where the patent holder has filed a grant of 
> rights to freely use the patent are not considered terribly 
> encumbering.
> 
> For discussions of release of IPR, the correct address is the 
> ISOC vice president for standards, Scott Bradner, 
> <[email-masked]>; also send CC to the IETF Chair (Fred Baker 
> <[email-masked]>) and the IESG secretary <[email-masked]>
> 
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/midcom
> 

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

---

From: "Mark Pietras" <[email-masked]>
Date: Wed, 24 Oct 2001 09:45:22 -0500

After going over STUN in more detail, I've got a few lower-level detail
comments/questions (some pretty minor) about the document rather than
concerning the approach.  I haven't read other comments on the document, or
seen an update, so I apologize if these have been addressed already:

These two statements seem to be conflicting (or maybe I'm just taking it out
of context), but I think the second statement needs clarification in that
there is another place that the response might go than the obseved
addr/port:
> 6 Message Overview
>    There is also a RESPONSE-ADDRESS attribute, which
>    is also an IP address and port. The RESPONSE-ADDRESS attribute can be
>    present in the request, and >>indicates where the response is to be
>    sent<<. Its optional, and when not present, the response is sent to the
>    source IP address and port of the request.
> 7 Server Behavior
>    The server MUST add a MAPPED-ADDRESS attribute to the response. The
>    IP address component of this attribute >>MUST be set to the source IP
>    address observed<< in the request. The port component of this attribute
>    MUST be set to the source port observed in the query request.

Seems to me that the FLAGS attribute could be optional in the request,
although that's not stated.  As a side note, if that's not reasonable, then
the line: "After the header are 0 or more attributes" shouldn't be: "0 or
more" as there will always be at least 1 (Request with flags, or Response
with mapped-address).

In the attribute, the length field isn't specifically defined as to whether
the attribute header is included or not.  I'd suggest that it doesn't
include the four octets (type and length) to be consistent with the main
header.
>   10.2 Message Attributes
>   After the header are 0 or more attributes. Each attribute is TLV
>   encoded, with a 16 bit type, 16 bit length, and variable value:...

Unless I'm missing something, it seems to me a multi-homed implementation
would be more efficient (and therefore perhaps a better suggestion) than
using the RESPONSE-ADDRESS.  I suppose the RESPONSE-ADDRESS is the more
complex implementation though and deserves more attention...
>   One potential way to implement the change-IP feature is for the
>   server to generate its own request, and send it to another server...
From what I can tell, this is also the only reason for RESPONSE-ADDRESS too,
right?

Seems to me that CHANGED-ADDRESS is missing from the list:
>   0x0001: MAPPED-ADDRESS
>   0x0002: RESPONSE-ADDRESS
>   0x0003: FLAGS
>   0x0004: SOURCE-ADDRESS
Based on layout of document, I think this was intended:
>   0x0001: MAPPED-ADDRESS
>   0x0002: RESPONSE-ADDRESS
>   0x0003: CHANGED-ADDRESS
>   0x0004: FLAGS
>   0x0005: SOURCE-ADDRESS

A side note on address realms:
If a STUN packet traverses address realm types (ipv4 client <-> ipv6 server)
a client in the ipv4 realm will have to be ipv6 aware because the response
will contain the ipv6 address of the NAT.  And when I say client, I mean
both the STUN client _and_ the client using the information as it will be
communicating it somewhere else in it's signaling (e.g. SIP/SDP).

Note on attributes:
There's no explicit or implied order to how attributes appear in messages, I
suppose that's okay (although slightly more work to deal with), but I don't
recall seeing a statement about what servers (or clients for that matter) do
when 1) they see an attribute in a request meant only for a response (or
visa versa), or 2) there is more than one attribute of the same type in a
message (e.g. two FLAGS attributes).

That's it for now...  looks good.

Mark Pietras.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Jonathan Rosenberg
Sent: Wednesday, October 24, 2001 12:14 AM
To: 'Melinda Shore'; midcom
Subject: RE: [midcom] pre-midcom candidates

[deleted]