Dear all, Tal, Tal had a good question on whether the hash-digest computed was an integrity check value. Instead of the hash digest he had suggested alternate methods for the same.
I guess I forgot what I wrote up in the draft. Just to make it clear the innermost label which is the hash digest computed on the first 128 or 64 byte portion of the payload which is binary anded with an arbitrary bit pattern known to both PEs in the topology , serves as an added binary pattern which has to be guessed by the intruder intending to spoof the packet into the VPN's PE onto the CE. Thus the effective label space that has to be guessed by the intruder is the label for that time slice and the binary pattern computed on the payload (result of the hash-digest ANDed with the arbitrary bit pattern). This makes it essentially a 40 bit label space. The hash-digest was not intended to be a ICV. It could serve as an ICV as well though come to think of it. Since the binary pattern exchanged through the control plane is not known to the intruder, and the hash algorithm used is not known to the intruder (unless of course both of them are compromised in the control plane exchange which is of course secure) the resulting innermost label extends the label space to 40 bits (including the label for that time slice) that has to be guessed. Regarding the comment from the folks on jabber who called in, as to whether there might be a flood of replay packets with the + or - 1 time slice being in place, the previous label used would be known but the one after the current time slice would be hard to guess owing to the random number generation function being used to determine which the next label should be. It should be possible to jam for that time slice with the same packet with the 2 labels (previous and current) for that time slice being repeated again and again. This has to be solved. The draft does not cover how this is solved and we as authors need to work on it. I am not sure how it could be solved if at all unless some sort of sequence number is used to distinguish between consecutive packets. But this would be an overhead for a forwarding ASIC to hold sequence numbers for every FEC that is subject to this scheme. We would like your comments on the drafts and if any one has a clue as to how this jamming replay attack prevention is to be done we would be happy to integrate this to the draft. If the time slice is fairly small in milli or microseconds we could get over this problem to an extent but a repetitive algorithm that the intruder could employ would be to constantly replay packets when sets of previous and current labels can be used to send the same packet over and over again. This would gain entry to the CE. We understand that this is a problem and needs addressing. We are working on it. In the meantime we would welcome your feedback on this draft and any other areas where this scheme might apply. thanks and regards, balaji venkat and shankar raman
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
