Re: [lisp] Fwd: AD Review of draft-ietf-lisp-sec-25

[Alvaro Retana <[e-mail]>]

On May 25, 2022 at 6:48:05 AM, Luigi Iannone wrote:


Luigi:

Hi!


> Revision -26 of lisp-sec has been submitted.
> Damien and the other co-authors helped in addressing your remarks.
> Hereafter, you can find inline answers to the vapors points.

I have some comments left below.  There are a couple of "major" issues
left, but I am starting the IETF Last Call now.  You can address my
comments with others that may come in.

I want to highlight the registration policy for the new registries --
see the comments inline.


Thanks!

Alvaro.



...
> > 363 Requested HMAC ID: The HMAC algorithm, that will be used to
> > 364 protect the mappings, requested by the ITR. See Section 6.4 for
> > 365 details, and Section 8.3 for HMAC IDs that MUST be supported.
> >
> > [major] §8.3 says this:
> >
> > AUTH-HMAC-SHA-1-96 MUST be supported, AUTH-HMAC-SHA-256-128 SHOULD be
> > supported.
> >
> > However, (1) it is not good practice to include specifications in the
> > IANA Considerations section (only instructions to IANA should be
> > included there),
>
> The text has been moved and is not anymore in the IANA section.

      Requested HMAC ID: The HMAC algorithm, that will be used to
      protect the mappings, requested by the ITR.  See Section 6.4 for
      details, and Section 8.3 for HMAC IDs.

[nit] There's no need to point to §8.* -- here, or in the other descriptions.



...
> > s/OTK Wrapping ID:/OTK Wrapping ID (OTK Wrap. ID):
>
> Done. Thanks.

[nit] There's an extra space: "OTK Wrap.  ID".



...
> > [major] "ITR MUST set EID-AD Length to 4 bytes"
> >
> > What should the receiver do if the length is set to anything else?
> >
> > For messages not originated by the ITR, the length has to be more then
> > 4. In fact, it has to be 12 + the length of EID-prefix (multiple may
> > be present) + length of EID HMAC. What should a receiver do if the
> > length is not appropriate?
> >
> > I don't remember seeing anything in rfc6833bis about error handling or
> > what to do about mismatched lengths in general. Did I miss it?
>
> That is correct. But if such details is added for the EID-AD length it has to
> be added for all “*-length” fields in all the specs.
> Is it worth it?

Well...  I think it is -- there should be clear error handling
guidelines so everyone knows what to do.  I went to look at rfc6833bis
because the behavior should have been defined there.

However, at this point, we should move on.  I'll leave it as
"homework" for the WG to figure out error handling in a future
document.  We don't need to hold anything up.



...
> > 422 EID mask-len: Mask length for EID-prefix.
> >
> > 424 EID-AFI: Address family of EID-prefix according to [AFN].
> >
> > 426 EID-prefix: The Map-Server uses this field to specify the EID-
> > 427 prefix that the destination ETR is authoritative for, and is the
> > 428 longest match for the requested EID.
> >
> > [major] These 3 fields, which are part of the "Rec", are the same as
> > what is specified in §5.2/rfc6833bis. But the descriptions are
> > different, and the EID-AFI names doesn't match EID-Prefix-AFI. Please
> > point at the definitions in rfc6833bis:
> >
> > EID mask-len: As defined in §5.2/rfc6833bis.
> > ...
> >
>
> Done when possible.

[major] About EID-AFI.  rfc6833bis calls this field EID-Prefix-AFI.
Please be consistent.  If the fields don't have the same name then the
pointer to rfc6833bis doesn't make sense.



...
> > 503 PKT HMAC: HMAC of the whole Map-Reply packet, including the LISP-
> > 504 SEC Authentication Data. The scope of the authentication goes
> > 505 from the Map-Reply Type field to the PKT HMAC field included.
> > 506 Before computing the HMAC operation the PKT HMAC field MUST be set
> > 507 to 0. See Section 6.8 for more details.
...
> > It would be better if the specification was made only once. A pointer
> > to §6.8 should be enough here.
>
> It is now in the that section.

[] You left the text in §6.2 -- so we still have two definitions that
don't say the same thing.



