[BEHAVE] Resend : 2nd WGLC draft-ietf-behave-nat-behavior-discovery-04

Begin forwarded message:

From: MAILER-DAEMON at core3.amsl.com (Mail Delivery System)
Date: August 28, 2008 7:42:05 PM MDT (CA)
To: fluffy at cisco.com
Subject: Undelivered Mail Returned to Sender

This is the mail system at host core3.amsl.com.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                  The mail system

<behave at core3.amsl.com>: Command time limit exceeded: "/a/postconfirm/mailman
   post behave ietf.org"
Reporting-MTA: dns; core3.amsl.com
X-Postfix-Queue-ID: 29F9A28C2FF
X-Postfix-Sender: rfc822; fluffy at cisco.com
Arrival-Date: Thu, 28 Aug 2008 18:25:24 -0700 (PDT)

Final-Recipient: rfc822; behave at core3.amsl.com
Original-Recipient: rfc822;behave at ietf.org
Action: failed
Status: 5.3.0
Diagnostic-Code: x-unix; internal software error

From: Cullen Jennings <fluffy at cisco.com>
Date: August 28, 2008 7:25:37 PM MDT (CA)
To: Behave WG <behave at ietf.org>, Bruce Lowekamp <lowekamp at sipeerior.com>, Derek MacDonald <derek at xten.com>
From: MAILER-DAEMON at core3.amsl.com (Mail Delivery System)
Date: August 28, 2008 7:42:05 PM MDT (CA)
To: fluffy at cisco.com
Subject: Undelivered Mail Returned to Sender

This is the mail system at host core3.amsl.com.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                  The mail system

<behave at core3.amsl.com>: Command time limit exceeded: "/a/postconfirm/mailman
   post behave ietf.org"
Reporting-MTA: dns; core3.amsl.com
X-Postfix-Queue-ID: 29F9A28C2FF
X-Postfix-Sender: rfc822; fluffy at cisco.com
Arrival-Date: Thu, 28 Aug 2008 18:25:24 -0700 (PDT)

Final-Recipient: rfc822; behave at core3.amsl.com
Original-Recipient: rfc822;behave at ietf.org
Action: failed
Status: 5.3.0
Diagnostic-Code: x-unix; internal software error

From: Cullen Jennings <fluffy at cisco.com>
Date: August 28, 2008 7:25:37 PM MDT (CA)
To: Behave WG <behave at ietf.org>, Bruce Lowekamp <lowekamp at sipeerior.com>, Derek MacDonald <derek at xten.com>
Subject: Re: [BEHAVE] 2nd WGLC draft-ietf-behave-nat-behavior-discovery-04

Few comments

Test 1: The first test defined in section 4.1 You have to have a good way to distinguish not UDP connectivity from the case where the STUN server is down or someone put in the wrong address.

Test 2: In test 4.2, I think it is important to identity that this test has to be done for every single port the application wants to use because we know that the results for different ports are often not the same

Test 3: This would be better if it mandated using a random source port and highlight that if any device had recently done test 2 on the same port, this test will fail to get the correct result and it fails in a way that suggests things will work that don't. It may sound odd to think one might get the same port but often when an embedded system reboots, it might run the same tests again at the same IP address and with ports like this.

Section 4.4 - given the rate limiting of NATs, I would give some advice that was more implementable than "care must be given". I'd specifically rate limit to something like no more than X stun packets per second. It would be nice to discuss here how long these tests can take even when they are done in parallel.

Section 4.5 - the XOR-RESPONSE-TARGET just sort comes out of nowhere and is a bit hard to understand when reading the draft from front to back

The whole XOR-RESPONSE-TARGET has all the same security problems and issues as TURN. Instead of reinventing it all here, why not just use TURN to be able to send the packets to where you want them?

In section 6.1 where you have "the server must verity that it has previously..." I think this must needs to be a MUST

I will note the RESPONSE-TARGET design forces the server to remember for some time some state about every binding request.

Section 5.1 - the SRV service name needs to be in the IANA registry

Cullen <as an individual contributor>

On Aug 7, 2008, at 18:26 , Dan Wing wrote:

I'd like to do a quick one week 2nd WGLC on "NAT Behavior Discovery Using
STUN",
<http://tools.ietf.org/html/draft-ietf-behave-nat-behavior-discovery-04>.
This will end on August 14th.

Please send comments to the authors (CC'd) and the list.

-d

_______________________________________________
Behave mailing list
Behave at ietf.org
https://www.ietf.org/mailman/listinfo/behave

[BEHAVE] Resend : 2nd WGLC draft-ietf-behave-nat-behavior-discovery-04

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.