| < draft-sprecher-mobile-tg-exposure-req-arch-00.txt | draft-sprecher-mobile-tg-exposure-req-arch-01.txt > | |||
|---|---|---|---|---|
| Internet Engineering Task Force A. Jain | Internet Engineering Task Force A. Jain | |||
| Internet-Draft A. Terzis | Internet-Draft A. Terzis | |||
| Intended status: Informational Google | Intended status: Informational Google | |||
| Expires: August 23, 2015 N. Sprecher | Expires: August 24, 2015 N. Sprecher | |||
| S. Arunachalam | S. Arunachalam | |||
| Nokia Networks | Nokia Networks | |||
| K. Smith | K. Smith | |||
| G. Klas | G. Klas | |||
| Vodafone | Vodafone | |||
| February 19, 2015 | February 20, 2015 | |||
| Requirements and reference architecture for Mobile Throughput Guidance | Requirements and reference architecture for Mobile Throughput Guidance | |||
| Exposure | Exposure | |||
| draft-sprecher-mobile-tg-exposure-req-arch-00.txt | draft-sprecher-mobile-tg-exposure-req-arch-01.txt | |||
| Abstract | Abstract | |||
| Rapidly-varying conditions in a cellular network can cause problems | Rapidly-varying conditions in a cellular network can cause problems | |||
| for the Transmission Control Protocol (TCP), which in turn can | for the Transmission Control Protocol (TCP), which in turn can | |||
| degrade application performance. | degrade application performance. | |||
| This document presents the problem statement and proposes solution | This document presents the problem statement and proposes solution | |||
| principles. It specifies the requirements and reference architecture | principles. It specifies the requirements and reference architecture | |||
| for a mobile throughput guidance exposure mechanism that can be used | for a mobile throughput guidance exposure mechanism that can be used | |||
| skipping to change at page 2, line 4 ¶ | skipping to change at page 2, line 4 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on August 23, 2015. | This Internet-Draft will expire on August 24, 2015. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2015 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| skipping to change at page 7, line 5 ¶ | skipping to change at page 7, line 5 ¶ | |||
| 2.2. Security requirements | 2.2. Security requirements | |||
| 1. A trustful relationship between the Mobile Throughput Provider | 1. A trustful relationship between the Mobile Throughput Provider | |||
| and the TCP server SHOULD be formed before any information is | and the TCP server SHOULD be formed before any information is | |||
| exposed. | exposed. | |||
| 2. There SHOULD be a mechanism to configure the Mobile Throughput | 2. There SHOULD be a mechanism to configure the Mobile Throughput | |||
| Guidance Provider with a list of destinations to which throughput | Guidance Provider with a list of destinations to which throughput | |||
| guidance should be provided. | guidance should be provided. | |||
| 3. The identifier of the network that exposes the throughput | 3. The identity of the Mobile Throughput Guidance Provider SHALL be | |||
| guidance information SHALL be explicitly known to the TCP server | explicitly known to the TCP server which receives the | |||
| which receives the information. The TCP server SHALL be able to | information. The TCP server SHALL be able to authenticate the | |||
| authenticate the identity of the information provider. The | identity of the Mobile Throughput Guidance Provider. The Mobile | |||
| Throughput Guidance Provider MUST NOT reveal any other identity | Throughput Guidance Provider MUST NOT reveal any other identity | |||
| or address of network elements that can compromise the security | or address of network elements that can compromise the security | |||
| of the network. | of the network. | |||
| 4. The mobile throughput guidance information SHOULD be secured to | 4. The mobile throughput guidance information SHOULD be secured to | |||
| ensure confidentiality and integrity. | ensure confidentiality and integrity. | |||
| 5. There SHOULD be a mechanism to configure the required security | 5. There SHOULD be a mechanism to configure the required security | |||
| level and parameters for the encryption and the authentication if | level and parameters for the encryption and the authentication if | |||
| supported. | supported. | |||
| skipping to change at page 9, line 27 ¶ | skipping to change at page 9, line 27 ¶ | |||
| discussed in the solution documents. Section 2 specifies a set of | discussed in the solution documents. Section 2 specifies a set of | |||
| requirements on the management of the mobile throughput guidance | requirements on the management of the mobile throughput guidance | |||
| exposure functional elements and protocol operation. | exposure functional elements and protocol operation. | |||
| 6. Security considerations | 6. Security considerations | |||
| The exposure of mobile throughput guidance information from the | The exposure of mobile throughput guidance information from the | |||
| cellular network to the TCP server introduces a set of security | cellular network to the TCP server introduces a set of security | |||
| considerations. | considerations. | |||
| First, an identifier of the network that provides the throughput | As per requirement #3 in section 2.2, the TCP server SHALL be able to | |||
| guidance must be explicitly known to the endpoint receiving the | authenticate the identity of the Mobile Throughput Guidance Provider. | |||
| information. Omitting such information would enable malicious third | The Mobile Throughput Guidance Provider MUST NOT reveal any other | |||
| parties to provide erroneous information. To avoid compromising | identity or address of network elements that can compromise the | |||
| network and user security, other identities or addresses MUST NOT be | security of the network. | |||
| exposed. | ||||
| Furthermore, the throughput guidance information should be treated | Furthermore, the throughput guidance information should be treated | |||
| only as an estimate to the congestion control algorithm running at | only as an estimate to the congestion control algorithm running at | |||
| the transport endpoint. The endpoint that receives this information | the transport endpoint. The endpoint that receives this information | |||
| should not assume that it is always correct and accurate. | should not assume that it is always correct and accurate. | |||
| Specifically, endpoints should check the authenticity and integrity | Specifically, endpoints should check the authenticity and integrity | |||
| of the information received and if they find it erroneous they should | of the information received and if they find it erroneous they should | |||
| discard it and possibly take other corrective actions (e.g., discard | discard it and possibly take other corrective actions (e.g., discard | |||
| all future throughput guidance information from a particular IP | all future throughput guidance information from a particular IP | |||
| prefix). | prefix). | |||
| End of changes. 6 change blocks. | ||||
| 14 lines changed or deleted | 13 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||