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

Re: IPv6 Security Last Call Initial Questions

Jim,
	Ran may also respond but this is a co-AD response

1.  Is draft-ietf-ipsec-arch-00.txt going to be an Informational RFC
    only?  

>> this sounds like a thing to think about - it does make sense to me

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?

>> This issue was dicussed within the IPng directorate, the IESG and the 
>> IAB and the (non-unanimous) consensus was that it should be a requirement
>> that all complient IPv6 implementatons must support encryption and a
>> specific encryption protocol.  The IESG in approving the IPng
>> recommendation (RFC 1752) as a Proposed Standard endorced that
>> position.

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.

>> The reason to have any mention of this type is to ensure that some
>> implementer not assume that the specific requirements of that type
>> of key management will be fully met by this proposal.  The requirements
>> may or may not be met but the specific work has not been done to be
>> sure which.

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.

>> these two IDs were posted today and should be ready for advancement
>> at the same time as Ran's documents.

Scott