From 5057dea40dc97233bf76adb80d3438c147a52a5c Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 22 May 2015 10:58:27 -0700 Subject: [PATCH 1/3] Use version control properly --- ...-ietf-rtcweb-stun-consent-freshness-03.xml | 490 ----------------- ...-ietf-rtcweb-stun-consent-freshness-04.xml | 463 ---------------- ...-ietf-rtcweb-stun-consent-freshness-05.xml | 457 ---------------- ...-ietf-rtcweb-stun-consent-freshness-06.xml | 475 ----------------- ...-ietf-rtcweb-stun-consent-freshness-07.xml | 492 ------------------ ...-ietf-rtcweb-stun-consent-freshness-08.xml | 408 --------------- ...-ietf-rtcweb-stun-consent-freshness-09.xml | 424 --------------- ...-ietf-rtcweb-stun-consent-freshness-10.xml | 392 -------------- ...ft-ietf-rtcweb-stun-consent-freshness.xml} | 0 9 files changed, 3601 deletions(-) delete mode 100644 STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-03.xml delete mode 100644 STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-04.xml delete mode 100644 STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-05.xml delete mode 100644 STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-06.xml delete mode 100644 STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-07.xml delete mode 100644 STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-08.xml delete mode 100644 STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-09.xml delete mode 100644 STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-10.xml rename STUN-Consent-draft/{draft-ietf-rtcweb-stun-consent-freshness-13.xml => draft-ietf-rtcweb-stun-consent-freshness.xml} (100%) diff --git a/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-03.xml b/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-03.xml deleted file mode 100644 index b87142c..0000000 --- a/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-03.xml +++ /dev/null @@ -1,490 +0,0 @@ - - - - - - - - - - - - - - - - STUN Usage for Consent - Freshness - - - Cisco Systems - -
- - Cessna Business Park - - Sarjapur-Marathahalli Outer Ring Road - - Bangalore - - Karnataka - - 560103 - - India - - - mperumal@cisco.com -
- - - - Cisco Systems - -
- - 821 Alder Drive - - Milpitas - - California - - 95035 - - USA - - - dwing@cisco.com -
- - - - Cisco Systems - -
- - Cessna Business Park - - Sarjapur-Marathahalli Outer Ring Road - - Bangalore - - Karnataka - - 560103 - - India - - - rmohanr@cisco.com -
- - - - Cisco Systems - -
- - Cessna Business Park, Varthur Hobli - - Sarjapur Marathalli Outer Ring Road - - Bangalore - - Karnataka - - 560103 - - India - - - tireddy@cisco.com -
- - - - Mozilla - -
- - Suite 300 - - 650 Castro Street - - Mountain View - - California - - 94041 - - US - - - martin.thomson@gmail.com -
- - - - - RAI - - RTCWEB - - - To prevent sending excessive traffic to an endpoint, periodic consent - needs to be obtained from that remote endpoint. - - This document describes a consent mechanism using a new STUN usage. - This same mechanism can also determine connection loss ("liveness") with - a remote peer. - - - - -
- To prevent attacks on peers, RTP endpoints have to ensure the remote - peer wants to receive traffic. This is performed both when the session - is first established to the remote peer using ICE connectivity checks, - and periodically for the duration of the session using the procedures - defined in this document. - - When a session is first established, WebRTC implementations are - required to perform STUN connectivity checks as part of ICE. That initial consent is not described - further in this document and it is assumed that ICE is being used for - that initial consent. - - Related to consent is loss of connectivity ("liveness"). Many - applications want notification of connection loss to take appropriate - actions (e.g., alert the user, try switching to a different - interface). - - This document describes a new STUN usage with exchange of request and - response messages to verify the remote peer's consent to receive traffic, - and the absence of which for a period of time indicates a loss of liveness. - - Consent is done irrespective of transport protocol used for media. When - TCP is used as transport for media from a TURN client to a TURN server and - UDP is used from the server to the remote peer, Consent MUST be done by the - TURN Client. For other cases where TCP is used for media, Consent MAY be done - by the endpoints. -
- -
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in . - - - It is the mechanism of obtaining - permission to send traffic to a certain transport address. - This is the initial consent to send traffic, which is - obtained by ICE or a TCP handshake. - - Permission to continue sending - traffic to a certain transport address. This is performed by the - procedure described in this document. - - Detecting loss of connectivity to a - certain transport address. This is performed by the procedure - described in this document. - - The remote peer's IP address and - (UDP or TCP) port number. - -
- -
- Although ICE requires periodic keepalive traffic to keep NAT bindings - alive (Section 10 of , ), those keepalives are sent as STUN Indications - which are send-and-forget, and do not evoke a response. A response is - necessary both for consent to continue sending traffic, as well as to - verify session liveness. Thus, we need a request/response mechanism for - consent freshness. ICE can be used for that mechanism because ICE - already requires ICE agents continue listening for ICE messages, as - described in section 10 of . - - -
- -
- There are two ways consent to send traffic is revoked: expiration -of consent and immediate revocation of consent, which are discussed in -the following sections. - -
- A WebRTC browser performs a combined consent freshness and session - liveness test using STUN request/response as described below: - - An endpoint MUST NOT send application data (e.g., RTP, RTCP, - SCTP, DTLS) on an ICE-initiated connection unless the receiving - endpoint consents to receive the data. After a successful ICE - connectivity check on a particular transport address, subsequent - consent MUST be obtained following the procedure described in - this document. The consent expires after a fixed amount of - time. - - Explicit consent to send is obtained by sending an ICE - binding request to the remote peer's Transport Address and - receiving a matching and authenticated ICE binding response from - the inverted remote peer's Transport Address. These ICE binding - requests and responses are authenticated using the same - short-term credentials as the initial ICE exchange, but using a - new (fresh) transaction-id each time consent needs to be - refreshed. Implementations MUST obtain fresh consent before - their existing consent expires. If an ICE binding response is not - received after waiting for 5 (+/-1) seconds (giving ample time for - the response to be received), another ICE binding request is sent using - a new (fresh) transaction-id (so that round-trip time can be calculated), - and re-transmissions MUST NOT be sent more frequently than every - 500ms or the smoothed round-trip time (from previous consent - freshness checks or RTP round-trip time), whichever is less. For - the purposes of this document, receipt of an ICE response with - the matching transaction-id of its request with a valid - MESSAGE-INTEGRITY is considered a consent response. - - The initial Consent to send traffic is obtained by ICE. Consent - expires after 30 seconds. That is, if a valid STUN - binding response corresponding to one of the STUN requests sent - in the last 30 seconds has not been received from the inverted - 5-tuple, the endpoint MUST cease transmission on that - 5-tuple. - - - To meet the security needs of consent, an untrusted -application (e.g., JavaScript) MUST NOT be able to obtain or control -the ICE transaction-id, because that enables spoofing STUN responses, -falsifying consent - -An endpoint that is not sending any application traffic -does not need to obtain consent which can slightly conserve its -resources. However, the endpoint needs to ensure its NAT or firewall -mappings persist which can be done using keepalive or other techniques -(see Section 10 of and -see ). If the endpoint wants send -application traffic, it needs to first obtain consent if its consent has -expired. - - -
-
- The previous section explained how consent expires due to a -timeout. In some cases it is useful to signal a connection is -terminated, rather than relying on a timeout. This is done by -immediately revoking consent. - - Consent for sending traffic on the media or data channel is - revoked by receipt of a an authenticated message that closes - the connection (for instance, a TLS fatal alert). - - Receipt of an unauthenticated message that closes a - connection (e.g., TCP FIN) does not indicate revocation of - consent. Thus, an endpoint receiving an unauthenticated - end-of-session message SHOULD continue sending media (over - connectionless transport) or attempt to re-establish the - connection (over connection-oriented transport) until consent - expires or it receives an authenticated message revoking - consent. -
- -
- - - -
- A connection is considered "live" if packets are received from a - remote endpoint within an application-dependent period. An application - can request a notification when there are no packets received for a - certain period (configurable). - - Similarly, if packets haven't been received within a certain period, - an application can request a consent check (heartbeat) be generated. - These two time intervals might be controlled by the same configuration - item. - - Sending consent checks (heartbeats) at a high rate could allow a - malicious application to generate congestion, so applications MUST NOT - send heartbeats at an average rate of more than 1 per second. -
- -
- It is RECOMMENDED that STUN consent checks use the same Diffserv - Codepoint markings as the ICE connectivity checks described in - section 7.1.2.4 of for a given 5-tuple. - - Note: It is possible that different Diffserv Codepoints are used by - different media over the same transport address . Such a case is outside the - scope of this document. -
- -
- For the consent freshness and liveness test the W3C specification - should provide APIs as described below: - Ability for the browser to notify the JavaScript that a consent - freshness transaction has failed for a media stream and the browser - has stopped transmitting for that stream. - - Ability for the JavaScript to start and stop liveness test and - set the liveness test interval. - - Ability for the browser to notify the JavaScript that a liveness - test has failed for a media stream. - -
- -
- This document describes a security mechanism. - - The security considerations discussed in should also be taken into account. - - SRTP is encrypted and authenticated with symmetric keys; that is, - both sender and receiver know the keys. With two party sessions, receipt - of an authenticated packet from the single remote party is a strong - assurance the packet came from that party. However, when a session - involves more than two parties, all of whom know each others keys, any - of those parties could have sent (or spoofed) the packet. Such shared - key distributions are possible with some MIKEY modes, Security - Descriptions, and EKT. Thus, in such shared - keying distributions, receipt of an authenticated SRTP packet is not - sufficient. -
- -
- This document does not require any action from IANA. -
- -
- Thanks to Eric Rescorla, Harald Alvestrand, Bernard Aboba, Magnus - Westerland, Cullen Jennings and Simon Perreault for their valuable - inputs and comments. -
- - - - - - - - - - - - - - - - - - - - - -
- This section describes one possible implementation algorithm - of consent. This section is non-normative and provided for - reference only. - - The solution uses three values: - - - A consent timer, Tc, whose value is set to 30 seconds. - - A packet receipt timer, Tr, whose value is determined by the - application. Tr can be greater than 1 but less than 30 seconds and - has a default value of 5 seconds. - - A consent timeout, Tf, which is how many seconds elapse without a - consent response before the browser ceases transmission of media. - Its value is be 30 seconds or less. - - A retransmission Timer, Tret, whose value is determined by the - RTT of a given path. The duration of this timer is set to 1.5 times of ( 500 ms or - the smoothened round-trip time (from previous consent freshness checks - or RTP round-trip time)), whichever is less. - - - A WebRTC browser performs a combined consent freshness and session - liveness test using STUN request/response as described below: - - Every Tc seconds, the WebRTC browser sends a STUN Binding Request to - the peer. The difference from ICE connectivity check is that there is no - exponential back off for retransmissions. - - If a valid STUN Binding Response is received, the consent timer is - reset to the time of receiving the response and fires again Tc seconds - later. - - If a valid STUN Binding Response is not received after Tret - milliseconds, the STUN Binding Request is retransmitted (with a new - Transaction ID). As long as a valid STUN Binding - Response is not received, this retransmission is repeated every Tret - milliseconds until Tf seconds have elapsed or a valid response is - received. If no valid response is received after Tf seconds, the WebRTC - browser quits transmitting traffic to this remote peer. The streams that - are being sent on a flow(5-tuple) for which a consent has failed will be - stopped. If the default value of Tf is 30 seconds then media - transmission will stop Consent (Tf) expires. -
- - diff --git a/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-04.xml b/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-04.xml deleted file mode 100644 index a73980e..0000000 --- a/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-04.xml +++ /dev/null @@ -1,463 +0,0 @@ - - - - - - - - - - - - - - - - STUN Usage for Consent - Freshness - - - Cisco Systems - -
- - Cessna Business Park - - Sarjapur-Marathahalli Outer Ring Road - - Bangalore - - Karnataka - - 560103 - - India - - - mperumal@cisco.com -
- - - - Cisco Systems - -
- - 821 Alder Drive - - Milpitas - - California - - 95035 - - USA - - - dwing@cisco.com -
- - - - Cisco Systems - -
- - Cessna Business Park - - Sarjapur-Marathahalli Outer Ring Road - - Bangalore - - Karnataka - - 560103 - - India - - - rmohanr@cisco.com -
- - - - Cisco Systems - -
- - Cessna Business Park, Varthur Hobli - - Sarjapur Marathalli Outer Ring Road - - Bangalore - - Karnataka - - 560103 - - India - - - tireddy@cisco.com -
- - - - Mozilla - -
- - Suite 300 - - 650 Castro Street - - Mountain View - - California - - 94041 - - US - - - martin.thomson@gmail.com -
- - - - - RAI - - RTCWEB - - - To prevent sending excessive traffic to an endpoint, periodic consent - needs to be obtained from that remote endpoint. - - This document describes a consent mechanism using a new STUN usage. - This same mechanism can also determine connection loss ("liveness") with - a remote peer. - - - - -
- To prevent attacks on peers, RTP endpoints have to ensure the remote - peer wants to receive traffic. This is performed both when the session - is first established to the remote peer using ICE connectivity checks, - and periodically for the duration of the session using the procedures - defined in this document. - - When a session is first established, WebRTC implementations are - required to perform STUN connectivity checks as part of ICE. That initial consent is not described - further in this document and it is assumed that ICE is being used for - that initial consent. - - Related to consent is loss of connectivity ("liveness"). Many - applications want notification of connection loss to take appropriate - actions (e.g., alert the user, try switching to a different - interface). - - This document describes a new STUN usage with exchange of request and - response messages to verify the remote peer's consent to receive traffic, - and the absence of which for a period of time indicates a loss of liveness. - -
- -
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in . - - - It is the mechanism of obtaining - permission to send traffic to a certain transport address. - This is the initial consent to send traffic, which is - obtained by ICE or a TCP handshake. - - Permission to continue sending - traffic to a certain transport address. This is performed by the - procedure described in this document. - - Detecting loss of connectivity to a - certain transport address. This is performed by the procedure - described in this document. - - The remote peer's IP address and - (UDP or TCP) port number. - -
- -
- Although ICE requires periodic keepalive traffic to keep NAT bindings - alive (Section 10 of , ), those keepalives are sent as STUN Indications - which are send-and-forget, and do not evoke a response. A response is - necessary both for consent to continue sending traffic, as well as to - verify session liveness. Thus, we need a request/response mechanism for - consent freshness. ICE can be used for that mechanism because ICE - already requires ICE agents continue listening for ICE messages, as - described in section 10 of . - - -
- -
- There are two ways consent to send traffic is revoked: expiration -of consent and immediate revocation of consent, which are discussed in -the following sections. - -
- A WebRTC browser performs a combined consent freshness and session - liveness test using STUN request/response as described below: - - An endpoint MUST NOT send application data (e.g., RTP, RTCP, - SCTP, DTLS) on an ICE-initiated connection unless the receiving - endpoint consents to receive the data. After a successful ICE - connectivity check on a particular transport address, subsequent - consent MUST be obtained following the procedure described in - this document. The consent expires after a fixed amount of - time. - - Explicit consent to send is obtained by sending an ICE - binding request to the remote peer's Transport Address and - receiving a matching, authenticated, non-error ICE binding - response from the inverted remote peer's Transport - Address. These ICE binding requests and responses are - authenticated using the same short-term credentials as the - initial ICE exchange. Implementations MUST cease sending data - if their consent expires. To prevent expiry of consent, a STUN - binding request is sent every N milliseconds, where N SHOULD be - 5000 milliseconds and MUST be randomized at least 20% above and - 20% below that value (to prevent prevent network - synchronization). Using the value 5000 milliseconds and that - 20% randomization range, N would be a value between 4000 and - 6000. These STUN binding requests for consent are not - re-transmitted. Each STUN binding request for consent - re-calculates a new random value N and a - new cryptographically-random STUN - transaction ID. - - - The initial Consent to send traffic is obtained by ICE. Consent - expires after 30 seconds. That is, if a valid STUN - binding response corresponding to one of the STUN requests sent - in the last 30 seconds has not been received from the inverted - 5-tuple, the endpoint MUST cease transmission on that - 5-tuple. - - - To meet the security needs of consent, an untrusted -application (e.g., JavaScript) MUST NOT be able to obtain or control -the STUN transaction ID, because that enables spoofing STUN responses, -falsifying consent. - -While TCP affords some protection from off-path attackers -(, ), -there is still a risk an attacker could cause a TCP sender to send -packets forever by spoofing ACKs. To prevent such an attack, consent -checks MUST be performed over all WebRTC-initiated transport -connections, including TCP. In this way, an off-path attacker -spoofing TCP segments can not cause a TCP sender to send packets -longer than the consent timer (30 seconds). - - - -An endpoint that is not sending any application traffic does not -need to obtain consent which can slightly conserve its resources. -However, the endpoint needs to ensure its NAT or firewall mappings -persist which can be done using keepalive or other techniques -(see Section 10 of and -see ). If the endpoint wants to send -application traffic, it needs to first obtain consent if its consent -has expired. - - -
-
-The previous section explained how consent expires due to a -timeout. In some cases it is useful to signal a connection is -terminated, rather than relying on a timeout. This is done by -immediately revoking consent. - - Consent for sending traffic on the media or data channel is - immediately revoked by receipt of a an authenticated message - that closes the connection (e.g., a TLS fatal alert) or - receipt of a valid and authenticated STUN response with error - code Forbidden (403). - - Receipt of an unauthenticated message that closes a - connection (e.g., TCP FIN) does not indicate revocation of - consent. Thus, an endpoint receiving an unauthenticated - end-of-session message SHOULD continue sending media (over - connectionless transport) or attempt to re-establish the - connection (over connection-oriented transport) until consent - expires or it receives an authenticated message revoking - consent. - -Note that an authenticated SRTCP BYE does not terminate - consent; it only indicates the associated SRTP source - has quit. -
- -
- - - -
- A connection is considered "live" if packets are received from a - remote endpoint within an application-dependent period. An application - can request a notification when there are no packets received for a - certain period (configurable). - - Similarly, if packets haven't been received within a certain period, - an application can request a consent check (heartbeat) be generated. - These two time intervals might be controlled by the same configuration - item. - - Sending consent checks (heartbeats) at a high rate could allow a - malicious application to generate congestion, so applications MUST NOT - be able to send heartbeats at an average rate of more than 1 per second. -
- -
- It is RECOMMENDED that STUN consent checks use the same Diffserv - Codepoint markings as the ICE connectivity checks described in section - 7.1.2.4 of for a given 5-tuple. - - Note: It is possible that different Diffserv Codepoints are used by - different media over the same transport address . Such a case is outside the - scope of this document. -
- -
- For the consent freshness and liveness test the W3C specification - should provide APIs as described below: - Ability for the browser to notify the JavaScript that consent freshness - has failed for a 5-tuple and the browser has stopped transmitting on that - 5-tuple. - - Ability for the JavaScript to start and stop liveness test and - set the liveness test interval. - - Ability for the browser to notify the JavaScript that a liveness - test has failed for a media stream. - -
- -
- This document describes a security mechanism. - - The security considerations discussed in should also be taken into account. - - SRTP is encrypted and authenticated with symmetric keys; that is, - both sender and receiver know the keys. With two party sessions, receipt - of an authenticated packet from the single remote party is a strong - assurance the packet came from that party. However, when a session - involves more than two parties, all of whom know each others keys, any - of those parties could have sent (or spoofed) the packet. Such shared - key distributions are possible with some MIKEY modes, Security - Descriptions, and EKT. Thus, in such shared - keying distributions, receipt of an authenticated SRTP packet is not - sufficient to verify consent. -
- -
- This document does not require any action from IANA. -
- -
- Thanks to Eric Rescorla, Harald Alvestrand, Bernard Aboba, Magnus - Westerland, Cullen Jennings, Christer Holmberg and Simon Perreault for their valuable - inputs and comments. -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-05.xml b/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-05.xml deleted file mode 100644 index d3a5770..0000000 --- a/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-05.xml +++ /dev/null @@ -1,457 +0,0 @@ - - - - - - - - - - - - - - - - STUN Usage for Consent - Freshness - - - Ericsson -
- - Mahadevapura - Bangalore - Karnataka - 560048 - India - - muthu.arul@gmail.com -
- - - - Cisco Systems - -
- - 821 Alder Drive - - Milpitas - - California - - 95035 - - USA - - - dwing@cisco.com -
- - - - Cisco Systems - -
- - Cessna Business Park - - Sarjapur-Marathahalli Outer Ring Road - - Bangalore - - Karnataka - - 560103 - - India - - - rmohanr@cisco.com -
- - - - Cisco Systems - -
- - Cessna Business Park, Varthur Hobli - - Sarjapur Marathalli Outer Ring Road - - Bangalore - - Karnataka - - 560103 - - India - - - tireddy@cisco.com -
- - - - Mozilla - -
- - Suite 300 - - 650 Castro Street - - Mountain View - - California - - 94041 - - US - - - martin.thomson@gmail.com -
- - - - - RAI - - RTCWEB - - - To prevent sending excessive traffic to an endpoint, periodic consent - needs to be obtained from that remote endpoint. - - This document describes a consent mechanism using a new STUN usage. - This same mechanism can also determine connection loss ("liveness") with - a remote peer. - - - - -
- To prevent attacks on peers, RTP endpoints have to ensure the remote - peer wants to receive traffic. This is performed both when the session - is first established to the remote peer using ICE connectivity checks, - and periodically for the duration of the session using the procedures - defined in this document. - - When a session is first established, WebRTC implementations are - required to perform STUN connectivity checks as part of ICE. That initial consent is not described - further in this document and it is assumed that ICE is being used for - that initial consent. - - Related to consent is loss of connectivity ("liveness"). Many - applications want notification of connection loss to take appropriate - actions (e.g., alert the user, try switching to a different - interface). - - This document describes a new STUN usage with exchange of request and - response messages to verify the remote peer's consent to receive traffic, - and the absence of which for a period of time indicates a loss of liveness. - - WebRTC endpoints are required to support full ICE as specified in section 3.4 of . However, when WebRTC endpoints interwork with other endpoints that support only ICE-lite (e.g. gateways) those endpoints will not generate consent checks, but just respond to consent checks they receive. - -
- -
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in . - - - It is the mechanism of obtaining - permission to send traffic to a certain transport address. - This is the initial consent to send traffic, which is - obtained by ICE or a TCP handshake. - - Permission to continue sending - traffic to a certain transport address. This is performed by the - procedure described in this document. - - Detecting loss of connectivity to a - certain transport address. This is performed by the procedure - described in this document. - - The remote peer's IP address and - (UDP or TCP) port number. - - -
- -
- Although ICE requires periodic keepalive traffic to keep NAT bindings - alive (Section 10 of , ), those keepalives are sent as STUN Indications - which are send-and-forget, and do not evoke a response. A response is - necessary both for consent to continue sending traffic, as well as to - verify session liveness. Thus, we need a request/response mechanism for - consent freshness. ICE can be used for that mechanism because ICE - already requires ICE agents continue listening for ICE messages, as - described in section 10 of . - - -
- -
- There are two ways consent to send traffic is revoked: expiration -of consent and immediate revocation of consent, which are discussed in -the following sections. - -
- A WebRTC browser performs a combined consent freshness and session - liveness test using STUN request/response as described below: - - An endpoint MUST NOT send application data (e.g., RTP, RTCP, - SCTP, DTLS) on an ICE-initiated connection unless the receiving - endpoint consents to receive the data. After a successful ICE - connectivity check on a particular transport address, subsequent - consent MUST be obtained following the procedure described in - this document. The consent expires after a fixed amount of - time. - - Explicit consent to send is obtained by sending an ICE - binding request to the remote peer's Transport Address and - receiving a matching, authenticated, non-error ICE binding - response from the remote peer's Transport - Address. These ICE binding requests and responses are - authenticated using the same short-term credentials as the - initial ICE exchange. Implementations MUST cease sending data - if their consent expires. To prevent expiry of consent, a STUN - binding request is sent every N milliseconds, where N SHOULD be - 5000 milliseconds and MUST be randomized at least 20% above and - 20% below that value (to prevent prevent network - synchronization). Using the value 5000 milliseconds and that - 20% randomization range, N would be a value between 4000 and - 6000. These STUN binding requests for consent are not - re-transmitted. Each STUN binding request for consent - re-calculates a new random value N and a - new cryptographically-random STUN - transaction ID. - - - The initial Consent to send traffic is obtained by ICE. Consent - expires after 30 seconds. That is, if a valid STUN - binding response corresponding to one of the STUN requests sent - in the last 30 seconds has not been received from the remote peer's Transport Address, the endpoint MUST cease transmission on that 5-tuple. - - - To meet the security needs of consent, an untrusted -application (e.g., JavaScript) MUST NOT be able to obtain or control -the STUN transaction ID, because that enables spoofing STUN responses, -falsifying consent. - -While TCP affords some protection from off-path attackers -(, ), -there is still a risk an attacker could cause a TCP sender to send -packets forever by spoofing ACKs. To prevent such an attack, consent -checks MUST be performed over all WebRTC-initiated transport -connections, including TCP. In this way, an off-path attacker -spoofing TCP segments can not cause a TCP sender to send packets -longer than the consent timer (30 seconds). - - - -An endpoint that is not sending any application traffic does not -need to obtain consent which can slightly conserve its resources. -However, the endpoint needs to ensure its NAT or firewall mappings -persist which can be done using keepalive or other techniques -(see Section 10 of and -see ). If the endpoint wants to send -application traffic, it needs to first obtain consent if its consent -has expired. - - -
-
-The previous section explained how consent expires due to a -timeout. In some cases it is useful to signal a connection is -terminated, rather than relying on a timeout. This is done by -immediately revoking consent. - - Consent for sending traffic on the media or data channel is - immediately revoked by receipt of a an authenticated message - that closes the connection (e.g., a TLS fatal alert) or - receipt of a valid and authenticated STUN response with error - code Forbidden (403). - - Receipt of an unauthenticated message that closes a - connection (e.g., TCP FIN) does not indicate revocation of - consent. Thus, an endpoint receiving an unauthenticated - end-of-session message SHOULD continue sending media (over - connectionless transport) or attempt to re-establish the - connection (over connection-oriented transport) until consent - expires or it receives an authenticated message revoking - consent. - -Note that an authenticated SRTCP BYE does not terminate - consent; it only indicates the associated SRTP source - has quit. -
- -
- - - -
- A connection is considered "live" if packets are received from a - remote endpoint within an application-dependent period. An application - can request a notification when there are no packets received for a - certain period (configurable). - - Similarly, if packets haven't been received within a certain period, - an application can request a consent check (heartbeat) be generated. - These two time intervals might be controlled by the same configuration - item. - - Sending consent checks (heartbeats) at a high rate could allow a - malicious application to generate congestion, so applications MUST NOT - be able to send heartbeats at an average rate of more than 1 per second. -
- -
- It is RECOMMENDED that STUN consent checks use the same Diffserv - Codepoint markings as the ICE connectivity checks described in section - 7.1.2.4 of for a given 5-tuple. - - Note: It is possible that different Diffserv Codepoints are used by - different media over the same transport address . Such a case is outside the - scope of this document. -
- -
- For the consent freshness and liveness test the W3C specification - should provide APIs as described below: - Ability for the browser to notify the JavaScript that consent freshness - has failed for a 5-tuple and the browser has stopped transmitting on that - 5-tuple. - - Ability for the JavaScript to start and stop liveness test and - set the liveness test interval. - - Ability for the browser to notify the JavaScript that a liveness - test has failed for a media stream. - -
- -
- This document describes a security mechanism. - - The security considerations discussed in should also be taken into account. - - SRTP is encrypted and authenticated with symmetric keys; that is, - both sender and receiver know the keys. With two party sessions, receipt - of an authenticated packet from the single remote party is a strong - assurance the packet came from that party. However, when a session - involves more than two parties, all of whom know each others keys, any - of those parties could have sent (or spoofed) the packet. Such shared - key distributions are possible with some MIKEY modes, Security - Descriptions, and EKT. Thus, in such shared - keying distributions, receipt of an authenticated SRTP packet is not - sufficient to verify consent. -
- -
- This document does not require any action from IANA. -
- -
- Thanks to Eric Rescorla, Harald Alvestrand, Bernard Aboba, Magnus - Westerland, Cullen Jennings, Christer Holmberg and Simon Perreault for their valuable - inputs and comments. -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-06.xml b/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-06.xml deleted file mode 100644 index bdb4790..0000000 --- a/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-06.xml +++ /dev/null @@ -1,475 +0,0 @@ - - - - - - - - - - - - - - - - STUN Usage for Consent - Freshness - - - Ericsson -
- - Mahadevapura - Bangalore - Karnataka - 560048 - India - - muthu.arul@gmail.com -
- - - - Cisco Systems - -
- - 821 Alder Drive - - Milpitas - - California - - 95035 - - USA - - - dwing@cisco.com -
- - - - Cisco Systems - -
- - Cessna Business Park - - Sarjapur-Marathahalli Outer Ring Road - - Bangalore - - Karnataka - - 560103 - - India - - - rmohanr@cisco.com -
- - - - Cisco Systems - -
- - Cessna Business Park, Varthur Hobli - - Sarjapur Marathalli Outer Ring Road - - Bangalore - - Karnataka - - 560103 - - India - - - tireddy@cisco.com -
- - - - Mozilla - -
- - Suite 300 - - 650 Castro Street - - Mountain View - - California - - 94041 - - US - - - martin.thomson@gmail.com -
- - - - - RAI - - RTCWEB - - - To prevent sending excessive traffic to an endpoint, periodic consent - needs to be obtained from that remote endpoint. - - This document describes a consent mechanism using a new STUN usage. - This same mechanism can also determine connection loss ("liveness") with - a remote peer. - - - - -
- To prevent attacks on peers, RTP endpoints have to ensure the remote - peer wants to receive traffic. This is performed both when the session - is first established to the remote peer using ICE connectivity checks, - and periodically for the duration of the session using the procedures - defined in this document. - - When a session is first established, WebRTC implementations are - required to perform STUN connectivity checks as part of ICE. That initial consent is not described - further in this document and it is assumed that ICE is being used for - that initial consent. - - Related to consent is loss of connectivity ("liveness"). Many - applications want notification of connection loss to take appropriate - actions (e.g., alert the user, try switching to a different - interface). - - This document describes a new STUN usage with exchange of request and - response messages to verify the remote peer's consent to receive traffic, - and the absence of which for a period of time indicates a loss of liveness. - - WebRTC endpoints are required to support full ICE as - specified in section 3.4 of - . However, when - WebRTC endpoints interwork with other endpoints that support - only ICE-lite (e.g., gateways) those endpoints will not generate - consent checks, but just respond to consent checks they - receive. - -
- -
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in . - - - It is the mechanism of obtaining - permission to send traffic to a certain transport address. - This is the initial consent to send traffic, which is - obtained by ICE or a TCP handshake. - - Permission to continue sending - traffic to a certain transport address. This is performed by the - procedure described in this document. - - Detecting loss of connectivity to a - certain transport address. This is performed by the procedure - described in this document. - - The remote peer's IP address and - (UDP or TCP) port number. - - -
- -
- Although ICE requires periodic keepalive traffic to keep NAT bindings - alive (Section 10 of , ), those keepalives are sent as STUN Indications - which are send-and-forget, and do not evoke a response. A response is - necessary both for consent to continue sending traffic, as well as to - verify session liveness. Thus, we need a request/response mechanism for - consent freshness. ICE can be used for that mechanism because ICE - already requires ICE agents continue listening for ICE messages, as - described in section 10 of . - - -
- -
- There are two ways consent to send traffic is revoked: expiration -of consent and immediate revocation of consent, which are discussed in -the following sections. - -
- A WebRTC browser performs a combined consent freshness and session - liveness test using STUN request/response as described below: - - An endpoint MUST NOT send application data (e.g., RTP, RTCP, - SCTP, DTLS), over any transport protocol (e.g., UDP, TCP) on an - ICE-initiated connection unless the receiving endpoint consents - to receive the data. After a successful ICE connectivity check - on a particular transport address, subsequent consent MUST be - obtained following the procedure described in this document. The - consent expires after a fixed amount of time. During ICE restart - consent checks MUST continue to be sent on previously validated - pair, and MUST be responded to on the previously validated pair, - until ICE restart completes. - - Note: Although TCP has its own consent - mechanism (TCP acknowledgements), consent is necessary over a - TCP connection because it could be translated to a UDP - connection (e.g., ). - - Explicit consent to send is obtained by sending an ICE - binding request to the remote peer's Transport Address and - receiving a matching, authenticated, non-error ICE binding - response from the remote peer's Transport Address. These ICE - binding requests and responses are authenticated using the same - short-term credentials as the initial ICE - exchange. Implementations MUST cease sending data if their - consent expires. To prevent expiry of consent, a STUN binding - request MUST be sent every N milliseconds, where N is chosen randomly - with each consent check in the interval [.8N, 1.2N] (to prevent - network synchronization), where N SHOULD be 5000. Using - the value 5000 milliseconds and that 20% randomization range, N - would be a value between 4000 and 6000. These STUN binding - requests for consent are not re-transmitted. Each STUN binding - request for consent re-calculates a new random value N and a - new cryptographically-random STUN - transaction ID. - - - The initial Consent to send traffic is obtained by ICE. Consent - expires after 30 seconds. That is, if a valid STUN - binding response corresponding to one of the STUN requests sent - in the last 30 seconds has not been received from the remote peer's Transport Address, the endpoint MUST cease transmission on that 5-tuple. - - - To meet the security needs of consent, an untrusted -application (e.g., JavaScript) MUST NOT be able to obtain or control -the STUN transaction ID, because that enables spoofing STUN responses, -falsifying consent. - -While TCP affords some protection from off-path attackers -(, ), -there is still a risk an attacker could cause a TCP sender to send -packets forever by spoofing ACKs. To prevent such an attack, consent -checks MUST be performed over all WebRTC-initiated transport -connections, including TCP. In this way, an off-path attacker -spoofing TCP segments can not cause a TCP sender to send packets -longer than the consent timer (30 seconds). - - - -An endpoint that is not sending any application traffic does not -need to obtain consent which can slightly conserve its resources. -However, the endpoint needs to ensure its NAT or firewall mappings -persist which can be done using keepalive or other techniques -(see Section 10 of and -see ). If the endpoint wants to send -application traffic, it needs to first obtain consent if its consent -has expired. - - -
-
-The previous section explained how consent expires due to a -timeout. In some cases it is useful to signal a connection is -terminated, rather than relying on a timeout. This is done by -immediately revoking consent. - - Consent for sending traffic on the media or data channel is - immediately revoked by receipt of an authenticated message - that closes the connection (e.g., a TLS fatal alert) or - receipt of a valid and authenticated STUN response with error - code Forbidden (403). Those consent revocation messages can - be lost on the network, so an implementation wanting to - immediately revoke consent needs to remember those credentials - until consent expiry (30 seconds). - - Receipt of an unauthenticated message that closes a - connection (e.g., TCP FIN) does not indicate revocation of - consent. Thus, an endpoint receiving an unauthenticated - end-of-session message SHOULD continue sending media (over - connectionless transport) or attempt to re-establish the - connection (over connection-oriented transport) until consent - expires or it receives an authenticated message revoking - consent. - -Note that an authenticated SRTCP BYE does not terminate - consent; it only indicates the associated SRTP source - has quit. -
- -
- - - -
- A connection is considered "live" if packets are received from a - remote endpoint within an application-dependent period. An application - can request a notification when there are no packets received for a - certain period (configurable). - - Similarly, if packets haven't been received within a certain period, - an application can request a consent check (heartbeat) be generated. - These two time intervals might be controlled by the same configuration - item. - - Sending consent checks (heartbeats) at a high rate could allow a - malicious application to generate congestion, so applications MUST NOT - be able to send heartbeats at an average rate of more than 1 per second. -
- -
- It is RECOMMENDED that STUN consent checks use the same Diffserv - Codepoint markings as the ICE connectivity checks described in section - 7.1.2.4 of for a given 5-tuple. - - Note: It is possible that different Diffserv Codepoints are used by - different media over the same transport address . Such a case is outside the - scope of this document. -
- -
- For the consent freshness and liveness test the W3C specification - should provide APIs as described below: - Ability for the browser to notify the JavaScript that consent freshness - has failed for a 5-tuple and the browser has stopped transmitting on that - 5-tuple. - - Ability for the JavaScript to start and stop liveness test and - set the liveness test interval. - - Ability for the browser to notify the JavaScript that a liveness - test has failed for a media stream. - -
- -
- This document describes a security mechanism. - - The security considerations discussed in should also be taken into account. - - SRTP is encrypted and authenticated with symmetric keys; that is, - both sender and receiver know the keys. With two party sessions, receipt - of an authenticated packet from the single remote party is a strong - assurance the packet came from that party. However, when a session - involves more than two parties, all of whom know each others keys, any - of those parties could have sent (or spoofed) the packet. Such shared - key distributions are possible with some MIKEY modes, Security - Descriptions, and EKT. Thus, in such shared - keying distributions, receipt of an authenticated SRTP packet is not - sufficient to verify consent. -
- -
- This document does not require any action from IANA. -
- -
- Thanks to Eric Rescorla, Harald Alvestrand, Bernard Aboba, - Magnus Westerland, Cullen Jennings, Christer Holmberg, Simon - Perreault, Paul Kyzivat, Emil Ivov, and Jonathan Lennox for - their valuable inputs and comments. -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-07.xml b/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-07.xml deleted file mode 100644 index 9256ead..0000000 --- a/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-07.xml +++ /dev/null @@ -1,492 +0,0 @@ - - - - - - - - - - - - - - - - - STUN Usage for Consent - Freshness - - - Ericsson -
- - Ferns Icon - Doddanekundi, Mahadevapura - Bangalore - Karnataka - 560037 - India - - muthu.arul@gmail.com -
- - - - Cisco Systems - -
- - 821 Alder Drive - - Milpitas - - California - - 95035 - - USA - - - dwing@cisco.com -
- - - - Cisco Systems - -
- - Cessna Business Park - - Sarjapur-Marathahalli Outer Ring Road - - Bangalore - - Karnataka - - 560103 - - India - - - rmohanr@cisco.com -
- - - - Cisco Systems - -
- - Cessna Business Park, Varthur Hobli - - Sarjapur Marathalli Outer Ring Road - - Bangalore - - Karnataka - - 560103 - - India - - - tireddy@cisco.com -
- - - - Mozilla - -
- - Suite 300 - - 650 Castro Street - - Mountain View - - California - - 94041 - - US - - - martin.thomson@gmail.com -
- - - - - RAI - - RTCWEB - - - To prevent sending excessive traffic to an endpoint, periodic consent - needs to be obtained from that remote endpoint. - - This document describes a consent mechanism using a new -Session Traversal Utilities for NAT (STUN) usage. This same mechanism -can also determine connection loss ("liveness") with a remote -peer. - - - - -
- To prevent attacks on peers, RTP endpoints have to ensure the - remote peer wants to receive traffic. This is performed both - when the session is first established to the remote peer using - Interactive Connectivity Establishment ICE connectivity - checks, and periodically for the duration of the session using - the procedures defined in this document. - - When a session is first established, ICE implementations - obtain initial consent by performing STUN connectivity checks as - part of ICE. That initial consent is not described further in - this document and it is assumed that ICE is being used for that - initial consent. - - Related to consent is loss of connectivity ("liveness"). Many - applications want notification of connection loss to take appropriate - actions (e.g., alert the user, try switching to a different - interface). - - This document describes a new STUN usage with exchange of request and - response messages to verify the remote peer's consent to receive traffic, - and the absence of which for a period of time indicates a loss of liveness. - -When a (full) ICE implementation interworks with an ICE-lite - implementation the ICE-lite implementation will not generate - consent checks, but will just just respond to consent checks it - receives. - -
- -
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in . - - - It is the mechanism of obtaining - permission to send traffic to a certain transport address. - This is the initial consent to send traffic, which is - obtained by ICE or a TCP handshake. - - Permission to continue sending - traffic to a certain transport address. This is performed by the - procedure described in this document. - - Detecting loss of connectivity to a - certain transport address. This is performed by the procedure - described in this document. - - The remote peer's IP address and - (UDP or TCP) port number. - - -
- -
- Although ICE requires periodic keepalive traffic to keep NAT - bindings alive (Section 10 - of , ), - those keepalives are sent as STUN Indications which are - send-and-forget, and do not evoke a response. A response is - necessary both for consent to continue sending traffic, as well - as to verify session liveness. Thus, we need a request/response - mechanism for consent freshness. ICE can be used for that - mechanism because ICE implementations are already required to - continue listening for ICE messages, as described in section 10 - of . - - -
- -
- There are two ways consent to send traffic is revoked: expiration -of consent and immediate revocation of consent, which are discussed in -the following sections. - -
- A WebRTC - implementation, which implements ICE, MUST perform a - combined consent freshness and session liveness test using STUN - request/response as described below: - - An endpoint MUST NOT send application data (e.g., RTP, RTCP, - SCTP, DTLS), over any transport protocol (e.g., UDP, TCP) on an - ICE-initiated connection unless the receiving endpoint consents - to receive the data. After a successful ICE connectivity check - on a particular transport address, subsequent consent MUST be - obtained following the procedure described in this document. The - consent expires after a fixed amount of time. During ICE restart - consent checks MUST continue to be sent on previously validated - pair, and MUST be responded to on the previously validated pair, - until ICE restart completes. - - Note: Although TCP has its own consent - mechanism (TCP acknowledgements), consent is necessary over a - TCP connection because it could be translated to a UDP - connection (e.g., ). - - Explicit consent to send is obtained by sending an ICE - binding request to the remote peer's Transport Address and - receiving a matching, authenticated, non-error ICE binding - response from the remote peer's Transport Address. These ICE - binding requests and responses are authenticated using the same - short-term credentials as the initial ICE - exchange. Implementations MUST cease sending data if their - consent expires. To prevent expiry of consent, a STUN binding - request MUST be sent every N milliseconds, where N is chosen randomly - with each consent check in the interval [.8N, 1.2N] (to prevent - network synchronization), where N SHOULD be 5000. Using - the value 5000 milliseconds and that 20% randomization range, N - would be a value between 4000 and 6000. These STUN binding - requests for consent are not re-transmitted. Each STUN binding - request for consent re-calculates a new random value N and a - new cryptographically-random STUN - transaction ID. - - - The initial Consent to send traffic is obtained by ICE. Consent - expires after 30 seconds. That is, if a valid STUN - binding response corresponding to one of the STUN requests sent - in the last 30 seconds has not been received from the remote peer's Transport Address, the endpoint MUST cease transmission on that 5-tuple. - - - To meet the security needs of consent, an untrusted -application (e.g., JavaScript) MUST NOT be able to obtain or control -the STUN transaction ID, because that enables spoofing STUN responses, -falsifying consent. - -While TCP affords some protection from off-path attackers -(, ), -there is still a risk an attacker could cause a TCP sender to send -packets forever by spoofing ACKs. To prevent such an attack, consent -checks MUST be performed over all transport connections, including -TCP. In this way, an off-path attacker spoofing TCP segments can not -cause a TCP sender to send packets longer than the consent timer (30 -seconds). - - - -An endpoint that is not sending any application traffic does not -need to obtain consent which can slightly conserve its resources. -However, the endpoint needs to ensure its NAT or firewall mappings -persist which can be done using keepalive or other techniques -(see Section 10 of and -see ). If the endpoint wants to send -application traffic, it needs to first obtain consent if its consent -has expired. - - -
-
-The previous section explained how consent expires due to a -timeout. In some cases it is useful to signal a connection is -terminated, rather than relying on a timeout. This is done by -immediately revoking consent. - - Consent for sending traffic on the media or data channel is - immediately revoked by receipt of an authenticated message - that closes the connection (e.g., a TLS fatal alert) or - receipt of a valid and authenticated STUN response with error - code Forbidden (403). Those consent revocation messages can - be lost on the network, so an implementation wanting to - immediately revoke consent needs to remember those credentials - until consent expiry (30 seconds). - - Receipt of an unauthenticated message that closes a - connection (e.g., TCP FIN) does not indicate revocation of - consent. Thus, an endpoint receiving an unauthenticated - end-of-session message SHOULD continue sending media (over - connectionless transport) or attempt to re-establish the - connection (over connection-oriented transport) until consent - expires or it receives an authenticated message revoking - consent. - -Note that an authenticated SRTCP BYE does not terminate - consent; it only indicates the associated SRTP source - has quit. -
- -
- - - -
- A connection is considered "live" if packets are received from a - remote endpoint within an application-dependent period. An application - can request a notification when there are no packets received for a - certain period (configurable). - - Similarly, if packets haven't been received within a certain period, - an application can request a consent check (heartbeat) be generated. - These two time intervals might be controlled by the same configuration - item. - - Sending consent checks (heartbeats) at a high rate could allow a - malicious application to generate congestion, so applications MUST NOT - be able to send heartbeats at an average rate of more than 1 per second. -
- -
- It is RECOMMENDED that STUN consent checks use the same Diffserv - Codepoint markings as the ICE connectivity checks described in section - 7.1.2.4 of for a given 5-tuple. - - Note: It is possible that different Diffserv Codepoints are used by - different media over the same transport address . Such a case is outside the - scope of this document. -
- -
- For the consent freshness and liveness test the W3C specification - should provide APIs as described below: - Ability for the browser to notify the JavaScript that consent freshness - has failed for a 5-tuple and the browser has stopped transmitting on that - 5-tuple. - - Ability for the JavaScript to start and stop liveness test and - set the liveness test interval. - - Ability for the browser to notify the JavaScript that a liveness - test has failed for a media stream. - -
- -
- This document describes a security mechanism. - - The security considerations discussed in should also be taken into account. - - SRTP is encrypted and authenticated with symmetric keys; that is, - both sender and receiver know the keys. With two party sessions, receipt - of an authenticated packet from the single remote party is a strong - assurance the packet came from that party. However, when a session - involves more than two parties, all of whom know each others keys, any - of those parties could have sent (or spoofed) the packet. Such shared - key distributions are possible with some MIKEY modes, Security - Descriptions, and EKT. Thus, in such shared - keying distributions, receipt of an authenticated SRTP packet is not - sufficient to verify consent. -
- -
- This document does not require any action from IANA. -
- -
- Thanks to Eric Rescorla, Harald Alvestrand, Bernard Aboba, - Magnus Westerland, Cullen Jennings, Christer Holmberg, Simon - Perreault, Paul Kyzivat, Emil Ivov, and Jonathan Lennox for - their valuable inputs and comments. -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-08.xml b/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-08.xml deleted file mode 100644 index 2eef123..0000000 --- a/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-08.xml +++ /dev/null @@ -1,408 +0,0 @@ - - - - - - - - - - - - - - - - -STUN Usage for Consent -Freshness - -Ericsson -
- -Ferns Icon -Doddanekundi, Mahadevapura -Bangalore -Karnataka -560037 -India - -muthu.arul@gmail.com -
- - -Cisco Systems -
- -821 Alder Drive -Milpitas -California -95035 -USA - -dwing@cisco.com -
- - -Cisco Systems -
- -Cessna Business Park -Sarjapur-Marathahalli Outer Ring Road -Bangalore -Karnataka -560103 -India - -rmohanr@cisco.com -
- - -Cisco Systems -
- -Cessna Business Park, Varthur Hobli -Sarjapur Marathalli Outer Ring Road -Bangalore -Karnataka -560103 -India - -tireddy@cisco.com -
- - -Mozilla -
- -Suite 300 -650 Castro Street -Mountain View -California -94041 -US - -martin.thomson@gmail.com -
- - -RAI -RTCWEB - -To prevent sending excessive traffic to an endpoint, periodic consent -needs to be obtained from that remote endpoint. -This document describes a consent mechanism using a new -Session Traversal Utilities for NAT (STUN) usage. This same mechanism -can also determine connection loss ("liveness") with a remote -peer. - - - -
-To prevent attacks on peers, RTP endpoints have to ensure the -remote peer wants to receive traffic. This is performed both -when the session is first established to the remote peer using -Interactive Connectivity Establishment ICE connectivity -checks, and periodically for the duration of the session using -the procedures defined in this document. -When a session is first established, ICE implementations -obtain initial consent by performing STUN connectivity checks as -part of ICE. That initial consent is not described further in -this document and it is assumed that ICE is being used for that -initial consent. -Related to consent is loss of connectivity ("liveness"). Many -applications want notification of connection loss to take appropriate -actions (e.g., alert the user, try switching to a different -interface). -This document describes a new STUN usage with exchange of request and -response messages to verify the remote peer's consent to receive traffic, -and the absence of which for a period of time indicates a loss of liveness. -When a (full) ICE implementation interworks with an ICE-lite -implementation the ICE-lite implementation will not generate consent -checks, but will just respond to consent checks it receives. ICE-lite -implementation do not require any changes to respond to consent -checks. This is acceptable because ICE-Lite implementations are expected to -only use RTP and expected to -implement . -
-
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", -"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this -document are to be interpreted as described in . - -It is the mechanism of obtaining -permission to send traffic to a certain transport address. -This is the initial consent to send traffic, which is -obtained by ICE or a TCP handshake. -Permission to continue sending -traffic to a certain transport address. This is performed by the -procedure described in this document. -Detecting loss of connectivity to a -certain transport address. This is performed by the procedure -described in this document. -The remote peer's IP address and -(UDP or TCP) port number. - -
-
-Although ICE requires periodic keepalive traffic to keep NAT -bindings alive (Section 10 -of , ), -those keepalives are sent as STUN Indications which are -send-and-forget, and do not evoke a response. A response is -necessary both for consent to continue sending traffic, as well -as to verify session liveness. Thus, we need a request/response -mechanism for consent freshness. ICE can be used for that -mechanism because ICE implementations are already required to -continue listening for ICE messages, as described in section 10 -of . -
-
-There are two ways consent to send traffic is revoked: expiration -of consent and immediate revocation of consent, which are discussed in -the following sections. -
-A WebRTC -implementation, which implements full ICE, MUST perform a -combined consent freshness and session liveness test using STUN -request/response as described below: -An endpoint MUST NOT send application data (e.g., RTP, RTCP, -SCTP, DTLS), over any transport protocol (e.g., UDP, TCP) on an -ICE-initiated connection unless the receiving endpoint consents -to receive the data. After a successful ICE connectivity check -on a particular transport address, subsequent consent MUST be -obtained following the procedure described in this document. The -consent expires after a fixed amount of time. During ICE restart -consent checks MUST continue to be sent on previously validated -pair, and MUST be responded to on the previously validated pair, -until ICE restart completes. -Note: Although TCP has its own consent -mechanism (TCP acknowledgements), consent is necessary over a -TCP connection because it could be translated to a UDP -connection (e.g., ). -Explicit consent to send is obtained by sending an ICE binding -request to the remote peer's Transport Address and receiving a -matching, authenticated, non-error ICE binding response from the -remote peer's Transport Address. These ICE binding requests and -responses are authenticated using the same short-term credentials as -the initial ICE exchange. Implementations MUST cease sending data if -their consent expires. To prevent expiry of consent, a STUN binding -request MUST be sent every N milliseconds, where N is chosen randomly -with each consent check in the interval [.8N, 1.2N] (to prevent -network synchronization), where N SHOULD be 5000. Using the value 5000 -milliseconds and that 20% randomization range, N would be a value -between 4000 and 6000. Each STUN binding request for consent -re-calculates a new random value N and a -new cryptographically-random STUN -transaction ID. Each STUN binding requests for consent is transmitted -once, which means if it goes over an unreliable transport (including -over a TURN server, even if the local communication is TCP) the -request or its corresponding response might be lost. Hence, the -sender cannot assume that it will receive a response for each consent -request, and a response might be for a previous request (rather than -for the most recently sent request). Consent expiration causes -immediate termination of all outstanding STUN consent transactions. -Each STUN consent transaction is -maintained until one of the following criteria is fulfilled: -An authenticated STUN response associated with the transaction is received; or -An authenticated STUN response associated to a newer transaction is received. - - - -The initial Consent to send traffic is obtained by ICE. Consent -expires after 30 seconds. That is, if a valid STUN binding response -corresponding to one of the previous STUN requests (not necessarily -the most recently sent request) sent in the last 30 seconds has not -been received from the remote peer's Transport Address, the endpoint -MUST cease transmission on that 5-tuple. If a response is received -that is more than 30 seconds older than its request, that response -is ignored. - - - -To meet the security needs of consent, an untrusted -application (e.g., JavaScript) MUST NOT be able to obtain or control -the STUN transaction ID, because that enables spoofing STUN responses, -falsifying consent. -While TCP affords some protection from off-path attackers -(, ), -there is still a risk an attacker could cause a TCP sender to send -packets forever by spoofing ACKs. To prevent such an attack, consent -checks MUST be performed over all transport connections, including -TCP. In this way, an off-path attacker spoofing TCP segments can not -cause a TCP sender to send packets longer than the consent timer (30 -seconds). -An endpoint that is not sending any application traffic does not -need to obtain consent which can slightly conserve its resources. -However, the endpoint needs to ensure its NAT or firewall mappings -persist which can be done using keepalive or other techniques -(see Section 10 of and -see ). If the endpoint wants to send -application traffic, it needs to first obtain consent if its consent -has expired. -
-
-The previous section explained how consent expires due to a -timeout. In some cases it is useful to signal a connection is -terminated, rather than relying on a timeout. This is done by -immediately revoking consent. -Consent for sending traffic on the media or data channel is -immediately revoked by receipt of an authenticated message -that closes the connection (e.g., a TLS fatal alert) or -receipt of a valid and authenticated STUN response with error -code Forbidden (403). Those consent revocation messages can -be lost on the network, so an implementation wanting to -immediately revoke consent needs to remember those credentials -until consent expiry (30 seconds). -Receipt of an unauthenticated message that closes a -connection (e.g., TCP FIN) does not indicate revocation of -consent. Thus, an endpoint receiving an unauthenticated -end-of-session message SHOULD continue sending media (over -connectionless transport) or attempt to re-establish the -connection (over connection-oriented transport) until consent -expires or it receives an authenticated message revoking -consent. -Note that an authenticated SRTCP BYE does not terminate -consent; it only indicates the associated SRTP source -has quit. -
-
- -
-A connection is considered "live" if packets are received from a -remote endpoint within an application-dependent period. An application -can request a notification when there are no packets received for a -certain period (configurable). -Similarly, if packets haven't been received within a certain period, -an application can request a consent check (heartbeat) be generated. -These two time intervals might be controlled by the same configuration -item. -Sending consent checks (heartbeats) at a high rate could allow a -malicious application to generate congestion, so applications MUST NOT -be able to send heartbeats at an average rate of more than 1 per second. -
-
-It is RECOMMENDED that STUN consent checks use the same Diffserv -Codepoint markings as the ICE connectivity checks described in section -7.1.2.4 of for a given 5-tuple. -Note: It is possible that different Diffserv Codepoints are used by -different media over the same transport address . Such a case is outside the -scope of this document. -
-
-For the consent freshness and liveness test the W3C specification -should provide APIs as described below: -Ability for the browser to notify the JavaScript that consent freshness -has failed for a 5-tuple and the browser has stopped transmitting on that -5-tuple. -Ability for the JavaScript to start and stop liveness test and -set the liveness test interval. -Ability for the browser to notify the JavaScript that a liveness -test has failed for a media stream. - -
-
-This document describes a security mechanism. -The security considerations discussed in should also be taken into account. -SRTP is encrypted and authenticated with symmetric keys; that is, -both sender and receiver know the keys. With two party sessions, receipt -of an authenticated packet from the single remote party is a strong -assurance the packet came from that party. However, when a session -involves more than two parties, all of whom know each others keys, any -of those parties could have sent (or spoofed) the packet. Such shared -key distributions are possible with some MIKEY modes, Security -Descriptions, and EKT. Thus, in such shared -keying distributions, receipt of an authenticated SRTP packet is not -sufficient to verify consent. -
-
-This document does not require any action from IANA. -
-
-Thanks to Eric Rescorla, Harald Alvestrand, Bernard Aboba, -Magnus Westerland, Cullen Jennings, Christer Holmberg, Simon -Perreault, Paul Kyzivat, Emil Ivov, and Jonathan Lennox for -their valuable inputs and comments. -
- - - - - - - - - - - - - - - - - - - - - - - diff --git a/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-09.xml b/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-09.xml deleted file mode 100644 index e9fbe24..0000000 --- a/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-09.xml +++ /dev/null @@ -1,424 +0,0 @@ - - - - - - - - - - - - - - - - - STUN Usage for Consent - Freshness - - - Ericsson - -
- - Ferns Icon - - Doddanekundi, Mahadevapura - - Bangalore - - Karnataka - - 560037 - - India - - - muthu.arul@gmail.com -
- - - - Cisco Systems - -
- - 821 Alder Drive - - Milpitas - - California - - 95035 - - USA - - - dwing@cisco.com -
- - - - Cisco Systems - -
- - Cessna Business Park - - Sarjapur-Marathahalli Outer Ring Road - - Bangalore - - Karnataka - - 560103 - - India - - - rmohanr@cisco.com -
- - - - Cisco Systems - -
- - Cessna Business Park, Varthur Hobli - - Sarjapur Marathalli Outer Ring Road - - Bangalore - - Karnataka - - 560103 - - India - - - tireddy@cisco.com -
- - - - Mozilla - -
- - Suite 300 - - 650 Castro Street - - Mountain View - - California - - 94041 - - US - - - martin.thomson@gmail.com -
- - - - - RAI - - RTCWEB - - - To prevent sending excessive traffic to an endpoint, periodic consent - needs to be obtained from that remote endpoint. - - This document describes a consent mechanism using a new Session - Traversal Utilities for NAT (STUN) usage. This same mechanism can also - determine connection loss ("liveness") with a remote peer. - - - - -
- To prevent attacks on peers, RTP endpoints have to ensure the remote - peer is willing to receive traffic. This is performed both when the - session is first established to the remote peer using Interactive Connectivity Establishment ICE - connectivity checks, and periodically for the duration of the session - using the procedures defined in this document. - - When a session is first established, ICE implementations obtain an - initial consent to send by performing STUN connectivity checks. This - document describes a new STUN usage with exchange of request and - response messages that verifies the remote peer's ongoing consent to - receive traffic. This consent expires after a period of time and needs - to be continually renewed, which ensures that consent can be - terminated. - - This document defines what it takes to obtain, maintain, and lose - consent to send. Consent to send applies to a single 5-tuple. How - applications react to changes in consent is not described in this - document. - - This applies to full ICE implementations. An ICE-lite implementation - will not generate consent checks, but will just respond to consent - checks it receives. ICE-lite implementation do not require any changes - to respond to consent checks. -
- -
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in . - - - The mechanism of obtaining permission to send - to a remote transport address. Initial consent is obtained using ICE - or a TCP handshake. - - Maintaining and renewing consent - over time. - - Detecting loss of connectivity to a - certain transport address. - - The remote peer's IP address and - UDP or TCP port number. - -
- -
- Although ICE requires periodic keepalive traffic to keep NAT bindings - alive (Section 10 of , ), those keepalives are sent as STUN Indications - which are send-and-forget, and do not evoke a response. A response is - necessary both for consent to continue sending traffic, as well as to - verify session liveness. Thus, we need a request/response mechanism for - consent freshness. ICE can be used for that mechanism because ICE - implementations are already required to continue listening for ICE - messages, as described in section 10 of . -
- -
- There are two ways consent to send traffic is revoked: expiration of - consent and immediate revocation of consent, which are discussed in the - following sections. - -
- A WebRTC - implementation, which implements full ICE, MUST perform a - combined consent freshness and session liveness test using STUN - request/response as described below: - - An endpoint MUST NOT send data other than paced STUN connectivity - checks or responses toward any transport address unless the receiving - endpoint consents to receive data. That is, no application data (e.g., - RTP or DTLS) can be sent until consent is obtained. After a successful - ICE connectivity check on a particular transport address, consent MUST - be maintained following the procedure described in this document. - - Explicit consent to send is obtained and maintained by sending an - ICE binding request to the remote peer's transport address and - receiving a matching, authenticated, non-error ICE binding response - from the remote peer's transport address. These ICE binding requests - and responses are authenticated using the same short-term credentials - as the initial ICE exchange. - Although TCP has its own consent mechanism - (TCP acknowledgements), consent is necessary over a TCP connection - because it could be translated to a UDP connection (e.g., ). - - - Initial consent to send traffic is obtained using ICE. Consent - expires after 30 seconds. That is, if a valid STUN binding response - corresponding to any STUN request sent in the last 30 seconds has not - been received from the remote peer's transport address, the endpoint - MUST cease transmission on that 5-tuple. STUN consent responses - received after consent expiry do not re-establish consent, and may be - discarded or cause an ICMP error. - - To prevent expiry of consent, a STUN binding request can be sent - periodically. To prevent synchronization of consent checks, each - interval MUST be randomized from between 0.8 and 1.2 times the basic - period. Implementations SHOULD set a default interval of 5 seconds, - resulting in a period between checks of 4 to 6 seconds. - - Each STUN binding request for consent MUST use a new and cryptographically strong STUN transaction ID. - Each STUN binding requests for consent is transmitted once only. - Hence, the sender cannot assume that it will receive a response for - each consent request, or that responses will be ordered, since there - could be unreliable or unordered transports on the path. Each STUN - transaction ID is maintained until consent expires or a response is - received for either this transaction or a more recent transaction. - - To meet the security needs of consent, an untrusted application - (e.g., JavaScript or signaling servers) MUST NOT be able to obtain or - control the STUN transaction ID, because that enables spoofing of STUN - responses, falsifying consent. - - During ICE restart consent checks MUST continue to be sent on - previously validated pair, and MUST be responded to on the previously - validated pair, until ICE restart completes. - - While TCP affords some protection from off-path attackers (, ), there is - still a risk an attacker could cause a TCP sender to send forever by - spoofing ACKs. To prevent such an attack, consent checks MUST be - performed over all transport connections, including TCP. In this way, - an off-path attacker spoofing TCP segments can not cause a TCP sender - to send once the consent timer expires (30 seconds). - - An endpoint that is not sending any application data does not need - to maintain consent. However, failure to send could cause any NAT or - firewall mappings for the flow to expire. Furthermore, having one peer - unable to send is detrimental to many protocols. - - After consent is lost for any reason, the same ICE credentials MUST - NOT be used on the affected 5-tuple again. That means that a new - session, or an ICE restart, is needed to obtain consent to send. -
- -
- In some cases it is useful to signal that consent is terminated - rather than relying on a timeout. - - Consent for sending application data is immediately revoked by - receipt of an authenticated message that closes the connection (e.g., - a TLS fatal alert) or receipt of a valid and authenticated STUN - response with error code Forbidden (403). Note however that consent - revocation messages can be lost on the network, so an endpoint could - resend these messages, or wait for consent to expire. - - Receipt of an unauthenticated message that closes a connection - (e.g., TCP FIN) does not indicate revocation of consent. Thus, an - endpoint receiving an unauthenticated end-of-session message SHOULD - continue sending media (over connectionless transport) or attempt to - re-establish the connection (over connection-oriented transport) until - consent expires or it receives an authenticated message revoking - consent. - - Note that an authenticated SRTCP BYE does not terminate consent; it - only indicates the associated SRTP source has quit. -
-
- -
- Regular consent checks have the side effect of indicating liveness - for the selected 5-tuple. This allows for the timely detection of - network faults. A connection is considered "live" if authenticated - messages are received from a remote endpoint within a given period. - - To support this use case, an application MAY be provided a means to - request a notification when there are no authenticated messages received - for a certain period. - - An application MAY also be provided a means to alter the basic - consent check period from the default value (the suggested value being - 5s) to any value up to 24 seconds. This ensures that connectivity checks - are not generated at an excessive rate and that at least one consent - check is sent every 30 seconds, allowing for the maximal 1.2 times - variation. Note that increasing the consent check period increases the - risk of packet loss causing consent expiration. - - Sending consent checks (heartbeats) at a high rate could allow a - malicious application to generate congestion, so applications MUST NOT - send consent checks at an average rate of more than 1 per second. -
- -
- It is RECOMMENDED that STUN consent checks use the same Diffserv - Codepoint markings as the ICE connectivity checks described in Section - 7.1.2.4 of for a given 5-tuple. - It is possible that different Diffserv - Codepoints are used by different media over the same transport - address . Such a - case is outside the scope of this document. - -
- -
- The W3C specification MAY provide the following API points to provide - feedback and control over consent: - Generate an event when consent has expired for a given 5-tuple, - meaning that transmission of data has ceased. This could indicate - what application data is affected, such as media or data - channels. - - Ability to set the consent check interval from its default - (recommended: 5 seconds) to any value between 1 second and 24 - seconds. - -
- -
- This document describes a security mechanism. - - The security considerations discussed in should also be taken into account. - - SRTP is encrypted and authenticated with symmetric keys; that is, - both sender and receiver know the keys. With two party sessions, receipt - of an authenticated packet from the single remote party is a strong - assurance the packet came from that party. However, when a session - involves more than two parties, all of whom know each others keys, any - of those parties could have sent (or spoofed) the packet. Such shared - key distributions are possible with some MIKEY modes, Security - Descriptions, and EKT. Thus, in such shared - keying distributions, receipt of an authenticated SRTP packet is not - sufficient to verify consent. -
- -
- This document does not require any action from IANA. -
- -
- Thanks to Eric Rescorla, Harald Alvestrand, Bernard Aboba, Magnus - Westerland, Cullen Jennings, Christer Holmberg, Simon Perreault, Paul - Kyzivat, Emil Ivov, and Jonathan Lennox for their valuable inputs and - comments. -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-10.xml b/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-10.xml deleted file mode 100644 index ae63aa2..0000000 --- a/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-10.xml +++ /dev/null @@ -1,392 +0,0 @@ - - - - - - - - - - - - - - - - -STUN Usage for Consent -Freshness - -Ericsson -
- -Ferns Icon -Doddanekundi, Mahadevapura -Bangalore -Karnataka -560037 -India - -muthu.arul@gmail.com -
- - -Cisco Systems -
- -821 Alder Drive -Milpitas -California -95035 -USA - -dwing@cisco.com -
- - -Cisco Systems -
- -Cessna Business Park -Sarjapur-Marathahalli Outer Ring Road -Bangalore -Karnataka -560103 -India - -rmohanr@cisco.com -
- - -Cisco Systems -
- -Cessna Business Park, Varthur Hobli -Sarjapur Marathalli Outer Ring Road -Bangalore -Karnataka -560103 -India - -tireddy@cisco.com -
- - -Mozilla -
- -Suite 300 -650 Castro Street -Mountain View -California -94041 -US - -martin.thomson@gmail.com -
- - -RAI -RTCWEB - - -To prevent sending excessive traffic to an endpoint, periodic consent -needs to be obtained from that remote endpoint. - - -This document describes a consent mechanism using a new Session -Traversal Utilities for NAT (STUN) usage. - - - - -
- -To prevent attacks on peers, endpoints have to ensure the remote -peer is willing to receive traffic. This is performed both when the -session is first established to the remote peer using Interactive Connectivity Establishment ICE -connectivity checks, and periodically for the duration of the session -using the procedures defined in this document. - - -When a session is first established, ICE implementations obtain an -initial consent to send by performing STUN connectivity checks. This -document describes a new STUN usage with exchange of request and -response messages that verifies the remote peer's ongoing consent to -receive traffic. This consent expires after a period of time and needs -to be continually renewed, which ensures that consent can be terminated. - - -This document defines what it takes to obtain, maintain, and lose -consent to send. Consent to send applies to a single 5-tuple. How -applications react to changes in consent is not described in this -document. - - -Consent is obtained only by full ICE implementations. An ICE-lite implementation -will not generate consent checks, but will just respond to consent -checks it receives. No changes are required to ICE-lite implementations in order -to respond to consent checks, as they are processed as normal ICE connectivity checks.. - -
-
- -The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", -"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this -document are to be interpreted as described in . - - - - -The mechanism of obtaining permission to send to a remote transport -address. Initial consent is obtained using ICE. - - -Maintaining and renewing consent over time. - - -The remote peer's IP address and UDP or TCP port number. - - - -
-
- -Although ICE requires periodic keepalive traffic to keep NAT bindings -alive (Section 10 of , ), those keepalives are sent as STUN Indications -which are send-and-forget, and do not evoke a response. A response is -necessary for consent to continue sending traffic. Thus, we need a -request/response mechanism for consent freshness. ICE can be used for -that mechanism because ICE implementations are already required to continue - listening for ICE messages, as described in section 10 of - . If consent is performed then there is - no need to send keepalive messages. - -
-
- -There are two ways consent to send traffic is revoked: expiration of -consent and immediate revocation of consent, which are discussed in the -following sections. - -
- -A WebRTC -implementation, which implements full ICE, MUST perform consent freshness -test using STUN request/response as described below: - - -An endpoint MUST NOT send data other than paced STUN connectivity -checks or responses toward any transport address unless the receiving -endpoint consents to receive data. That is, no application data (e.g., RTP or DTLS) -can be sent until consent is obtained. After a successful ICE connectivity check -on a particular transport address, consent MUST be maintained following the -procedure described in this document. - - -Explicit consent to send is obtained and maintained by sending an STUN -binding request to the remote peer's transport address and receiving a -matching, authenticated, non-error STUN binding response from the -remote peer's transport address. These STUN binding requests and -responses are authenticated using the same short-term credentials as -the initial ICE exchange. - - -Although TCP has its own consent mechanism (TCP acknowledgements), -consent is necessary over a TCP connection because it could be -translated to a UDP connection (e.g., ). - - - - -Initial consent to send traffic is obtained using ICE. Consent expires -after 30 seconds. That is, if a valid STUN binding response corresponding -to any STUN request sent in the last 30 seconds has not been received from -the remote peer's transport address, the endpoint MUST cease transmission - on that 5-tuple. STUN consent responses received after consent expiry do not -re-establish consent, and may be discarded or cause an ICMP error. - - -To prevent expiry of consent, a STUN binding request can be sent -periodically. To prevent synchronization of consent checks, each -interval MUST be randomized from between 0.8 and 1.2 times the basic -period. Implementations SHOULD set a default interval of 5 seconds, -resulting in a period between checks of 4 to 6 seconds. - - -Each STUN binding request for consent MUST use a new cryptographically strong STUN transaction -ID. Each STUN binding requests for consent is transmitted once -only. Hence, the sender cannot assume that it will receive a response -for each consent request, and a response might be for a previous request -(rather than for the most recently sent request). Consent expiration causes -immediate termination of all outstanding STUN consent transactions. Each -STUN transaction is maintained until one of the following criteria is -fulfilled: -A STUN response associated with the transaction is received; or -A STUN response associated to a newer transaction is received. - - - -To meet the security needs of consent, an untrusted application (e.g., -JavaScript or signaling servers) MUST NOT be able to obtain or control -the STUN transaction ID, because that enables spoofing of STUN -responses, falsifying consent. - - -To prevent attacks on the peer during ICE restart, an endpoint that - continues to send traffic on the previously validated candidate pair - during ICE restart MUST continue to perform consent freshness on that - candidate pair as described earlier. - - -While TCP affords some protection from off-path attackers (, ), there is -still a risk an attacker could cause a TCP sender to send forever by -spoofing ACKs. To prevent such an attack, consent checks MUST be -performed over all transport connections, including TCP. In this way, -an off-path attacker spoofing TCP segments can not cause a TCP sender -to send once the consent timer expires (30 seconds). - - -An endpoint that is not sending any application data does not need to -maintain consent. However, failure to send could cause any NAT or -firewall mappings for the flow to expire. Furthermore, having one -peer unable to send is detrimental to many protocols. - - -After consent is lost for any reason, the same ICE credentials MUST -NOT be used on the affected 5-tuple again. That means that a new -session, or an ICE restart, is needed to obtain consent to send. - -
-
- -In some cases it is useful to signal that consent is terminated rather -than relying on a timeout. - - -Consent for sending application data is immediately revoked by receipt -of an authenticated message that closes the connection (e.g., a TLS -fatal alert) or receipt of a valid and authenticated STUN response -with error code Forbidden (403). Note however that consent revocation -messages can be lost on the network, so an endpoint could resend -these messages, or wait for consent to expire. - - -Receipt of an unauthenticated message that closes a connection (e.g., -TCP FIN) does not indicate revocation of consent. Thus, an endpoint -receiving an unauthenticated end-of-session message SHOULD continue -sending media (over connectionless transport) or attempt to -re-establish the connection (over connection-oriented transport) until -consent expires or it receives an authenticated message revoking -consent. - - -Note that an authenticated SRTCP BYE does not terminate consent; it -only indicates the associated SRTP source has quit. - -
-
- -
- -It is RECOMMENDED that STUN consent checks use the same Diffserv -Codepoint markings as the ICE connectivity checks described in Section -7.1.2.4 of for a given 5-tuple. - - -It is possible that different Diffserv Codepoints are used by -different media over the same transport address . Such a case is outside -the scope of this document. - - - -
- -
-The DTLS applicability is identical to what is described in Section 4.2 - of . -
- -
- -The W3C specification MAY provide the following API points to provide -feedback and control over consent: - - -Generate an event when consent has expired for a given 5-tuple, -meaning that transmission of data has ceased. This could indicate -what application data is affected, such as media or data channels. - - - -
- -
- -This document describes a security mechanism. - - -The security considerations discussed in -should also be taken into account. - - -SRTP is encrypted and authenticated with symmetric keys; that is, both -sender and receiver know the keys. With two party sessions, receipt of -an authenticated packet from the single remote party is a strong -assurance the packet came from that party. However, when a session -involves more than two parties, all of whom know each others keys, any -of those parties could have sent (or spoofed) the packet. Such shared -key distributions are possible with some MIKEY modes, Security -Descriptions, and EKT. Thus, in such shared -keying distributions, receipt of an authenticated SRTP packet is not -sufficient to verify consent. - -
-
- -This document does not require any action from IANA. - -
-
- -Thanks to Eric Rescorla, Harald Alvestrand, Bernard Aboba, Magnus -Westerland, Cullen Jennings, Christer Holmberg, Simon Perreault, Paul -Kyzivat, Emil Ivov, Jonathan Lennox, Inaki Baz Castillo, Rajmohan Banavi -and Christian Groves for their valuable inputs and comments. Thanks to -Christer Holmberg for doing a through review. - -
- - - - - - - - - - - - - - - - - - - - - - - diff --git a/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-13.xml b/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness.xml similarity index 100% rename from STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-13.xml rename to STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness.xml From f87b3ab6ab94693da763b7af90601d047007856a Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 22 May 2015 10:59:21 -0700 Subject: [PATCH 2/3] Removing junk --- ...-ietf-rtcweb-stun-consent-freshness-04.txt | 504 ------------------ 1 file changed, 504 deletions(-) delete mode 100644 STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-04.txt diff --git a/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-04.txt b/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-04.txt deleted file mode 100644 index 0775896..0000000 --- a/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-04.txt +++ /dev/null @@ -1,504 +0,0 @@ - - - - -RTCWEB M. Perumal -Internet-Draft D. Wing -Intended status: Standards Track R. Ravindranath -Expires: December 19, 2014 T. Reddy - Cisco Systems - M. Thomson - Mozilla - June 17, 2014 - - - STUN Usage for Consent Freshness - draft-ietf-rtcweb-stun-consent-freshness-04 - -Abstract - - To prevent sending excessive traffic to an endpoint, periodic consent - needs to be obtained from that remote endpoint. - - This document describes a consent mechanism using a new STUN usage. - This same mechanism can also determine connection loss ("liveness") - with a remote peer. - -Status of This Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on December 19, 2014. - -Copyright Notice - - Copyright (c) 2014 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - - - -Perumal, et al. Expires December 19, 2014 [Page 1] - -Internet-Draft STUN Usage for Consent Freshness June 2014 - - - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Design Considerations . . . . . . . . . . . . . . . . . . . . 3 - 4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 4.1. Expiration of Consent . . . . . . . . . . . . . . . . . . 3 - 4.2. Immediate Revocation of Consent . . . . . . . . . . . . . 5 - 5. Connection Liveness . . . . . . . . . . . . . . . . . . . . . 5 - 6. DiffServ Treatment for Consent packets . . . . . . . . . . . 5 - 7. W3C API Implications . . . . . . . . . . . . . . . . . . . . 6 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 - 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 6 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 - 11.2. Informative References . . . . . . . . . . . . . . . . . 7 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 - -1. Introduction - - To prevent attacks on peers, RTP endpoints have to ensure the remote - peer wants to receive traffic. This is performed both when the - session is first established to the remote peer using ICE - connectivity checks, and periodically for the duration of the session - using the procedures defined in this document. - - When a session is first established, WebRTC implementations are - required to perform STUN connectivity checks as part of ICE - [RFC5245]. That initial consent is not described further in this - document and it is assumed that ICE is being used for that initial - consent. - - Related to consent is loss of connectivity ("liveness"). Many - applications want notification of connection loss to take appropriate - actions (e.g., alert the user, try switching to a different - interface). - - This document describes a new STUN usage with exchange of request and - response messages to verify the remote peer's consent to receive - traffic, and the absence of which for a period of time indicates a - loss of liveness. - - - -Perumal, et al. Expires December 19, 2014 [Page 2] - -Internet-Draft STUN Usage for Consent Freshness June 2014 - - -2. Terminology - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - Consent: It is the mechanism of obtaining permission to send traffic - to a certain transport address. This is the initial consent to - send traffic, which is obtained by ICE or a TCP handshake. - - Consent Freshness: Permission to continue sending traffic to a - certain transport address. This is performed by the procedure - described in this document. - - Session Liveness: Detecting loss of connectivity to a certain - transport address. This is performed by the procedure described - in this document. - - Transport Address: The remote peer's IP address and (UDP or TCP) - port number. - -3. Design Considerations - - Although ICE requires periodic keepalive traffic to keep NAT bindings - alive (Section 10 of [RFC5245], [RFC6263]), those keepalives are sent - as STUN Indications which are send-and-forget, and do not evoke a - response. A response is necessary both for consent to continue - sending traffic, as well as to verify session liveness. Thus, we - need a request/response mechanism for consent freshness. ICE can be - used for that mechanism because ICE already requires ICE agents - continue listening for ICE messages, as described in section 10 of - [RFC5245]. - -4. Solution - - There are two ways consent to send traffic is revoked: expiration of - consent and immediate revocation of consent, which are discussed in - the following sections. - -4.1. Expiration of Consent - - A WebRTC browser performs a combined consent freshness and session - liveness test using STUN request/response as described below: - - An endpoint MUST NOT send application data (e.g., RTP, RTCP, SCTP, - DTLS) on an ICE-initiated connection unless the receiving endpoint - consents to receive the data. After a successful ICE connectivity - check on a particular transport address, subsequent consent MUST be - - - -Perumal, et al. Expires December 19, 2014 [Page 3] - -Internet-Draft STUN Usage for Consent Freshness June 2014 - - - obtained following the procedure described in this document. The - consent expires after a fixed amount of time. - - Explicit consent to send is obtained by sending an ICE binding - request to the remote peer's Transport Address and receiving a - matching, authenticated, non-error ICE binding response from the - inverted remote peer's Transport Address. These ICE binding requests - and responses are authenticated using the same short-term credentials - as the initial ICE exchange. Implementations MUST cease sending data - if their consent expires. To prevent expiry of consent, a STUN - binding request is sent every N milliseconds, where N SHOULD be 5000 - milliseconds and MUST be randomized at least 20% above and 20% below - that value (to prevent prevent network synchronization). Using the - value 5000 milliseconds and that 20% randomization range, N would be - a value between 4000 and 6000. These STUN binding requests for - consent are not re-transmitted. Each STUN binding request for - consent re-calculates a new random value N and a new - cryptographically-random [RFC4086] STUN transaction ID. - - The initial Consent to send traffic is obtained by ICE. Consent - expires after 30 seconds. That is, if a valid STUN binding response - corresponding to one of the STUN requests sent in the last 30 seconds - has not been received from the inverted 5-tuple, the endpoint MUST - cease transmission on that 5-tuple. - - To meet the security needs of consent, an untrusted application - (e.g., JavaScript) MUST NOT be able to obtain or control the STUN - transaction ID, because that enables spoofing STUN responses, - falsifying consent. - - While TCP affords some protection from off-path attackers ([RFC5961], - [RFC4953]), there is still a risk an attacker could cause a TCP - sender to send packets forever by spoofing ACKs. To prevent such an - attack, consent checks MUST be performed over all WebRTC-initiated - transport connections, including TCP. In this way, an off-path - attacker spoofing TCP segments can not cause a TCP sender to send - packets longer than the consent timer (30 seconds). - - An endpoint that is not sending any application traffic does not need - to obtain consent which can slightly conserve its resources. - However, the endpoint needs to ensure its NAT or firewall mappings - persist which can be done using keepalive or other techniques (see - Section 10 of [RFC5245] and see [RFC6263]). If the endpoint wants to - send application traffic, it needs to first obtain consent if its - consent has expired. - - - - - - -Perumal, et al. Expires December 19, 2014 [Page 4] - -Internet-Draft STUN Usage for Consent Freshness June 2014 - - -4.2. Immediate Revocation of Consent - - The previous section explained how consent expires due to a timeout. - In some cases it is useful to signal a connection is terminated, - rather than relying on a timeout. This is done by immediately - revoking consent. - - Consent for sending traffic on the media or data channel is - immediately revoked by receipt of a an authenticated message that - closes the connection (e.g., a TLS fatal alert) or receipt of a valid - and authenticated STUN response with error code Forbidden (403). - - Receipt of an unauthenticated message that closes a connection (e.g., - TCP FIN) does not indicate revocation of consent. Thus, an endpoint - receiving an unauthenticated end-of-session message SHOULD continue - sending media (over connectionless transport) or attempt to re- - establish the connection (over connection-oriented transport) until - consent expires or it receives an authenticated message revoking - consent. - - Note that an authenticated SRTCP BYE does not terminate consent; it - only indicates the associated SRTP source has quit. - -5. Connection Liveness - - A connection is considered "live" if packets are received from a - remote endpoint within an application-dependent period. An - application can request a notification when there are no packets - received for a certain period (configurable). - - Similarly, if packets haven't been received within a certain period, - an application can request a consent check (heartbeat) be generated. - These two time intervals might be controlled by the same - configuration item. - - Sending consent checks (heartbeats) at a high rate could allow a - malicious application to generate congestion, so applications MUST - NOT be able to send heartbeats at an average rate of more than 1 per - second. - -6. DiffServ Treatment for Consent packets - - It is RECOMMENDED that STUN consent checks use the same Diffserv - Codepoint markings as the ICE connectivity checks described in - section 7.1.2.4 of [RFC5245] for a given 5-tuple. - - Note: It is possible that different Diffserv Codepoints are used by - different media over the same transport address - - - -Perumal, et al. Expires December 19, 2014 [Page 5] - -Internet-Draft STUN Usage for Consent Freshness June 2014 - - - [I-D.ietf-tsvwg-rtcweb-qos]. Such a case is outside the scope of - this document. - -7. W3C API Implications - - For the consent freshness and liveness test the W3C specification - should provide APIs as described below: - - 1. Ability for the browser to notify the JavaScript that consent - freshness has failed for a 5-tuple and the browser has stopped - transmitting on that 5-tuple. - - 2. Ability for the JavaScript to start and stop liveness test and - set the liveness test interval. - - 3. Ability for the browser to notify the JavaScript that a liveness - test has failed for a media stream. - -8. Security Considerations - - This document describes a security mechanism. - - The security considerations discussed in [RFC5245] should also be - taken into account. - - SRTP is encrypted and authenticated with symmetric keys; that is, - both sender and receiver know the keys. With two party sessions, - receipt of an authenticated packet from the single remote party is a - strong assurance the packet came from that party. However, when a - session involves more than two parties, all of whom know each others - keys, any of those parties could have sent (or spoofed) the packet. - Such shared key distributions are possible with some MIKEY [RFC3830] - modes, Security Descriptions [RFC4568], and EKT - [I-D.ietf-avtcore-srtp-ekt]. Thus, in such shared keying - distributions, receipt of an authenticated SRTP packet is not - sufficient to verify consent. - -9. IANA Considerations - - This document does not require any action from IANA. - -10. Acknowledgement - - Thanks to Eric Rescorla, Harald Alvestrand, Bernard Aboba, Magnus - Westerland, Cullen Jennings, Christer Holmberg and Simon Perreault - for their valuable inputs and comments. - - - - - -Perumal, et al. Expires December 19, 2014 [Page 6] - -Internet-Draft STUN Usage for Consent Freshness June 2014 - - -11. References - -11.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness - Requirements for Security", BCP 106, RFC 4086, June 2005. - - [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment - (ICE): A Protocol for Network Address Translator (NAT) - Traversal for Offer/Answer Protocols", RFC 5245, April - 2010. - - [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for - Keeping Alive the NAT Mappings Associated with RTP / RTP - Control Protocol (RTCP) Flows", RFC 6263, June 2011. - -11.2. Informative References - - [I-D.ietf-avtcore-srtp-ekt] - McGrew, D. and D. Wing, "Encrypted Key Transport for - Secure RTP", draft-ietf-avtcore-srtp-ekt-02 (work in - progress), February 2014. - - [I-D.ietf-tsvwg-rtcweb-qos] - Dhesikan, S., Druta, D., Jones, P., and J. Polk, "DSCP and - other packet markings for RTCWeb QoS", draft-ietf-tsvwg- - rtcweb-qos-00 (work in progress), April 2014. - - [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. - Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, - August 2004. - - [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session - Description Protocol (SDP) Security Descriptions for Media - Streams", RFC 4568, July 2006. - - [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC - 4953, July 2007. - - [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's - Robustness to Blind In-Window Attacks", RFC 5961, August - 2010. - - - - - - -Perumal, et al. Expires December 19, 2014 [Page 7] - -Internet-Draft STUN Usage for Consent Freshness June 2014 - - -Authors' Addresses - - Muthu Arul Mozhi Perumal - Cisco Systems - Cessna Business Park - Sarjapur-Marathahalli Outer Ring Road - Bangalore, Karnataka 560103 - India - - Email: mperumal@cisco.com - - - Dan Wing - Cisco Systems - 821 Alder Drive - Milpitas, California 95035 - USA - - Email: dwing@cisco.com - - - Ram Mohan Ravindranath - Cisco Systems - Cessna Business Park - Sarjapur-Marathahalli Outer Ring Road - Bangalore, Karnataka 560103 - India - - Email: rmohanr@cisco.com - - - Tirumaleswar Reddy - Cisco Systems - Cessna Business Park, Varthur Hobli - Sarjapur Marathalli Outer Ring Road - Bangalore, Karnataka 560103 - India - - Email: tireddy@cisco.com - - - - - - - - - - - - -Perumal, et al. Expires December 19, 2014 [Page 8] - -Internet-Draft STUN Usage for Consent Freshness June 2014 - - - Martin Thomson - Mozilla - Suite 300 - 650 Castro Street - Mountain View, California 94041 - US - - Email: martin.thomson@gmail.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Perumal, et al. Expires December 19, 2014 [Page 9] From d97eef05b84d4f81774d326e60b97c2c8cc1cc04 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 22 May 2015 11:00:05 -0700 Subject: [PATCH 3/3] More messing around --- ...-ietf-rtcweb-stun-consent-freshness-14.xml | 435 ------------------ ...aft-ietf-rtcweb-stun-consent-freshness.xml | 132 ++++-- 2 files changed, 83 insertions(+), 484 deletions(-) delete mode 100644 STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-14.xml diff --git a/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-14.xml b/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-14.xml deleted file mode 100644 index 84722f4..0000000 --- a/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-14.xml +++ /dev/null @@ -1,435 +0,0 @@ - - - - - - - - - - - - - - - - -STUN Usage for Consent -Freshness - -Ericsson -
- -Ferns Icon -Doddanekundi, Mahadevapura -Bangalore -Karnataka -560037 -India - -muthu.arul@gmail.com -
- - -Cisco Systems -
- -821 Alder Drive -Milpitas -California -95035 -USA - -dwing@cisco.com -
- - -Cisco Systems -
- -Cessna Business Park -Sarjapur-Marathahalli Outer Ring Road -Bangalore -Karnataka -560103 -India - -rmohanr@cisco.com -
- - -Cisco Systems -
- -Cessna Business Park, Varthur Hobli -Sarjapur Marathalli Outer Ring Road -Bangalore -Karnataka -560103 -India - -tireddy@cisco.com -
- - -Mozilla -
- -Suite 300 -650 Castro Street -Mountain View -California -94041 -US - -martin.thomson@gmail.com -
- - -RAI -RTCWEB - - -To prevent sending excessive traffic to an endpoint, periodic consent -needs to be obtained from that remote endpoint. To prevent attacks on peers, endpoints -have to ensure the remote peer is willing to receive traffic. - - -This document describes a consent mechanism using a new Session -Traversal Utilities for NAT (STUN) usage. - - - - -
- -To prevent attacks on peers, endpoints have to ensure the remote -peer is willing to receive traffic. This is performed both when the -session is first established to the remote peer using Interactive Connectivity Establishment ICE -connectivity checks, and periodically for the duration of the session -using the procedures defined in this document. - - -When a session is first established, ICE implementations obtain an -initial consent to send by performing STUN connectivity checks. This -document describes a new STUN usage with exchange of request and -response messages that verifies the remote peer's ongoing consent to -receive traffic. This consent expires after a period of time and needs -to be continually renewed, which ensures that consent can be terminated. - - -This document defines what it takes to obtain, maintain, and lose consent -to send. Consent to send applies to a single 5-tuple. How applications react to changes -in consent is not described in this document. The consent mechanism does not update the -ICE procedures defined in . - - -Consent is obtained only by full ICE implementations. An ICE-lite implementation as defined -in section 2.7 of will not generate consent checks, but will just -respond to consent checks it receives. No changes are required to ICE-lite implementations - in order to respond to consent checks, as they are processed as normal ICE connectivity - checks. - -
- -
- -This document defines what it takes to obtain, maintain, and lose consent -to send using ICE. Verification of peer consent before sending traffic is -necessary in deployments like WebRTC to ensure that a malicious JavaScript cannot use -the browser as a platform for launching attacks.Section 4.4 and section 5.3 of - explains why webRTC application needs -consent. - -Other Applications that have similar security requirement where it is -required to verify peer's consent before sending non-ICE packets can use the consent -mechanism described in this draft. -
- -
- -The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", -"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this -document are to be interpreted as described in . - - - - -The mechanism of obtaining permission to send to a remote transport -address. Initial consent is obtained using ICE. - - -Maintaining and renewing consent over time. - - -The remote peer's IP address and UDP or TCP port number. - - - -
-
- -Although ICE requires periodic keepalive traffic to keep NAT bindings -alive (Section 10 of , ), those keepalives are sent as STUN Indications -which are send-and-forget, and do not evoke a response. A response is -necessary for consent to continue sending traffic. Thus, we need a -request/response mechanism for consent freshness. ICE can be used for -that mechanism because ICE implementations are already required to continue - listening for ICE messages, as described in section 10 of - . If consent is performed then there is - no need to send keepalive messages. - - - -When secure media (SRTP/SRTCP) is used the following considerations are applicable. -SRTP is encrypted and authenticated with symmetric keys; that is, both -sender and receiver know the keys. With two party sessions, receipt of -an authenticated packet from the single remote party is a strong -assurance the packet came from that party. However, when a session -involves more than two parties, all of whom know each other's keys, any -of those parties could have sent (or spoofed) the packet. Such shared -key distributions are possible with some MIKEY modes, Security -Descriptions, and EKT. Thus, in such shared -keying distributions, receipt of an authenticated SRTP packet is not -sufficient to verify consent. - -
-
- -There are two ways consent to send traffic is revoked: expiration of -consent and immediate revocation of consent, which are discussed in the -following sections. - -
- - A full ICE implementation performs consent freshness test using STUN - request/response as described below: - - -An endpoint MUST NOT send data other than paced STUN connectivity -checks or responses toward any transport address unless the receiving -endpoint consents to receive data. That is, no application data (e.g., RTP or DTLS) -can be sent until consent is obtained. After a successful ICE connectivity check -on a particular transport address, consent MUST be maintained following the -procedure described in this document. - - -Explicit consent to send is obtained and maintained by sending an STUN -binding request to the remote peer's transport address and receiving a -matching, authenticated, non-error STUN binding response from the -remote peer's transport address. These STUN binding requests and -responses are authenticated using the same short-term credentials as -the initial ICE exchange. - - -Although TCP has its own consent mechanism (TCP acknowledgements), -consent is necessary over a TCP connection because it could be -translated to a UDP connection (e.g., ). - - - - -Initial consent to send traffic is obtained using ICE. Consent expires -after 30 seconds. That is, if a valid STUN binding response corresponding -to any STUN request sent in the last 30 seconds has not been received from -the remote peer's transport address, the endpoint MUST cease transmission - on that 5-tuple. STUN consent responses received after consent expiry do not -re-establish consent, and may be discarded or cause an ICMP error. - - -To prevent expiry of consent, a STUN binding request can be sent -periodically. To prevent synchronization of consent checks, each -interval MUST be randomized from between 0.8 and 1.2 times the basic -period. Implementations SHOULD set a default interval of 5 seconds, -resulting in a period between checks of 4 to 6 seconds. - - -Each STUN binding request for consent MUST use a new cryptographically strong STUN transaction -ID. Each STUN binding requests for consent is transmitted once -only. Hence, the sender cannot assume that it will receive a response -for each consent request, and a response might be for a previous request -(rather than for the most recently sent request). Consent expiration causes -immediate termination of all outstanding STUN consent transactions. Each -STUN transaction is maintained until one of the following criteria is -fulfilled: -A STUN response associated with the transaction is received; or -A STUN response associated to a newer transaction is received. - - - -To meet the security needs of consent, an untrusted application (e.g., -JavaScript or signaling servers) MUST NOT be able to obtain or control -the STUN transaction ID, because that enables spoofing of STUN -responses, falsifying consent. - - -To prevent attacks on the peer during ICE restart, an endpoint that - continues to send traffic on the previously validated candidate pair - during ICE restart MUST continue to perform consent freshness on that - candidate pair as described earlier. - - -While TCP affords some protection from off-path attackers (, ), there is -still a risk an attacker could cause a TCP sender to send forever by -spoofing ACKs. To prevent such an attack, consent checks MUST be -performed over all transport connections, including TCP. In this way, -an off-path attacker spoofing TCP segments cannot cause a TCP sender -to send once the consent timer expires (30 seconds). - - -An endpoint that is not sending any application data does not need to -maintain consent. However, not sending any traffic could cause NAT or -firewall mappings to expire. Furthermore, having one peer unable to send - is detrimental to many protocols. Absent better information about the - network, if an endpoint needs to ensure its NAT or firewall mappings do - not expire, it can be done using keepalive or other techniques (see - Section 10 of and see ). - - - -After consent is lost for any reason, the same ICE credentials MUST -NOT be used on the affected 5-tuple again. That means that a new -session, or an ICE restart, is needed to obtain consent to send. - -
-
- -In some cases it is useful to signal that consent is terminated rather -than relying on a timeout. - - -Consent for sending application data is immediately revoked by receipt -of an authenticated message that closes the connection (e.g., a TLS -fatal alert) or receipt of a valid and authenticated STUN response -with error code Forbidden (403). Note however that consent revocation -messages can be lost on the network, so an endpoint could resend -these messages, or wait for consent to expire. - - -Receipt of an unauthenticated message that closes a connection (e.g., -TCP FIN) does not indicate revocation of consent. Thus, an endpoint -receiving an unauthenticated end-of-session message SHOULD continue -sending media (over connectionless transport) or attempt to -re-establish the connection (over connection-oriented transport) until -consent expires or it receives an authenticated message revoking -consent. - - -Note that an authenticated SRTCP BYE does not terminate consent; it -only indicates the associated SRTP source has quit. - -
-
- -
- -It is RECOMMENDED that STUN consent checks use the same Diffserv -Codepoint markings as the ICE connectivity checks described in Section -7.1.2.4 of for a given 5-tuple. - - -It is possible that different Diffserv Codepoints are used by -different media over the same transport address . Such a case is outside -the scope of this document. - - - -
- -
-The DTLS applicability is identical to what is described in Section 4.2 - of . -
- -
- -The W3C specification may provide an API hook that generates an event -when consent has expired for a given 5-tuple, meaning that transmission of data -has ceased. This could indicate what application data is affected, such as -media or data channels. - -
- -
- -This document describes a security mechanism details of which are mentioned in section 4.1 -and section 4.2. Consent requires 96 bits transaction ID to be uniformly and randomly -chosen from the interval 0 .. 2**96-1, and be cryptographically strong. -This is good enough security against an off-path attacker replaying old -STUN consent responses. - - -The security considerations discussed in -should also be taken into account. - -
-
- -This document does not require any action from IANA. - -
-
- -Thanks to Eric Rescorla, Harald Alvestrand, Bernard Aboba, Magnus -Westerland, Cullen Jennings, Christer Holmberg, Simon Perreault, Paul -Kyzivat, Emil Ivov, Jonathan Lennox, Inaki Baz Castillo, Rajmohan Banavi, -Christian Groves, Meral Shirazipour and David Black for their valuable inputs and comments. -Thanks to Christer Holmberg for doing a thorough review. - -
- - - - - - - - - - - - - - - - - - - - - - WebRTC 1.0: Real-time Communication Between Browsers - - - - - - - - - - - - - - - - - - - - - - - diff --git a/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness.xml b/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness.xml index 5942a10..84722f4 100644 --- a/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness.xml +++ b/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness.xml @@ -1,4 +1,4 @@ - + @@ -12,7 +12,8 @@ - + STUN Usage for Consent Freshness @@ -43,7 +44,8 @@ Freshness dwing@cisco.com - + Cisco Systems
@@ -85,13 +87,14 @@ Freshness martin.thomson@gmail.com
- + RAI RTCWEB To prevent sending excessive traffic to an endpoint, periodic consent -needs to be obtained from that remote endpoint. +needs to be obtained from that remote endpoint. To prevent attacks on peers, endpoints +have to ensure the remote peer is willing to receive traffic. This document describes a consent mechanism using a new Session @@ -104,7 +107,8 @@ Traversal Utilities for NAT (STUN) usage. To prevent attacks on peers, endpoints have to ensure the remote peer is willing to receive traffic. This is performed both when the -session is first established to the remote peer using Interactive Connectivity Establishment ICE +session is first established to the remote peer using Interactive Connectivity Establishment ICE connectivity checks, and periodically for the duration of the session using the procedures defined in this document. @@ -117,23 +121,40 @@ receive traffic. This consent expires after a period of time and needs to be continually renewed, which ensures that consent can be terminated. -This document defines what it takes to obtain, maintain, and lose -consent to send. Consent to send applies to a single 5-tuple. How -applications react to changes in consent is not described in this -document. +This document defines what it takes to obtain, maintain, and lose consent +to send. Consent to send applies to a single 5-tuple. How applications react to changes +in consent is not described in this document. The consent mechanism does not update the +ICE procedures defined in . -Consent is obtained only by full ICE implementations. An ICE-lite implementation -will not generate consent checks, but will just respond to consent -checks it receives. No changes are required to ICE-lite implementations in order -to respond to consent checks, as they are processed as normal ICE connectivity checks. +Consent is obtained only by full ICE implementations. An ICE-lite implementation as defined +in section 2.7 of will not generate consent checks, but will just +respond to consent checks it receives. No changes are required to ICE-lite implementations + in order to respond to consent checks, as they are processed as normal ICE connectivity + checks. + +
+ +This document defines what it takes to obtain, maintain, and lose consent +to send using ICE. Verification of peer consent before sending traffic is +necessary in deployments like WebRTC to ensure that a malicious JavaScript cannot use +the browser as a platform for launching attacks.Section 4.4 and section 5.3 of + explains why webRTC application needs +consent. + +Other Applications that have similar security requirement where it is +required to verify peer's consent before sending non-ICE packets can use the consent +mechanism described in this draft. +
+
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this -document are to be interpreted as described in . +document are to be interpreted as described in . @@ -153,15 +174,32 @@ The remote peer's IP address and UDP or TCP port number.
Although ICE requires periodic keepalive traffic to keep NAT bindings -alive (Section 10 of , ), those keepalives are sent as STUN Indications +alive (Section 10 of , ), those keepalives are sent as STUN Indications which are send-and-forget, and do not evoke a response. A response is necessary for consent to continue sending traffic. Thus, we need a request/response mechanism for consent freshness. ICE can be used for that mechanism because ICE implementations are already required to continue listening for ICE messages, as described in section 10 of - . If consent is performed then there is + . If consent is performed then there is no need to send keepalive messages. + + +When secure media (SRTP/SRTCP) is used the following considerations are applicable. +SRTP is encrypted and authenticated with symmetric keys; that is, both +sender and receiver know the keys. With two party sessions, receipt of +an authenticated packet from the single remote party is a strong +assurance the packet came from that party. However, when a session +involves more than two parties, all of whom know each other's keys, any +of those parties could have sent (or spoofed) the packet. Such shared +key distributions are possible with some MIKEY modes, Security +Descriptions, and EKT. Thus, in such shared +keying distributions, receipt of an authenticated SRTP packet is not +sufficient to verify consent. +
@@ -193,7 +231,8 @@ the initial ICE exchange. Although TCP has its own consent mechanism (TCP acknowledgements), consent is necessary over a TCP connection because it could be -translated to a UDP connection (e.g., ). +translated to a UDP connection (e.g., ). @@ -213,7 +252,8 @@ period. Implementations SHOULD set a default interval of 5 seconds, resulting in a period between checks of 4 to 6 seconds. -Each STUN binding request for consent MUST use a new cryptographically strong STUN transaction +Each STUN binding request for consent MUST use a new cryptographically strong STUN transaction ID. Each STUN binding requests for consent is transmitted once only. Hence, the sender cannot assume that it will receive a response for each consent request, and a response might be for a previous request @@ -238,11 +278,12 @@ To prevent attacks on the peer during ICE restart, an endpoint that candidate pair as described earlier. -While TCP affords some protection from off-path attackers (, ), there is +While TCP affords some protection from off-path attackers (, ), there is still a risk an attacker could cause a TCP sender to send forever by spoofing ACKs. To prevent such an attack, consent checks MUST be performed over all transport connections, including TCP. In this way, -an off-path attacker spoofing TCP segments can not cause a TCP sender +an off-path attacker spoofing TCP segments cannot cause a TCP sender to send once the consent timer expires (30 seconds). @@ -294,11 +335,12 @@ only indicates the associated SRTP source has quit. It is RECOMMENDED that STUN consent checks use the same Diffserv Codepoint markings as the ICE connectivity checks described in Section -7.1.2.4 of for a given 5-tuple. +7.1.2.4 of for a given 5-tuple. It is possible that different Diffserv Codepoints are used by -different media over the same transport address . Such a case is outside +different media over the same transport address . Such a case is outside the scope of this document. @@ -307,7 +349,7 @@ the scope of this document.
The DTLS applicability is identical to what is described in Section 4.2 - of . + of .
@@ -321,24 +363,16 @@ media or data channels.
-This document describes a security mechanism. +This document describes a security mechanism details of which are mentioned in section 4.1 +and section 4.2. Consent requires 96 bits transaction ID to be uniformly and randomly +chosen from the interval 0 .. 2**96-1, and be cryptographically strong. +This is good enough security against an off-path attacker replaying old +STUN consent responses. -The security considerations discussed in +The security considerations discussed in should also be taken into account. - -SRTP is encrypted and authenticated with symmetric keys; that is, both -sender and receiver know the keys. With two party sessions, receipt of -an authenticated packet from the single remote party is a strong -assurance the packet came from that party. However, when a session -involves more than two parties, all of whom know each others keys, any -of those parties could have sent (or spoofed) the packet. Such shared -key distributions are possible with some MIKEY modes, Security -Descriptions, and EKT. Thus, in such shared -keying distributions, receipt of an authenticated SRTP packet is not -sufficient to verify consent. -
@@ -349,9 +383,9 @@ This document does not require any action from IANA. Thanks to Eric Rescorla, Harald Alvestrand, Bernard Aboba, Magnus Westerland, Cullen Jennings, Christer Holmberg, Simon Perreault, Paul -Kyzivat, Emil Ivov, Jonathan Lennox, Inaki Baz Castillo, Rajmohan Banavi -and Christian Groves for their valuable inputs and comments. Thanks to -Christer Holmberg for doing a through review. +Kyzivat, Emil Ivov, Jonathan Lennox, Inaki Baz Castillo, Rajmohan Banavi, +Christian Groves, Meral Shirazipour and David Black for their valuable inputs and comments. +Thanks to Christer Holmberg for doing a thorough review.
@@ -364,7 +398,7 @@ Christer Holmberg for doing a through review. - + @@ -378,24 +412,24 @@ Christer Holmberg for doing a through review. WebRTC 1.0: Real-time Communication Between Browsers - + - + - + - + - + - + - \ No newline at end of file +