Subject: [Hipsec] Feedback - draft-nikander-hip-path.txt

From: Abhinav Pathak <[email-masked]>
Date: Wed, 09 Nov 2005 11:25:31 +0200

Hello

Below are my feedback for the draft-nikander-hip-path.txt. This was a mail to
the authors of draft (some time back). Some of the changes have been
incorporated and am working on the rest. I will be submitting soon a revision
of the draft.

--abi

<mail>

Hello

The implementation of this draft was stalled in May as we did not have a working
version of HIPL over IPv4 (the one we had is incomplete and uses hooks to work
things out). So we first finished the BEET patch and now working on getting IPv4
support for HIPL (using BEET) and then there would be NAT traversal for it --
infact HIPL over ipv4 plus NAT traversal(between HIP initiator and HIP
responder) is my bachelors' thesis at IIT Kanpur
http://home.iitk.ac.in/~abpathak/acads.html .

I worked on the draft a bit in May to get the UDP-REA and S-UDP-REA parameter to
go along with base exchange, and thus NAT detection was done then. But as there
was no means of testing it out (ip6tables doesnt support NAT yet!!) we moved on
to BEET.

Some Feedback about the draft:

1) One of the problems I faced about the draft, is that it tells to dynamically
switch on/off UDP encapsulation for a particular conversation (depending on NAT
present or not). For this we need to make dynamic UDP encapsulation (probably
through the xfrm interface) in the kernel -- this is from linux kernel point of
view.

This would be of particular interest in mobility scenarios. If a HIP client
moves from behind NAT to outside it. Then there would be no need for UDP
encapsulation.

Also for a host behind a NAT needs UDP encap to talk to a server outside NAT,
but can talk without UDP encapsulation to a server inside the same NAT.

So, I guess the draft should specify that there is a need for UDP encapsulation
to be defined per SA/SP basis (this is what we plan to do).

2) As per discussion with Julien Laganier in May, there was some confusion with
Length field in (S)UDP-REA parameters. An excerpt from his mail (reply) says
that there is some problem with a figure

<snip>

> > > 1. In UDP-REA and SUDP-REA Parameter, what does the length
> > > field represent. Length of the (S)UDP-REA Parameter (as a
> > > whole) or length of the whole of the packet (which should not
> > > be according to me as, if the packet is encapsulated in with
> > > UDP Encapsulation, then that UDP header should have the length
> > > of the packet as a whole). ( The draft states : Length (2
> > > bytes) represents length in Octets, excluding type and length
> > > fields).
> >
> > My understanding is that the Length denotes the length of the
> > whole parameter. So UDP-REA is 4 + hash_length +
> > padding_to_64bits octets long and S-UDP-REA is 4 + 2 + 2 + 2 *
> > addr_size + padding_to_64bits octets.
>
> Why do we need padding in the SUDP_REA Parameter? The draft says
> that there is no padding in it.

I get confused between the real length and what's in the length field,
which doesn't include the padding. Let me quote the hip-base draft:

-----
All the TLV parameters have a length (including Type and Length
fields) which is a multiple of 8 bytes.  When needed, padding MUST be
added to the end of the parameter so that the total length becomes a
multiple of 8 bytes.  This rule ensures proper alignment of data.  If
padding is added, the Length field MUST NOT include the padding.  Any
added padding bytes MUST be set zero by the sender, but their content
SHOULD NOT be checked on the receiving end.
-----

So I think that while the complete length would be as I said before,
the padding isn't included in the computation of the Length field, so
the lenth is 4 + hash_length for UDP-REA and 4 + 2 + 2 + 2 *
addr_size for S-UDP-REA.

So IMHO that means there's an error in the S-UDP-REA figure. Should
have been like below (because we need to be 64 bits aligned):

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Address Lifetime                      |T|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Source Port                |    Destination Port           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~    Source Address                                             ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~    Destination Address                                        ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Padding                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Tnx.

--julien

</snip>

IMHO the length parameter should be defined some what more explicitly.

3) We need to define a port number on which to recieve the UDP (with HIP)
packets on so that we can differentiate them from other UDP traffic and to make
a listner on both client and server on that port. (we were using 4500 (used for
standard NAT traversal by kame/racoon) if i remember properly).

4) There are some statements which are I think need a bit more reasoning like

a. An integration with STUN and TURN would not add more security to the protocol
exchange. (page 3)
b. It MUST be ensured that the total length (including padding) of the UDP-REA
parameter is 11 + Length - (Length + 3) % 8 (page 3)

5) Some grammatical corrections -- excerpt from my mail to the authors of draft
in May

<snip>

Besides these, there are some spelling errors, and some gramatical mistakes
which are mentioned below.

a. Page 3 : 3rd line. should be Firewalls are present. Instead of Firewalls are
presents.

b. Page 6 : 4th para. 3rd line, the word particularly is repeated twice.

c. Page 10 : 3rd point in further information for message handling. 3rd line,
the is repeated twice.

d. Page 11 : 1st para, It is mentioned twice that the HIP Initiator is behind
the NAT.

e. Page 3: In introduction "The client obviously needs to support the clide part
of the protocol as well" . CLIDE is something not clear to me.

</snip>

I will be implementing this draft from January onwards when we will have hipl
over ipv4 ready.

Please mail me back for further clarifications/comments.

</mail>

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec