Subject: [BEHAVE] Path MTU Discovery Using STUN (-01)

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 14 Jul 2008 16:53:06 -0700

I just submitted an updated I-D:

http://www.ietf.org/internet-drafts/draft-petithuguenin-behave-stun-pmtud-01.txt

Comments appreciated.

Thanks.

Changelog:

   o  Removed the use of modified STUN transaction but shorten the
      retransmission for the simple probing mechanism.
   o  Added a complete probing mechanism.
   o  Removed the PADDING-RECEIVED attribute.
   o  Added release notes.

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]
[                                                               ]
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 21 Jul 2008 18:42:07 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Marc Petit-Huguenin
> Sent: Monday, July 14, 2008 4:53 PM
> To: Behave WG
> Subject: [BEHAVE] Path MTU Discovery Using STUN (-01)
>

Has anyone read Marc's draft and has comments they would like to share?

-d

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 23 Jul 2008 12:25:13 +0300

> http://www.ietf.org/internet-drafts/draft-petithuguenin-behave-stun-pmtud-0

In section 4.2, I wonder how the server knows whether the IP/port is used by 
another protocol... ? What about MUST add a FINGERPRINT if the Request had 
one, and MAY add a FINGERPRINT if the Request did not?

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 23 Jul 2008 12:45:48 -0700

Rémi Denis-Courmont wrote:
> another protocol... ? 

You are right, the server can not be sure 100%, no more than the client
(in section 4.1).  I'll change the text to say that the client and the
server MUST add the FINGERPRINT attribute, in all cases.

> What about MUST add a FINGERPRINT if the Request had 

Thanks.

---

From: Bruce Lowekamp <[email-masked]>
Date: Thu, 24 Jul 2008 11:30:33 -0400

> server MUST add the FINGERPRINT attribute, in all cases.

This strikes me as excessive.  FINGERPRINT is optional in 3489bis and 
only intended for use when STUN is being multiplexed with a protocol 
that cannot be distinguished from STUN.  Making its use a MUST with a 
STUN extension that can be used with any application seems unnecessary. 
  I would rather just leave it up to the application/specific usage to 
specify whether FINGERPRINT is required in client requests.  I agree 
with Rémi's suggestion to specify that the server MUST add it if the 
Request had it.

Bruce

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 31 Jul 2008 21:20:43 +0100

Bruce Lowekamp wrote:
>>>> http://www.ietf.org/internet-drafts/draft-petithuguenin-behave-stun-pmtud-0
>>>>
>>>> 1.txt
>>> In section 4.2, I wonder how the server knows whether the IP/port is
>>> used by another protocol... ? 
>>
>>> What about MUST add a FINGERPRINT if the Request had one, and MAY add
>>> a FINGERPRINT if the Request did not?

Sorry for the delay for responding.

I spent some time thinking about this, and my conclusions are 1) that I
agree that using FINGERPRINT or not should be decided protocol by
protocol and 2) that the decision of using a FINGERPRINT in a response
is independent of the decision of using it in a request (even if they
are often the same).  I apologize to do not have the time to elaborate
more on this (IETF meeting), but I will publish a new version of the I-D
soon that will explain this and that can be used for subsequent
discussions.  Note that Dan is still trying to find the right WG for
this work (many thanks to Dan for his support) but I will anyway post a
note in this m.-l. as soon a new version is available.

Thank you for your interest in this work.

-- 
Marc Petit-Huguenin
Home: [email-masked]
Work: [email-masked]