Re: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6833bis-27: (with DISCUSS and COMMENT)
Hi Albert, On Wed, Sep 30, 2020 at 01:31:42AM +0200, Albert Cabellos wrote: > Hi > > I´ve posted -29 following your comments, please find inline specific > responses: Thanks. I'll respond to a few things inline, and will then go update my ballot position. (To No Objection, hooray!) > On Thu, Jul 9, 2020 at 6:26 AM Benjamin Kaduk via Datatracker > wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-lisp-rfc6833bis-27: 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-lisp-rfc6833bis/ > > > > > > > > -- > > DISCUSS: > > -- > > > > (1) The -27 brought back the "MUST" for HMAC-SHA256-128 in Section 5.6 per > > my ballot on the -26, but left unchanged section 9, so we still have a > > SHOULD vs. MUST inconsistency w.r.t. implementing > > HMAC-SHA256-128+HKDF-SHA256. (I would of course prefer the same > > resolution of the inconsistency that Roman does, but have forgotten to > > what extent we have to defer to the deployed reality.) > > > > From a deployment reality perspective, I think that this makes sense: > > Implementations of this specification MUST implement > HMAC-SHA-256-128 and SHOULD implement HMAC-SHA256-128+HKDF-SHA256 > > Now it is consistent across the document. Please let me know your view on > this. I think I am resigned to this, since we only added the HKDF stuff at IESG Evaluation stage. (I suppose Roman or someone else could feel otherwise, though.) > > > > (2) It looks like the update in Section 5.7 is attempting to address my > > point about only terminating Map-Notify retransmission when the > > authentication data of the Map-Notify-Ack validates, but the added text > > is either misplaced or malformed. Perhaps > > > > CURRENT: > >The Map-Notify-Ack message has the same contents as a Map-Notify > >message. It is used to acknowledge the receipt of a Map-Notify and > >for the sender to stop retransmitting a Map-Notify with the same > >nonce and the authentication data validates. [...] > > > > NEW: > >The Map-Notify-Ack message has the same contents as a Map-Notify > >message. It is used to acknowledge the receipt of a Map-Notify and, > >once the the authentication data is validated, allows for the > >Map-Notify sender to stop retransmitting a Map-Notify with the same > >nonce. [...] > > > > Changed, thanks. > > > (3) I think that Eric Rescorla's concern about a misbehaving ETR being > > able to prevent an ITR from learning that the ETR is no longer the > > appropriate ETR for a given prefix remains unaddressed. I wrote up a > > longer description at > > https://mailarchive.ietf.org/arch/msg/lisp/O2ycn4CkWsPhFyqrZuB4ZJBNnl0/ > > but in short, we only require the ITR to send its Map-Request through > > the mapping system (vs. directly to the ETR) when SMR is sent from an > > address not in the current mapping data for that prefix -- if the SMR is > > sent from an address in the current mapping data, we allow sending > > Map-Request directly to the ETR, outside the mapping system. I don't > > see a mechanism that guarantees that such a "revocation" event is > > noticed by the ITR. > > > > Updated the section, now all SMR-invoked Map-Requests MUST be sent > through the Mapping System (This is what deployments are doing): > > An SMR message is simply a bit set in a Map-Request message. > An ITR or PITR will send a Map-Request (SMR-invoked > Map-Request) when they receive an SMR > message. While the SMR message is sent through the > data-plane, the SMR-invoked Map-Request > MUST be sent through the Mapping System (not directly). Thanks, that does make me feel better about how things work. > > > (4) The specification of the MAC+KDF algorithms doesn't seem detailed > > enough to be implementable. RFC 4868 is attempted to be used as a > > reference for both HMAC-SHA256-128 (er, and the one-character-off > > HMAC-SHA-256-128) and HKDF-SHA2562 (note spurious final '2'), but I > > think it can only work as a reference for the MAC algorithm. Presumably > > we need RFC 5869 or such for the KDF part > > > > Fixed, thanks. > > > > (5) This is probably my fault, but we're missing a step with how we > > describe the Map-Notify/Map-Notify-Ack per-message authentication. > > Specifically, while we do say that the authentication data needs to be > > recomputed each time, we don't clearly state that this is
Re: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6833bis-27: (with DISCUSS and COMMENT)
Hi I´ve posted -29 following your comments, please find inline specific responses: On Thu, Jul 9, 2020 at 6:26 AM Benjamin Kaduk via Datatracker wrote: > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-lisp-rfc6833bis-27: 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-lisp-rfc6833bis/ > > > > -- > DISCUSS: > -- > > (1) The -27 brought back the "MUST" for HMAC-SHA256-128 in Section 5.6 per > my ballot on the -26, but left unchanged section 9, so we still have a > SHOULD vs. MUST inconsistency w.r.t. implementing > HMAC-SHA256-128+HKDF-SHA256. (I would of course prefer the same > resolution of the inconsistency that Roman does, but have forgotten to > what extent we have to defer to the deployed reality.) > >From a deployment reality perspective, I think that this makes sense: Implementations of this specification MUST implement HMAC-SHA-256-128 and SHOULD implement HMAC-SHA256-128+HKDF-SHA256 Now it is consistent across the document. Please let me know your view on this. > > (2) It looks like the update in Section 5.7 is attempting to address my > point about only terminating Map-Notify retransmission when the > authentication data of the Map-Notify-Ack validates, but the added text > is either misplaced or malformed. Perhaps > > CURRENT: >The Map-Notify-Ack message has the same contents as a Map-Notify >message. It is used to acknowledge the receipt of a Map-Notify and >for the sender to stop retransmitting a Map-Notify with the same >nonce and the authentication data validates. [...] > > NEW: >The Map-Notify-Ack message has the same contents as a Map-Notify >message. It is used to acknowledge the receipt of a Map-Notify and, >once the the authentication data is validated, allows for the >Map-Notify sender to stop retransmitting a Map-Notify with the same >nonce. [...] > Changed, thanks. > (3) I think that Eric Rescorla's concern about a misbehaving ETR being > able to prevent an ITR from learning that the ETR is no longer the > appropriate ETR for a given prefix remains unaddressed. I wrote up a > longer description at > https://mailarchive.ietf.org/arch/msg/lisp/O2ycn4CkWsPhFyqrZuB4ZJBNnl0/ > but in short, we only require the ITR to send its Map-Request through > the mapping system (vs. directly to the ETR) when SMR is sent from an > address not in the current mapping data for that prefix -- if the SMR is > sent from an address in the current mapping data, we allow sending > Map-Request directly to the ETR, outside the mapping system. I don't > see a mechanism that guarantees that such a "revocation" event is > noticed by the ITR. > Updated the section, now all SMR-invoked Map-Requests MUST be sent through the Mapping System (This is what deployments are doing): An SMR message is simply a bit set in a Map-Request message. An ITR or PITR will send a Map-Request (SMR-invoked Map-Request) when they receive an SMR message. While the SMR message is sent through the data-plane, the SMR-invoked Map-Request MUST be sent through the Mapping System (not directly). > (4) The specification of the MAC+KDF algorithms doesn't seem detailed > enough to be implementable. RFC 4868 is attempted to be used as a > reference for both HMAC-SHA256-128 (er, and the one-character-off > HMAC-SHA-256-128) and HKDF-SHA2562 (note spurious final '2'), but I > think it can only work as a reference for the MAC algorithm. Presumably > we need RFC 5869 or such for the KDF part > Fixed, thanks. > (5) This is probably my fault, but we're missing a step with how we > describe the Map-Notify/Map-Notify-Ack per-message authentication. > Specifically, while we do say that the authentication data needs to be > recomputed each time, we don't clearly state that this is because the > correct per-message key is different, because we are using a different > 's' input to the KDF function for the different messages. In line with > the "Map-Register Authentication" used for Map-Register, this would > presumably be "Map-Notify Authentication" and "Map-Notify-Ack > Authentication", but neither of those strings appear in this document. > We might be able to localize the change to Section 5.6, akin to > > OLD: > 4: The derived per-message key is computed as: per-msg- > key=KDF(nonce+s+PSK[Key ID]). Where the nonce is the value in > the Nonce field of the
[lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6833bis-27: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-lisp-rfc6833bis-27: 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-lisp-rfc6833bis/ -- DISCUSS: -- (1) The -27 brought back the "MUST" for HMAC-SHA256-128 in Section 5.6 per my ballot on the -26, but left unchanged section 9, so we still have a SHOULD vs. MUST inconsistency w.r.t. implementing HMAC-SHA256-128+HKDF-SHA256. (I would of course prefer the same resolution of the inconsistency that Roman does, but have forgotten to what extent we have to defer to the deployed reality.) (2) It looks like the update in Section 5.7 is attempting to address my point about only terminating Map-Notify retransmission when the authentication data of the Map-Notify-Ack validates, but the added text is either misplaced or malformed. Perhaps CURRENT: The Map-Notify-Ack message has the same contents as a Map-Notify message. It is used to acknowledge the receipt of a Map-Notify and for the sender to stop retransmitting a Map-Notify with the same nonce and the authentication data validates. [...] NEW: The Map-Notify-Ack message has the same contents as a Map-Notify message. It is used to acknowledge the receipt of a Map-Notify and, once the the authentication data is validated, allows for the Map-Notify sender to stop retransmitting a Map-Notify with the same nonce. [...] (3) I think that Eric Rescorla's concern about a misbehaving ETR being able to prevent an ITR from learning that the ETR is no longer the appropriate ETR for a given prefix remains unaddressed. I wrote up a longer description at https://mailarchive.ietf.org/arch/msg/lisp/O2ycn4CkWsPhFyqrZuB4ZJBNnl0/ but in short, we only require the ITR to send its Map-Request through the mapping system (vs. directly to the ETR) when SMR is sent from an address not in the current mapping data for that prefix -- if the SMR is sent from an address in the current mapping data, we allow sending Map-Request directly to the ETR, outside the mapping system. I don't see a mechanism that guarantees that such a "revocation" event is noticed by the ITR. (4) The specification of the MAC+KDF algorithms doesn't seem detailed enough to be implementable. RFC 4868 is attempted to be used as a reference for both HMAC-SHA256-128 (er, and the one-character-off HMAC-SHA-256-128) and HKDF-SHA2562 (note spurious final '2'), but I think it can only work as a reference for the MAC algorithm. Presumably we need RFC 5869 or such for the KDF part (5) This is probably my fault, but we're missing a step with how we describe the Map-Notify/Map-Notify-Ack per-message authentication. Specifically, while we do say that the authentication data needs to be recomputed each time, we don't clearly state that this is because the correct per-message key is different, because we are using a different 's' input to the KDF function for the different messages. In line with the "Map-Register Authentication" used for Map-Register, this would presumably be "Map-Notify Authentication" and "Map-Notify-Ack Authentication", but neither of those strings appear in this document. We might be able to localize the change to Section 5.6, akin to OLD: 4: The derived per-message key is computed as: per-msg- key=KDF(nonce+s+PSK[Key ID]). Where the nonce is the value in the Nonce field of the Map-Register and 's' is a string equal to "Map-Register Authentication". [...] NEW: 4: The derived per-message key is computed as: per-msg- key=KDF(nonce+s+PSK[Key ID]). Where the nonce is the value in the Nonce field of the Map-Register and 's' is a string that corresponds to the message type being authenticated. For Map-Register messages, it is equal to "Map-Register Authentication". Similarly, for Map-Notify and Map-Notify-Ack messages, it is "Map-Notify Authentication" and "Map-Notify-Ack Authentication", respectively. However, I think the rhetoric would be more robust if we also modified Section 5.7 to mention the existence of the different 's' values (or, rather, the different per-message key) when we say that the authentication data is recomputed. Perhaps, s/is recomputed/is recomputed using the corresponding per-message key/ (twice). -- COMMENT: --