...
> > 731 In this way the ITR that sent a LISP-SEC protected Map-Request always
> > 732 receives a LISP-SEC protected Map-Reply. However, the ETR-Cant-Sign
> > 733 E-bit set to 1 specifies that a non LISP-SEC Map-Request might reach
> > 734 additional ETRs that have LISP-SEC disabled. This mechanism allows
> > 735 the ITR to securely downgrade to non LISP-SEC requests, if so
> > 736 desired.
> >
> > [major] "This mechanism allows the ITR to securely downgrade to non
> > LISP-SEC requests, if so desired."
>
> Sentence has been changed, now also including that by so doing there is no
> protection against threat described in section 4.
>
> > Besides the fact that "securely downgrade to non LISP-SEC" sounds like
> > a contradiction, the "if so desired" part leaves the operation up in
> > the air. When/why would an ITR desire to disable security? What are
> > the use cases where it may be ok? What are the risks that should be
> > considered?
> >
> > As I see it, downgrading is risky because it can open the door to
> > overclaiming, which list-sec closes (rfc6833bis). IOW, a rogue ETR
> > can decide not to set the S-bit (even if it did support lisp-sec) and
> > eliminate its benefits. rfc6833bis also says this:
> >
> > 3. LISP-SEC [I-D.ietf-lisp-sec] MUST be implemented. Network
> > operators should carefully weight how the LISP-SEC threat model
> > applies to their particular use case or deployment. If they
> > decide to ignore a particular recommendation, they should make
> > sure the risk associated with the corresponding threats is well
> > understood.
> >
> >
> > Please add a "Deployment/Operational Considerations" section to help
> > operators in making the decision above, particularly about when an ITR
> > may desire to downgrade. Please include (as appropriate) information
> > as described in §2/rfc5706.
> >
> > FWIW, I see the E-bit as useful as a transition mechanism: while not
> > all the ETRs may have been upgraded then it seems ok to downgrade to
> > maintain the operation of the network. However, I'm having a hard
> > time seeing the value afterwards.

[] I still think that a malicious downgrade (attack) is not properly
covered anywhere -- it is not even mentioned in the Security
Considerations.



...
> Changed as suggested. Thanks.

[minor] The text now has redundant information:

   In response to an encapsulated Map-Request that has the S-bit set, an
   ITR MUST receive a Map-Reply with the S-bit set, that includes an
   EID-AD and a PKT-AD.  If the Map-Reply does not include both ADs, the
   ITR MUST discard it.  In response to a Protected Map-Request, an ITR
   expects a Map-Reply with the S-bit set to 1 including an EID-AD and a
   PKT-AD.  The ITR MUST discard the Map-Reply otherwise.

Only the last two sentences are needed.



...
> > [major] What are "piggybacked Map-Replies"? Where are they specified?

[] I still don't know what this is.



...
> > 881 6.9.1. Map-Reply Record Validation
...
> Changed in the example no more normative language used.

[] The example still has Normative language.



...
> > [major] The Specification Required policy requires the review of a
> > Designated Expert. Please provide instructions for the experts? What
> > factors should they take into account when approving a new value?
>
> Added sentence stating that security experts have to assess that the new KDF
> is strong enough.

[major] I have several comments/questions...this is the new text in §8.5:

   Values 2-65535 are unassigned.  They are to be assigned according to
   the "Specification Required" policy defined in [RFC8126].  Expert
   review, from security area, should assess that the security of key
   derivation function, so that its use does not introduce security
   risks.

The way Designated Experts (DE) work is that a couple of DEs are
assigned to a registry.  This is usually done from volunteers that
include the authors and maybe others in the WG.  IOW, there is no
possibility to assign a review to an "expert...from the security area"
unless that person is already the DE for this registry.

What exactly should a DE consider when evaluating that the KDF "does
not introduce security risks"?

§8.3 and §8.4 also include of security-related registries.  Should the
same instructions apply there?

All the new registries use "Specification Required".  Are there
specific considerations the Designated Experts (DE) should think about
for the others?


The existing security-related LISP registries (LISP Algorithm ID
Numbers / rfc6833bis and LISP Crypto Cipher Suite / rfc8061) use a
First Come First Served registration policy.  Personally, FCFS seems
too open to me (as anyone can request a codepoint)...  Just pointing
this out.



> All references fixed as requested (note that IDnit will signal them as
> downref).

[] All of them, except RFC7835 are already in the downref registry.  I
don't think RFC7835 will be an issue.

[]