INTERNET-DRAFT Fredrik Danerklint Intended Status: Internet Best Current Practice (F redan AB) Expires: September 27, 2012 March 26, 2012 The Last Mile Cache draft-tlmc-00 Abstract The Last Mile Cache is a solution of how to cache content closer to the end user. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2012 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Fredrik Danerklint Expires September 27, 2012 [Page 1] INTERNET DRAFT The Last Mile Cache March 26, 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Last Mile Cache . . . . . . . . . . . . . . . . . . . . . 3 2.1 What's needed to done before starting to use TLMC . . . . . 5 2.2 The Databases . . . . . . . . . . . . . . . . . . . . . . . 6 2.3 Content Provider . . . . . . . . . . . . . . . . . . . . . . 9 2.4 Internet Service Provider . . . . . . . . . . . . . . . . . 10 2.5 Logfiles . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.7 The weakest link . . . . . . . . . . . . . . . . . . . . . . 12 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 13 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1 Normative References . . . . . . . . . . . . . . . . . . . 13 5.2 Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Fredrik Danerklint Expires September 27, 2012 [Page 2] INTERNET DRAFT The Last Mile Cache March 26, 2012 1 Introduction The Last Mile Cache [TLMC] tries to cache content much closer to end user. This solution is a two part. First the content providers and the second part, Internet Service Providers [ISP]. It also has some kind of fail over to the content provider if the cache server at the ISP is not available. 1.1 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 RFC 2119 [RFC2119]. 2. The Last Mile Cache The Last Mile Cache [TLMC] is a two part solution. First we are looking it from the end user perspective to see what is happening when using TLMC and to understand the hole idea. When a end user is issuing a request for http://mirrors.example.org it has to ask the domain name system [DNS] which ip address it has so it can connect to it. In our case we want it to have the ip address of the cache server at the end user's ISP (we call this ISP for example.com). To have this the following is happening. When the DNS for mirrors.example.org gets the DNS request for that host and it is from a ip address within the ISP example.com it will answer with a CNAME type with the ISP's domain for handling TLMC append to it (The ISP example.com is using tlmc.example.com as that domain). The answer will then look like this: 'mirrors.example.org IN CNAME mirrors.example.org.tlmc.example.com'. We now have to ask our ISP DNS for that host. The ISP's DNS now has two choices. Either it will give back the ip address of the nearest cache server for the end user to connect to OR it will answer with a CNAME if the ISP knows that the cache server(s) is down. If the DNS at the ISP provide a CNAME back we simply cannot use 'mirrors.example.org' as answer since then we will create a lookup loop. What we need is something that can be different from 'mirrors.example.org' but still unique to the content provider (example.org) to know where the answer should go (hopefully as close to the end user / cache server as possible). Fredrik Danerklint Expires September 27, 2012 [Page 3] INTERNET DRAFT The Last Mile Cache March 26, 2012 To solve this, the ISP MUST append the answer, without it's own TLMC domain, with the UN/LOCODE of the location where the DNS is placed. If the ISP DNS was placed in Karlskrona, Sweden, it would have looked like this: 'mirrors.example.org.tlmc.example.com IN CNAME kaa.k.se.mirrors.example.org' This method is also the same for the cache server at the ISP to load content from the content providers to the end user. It MUST append the DNS request with the UN/LOCODE of the location where the cache server is placed, like this: http://kaa.k.se.mirrors.example.org/ Still the name for that request MUST be http://mirrors.example.org/. When the content provider gets a DNS request for '*.mirrors.example.org' it MUST NOT return a CNAME record pointing it back to ISP where the request came from. Instead it SHOULD return a record to the closest server to serve the content from. Fredrik Danerklint Expires September 27, 2012 [Page 4] INTERNET DRAFT The Last Mile Cache March 26, 2012 2.1 What's needed to done before starting to use TLMC Before we can start using TLMC we need to provide two things. First what hosts (or website if you prefer that) that can be cached and second, the ip address ranges from the ISP so we know when to serve the content from the local cache server at the ISP. To be able to achieve this we need some kind of a database. The database itself will pretty much look like a Internet Routing Registry [IRR]. For example, RIPE:s database of routing registry, ripe.db.route.gz and ripe.db.route6.gz, is such examples. The content provider needs to make sure that their DNS can handle this type of DNS request that they gets and the ISP also needs a DNS to handle their request as well a cache server. Both parts also needs to know their UN/LOCODE location of their servers. This is what's REQUIRED for each part. 2.1.1 UN/LOCODE, United Nations Code for Trade and Transport Locations. When specifying the UN/LOCODE, the syntax is like this: LOCODE without the ISO 3166-1 country code.[SubDiv].ISO 3166-1 country code. The field SubDiv is OPTIONAL. Example of the city of Karlskrona, Sweden would be like this: kaa.k.se Another example, Bellingshausen, Antarctica, would be: bhn.aq Fredrik Danerklint Expires September 27, 2012 [Page 5] INTERNET DRAFT The Last Mile Cache March 26, 2012 2.2 The Databases There are going to be two databases. One for the hosts (called tlmc- hosts.db) and one for the ip address ranges (called-prefixes.db) from the ISP:s around the world. This way it will be easier to build local filter if that is necessary. An ISP SHOULD use the following example in their DNS to know if a request should be handle via the local cache server or sent upstream to the content provider: #grep hostname tlmc-hosts.db | gawk '{ print $2 }' >local-dns-filter 2.2.1 Database for the hosts Each host contains up to four records, 'hostname', 'log','period' and 'pgp'. Each host entry has been verified in that sense that a e-mail has been sent to the hostmaster of the domain (in our case that would be 'example.org') that contains a verification code to be submitted before a record is made into the database of hosts. This procedure is also done during a change request for an already host entry in the database. If you have more than one host for your domain, you'll need one record for each host that you are willing to be cached. 2.2.1.1 hostname This entry describe which host that can be cached for your domain. 'hostname: mirrors.example.org' is a valid one. REQUIRED. 2.2.1.2 log This entry describe to which e-mail address the logfile for that host should be sent. 'log: tlmclogs@example.org' is a valid one. REQUIRED. Fredrik Danerklint Expires September 27, 2012 [Page 6] INTERNET DRAFT The Last Mile Cache March 26, 2012 2.2.1.3 period This entry is OPTIONAL and describe under which period the logfile for this host SHOULD be sent to above e-mail address. Content provider should be a were that an ISP might not honor this entry. The period can contain: '1h' for every 1 hour '1d' for every 1 day '1w' for every 1 week '1m' for every 1 month The first number of each period can be '1-24' for hour, '1-31' for day, '1-52' for week and '1-12' for month. If the period entry does not exist the REQUIRED period SHALL be 1 month and the ISP MUST follow that. If the period is longer than 1 month then the ISP MUST follow that instead. 'period: 1h' is a valid example of a period. 2.2.1.4 pgp This entry is OPTIONAL and contains the public key signature of the e-mail address specified in the 'log' entry. It means that the above logfile should be sent as an encrypted PGP e-mail to the above e-mail address. However, for this to work correctly, the ISP needs as well to publish their PGP key in the databases of 'tlmc-prefixes.db'. 'pgp: 0x12345678' is a valid example of a public PGP signature key with the keyid of 0x12345678. Fredrik Danerklint Expires September 27, 2012 [Page 7] INTERNET DRAFT The Last Mile Cache March 26, 2012 2.2.2 Database for the prefixes Each prefix contains up to three records, 'prefix' or 'prefix6', 'cname', 'from' and 'pgp'. For you as an ISP to be able to add an entry to the database your prefix MUST first be in of the many routing databases that exists today. Not only that but it is also REQUIRED that the syntax for that prefix is correct. The verification is the same as 2.2.1 with the exception that it sends the e-mail to the hostmaster of the reverse address prefix which MUST exist in either the 'in-addr.arpa' or 'ip6.arpa' domain. 2.2.2.1 prefix or prefix6 This holds the prefix from where the ISP customers, end users, are coming from. You should aggregate your prefixes as much as possible. Aggregation is OPTIONAL. REQUIRED. 2.2.2.2 cname Which domain name the content provider should use when a request comes from this prefix. REQUIRED. 2.2.2.3 from The e-mail address the ISP using when sending logfiles. REQUIRED. 2.2.2.4 pgp This holds the pgp key that the ISP would use if the content provider also has a pgp key. OPTIONAL. 2.2.2.5 Example entry for the prefix database 'prefix: 192.0.2.0/24' 'cname: tlmc.example.com' 'from: tlmc@example.com' 'prefix6: 2001:db8::/32' 'cname: tlmc.example.com' 'from: tlmc@example.com' 'pgp: 0x12345678' Fredrik Danerklint Expires September 27, 2012 [Page 8] INTERNET DRAFT The Last Mile Cache March 26, 2012 2.3 Content Provider For a content provider to be able to use TLMC they need to have a DNS that can answer the question received in '2. The Last Mile Cache' as described there and register the hosts in the database. Also make sure that your webserver add headers to allow the cache servers to actually cache your content. A content provider should be aware that it might take more than 24 hours for the ISP:s around the world to download the new database of 'tlmc-hosts.db' before you SHOULD start using TLMC. Fredrik Danerklint Expires September 27, 2012 [Page 9] INTERNET DRAFT The Last Mile Cache March 26, 2012 2.4 Internet Service Provider An ISP need first to install a cache server somewhere in their network. They don't need to add all their prefixes to the databases directly from start, they can start with a smaller subset if they want. However, please remember that it is not the ip addresses for the applications that's needed to be in the database. It is from which ip address the DNS request origins from. If you allow your customers to have their own DNS, include their prefixes as well. Otherwise it's only the ISP's own DNS ip addresses that's needed to be in the database. There is an working example with PowerDNS as the DNS and a special backend to be able to answer your customer with your cache server(s) ip address, at https://tlmc.fredan.se/. You only have to run this on the delegated domain (tlmc.example.org). If you are using Apache Traffic Server [ATS] as the cache server, this is what's needed in the configuration: From the file 'remap_config': regex_map http://(.*)/ http://kaa.k.se.$0/ You MUST replace "kaa.k.se" with your UN/LOCODE of where the cache server is placed. Fredrik Danerklint Expires September 27, 2012 [Page 10] INTERNET DRAFT The Last Mile Cache March 26, 2012 2.5 Logfiles The content of the sent logfiles SHALL be like this: The timestamp MUST be in Unix seconds with the timezone in UTC. Since there is no ip addresses in the logfile the ISP MUST send one logfile for the content served with ip4 addresses and one for ip6 addresses to the content provider. Also each logfile SHALL be named with the 'cname' as specified in the 'tlmc-prefixes.db' database. In our example this is what the logfile should have been named: 'mirrors.example.org.tlmc.example.com.ip4.log' for content served to end users with ip4 addresses and 'mirrors.example.org.tlmc.example.com.ip6.log' for content served to end users with ip6 addresses. Fredrik Danerklint Expires September 27, 2012 [Page 11] INTERNET DRAFT The Last Mile Cache March 26, 2012 2.7 The weakest link The weakest link with TLMC is the local DNS at the ISP. Redundancy with multiplies DNS is RECOMMENDED. Fredrik Danerklint Expires September 27, 2012 [Page 12] INTERNET DRAFT The Last Mile Cache March 26, 2012 3 Security Considerations Since the content transported over TLMC is unencrypted from the content provider to the end user, you should encrypt the file(s) that you don't want anybody to be able to look at without a 'key'. TLMC SHALL NOT handle of how to distribute your 'key'. 4 IANA Considerations 5 References 5.1 Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [UN/LOCODE] "United Nations Code for Trade and Transport Locations", . 5.2 Informative References [DNS] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [PGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007. [ATS] "Apache Traffic Server", . [IRR] "Internet Routing Registry", . [UNIX TIME] "Number of seconds elapsed since midnight Coordinated Universal Time (UTC) of Thursday, January 1, 1970", . Fredrik Danerklint Expires September 27, 2012 [Page 13] INTERNET DRAFT The Last Mile Cache March 26, 2012 Authors' Addresses Fredrik Danerklint Kungsmarksvagen 33A S-37144 Karlskrona SWEDEN EMail: fredan-tlmc@fredan.se Fredrik Danerklint Expires September 27, 2012 [Page 14]