1 / 9

A TLS Extension for Service Indication draft-zhang-tls-service-indication-extension-00

This draft proposes a TLS extension to provide Service Indication Information for charging gateways, enabling ISPs to distinguish traffic accessing specific content/services. The extension ensures secure transfer of the information to prevent misuse and protect user privacy.

asmtih
Download Presentation

A TLS Extension for Service Indication draft-zhang-tls-service-indication-extension-00

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A TLS Extension for Service Indicationdraft-zhang-tls-service-indication-extension-00 Dacheng Zhang Dapeng Liu Alibaba Group IETF 95

  2. Motivation Scenario (1) • To attract potential consumers and gain advantages in the market competition, ICPs seek to provide customers with discount for their traffics accessing their services. • To achieve this, a ICP need to cooperate with its ISPs and enable the charging gateways of ISPs to distinguish the traffic flows accessing to certain content/services from other traffics. • In order to achieve this objective, additional Service IndicationInformation needs to be provided for a charging gateway so that the gateway can find the associated charging policies for the traffic flow. • Such information should not be be provided at the application layer when TLS has been widely used in practice.

  3. Motivation Scenario (2) • On 11 Nov. 2016, Alibaba attracted over 115 million buyers to its marketplaces and enabled RMB91.2 billion (US$14 billion) in GMV settled through Alipay on Alibaba’splatforms. • Alibaba’s platform supported 467 million delivery orders during a 24-hour period and enabled about 140,000 peak transactions processed per second. • So, security is a big concern，but we need a light solution.

  4. Why don’t we use SNI? • SNI is not use for service indication • SNI has a length limitation • No protection is provided for SNI. Moreover，SNI is relatively static, when a SNI of ICP A is know by ICP B, the APP of ICP B can use it to gain benefit

  5. What do we need? • We need to transfer the Service Indication information in a secure way so that ICP B cannot use the SNI of ICP A without being detected

  6. Our Solution (1) • We define an extension to carry the SI information and transfer it in the client_hello packet struct { opaque ServieName; uint64 timestamp; KeyIDkey_identifier; opaque Message_authenticaiton_data; } ServiceIndicatingInfo; enum { key_id(0) } KeyID;

  7. Our Solution (2) • We use timestamp and HMAC to guarantee the freshness of the SI information • In the current solution, the digest only covers the extension, so that an attacker can re-use the token when the timestamp is still valid • In the future version we consider to have the digest cover the whole packet, which will make the attacks more difficult.

  8. Why don’t we do this work at the TCP or IP layer • No space for IPv4 header • There are limits on the lengths TCP options • TCP and IP are implemented in kernel mode, which makes the deployment of such change more difficult • …

  9. Comments?

More Related