headers
Melinda Shore | 2 Feb 2004 22:42
Picon
Favicon

Fwd: I-D ACTION:draft-ietf-midcom-mib-00.txt

This doesn't appear to have been cc'ed to the midcom mailing list.

Here's the announcement for the midcom MIB, our final piece of work.
Please have a good, thorough look at it and bring any issues you
identify to the mailing list.  This will also be the primary agenda
item at the upcoming IETF meeting.

Melinda

Begin forwarded message:

> From: Internet-Drafts <at> ietf.org
> Date: Mon Feb 2, 2004  3:58:44 PM US/Eastern
> To: IETF-Announce: ;
> Subject: I-D ACTION:draft-ietf-midcom-mib-00.txt
> Reply-To: Internet-Drafts <at> ietf.org
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>
>
> 	Title		: Definitions of Managed Objects for Middlebox Communication
> 	Author(s)	: J. Quittek
> 	Filename	: draft-ietf-midcom-mib-00.txt
> 	Pages		: 76
> 	Date		: 2004-2-2
> 	
> This memo defines a portion of the Management Information Base (MIB)
>    for use with network management protocols in the Internet community.
>    In particular, it describes a set of managed objects that allow
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sumandra Majee | 2 Feb 2004 23:01
Picon
Favicon

(no subject)

unsubscribe sumandra majee
Permalink | Reply | 0 comments |
headers
Melinda Shore | 10 Feb 2004 20:12
Picon
Favicon

Agenda for Seoul meeting

I've appended the agenda for the midcom session at the meeting in
Seoul.  I'll be unable to attend myself, and Mary Barnes has agreed
to chair the meeting in my absence.  Please let us know of any
additions or changes to the proposed agenda.

Thanks,

Melinda

Middlebox Communication (midcom)

Tuesday, March 2 at 1415-1315
=============================

CHAIR: Mary Barnes (sitting in for Melinda Shore)

AGENDA:

Agenda bashing/note-taker/blue sheets

Status update
        draft-ietf-midcom-protocol-eval-06.txt
        draft-ietf-midcom-semantics-07.txt

What do we do with draft-ietf-midcom-mib-analysis-01.txt?

MIB document
         draft-ietf-midcom-mib-00.txt

Way forward
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Rosenberg | 10 Feb 2004 20:57

[Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt]

This is a great piece of work. Thanks to Cullen for putting this together.

One conclusion I draw from this is that, as STUN itself predicts, the 
NAT classification algorithm is brittle because it makes assumptions 
about the types of NATs and there behaviors. We are now seeing NATs that 
have this dual behavior, depending on whether the internal port is 
allocated or not, and STUN's detection algorithm does not take this into 
account. Indeed, I would be inclined to work on reivising STUN, and in 
such a revision, remove the detection algorithm and explain why that was 
done. What do people think of that?

To me, this also further strengthens the arguments behind something like 
ICE (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-00.txt), 
which uses STUN, but does *not* use the detection algorithm. Rather, it 
relies on dynamic connectivity checks to figure out whether an address 
works or not. The argument there is that, ultimately, the only way to 
know whether you can receive media sent from address A to interface X is 
if you can receive a packet from address A sent to interface X. Any 
other way of verifying this conclusion is based on assumptions that can 
be wrong.

Thanks,
Jonathan R.
--

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen <at> dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com
(Continue reading)

Permalink | Reply | 27 comments |
headers
Jiri Kuthan | 12 Feb 2004 18:17
Picon
Favicon

(no subject)

At 08:57 PM 2/10/2004, Jonathan Rosenberg wrote:
>This is a great piece of work. Thanks to Cullen for putting this together.

Cullen,

thanks, that's indeed a very helpful piece of information. In particular
the observation that modern NATs are rarely symmetric makes me feel better.
(The current situation is AFAIK roughly up to 20% of user population is 
behind symmetric NATs.)

Can you send me STUN traces (PCAP at best) for some of the non-deterministic 
NATs? Particularly according to some tests we did long time ago, Linksys WRT54G
was symmetric all the time. Unfortunately, I no longer have one around to retest
and I did not record firmware version either.

-jiri
Permalink | Reply | 13 comments |
headers
Jiri Kuthan | 13 Feb 2004 13:08
Picon
Favicon

[Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt]

At 06:17 PM 2/12/2004, Jiri Kuthan wrote:
>At 08:57 PM 2/10/2004, Jonathan Rosenberg wrote:
>>This is a great piece of work. Thanks to Cullen for putting this together.
>
>Cullen,
>
>thanks, that's indeed a very helpful piece of information. In particular
>the observation that modern NATs are rarely symmetric makes me feel better.
>(The current situation is AFAIK roughly up to 20% of user population is 
>behind symmetric NATs.)
>
>Can you send me STUN traces (PCAP at best) for some of the non-deterministic 
>NATs? Particularly according to some tests we did long time ago, Linksys WRT54G
>was symmetric all the time. Unfortunately, I no longer have one around to retest
>and I did not record firmware version either.

