RE: secdir review of draft-ietf-dime-priority-avps-04

[Stephen Hanna <[e-mail]>]

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: [e-mail] [mailto:[e-mail]]
> Sent: Tuesday, July 26, 2011 7:24 AM
> To: Stephen Hanna
> Cc: [e-mail]; [e-mail]; draft-ietf-dime-priority-
> [e-mail]; [e-mail]
> Subject: RE: secdir review of draft-ietf-dime-priority-avps-04
> 
> Steve,
> 
> 
> Quoting Stephen Hanna <[e-mail]>:
> 
> > 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
>