[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IPv6 Security Last Call Initial Questions
If you can respond to these initial questions it would be appreciated.
I have other input regarding style and editing in the document I will
send privately to you. Ran as author I would appreciate responses from
you, others will be listened to (and most likely not responded to which
DOES NOT mean I agree), your response is the important one for this last
call, as author.
1. Is draft-ietf-ipsec-arch-00.txt going to be an Informational RFC
The reason I ask is that there is much text in ipsec that does not
apply to an actual implementation, but is history, opinions on
directions, and boilerplate type material. I believe this is good
data in an Informational RFC like the Hinden IPng White Paper and
useful to the IETF community at large, but not necessary or useful
in a proposed standard. The standard that goes with the IPng White
Paper is the Deering/Hinden IPv6 Base Specification, which is a good
example of how a standard to implement should be written.
2. DES-CBC Encryption. Could I get the formal answer to this question
from you for the record? This question could also be asked of the IESG
at that Last Call effort too [if necessary].
An IPv6 implementation is required (MUST) to implement DES-CBC. Yet
in my country (U.S.A.) being conformant means that vendors MUST build a
product that cannot be exported to the International market.
Changing it to SHOULD would eliminate this objection to the draft.
Why cannot we use the word SHOULD?
3. The term 'userid' is used in the drafts for the sending host.
What is the 'userid' and how do I know as an implementor where I get
the userid on a node?
4. Could we have examples of manual configuration, host to host keying,
and user to user keying?
I am not sure how I should implement any of these, and in the case of
user to user keying, I am not clear what that actually means?
5. In 4. Key Management section.
'Support for key management methods where the key management data is
carried within the IP layer is not a design objective for these
IP-layer security mechanisms.'
If this means it will not work then I think a standard should say
that, or else say nothing. Saying this means nothing to me as an
implementor. I cannot test for this case, so why is it an
This last point is critical. Statements in standards for which I
cannot implement as a test case is suspect as to the words being useful
for an implementor.
6. Security warnings and statements of potential attack.
Would it be possible to put these in an appendix, when they are not in
the standard to provide implementation details?
7. The specs reference two new IDs (or work in progress) for MD5 and
These are new. Are these the specifications you are stating to
implement MD5 and DES-CBC? Because you have stated MUST, if these
specs cannot be made proposed in the same time frame as your
standard, it will hold up the IPv6 Security work from going to
proposed standard. By saying SHOULD or they are an option, you free
your work from those work items reaching proposed standard IMHO.