On 10/23/13 10:38 PM, Zhangdacheng (Dacheng) wrote: > 1) use ACL to process the packet, discard the packet if it is from > an unknown address. > 2) find a proper key to verify the integrity, authenticity, and freshness of the packet through the information transported in the packet header (e.g., key ID). > 3) find out whether the sender of the packet is authorized to send > out this packet. > > So, if your "address filtering based authorization" is performed in step 1, then I think it is not sufficient since we cannot jump over step 3.
I think this is a really critical point, and one that merits some careful consideration (and some text). Here's the question: in a scenario like the one under discussion, is it reasonable to assume that if you're sharing encryption/decryption/ authentication keys with a peer, are operations requested by that peer then authorized? In other contexts we've used group keys/key groups as authorization groups (that is to say, if a given node is a member of a keying group, requests from it to other members of the group are authorized, and groups may be overlapping depending on authorization requirements). That said, it may be the case that you can share keys with a node of whom you are *not* authorized to make requests (or rather, the node is not authorized to honor your requests). The questions about key management are, I think, central to the question of security requirements, and probably merit some fairly explicit discussion. Melinda _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
