[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: SA Attribute Negotiation
At 07:48 PM 12/12/96 -0500, Roy Pereira <rpereira@timestep.com> wrote:
[ .. ]
>I would like to see a standard length for some of the attributes, like
>key durations. If we decide upon a 32 bit integer to represent these
>and other values, then all implementations would be able to handle these
>attributes correctly.
>
>But if one implementation sends out a key duration of 1^199 seconds and
>codes it as a 128 bit integer, a lot of implementations will not be able
>to utilize it and thus it will not accept that proposal. We need to
>define standard variable attribute that has a lenth of 32 bits. This
>would be used by attributes that need integers as values, but that can't
>or dont wish to represent them as 16-bits with a basic attribute.
[ ..etc. ]
and on Tue, 17 Dec 1996 09:05:08 -0800 Derell Piper <piper@tgv.com> wrote:
>I don't view most (any?) of the Phase II attributes as mandatory.
>
>I think we should define default values for each and allow either side to
>override the defaults if they so choose (based on local policy).
>
>If people generally agree with this, I'll pick some defaults for the next
>version of the draft. This would also help to address Roy's concerns that
>a default attribute size be specified for basic interoperability.
I want to suggest that certain points seem pretty clear, and ask for response
from anyone who sees things otherwise:
o If the Initiator omits a default attribute, the responder may legitimately
return any legal value. Initiator can reject it by not proceeding, and
sending Notify (SA unacceptable) if its policy permits response.
o There is no need for Responder to send any attributes back at all, if it
accepts the values it received and accepts defaults for attributes it
did not receive.
(The draft does not prescribe that any of the attributes MUST be
returned.)
o The Initiator indicates acceptance of all attributes sent by the Responder,
if it proceeds with the exchange.
o Either party may send a Lifetime shorter than the other's.
This is generally not a grounds for rejection; the party who receives
the Lifetime which is smaller would do well to enforce it, but it
also could conceivably just leave enforcement of a smaller limit to
the other party.
Party A cannot possibly be required to allow the SA to last a longer
lifetime based on what party B sends. This holds whether party A is
Initiator or Responder.
o The responder should not send back a longer Lifetime value than
one explicitly sent by the initiator.
o The standard has no need to define particular field sizes, other than
to define default values.
Given the attributes that presently exist:
No implementation needs to store and act on a number received from its
partner which is larger the max it permits. If you receive a Lifetime
attribute of larger size than you support, the only decoding action you
need is to discover where the high-order nonzero is; if this shows the
value is bigger than what you support, then as discussed above you
are allowed to ignore or reduce it.
These remarks are based on the attributes we have now, i.e. only
Lifetimes; the rule for them is, either party can reduce them. Quite
conceivably a future standard might introduce attributes which would
need different rules; but that is Futures.
Not so clear:
o If party A sends a Lifetime in Kilobytes but party B implements no
Kilobyte limit, only a Time limit:
I would think party B can accept the connection and depend on party A
to enforce the limit which it announced.
o I presume it is unreasonable that anyone would implement kilobyte limits
and not time limits?
The bald assertions above are based on my understanding and my wild-eyed
beliefs about how it just has to be in order to work given the drafts;
comments and corrections are welcome.
Best regards,
- John Burke <jburke@cylink.com>