Subject: [Hipsec] Teaching NATs to understand SPIs?

From: [email-masked] (Pekka Nikander)
Date: Tue Dec 16 10:07:01 2003

[While this is strictly out-of-topic at the mobike mailing
  list, I am sending this message to both mobike and hipsec
  mailing list.  To mobike since there has recently been
  quite a lot of discussion about the complications of IPsec
  NAT-T and mobility, and to the hipsec mailing list since
  the HIP folks have been discussing various SPI-based NAT
  traversal issues already for a few years.  Please use
  your own judgement on where to send replies.]

In the HIP community, there has been a desire to make
HIP to work through NATs for quite some time.  Recently
this work has been proposed to be outside of any WG work,
but that there would be an item for this at the IRTF side.
[The intention is that there would be a HIP WG and a
HIP-related but wider RG.  The RG would study both HIP and
other issues related to identifier/locator splitting.]

The current HIP approach is based on the idea that the
key management protocol sends the SPIs in clear text,
thereby allowing knowledgeable NAT boxes to create
mappings between HIP Host Identifiers and <IPaddr, SPI>
pairs.  Technically, that would allow a NAT box to
create HIP-connection specific mappings on the fly, and
to NAT directly ESP instead of requiring UDP tunneling.
There has also been the idea that the public key signatures
in HIP packets could be used to verify the any changes
in this mapping, caused by mobility.  However, those ideas
are less baked:  doing PK verification at a NAT box may
be too expensive, in HIP only the responder's public
key becomes public information while the initiator's
public key can be kept hidden (not sent in clear text
in key exchange), etc.  Some people are looking at
alternatives.

Now, the real question is whether it is sufficient that
these issues are studied in an IRTF RG, or if there
is sufficient interest to start a working group on the
issue?

Basically, I see at least two options:

   1. Let the proposed HIP-related IRTF RG to initially
      tackle this problem space, and wait until we see
      if there comes out anything usable.

   2. Try to run a BOF in Seoul or San Diego, and form
      a WG to solve the problem on how to teach NAT
      boxes to understand SPIs and create SPI based
      mappings instead of using UDP encapsulation.

Maybe there are others that I am not aware of, or other
people working on the area.  If so, I'd very much
would like to know.

--Pekka Nikander

---

From: [email-masked] (James Kempf)
Date: Tue Dec 16 13:58:01 2003

I think the intent of NSIS is that it will be a protocol for communicating
with general middleboxes. MIDCOM was supposed to do this as well near term,
I think they decided to use SNMP, don't know where they are at.

            jak

----- Original Message ----- 
From: "Pekka Nikander" <[email-masked]>
To: "MOBIKE Mailing List" <[email-masked]>;
<[email-masked]>
Sent: Tuesday, December 16, 2003 7:43 AM
Subject: [Mobike] Teaching NATs to understand SPIs?

> _______________________________________________
> Mobike mailing list
> [email-masked]
> https://www.machshav.com/mailman/listinfo/mobike
>

---

From: [email-masked] (Jari Arkko)
Date: Tue Dec 16 15:18:01 2003

> I think they decided to use SNMP, don't know where they are at.

I'm scared about the kind of discovery, deployment, and security
considerations that would apply to the use of SNMP from clients
to middle boxes. But I confess I know nothing at all about MIDCOM,
so maybe their solution is good and takes care of all the
considerations. I guess I need to read about MIDCOM and NSIS
to learn more...

The rest of this e-mail is about history, and 20-20 hindsight
into decisions that were taken years ago.

It is fascinating to think about how we must have ended
up with the current state of the art.

It must have been a small, almost insignificant design
decision: put the IKE SPIs in the encrypted part of the
packet. That's where all the other parameters go, so its
logical. Yet this turns out to have a significant impact
on what NATs could do about IPsec -- perhaps it even made
an impact to how fast IPsec got deployed, since NATs
were a problem for some time. And it continues to have
an impact today, in the form of extra UDP tunneling that
is needed.

Why does the SPI location matter? Because if the SPIs are
hidden, the NAT box does not know how to create a mapping.
This would not be such a big problem if the NAT box could
learn the SPIs on the fly, but the fact that the SPIs are
different in each direction prevents this. Note: there
was no security reason to prevent the SPIs from being
exposed, as they are in any case visible in ESP & AH.

I wonder what kind of protocols and NAT devices we would
have today if the SPIs had been outside the encrypted part?

I don't want to claim that a cleartext SPI would have solved
all problems. It would certainly work only for those NAT
devices that were co-operative. I have a feeling that some
fraction NATs are of a more evil sort, the get-yourself-a-more-
expensive-subscription-if-you-want-servers-or-vpns type...

Similar considerations may apply to protocols that carry
other data than SPIs, such as RTP port numbers.

--Jari