WRT to this particular case, linksys web tells me the box is Linux based
(http://www.linksys.com/support/gpl.asp) in which case chances are high
the box is symmetric all the times. I agree it would be good to verify your
list -- what a pity we just missed an opportunity at sipit.

-jiri
Permalink | Reply | 12 comments |
headers
Jiri Kuthan | 13 Feb 2004 14:48
Picon
Favicon

Re: [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt]

At 08:57 PM 2/10/2004, Jonathan Rosenberg wrote:
>This is a great piece of work. Thanks to Cullen for putting this together.
>
>One conclusion I draw from this is that, as STUN itself predicts, the NAT classification algorithm is
brittle because it makes assumptions about the types of NATs and there behaviors. We are now seeing NATs
that have this dual behavior, depending on whether the internal port is allocated or not, and STUN's
detection algorithm does not take this into account. Indeed, I would be inclined to work on reivising
STUN, and in such a revision, remove the detection algorithm and explain why that was done. What do people
think of that?

I think there is still some value in the NAT-type tests even with 
use of ICE. Positive assertions about traversable NATs may be brittle, 
I agree. Negative assertions about hard-to-traverse NATs are quite 
safe and can eliminiate unnecessary tries. Particularly, if you know 
you are behind a symmetric NAT you can safely eliminate STUN address 
from your offer. 

>To me, this also further strengthens the arguments behind something like ICE
(http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-00.txt), which uses STUN, but does
*not* use the detection algorithm. Rather, it relies on dynamic connectivity checks to figure out
whether an address works or not. The argument there is that, ultimately, the only way to know whether you
can receive media sent from address A to interface X is if you can receive a packet from address A sent to
interface X. Any other way of verifying this conclusion is based on assumptions that can be wrong.

Whereas I am quite comfortable with ICE and enjoy its e2e robustness, 
I think there is still some other, parallel, undone work. The left option 
of using a media relay indicates to me that there is an architectural 
imperfection and I see it in silly NATs (silly is an aggregate word standing 
for undeterministic or symmetric or bad or whatsoever). It seems very
desirable to me to abandon such devices and I think it is a quite realistic
(Continue reading)

Permalink | Reply | 12 comments |
headers
Bryan Ford | 13 Feb 2004 16:01
Picon
Favicon

Re: [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt]

On Friday 13 February 2004 08:48 am, Jiri Kuthan wrote:
> A way the IETF can help is to collect recommendations for NATs. There was
> such an effort long time ago
> (http://www.iptel.org/ietf/firewall/nat/draft-ietf-mmusic-natreq4udp-00.txt
>), I maintain a very similar list as well (don't be silly, keep NAT bindings
> for a while, allow  hairpinning, try to preserve port numbers, try to use
> stateless binding allocation algorithms).

FYI, Pyda Srisuresh, Dan Kegel and I have for a while been working on a 
document whose sole purpose is to collect precisely these things - general 
recommendations for NATs, and general (protocol-independent) recommendations 
for applications trying to traverse NATs.  It's already gone through a few 
versions; the latest one recently came back from first review by the IESG, 
and we're hoping to have another, near-final update before long.  The most 
recent version is available here:

	http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt

Please let me know if you find inaccuracies or have other comments/additions.  
Thanks!

Bryan
Permalink | Reply | 8 comments |
headers
Justin Uberti | 13 Feb 2004 16:19
Picon
Favicon

Re: [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt

Here at AOL we have found that the WRT54G is port-restricted cone in its 
normal mode, which is what is documented by Cullen. Our other test 
results are also mostly consistent with the document, with the exception 
of some Linksys models, where the difference may be explained by 
different firmware versions. We were not able to find any symmetric NATs 
in our admittedly small sample.

Cisco PIIX       Port
DLink DI-704P    Cone
Linksys BEFSR41  Addr
Linksys BEFSX41  Addr
Linksys BEFW11S4 Port
Linksys WRT54G   Port
Netgear RP614    Cone
Netgear WGR614   Cone

FWIW, we have found that some Linksys routers will rewrite the IP 
address in the STUN reply to be the nonroutable (e.g. 192.168.x.x) 
address rather than the NAT address, causing the STUN detection to 
classify the connectivity as "Open". For our STUN-like protocol we have 
the server XOR the IP address prior to returning it to prevent such 
rewriting.

Also, we have observed from our customers this approximate breakdown in 
market share: (obviously heavily skewed toward a US population)
Linksys     59%
Netgear     14%
DLink       13%
Belkin       5%
Microsoft    3%
(Continue reading)

Permalink | Reply | 10 comments |
headers
Bryan Ford | 13 Feb 2004 16:41
Picon
Favicon

Re: [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt

On Friday 13 February 2004 10:19 am, Justin Uberti wrote:
> Also, we have observed from our customers this approximate breakdown in
> market share: (obviously heavily skewed toward a US population)
> Linksys     59%
> Netgear     14%
> DLink       13%
> Belkin       5%
> Microsoft    3%
> SMC          2%
> Siemens      2%
> Zyxel        1%
> ActionTec    1%
> 3Com        <1%
> Comcast     <1%
> Dell        <1%

That's very useful info - thanks very much for posting it!

Out of curiosity, does anyone have any similar info about the types of 
"big-iron" NAT boxes are most commonly deployed at the ISP or corporate 
network level rather than at the consumer level?  I assume this area is 
Cisco-dominated, but to what degree, and who are the other significant 
players, if any?  The reason I ask is because it is at this level that not 
only [[port-]restricted] cone NAT becomes important, but also hairpin aka 
loopback translation support becomes critical, if users behind the same 
top-level NAT but separate second-level (consumer) NATs are to be able to 
talk to each other.

Justin, you folks at AOL deploy a lot of such boxes, don't you?  Do you 
know/can you divulge what type they are and what their NAT behavior is?
(Continue reading)

Permalink | Reply | 4 comments |

Gmane