32

I can't seem to get a straight answer to this quesion. Wikipedia says "IPsec is an integral part of the base protocol suite in IPv6," but does that mean that ALL communications are always encrypted, or does it mean that encryption is optional, but devices must be able to understand it (should it be used)?

If encryption is optional, is it the operating system that decides whether to use encryption, or is it the application? Do popular operating systems and software generally enable encryption?

I would investigate this myself, but I lack IPv6 connectivity.

Update: Ok, so it's optional. My follow-up question: typically, is it the application that defines whether to use encryption, or is it the operating system?

A specific example: Imagine I have a recent version of Windows with native ipv6 support, and I search for something on ipv6.google.com using Mozilla Firefox. Would it be encrypted?

2
  • 17
    IPSec is like a lock on a door; it might be part of the door, but it doesn't mean the door is necessarily locked.
    – Chris S
    Apr 18, 2011 at 17:06
  • @Chris S: Awesome comment, you have my up-vote for that. Apr 19, 2011 at 1:42

4 Answers 4

31

No.

IPv6 has IPsec built-in as part of the protocol, and it's not a bolt-on as it is with IPv4. However, this doesn't mean it's enabled by default, it just means it's a (theoretically) lower overhead on the network stack.

Generally, IPsec usage is determinated at the IP-level of the network stack, and therefore determined by the system policies itself. e.g. System A might have a policy that requires both AH and ESP to have any communication with the 4.0.0.0/8 subnet.

Update: to be clear, the application doesn't care - it just knows it has to open a network connection somewhere and send/receive data down it. The system then has to figure out whether to negotiate IPsec for the given requested connection. IPsec is very much designed to be a low-level authentication/encryption mechanism and is purposefully built so that higher-level protocols and applications don't have to worry about it.

That said, it's just another network-level security control, and shouldn't necessarily be used in isolation or relied upon to guarantee 'security' - if you're trying to solve and authentication problem, it's entirely possible that you'd want the application to enforce some sort of user-level authentication whilst leaving machine-level authentication down to IPsec.

3
  • 1
    Thank you for clearly dismissing a horribly popular myth.
    – Marcin
    Apr 18, 2011 at 17:45
  • 3
    Oh, the things that could have been. Maybe we'll get this in IPv8 in a few hundred years. Sep 1, 2012 at 8:52
  • 1
    I disagree - encryption should always be possible, and at best, very easy. Mandating a certain type of security control regardless of the existence of other controls is a little short-sighted with regards to the use cases where you actively don't want IP-level encryption.
    – growse
    Sep 1, 2012 at 9:29
20

Short answer: No.

Long answer: IPsec was considered when designing IPv6, in the sense that, unlike in IPv4, IPsec (when used) is part of the IPv6 header.

More explanation: in IPv4, IPsec runs on top of IP itself. It's actually a Layer 4 protocol that 'masquerades' as a Layer 3 protocol (so that the usual L4 protocols of TCP and UDP will still be able to work). The ESP (Encapsulating Security Payload) cannot span between IP packets. As a result, IPsec packets usually will have severely reduced payload capacity if fragmentation is prevented. Plus, because it's on top of IP, IP's header is not protected.

In IPv6, IPsec is part of IP itself. It can span packets, since the ESP header is now a part of IP's header. And because it's integrated with IP, more parts of the IP header can be protected.

I hope my 'in a nutshell' explanation is clear enough.

1
  • 1
    Actually, AH signs the entire packet, meaning nothing can be changed (i.e. NAT breaks it.) This is why very few IPSec tunnels actually use AH. And it's one of many extension headers, not literally "part of IP's header."
    – Ricky
    Feb 11, 2016 at 2:07
2

To you Followup Question:

The operating system defines when to use encryption. These "policy" options are within control panels / configuration policies. You say things like "if you want to connect to any address in subnet ab12:: you must have secret Blah1234". There are options to use PKI.

At the moment an application cannot add to this policy or demand this policy is set up. There is a mention in the linux socket ipv6 section "IPSec support for EH and AH headers is missing. " so people have thought of this but there is currently no known working implementations.

1

To your followup question yes and no.

Applications can specify encryption, but the encryption is done at the application level. There are a wide variety of unencrypted/encrypted protocol pairs using different ports such as HTTP/HTTPS, LDAP/LDAPS, IMAP/IMAPS, and SMTP/SSMTP. These all use SSL or TLS encryption. Some services will offer a startTLS option which allow an encrypted connection to be started on the normally unencrypted port. SSH is an application which always uses an encrypted connection. Encryption is end to end for these cases. (There is a NULL encryption algorithm which can be used, and the encrypted content will be transported unencrypted.)

IPSEC is configured by the administrator and the application will not be aware whether or not the connection is encrypted. I have mainly seen IPSEC used to bridge traffic between LANs over unsecured connections (VPN connections). I believe IPSEC may apply to only part of the route, so on some network segments the data is transmitted in the clear (unencrypted).

Given a choice I will use application encryption as network encryption is not heavily used.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .