[TICTOC] TicToc coupled with label hop : some clarifications

[Balaji venkat Venkataswami <[e-mail]>]

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