> I still think you'll need to say something about how you're building the > pseudo-header for IPv4 vs IPv6. Are you assuming that the header would > be a different size for IPv4, or the same size with some zero-packing? Noted, will do. >>> The protocol allows for multiple HMAC algorithms, but has no mechanism for >>> signaling which one was used. >> This is the case, and it is the intent -- checking algorithm availability >> is done at key provisioning time. > So this is me being new to babel itself - I'll go read the base documents > more carefully. The point here is that the receiver does not need to know the set of HMAC algorithms implemented by the sender: it just computes its own HMAC of the packet, and compares the result (bytewise) with every HMAC TLV included by the sender; if some of the HMAC TLVs use algorithms that are not understood by the receiver, then the comparison fails, and no harm is done. This is, in my understanding, no different from RFC 2328, Appendix D.5.2, paragraph (2) (which is, as far as I know, unchanged by RFC 5709). >>> The third bullet at the top of page 4 (among different nodes) has its >>> actors confused. >> I have double-checked, and I believe the property is correct as stated. > I disagree. I think the clause you have in the "then" part of that > sentence stands alone, and the "if" part has no bearing on it. That's a subtle point, and one that my colleagues and I have spent a significant amount of time thinking about. I'm not happy with the current formulation, but this is the best I can do right now. More below. > A copy of a valid packet originally sent from C to A and then replayed to > B will be detected at B as invalid if... That's too strong. The protocol is designed to protect *multicast* communication, so a packet sent from C to both A and B will be accepted by both A and B. It does not matter if the packet is sent over a link-layer multicast C->A,B, or twice over link-layer unicast C->A,C->B -- in either case, it is accepted by both A and B. The property we have is that if C->A is accepted by A, then C->B is accepted by B only if both of the following are true: - B has previously accepted A's challenge reply; - B hasn't accepted any later packet from A. I agree that this property is confusing, so if you can point us to comparable protocols and the properties that they provably satisfy, then perhaps it could help us find a better formulation of the security properties that we claim. Thanks, -- Juliusz
