[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Beating the dead horse (responder life notify questions)
I am in the process of refining the AIX code to behave better when
negotiating lifetime (for time and size types). Of course I have a few
questions (it wouldn't be IKE development otherwise ;^):
1. Is anyone using NOTIFY-SA-LIFETIME to notify the initiator that a
smaller lifetime is being used by the responder in Phase 1 negotiations? I
noticed that Dan Harkin mentioned in some earlier ipsec-list e-mail that:
"But that only works with phase 2 negotiation because RFC2409, sadly, does
not define a notify message analogous to the DOI's RESPONDER-LIFETIME. So
the only options for phase 1 are 1 or 2: fail the negotiation or just
ignore what the operator has configured. One of the action items from
http://www.lounge.org/ike_doi_errata.html is to rectify that though."
So from this I'm thinking I shouldn't send a lifetime notify in Phase 1 but
I wasn't sure if folks were implementing draft-ietf-ipsec-notifymsg-02.txt
which describes NOTIFY-SA-LIFETIME.
2. If in Phase 2, the responder receives both seconds and KB lifetimes and
wants to reduce both, should it append a RESPONDER-LIFETIME notify to the
quickmode reply and place all the life attributes (for seconds and KB) in
the Notification Data section encoded in a manner similar to attributes in
a transform payload?
I'm also a little confused by the following statement in RFC2407 (Internet
IPSec DOI):
Implementation Note: saying that the Notification Data field contains
an attribute list is equivalent to saying that the Notification Data
field has zero length and the Notification Payload has an associated
attribute list.
Why does the Notification Data field have 0 length when sending a list of
attributes? I thought the Notification Data field would contain the
attributes since there isn't an separate attribute payload (at least not in
RFC2408).
Okay, I'll stop now.
--
Will Fiveash
IBM AIX System Development