Subject: [Hipsec] Updating moskowitz-hip-07: IPv4 pseudo header

From: [email-masked] (Henderson, Thomas R)
Date: Sun Sep 28 18:55:01 2003

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]]
> Sent: Friday, September 05, 2003 3:20 AM
> To: [email-masked]
> Subject: [Hipsec] Updating moskowitz-hip-07: IPv4 pseudo header
> >=20
> I propose that we change the text as follows:
>=20
>     In case of using IPv4, the IPv4 UDP pseudo header format [RFC768]
>     is used.  In the pseudo header, the source and destination
>     addresses are those used in the IP header, the zero field is
>     obviously zero, the protocol is the HIP protcol number (TBD),
>     and the length is calculated as in the IPv6 case.
>=20
> This would require a small change to the current implementations.
>=20
> Opinions?
>=20
>

Another option may be to leave out the IP addresses from the IPv4=20
HIP checksum (that's what HIP is all about, right? :).   =20

Otherwise, I'm fine with the proposed change.  I think that =
realistically
we should expect to tunnel HIP over UDP for IPv4 NAT traversal, in which
case the HIP checksum might be redundant, but if it comes to pass that
IPv4 NATs are HIP aware, it is reasonable to either a) make the
checksum rewriting the same as TCP/UDP or b) do not require them to=20
rewrite checksums by avoiding the pseudoheader construct or by using
dummy addresses in the pseudoheader. =20

Option b) might be more NAT friendly if the deployed base of NATs is=20
able to handle non TCP/UDP traffic by simply manipulating the IP header, =

but I suspect that even avoidance of layer 4 manipulation will not be=20
sufficient to get through many legacy NATs. =20

Tom

=20

---

From: [email-masked] (Pekka Nikander)
Date: Mon Sep 29 05:55:01 2003

> Another option may be to leave out the IP addresses from the IPv4 
> HIP checksum (that's what HIP is all about, right? :).    

Well, I would not be willing to remove a feature that is present
in all protocols that run over IP.  (At least AFAIK; there may be
protocols that do not have a CRC.)  Even though packet corruption
is very rare with current link and router technologies, it does
happen.  I'd rather drop a packet on a CRC check than to proceed
and perhaps try to solve a very hard cookie before giving up.

> Otherwise, I'm fine with the proposed change. 

OK, I will take this as a resolution for Issue 10a.
We will use [RFC768] pseudo header format for HIP
packets carried over IPv4.

> I think that realistically
> checksum rewriting the same as TCP/UDP or b) do not require them to 
> dummy addresses in the pseudoheader.  

Now, carrying HIP over UDP is an interesting question.  As I showed
in my recent half-joke
http://honor.trusecure.com/pipermail/hipsec/2003-September/000044.html
it might be possible to run HIP masquareded as UDP, i.e., use UDP as
the protocol number and then use "magic" port numbers to recognized
that it is actually HIP.  That is admittedly a hack.

However, if we consider the situation more realistically, we do not
need all fields from the HIP header if we run HIP over UDP.  Instead,
the result might look somewhat like the following:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Source port           |       Destination port        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Length              |              CRC              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       HIP Controls            | HIP pkt Type  | Ver.  |  Res. |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Hence, the overhead caused by UDP would be just 4 bytes.
Maybe we should specify that when you run HIP over IPv6, you use
the extension header format, but when you run HIP over IPv4, you
would carry it over UDP?  Doesn't look like too hard to implement.

Opinions?

> Option b) might be more NAT friendly if the deployed base of NATs is 
> able to handle non TCP/UDP traffic by simply manipulating the IP header, 
> but I suspect that even avoidance of layer 4 manipulation will not be 
> sufficient to get through many legacy NATs.  

Agreed.

--Pekka

---

From: [email-masked] (Andrew McGregor)
Date: Mon Sep 29 06:21:00 2003

> packets carried over IPv4.

This sounds a lot like the right thing.

> the result might look somewhat like the following:

Let's try it and see, shall we?  It's almost trivial for me, so I'll have a 
go before Minneapolis and try it with a few NATs.

Andrew

---

From: [email-masked] (Pekka Nikander)
Date: Mon Sep 29 06:40:01 2003

Andrew McGregor wrote:
> Let's try it and see, shall we?  It's almost trivial for me, so I'll 
> have a go before Minneapolis and try it with a few NATs.

