RFC 5387

Problem and Applicability Statement for Better-Than-Nothing Security (BTNS)

📅 published November 2008, from ietf

RFC 5387: Problem and Applicability Statement for Better-Than-Nothing Security (BTNS) 🎀

okay bestie, this one is from the Network Working Group and it's dated November 2008 🌸 It's Informational, so it's here to share info with the Internet community, not to set a standard 🫶 It was written by J. Touch (USC/ISI), D. Black (EMC), and Y. Wang (Microsoft). The title block doesn't list anything it obsoletes or updates, so it's just doing its own thing ✨

Status of This Memo 📜

this memo gives info to the Internet community and does NOT specify an Internet standard of any kind, so chill 💅 Distribution of this memo is unlimited, so share it with everyone 💖

Copyright (c) 2008 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) as they stand on the date it was published. read those carefully, because they spell out what you can and can't do with this doc, and it's giving legal homework 📚

Abstract 🌈

okay so IPsec, the Internet network security protocol suite, usually needs authentication of network-layer entities so it can do access control and provide security services 🔐 That authentication can rely on stuff like pre-shared symmetric keys, certificates with matching asymmetric keys, or Kerberos (through Kerberized Internet Negotiation of Keys (KINK)). And honestly? Deploying all that authentication info and its identities is a huge obstacle to using IPsec 😭

this document explains why we should extend the suite so IPsec security services can be used without authentication 🦋 That's the "better-than-nothing security" (BTNS) idea: protection that's better than nothing ✨ BTNS can be used alone (that's Stand-Alone BTNS, or SAB) or it can give you network-layer security that higher layers in the protocol stack can authenticate (that's Channel-Bound BTNS, or CBB) 💜 The doc also covers situations where SAB and/or CBB extensions make sense.

Table of Contents 🗂️

   1. Introduction ....................................................3
      1.1. Authentication .............................................3
      1.2. IPsec Channels and Channel Binding .........................4
      1.3. BTNS Methods ...............................................6
      1.4. BTNS Scope .................................................6
      1.5. Structure of This Document .................................7
   2. Problem Statement ...............................................7
      2.1. Network Layer ..............................................8
           2.1.1. Authentication Identities ...........................8
           2.1.2. Authentication Methods ..............................8
           2.1.3. Current IPsec Limits on Unauthenticated Peers .......9
      2.2. Higher Layer Issues ........................................9
           2.2.1. Transport Protection from Packet Spoofing ...........9
           2.2.2. Authentication at Multiple Layers ..................10
   3. BTNS Overview and Threat Models ................................12
      3.1. BTNS Overview .............................................12
      3.2. BTNS and IPsec Security Services ..........................13
      3.3. BTNS and IPsec Modes ......................................14
   4. Applicability Statement ........................................15
      4.1. Benefits ..................................................16
      4.2. Vulnerabilities ...........................................16
      4.3. Stand-Alone BTNS (SAB) ....................................17
           4.3.1. Symmetric SAB ......................................17
           4.3.2. Asymmetric SAB .....................................18
      4.4. Channel-Bound BTNS (CBB) ..................................18
      4.5. Summary of Uses, Vulnerabilities, and Benefits ............19
   5. Security Considerations ........................................20
      5.1. Threat Models and Evaluation ..............................20
      5.2. Interaction with Other Security Services ..................20
      5.3. MITM and Masquerader Attacks ..............................21
      5.4. Denial of Service (DoS) Attacks and Resource
           Consumptions ..............................................22
      5.5. Exposure to Anonymous Access ..............................22
      5.6. ICMP Attacks ..............................................22
      5.7. Leap of Faith .............................................22
      5.8. Connection Hijacking through Rekeying .....................24
      5.9. Configuration Errors ......................................25
   6. Related Efforts ................................................25
   7. Acknowledgments ................................................25
   8. Informative References .........................................26

1. Introduction ✨

okay so network security comes from a bunch of protocols at different layers of the stack 🥞 At the network layer, the IPsec protocol suite (made of IKE (Internet Key Exchange protocol), ESP (Encapsulating Security Payload), and AH (Authentication Header)) secures IP traffic 🔐 IPsec, IKE included, gives you super high levels of security that protect against a wide range of threats, but it requires authentication [5][7][8] 🙈 And authentication needs authentication identities and credentials to be deployed, which can be a real obstacle to using IPsec 😩 This document talks about that dependency and introduces "Better-Than-Nothing Security" (BTNS) as one solution 🦋 Its goal is to give everyone a generally useful way to apply IPsec security services without needing network-layer authentication 💖

1.1. Authentication 🔑

there are two main architectural approaches to authentication: using out-of-band communications, and using pre-deployed information 🧚 Out-of-band authentication can happen through a trusted third party, through a separate communication channel to the peer, or through the same channel you're securing but at a higher layer 💜 Out-of-band authentication needs mechanisms and interfaces that bind the authenticated identities to the secure communication channels, and it's out of scope for this document (though it may be possible to extend the channel binding mode of BTNS to work with such mechanisms) 🌸 Pre-deployed information includes identities, pre-shared secrets, and credentials that trusted authorities have authenticated (for example, a certificate and its corresponding private key) 🎀

this form of authentication often needs manual deployment and coordination between the communicating peers 😮‍💨 Plus, getting and deploying credentials like certificates signed by certification authorities (CA) takes extra protocol and administrative actions, which can cost a lot of time and effort ⏳

these factors make it more work to use IKE with IPsec for peer authentication 🥲 So some users and applications skip using IPsec to protect traffic at the network layer, and instead rely on higher-layer security protocols (for example, TLS [4]) or just run with no security at all 💀 As Section 2.2.1 explains, higher-layer security protocols may not be enough to protect against some network-layer attacks 🚨

to make things better, you could either reduce the hurdles to getting and configuring authentication information, or remove the requirement for authentication in IPsec 👑 The second option is the core idea of BTNS, which gives you anonymous (unauthenticated) keying for IPsec so it can create security associations (SAs) with peers that don't have the required authentication credentials 🫶 This needs extensions to the IPsec architecture 🔧 Since the new BTNS modes relax the authentication requirement, the impacts, tradeoffs, and risks must be thoroughly understood before anyone applies BTNS to any communications ⚠️ More specifically, this document looks at whether and when network-layer authentication can be left out, the risks of using BTNS, and finally, the impacts on the existing IPsec architecture 🌈

BTNS uses a weaker idea of authenticated identity compared to most authentication protocols, and this weaker idea is bootstrapped from the security association itself 💅 It's called "continuity of association," and it doesn't mean "Bill Smith" or "owner of shared secret X2YQ." It means "the entity with which I have been communicating on connection #23" 🙈 Continuity of association is only invariant within a single SA, not across SAs, so it can only protect you for the lifetime of an SA ⏰ This is a core notion BTNS relies on, especially when there's no higher-layer authentication 🔥 Continuity of association can be seen as a form of authentication where the identity isn't authenticated across separate associations or out-of-band, but it also doesn't change during the lifetime of the SA 🦋

1.2. IPsec Channels and Channel Binding 🦋

okay so when higher-layer protocols use IPsec security services, it is SO important to bind those services to the higher-layer protocol sessions 💅 that way the security gets applied consistently to all the higher-layer traffic involved. The result of this binding is an "IPsec channel", and making one is an instance of channel binding. Channel binding is covered in RFC 5056 [27] and in an associated connection latching document [26]. This subsection is a quick recap of the parts of those docs you need to get BTNS 🫶

A secure channel is a packet, datagram, octet stream connection, or sequence of connections between two endpoints that affords cryptographic integrity and, optionally, confidentiality to data exchanged over it [27]. Applying that to IPsec, an "IPsec channel" is a packet flow tied to a higher-layer protocol session, like a TCP connection, where every packet is protected by IPsec SAs such that:

  • the peer's identity is the same for the lifetime of the packet flow, and
  • the quality of IPsec protection used for the packet flow's individual packets is the same for all of them for the lifetime of the packet flow [26].

The endpoints of an IPsec channel are the higher-layer protocol endpoints, which sit beyond the endpoints of the IPsec SAs involved. 🧚 This means each IPsec SA needs to be bound to the higher-layer protocol session and its endpoints. If you skip this binding, you open the door to man-in-the-middle (MITM) attacks, where what looks like one IPsec SA for the higher-layer protocol traffic is actually two separate SAs stitched together by an attacker acting as a traffic-forwarding proxy. 💀 not it.

Connection latching [26] and channel binding [27] work together to create IPsec channels and bind IPsec SAs to higher-layer protocols. Connection latching creates an IPsec channel by associating IPsec SAs with higher-layer protocol sessions, and channel binding lets a higher-layer protocol bind its authentication to those IPsec SAs. Caching this "latch" across higher-layer protocol sessions is necessary to counter inter-session spoofing attacks, and the channel binding authentication should be performed on each higher-layer protocol session. ✨ Connection latching and channel binding are useful not only for BTNS but also for IPsec SAs whose peers are fully authenticated by IKE during creation of the SA.

Channel binding for IPsec is based on information obtained from the SA creation process that uniquely identifies an SA pair. You can do the binding by adding this identifying information to higher-layer authentication mechanisms based on one-way hashes, key exchanges, or (public key) cryptographic signatures. In all three cases, the resulting higher-layer authentication resists man-in-the-middle attacks on SA creation 🔥 When each IKE peer uses a public-private key pair for IKE authentication to create an SA pair, the pair of public keys used (one for each peer) is enough for channel binding. Strongly incorporating this information into higher-layer authentication makes that authentication fail when an MITM attacker has concatenated separate SAs by acting as a traffic-forwarding proxy. 👑

1.3. BTNS Methods 🎀

There are two classes of scenarios in which BTNS may be used to apply IPsec services without network-layer authentication:

  1. Protection of traffic for a higher-layer protocol that does not use authentication. The result is "better than nothing" 🌸 because once an unauthenticated SA is successfully created without an MITM, that SA's IPsec security services resist later MITM attacks. Even though the lack of authentication means the initial creation of the BTNS-based security association (SA) can be subverted by an MITM, the SA still holds up afterwards. This way of using BTNS is called Stand-Alone BTNS (SAB) because it does not rely on any security services outside of IPsec.
  2. Protection of traffic generated by a higher-layer protocol that uses authentication. The "better-than-nothing" protection here depends on the strength of the higher-layer protocol's authentication and on how that authentication is channel bound to the BTNS-based SAs. The level of protection may be comparable to what network-layer IKE authentication gives you, when the higher-layer protocol uses strong authentication and strong channel binding is used to associate the BTNS-based SA with that higher-layer authentication. This way of using BTNS is called Channel-Bound BTNS (CBB) when the combination of higher-layer authentication and channel binding is enough to detect an MITM attack on creation of a BTNS-based SA. 🦋

It is possible to combine IKE authentication for one end of an SA pair with BTNS's absence of network-layer authentication for the other end. The resulting asymmetric authentication creates asymmetric modes of BTNS, which are discussed further in Section 3.2 below. 💜

1.4. BTNS Scope 🌈

The scope of BTNS is to provide a generally useful way of applying IPsec security services that does not require network-level authentication credentials. The following areas are outside this scope and so are not discussed further in this document:

  1. Use of security frameworks other than IPsec to provide security services for higher-layer protocols. There are lots of security service frameworks besides IPsec, like TLS [4], Simple Authentication and Security Layer (SASL) [11], and Generic Security Service Application Program Interface (GSS-API) [10]. There are also plenty of non-IPsec security mechanisms, like TCP MD5 [6], and all of these are described in other documents. BTNS is based on IPsec by design, so it will not always be the most appropriate solution 🙈
  2. Use of the Extensible Authentication Protocol (EAP) for IKE authentication. Section 1.3 of RFC 3748 clearly restricts EAP's applicability to network access protocols [1]:
"EAP was designed for use in network access authentication, where IP layer connectivity may not be available. Use of EAP for other purposes, such as bulk data transport, is NOT RECOMMENDED."

So EAP authentication for IKE only applies to situations where IKE is used to establish network access (e.g., create a Virtual Private Network (VPN) connection). BTNS, on the other hand, is meant to be generally applicable 😭 It covers many areas beyond network access and specifically includes protocols that transfer large amounts of data, such as iSCSI [19] and NFSv4 [21].

  1. Manual keying is not considered for BTNS, because manual keying is unsafe for protocols that transfer large amounts of data (e.g., RFC 3723 forbids use of manual keying with the IP Storage protocols, including iSCSI, for this reason [2]). 🙅‍♀️

1.5. Structure of This Document 🍓

The next section talks about the motivations for BTNS, mainly based on the implications of IKE's requirements for network-layer authentication. Section 3 gives a high-level overview of BTNS, covering both SAB and CBB. It also describes the security services offered and the BTNS modes of operation (based on combinations of SAB, CBB, and/or IKE authentication). Section 4 explores where all of the BTNS modes can be applied. After that comes a discussion of the risks and other security considerations in Section 5. Finally, Section 6 briefly describes other related efforts. ⭐

2. Problem Statement ✨

This section describes the problems that motivated the development of BTNS. The main concern is that IPsec isn't widely used, even though there has been rigorous development effort and a big emphasis on network security from users and organizations. 🥺 People also disagree about which layer is best for securing network communications and how security protocols at different layers should interact. The discussion below roughly sorts these issues by layer: network layer and higher layers.

2.1. Network Layer 🌸

At the network layer, one of the hurdles is satisfying the authentication requirements of IPsec and IKE. This section covers some drawbacks of network-layer authentication and the results of these requirements.

2.1.1. Authentication Identities 🪪

Current IPsec authentication supports several types of identities in the Peer Authorization Database (PAD): IPv4 addresses, IPv6 addresses, DNS names, Distinguished Names, RFC 822 email addresses, and Key IDs [8]. All of them require either certificates or pre-shared secrets to authenticate. The identities the PAD supports can be roughly sorted into network-layer identifiers and other identifiers.

The first three types, IPv4 addresses, IPv6 addresses, and DNS names, are network-layer identifiers. The main problem with IP addresses as identifiers is that they often don't consistently represent the same physical systems, thanks to the growing use of dynamic address assignments (DHCP) and system mobility. DNS names get affected too, because the name-to-address mapping isn't always up to date. Stale mapping information can cause mismatches between the IP address recorded in the DNS for a named system and that system's actual IP address, which causes problems if the DNS is used to cross-check the IP address a DNS name was presented from. Also, DNS names aren't always under the control of the endpoint owner. 😵‍💫

There are two main drawbacks with the other, non-network-layer identifiers defined for the PAD. First, the PAD functionality can be overly restrictive, because there are other forms of identifiers that the PAD specification doesn't cover (EAP does not loosen these restrictions in general; see Section 1.4). Second, using any non-network-layer identifiers for IPsec authentication may result in multiple authentications for the same or different identifiers at different layers. That creates a need to associate the authentications and brings new error cases (e.g., one of two authentications for the same identifier fails). These issues are also related to channel binding and are discussed further later in this document. 🫠

2.1.2. Authentication Methods 🔐

As described earlier, certificates and pre-shared secrets are the only authentication methods accepted by current IPsec and IKE specifications. Pre-shared secrets need manual configuration and out-of-band communication. The verification process for certificates is cumbersome, and there are administrative and potential monetary costs to obtaining them. These factors are among the possible reasons why IPsec isn't widely used outside of environments with the highest security requirements. 💅

2.1.3. Current IPsec Limits on Unauthenticated Peers 🚧

Okay so, pre-configuring SPD "bypass" entries to talk to unauthenticated peers only works if you already know their IP addresses in advance 🙈. The lack of unauthenticated IPsec modes often means you can't get secure communication at the network layer with unauthenticated or unknown peers, even when they get authenticated later on in a higher-layer protocol or application 💀. And there's no channel binding API between IPsec and the higher layers, so those conversations may completely bypass IPsec and leave the network layer totally unprotected 😭. Not it.

2.2. Higher-Layer Issues 🎀

For higher layers, the next subsection looks at whether IPsec is even necessary when transport layer security is already in use 🤔. Using IPsec alongside transport security gives extra motivation to cut down the admin burden of IPsec 💅. After that, we talk about what happens when you do authentication at both the network layer and a higher layer for the same connection (double authentication, the drama 🙃).

2.2.1. Transport Protection from Packet Spoofing 🦋

Let's talk transport protocols 🚚. Faster networks and long-lived connections have made connection-oriented transport protocols more vulnerable to certain attacks 😬. TCP, like lots of other protocols, is susceptible to off-path third-party attacks, such as injecting a TCP RST [24]. The Internet lacks comprehensive ingress filtering to discard this spoofed traffic before it does damage. These attacks can affect BGP sessions between core Internet routers, so they're a big deal [3][12]. As a result, a bunch of proposed solutions have popped up, and most of them live at the transport layer ✨.

Some of these solutions beef up the transport protocol's own security, e.g., TCP MD5 [6]. Others tweak the core TCP processing rules to make it harder for off-path attackers to sneak in meaningful packets, either during the initial handshake (e.g., SYN cookies) or after a connection is established (e.g., TCPsecure) [15][23]. Some of these ideas are new to TCP but have already been put into other transport protocols (e.g., Stream Control Transmission Protocol (SCTP) [22]) or intermediate "layer 3.5" protocols (e.g., Host Identity Protocol (HIP) [14]) 🧚.

TCP MD5 and its potential successor, TCP Auth [25], are based on authentication. TCP-specific modifications that lack authentication are, at best, temporary patches on the ubiquitous spoofing vulnerability 🩹. The obvious solution to spoofing is end-to-end validation of the traffic, either at the transport layer or the network layer. The IPsec suite already authenticates a network-layer packet and its contents, but the costs of the authentication infrastructure IPsec requires can be prohibitive 💸. Similarly, TCP MD5 requires pre-shared keys, which can also be prohibitive. TCP Auth is currently under development and may include a BTNS-like mode 👀.

Protecting systems from spoofed packets is ultimately an authentication issue: making sure a receiver's interpretation of a packet's source is accurate 🎯. Authentication validates the identity of the source of the packet. The current IPsec suite assumes that identity is validated either by a trusted third party (e.g., a certification authority) or by a pre-deployed shared secret 🔐. Such an identity is unique and invariant across associations (pair-wise security configuration), and it can be used to reject packets that aren't authentic.

With regard to BGP in particular, it's been understood that appropriate network- or transport-layer authentication is the preferred protection from TCP spoofing attacks [3]. Authentication at one router by itself doesn't provide overall BGP security, because that router remains at the mercy of all the routers it peers with, since it depends on them to also support authentication [25]. The reality is that few Internet routers are configured to support authentication at all, so BGP packets end up being sent over unsecured TCP 😭. BTNS lets an individual router relax the need for authentication so it can enable protected sessions that aren't authenticated. That's "better than nothing" in cases where "nothing" is the alternative 🌈. The routing community has chosen solutions other than BTNS to protect BGP's TCP connections (e.g., TCP MD5), but BGP still shows up in this document because it motivated the development of BTNS 💜.

