Ethereum's stacks open a transport session and then agree, inside that session, which protocols run over it and how the channel is protected. Each stack makes these choices once; the protocol pages build on them.
Protocol negotiation
The execution stack negotiates capabilities in the RLPx Hello message: both
peers list the capability name-version pairs they support, and a capability is
usable only when both sides announced the same name and version.
The consensus stack uses multistream-select 1.0 over its libp2p connections. Clients MUST use exact equality when negotiating protocol versions to use and MAY use the version to give priority to higher version numbers. Clients MUST support multistream-select 1.0 and MAY support multiselect 2.0 when it solidifies; once every client implements 2.0, multistream-select 1.0 MAY be phased out.
Secure channels
The execution stack authenticates and encrypts every RLPx session with its ECIES handshake: a TCP connection followed by an agreement on ephemeral key material for further encrypted and authenticated communication.
The consensus stack secures each transport differently. QUIC connections use
TLS 1.3, configured according to the libp2p TLS specification. The TCP
fallback uses the libp2p-noise secure channel with secp256k1 identities;
clients MUST support the XX handshake pattern.
The stack pages state the full transport contracts; this page names the concepts they share.