[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: private use ISAKMP attributes
Daniel Harkins (dharkins@cisco.com) said on 7/21/97 at 4:51 PM
> What would _your_ ISAKMP implementation do if I gave you the following
>phase 1 offer?
>
> class value
> ----- -----
> 1 1 (DES-CBC for encryption)
> 2 2 (SHA for hash)
> 3 1 (pre-shared key authentication)
> 4 1 (default D-H group 1)
> 11 65001 (life type of some private use value)
>
>Would you reject it because you don't know what a life type of 65001 is or
>would you accept it because that life type means nothing to you and the
>offer is, otherwise, acceptable?
>
>Would it make a difference if I also offered this along with the above?
>
> class value
> ----- -----
> 12 (basic) 47 (life duration of 47 something-or-others)
>
>Similarly, what if I offered (as part of an otherwise acceptable offer) a
>private use class:
>
> class value
> ----- -----
> 65001 47 (?????)
>
>Acceptable or not?
>
> Dan.
>
>
I have no choice but to reject it. If I accept it, I am promising to obey and perform
what your private attribute says to do. It may be something superfluos like a
special lifetype which if ignored, your side will timeout anyway. But I don't know
that. It may be something real important that if I don't obey will either cause
un-interoperability or may cause a security hole.
I suggest you offer your proposal containing private parts and also offer a
"standard" proposal. That way, if you are talking to someone who understands
your privates, they will accept and obey, otherwise they'll pick your standard
proposal.
Of course with private attribute types, there can be conflict between two vendors
who pick the same number for different things (hint: don't pick the first number in
the private range). We need to be able to register a standard Private Scheme Attribute Class
or something.
Ultimately, it is left up to the user or administrator to configure proposals for specific systems knowing
ahead of time which use the private schemes and which are strictly standard.
Edward Russell
erussell@ftp.com
Edward Russell
erussell@ftp.com
Follow-Ups: