Re: Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)
Eric Rescorla <[email protected]> Wed, 26 Dec 2018 17:04:27 -0800
| Newsgroups | gmane.ietf.hipsec,gmane.ietf.hip |
|---|---|
| Message-ID | <CABcZeBO3gLUZevW0zTN6RHiuYBY+7d-4DefSNBA3FzhXFWfGQw@mail.gmail.com> |
--===============3002762711652664263== Content-Type: multipart/alternative; boundary="0000000000009e3b97057df6893f" --0000000000009e3b97057df6893f Content-Type: text/plain; charset="UTF-8" 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 --0000000000009e3b97057df6893f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr">On Wed, Nov 7, 2018 at 1:37 PM Miika Komu <<a href=3D"m= ailto:[email protected]" target=3D"_blank">[email protected]</a= >> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px= 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi = Eric,<br> <br> apologies for the belated response, I am not working on HIP anymore, so <br= > it has been rather difficult to find time for this.<br> <br> On 5/4/18 22:34, Eric Rescorla wrote:<br> > Eric Rescorla has entered the following ballot position for<br> > draft-ietf-hip-native-nat-traversal-28: Discuss<br> > <br> > When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s<br> > introductory paragraph, however.)<br> > <br> > <br> > Please refer to <a href=3D"https://www.ietf.org/iesg/statement/discuss= -criteria.html" rel=3D"noreferrer" target=3D"_blank">https://www.ietf.org/i= esg/statement/discuss-criteria.html</a><br> > for more information about IESG DISCUSS and COMMENT positions.<br> > <br> > <br> > The document, along with other ballot positions, can be found here:<br= > > <a href=3D"https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-= traversal/" rel=3D"noreferrer" target=3D"_blank">https://datatracker.ietf.o= rg/doc/draft-ietf-hip-native-nat-traversal/</a><br> > <br> > <br> > <br> > ----------------------------------------------------------------------= <br> > DISCUSS:<br> > ----------------------------------------------------------------------= <br> > <br> > Rich version of this review at:<br> > <a href=3D"https://mozphab-ietf.devsvcdev.mozaws.net/D3099" rel=3D"nor= eferrer" target=3D"_blank">https://mozphab-ietf.devsvcdev.mozaws.net/D3099<= /a><br> > <br> > <br> > I am very familiar with ICE and yet I found this document extremely<br= > > hard to follow. The problem is that it cherry-picks pieces of ICE and<= br> > I'm just not sure that it's a complete specification when put = all<br> > together. I have noted a number of places where I actually am not sure= <br> > how to implement something, and fixing those will resolve this<br> > DISCUSS, but IMO you really should totally rewrite this document<br> > either (a) as a variant of ICE or (b) as an entirely new document not<= br> > with a pile of new text and then references out to ICE sections.<br> <br> the expected receivers of the work are the implementers of RFC5770, so <br> the draft follows the sectioning of the RFC5770 (which has two <br> interoperable implementations).<br> <br> If I understood your comment right, the variant of ICE (a) would follow <br= > the ICE document structure but then the document would not serve anymore <b= r> HIP implementers so well. What comes to option (b), I think it would <br> make the the document quite long if we replicated everything in the ICE <br= > specification (and possibly from the HIP specifications) in the draft.<br><= /blockquote><div><br></div><div>Yes, it would be long, because ICE is compl= icated. It would also be complete.</div><div>As I said in my initial ballot= , if you resolve the ambiguities I noted I will</div><div>clear my DISCUSS,= but I think that this document should really be rewritten</div><div>and i = would urge the AD to require it.</div><div><br></div><div><br></div><div>= =C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0= px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> > S 4.6.2.<br> >>=C2=A0 =C2=A0 <br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0A host may receive a connectivity check = before it has received the<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0candidates from its peer.=C2=A0 In such = a case, the host MUST immediately<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0generate a response, and then continue w= aiting for the candidates.=C2=A0 A<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0host MUST NOT select a candidate pair un= til it has verified the pair<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0using a connectivity check as defined in= Section 4.6.1.<br> > <br> > Are you supposed to put this on a TODO check list as with ICE?<br> <br> I believe you refer to the triggered-check queue:<br> <br> <a href=3D"https://tools.ietf.org/html/rfc8445#section-6.1.4.1" rel=3D"nore= ferrer" target=3D"_blank">https://tools.ietf.org/html/rfc8445#section-6.1.4= ..1</a><br> <br> I changed the text as follows:<br> <br> A host may receive a connectivity check before it has<br> <br> received the candidates from its peer. In such a case, the<br> <br> host MUST immediately generate a response by placing it in the <br> triggered-check queue, and then continue<br> waiting for the candidates.<br></blockquote><div><br></div><div>Well, this = isn't generating a response, it's queueing a response.</div><div><b= r></div><div> <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0= px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> > S 5.8.<br> >>=C2=A0 =C2=A0 <br> >>=C2=A0 =C2=A0 5.8.=C2=A0 RELAY_HMAC Parameter<br> >>=C2=A0 =C2=A0 <br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0As specified in Legacy ICE-HIP [RFC5770]= , the RELAY_HMAC parameter<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0value has the TLV type 65520.=C2=A0 It h= as the same semantics as RVS_HMAC<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC8004].<br> > <br> > What key is used for the HMAC?<br> <br> clarified this as follows:<br> <br> [..] It has the same semantics as RVS_HMAC as specified in section 4.2.1 <b= r> in [RFC8004].=C2=A0 Similarly as with RVS_HMAC, also RELAY_HMAC is is keyed= <br> with the HIP integrity key (HIP-lg or HIP-gl as specified in section 6.5 <b= r> in [RFC7401]), established during the relay registration procedure as <br> described in Section 4.1.<br></blockquote><div><br></div><div>This seems li= ke it might have potential for cross-protocol attacks on the key. Why</div>= <div>is this OK></div><div><br></div><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad= ding-left:1ex"> <br> > S 4.2.<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0deployments in order to enable it by sof= tware configuration update if<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0needed at some point.=C2=A0 A host SHOUL= D employ only a single server for<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0gathering the candidates for a single HI= P association; either one<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0server providing both Control and Data R= elay Server functionality, or<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0one Control Relay Server and also Data R= elay Server if the<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0functionality is offered by another serv= er.=C2=A0 When the relay service<br> > <br> > How does this interact with mult-layered NAT?><br> <br> No different from ICE with separated STUN and TURN servers multi-layer <br> NAT scenarios. Should we mention something about the issues related to <br> some specific scenario?<br></blockquote><div><br></div><div>Well, with mult= i-layered NAT, you actually want a STUN server at each level</div><div>so t= hat you minimize hairpinning. But you recommend against that here.</div><di= v><br></div><br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0= px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> > S 5.7.<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0| Reserved=C2=A0 | 0=C2=A0 =C2=A0 =C2=A0= =C2=A0 | Reserved for future extensions=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0| Preferred | 0 or 1=C2=A0 =C2=A0| Set t= o 1 for a Locator in R1 if the=C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0| (P) bit=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | Responder can use it for the rest of the=C2=A0 =C2=A0|<= br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | base exchange, otherwise set to ze= ro=C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0| Locator=C2=A0 =C2=A0| Variable | Locat= or lifetime in seconds=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0| Lifetime=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |<br> > <br> > What is the purpose of this? It's not an ICE parameter.<br> <br> In HIP, locators have a maximum lifetime after which they become <br> deprecated (RFC8046). Should add something here?<br></blockquote><div><br><= /div><div>Yes</div><div><br></div><div>-Ekr</div><div><br></div></div></div= > --0000000000009e3b97057df6893f-- --===============3002762711652664263== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec --===============3002762711652664263==--