FYI,
my original concerns are now addressed in the 12 version of the draft.
Regarding to my last question on OSPI and ISPI, I think it is better to
keep things as they are (i.e. it is not mandatory for the Initiator to
even have a HIP relay). I discussed the topic with Ari and this follows
better the ICE methodology.
On 02/22/2016 05:30 PM, Miika Komu wrote:
Hi Ari,
below is more detailed list of the nits and also some technical comments
about the protocol.
On 02/16/2016 04:01 PM, Ari Keränen wrote:
On 12/02/16 22:59, Miika Komu wrote:
Hi,
On 01/29/2016 02:32 PM, Gonzalo Camarillo wrote:
Hi,
I would like to start a WGLC on the following draft. This WGLC will end
on February 12th:
https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/
Please, send your comments to this list.
in general, the draft should have a short intro to the NAT traversal
procedure and re-introduce some terms even though it all is specified in
RFC5770. This would make the draft a bit easier to read. I have also
some other nits which I'll send a bit later.
Thanks for the review Miika! Also Petri commented along the same lines.
We'll add some intro text to the draft to address this.
> 2. Terminology
I would repeat some of the terms used in RFC5770. Particularly these
would be useful:
* relayed address
* server reflexive candidate
* relayed candidate
* mapped address
They are used the text and it would be nice to make the draft a bit more
self-explanatory.
I would also suggest to explain the ICE term "permission" here.
> 3. Protocol Description
I would suggest to add a small intro here of the entire process
(registration, discovery of relay, base exchange, hole punching, ESP). A
picture similar to figure 1 in RFC5770 would be nice.
> 3.1. Relay Registration
> Section 3.3 at [I-D.ietf-hip-rfc5203-bis]), and the relay has
at -> in
> 3.2. Forwarding Rules and Permissions
>
> Permissions are not required for the connectivity checks, but if a
> relayed address is selected to be used for data, the registered host
> MUST send an UPDATE message [RFC7401] with a PEER_PERMISSION
> parameter (see Section 4.2) with the address of the peer and the
> outbound and inbound SPI values the host is using with this peer.
PEER_PERMISSION is not a part of RFC5770, why is it introduced here?
The description is missing also the destination where this message is to
be sent (it is the relay).
> 3.3. Relaying UDP Encapsulated Data and Control Packets
> When a host wants to send a HIP control packet (such as a
> connectivity check packet) to a peer via the data relay, it MUST add
* wants -> intends (machines don't have a will, at least yet :)
* it -> ambiguous, should be "the host"
* via the *peer's* data relay, right? I mean both hosts may have their
own data relays.
> send it to the data relay's address. The data relay MUST send the
address of the data relay of the peer (right?)
> When a host wants to send a UDP encapsulated ESP packet to a peer via
> the data relay, it MUST have an active permission at the data relay
> for the peer with the outbound SPI value it is using.
*peer* data relay
> The host MUST send the UDP encapsulated ESP packet to the data
relay's address.
What host? Whose data relay?
* wants -> intends
* peer's data relay (right? please correct twice)
The third ("If the data relay..."), fourth (When a host) and fifth
("When the data relay...") paragraphs appear a bit of
redundant/overlapping, perhaps it is better to merge them together.
Please state the owner of the data relay (i.e. registered host) in all
cases. The data relay only relays data traffic to one way (to the
registered host), right?
> 3.4. Candidate Gathering
> Gathering of candidates MAY also be performed like specified in
like -> as
> 3.7. Connectivity Check Pacing Negotiation
> the check pacing negotiation -> the connectivity check pacing
negotiation
> 3.8. Connectivity Checks
> [RFC5770] but instead of STUN packets, the connectivity checks are
..., but instead of STUN packets,,,
> checklist and start check transactions every Ta milliseconds as long
..start *to* check..
> The UPDATE packets that acknowledge a
> connectivity check requests MUST be sent from the same address that
> received the check and to the same address where the check was
> received from.
it would be easier to read this in singular form rather than plural:
An/Any UPDATE packet that acknowledges a connectivity check request MUST
originate from the same address that
was used to receive the check and destined to the same address where the
check was
received from.
(please note that I changed the wording a bit)
> The acknowledgment UPDATE packets MUST contain a MAPPED_ADDRESS
> parameter with the port, protocol, and IP address of the address
> where the connectivity check request was received from.
same here:
An/Any acknowledgment UPDATE packet MUST...
> If the controlling host
> does not have
