[Cryptography] Two quick questions about IPsec AH

[William Allen Simpson]

On 1/11/22 2:44 AM, Tero Kivinen wrote:
> Phillip Hallam-Baker writes:
>> IPSEC as specified in the RFCs was simply unusable because it didn't work
>> through NAT. The IPSEC authentication included the source address and that
>> caused connections to fail through NAT boxes.
> 
> (Btw, correct spelling is IPsec, not IPSEC).
> 

Agreed.

> And you are mixing things here. AH (authentication header) tries to
> authenticate headers, thus it does include source and destination
> addresses in the authentication (they are part of the headers).
> 
> I.e., the fact that it detects someone modifying the headers is
> feature not a bug, and as NATs modify those headers it will detect
> those as attacks.
> 

Correct.

> ESP on the other hand does NOT include source or destination address
> in the integrity check value calculations thus do not care that source
> or destination addresses changes. So ESP works fine through NATs, but
> the problem is that NATs to other things than just change source and
> destination addresses.
> 

A bit more history: the actual SIP[P] designers were never anti-NAT.
Paul Francis was one of us, and an originator of NAT.  My PIPE
featured NAT/firewall traversal, as did Paul's PIP.  That's what
made it polymorphic.

[PIPE = my practical internet protocol extensions; SIP = Steve's simpler
internet protocol; PIP = Paul's polymorphic internet protocol;
SIPP = SIP plus PIP]

One of the given reasons for site local addresses was supporting an
explicit security boundary.

IP addresses should never be used as a method of authentication.  SIP[P]
globally routable addresses were required to change regularly in my
original address assignment drafts.  I'm fairly certain we eventually got
that back into the IPv6 RFCs, although it took some years.

Photuris also featured automated firewall traversal, and treated NAT as an
instance of firewall.


> Another issue with NATs is that they do not know to which device the
> ESP packets coming back from the network should be passed to, i.e. as
> normally NATs multiplex data based on the port numbers, and ESP
> packets do not have port numbers, thus NAT does not know to which
> internal node this incoming ESP packet needs to be sent to. The ESP
> packets do include SPI value which could be used to multiplex data
> back to original host, but the problem is that NAT does not know which
> SPI is used by which internal host.
> 

By definition, SPIs are per destination.

My original Neighbor Discovery and Router Discovery specifications
never assigned any globally routable address until the node was
authenticated via the link local address.  Therefore, every
firewall/NAT/router already knew the mapping between local and globally
routed addresses, and maintained the list of SPIs per destination.

I still painfully remember the screaming in the DHCP WG over every
device needing to authenticate.  (Nobody should be able to drop a
device into my network without some kind of permission.)  They
claimed it would be impossible to manage.

Of course, security folks knew that was a requirement.  Assigning a
globally routable address to every [lightbulb, toaster, TV] is a
terrible idea.  My lightbulbs should not be talking outside the house.
The firewall should prevent it.  Policy should specify which devices
are accessible.

Photuris automated firewall traversal simply built a tunnel.  An outer
ESP layer to the firewall, with an inner ESP layer end-to-end.  This
supported IPv6 on the outside with IPv4 on the inside.

That is, we'd already discussed and solved all these problems.

Later ignorant WG editors broke them.


>> So I rather doubt EH is used because I doubt any of the kludges were
>> implemented for anything besides ESP. And besides which, there is a null
>> cipher for testing and for environments where you want authentication but DO
>> NOT want encryption (this is very common in SCADA deployments and for
>> excellent reasons)
> 
> ENCR_NULL is not only for testing, it is also in situations where you
> do not want to do encryption (for example if traffic is already
> encrypted, so there is no point of encrypting it second time), but do
> want to do integrity and authentication checking.
> 
> Because of this reason the ENCR_NULL is still MUST for ESP in the
> RFC8221.

IMnsHO, NULL encryption is evil, and should never have been allowed in the
specification -- even for testing.  For me, that was the last straw.

There's nothing wrong with multiple layers of encryption.  I encourage it.