Hi Les,
Thanks for the follow-up.
Please see inline.
Cheers,
Med
De : Les Ginsberg (ginsberg) <ginsb...@cisco.com>
Envoyé : mercredi 26 mars 2025 20:05
À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; The IESG
<i...@ietf.org>
Cc : draft-ietf-lsr-multi-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org;
yingzhen.i...@gmail.com
Objet : RE: [Lsr] Mohamed Boucadair's Yes on draft-ietf-lsr-multi-tlv-11: (with
COMMENT)
Med -
Thanx for the prompt response.
Reducing the thread to only the remaining issues.
> > > # Section 5 (*)
> > >
> > > CURRENT:
> > > When processing MP-TLVs, implementations MUST NOT impose a
> > minimum
> > > length check.
> > >
> > > Agree... however, should we have a max of MP-TLVs to be used as a
> > > guard for splitting the information into a large numbers of TLVs?
> >
> > [LES:] I see no reason to impose a maximum. Any number chosen would be
> > arbitrary and risks becoming "too small" in the future.
>
> [Med] I'm not asking to pick a random max value, but to have a knob for
> Operators to control a max based on their local policy. We need some guards
> here.
>
[LES:] I am not comfortable specifying (or even suggesting) a max value.
[Med] As I said earlier, I’m not asking for that. The exact value will be up to
the taste of the operation. My request here is to give that control.
It isn’t needed and I think introduces additional issues.
[Med] misbehaviors from within networks happen, bugs and misconfiguration
happen as well, etc. I still think the guard does not bring any issue, but fix
them.
The only reason an excessively large number of TLVs for the same object would
be sent are:
a)They are actually needed because of the amount if information required in a
given deployment
b)The sending implementation has a bug
c)There is an attacker
Regardless of the reason, the receiver has to deal with this. Specifying an
arbitrary max isn’t going to help when the need is legitimate - and it
obviously won’t help prevent the pathological cases.
Note that Section 5 (last paragraph) provides guidance on how to deal with
duplicated information.
[Med] I’m afraid that para does not cover this point.
> > > OLD:
> > > a given implementation might limit MP-
> > > TLV support to particular codepoints based on the needs of the
> > > deployment scenarios in which it is used.
> > >
> > > NEW:
> > > a given implementation might limit MP-
> > > TLV support to particular codepoints based on the needs of the
> > > deployment scenarios in which it is used (e.g., set by default
> > > or controlled by a configuration parameter).
> > >
> > [LES:] Configuration controls are discussed in Section 8.
>
> [Med] I feel like we need to exemplify how the "the needs of deployment .."
> are made known to an implementation.
>
[LES:] Vendors work with their customers to define deployment requirements (or
vice versa if you prefer 😊).
It is important to note that MP-TLV implementation is to some degree codepoint
specific.
The fact that I have implemented MP-TLV support for neighbor advertisements
doesn’t mean I then have MP-TLV support for prefix advertisements with no
additional work required.
Also, while there are many codepoints to which MP-TLV is applicable, the
likelihood of needing it in a real deployment for a given codepoint may be
extremely low.
This means each implementation will make business-based decisions on when to do
the work required to support MP-TLV for a given codepoint.
I think we have addressed this point with the current text.
[Med] Let’s park this one.
> > >
> > > ## Does the report in the following covers logging? Can we be
> > explicit
> > > here? (*)
> > >
> > [LES:] I am not clear on what is not explicit in the current text?
>
> [Med] I'm approaching alarm/log from a logic similar to rfc8632#section-3.1,
> where alarm/alarm reporting/logging are distinct concepts.
>
[LES:] Thanx for the pointer to RFC 8632.
Suppose we change:
" Implementations which support disablement of MP-TLVs MUST report alarms under
the following conditions:"
to
" Implementations which support disablement of MP-TLVs MUST log the following
occurrences:"
[Med] WFM. Thanks
???
> >
> > > # Section 10 (*)
> > >
> > > CURRENT:
> > > This document creates no new security issues for IS-IS.
> > >
> > > Isn’t generalizing applicability of MP-TLV may be misused (e.g.,
> > abuse
> > > the number of occurrences to consume computing resources of a
> > receiver)?
> > >
> > [LES:] No. Even in the absence of MP-TLV, nothing prevents an attacker
> > from sending multiple TLVs for the same object - potentially with
> > conflicting content.
> > It could be argued that with MP-TLV support implementations are
> > somewhat less vulnerable because at least they know how to deal with
> > MP-TLV if it is received.
>
> [Med] What about if you formulate this as a considerations and include it in
> that section?
>
[LES:] The point of the Security Considerations is to make readers aware of new
vulnerabilities.
Here you are suggesting we should also comment on how we may have reduced an
existing vulnerability.
This could be done, but I am not convinced it adds value.
[Med] It has value as it clarifies how an existing vulnerability can be
softened. Thanks.
???
Les
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org
