Re: [rtcweb] Adopting draft-muthu-behave-consent-freshness?

["Lijing (Jessie, Huawei)" <[e-mail]>]

Hi all,

As a newcomer to RTCWEB, I have some doubts after I have read the draft. 

1. in "4.  Solution Overview", may be it would be better to clarify when to send a STUN Binding Request(in the middle of a media session or before sending traffic, during sending traffic or only during silence periods) and which side to send the request(controlling agent or both sides)? During the session, there are RTP/RTCP media streams which can keep the NAT mapping and confirm the connectivity state of the media plane. Before the session, we can use the ICE connectivity checks. 
So according to my understanding, the STUN Binding Request should only be sent during the silence periods. A media connectivity check with a request and a response during a session, is this the main idea of this document?

2. in " 7.  Security Considerations", there are the following words. 
  "Once that connection to the remote
   peer has been established with ICE, the consent to continue sending
   traffic does not benefit from re-asserting that same username and
   password, so long as the senders and receiver's IP addresses remain
   the same (as they usually do)."

   As when one agent receives STUN Binding Request, unlike the processing of STUN Binding Indication message, it have to do more processes to send the Response message, I am not sure whether it is appreciate not to authenticate the source and respond directly. Is it more likely to receive malicious attacks?

Neglect my words, if my understandings are wrong.

Best regards,

Jessie


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Magnus Westerlund
Sent: Monday, September 09, 2013 4:37 PM
To: [e-mail]
Subject: [rtcweb] Adopting draft-muthu-behave-consent-freshness?

WG,

This is a call for WG adoption of STUN Usage for Consent Freshness
(draft-muthu-behave-consent-freshness-04). This document defines a STUN
usage for consent freshness. As this requires no protocol extensions we
as intended users can define this usage in our WG. Such work also
matches our charter. The draft-ietf-rtcweb-security-arch-07 is
normatively dependent on this STUN usage.

Document:
https://datatracker.ietf.org/doc/draft-muthu-behave-consent-freshness/

WG, please indicate your support or issues with adopting this document
as WG item with a proposed milestone:

Mar 2014 Send STUN Usage for Consent Freshness to IESG for publication
as proposed standard.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------

_______________________________________________
rtcweb mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rtcweb