Subject: Re: [TICTOC] draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ...

From: Tal Mizrahi <[email-masked]>
Date: Mon, 9 Jul 2012 09:14:20 +0300

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?
2.	Is there something preventing the attacker from attacking PTP, thus causing DoS to the data plane?
3.	Is the "additional label" similar to an Integrity Check Value (ICV) computed over part of the packet header? 
4.	Is there something in your approach that would prevent an attacker from a replay attack?
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?
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?

Tal.

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 9 Jul 2012 10:45:35 -0700

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-masked]> wrote:

> Dear Tal,
>
> Comments inline
>
> On Mon, Jul 9, 2012 at 11:44 AM, Tal Mizrahi <[email-masked]> wrote:
>
>> Hi Balaji,
>>
>> 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.
>
>
> 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.
>
>
> 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.
>>
>>
>

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 9 Jul 2012 22:06:29 +0300

Hi Balaji,

Thanks for the prompt and detailed response.
Please see inline.

Regards,
Tal.

From: Balaji venkat Venkataswami [mailto:[email-masked]]
Sent: Monday, July 09, 2012 6:47 PM
To: Tal Mizrahi
Cc: [email-masked]; Shankar Raman M J; [email-masked]; [email-masked]
Subject: Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ...

Dear Tal,

Comments inline
On Mon, Jul 9, 2012 at 11:44 AM, Tal Mizrahi <[email-masked]<mailto:[email-masked]>> wrote:
Hi Balaji,

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.

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.
[TM] Right. Unless I am missing something, that sounds like a variant of an ICV: it basically produces a label which is a function(packet payload, pre-shared secret). That is essentially what an ICV does, unless I am missing something?

For a reply attack to succeed, the replay should time the labels correctly otherwise the traffic gets rejected.
[TM] Right, so assuming the attacker is "fast enough", the attacker can replay during the time slice (which is ~seconds)?

Yes. It is available as +or- 1 unit (usually seconds) in the algorithm. Maybe a little more fine tuning is required on this.

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.
[TM] Since an ICV uses a pre-shared key, even if the algorithm is well-known to the attacker, the attacker cannot forge/spoof it, assuming that the attacker is not exposed to the key. ICV mechanisms typically support anti replay, e.g., the IPsec AH.

thanks and regards,

Tal.

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 9 Jul 2012 19:09:45 -0400

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-masked] [mailto:[email-masked]] On Behalf Of Bhargav Bhikkaji
Sent: Monday, July 09, 2012 3:45 PM
To: Greg Mirsky; Balaji venkat Venkataswami
Cc: [email-masked]; Shankar Raman M J; [email-masked]; [email-masked]
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-masked] [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Monday, July 09, 2012 10:46 AM
To: Balaji venkat Venkataswami
Cc: [email-masked]; Shankar Raman M J; [email-masked]; [email-masked]
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-masked]<mailto:[email-masked]>> wrote:
Dear Tal,

Comments inline

thanks and regards,

Tal.

---

From: Bhargav Bhikkaji <[email-masked]>
Date: Mon, 9 Jul 2012 15:45:04 -0700

Dear Greg,

Thanks

Dear Balaji,

Regards,
Greg

Comments inline

thanks and regards,

Tal.

---

From: Bhargav Bhikkaji <[email-masked]>
Date: Mon, 9 Jul 2012 19:59:12 -0700

Hi Tal,

Thanks for your comments. Pls see inline [BB] for response

-Bhargav

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tal Mizrahi
Sent: Monday, July 09, 2012 12:06 PM
To: Balaji venkat Venkataswami
Cc: [email-masked]; Shankar Raman M J; [email-masked]; [email-masked]
Subject: RE: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ...

Hi Balaji,

Regards,
Tal.

Dear Tal,

Comments inline

[BB]: Agreed, the scheme we proposed is a of ICV scheme.

[BB]: We had submitted a draft where certain bits of IPSec digital signature is used as "additional label". This would help to identify forged/spoofed packet.

http://tools.ietf.org/html/draft-bhargav-l3vpn-inter-provider-optcsec-01

thanks and regards,

Tal.

---

From: Balaji venkat Venkataswami <[email-masked]>
Date: Mon, 9 Jul 2012 21:17:06 +0530

Dear Tal,

Comments inline

On Mon, Jul 9, 2012 at 11:44 AM, Tal Mizrahi <[email-masked]> wrote:

> 1.      Since the label hopping mechanism relies on PTP, I understand that
> PTP traffic itself does not use label hopping, right?
>

> 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.

thanks and regards,

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 10 Jul 2012 09:07:35 +0100

> 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.
>
Given that forwarders are work conserving, a packet that has already 
started will go to completion, so a high priority  packet arriving after 
the transmit decision has been taken by the forwarder waits. The now 
devalued timing packet goes ahead of all other packets, some of which 
are less devalued by the delay. I am worried that giving timing packet 
priority degrades the network without achieving anything for the timing 
system.

Do we have any measured evidence that sending timing packets with a high 
priority is actually beneficial? If so can someone please point me at it.

Thanks

Stewart