RFC 1675

RFC 1675: Security Concerns for IPng 🎀

okay bestie, the title block first 💅 This is RFC 1675, called "Security Concerns for IPng." Steven M. Bellovin from AT&T Bell Laboratories wrote it. It's Informational and dated August 1994. The title block doesn't list anything it obsoletes or updates, so it's just doing its own thing ✨

---

Status of This Memo

So the vibe here is that this memo is here to provide information for the Internet community 📖 It does not specify an Internet standard of any kind 🙅‍♀️ Distribution of this memo is unlimited 💜

Abstract

This doc was submitted to the IETF IPng area as a response to RFC 1550 🫶 Publishing it does not mean the IPng area accepts any of the ideas inside 🙈 If you want to share comments, send them to big-internet@munnari.oz.au 📬

Overview and Rationale

Okay, the big picture: some of the IPng candidates have features that are kinda worrisome from a security perspective 😬 IPng doesn't have to be better than IPv4, but it is mandatory that it not make things worse 💀 Below, I go through the areas I'm concerned about. In some cases a feature would hurt security if nothing else is done. Adopting it anyway might be fine, but then the corrective action is mandatory 🔥

Firewalls 🧱

Firewalls are a whole main character in today's Internet, for better or worse 💅 Real talk, they aren't mainly a response to network protocol security problems. They're a way to compensate for failings in software engineering and system administration 🩹 So firewalls aren't going anywhere soon, and IPng will do nothing to make host programs any less buggy 🙃 Anything that makes firewalls harder to deploy will make IPng less acceptable in the market 📉

Firewalls come with a list of requirements 📋 First, there must be a hierarchical address space. Lots of address-based filters use the structure of IPv4 addresses for access control decisions, and lucky for us, this is a requirement for scalable routing too 🙌

Routers only need access to the destination address of the packet 🗺️ But network-level firewalls often need to check both the source and destination address. A structure that makes the source address harder to find is a distinct negative 👎

They also need access to the transport-level header (that's TCP or UDP 🧃). That could be for the port number field, or for access to various flag bits, notably the ACK bit in the TCP header. That latter field is used to tell incoming calls apart from outgoing ones 📞

In a different vein, at least one of the possible transition plans uses network-level packet translators [1] 🔁 Organizations that use firewalls will need to deploy their own translators to help convert their internal networks. They can't rely on centrally-located translators meant for the entire Internet community 🙅 So translators have to be simple, portable to lots of common platforms, and cheap 💸 We don't want to put too high a financial barrier in front of converts to IPng 🫶

By the same token, it's desirable that these translation boxes not be usable for network-layer connection-laundering. It's already hard enough to trace back attacks today, so we shouldn't make it harder 🕵️ (Some brands of terminal servers can be used for laundering. Most sites with such boxes have learned to configure them so that such activities are impossible.) Comprehensive logging is a possible alternative 📜

IPAE [1] is giving good translation energy 🎉 Its addresses are (as much as possible) preserved. So it's necessary to avoid any alternative strategies, like circuit-level translators, that might cause problems 🚫

---

Encryption and Authentication 🔐

A bunch of people are starting to experiment with IP-level encryption and cryptographic authentication, and this trend will (and should) continue 📈 IPng should not make this harder, either intrinsically or by imposing a substantial performance barrier 🏃‍♀️

Encryption can happen at different granularities: host to host, host to gateway, and gateway to gateway 🧩 All of these have their uses, so IPng must not rule out any of them. Encapsulation and tunneling strategies are kinda problematic, because the packet may no longer carry the original source address when it reaches an encrypting gateway 😭 (This may be seen more as a constraint on network topologies. So be it, but we should warn people about the limitation.)

Dual-stack approaches, like in TUBA's transition plan [2], imply multiple addresses for each host 👯 (IPAE has this feature too.) The encryption and access control infrastructure needs to know about all addresses for a given host, belonging to whichever stack. It should not be possible to bypass authentication or encryption by asking for a different address for the same host 🚪🔒

---

Source Routing and Address-based Authentication 🗺️

The dominant form of host authentication in today's Internet is address-based 🪪 Basically, hosts often decide to trust other hosts based on their IP addresses. (Honestly, it's worse than that. A lot of authentication is name-based, which opens up new avenues of attack. But if an attacker can spoof an IP address, there's no need to attack the name service.) To the extent that it works, address-based authentication relies on the implied accuracy of the return route. Injecting packets with a false source address is easy, but replies will generally follow the usual routing patterns and get sent to the real host with that address. This frustrates most, though not all, attempts at impersonation 🛡️

Problems can show up if source-routing is used 😬 A source route has to be reversed for reply packets, and it overrides the usual routing mechanism. That hence destroys the security of address-based authentication. For this reason, many organizations disable source-routing, at least at their border routers 🚧

One candidate IPng, SIPP, includes source-routing as an important component. To the extent this is used, it breaks address-based authentication. This may not be bad. In fact, it's probably good 🤷‍♀️ But it is vital that a more secure cryptographic authentication protocol be defined and deployed before any substantial cutover to source routing, if SIPP is adopted 🚨

---

Accounting 💰

A significant part of the world wants to do usage-sensitive accounting. This may be for billing, or it may simply be to accommodate quality-of-service requests. Either way, definitive knowledge of the relevant address fields is needed 📊 To accommodate this, IPng should have a non-intrusive packet authentication mechanism. By "non-intrusive," I mean that it should (a) present little or no load to intermediate hops that do not need to do authentication; (b) be deletable (if desired) by the border gateways; and (c) be ignorable by end-systems or billing systems to which it is not relevant ✨

References 📚

[1] Gilligan, R., and E. Nordmark, "IPAE: The SIPP Interoperability and Transition Mechanism", Work in Progress, March 16, 1994.

[2] Piscitello, D., "Transition Plan for TUBA/CLNP", Work in Progress, March 4, 1994.

Security Considerations 🚨

This entire memo is about Security Considerations. Literally the whole thing 💀 It's giving meta, and you should take every word of it seriously, bestie 🫶

Author's Address 💌

Steven M. Bellovin
Software Engineering Research Department
AT&T Bell Laboratories
600 Mountain Avenue
Murray Hill, NJ  07974, USA

Phone: +1 908-582-5886
Fax: +1 908-582-3063
EMail:  smb@research.att.com