2.2.2. Authentication at Multiple Layers 🧩

Some existing Internet protocols provide authentication above the network and transport layers but rely on the IPsec suite for packet-by-packet cryptographic integrity and confidentiality. Examples include iSCSI [19] and the remote direct data placement (RDDP) protocols [16][20] 📦. With the current IPsec suite, you end up with two authentication operations: one at the IPsec layer using an identity for IKE and an associated secret or key, and another by the higher-layer protocol using a higher-layer identity and secret or key 🙃. With the current IPsec specifications, this redundant authentication is necessary because the identity and key formats differ between IPsec and the higher-layer protocol and/or because there's no standard interface to pass authentication results up from IPsec to the higher layer. End-node software is then responsible for making sure the identities used for these two authentication operations are consistent in some fashion, and determining whether they're consistent is an authorization policy decision 🧐.

If the end-node software fails to enforce appropriate consistency across authentication operations at different layers, it creates man-in-the-middle attack opportunities at the network layer 🚨. An attacker can exploit this by interposing as a proxy. Rather than impersonating the attacked endpoints, the attacker only needs to authenticate with identities that are acceptable to those endpoints. That success lets the attacker get full access to the higher-layer traffic by passing the higher-layer authentication operation through without modification 😱. Without any consistency checks on the identities used at different layers, higher-layer traffic may be accessible to any entity that can successfully authenticate at the network layer.

In principle, a single authentication operation should suffice to protect the higher-layer traffic, which removes the need for:

  • the second authentication operation,
  • configuration and management of the identities and secrets or keys for the second authentication (even if the identities and secrets or keys are the same, the two authentication operations may employ different repositories for identities, secrets, and keys), and
  • determining in some fashion that the two authenticated identities are consistent. As noted above, there are significant potential MITM vulnerabilities if this is not done.

IPsec may not always be present for these higher-layer protocols, and even when it is present, it may not always be used. So if there's a choice, higher-layer protocol authentication is preferable, since it will always be available for use, independent of IPsec ✅.

A "better-than-nothing" security approach to IPsec can address this problem by setting up an IPsec security association without an authentication, and then using an extended form of the higher-layer authentication to establish that the higher-layer protocol session is protected by a single IPsec SA. This counters man-in-the-middle (MITM) attacks on BTNS IPsec session establishment by terminating the higher-layer session via an authentication failure when such an attack occurs. The result is that a single authentication operation validates not only the higher-layer peer's identity but also the continuity of the security association to that peer 💖. This higher-layer check for a single IPsec SA is referred to in this document as "channel binding", thus the name Channel-Bound BTNS (CBB) [27].

3. BTNS Overview and Threat Models 🕵️

This section provides an overview of BTNS and the IPsec security services that are offered when BTNS is used. It also describes the multiple operating modes of BTNS.

3.1. BTNS Overview 🌸

This is an overview of what is needed in IPsec to enable BTNS. The detailed specifications of the extensions are addressed by the relevant protocol specifications 📝.

The main update to IPsec is adding extensions to security policy that permit secure communications with unauthenticated peers. These extensions are necessary for both IPsec and IKE. For IPsec, the first extension applies to the PAD, which specifies the forms of authentication allowed for each IKE peer. In addition to existing forms of authentication, such as X.509 certificates and pre-shared secrets, the extension adds an unauthenticated category in which the public key presented by the peer serves as its identity (and is authenticated by the peer demonstrating knowledge of the corresponding private key) [28]. The second extension is that a flag is added to each SPD entry to indicate whether BTNS lack of authentication is acceptable for that SPD entry.

The changes to enable channel binding between IPsec and higher-layer protocols or applications are more complex than the policy extensions above. They require specifying APIs and interactions between IPsec and higher-layer protocols. This document assumes such provisions will be developed, but does not address their details 🙏.

3.2. BTNS and IPsec Security Services ✨

okay so the BTNS changes and extensions mostly hit IPsec policy, which we just covered 🎀. Every other part of the IPsec and IKE specs stays exactly the same, bestie 💅. BTNS doesn't need its own separate IPsec implementation either, because it can plug into whatever IPsec implementation a system already has 🧚. BTNS only applies to the SAs that match PAD policies which explicitly specify or enable a BTNS mode, and where the matching SPD entries allow BTNS. All the other non-BTNS policy entries (in both the SPD and the PAD) and all the non-BTNS SAs are totally unaffected 🫶.

In theory, dropping the requirement that every SA be authenticated means BTNS can set up secure IPsec connections in a way that's kinda similar to fully authenticated IKE. The catch is that BTNS cannot verify or authenticate the peer identities of these SAs 😭. Here's the list of IPsec security services and how BTNS changes each one 👑.

  1. Access Control BTNS extends IPsec's access control services to allow unauthenticated connections. These extensions are built into the IPsec PAD and SPD in a way that doesn't touch the access controls for entries that don't use the BTNS extensions. For Channel-Bound BTNS, the authentication that applies to the SA happens at a higher layer, which links higher-layer access control policy to IPsec's network-layer access control mechanisms 🔐.
  2. Data Origin Authentication Stand-Alone BTNS weakens data origin authentication down to continuity of association. That means you only get the assurance that traffic on an SA keeps coming from the same unauthenticated source 🥺. Channel-Bound BTNS relies on higher-layer authentication to provide data origin authentication of protected network traffic 💜.
  3. Connectionless Integrity
  4. Anti-Replay Protection
  5. Confidentiality
  6. (Limited) Traffic Flow Confidentiality

For the security services in items 3 through 6, it's possible to set up secure IPsec connections with rogue peers via BTNS, because authentication isn't required 💀. BUT once the connection is established, it's protected by these services in the same way as a connection set up with conventional IPsec means. So it's still giving protection, just not identity 🌈.

3.3. BTNS and IPsec Modes 🦋

