[Hipsec] Comments on draft-hip-native-nat-traversal-19

[Christer Holmberg <[e-mail]>]

Hi,

As co-author for the ICEbis draft, I was asked to review draft-hip-native-nat-traversal-19.

I have not had time to review the whole document. However, many of my comments are generic, and apply to the whole document.

I have no knowledge of HIP, so I will not comment on HIP issues like messages, parameters etc used.

General:
=======

QG0: Throughout the document, you use RFC 2119 terminology (SHOULD,
MUST etc with capital letters) when you refer to procedures and rules
defined elsewhere. I think that is wrong, and it also makes it very
difficult what exactly is defined in this document, and what is
defined in some other specification.

QG1: You say that the mechanism in the draft is based on ICE. I think
it would be good to give a name to the mechanism. "HIP-ICE", or
something similar.

QG2: I would also like to have a dedicated section which on a
high-level describes the differences/restrictions between legacy ICE and HIP-ICE.
It helps very much when later reading the details in section 4. That
section should at least list the different types of functions (HIP
relays etc) are used for gathering candidates, what protocol (HIP
messages) is used instead of STUN, what types of candidates are used
and how they are retrieved.

It would also be good to give a short overview of the HIP messages
used for the connectivity checks. It is very useful when later reading
the details.

QG3: You should use consistent terminology when you talk about
endpoints and relays. Sometimes the text says "host", sometimes "HIP relay server client",
sometimes "relay client", sometimes "end-host". Sometimes you say "HIP
relay", sometimes "HIP server relay", etc. Sometimes you say
"non-relay host", which suggests that the relay is also a host.


Section 3:
========

Q30: The text says:

"The hosts may use HIP relay servers (or even STUN or TURN servers)
for gathering the candidates."

This is confusing, as you have earlier said that HIP-ICE doesn't use STUN.

(Implementations may of course provide both STUN- and HIP functionality, but that is outside the scope of the document.)


Q31: The text says:

"To be contacted from behind a NAT, the Responder must be registered with a HIP relay server reachable on
the public Internet, and we assume, as a starting point, that the Initiator knows both the Responder's Host Identity Tag (HIT) and the
address of one of its relay servers"

First, when you say "its relay servers", I assume you mean the relay servers of the Responder?

Second, doesn't the Initiator need to know the address of the relay to which the Responder is actually registered, in case there are multiple
relays but the Responder is not registered with all of them? Maybe someone thinks it's obvious, but I think it should be make clear.

Could you simply say:

"To be contacted from behind a NAT, the Responder must be registered
with a HIP relay server reachable on the public Internet. It is assumed that
the Initiator knows the address of the relay server(s) to which the Responder
is registered."


Q32: The section introduces the "base exchange" concept, but it is not
clearly defined. Is it something defined in HIP, is it HIP-ICE specific?
I think you should add a description/reference somewhere.


Q33: The text says:
"At the end of the procedure, if successful, the hosts will have established a
UDP-based tunnel that traverses both NATs, with the
data flowing directly from NAT to NAT or via a HIP data relay server."

What if the responder has only registered to a HIP server relay? The
text in the section seems to suggest that it is optional to register
to a data relay.

The text needs to be more clear on whether the endpoints need to
register to a server relay and/or data relay.


Section 4.2:
==========

Q421: In general, I think it would be useful to split the section into
HIP client procedures and HIP relay server procedures.


Q422: I think the following text should be in the beginning of the section:

    "ICE guidelines for candidate gathering MUST be followed as described
    in section 4.1.1 in [I-D.ietf-ice-rfc5245bis].  A number of host
    candidates (loopback, anycast and others) should excluded as
    described in section 4.1.1.1 of the ICE specification
    [I-D.ietf-ice-rfc5245bis]."


Q423: The text says:

    "However, if no data relay is used, and the host has only
    a single local IP address to use, the host MAY use the local address
    as the only host candidate"

I am not sure what is meant by "as the only host candidate".


Q424: The text says:

    "Relayed candidates SHOULD be gathered in order to guarantee
     successful NAT traversal.  It is RECOMMENDED for
     implementations to support this functionality"

If you say SHOULD use, why do you then only say RECOMMEND support?
Doesn't the support need to be stronger than the usage?


Q425: The text says:

    "Unlike ICE, this protocol only creates a single UDP flow between
      the two communicating hosts, so only a single component exists."

This is confusing. What is meant by "unlike ICE"? You are using ICE :)
I assume you are referring to ICE usage for non-multiplexed RTP/RTCP?

I think you simply need to say that HIP only uses a single UDP flow,
using a single component, with a value of 1.


Section 4.3:
==========

Q431: The text says:

    "This section describes the usage of a new non-critical parameter type."

Shouldn't it say that the section defines a new parameter type?


Q432: If I understand correctly, the NAT mode negotiation between an
endpoint and a relay takes place during registration.

But, when does the NAT mode negotiation between two endpoints (shown
in the call flow) take place? During connectivity checks? I think you
should clarify that.


Section 4.6:
==========

Q460:The text says:

    "but UDP encapsulated HIP control messages are used instead of ICE
      messages."

What do you mean by "ICE messages"? STUN?


Section 4.6.2:
============

Q4620: The text says:

    "The HITs of the two communicating hosts MUST be used as credentials
    in this protocol (in contrast to ICE which employs username-password
    fragments)."

Again, "contrast to ICE" sounds confusing, because you are using ICE.
Maybe you should say "legacy ICE", or something similar, when
referring to 5245bis procedures.


Section 4.7:
==========

Q470: The name of the section ("NAT traversal alternatives") is
confusing, because one may think it talks about something else than HIP-ICE.
I would suggest to call it something like "Optimizations".


Section 4.9:
==========

Q490: I think Mobiliy should be described in a separate main section.


Regards,

Christer