Med –
V13 of the draft has been posted which addresses the logging text and the
Security section text.
There is then one open issue:
> > > # 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.
[LES2:] Let’s dig a bit deeper here.
You propose that each implementation locally choose a maximum value for the
number of MP-TLVs it supports for a given object.
Suppose that Node A chooses “2” and Node B chooses “3”.
Both of them receive advertisements which have 3 MP-TLVs for a given object.
What will happen?
Node A will use 2 of the TLVs – Node B will use all 3 of the TLVs.
Which means we are in an equivalent situation to having a node which doesn’t
support MP-TLVs at all in the network.
And we are vulnerable to the same problems – forwarding loops/black holes.
One way of dealing with this would be to specify a global maximum instead of
leaving it to individual nodes to choose a maximum.
But this means if the number proves too small over time, we now have to do an
upgrade and get all nodes to support a larger number.
And even with a consistent maximum, receivers still have to deal with what ever
they receive i.e., nodes cannot simply ignore the additional TLVs. Even if they
don’t actively use the information in those TLVs they have to track all of the
TLVs associated with a given object so that they become aware when that number
falls into the acceptable range – noting that you don’t know which of the TLVs
may be withdrawn in the next update.
I appreciate the concern that you have – but imposing a limit isn’t going to
help – it is only going to create additional problems.
Les
_______________________________________________
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org