okay so the previous sections described two ways of using BTNS: Stand-Alone (SAB) and Channel-Bound (CBB) 🍓. Both can also be used symmetrically, where neither party authenticates at the network layer, or asymmetrically, where only one party skips network-layer authentication. There are a bunch of cases to think about, based on combos of the endpoint security capabilities of SAB, CBB, and conventional IKE authentication of an identity (denoted as AUTH below). The tables below show all of the combinations based on the capabilities of the two security endpoints 📊.

           | AUTH  |  SAB  |                | CB-AUTH |   CBB   |
      -----+-------+-------+         -------+---------+---------+
           |       |       |                |         |         |
      AUTH | AUTH  | A-SAB |         CB-AUTH| CB-AUTH |  A-CBB  |
           |       |       |                |         |         |
      -----+-------+-------+         -------+---------+---------+
           |       |       |                |         |         |
      SAB  | A-SAB | S-SAB |           CBB  |  A-CBB  |  S-CBB  |
           |       |       |                |         |         |
      -----+-------+-------+         -------+---------+---------+

        No Channel Binding               With Channel Binding

There are six operating modes that come out of these combos 🎀. The first three use network-layer authentication schemes without channel binding to higher-layer authentication:

  1. AUTH: both parties provide and authenticate conventional, IKE-supported identities.
  2. Symmetric SAB (S-SAB): neither party authenticates with a conventional, IKE-supported identity.
  3. Asymmetric SAB (A-SAB): one party doesn't authenticate with a conventional, IKE-supported identity, but the other side does authenticate with one.

The next three modes combine the network-layer behaviors with channel binding to higher-layer authentication credentials ✨:

  1. CB-AUTH: channel binding is used and both parties authenticate with conventional, IKE-supported identities.
  2. Symmetric CBB (S-CBB): neither party authenticates with a conventional, IKE-supported identity, but channel binding is used to bind the SAs to higher-layer authentication operations.
  3. Asymmetric CBB (A-CBB): asymmetric SAB (A-SAB) used with channel binding. At the network layer, one party doesn't authenticate with a conventional, IKE-supported identity, but the other party does. Channel binding is used to bind the SA to higher-layer authentication operations.

There are three security mechanisms involved in BTNS with channel binding 🧩:

  1. BTNS and IPsec at the network layer,
  2. higher-layer authentication, and
  3. the connection latching plus channel binding mechanisms that bind the higher-layer authentication credentials with the secure IPsec channel.

