Re: [karp] Gen-ART review of draft-ietf-karp-crypto-key-table-08

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

 



>>>>> "Black," == Black, David <david.black@xxxxxxx> writes:


    Black,> [A] Overall - I would like to see a paragraph added on how
    Black,> this database conceptually relates to the IPsec Peer
    Black,> Authorization Database (PAD) - see RFC 4301, section 4.4.3.

It doesn't.
not even a little bit.
It's not IPsec; it's not about what key management peers to interact
with.

It's conceptually similar to the Security Association Database (SAD).
In a discussion with Jari I agreed to propose text for a paragraph
describing how this interacts with IPsec.

If this conceptual database is used to manage to keys for a security
    protocol that uses IPsec [RFC4301] security services, then  the
    interactions between this conceptual database and the IPsec
    databases needs to be described by the protocol specification.
    Typically such a protocol would insert entries into the Security
    Association Database (SAD) when rows are inserted into the key table
    and remove SAD entries when key table rows are removed.  The
    protocol specification needs to describe how the SAD entries are
    constructed along with any other IPsec database entries that are
    needed, including a description of how these entries are ordered
    along with other IPsec database entries.  The question of whether it
    is desirable to use this conceptual database to manage protocols
    that use IPsec security services is open and has not been evaluated.

    Black,> [C] (Section 3) Where does key selection occur?  I would
    Black,> suggest that the database return all possible keys and let
    Black,> the protocol figure out what to use.  This is particularly
    Black,> important for inbound traffic for obvious reasons.

I think we've discussed key selection in the WG and come to a different
conclusion.  The key table selects the key.  We expect peer, key ID,
protocol and interface to identify a unique key for an inbound packet.

So, I think the concern you raise is not a problem.
While there was not a specific thread discussing key selection or this
issue, there were multiple reviewers who provided comments on key
selection over the development of the document, and making a major
change at this point without a technical problem seems undesirable.
If I'm missing something and the inbound packet issue is a problem then
we need to discuss it.



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]