Re: [Dime] AD review of draft-ietf-dime-drmp-03

[Steve Donovan <[e-mail]>]

I'm okay with this wording.

Steve

On 3/9/16 10:08 AM, [e-mail] wrote:
>
> I forget to add that the security considerations should be updated as 
> follow:
>
> existing text in section 11:
>
>    Diameter does not include features to provide end-to-end
>
>    authentication, integrity protection, or confidentiality.  This opens
>
>    the possibility that agents in the path of a request could modify the
>
>    DRMP AVP to reflect a priority different than that asserted by the
>
> sender of the request.
>
> new proposed text (adding malicious or compromised)
>
>    Diameter does not include features to provide end-to-end
>
>    authentication, integrity protection, or confidentiality.  This opens
>
>    the possibility that malicious or compromised agents in the path of
>
>    a request could modify the DRMP AVP to reflect a priority different
>
>    than that asserted by the sender of the request.
>
> regards,
>
> Lionel
>
> *De :*MORAND Lionel IMT/OLN
> *Envoyé :* mercredi 9 mars 2016 17:05
> *À :* 'Janet P Gunn'; Steve Donovan
> *Cc :* [e-mail]; DiME; Stephen Farrell
> *Objet :* RE: [Dime] AD review of draft-ietf-dime-drmp-03
>
> Hi Steve,
>
> It is true that some scenarios will require action of agents on the 
> DRMP AVP.
>
> in that case, I would be more explicit and change a little bit the 
> order as "save the transaction priority" is valid in any case:
>
> è Note that the title of the bullet 2 should be " Agents handing the 
> request " and not "Agents handling the request"
>
>    2.  Agents handling the request - Agents use the priority information
>
>        when making routing decisions.  This can include determining
>
>        which requests to route first, which requests to throttle and
>
>        where the request is routed.  For instance, requests with higher
>
>        priority might have a lower probability of being throttled.  The
>
>        mechanism for how the agent determines which requests are
>
>        throttled is implementation dependent and is outside the scope of
>
>        this document.  Before forwarding request messages, agents 
> generally do not
>
>        modify the priority information present in the received request
>
>        message nor include the priority information when absent in the 
> received request message.
>
>        However, in some scenarios, agents
>
>        can modify the priority information e.g. edge agents modifying the
>
>        priority  values set by an adjacent operator. There might be other
>
>        scenarios where a Diameter endpoint does not support the DRMP
>
>        mechanism and agents insert the priority information in the 
> request messages for that non
>
>        supporting endpoint. When forwarding the request messages, the 
> agent saves
>
>        the transaction priority in the transaction state, either as
>
>        locally managed state or using the Proxy-Info mechanism defined
>
>        in [RFC6733 <https://tools.ietf.org/html/rfc6733>].  This will 
> be used when handling the associated
>
>        answer message for the transaction.
>
> The same kind of change should be done in bullet 5 that is about 
> handling of answers:
>
>    5.  Agent handling the answer - By default, agents handling answer
>
>        messages use the priority information stored with the transaction
>
>        state to determine the priority of relaying the answer message.
>
>        However, priority information included in the answer message,
>
>        when present, is used in place of the stored priority
>
>        information.  The use of priority information implies that
>
>        answers for higher priority transactions are given preferential
>
>        treatment to lower priority transactions. When forwarding the 
> answer messages, agents generally do not
>
>        modify the priority information present in the received answer 
> messages
>
>        nor include the priority information when absent in the 
> received answer messages.
>
>        However, in some scenarios, agents
>
>        can modify the priority information e.g. edge agents modifying the
>
>        priority  values set by an adjacent operator. There might be other
>
>        scenarios where a Diameter endpoint does not support the DRMP
>
>        mechanism and agents insert the priority information for that non
>
>        supporting endpoint.
>
> If it is agreed that agents can modify/include the DRMP AVP, I think 
> that the "SHOULD NOT" is not correct as it is a "MAY", even if not often.
>
> I think the proposed added requirements can be safely removed.
>
> Regards,
>
> Lionel
>
> *De :*Janet P Gunn [mailto:[e-mail]]
> *Envoyé :* mercredi 9 mars 2016 16:23
> *À :* Steve Donovan
> *Cc :* [e-mail] <mailto:[e-mail]>; DiME; MORAND Lionel 
> IMT/OLN; Stephen Farrell
> *Objet :* Re: [Dime] AD review of draft-ietf-dime-drmp-03
>
> Sounds good to me.
>
> Janet
>
> This electronic message transmission contains information from CSRA 
> that may be attorney-client privileged, proprietary or confidential. 
> The information in this message is intended only for use by the 
> individual(s) to whom it is addressed. If you believe you have 
> received this message in error, please contact me immediately and be 
> aware that any use, disclosure, copying or distribution of the 
> contents of this message is strictly prohibited. NOTE: Regardless of 
> content, this email shall not operate to bind CSRA to any order or 
> other contract unless pursuant to explicit written agreement or 
> government initiative expressly permitting the use of email for such 
> purpose.
>
>
>
> From: Steve Donovan <[e-mail] 
> <mailto:[e-mail]>>
> To: [e-mail] <mailto:[e-mail]>, 
> Stephen Farrell <[e-mail] 
> <mailto:[e-mail]>>, "[e-mail] 
> <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> Date: 03/09/2016 10:15 AM
> Subject: Re: [Dime] AD review of draft-ietf-dime-drmp-03
> Sent by: "DiME" <[e-mail] <mailto:[e-mail]>>
>
> ------------------------------------------------------------------------
>
>
>
>
> All,
>
> I've commented on Stephen's and Lionel's suggested changes below.
>
> If there is agreement to my proposed changes outlined below then I 
> will submit a new version of the document.
>
> Regards,
>
> Steve
>
> On 3/8/16 9:41 AM, [e-mail] 
> <mailto:[e-mail]> wrote:
> i will let Steve react but I can give my feeling :)
>
> The priority is set by the Diameter or Diameter server, not by agent.
>
> It is somehow describe in section 6 Theory of Operation
>
>   2.  Agents handing the request - Agents use the priority information
>       when making routing decisions.  This can include determining
>       which requests to route first, which requests to throttle and
>       where the request is routed.  For instance, requests with higher
>       priority might have a lower probability of being throttled.  The
>       mechanism for how the agent determines which requests are
>       throttled is implementation dependent and is outside the scope of
>       this document.  The agent also saves the transaction priority in
>       the transaction state, either as locally managed state or using
>       the Proxy-Info mechanism defined in [RFC6733].  This will be used
>       when handling the associated answer message for the transaction.
>
> Agents are just using this information if present. They are not modify 
> it or include it if absent.
> It is said in section 8.  Normative Behavior
>
>      Note: This guidance on the handling of messages without a priority
>      does not result in a Diameter agent inserting a DRMP AVP into the
>      message.  Rather, it gives guidance on how that specific
>      transaction should be treated when its priority is compared with
>      other requests.  When a Diameter agent relays the request it will
>      not insert a DRMP AVP with a priority value of 10.
>
> It could be possible to clarify it as follow:
>
> in section 6, the end of the point 2 could be enhanced as follow:
>
>   2.  Agents *handling* the request - Agents use the priority information
>       when making routing decisions.  This can include determining
>       which requests to route first, which requests to throttle and
>       where the request is routed.  For instance, requests with higher
>       priority might have a lower probability of being throttled.  The
>       mechanism for how the agent determines which requests are
>       throttled is implementation dependent and is outside the scope of
>       this document.  The agent also saves the transaction priority in
>       the transaction state, either as locally managed state or using
>       the Proxy-Info mechanism defined in [RFC6733].  This will be used
>       when handling the associated answer message for the transaction.
>       *Agents are not supposed to modify or include priority 
> information in
>       in forwarded requests or answers.*
> SRD> I propose the following reworded last sentence: "Agents generally 
> do no modify priority
> information and agents generally do not add new priority information 
> in forwarded requests or answers."
>
> SRD> There is one scenario where I can see an agent does add add 
> priority information, in a
> transition period when not all endpoints support the DRMP mechanism 
> and the agent
> is used to insert priority information for the non supporting endpoint.
>
> SRD> I also see one scenario where an agent might modify priority 
> values.  This would
> be an edge agent case where the priority values included by another 
> operator's Diameter
> network aren't trusted and new values are needed.
>
> SRD> I propose that notes that address these scenarios be added to the 
> new normative requirements proposed below.
>
>
> The "not supposed" is used because it is difficult to use normative 
> wording here.
>
> In section 8, a new requirement could be added, right after " Diameter 
> agents MAY use routing priority information..."
>
>   Diameter agents SHOULD NOT modify or include the DRMP AVP when
>   relaying request and answer messages.
> SRD> I propose the following:
>    Diameter agents SHOULD NOT modify priority information when relaying
>   request and answer messages.
>
>      There might be scenarios where a Diameter agent does modify
>      priority information.  For instance, an edge agent might need to
>      modify the priority values set by an adjacent operator.
>
>   Diameter agents SHOULD NOT add priority information when relaying
>   request and answer messages.
>
>      There might be scenarios where a Diameter endpoint does not
>      support the DRMP mechanism and agents insert priority information
>      for that non supporting endpoint.
>
>
> Just a proposal, waiting for Steve and WG comments.
>
> Regards,
>
> Lionel
>
>
>
> -----Message d'origine-----
> De : DiME [mailto:[e-mail]] De la part de Stephen Farrell
> Envoyé : vendredi 4 mars 2016 18:07
> À : [e-mail] <mailto:[e-mail]>
> Objet : [Dime] AD review of draft-ietf-dime-drmp-03
>
>
> Hiya,
>
> I just have one question I'd like to ask the wg about before I start 
> IETF LC.
>
> You don't say if priorities are intended to be modified after they 
> have been
> set. In the security considerations you do say that this could be done
> maliciously, and you do say that priorities need to be dropped if received
> from a source not trusted for that, but you never say if it's 
> considered ok or
> not for e.g. an agent to change a priority for some local policy 
> reason. Don't
> you need to say that somewhere? (And apologies if you do say it somewhere
> and I missed it:-)
>
> There are some nits below, you can handled these before or after IETF LC,
> whichever is best.
>
> Cheers,
> S.
>
>
> - Section 5: URL and MME aren't expanded. Since you're just using it as an
> example, I'd say expanding this will help any reader who's not a 3gpp
> afficionado.
> SRD> Change made.
>
>
> - Section 8, "The priority marking scheme SHOULD NOT require the Diameter
> Agents to understand application specific AVPs."
> Isn't that a bogus use of 2119 language since we're not expressing
> requirements here? s/SHOULD NOT/does not/ would seem better.
> SRD> Agreed, change made.
>
>
> - Section 8, People will ask "why default to 10?" I recall the WG 
> discussed this
> but iirc mostly didn't care too much but it might be nice to justify 
> 10 if there's
> a way to do it that doesn't amount to "just because" :-)
> SRD> I'm open to wording suggestions here but the only real reason is 
> that we needed a default and some thought it might be better to have 
> the default allow for a few more higher-than-default values than 
> lower-than-default values.  I'm not sure saying this adds much value.
>
>
> - Section 8, The "When setting and using..." paragraphs are quite verbose.
> It'd be no harm to make that shorter, e.g. by just saying: "For all 
> integers x,y
> in [0,15] treat PRIORITY_<x> as lower priority than PRIOIRTY_<y> when y<x"
> You could do something similar in 9.1.
> SRD> The existing language was put in when we had 5 priority values.  
> The above is certainly a more elegant way of specifying it.  Changed 
> to the following:
>
>    When setting and using priorities, for all integers x,y in [0,15]
>   treat PRIORITY_<x> as lower priority than PRIOIRTY_<y> when y<x.
>
>      Note: As a result PRIORITY_0 is the highest priority.
> SRD> I'm not sure this can be done in section 9.1, as this is listing 
> the enumerated values for the AVP.
>
>
>
>
> I-D nits:
>
>  == Unused Reference: 'RFC5226'
>  == Unused Reference: 'RFC4412'
> SRD> These references removed.
>
>
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>
> _______________________________________________
> DiME mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/dime
>
> _________________________________________________________________________________________________________________________
>
> 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.