Hi Nalini, Thank you for the review of the draft. I like your suggestion – I think it hits on one of the key objectives of the draft, that is, to help protocol designers and implementers understand the perspectives of security operations so that they can use their expertise and insight to provide advice when designing the protocol. Understanding error and abnormal conditions are a good example of where that can be drawn out. It’s not intended that this draft will mandate inclusion of text, but I like the idea of examples, and possible actions to make sure they are given consideration and captured where possible.
We’ll look to add some text on this in the next version. Thanks again, Michael From: [email protected] <[email protected]> Sent: 04 March 2026 15:05 To: [email protected]; [email protected] Subject: [practical-cybersecurity] Comments: draft-parsons-opsawg-security-operations-00 Michael & Flo, Thanks for putting this together. I wanted to follow up a bit on the logging section. SECOPS can't act on what it can't see. Protocol designers and implementers are the only parties who know what error or abnormal conditions can happen. So, I suggest that we add guidance to explicitly define detectable error conditions and logging requirements so that security operations can monitor and respond effectively. Having said that, error responses themselves (ICMP, control replies, resets, etc.) can become attack vectors (reflection/amplification or DoS) so this has to be carefully designed. For example, here are some unexpected or error conditions: * Protocol syntax errors * Unexpected state transitions * Invalid parameter values * Authentication or authorization failures * Resource exhaustion * Replay or duplicate message detection * Message ordering violations * Rate-limit triggers * Unexpected transport conditions (connection resets, unreachable endpoints) For each condition, the specification should define: * Detection criteria * Recommended logging fields * Recommended severity level * Recommended response behavior Example: Condition Detection Log Fields Invalid message format...............parsing failure.........................source address, protocol state, field Invalid authentication token........auth verification failure............peer identity, token type Protocol state violation................unexpected message.............current state, message type Thoughts? Chief Technology Officer Outside the Stacks, Inc. https://www.outsidethestacks.com President Industry Network Technology Council https://www.industrynetcouncil.org
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
