[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (IPng) Re: Proposed message on perfect forward security
Dan,
I will edit the drafts to clarify. Those "reserved for future use"
SAIDs are reserved to the Internet Assigned Numbers Authority (IANA)
per the universal IETF practice. The IANA has always been most
reasonable about allocating numbers in all cases for the entire past
for all protocols where IANA controls number spaces. It is often
the case that IANA wants a public specification (e.g. Informational RFC
or Experimental RFC or Standards-track RFC) to exist before granting
the number.
I will support allocating _1_ of the reserved SAIDs to SKIP once
there is a public specification for how SKIP would be used. That
public spec would need to be reasonably complete and reasonably
clear (i.e. clear enough that someone else could implement it
if patent issues and such did not exist). Such allocation would
be the decision of the IANA, but there are zero cases where IANA
has been unreasonable about allocating numbers. If I understand
Ted, Bill, Perry, and Jeff correctly, they would also support allocating
_1_ of the reserved SAIDs to SKIP once there were a clear public
spec for how SKIP would be implemented/used with the IPv4/v6 security
mechanisms. (Jim, The same applies for any "in-band" (sic) protocol
that DEC would like to use. DEC should have no trouble obtaining
a reserved SAID upon publication of an open specification for its
key management scheme should DEC choose to go down that path :-).
Because the IPv6/v4 security drafts are standards-track and the
use of SKIP is not currently standards-track (or even the consensus
of the IPsec WG, unlike Photuris which does have rough consensus
in the IPsec WG), it is not appropriate for those IPv4/v6 drafts
to specifically allocate an SAID to SKIP at this time. Furthermore,
there is no I-D or RFC describing how SKIP would be used with
IPv4/v6 security so it would be granting a special privilege to an
undocumented protocol that is currently completely proprietary.
This also makes it inappropriate for a standards-track specification
such as the IPv4/IPv6 security drafts.
Ran
atkinson@itd.nrl.navy.mil
References: