Hi Steve,
It should be maybe clarified (if required) that this document does not create a
new protocol/solution. It only defines extensions to an existing protocol
(Diameter QoS Application), completing a standard list of AVPs in order to
support a set of parameters already defined in other specifications.
So, to be able to use this set of AVPs, you will have first to comply with the
Diameter base protocol (RFC3588(bis)), the Diameter QoS application (RFC5866),
the RFC 5624 defining the list of AVP, and all the different specifications
defining these priority parameters. This document does not introduce new
security issue. It just relies on existing solutions.
I understand therefore the concerns from Ken.
Regards,
Lionel
-----Message d'origine-----
De : carlberg(_at_)g11(_dot_)org(_dot_)uk
[mailto:carlberg(_at_)g11(_dot_)org(_dot_)uk]
Envoyé : mardi 26 juillet 2011 13:24
À : Stephen Hanna
Cc : ietf(_at_)ietf(_dot_)org; secdir(_at_)ietf(_dot_)org;
draft-ietf-dime-priority-avps(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org; MORAND
Lionel RD-CORE-ISS
Objet : RE: secdir review of draft-ietf-dime-priority-avps-04
Steve,
Quoting Stephen Hanna <shanna(_at_)juniper(_dot_)net>:
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf