RFC 1455

Physical Link Security Type of Service 🦋

Okay bestie, the title block first 💅 This is RFC 1455, from the Network Working Group, written by D. Eastlake, III (Donald E. Eastlake, III) at Digital Equipment Corporation and dated May 1993. It's filed as an Experimental Protocol, and it doesn't list any RFCs it obsoletes or updates ✨

Status of this Memo 🌸

This memo defines an Experimental Protocol for the Internet community, and the authors are asking for discussion and suggestions for improvement 🫶 For the standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards." Distribution of this memo is unlimited 💜

Abstract 🎀

This RFC documents an experimental protocol that adds a Type of Service (TOS) asking the network for maximum physical link security 🔥 It's an addition to the types of service listed in RFC 1349: Type of Service in the Internet Protocol Suite. The new TOS asks the network to protect traffic labeled this way against secret watching by outside agents, as much as the network can manage 🕵️ The point is protection against traffic analysis, plus an extra possible layer of data confidentiality. It fits with every other defined type of service for IP version 4 because it's based on link-level characteristics, and it won't promise any particular guaranteed level of service 🦋

1. Nature of Requirement 💅

This IP addition tackles two possible security needs: resistance to traffic analysis and confidentiality ✨ The next two subsections cover those, and then there's a look at why links have different levels of physical security, so asking for the more secure ones actually means something 🌈

1.1 Traffic Analysis 🌸

Right now, every Internet Protocol (IP) packet MUST keep most of its header information, including the "from" and "to" addresses, in the clear 😭 This is REQUIRED so routers can handle the traffic properly, even when a higher-level protocol fully encrypts every byte after the IP header. That means even end-to-end encrypted IP packets can be traffic-analyzed if someone can watch the data stream 💀 Traffic stats are usually less sensitive than what's inside the packets, but sometimes you can figure out what hosts or users are doing just from the traffic info 🙈

Routers need to see header info, so it's hard to protect traffic statistics from an adversary who's already on the inside of the network 🫶 Still, more secure physical links make it harder for outsiders to watch the traffic, which helps protect against traffic analysis 🦋

Users would obviously love a guaranteed level of link security, the same way they'd love a guaranteed bandwidth or delay 👑 But those guarantees need a resource reservation and/or policy routing scheme, and that's beyond what the current IP Type of Service facility can do 😭

The TOS field is in all current Internet packets, and routing based on TOS shows up in routing protocols like OSPF [See 5,6,7]. Realistically though, the whole Internet is not going to implement this extra TOS any time soon 🙈 Even so, people worried about traffic analysis need a way to ask that the links their packets cross be as physically secure as possible, ahead of other link characteristics 💖 That's exactly what this proposed TOS gives them ✨

1.2 Confidentiality 💖

Using links with more physical security adds a layer of protection for the confidentiality of packet data, on top of the traffic analysis protection 🫶 If the packet contents are already protected by end-to-end encryption, secure links make it harder for an outside attacker to grab the encrypted data to go after 🔥 If the contents are plain text, secure links might be the only confidentiality protection there is 😭

Sometimes end-to-end encryption just isn't allowed 💀 For example, paths through countries that restrict encryption, like France or Australia, and paths that use an amateur radio link, where encryption is prohibited 🌈 In those cases, link security is usually the only confidentiality available 💅 The proposed TOS gives a way to ask the network for the best it can do to protect that unencrypted data 🦋

This TOS is REQUIRED for better confidentiality, especially where encryption can't be used, even though it doesn't give the guarantees a lot of users want 🎀 Check the discussion at the end of the Traffic Analysis section above 💜

1.3 Link Physical Security Characteristics 🌈

Physical links are made of lines and routers, and they vary a lot in how easily someone can secretly observe the information flowing over them 👀 Here's a list of examples for line security:

1. Land line media is usually harder to intercept than radio broadcast media.
2. Among radio broadcast media, spread spectrum or other low probability of intercept systems are harder to intercept than normal broadcast systems. At the other extreme, systems with a large footprint on the earth, like some satellite down links, can be particularly accessible 🛰️
3. Among land lines, point-to-point systems are generally harder to intercept than multi-point systems like Ethernet or FDDI.
4. Fiber optic land lines are generally harder to intercept than metallic paths, because fiber is harder to tap 🧚
5. A secure land line, like one in pressurized conduit with pressure alarms or one installed so guards can observe it, is harder to intercept than an unsecured land line 👑
6. An encrypted link is preferable to an unencrypted one, because even if someone accessed it, getting anything useful out of it would be much harder 💜

