[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec-tools-devel
Subject:    Re: [Ipsec-tools-devel] Phase 1 lifetimes
From:       "Matthew Grooms" <mgrooms () shrew ! net>
Date:       2007-06-08 9:28:19
Message-ID: 200706080928.l589SJZL050716 () hole ! shrew ! net
[Download RAW message or body]


On 6/8/2007, "VANHULLEBUS Yvan" <vanhu@free.fr> wrote:
>
>> >I'm sure I tested exactly the same thing on my proprietry ike daemon and
>> >got a proposal from pix of 5 minutes).
>> >
>> >Anybody got any ideas?
>> >
>>
>> I believe returning a lifetime value other than the one specified in the
>> selected initiators proposal/transform would violate the RFC. As far as
>> I know, there is no mechanism analogous to RESPONDER-LIFETIME in phase1.
>

What I should have said was there is no mechanism analogous to
RESPONDER-LIFETIME defined by ISAKMP that is useful. Note, there is a
definition in RFC 2408 for a NOTIFY-SA-LIFETIME but it is quite vague
which limits its utility.

There were a few attempts to further define these notification for use
with phase 1 exchanges but never made it out of draft form ...

http://www3.ietf.org/proceedings/01aug/I-D/draft-ietf-ipsec-ike-lifetime-00.txt
http://www3.ietf.org/proceedings/01mar/I-D/ipsec-notifymsg-04.txt

>See RFC 2407:
>

Which defines notification messages that are specific to the IPsec DOI. I
don't have time to dig the references up right now, but recall seeing
many long discussions related to the validity of applying DOI specifics
to generic ISAKMP exchanges. Debates like these eventually led to IKEv2
which collapse the DOI model. There is more of a rub in this case as the
2 RFCs define notifications that mean the same thing depending on who
you ask. I wouldn't be surprised if this is why the original racoon
authors opted to omit support for RESPONDER-LIFETIME notifications WRT
ISKAMP defined exchanges.

>4.5.4 Lifetime Notification
>
>   When an initiator offers an SA lifetime greater than what the
>   responder desires based on their local policy, the responder has
>   three choices: 1) fail the negotiation entirely; 2) complete the
>   negotiation but use a shorter lifetime than what was offered; 3)
>   complete the negotiation and send an advisory notification to the
>   initiator indicating the responder's true lifetime.  The choice of
>   what the responder actually does is implementation specific and/or
>   based on local policy.
>
>   To ensure interoperability in the latter case, the IPSEC DOI
>   requires
>   the following only when the responder wishes to notify the
>   initiator:
>   if the initiator offers an SA lifetime longer than the responder is
>   willing to accept, the responder SHOULD include an ISAKMP
>   Notification Payload in the exchange that includes the responder's
>   IPSEC SA payload.  Section 4.6.3.1 defines the payload layout for
>   the
>   RESPONDER-LIFETIME Notification Message type which MUST be used for
>   this purpose.
>
>
>[....]
>
>4.6.3.1 RESPONDER-LIFETIME
>
>[....]
>     o  Protocol ID - set to selected Protocol ID from chosen SA
>     o  SPI Size - set to either sixteen (16) (two eight-octet ISAKMP
>        cookies) or four (4) (one IPSEC SPI)
>     o  Notify Message Type - set to RESPONDER-LIFETIME (Section
>     4.6.3)
>     o  SPI - set to the two ISAKMP cookies or to the sender's inbound
>        IPSEC SPI
>
>So it *is* possible to send an RESPONDER-LIFETIME for phase1
>messages......
>
>But if we implement that, we'll have to ensure the notify is protected
>by the phase1 !
>

I don't see any harm is implementing support for processing a received
RESPONDER-LIFETIME notifications for ISAKMP SAs. Support for sending
these messages should be handled with more care.

-Matthew

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Ipsec-tools-devel mailing list
Ipsec-tools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel
[prev in list] [next in list] [prev in thread] [next in thread]