I am no longer an area director, so generally I suggest you take up these comments with the current ADs.
On Wed, Feb 19, 2020 at 1:08 PM Miika Komu <[email protected]> wrote: > Hi Eric, > > thanks for your comments, my response below. > > ke, 2018-12-26 kello 17:04 -0800, Eric Rescorla kirjoitti: > > > > > > 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. > > reworded as follows: > > In such a case, the host MUST immediately queue a response by placing > it in the triggered-check queue, and then continue waiting for the > candidates. > > > > > 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> > > this is standard way of deriving keys in HIP. The keying procedure is > the same as with specified in RFC8004. If there is some attack > scenario, please describe it in detail? > > Or is there some editorial issue here? > I'm not sure. When I read this text it appears to say that you should be using the same key for two kinds of messages. Is that correct? -Ekr > > > 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. > > good point. This unnecessary constraint has been removed as it was also > requested by Benjamin Kaduk. > > > > > 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 > > Added a reference: > > "Locator lifetime in seconds, see Section 4 in [RFC8046]" > > > >
_______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