Routers have different levels of security against interception too, depending on how physically secure the router site is and similar factors 🙈

All these comparisons show there are real, significant differences in how secure the physical links in the Internet are 🔥 Picking links where it's hard for an outside observer to watch the traffic improves both confidentiality and protection against traffic analysis ✨

2. Protocol Specification 👑

The value 15 decimal (F hex) in the four-bit Type of Service IP header field asks for the packet to be routed to minimize the chance that agents outside the network can secretly observe its contents 💖 (This value was chosen to sit at the maximum hamming distance from the other existing TOS values 🧚)

3. Protocol Implementation 🧚

This TOS can be implemented in routing systems that offer TOS-based routing, like OSPF (see RFCs 1245 through 1247), by assigning costs to links 🌸 How you set the "cost" of each link for this TOS is a local policy call 💅

Services can be truly incomparable when criteria like the ones in the Nature of Requirement section above clash 😭 For example, you might have to choose between an encrypted broadcast system and an unencrypted fiber optic land line. In practice, link encryption would probably beat every other form of protection, and the physical security from criterion 5 above would beat other land line differences 🫶

Here's an example of "costs" at a hypothetical router:

           Cost    Type
            1      Strong encryption with secure key distribution
            2      Physically secure point-to-point line
            6      Typical point-to-point line
            8      Typical local multi-point media
           12      Metropolitan area multi-point media
           24      Local radio broadcast
           32      Satellite link

Link costs SHOULD be set in the same ratio as the probability of interception 📊 So these example costs imply a local policy assumption that interception is 32 times more likely on a satellite link and its router than on a strongly encrypted line and its router 👀 You don't need the absolute probability of interception on any one link. Estimating the ratio between interception probabilities on different links is enough 💖

Heads up, bestie: using costs like these could mean way more links than the default type of service would pick 🙈 For example, over 50 highly secure links could be a better choice than two insecure links, like an unencrypted satellite hop and a radio link. But if the costs are set properly in proportion to the probability of interception, that longer route with more links is more secure than the shorter default route 🔥 This is also why you have to estimate router security as well as link security. An overly steep cost ratio based only on the security of a communications line could send packets through lots of routers that are less secure than the lines involved 😭 Taking router characteristics into account matters for every other defined TOS value too 💅

It SHOULD also be noted that routing algorithms usually add up the costs of the links 🧮 For this type of service, multiplying the link probabilities of secure transmission would be more appropriate. The same problem exists for the high reliability TOS, though, and adding them up is a decent approximation for most uses, as RFC 1349 notes 🌈

References 🍓

• [1] Postel, J., "Internet Protocol - DARPA Internet Program Protocol Specification", STD 5, RFC 791, DARPA, September 1981.
• [2] Braden, R., Editor, "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, IETF, October 1989.
• [3] Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, IETF, October 1989.
• [4] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, Consultant, July 1992.
• [5] Moy, J., Editor, "OSPF Protocol Analysis", RFC 1245, Proteon, Inc., July 1991.
• [6] Moy, J., Editor, "Experience with the OSPF Protocol", RFC 1246, Proteon, Inc., July 1991.
• [7] Moy, J., "OSPF Version 2", RFC 1247, Proteon, Inc., July 1991.

Security Considerations 💀

This is serious, bestie 😭 The entirety of this memo is about an Internet Protocol Type of Service that asks for maximum physical link security against secret interception. The whole point is keeping traffic away from prying eyes, so it's the security feature itself, not an afterthought 🔥

Author's Address 💜

Donald E. Eastlake, III
Digital Equipment Corporation*
30 Porter Road, MS: LJO2/I4
Littleton, MA 01460

Phone: +1 508 486 2358 (w),  +1 617 244 2679 (h)
Email: dee@ranger.enet.dec.com

*Company affiliation given for identification only. This document does not constitute a statement, official or otherwise, by Digital Equipment Corporation. 🦋