Hi Stephen, The example given below illustrates also what I'm thinking. And please forgive me if I miss something below. IMHO, what you are saying about the SIP-Resource-Priority is true for any other QoS parameters carried over the Diameter QoS application. It is therefore why I'm assuming that the security considerations (http://tools.ietf.org/html/rfc5866#section-11) provided in the RFC 5866 is valid for any QoS related AVP, including the new set of AVPs defined in this document. Would it make sense to refer to this section (instead of a copy/paste)? Would it solve the current issue? Regards, Lionel -----Message d'origine----- De : Stephen Hanna [mailto:shanna@xxxxxxxxxxx] Envoyé : mardi 26 juillet 2011 17:34 À : carlberg@xxxxxxxxxx Cc : ietf@xxxxxxxx; secdir@xxxxxxxx; draft-ietf-dime-priority-avps.all@xxxxxxxxxxxxxx; MORAND Lionel RD-CORE-ISS Objet : RE: secdir review of draft-ietf-dime-priority-avps-04 Every RFC author has an obligation to explain in the Security Considerations section what security issues are likely to arise when this specification is used and how those issues may be addressed. You can refer to other RFCs if you like but you cannot ignore the issues or just give a hand wave. Let me give a specific example. If a user is able to ensure that their phone calls always get the highest SIP-Resource-Priority, their calls will always go through, even during a disaster. This will benefit the user so they have an incentive to do it. However, it may damage the collective if calls from emergency responders are overridden. For this reason, protection against active MITM attacks SHOULD be employed when using Priority AVPs. If you can find an extant RFC that covers the relevant Security Considerations for your document, you can point to it and say that readers should review it because the security considerations for this draft are contained there. But you must perform a serious security analysis for your document if you want it to be accepted as an RFC. If the answer is that there are no security considerations, that's fine. You can say that. But in this case, that's clearly not the case. You raised the concern that documents may need to highlight security issues with underlying protocols upon which they depend. That is true. If you're depending on a protocol that has a serious security problem that's relevant to your document, you should explain that problem or point to a document that does so. If the problem is not relevant to your document, no problem. One need not consider every possible security issue, just the ones that are most relevant to your document. In your case, there are real security issues particular to conveying priority AVPs over Diameter. You should explain what those considerations are or point to documents that do so. As for MIBs, take a look at some recent ones and you will see that they do contain good Security Considerations sections. For example, see RFC 5834 and RFC 6240. If you'd like to learn more about how to write a good Security Considerations section, read RFC 3552. Or ask a security expert to help you. If you can't be bothered to think about security, you might as well withdraw your draft from consideration. Thanks, Steve > -----Original Message----- > From: carlberg@xxxxxxxxxx [mailto:carlberg@xxxxxxxxxx] > Sent: Tuesday, July 26, 2011 7:24 AM > To: Stephen Hanna > Cc: ietf@xxxxxxxx; secdir@xxxxxxxx; draft-ietf-dime-priority- > avps.all@xxxxxxxxxxxxxx; lionel.morand@xxxxxxxxxxxxxxxxxx > Subject: RE: secdir review of draft-ietf-dime-priority-avps-04 > > Steve, > > > Quoting Stephen Hanna <shanna@xxxxxxxxxxx>: > > > Thanks for your response, Ken. > > > > Removing the last sentence that you quoted would make things worse. > > Readers of this draft should definitely familiarize themselves with > > the security considerations related to priority. We should make that > > easier, not harder. The fact that those considerations also apply to > > other RFCs does not remove the fact that they apply to this one also. > > but those considerations do not directly apply to DIAMETER. > > > You cannot publish a document whose security considerations section > > says (as this one effectively does today), "There are lots of > security > > considerations related to this document. To understand them, please > > dig through all the referenced documents and figure it out yourself." > > Doing that digging and analysis is the job of the document editors. > > agreed, speaking in the general sense. But again, the security > considerations of these other protocols do not apply to the operation > of Diameter. > > > In order to ease the burden on you, I think a reasonable compromise > > would be for YOU to review the documents referenced and decide which > > have the most relevant security considerations. Then you could list > > those explicitly in the last paragraph of the Security > Considerations. > > I'm concerned about the implications of your recommendation. If we > extend this position to other work in the IETF, then efforts like > defining MIBs would mean that each MIB draft would need to perform a > security considerations analysis of each protocol that an objects > refers to in the context of SNMP. And one can extend the argument > that each protocol operating on top of TCP (and/or UDP) and IP would > need to perform an analysis on how TCP/UDP and IP may affect the upper > layer protocol. We don't do that today. > > cheers, > > -ken > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf