Dear Balaji, you've said " There is no information except on the ingress and egress PEs that identifies which is the PTP LSP for a particular VPN traffic protected by this scheme." AFAIK, notion of PTP LSP is not limited to PE's but to all P's that get PTP updates. Would that compromise your method?
Regards, Greg On Mon, Jul 9, 2012 at 8:47 AM, Balaji venkat Venkataswami < [email protected]> wrote: > Dear Tal, > > Comments inline > > On Mon, Jul 9, 2012 at 11:44 AM, Tal Mizrahi <[email protected]> wrote: > >> Hi Balaji, >> >> A few clarification questions - I think it would be good to clarify these >> issues in the draft: >> 1. Since the label hopping mechanism relies on PTP, I understand >> that PTP traffic itself does not use label hopping, right? >> > > The PTP traffic itself does not use label hopping. > > >> 2. Is there something preventing the attacker from attacking PTP, >> thus causing DoS to the data plane? >> > > It would be difficult for the attacker to identify which LSP is the PTP > LSP for a specific VPN traffic (flow / set of flows) that is protected by > this scheme. There is no information except on the ingress and egress PEs > that identifies which is the PTP LSP for a particular VPN traffic protected > by this scheme. > > 3. Is the "additional label" similar to an Integrity Check Value >> (ICV) computed over part of the packet header? >> > > It serves as a digest from which certain specific bits are chosen to > become the innermost label. Which bits are chosen depends upon the bitmask > exchanged during the control plane. > > >> 4. Is there something in your approach that would prevent an >> attacker from a replay attack? >> > > For a reply attack to succeed, the replay should time the labels correctly > otherwise the traffic gets rejected. > > 5. Looking at "Algorithm 3" I was not sure: does the receiver check >> two consequent time slots? I could not see such a check. I am referring to >> a case where the sender transmits at the end of a time slot, and the packet >> is received at the beginning of the next time slot. That would mean the >> receiver has to be able to tolerate two concurrent time slots, right? >> > > Yes. It is available as +or- 1 unit (usually seconds) in the algorithm. > Maybe a little more fine tuning is required on this. > > >> 6. The security parameters K, TS, A, I are exchanged over a secure >> link, which basically assumes there is a pre-shared key between the peer >> PEs. A naive question would be: how is your approach better than just using >> a standard ICV, based on the existing pre-shared key? >> > > While the ICV may protect against modification of the inner payload one > cannot prevent spoofing attacks if the algorithm for the ICV is deduced. > Our scheme provides facility to change the labels from time slice to time > slice so that guessing what packet belongs to which VPN traffic itself > becomes difficult. This is the first line of defense. If we provide ICV > alone we protect against modification but not with replay attacks. The > proposed scheme protects against VPN traffic identification (so replay > attacks cannot be made) and modification as well through the ICV which is > the innermost label. > > thanks and regards, > balaji , shankar and bhargav > >> >> Tal. >> >> >
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
