Re: [Dime] late comments Re: Start of the WGLC on draft-ietf-dime-drmp-02

[<[e-mail]>]

Dear Janet,

Thank you for your review and comments (that are not so late ☺ ) !

On the section 5, any clarification provided by Steve will be welcome, with the help of ECRIT community if required. Nevertheless, this section is only for information, describing potential use cases in which different priority for Diameter message routing could be needed. It is mainly for illustration as the main problematic is given in section 4. But for sure, we  should at least ensure that the examples  are correct.

On the Security considerations, I agree that the existing text could be a little bit expanded. I would not refer to RFC 4412 as the context is different in SIP environment, with functional entities that could be located in the customer premises (e.g. SIP phone or PSTN GW). Security considerations given in RFC 2475 (Architecture for Differentiated Services) could be used as guidelines. We should highlight the different threats/requirements for hop-by-Hop and end-to-end security. For hop-by-hop, we can rely on Diameter base protocol security mechanisms described in RFC6733, TLS/DTLS and IPsec providing data protection (integrity/confidentiality) at the peer connection level. 
As any agent in the path can modify the priority value inserted in the message, the system relies on a model where all the parties are trusted, end-to-end protection being not (yet) available over Diameter. I think that the text given in section 10.4 of RFC 7683 could be a good template for this part. Data integrity and signature mechanisms will be required to fulfil these security requirements but this is left for future work in the dime WG.

Best regards,

Lionel



************************************
De : Janet P Gunn [mailto:[e-mail]] 
Envoyé : mercredi 30 décembre 2015 20:26
À : MORAND Lionel IMT/OLN
Cc : [e-mail]; DiME
Objet : late comments Re: [Dime] Start of the WGLC on draft-ietf-dime-drmp-02

A couple of late comments- 

I thought I had commented on this before (in the first draft), but maybe it got lost. 

In sec 5.1 it says: 

   The United States Wireless Priority Services (WPS) and Government 
   Emergency Telecommunications Service (GETS) are examples of systems 
   designed to address these first responder needs. 

But this is not accurate.  GETS and WPS are used by the First Responder “Command/Management”, but NOT by the First Responder “Rank and File”. 

The web pages for WPS  ( http://www.dhs.gov/wireless-priority-service-wps ) and GETS ( http://www.dhs.gov/government-emergency-telecommunications-service-gets ) say that typical users are “responsible for the command and control functions critical to management of and response to national security and emergency situations, particularly during the first 24 to 72 hours following an event.” 

So the Fire  Chief might use WPS/GETS to call the local hospital (or an individual firefighter), or the hospital administrator might use WPS/GETS to call the State Health Department (or an individual doctor), but individual  firefighters would not use WPS/GETS to call each other. 

You might want to contact the ECRIT working group for examples of priority systems that DO support the front-line  firefighters, etc. 

My suggestion for rewording the paragraph is 

   The United States Wireless Priority Services (WPS) and Government 
   Emergency Telecommunications Service (GETS) are examples of systems 
   designed to address the command and control aspects of these first 
   responder needs. 

--- 

For section 5.2 Emergency Call Related Signaling, I would also suggest that you coordinate with ECRIT for appropriate wording.  In the “911” world, the bottleneck (scarce resource) is the people to answer the phone.  Sometimes it is counterproductive to improve the probability of success earlier in the call path, as it makes the congestion at the PSAP itself worse. 

--- 

Security 
I am not a security expert, but I expect the security section needs to be beefed up.  As it says in  RFC4412: 


   Any resource priority mechanism can be abused to obtain resources and 
   thus deny service to other users.  An adversary may be able to take 
   over a particular PSTN gateway, cause additional congestion during 
   emergencies affecting the PSTN, or deny service to legitimate users. 
   In SIP end systems, such as IP phones, this mechanism could 
   inappropriately terminate existing sessions and calls. 

   Thus, while the indication itself does not have to provide separate 
   authentication, SIP requests containing this header are very likely 
   to have higher authentication requirements than those without. 

I would expect similar verbiage would be appropriate for Diameter. 

--- 

Editorial nit 
 In the introduction, I think that this sentence 
   “As such, all requests are treated the same meaning that all requests have the same probability of being  throttled.” 
Would read better with a comma 
   “As such, all requests are treated the same, meaning that all requests have the same probability of being  throttled.” 

Happy New Year everyone, 

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:        <[e-mail]> 
To:        "[e-mail]" <[e-mail]> 
Date:        12/23/2015 05:26 AM 
Subject:        [Dime] Start of the WGLC on draft-ietf-dime-drmp-02 
Sent by:        "DiME" <[e-mail]> 
________________________________________



As agreed during the Dime session at IETF94, a Working Group Last Call is asked on the following document:

https://tools.ietf.org/html/draft-ietf-dime-drmp-02

Please respond to this email to support the document and/or send comments by 2016-01-20.

As this WGLC is initiated during the Xmas/end-of-year break, the WGLC period is extended to 4 weeks.
For reviewer of the document, don't forget to state if you are fine with the document even if there is no comment. It is important for evaluating the quality of the document and gauge the WG consensus. 

In addition, following the strategy for promoting compliance with the IPR disclosure rules (RFC6702), the chairs would like to check  whether there are claims of Intellectual Property Rights (IPR) on the document that need to be disclosed. Therefore, the following questions are addressed to the WG and Especially Authors and Contributors of the draft:

* Are you personally aware of any IPR that applies to draft-ietf-dime-drmp-02? If so, has this IPR been disclosed in compliance with IETF IPR rules?  (See RFCs 3979, 4879, 3669, and 5378  for more details.)

* If you are a document author or listed contributor on this document, please reply to this email message regardless of whether or not you are personally aware of any relevant IPR.  We might not be able to advance this document to the next stage until we have received a reply from each author and listed contributor.

* If you are on the DIME WG email list but are not an author or listed contributor for this document, you are reminded of your opportunity for a voluntary IPR disclosure under BCP 79.  Please do not reply  unless you want to make such a voluntary disclosure.

Online tools for filing IPR disclosures can be found at  <http://www.ietf.org/ipr/file-disclosure>.

Regards,

Lionel and Jouni

_________________________________________________________________________________________________________________________

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]
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.