IPsec NULL Encryption & NULL Authentication

Have you ever wanted to test an IPsec tunnel but wanted to see the packets in clear text instead of all those encrypted gibberish stuff? One of the ways and to me the easiest one is to use NULL encryption. In this post we will see how we can leverage this no encryption method. Below is our topology.

NULL-encryption-topology

We will first enable NULL encryption and then see what it means practically for us. I am not sharing entire config but only show what we need to enable this.

[edit]
admin@srx2# show security ipsec proposal LAB1007 
protocol esp;
authentication-algorithm hmac-sha1-96;
lifetime-seconds 10000;

Yes that is it! We have enabled NULL encryption. Setting NULL encryption means actually not setting any encryption-algorithm under IPsec proposals. If you leave it empty, your ESP encapsulated packets won’t be encrypted. You don’t believe me? Let me show you.

admin@srx2> show security ipsec security-associations vpn-name LAB1007 detail 
  ID: 131074 Virtual-system: root, VPN Name: LAB1007
  Local Gateway: 10.10.100.2, Remote Gateway: 192.168.18.2
  Local Identity: ipv4_subnet(any:0,[0..7]=1.1.1.0/24)
  Remote Identity: ipv4_subnet(any:0,[0..7]=2.2.2.0/24)
  Version: IKEv1
    DF-bit: clear
    Bind-interface: st0.1156

  Port: 500, Nego#: 1, Fail#: 0, Def-Del#: 0 Flag: 0x600a29 
  Last Tunnel Down Reason: SA not initiated
    Direction: inbound, SPI: 210c86ce, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 7171 seconds
    Lifesize Remaining:  Unlimited
    Soft lifetime: Expires in 6533 seconds
    Mode: Tunnel(0 0), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: NULL    <--- NULL Encryption
    Anti-replay service: counter-based enabled, Replay window size: 64

    Direction: outbound, SPI: 6ed44942, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 7171 seconds
    Lifesize Remaining:  Unlimited
    Soft lifetime: Expires in 6533 seconds
    Mode: Tunnel(0 0), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: NULL    <--- NULL Encryption
    Anti-replay service: counter-based enabled, Replay window size: 64

Now I hope you believe me now. Still don't? Let me show you then in wireshark. First send ping PC2 from PC1 and capture ESP traffic on the wire.

PC1>ping 10.10.100.10 -c 1
PING 10.10.100.10 (10.10.100.10) 56(84) bytes of data.
64 bytes from 10.10.100.10: icmp_seq=1 ttl=62 time=20.0 ms

--- 10.10.100.10 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 20.036/20.036/20.036/0.000 ms

Below is the screenshot of the captured traffic.

NULL-encyption-ESP-traffic-decrypt1

but we still see the ESP payload and nothing in clear text. The trick is that we must tell Wireshark to decode this NULL encrypted payload. As you can see in the following screenshot under protocol preferences, you can do this.

NULL-encryption-attempt-to-decode-2

and finally we have the clear text ICMP traffic. We can clearly see the inner IP header and payload. This is really cool if you want to troubleshoot ESP packets.

NULL-encryption-3

The title of the post also mentions about NULL authentication Actually the method to enable NULL authentication is also similar to NULL encryption but with a trick. If you want to disable authentication, then it is sufficient not to set the authentication as below.

[edit security ipsec proposal LAB1007]
admin@srx2# show 
protocol esp;
encryption-algorithm 3des-cbc;
lifetime-seconds 10000;
admin@srx2# run show security ipsec security-associations vpn-name LAB1007 detail 
  ID: 131074 Virtual-system: root, VPN Name: LAB1007
  Local Gateway: 10.10.100.2, Remote Gateway: 192.168.18.2
  Local Identity: ipv4_subnet(any:0,[0..7]=1.1.1.0/24)
  Remote Identity: ipv4_subnet(any:0,[0..7]=2.2.2.0/24)
  Version: IKEv1
    DF-bit: clear
    Bind-interface: st0.1156

  Port: 500, Nego#: 1, Fail#: 0, Def-Del#: 0 Flag: 0x600a29 
  Last Tunnel Down Reason: SA not initiated
    Direction: inbound, SPI: 7aa8aedd, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 9949 seconds
    Lifesize Remaining:  Unlimited
    Soft lifetime: Expires in 9311 seconds
    Mode: Tunnel(0 0), Type: dynamic, State: installed
    Protocol: ESP, Authentication: None, Encryption: 3des-cbc          <--- No authentication
    Anti-replay service: counter-based enabled, Replay window size: 64

    Direction: outbound, SPI: 99bf1ce7, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 9949 seconds
    Lifesize Remaining:  Unlimited
    Soft lifetime: Expires in 9311 seconds
    Mode: Tunnel(0 0), Type: dynamic, State: installed
    Protocol: ESP, Authentication: None, Encryption: 3des-cbc
    Anti-replay service: counter-based enabled, Replay window size: 64

but did you notice this time, I have enabled encryption. The trick is you can't disable both. You can but if you do, IPsec assigns the default encryption method 3des and default authentication sha1.

I have found the answer in RFC2401 from which I have quoted the relevant text.

Note that if ESP is specified, either (but not both) authentication
or encryption can be omitted. So it MUST be possible to configure
the SPD value for the authentication or encryption algorithms to be
"NULL". However, at least one of these services MUST be selected,
i.e., it MUST NOT be possible to configure both of them as "NULL".

I believe IPsec is easier once you know about NULL encryption. If you want to read Juniper documentation about this see the following:
http://www.juniper.net/techpubs/en_US/junos12.1/topics/usage-guidelines/services-configuring-ipsec-proposals.html

You find this method cool, then let me know!

About: rtoodtoo

Worked for more than 10 years as a Network/Support Engineer and also interested in Python, Linux, Security and SD-WAN // JNCIE-SEC #223 / RHCE / PCNSE


2 thoughts on “IPsec NULL Encryption & NULL Authentication”

  1. Pretty cool stuff, definitely useful for when in the lab. Don’t know how well that would go over if you were doing it over the internet with production data though. Maybe you could use it to get the tunnel up and just verify data is transversing correctly before putting in real data. I went in search for other reasons you might want to do this. RFC2410 (so close to the one you mentioned, so I had to double check) goes over the NULL encryption as well and makes it seem like you can make it act just like AH but within ESP and that it is faster than AH. Another post here https://routingfreak.wordpress.com/tag/esp-null/ basically says the same thing and that AH should be retired. I don’t see that happening, but cool to see you can do this.

    1. Thanks for reference to the RFC2410. It was really missing in this post. Actually in my opinion with the right configuration you can try NULL encryption without interrupting production traffic. For example, if a test is to be done between two protected end points, than a new /32 proxy-id SA would be brought up and through this new tunnel, ESP traffic could be tested.
      I haven’t tested this but I think it should work. It would be really useful to test high CPU issues or encryption related performance degradation.
      This would probably require FBF (policy based routing too) to handle routing part.

      Thanks for the valuable feedback, appreciated.

      Genco.

Leave a Reply to jbrantley39Cancel reply

Discover more from RtoDto.net

Subscribe now to keep reading and get access to the full archive.

Continue reading