1 / 16

ISMS Issues

ISMS Issues. David Harrington IETF65. Session Issues. SQ1: Are notifications originators responsible to establish sessions for notification delivery, and if so, how and when do they do so? Yes. NOs MUST be able to establish sessions.

jack-wood
Download Presentation

ISMS Issues

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ISMS Issues David Harrington IETF65

  2. Session Issues • SQ1: Are notifications originators responsible to establish sessions for notification delivery, and if so, how and when do they do so? • Yes. NOs MUST be able to establish sessions. • Sessions are established by default from the Transport Mapping Security Processor, but MAY be established in advance to support features such as call-home.

  3. Session Issues • SQ2: Can notification originators (re-)use already established (R/R) sessions for notification delivery? • Tentative answer: Yes, but it is not required for compliance. This would not require knowing session direction. • Tentative: No. This would require knowing session direction to determine if existing session is notify or R/R type.

  4. Session Issues • SQ2 (cont): How and when do they determine that a session does or does not exist, and how and when do they choose a session with the appropriate security characteristics (both SSH and SNMP)? • Application must provide securityN/M/L and transport address • Is it possible to tell TMSP desired direction?

  5. Session Issues • SQ3: Is it required that a session already exists before a notification can be sent? • No, the TMSP will attempt to establish a session if one does not exist.

  6. Session Issues • SQ3 (cont): when and how does the notification originator (or message processor) determine whether a session exists or not, and what happens if there is no session? • When the outgoing message reaches the transport mapping, the TMSP determines if a session exists, and if not will attempt to create a session.

  7. Session Issues • SQ4: Are sessions torn down when a logical operation is complete? • No, this is not the recommended design, but the decisions is implementation-dependent.

  8. Session Issues • SQ4 (cont): how and when does the engine know that a logical operation is complete (for example, when a message is discarded during processing and no Report is generated)? • This is Implementation-dependent.

  9. Session Issues • SQ5: If sessions are kept alive for future use, how do we deal with situations where sessions either need to be torn down due to resource constrains or where sessions seem to bind resources but are not really used? • Implementation-dependent.

  10. Session Issues • SQ6: How is session state information managed and in particular cleaned up when sessions go away (both via clean session shutdown or due to failures)? • Model- and implementation-dependent. If the model defines tables for session maintenance, it will need to describe how to do clean up.

  11. Session Issues • SQ7: How do we deal with MIB variables that are bound to the existence of a session (e.g. notification target configurations pointing to a session established by a "manager" to receive notifications)? • Model-dependent; the model should specify when entries should be deleted; implementation-dependent as to how.

  12. SSH Authentication • AQ1: Does notification delivery via SSH require user authentication of the notification originator and host authentication of the notification receiver? • If so, NO cannot reuse RR session.

  13. SSH Authentication • AQ2: Does notification delivery via SSH require host authentication of the notification originator and user authentication of the notification receiver? • If so, then NO can reuse RR session.

  14. SSH Authentication • AQ3: Should both authentication styles outlined above be supported and runtime configurable? • AQ1 is mandatory-to-implement • If AQ2 is supported, it is model-dependent and must be runtime-configurable. The WG should address what needs to be configured, but how is implementation-dependent.

  15. SSH Authentication • AQ4: Is it possible/useful to have a "turn" mechanism in SSH which allows a process to initiate the SSH protocol but later turn the automatically assigned client role into a server role? • This is not possible in SSH, but higher-layer functionality such as channels may be turned or may be symmetric.

  16. Questions?

More Related