Authentication at both the network and higher layers can be either bidirectional (both peers are authenticated) or unidirectional (one of the two peers doesn't authenticate) 🔄. In contrast, when channel binding is used, it must be applied at both ends of the communication to prevent MITM attacks 🚨. Existing channel binding mechanisms and APIs for this purpose (e.g., as defined in GSS-API [10]) mandate the exchange and verification of the channel binding values at both ends. That makes sure correct, non-spoofed channel characteristics get bound to the higher-layer authentication 🫶.

Note: When any Stand-Alone BTNS (SAB) or Channel-Bound BTNS (CBB) is used without being qualified as symmetric or asymmetric, the symmetric mode is the intended default meaning. 💅

4. Applicability Statement 🌸

BTNS is intended for services that are open to the public but still need protected associations, and for services that can be authenticated at higher layers in the protocol stack 💖. BTNS can also give some level of protection for private services, when the alternative is BTNS giving no protection at all 🙈.

BTNS uses the IPsec protocol suite, so it should not be used in situations where IPsec, and specifically IKE, is unsuitable. IPsec and IKE add computation overhead, and IKE also needs message exchanges that add round-trip latency to set up security associations. Those things may be undesirable in environments with limited computational resources and/or high communication latencies 🐢.

This section gives an overview of the types of applications that suit the various BTNS modes 🗺️. The next two sections cover the overall benefits and vulnerabilities, followed by the applicability analysis for each BTNS mode. This applicability statement only covers the four BTNS-specific modes. The AUTH and CB-AUTH modes are out of scope for this discussion 🙅‍♀️.

4.1. Benefits 🎁

BTNS protects security associations after they're established, by cutting down vulnerability to attacks from parties that aren't participants in the association 🛡️. BTNS-based SAs protect the network and transport layers without needing network-layer authentication. BTNS can be deployed without pre-deploying authentication material for IPsec or pre-shared information, and it can protect all transport layer protocols using one common mechanism ✨.

BTNS also helps protect systems from low-effort attacks on higher-layer sessions or connections that could disrupt valuable services or resources 👑. BTNS raises the level of effort for many kinds of network- and transport-layer attacks. Simple transport layer packet attacks get rejected, because the malicious packet or packets aren't part of an IPsec SA 🙅‍♀️. The attacker is instead forced to set up an unauthenticated IPsec SA and a transport connection for SAB. That means the attacker has to do as much work as a host engaging in the higher-layer communication 💪. SAB therefore pushes the effort for a DDoS (Distributed Denial of Service) attack up to the level of emulating a flash crowd. For open services, there may be no way to tell such a DDoS attack apart from an actual flash crowd 😭.

BTNS also allows individual security associations to be set up to protect higher-layer traffic, without needing pre-deployed authentication credentials 🔑.

4.2. Vulnerabilities 🥀

BTNS removes the requirement that every IPsec SA be authenticated. Hosts connecting to BTNS hosts are vulnerable to communicating with a masquerader throughout the association for SAB, or until higher layers provide additional authentication for CBB 🎭. As a result, authentication data (e.g., passwords) sent to a masquerading peer could be disclosed to an attacker 😱. This is a deliberate design tradeoff. In BTNS, network- and transport-layer access is no longer controlled by the identity presented by the other host, which opens hosts up to potential masquerading and flash crowd attacks ⚖️. On the flip side, BTNS can secure connections to hosts that can't authenticate at the network layer, so the network and transport layers are more protected than they could be with higher-layer authentication alone 🧡.

Without network-layer authentication information, other means have to be used to provide access control for local resources 🚧. Traffic selectors for the BTNS SPD entries can limit which interfaces, address ranges, and port ranges can access BTNS-enabled services 🎯. Rate limiting can restrict resource usage even further ⏱️. For SAB, these protections need to be considered throughout associations, whereas for CBB they need be present only until higher-layer protocols provide the missing authentication. CBB also relies on how effective the binding of higher-layer authentication to the BTNS network association is 🔗.

4.3. Stand-Alone BTNS (SAB) 🧚

SAB is intended for applications that can't use IKE-compatible authentication credentials and don't employ higher-layer authentication or other security protection 🫠. SAB is also a good fit when the identities of either party aren't important or are deliberately left out, but IPsec security services are still wanted (see Section 3.2) 💜. SAB is especially applicable to long-lived connections or sessions, where assurance that the entity at the other end of the connection hasn't changed may be a good enough substitute for the lack of authentication 💕. This section discusses symmetric and asymmetric SAB ✨.

4.3.1. Symmetric SAB ✨

Okay so, Symmetric SAB (S-SAB) is the move when neither party has network-layer authentication info and higher-layer protocols can't provide auth either 💅. S-SAB can still protect network and transport protocols, but it doesn't give you authentication beyond continuity of association 🫶. It's especially clutch for big file transfers or other long-lived connections that would benefit from not getting interrupted by attacks on the transport connection (like a sneaky fake TCP RST 😭), as long as the particular endpoint identities aren't important.

Open services like web servers and peer-to-peer networks could use S-SAB when their identities don't need to be authenticated but their communication would still benefit from protection 🌸. They might serve files that are either not validated or validated some other way (like published hashes). Those transmissions are a target for off-path attacks, and S-SAB could help mitigate that 🎀. S-SAB may also be useful for protecting voice-over-IP (VoIP) traffic between peers, like direct calls between VoIP clients 📞.

S-SAB is also useful for protecting any transport protocol when the endpoints don't deploy authentication, for whatever reason 🧚. This is the case for BGP TCP connections between core routers. The protection S-SAB gives is better than no protection at all, even though BGP isn't meant to be an open service 💜.

S-SAB can also be an intermediate step towards S-CBB ✨. S-SAB is the effective result when an IPsec channel is used (via connection latching), but the higher-layer authentication isn't bound to the IPsec SAs within the channel.

4.3.2. Asymmetric SAB

Asymmetric SAB (A-SAB) lets one party that lacks network-layer authentication info set up associations with another party that has authentication credentials for any applicable IKE authentication mechanism 🦋.

A-SAB is useful for protecting transport connections for open services on the Internet, like commercial web servers 💖. In these cases, the server is typically authenticated by a widely known CA, the same way TLS works at the application layer, but the clients don't need to be authenticated [4]. Yes, this may mean IPsec and TLS end up on the same connection 🙈. That duplication of security services at different layers is necessary when you need protection from the spoofing attacks described in Section 2. For example, TLS can't prevent a spoofed TCP RST, because the RST is processed by TCP rather than being passed to TLS 💀.

A-SAB can also secure transport for streaming media, like webcasts for remote education and entertainment 🍓.

4.4. Channel-Bound BTNS (CBB)

CBB lets hosts without network-layer authentication info cryptographically bind BTNS-based IPsec SAs to authentication at higher layers 🔥. It's meant for applications that already use higher-layer authentication but also benefit from extra network-layer security 👑. CBB provides network-layer security services without requiring authentication at the network layer. This makes IPsec security services available to applications with IKE-incompatible authentication credentials 🌈. CBB allows IPsec to be used with authentication mechanisms that IKE doesn't support, and it frees higher-layer applications and protocols from duplicating security services that IPsec already provides ✨.

Symmetric CBB integrates channel binding with S-SAB, and asymmetric CBB does the same with A-SAB 🫶. In both cases, the target applications have similar characteristics at the network layer to their non-channel-binding counterparts. The only significant difference is that authentication credentials at a higher layer get bound to the resulting IPsec channels 💅.

Even though the CBB modes refer to network-layer authentication, higher-layer authentication can also be asymmetric (one-way) or symmetric (two-way) 🧠. Asymmetric CBB can complement one-way higher-layer authentication by providing one-way authentication in the opposite direction at the network layer. Imagine an application with one-way, client-only authentication. The client can use A-CBB, where the server must present IKE-authenticated credentials at the network layer. This form of A-CBB achieves mutual authentication, albeit at separate layers 🦋. Many remote file system protocols, such as iSCSI and NFS, fit into this category and can benefit from channel binding with IPsec for better network-layer protection, including prevention of MITM attacks 🛡️.

Mechanisms and interfaces for BTNS channel binding with IPsec are discussed in further detail in [26] 📚.

4.5. Summary of Uses, Vulnerabilities, and Benefits

Here's the recap of the properties of each type of BTNS, based on the previous subsections 📋:

             SAB                          CBB
 --------------------------------------------------------------
 Uses     Open services                Same as SAB but with
          Peer-to-peer                 higher-layer auth.,
          Zero-config Infrastructure   e.g., iSCSI [19], NFSv4 [21]

 Vuln.    Masqueraders                 Masqueraders until bound
          Needs data rate limit        Needs data rate limit
          Load on IPsec                Load on IPsec
          Exposure to open access

 Benefit  Protects L3 & L4             Protects L3 & L4
          Avoids all auth. keys        Avoids L3 auth. keys
                                       Full auth. once bound

Most of the potential vulnerabilities in the table above have been discussed in earlier sections of this document 🙌. Some of the more general issues, like the increased load on IPsec processing, are addressed in the Security Considerations section of this document 🔐.

5. Security Considerations 🔐

This section describes the threat models for BTNS and discusses other security issues based on the threat models for different modes of BTNS 😤. Some of the issues were mentioned earlier in the document, but they're listed again for completeness 🫶.

5.1. Threat Models and Evaluation

BTNS is meant to protect sessions from a bunch of threats, including on-path man-in-the-middle attacks after key exchange, and off-path attacks 🚨. It's intended to protect the contents of a session once it's established, but it does not protect session establishment itself. Even so, this protection has value because it forces the attacker to target connection establishment instead of waiting for a more convenient time. That's especially valuable for long-lived sessions ⏳.

BTNS is not intended to protect the key exchange itself, which leaves an opening for a man-in-the-middle attack or a well-timed attack from other sources 😬. On top of that, Stand-Alone BTNS is not intended to protect the endpoint from nodes masquerading as legitimate clients of a higher-layer protocol or service 🎭. Channel-Bound BTNS can protect against that masquerading, though only at a later point after the security association is established, because a masquerade attack causes a client authentication failure at a higher layer ✨.

BTNS is also not intended to protect against DoS (Denial of Service) attacks that try to overload a CPU doing authentication or other security computations 🥵. BTNS also isn't meant to protect against configuration mistakes. These last two threat assumptions also hold for IPsec 💅.

The following sections discuss the implications of these threat models in more detail 🔍.

5.2. Interaction with Other Security Services

As with any aspect of network security, the use of BTNS must not interfere with other security services 🚫. Within IPsec, the scope of BTNS is limited to the SPD and PAD entries that explicitly specify BTNS, and to the resulting SAD entries 🧩. It's up to system administrators to deploy BTNS only where it's safe. Preferably, BTNS is used as an alternative to "bypass" SPD entries, which exempt specified traffic from IPsec cryptographic protection 🙏. In other words, BTNS should be used only as a substitute for no security, rather than as a substitute for stronger security ⚠️.

BTNS should be used only as a substitute for no security, never as a substitute for stronger security. Read that twice, bestie 💀.

When the higher-layer authentication required for CBB isn't available, other methods, such as IP address filtering, can help reduce SAB's exposure to anonymous access 🛑.

5.3. MITM and Masquerader Attacks

Previous sections described how CBB can counter MITM and masquerader attacks, even though BTNS doesn't protect key exchange and doesn't authenticate peer identities at the network layer 🦹. Still, there are some security issues with CBB that must be carefully evaluated before deploying BTNS 🧐.

With regular IPsec/IKE, a man in the middle can't subvert IKE authentication. So if an attacker tries to attack an IPsec SA by using two concatenated SAs, with the attacker acting as a traffic-forwarding proxy, that causes an IKE authentication failure 🙅‍♀️. On the other hand, a man-in-the-middle attack on IPsec with CBB is discovered later. With CBB, the IKE protocol succeeds because it's unauthenticated, so the security associations do get set up. The man in the middle won't be discovered until the higher-layer authentication fails 😱. There are two security concerns with this approach: possible exposure of sensitive authentication information to attackers, and resource consumption before attacks are detected 🚩.

How much information gets exposed depends on the higher-layer authentication protocols used in applications. If the higher-layer authentication requires exchanging sensitive information (like passwords or password-derived materials) that's directly useful, or that can be attacked offline, an attacker can gain that information even though the attack can be detected 🔑. So CBB must not be used with higher-layer protocols that may expose sensitive information during the authentication exchange 🛑. For example, Kerberos V AP exchanges would leak little other than the target's krb5 principal name. Kerberos V AS exchanges using PA-ENC-TIMESTAMP pre-authentication, however, would leak material that can then be attacked offline 😭. The latter should not be used with BTNS, even with Channel Binding 🙅‍♀️. Further, the ways BTNS is integrated with the higher-layer protocol must take into consideration any vulnerabilities that could be introduced in the APIs between these two systems, or in the information they share 🧱.

The resource consumption issue is addressed in the next section, on DoS attacks 👀.

5.4. Denial of Service (DoS) Attacks and Resource Consumptions ✨

okay bestie, so more BTNS traffic means more crypto math 🧮💅 Every protected packet and every incoming packet that gets verified needs extra computation in IPsec implementations that receive protected traffic and/or verify incoming traffic. 😭 That extra work makes it easier to overload a box, whether it's a legit flash crowd or a DoS or DDoS attack 🌊 Yeah, it could be a real blocker for deployment, but ngl this is an issue for every cryptographically protected communication system, not just this one 🔐 This document does not address the impact BTNS has on such increases in required computation.

The extra resource consumption is kinda two-sided 👑 It raises the level of effort for attacks such as MITM, but it also eats more resources to detect those attacks and to reject spoofed traffic 🙃 At the network layer, proper limits and access controls for resources should be set up for all BTNS SAs. CBB SAs may be granted increased resource access after the higher-layer authentications succeed. The same principles apply to the higher-layer protocols that use CBB SAs. Special care must be taken to avoid excessive resource usage before authentication is established in these applications 🫶

5.5. Exposure to Anonymous Access 🙈

The use of SAB by a service implies that the service is being offered for open access, since network-layer authentication is not performed. So, bestie, SAB should not be used with services that are not intended to be openly available 🌈

5.6. ICMP Attacks 🧚

This document does not consider ICMP attacks because the use of BTNS does not change the existing IPsec guidelines on ICMP traffic handling [8]. BTNS focuses on the authentication part of establishing security associations, and it does not alter the IPsec traffic processing model and protection boundary 💜 As a result, the entire IPsec packet processing guidelines, including ICMP processing, remain applicable when BTNS is added to IPsec ✨

5.7. Leap of Faith 🦋

okay this one is so good 😭 BTNS lets systems accept and establish security associations with peers without authenticating their identities. This can enable functionality similar to "Leap of Faith" authentication used in other security protocols and applications, like the Secure Shell Protocol (SSH) [29].

SSH implementations are allowed to accept unknown peer credentials (host public keys) without authentication, and those unauthenticated credentials may be cached in local databases for future authentication of the same peers. Similar to BTNS, these moves are allowed because there's a lack of "widely deployed key infrastructure" [29], and they make things easier to use and more acceptable to end users 🍓

There are subtle differences between SSH and BTNS when it comes to Leap of Faith, as shown in the following table 👀

                                     |   SSH   |  BTNS   |
      -------------------------------+---------+---------+
       Accept unauthenticated        | Allowed | Allowed |
       credentials                   |         |         |
      -------------------------------+---------+---------+
       Options/Warnings to reject    |   Yes   |   No    |
       unauthenticated credentials   |         |         |
      -------------------------------+---------+---------+
       Cache unauthenticated         |Required | Allowed |
       credential for future refs    |         |         |
      -------------------------------+---------+---------+

SSH requires proper warnings and options in applications to reject unauthenticated credentials, while BTNS accepts those credentials automatically when they match the corresponding policy entries 🤖 Once SSH accepts a credential for the first time, that credential should be cached and can be reused automatically without further warnings. BTNS credentials can be cached for future use too, but there's no security advantage to doing so, because a new unauthenticated credential that is allowed by the policy entries will be automatically accepted anyway 🙃

In addition, BTNS does not require IPsec to reuse credentials the way SSH does. When IPsec does reuse unauthenticated credentials, there may be implementation advantages to caching them 💅

SSH-style credential caching for reuse with SAB could be addressed by future extension(s) to BTNS. Those extension(s) would need to provide warnings about unauthenticated credentials and a mechanism for user acceptance or rejection of them, so they can reach a level of authentication assurance comparable to SSH's "Leap of Faith" 🧐 They would also need to deal with issues caused by the absence of identities in BTNS. At best, a cached BTNS credential reauthenticates the network-layer source of traffic when the credential is reused. SSH credential reuse, on the other hand, reauthenticates an identity 🪞

Network-layer reauthentication for SAB is further complicated by:

  • the ability of NATs to cause multiple independent network-layer sources of traffic to appear to be one source (potentially requiring acceptance and caching of multiple BTNS credentials),
  • the ability of multihoming to cause one network-layer source of traffic to appear to be multiple sources (potentially triggering unexpected warnings and requiring re-acceptance of the same BTNS credential), and
  • interactions with both mobility and address ownership changes (potentially requiring controlled BTNS credential reassignment and/or invalidation).

These issues are left to be addressed by possible future work on adding "Leap of Faith" functionality to BTNS 🔮

In contrast, for CBB, credential caching and verification are usually done at the higher-layer protocols or applications. Caching credentials for CBB at the BTNS level isn't as important, because the channel binding will bind whatever credentials are presented (new or cached) to the higher-layer protocol identity 🎀

5.8. Connection Hijacking through Rekeying 🕵️‍♀️

Each IPsec SA has a limited lifetime (defined as a time and/or byte count) and must be rekeyed or terminated when the lifetime expires. Rekeying an SA opens a small window of opportunity where an on-path attacker can step in and hijack the new SA created by rekeying, by spoofing the victim during the rekey 😱 BTNS, and especially SAB, makes this attack easier by removing the need for the attacker to authenticate as the victim, or to use the same non-BTNS PAD entry that the victim used for the original SA. CBB, on the other hand, can detect such attacks by noticing changes in the secure channel properties 🚨

This vulnerability comes from the lack of inter-session binding or latching of IKE SAs with the corresponding credentials of the two peers. Connection latching, together with channel binding, enables such binding, but it requires higher-layer protocols or applications to verify consistency of identities and authentication across the two SAs 💖

5.9. Configuration Errors ⚙️

BTNS does not address configuration errors that could result in increased vulnerability. That kind of vulnerability is already possible using "bypass" SPD entries 🙄 SPD entries that allow BTNS must be explicitly flagged, so they can be kept separate from SPD entries that do not allow BTNS, just as "bypass" SPD entries are kept separate from entries that create SAs with more conventional, stronger security 🧩

There have been a number of related efforts in the IETF and elsewhere to reduce the configuration effort of deploying the Internet security suite. It's giving teamwork, honestly 👑

The IETF PKI4IPsec effort focused on providing an automatic infrastructure for configuring Internet security services, e.g., to help deploy signed certificates and CA information [9]. The IETF KINK effort focused on adapting Kerberos [13] for IKE, letting IKE use the Kerberos key distribution infrastructure rather than requiring certificates or shared private keys [18]. KINK takes advantage of an existing architecture for automatic key management in Kerberos 🔑 Opportunistic Encryption (OE) is a system for automatic discovery of hosts willing to do a BTNS-like encryption, with authentication exchanged by leveraging existing use of the DNS [17]. BTNS is different from all three, though, because it's meant to avoid the need for that infrastructure altogether, rather than automating it 🦋

7. Acknowledgments 🫶

This document was inspired by discussions on the IETF TCPM WG about the spoofed RST attacks on BGP routers and various solutions, as well as discussions in the NFSv4 and IPS WGs about how to better integrate with IPsec 🌈 The concept of BTNS came out of these discussions, as well as discussions with USC/ISI's T. Faber, A. Falk, and B. Tung, and discussions on the IETF SAAG (Security Area open meeting) mailing list and the IPsec mailing list. The authors would like to thank the members of those WGs and lists, as well as the IETF BTNS BOFs and WG and its associated ANONsec mailing list (http://www.postel.org/anonsec) for their feedback. A special shoutout to Steve Kent, Sam Hartman, Nicolas Williams, and Pekka Savola 💜

This document was prepared using 2-Word-v2.0.template.dot. 💅

8. Informative References 📚✨

okay bestie, these are the receipts 🧾 the spec leans on for background. if you want the full story behind any of them, this is your reading list 🫶

  • [1] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
  • [2] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, April 2004.
  • [3] CERT Vulnerability Note VU#415294, "The Border Gateway Protocol relies on persistent TCP sessions without specifying authentication requirements", 4/20/2004.
  • [4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
  • [5] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
  • [6] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
  • [7] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
  • [8] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
  • [9] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007.
  • [10] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
  • [11] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
  • [12] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006.
  • [13] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
  • [14] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
  • [15] Ramaiah, A., R Stewart, M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", Work in Progress, January 2008.
  • [16] Recio, R., Metzler, B., Culley, P., Hilland, J., and D. Garcia, "A Remote Direct Memory Access Protocol Specification", RFC 5040, October 2007.
  • [17] Richardson, M. and D. Redelmeier, "Opportunistic Encryption using the Internet Key Exchange (IKE)", RFC 4322, December 2005.
  • [18] Sakane, S., Kamada, K., Thomas, M., and J. Vilhuber, "Kerberized Internet Negotiation of Keys (KINK)", RFC 4430, March 2006.
  • [19] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.
  • [20] Shah, H., Pinkerton, J., Recio, R., and P. Culley, "Direct Data Placement over Reliable Transports", RFC 5041, October 2007.
  • [21] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003.
  • [22] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
  • [23] TCP SYN-cookies, http://cr.yp.to/syncookies.html
  • [24] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, July 2007.
  • [25] Touch, J., A. Mankin, R. Bonica, "The TCP Authentication Option", Work in Progress, November 2007.
  • [26] Williams, N., "IPsec Channels: Connection Latching", Work in Progress, April 2008.
  • [27] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
  • [28] Williams, N. and M. Richardson, "Better-Than-Nothing Security: An Unauthenticated Mode of IPsec", RFC 5386, November 2008.
  • [29] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.

Authors' Addresses 💌🦋

these are the girlies who wrote it, so you know where to send the thank-you notes 💖

Joe Touch
USC/ISI
4676 Admiralty Way
Marina del Rey, CA 90292-6695
U.S.A.

Phone: +1 (310) 448-9151
EMail: touch@isi.edu


David L. Black
EMC Corporation
176 South Street
Hopkinton, MA 01748
USA

Phone: +1 (508) 293-7953
EMail: black_david@emc.com


Yu-Shun Wang
Microsoft
One Microsoft Way
Redmond, WA 98052
U.S.A.

Phone: +1 (425) 722-6980
EMail: yu-shun.wang@microsoft.com

and that's a wrap on the whole doc 🎀 you made it all the way through, bestie, we're so proud of you 🌈👑

📦 where this page comes from