ISAKMP info-exchange/notify handling

[Tylor Allison <allison@securecomputing.com>]

I have a few more questions about ISAKMP, this time regarding the use of 
ISAKMP Info exchanges and/or Notify/Delete payloads in response to error 
handling:

o   Reading the ISAKMP draft (v8), I'm lead to believe that a new ISAKMP
    Information Exchange is generated when ISAKMP hits an error condition.
    For example, section 5.2 under verifying cookies: "An Informational
    Exchange with a Notification payload containing the INVALID-COOKIE
    message type MAY be sent to the initiating entity.  This action is
    dictated by a system security policy."  Similar wording is used for
    other erroneous conditions.  

    I then find the following text in the IPSEC DOI (v6), Section 4.6.3
    "IPSEC DOI Notify Message Types: Notification Status Messages MUST be
    sent under the protection of an ISAKMP SA: either as a payload in the
    last Main Mode exchange; in a separate Informational Exchange after
    Main Mode or Aggressive Mode processing is complete; or as a payload in
    Quick Mode Exchange."

    I'm assuming that this last paragraph was meant to be applied to the
    IPSEC DOI Notify message types... but I have a question about whether
    or not any ISAKMP Notify or Delete Payload may be placed in the payload
    of a Main Mode, Aggressive, or Quick Mode exchange?  So instead of 
    generating a new ISAKMP Info exchange when responding to an error 
    condition, I would just fill out the next payload of the exchange with 
    the corresponding Notify or Delete Payload???  If this type of 
    processing is allowed, does it contradict with the text in the ISAKMP 
    draft mentioned above?

    I've been assuming that an Informational Exchange should always be
    generating in response to an error... even tho' I'll still handle
    notify or delete payloads in any exchange.

o   My next question concerns Informational Exchanges in response to Quick
    Mode negotiations.  The I/O resolution draft states, Section 5.7: 
    "As noted the message ID [of the ISAKMP info exchange] in the 
    ISAKMP header-- and used in the prf computation-- is unique to 
    this exchange and MUST NOT be the same as the message ID of another 
    phase 2 exchange which generated this information exchange."

    In an environment where PFS is not performed, ISAKMP SA's may be used
    to protect more than one Quick Mode negotiation.  How does one then
    know what Quick Mode negotiation an informational exchange is for?  
    The ISAKMP draft says: "Notification which occurs during, or is
    concerned with, a Phase 2 negotiation is identified by the Initiator
    and Responder cookie pair in the ISAKMP Header and the Message ID and
    SPI associated with the current negotiation."  This confuses me... the
    Message ID is lost (since we generate a new message ID for the Info
    exchange), we may not have the SPI value (e.g. Invalid IPSEC SA offered),
    or we may have multiple SPI's (e.g. QM negotiations with more than one
    IPSEC SA).  Am I missing something?  Are people using something
    other than the SPI's negotiated with the IPSEC SA's for their SPI's 
    in notify/delete payloads?  If not, how does one tie a specific Info
    exchange with the Phase 2 negotiation it is in response to?

Sorry so long-winded, any help would be appreciated...

Thanks!

---
Tylor Allison         tylor_allison@securecomputing.com        (612) 628-1554
Secure Computing Corporation

---

• Prev by Date: NAT bypass for e2e 'sensitive' applications (e.g: IPSEC)
• Next by Date: Job Change
• Prev by thread: NAT bypass for e2e 'sensitive' applications (e.g: IPSEC)
• Next by thread: Job Change
• Index(es):
  • Main
  • Thread