Subject: [bfcpbis] BFCP-UDP and DTLS

From: Christer Holmberg <[email-masked]>
Date: Wed, 28 Nov 2012 08:55:31 +0000

Hi,

I haven't really been following the BFCPbis work, so I appologize if the following has been discussed.

draft-ietf-bfcpbis-rfc4583bis-03 refers to section 5 of RFC 5763 for the SDP Offer/Answer procedures, and DTLS role selection (TLS client/server).

However, I think it would also be good to refer to section 6.7 of RFC 5763. Especially section 6.7.2 is important, in my view. It says that the passive UA sends a STUN request, in order to open the NAT pin hole, which means both UAs don't have to be active if they are behind NATs, and don't support ICE. Otherwise it could cause problem, if both are active and end up acting as TLS clients.

Regards,

Christer

---

From: Tom Kristensen <[email-masked]>
Date: Wed, 28 Nov 2012 15:35:50 +0100

Thanks Christer,

In the upcoming version of rfc4583bis, the usage of the RFC 4145 'setup' 
will be described (in Section 8). This attribute was just mentioned in 
rfc4582bis until now.

In rfc4582bis we say: "In order to facilitate the initial establishment 
of NAT bindings, and to maintain those bindings once established, BFCP 
entities using unreliable transport are RECOMMENDED to use STUN <xref 
target="RFC5389"/> Binding Indication for keep-alives, as described for 
ICE <xref target="RFC5245"/>."

However, we may refer to Section 6.7 (and especially 6.7.2) as well, but 
that may belong to rfc4582bis (where usage of STUN binding indications 
are recommended) instead of rfc4583bis?

-- Tom

On 11/28/2012 09:55 AM, Christer Holmberg wrote:
> draft-ietf-bfcpbis-rfc4583bis-03 refers to section 5 of RFC 5763 for 
> the SDP Offer/Answer procedures, and DTLS role selection (TLS 
> client/server).
>
> However, I think it would also be good to refer to section 6.7 of RFC 
> 5763. Especially section 6.7.2 is important, in my view. It says that 
> the passive UA sends a STUN request, in order to open the NAT pin 
> hole, which means both UAs don't have to be active if they are behind 
> NATs, and don't support ICE. Otherwise it could cause problem, if both 
> are active and end up acting as TLS clients.
>
> Regards,
>
> Christer
>
>
> _______________________________________________
> bfcpbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bfcpbis
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 28 Nov 2012 21:49:21 +0000

(as an individual)
Adding a reference to 6.7.2 of RFC 5763 sounds like a good idea to me, and I agree that rfc4582bis is probably a more appropriate place for this than rfc4583bis.

Cheers,
Charles

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Tom Kristensen (tomkrist)
> Sent: Wednesday, November 28, 2012 6:36 AM
> To: [email-masked]
> Subject: Re: [bfcpbis] BFCP-UDP and DTLS
> 
> Thanks Christer,
> 
> In the upcoming version of rfc4583bis, the usage of the RFC 4145 'setup' will
> be described (in Section 8). This attribute was just mentioned in rfc4582bis
> until now.
> 
> In rfc4582bis we say: "In order to facilitate the initial establishment of NAT
> bindings, and to maintain those bindings once established, BFCP entities
> using unreliable transport are RECOMMENDED to use STUN <xref
> target="RFC5389"/> Binding Indication for keep-alives, as described for ICE
> <xref target="RFC5245"/>."
> 
> However, we may refer to Section 6.7 (and especially 6.7.2) as well, but that
> may belong to rfc4582bis (where usage of STUN binding indications are
> recommended) instead of rfc4583bis?
> 
> -- Tom
> 
> 5763. Especially section 6.7.2 is important, in my view. It says that the
> passive UA sends a STUN request, in order to open the NAT pin hole, which
> means both UAs don't have to be active if they are behind NATs, and don't
> support ICE. Otherwise it could cause problem, if both are active and end up
> acting as TLS clients.
> 
> 
> 
> 	Regards,
> 
> 
> 
> 	Christer
> 
> 
>