[radext] RE : Re: Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT)

[<[e-mail]>]

Hi Alan,

" In this case, there are multiple parent attributes which define essentially the same sub-TLVs.  It would be nice to be able to re-use these these sub-TLVs, without having multiple different definitions for them."

How do you know that a newly defined sub-TLV will/may be reused or not in other (future) parent attributes?

In the document describing the new attribute, you may have a clear idea about the use in multiple parent attributes for one sub-TLV (Foo) and you may consider that another sub-TLV (Bar) will be used only once. But tomorrow, for another purpose, the sub-TLV Bar appears to be really useful and it is decided to use it in multiple (new) attributes.

How will you ensure that the same value can be reused for Bar if not reserved?

Regards,

Lionel

Le 6 sept. 2016 15:16, Alan DeKok <[e-mail]> a écrit :
On Sep 6, 2016, at 8:31 AM, [e-mail] wrote:
> Which means that whatever the parent attribute, value 1 will have to be reserved for IP-Port, value 2 for IP-Port-Limit, etc. even if these TLVs are never unused in these attributes.
> The argument given by Alan is that "a TLV called "foo" should have the same TLV-Type value (e.g. 1) across multiple parent TLVs.  There is enough space to do sparse allocation."

  In this draft, yes.  Where the same sub-TLVs are used in multiple different parent TLVs.

  It's not a hard & fast recommendation.  It's just one of the little things that would be nice, if it can be done.

> Following these recommendations, the section 7.3 should be revised as follow, with a TLV-Type defined per parent attribute:

  That needs to be done, as IANA requires very specific instructions.

  My $0.02 is that I'd like to see:

IP-Port-Type-Parent-A have the same "TLV-Type" value as IP-Port-Type-Parent-B.

> And the values x.x.{1-11} will have to be reserved for any new attribute of type "TLV" defined in the ranges 241.{6-240}, 242.{1-240}, 243.{1-240}, 244.{1-240}, 245.{1-240} and 246.{1-240}.

  That's not what I'm saying.

> It would be like defining a new registry for sub-TLVs. That is, in my opinion, in contradiction with the definition of the TLV data type given in section 7.3 of RFC6929 (see above).

  I would be in for of a new registry for sub-TLVs, but only where those sub-TLVs are re-used a lot.

  As an example, let's say we had firewall rules defined in RADIUS TLVs.  Each firewall rule can specify a src/dst IP/port, for 4 different fields.  The firewall rules have an "input" set, for packets destined locally, and an "output" set, for packets destined remotely.

  Let's say we have the following definitions for "input" attributes.  I'll omit numbers for clarity, but assume that order matters:

INPUT
        SRC-IP-Input
        DST-IP-Input
        SRC-Port-Input
        DST-Port-Input

  We need to define something similar for the output rules.  We could do this:

OUTPUT
        SRC-IP-Output
        DST-IP-Output
        SRC-Port-Output
        DST-Port-Output

  Which is nice.  The sub-TLVs have the same order.

  Or, if numbering doesn't matter, we could do:

OUTPUT
        SRC-Port-Output
        DST-Port-Output
        SRC-IP-Output
        DST-IP-Output

  Or:

OUTPUT
        SRC-Port-Output
        SRC-IP-Output
        DST-IP-Output
        DST-Port-Output

  I think that either of these last two options is objectively worse than the first one.

  Note that I'm not suggesting that *all* attributes have these 4 sub-TLVs defined.  Just the attributes which define firewall rules.

  In this case, there are multiple parent attributes which define essentially the same sub-TLVs.  It would be nice to be able to re-use these these sub-TLVs, without having multiple different definitions for them.

  I hope that clarifies things.

  Alan DeKok.


_________________________________________________________________________________________________________________________

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.