Dear Bhargav,
thank you for your expedient reply to my question.
Yes, technically, PTP LSP can run through LSRs that are not 1588-aware. But
that is very unlikely IMHO.
Then I need to note that the
http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpls-02 had expired last
April.
Regards,
Greg
________________________________
From: [email protected] [mailto:[email protected]] On Behalf Of
Bhargav Bhikkaji
Sent: Monday, July 09, 2012 3:45 PM
To: Greg Mirsky; Balaji venkat Venkataswami
Cc: [email protected]; Shankar Raman M J; [email protected]; [email protected]
Subject: RE: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ...
Dear Greg,
As per the PTP over MPLS draft, all intervening LSRs need not be 1588-aware.
If we use the EF-PHB with green as drop probability all P routers need not know
about the PTP LSP. This has been stated in the PTP over MPLS draft.
Even if we were to use the 1588 aware LSRs the actual binding between a PTP LSP
and the VPN which is protected by it is known only to the ingress and egress PE
and not anywhere else. The PTP LSP would have to be tied into the labels only
at the ingress and egress PE and this binding / tying up is known only to them.
Hence even if the PTP LSP timing is elicited the time slices when the labels
have to be used is known only to the ingress and egress PEs.
Thanks
From: [email protected] [mailto:[email protected]] On Behalf Of Greg
Mirsky
Sent: Monday, July 09, 2012 10:46 AM
To: Balaji venkat Venkataswami
Cc: [email protected]; Shankar Raman M J; [email protected]; [email protected]
Subject: Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ...
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]<mailto:[email protected]>> wrote:
Dear Tal,
Comments inline
On Mon, Jul 9, 2012 at 11:44 AM, Tal Mizrahi
<[email protected]<mailto:[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
