On Wed, Nov 7, 2018 at 1:37 PM Miika Komu <[email protected]> wrote:
> Hi Eric, > > apologies for the belated response, I am not working on HIP anymore, so > it has been rather difficult to find time for this. > > On 5/4/18 22:34, Eric Rescorla wrote: > > Eric Rescorla has entered the following ballot position for > > draft-ietf-hip-native-nat-traversal-28: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Rich version of this review at: > > https://mozphab-ietf.devsvcdev.mozaws.net/D3099 > > > > > > I am very familiar with ICE and yet I found this document extremely > > hard to follow. The problem is that it cherry-picks pieces of ICE and > > I'm just not sure that it's a complete specification when put all > > together. I have noted a number of places where I actually am not sure > > how to implement something, and fixing those will resolve this > > DISCUSS, but IMO you really should totally rewrite this document > > either (a) as a variant of ICE or (b) as an entirely new document not > > with a pile of new text and then references out to ICE sections. > > the expected receivers of the work are the implementers of RFC5770, so > the draft follows the sectioning of the RFC5770 (which has two > interoperable implementations). > > If I understood your comment right, the variant of ICE (a) would follow > the ICE document structure but then the document would not serve anymore > HIP implementers so well. What comes to option (b), I think it would > make the the document quite long if we replicated everything in the ICE > specification (and possibly from the HIP specifications) in the draft. > Yes, it would be long, because ICE is complicated. It would also be complete. As I said in my initial ballot, if you resolve the ambiguities I noted I will clear my DISCUSS, but I think that this document should really be rewritten and i would urge the AD to require it. > > S 4.6.2. > >> > >> A host may receive a connectivity check before it has received the > >> candidates from its peer. In such a case, the host MUST > immediately > >> generate a response, and then continue waiting for the > candidates. A > >> host MUST NOT select a candidate pair until it has verified the > pair > >> using a connectivity check as defined in Section 4.6.1. > > > > Are you supposed to put this on a TODO check list as with ICE? > > I believe you refer to the triggered-check queue: > > https://tools.ietf.org/html/rfc8445#section-6.1.4.1 > > I changed the text as follows: > > A host may receive a connectivity check before it has > > received the candidates from its peer. In such a case, the > > host MUST immediately generate a response by placing it in the > triggered-check queue, and then continue > waiting for the candidates. > Well, this isn't generating a response, it's queueing a response. > S 5.8. > >> > >> 5.8. RELAY_HMAC Parameter > >> > >> As specified in Legacy ICE-HIP [RFC5770], the RELAY_HMAC parameter > >> value has the TLV type 65520. It has the same semantics as > RVS_HMAC > >> [RFC8004]. > > > > What key is used for the HMAC? > > clarified this as follows: > > [..] It has the same semantics as RVS_HMAC as specified in section 4.2.1 > in [RFC8004]. Similarly as with RVS_HMAC, also RELAY_HMAC is is keyed > with the HIP integrity key (HIP-lg or HIP-gl as specified in section 6.5 > in [RFC7401]), established during the relay registration procedure as > described in Section 4.1. > This seems like it might have potential for cross-protocol attacks on the key. Why is this OK> > > S 4.2. > >> deployments in order to enable it by software configuration > update if > >> needed at some point. A host SHOULD employ only a single server > for > >> gathering the candidates for a single HIP association; either one > >> server providing both Control and Data Relay Server > functionality, or > >> one Control Relay Server and also Data Relay Server if the > >> functionality is offered by another server. When the relay > service > > > > How does this interact with mult-layered NAT?> > > No different from ICE with separated STUN and TURN servers multi-layer > NAT scenarios. Should we mention something about the issues related to > some specific scenario? > Well, with multi-layered NAT, you actually want a STUN server at each level so that you minimize hairpinning. But you recommend against that here. > S 5.7. > >> | Reserved | 0 | Reserved for future extensions > | > >> | Preferred | 0 or 1 | Set to 1 for a Locator in R1 if the > | > >> | (P) bit | | Responder can use it for the rest of > the | > >> | | | base exchange, otherwise set to zero > | > >> | Locator | Variable | Locator lifetime in seconds > | > >> | Lifetime | | > | > > > > What is the purpose of this? It's not an ICE parameter. > > In HIP, locators have a maximum lifetime after which they become > deprecated (RFC8046). Should add something here? > Yes -Ekr
_______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