Ok.  We'll implement it as well.  Port number?  Would that 272 be fine?
I'll add the format as an appendix to -08.  I think it is best to use
the same port for both source and destination.

I could add it to -08, and we could apply for the port from IANA,
if the thing works.

--Pekka Nikander

---

From: [email-masked] (Tim Shepard)
Date: Mon Sep 29 08:18:00 2003

> the same port for both source and destination.

If I understand correctly, the purpose of using UDP is to make HIP
work when you are behind a NAT.  But if you specify what port numbers
you use, then are you precluding being able to use HIP from behind a
NAT on more than one host?

I though I knew how NATs usually handled UDP ports, but now your
message has me wondering.  If the NAT is going to rewrite the source
port on outgoing packets, and use the destination port on incoming
packets to determine the ultimate destination (just like what NATs do
with TCP), then we're going to need a way to tell the other end not
just what IPv4 addresses we can be reached at, but also what IPv4
addresses and UDP port numbers we can be reached at.  But how can you
when you are behind a NAT learn what these are?  Or will it just be
implicit that if you receive a packet from a UDP port number at some
IPv4 address, then we assume that the far end is behind a NAT and add
that to their list of addresses.  (Or perhaps even send them a helpful
message saying "I heard you at IPv4 address foo UDP port bar.")

If the NAT isn't rewriting the UDP port numbers but instead uses
memory of recent outbound UDP traffic to decide how to route the
incoming UDP traffic, then how are we going to get the traffic to come
to us if the node we are corresponding with has moved and now has a
different address.

Even if the NAT box is rewriting port numbers, we may find that we are
unable to get all the appropriate HIP traffic to come our way.  The
ESP traffic is also an issue.

Experiments will be valuable.  How much do different real-world NATs
vary in how they handle all these issues?

			-Tim Shepard
			 [email-masked]

---

From: [email-masked] (Pekka Nikander)
Date: Tue Sep 30 03:51:01 2003

> NAT on more than one host?

Well, we have to specify the destination port number anyway.  I also
think that it is good to define the default source port number,
making operations simpler if there are no NATs.

> addresses and UDP port numbers we can be reached at.

Exactly.

> But how can you when you are behind a NAT learn what these are?

In the general case you can't.  However, your peer will be able to,
since it will see your I1 with the modified source address and
port number.

> Or will it just be implicit that if you receive a packet from a UDP 
> port number at some IPv4 address, then we assume that the far end is 
> behind a NAT and add that to their list of addresses.  (Or perhaps 
> even send them a helpful message saying "I heard you at IPv4 address 
> foo UDP port bar.")

That was more or less my thought; I don't know about Tom or Andrew.

> incoming UDP traffic,

That's my understanding of what NATs typically do.

> then how are we going to get the traffic to come to us if the node we
> are corresponding with has moved and now has a different address.

The moved host needs to send a REA.  The REA will (again)
have a funny source port, in the typical case.

> Even if the NAT box is rewriting port numbers, we may find that we 
> are unable to get all the appropriate HIP traffic to come our way. 
> The ESP traffic is also an issue.

Indeed.  And I don't have any answers for ESP right now.
According to my understanding, all the current standards for
tunneling ESP over UDP via NATs have IPRs attached.  But I
may well be wrong.

> vary in how they handle all these issues?

I have no idea.

I simply added the following appendix to the 08-pre.  If people are
unhappy with this, I can easily remove or modify it.  IMHO we need
to eventually specify this in a different document, but the
following appendix just defines the current thinking.

--------------------------

Appendix E. Running HIP over IPv4 UDP

    In the IPv4 world, with the deployed NAT devices, it may make sense
    to run HIP over UDP.  When running HIP over UDP, the following packet
    structure is used.  The structure is followed by the HITs, as usual.
    Both the Source and Destionation port MUST be 272.

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
|         Source port           |       Destination port        | \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  >UDP
|           Length              |              CRC              | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<
|       HIP Controls            | HIP pkt Type  | Ver.  |  Res. | > HIP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/

    It is currently undefined how the actual data transfer, using ESP, is
    handled.  Plain ESP may not go through all NAT devices.

    It is currently FORBIDDEN to use this packet format with IPv6.

---------------------------

--Pekka Nikander