[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

IPv6 Security Last Call Initial Questions

Ran,

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
    only?  

    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
    implementation standard?

    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
    DES-CBC?  

    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.

thanks
/jim
Follow-Ups: