Hi, Thanks Miika and sorry for belated answer. Your suggestions sound good. See inline for comments on the questions. I clipped out parts that needed no comments.
> On 22 Feb 2016, at 12:30, Miika Komu <[email protected]> wrote: [...] > I would also suggest to explain the ICE term "permission" here. OK. TURN RFC has text for that. [...] > > 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? Because that's needed for the data relay in order to have the same functionality as TURN server (c.f. PEER_PERMISSION in TURN RFC), i.e., to allow only explicitly singled peers to connect to the host via 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. No, RELAY_TO is used only with own relay. With peer's relay you don't need the parameter but can send plain connectivity check. This should be clarified. > > send it to the data relay's address. The data relay MUST send the > > address of the data relay of the peer (right?) No, own relay. Let's clarify that. > > > 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 Own again. > > The host MUST send the UDP encapsulated ESP packet to the data relay's > > address. > > What host? Whose data relay? The whose whose data relay is being used. > * 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? Return traffic from the host that is registered with PEER_PERMISSION is relayed too. [...] > > If the controlling host > > does not have any data to send, it SHOULD send an ICMP echo request > > ICMPv6 inside the tunnel - right? Yes. > > stop checks and start using the nominated pair. When the controlled > > host receives the first ESP packet, it MUST select that pair for use > > and send back an ESP packet to acknowledge a working candidate pair. > > If the controlled host does not have any data to send, it SHOULD send > > an ICMP echo request. > > ICMPv6 inside the tunnel? Yes (also other instances). > > If the connectivity checks failed the hosts SHOULD notify each other > > about the failure with a CONNECTIVITY_CHECKS_FAILED Notify Message > > Type [RFC5770]. > > ... failed, the hosts SHOULD ... > > It would also worthwhile to explain how the connectivity end in the case of > success, maybe through an example. That's explained in 5770 and 5245. But perhaps little redundancy would not hurt here. [...] > > 3.10. Handling Conflicting SPI Values > > > Since the HIP data relay determines from the SPI value to which peer > > an ESP packet should be forwarded, the outbound SPI values need to be > > unique for each relayed address registration. Thus, if a registered > > host detects that a peer would use an SPI value that is already used > > with another peer via the relay, it MUST NOT select the relayed > > address for use. > > This is a bit confusing, do you mean inbound SPI values? Or from which > viewpoint is this written? It's the inbound SPI from the peer's perspective. > > However, a host with many peers MAY decrease the odds of a conflict > > by registering more than one relayed address using different local > > addresses. > > local addresses? Do you mean in the case the host is multihomed? Or just by > using different SPI values? Yes, multiple IP addresses. Could be just different IP address from the same interface too. [...] > > 4.2. PEER_PERMISSION Parameter > > > The parameter is used for setting up and refreshing forwarding rules > > and permissions at the data relay for data packets. > > ... and the permission for data packets at the data relay. > > > OSPI the outbound SPI value the registered host is using for > > the peer with the Address and Port > > ISPI the inbound SPI value the registered host is using for > > the peer with the Address and Port > > What happens if both of the end-host have their own data relays? Then I think > the OSPI could be zero. The SPIs would still be the SPIs both endpoints use when sending ESP packets like in other cases. The relays don't touch the SPI values; just read them to know where to forward. > Why do you need to open both directions explicitly? I think the registered > host should be allowed to send through the relay after successfuly data relay > registration. So just opening the inbound direction should be sufficient and > OSPI could be removed? You want to also send data to the peer and then there's only OSPI in ESP packets. The relay works both ways. > > 4.3. HIP Connectivity Check Packets > > Why is the priority included separately in a new parameter since it was > already exhanged in the locator? For peer-reflexive priorities (see RFC 5245). The priority for those is different from the host priorities in the locator. > > > 5. Security Considerations > > I didn't find the described issue from RFC5770, but I would add that you're > talking about non-HIP aware firewalls. Also, the relay listens at a fixed > port for registered clients, but it can decide about the port facing the peer > host. Yes. Cheers, Ari _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
