Hi Sashank,

(coming back to this as soon as my holidays and the backlog they caused allow 
me)

Thanks! I must confess I attended Frank’s presentation and went directly to my 
interpretation of Shamir’s polynomials, overlooking some of the optimizations 
you propose. And coming back to what Frank asked a couple of messages before in 
the thread I fully agree it is worthwhile to pursue this in SFC. I can think of 
applications in NFV-space, and in the scenario of the hierarchical SFC some of 
us are proposing. In fact, I’ve been discussing this with other colleagues at 
the ETSI NFV meeting I am attending now.

Be goode,


On 1 Sep 2016, at 15:22 , Sashank Dara (sadara) 
<sad...@cisco.com<mailto:sad...@cisco.com>> wrote:

Hi Diego ,

Thanks for bringing up an excellent point on the computational complexity.
Fortunately the algorithm takes a cumulative approach which is agnostic of the 
path length.

  1.  Controller performs few trivial steps like choosing long term secrets, 
calculating the LPC values for each node and provisioning.
  2.  Each node only performs 2 additions, 1 multiplication and 1 mod(prime) 
operation per packet .
  3.  Verifier also performs step (2) and additionally performs 1 addition, 1 
mod(prime) and comparison to verify !

The above steps hold good for any length of nodes.

A detailed example is provided for illustrative purposes in our 
draft<https://tools.ietf.org/html/draft-brockners-proof-of-transit-01#section-3.3>
  (section 3.3) that explains above operations.

Would be happy to discuss more on the above, if needed.

Regards,
Sashank


From: "Diego R. Lopez" 
<diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com>>
Date: Friday, 26 August 2016 at 6:21 PM
To: "Frank Brockners (fbrockne)" <fbroc...@cisco.com<mailto:fbroc...@cisco.com>>
Cc: Tal Mizrahi <ta...@marvell.com<mailto:ta...@marvell.com>>, sashank dara 
<sad...@cisco.com<mailto:sad...@cisco.com>>, 
"draft-brockners-proof-of-tran...@tools.ietf.org<mailto:draft-brockners-proof-of-tran...@tools.ietf.org>"
 
<draft-brockners-proof-of-tran...@tools.ietf.org<mailto:draft-brockners-proof-of-tran...@tools.ietf.org>>,
 "opsawg@ietf.org<mailto:opsawg@ietf.org>" 
<opsawg@ietf.org<mailto:opsawg@ietf.org>>, 
"n...@ietf.org<mailto:n...@ietf.org>" <n...@ietf.org<mailto:n...@ietf.org>>, 
"s...@ietf.org<mailto:s...@ietf.org>" <s...@ietf.org<mailto:s...@ietf.org>>
Subject: Re: [sfc] Question regarding Proof of Transit draft

Hi Frank,

This is a really interesting piece of work, and I must say we have been 
discussing the PoT issue with some customers (though we used to call it 
“assured path traversal”) and we have been exploring possible solutions, trying 
to combine good-enough security with a reasonable amount of computational 
complexity, and I am glad to see a practical proposal addressing this problem. 
I had a brief conversation with Carlos while in Berlin, but I am afraid that 
the IETF week was too hectic for a detailed discussion.

Let me add to Tal’s analysis a third issue to consider. My understanding of 
Shamir’s polynomials is that they can be used to reconstruct a secret from N 
pieces you need a polynomial of degree N-1, so that implies that the 
verification is limited to a certain number of SFs (or SFFs), depending on the 
degree of the applied polynomial. We’d need and assessment on the computational 
complexity associated with path length and the requirements for adaptation of 
the PoT nodes (I guess SDN/NFV could play a role there…)

Be goode,

On 20 Jul 2016, at 09:16 , Frank Brockners (fbrockne) 
<fbroc...@cisco.com<mailto:fbroc...@cisco.com>> wrote:

Hi Tal,

well... if you could protect the integrity of the data stream between source 
and destination, you would not be able to swap the content of a packet – which 
is what your attack is all about. Rather than continue arguing the point, let’s 
acknowledge that it is a valid attack and let’s look for a solution :-). We’ll 
need to couple POT to integrity protection of the packet.

Hence, I’d like to come back to my question asked below:
Do you (and the entire SFC team here) think it is worthwhile to provide a 
solution for a deployment which is expected to *not* alter the packet payload?

Thanks, Frank

From: Tal Mizrahi [mailto:ta...@marvell.com]
Sent: Dienstag, 19. Juli 2016 18:15
To: Frank Brockners (fbrockne) <fbroc...@cisco.com<mailto:fbroc...@cisco.com>>; 
Sashank Dara (sadara) <sad...@cisco.com<mailto:sad...@cisco.com>>; 
draft-brockners-proof-of-tran...@tools.ietf.org<mailto:draft-brockners-proof-of-tran...@tools.ietf.org>
Cc: s...@ietf.org<mailto:s...@ietf.org>; 
opsawg@ietf.org<mailto:opsawg@ietf.org>; n...@ietf.org<mailto:n...@ietf.org>
Subject: RE: Question regarding Proof of Transit draft

Hi Frank,

The POT replacement attack (1.) is not an attack on the integrity. It is an 
attack on the path verification.
This simple attack can cause the verifier to accept a packet that did not go 
through the firewall SF (even though it should). I believe this is exactly the 
problem you were aiming to address in this draft.

Thanks,
Tal.

From: Frank Brockners (fbrockne) [mailto:fbroc...@cisco.com]
Sent: Tuesday, July 19, 2016 6:00 PM
To: Tal Mizrahi; Sashank Dara (sadara); 
draft-brockners-proof-of-tran...@tools.ietf.org<mailto:draft-brockners-proof-of-tran...@tools.ietf.org>
Cc: s...@ietf.org<mailto:s...@ietf.org>; 
opsawg@ietf.org<mailto:opsawg@ietf.org>; n...@ietf.org<mailto:n...@ietf.org>
Subject: RE: Question regarding Proof of Transit draft

Hi Tal,

thanks for the summary. We’ll provide more details on 2. Per my earlier point – 
1. is an interesting discussion, given that we don’t claim to provide integrity 
protection for the packet payload. Or in other terms – to be exact: What POT 
provides is a proof that the POT-header/meta-data transited all the required 
nodes. There is no association (and thus proof) provided for the additional 
data carried along with the POT-header – neither header nor payload. As a 
consequence, attacks which change the packet payload won’t be 
detected/mitigated. We’ll explicitly state this in the security considerations 
in the next rev of the document.
What we could consider is linking the RND number to CRC across the packet 
payload or similar – but that way we’d restrict the applicability to 
deployments where the packet payload isn’t changed across the path (which might 
not apply to certain deployment – e.g. WAN optimization / compression schemes).
Do you think it is worthwhile to provide a solution for a deployment which is 
expected to not alter the packet payload?

Thanks,
Frank

From: Tal Mizrahi [mailto:ta...@marvell.com]
Sent: Dienstag, 19. Juli 2016 17:44
To: Sashank Dara (sadara) <sad...@cisco.com<mailto:sad...@cisco.com>>; Frank 
Brockners (fbrockne) <fbroc...@cisco.com<mailto:fbroc...@cisco.com>>; 
draft-brockners-proof-of-tran...@tools.ietf.org<mailto:draft-brockners-proof-of-tran...@tools.ietf.org>
Cc: s...@ietf.org<mailto:s...@ietf.org>; 
opsawg@ietf.org<mailto:opsawg@ietf.org>; n...@ietf.org<mailto:n...@ietf.org>
Subject: RE: Question regarding Proof of Transit draft

Hi,

To summarize my take on this thread:
The proposed mechanism has two significant vulnerabilities that (in my 
understanding) are currently not addressed:
1.       A man-in-the-middle can replace the POT of packet A with the POT of 
packet B.
2.       It is possible to replay POTs within a certain time window, whose 
length is determined by the timestamp resolution.

Sashank, thanks for agreeing to look into it further. I am looking forward to 
your insights on this.

Regards,
Tal.

Link to the draft: 
https://tools.ietf.org/html/draft-brockners-proof-of-transit-01



From: Sashank Dara (sadara) [mailto:sad...@cisco.com]
Sent: Tuesday, July 19, 2016 12:20 PM
To: Tal Mizrahi; Frank Brockners (fbrockne); 
draft-brockners-proof-of-tran...@tools.ietf.org<mailto:draft-brockners-proof-of-tran...@tools.ietf.org>;
 s...@ietf.org<mailto:s...@ietf.org>
Subject: Re: Question regarding Proof of Transit draft



I want to ask a simple question:
If the attacker attaches the POT of packet A (indicating the path through 
1,3,5,6) to packet B, will the verifier accept packet B and believe that its 
path was indeed (1,3,5,6)?

[SD] If the verifier is programmed to just validate the POT meta data against 
{1,3,5,6} then yes it accepts it.
If the verifier is programmed to consult a policy database to cross check if 
the reconstructed path {1,3,5,6} is as per the policies then no , it drops it .

But I see your point , that the parameters used in POT data donot consider the 
path or node-ids etc . We shall discuss this internally and get back.

Also, We shall get back with more concrete numbers of the timestamp resolution 
and cache sizes (or other better approaches).

Thank you so much for all the inputs.



From: Tal Mizrahi
Sent: Tuesday, July 19, 2016 10:28 AM
To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); 
draft-brockners-proof-of-tran...@tools.ietf.org<mailto:draft-brockners-proof-of-tran...@tools.ietf.org>;
 s...@ietf.org<mailto:s...@ietf.org>
Subject: RE: Question regarding Proof of Transit draft

Dear Sashank,

I really appreciate the quick and detailed responses.

>>>Lets take correct path taken by Packet A  to be Path1 - ( 1,3,5,6) nodes.
>>>Lets assume incorrect path to be Packet B i.e. Path2 -  (1,2,3,6).
>>>
>>>If the attacker could take values from Path1 and reattach them to Path2 ,
>>>the reconstruction for PacketB would result in (1,3,5,6) instead of 
>>>(1,2,3,6).
>>>This could be compared with topology/policy db information for any policy
>>>violations. POT does not enforce a particular path to be taken.
>>So packet B skipped node 5 (e.g. the firewall SF), but the verifier believes 
>>it went through the correct path.
>>Would you agree?
>[SD] The verifier only constructs the path the packet took accurately, it is 
>upto
>the application to determine whether it violates any policies (I.e missing any 
>function)
>The bottom line is , an attacker taking a different path cannot get away with 
>it !
>The whole intent of “proof-of-transit” is to prove the path packet has taken 
>exactly.
>POT does not define whether it good/bad path. It is upto high level 
>applications on what
>do with “reconstructed” path.



I want to ask a simple question:
If the attacker attaches the POT of packet A (indicating the path through 
1,3,5,6) to packet B, will the verifier accept packet B and believe that its 
path was indeed (1,3,5,6)?


>>Hmmm… Let’s say we are talking about traffic at 10 Gbps, which is roughly
>>1 million packets per second. That would mean the verifier has to store a 
>>million values of RND-2.
>>Moreover, every time a packet arrives, the verifier would have to compare its
>>RND-2 value with the 1 million stored values, in order to verify there is no 
>>replay.
>>That does not sound feasible.
>>Am I missing something here?
>[SD] Second level precision is only an example, we could use as much precision 
>as we want to reduce the number of values to be cached !

My point is that assuming reasonable resources are used, the mechanism is 
vulnerable to a replay attack.
In order to prove me wrong, can you present concrete numbers of the timestamp 
resolution and the cache size?
Otherwise, you may consider using a sequence number + sliding window (e.g., as 
in IPsec).


Thanks,
Tal.



From: Sashank Dara (sadara) [mailto:sad...@cisco.com]
Sent: Tuesday, July 19, 2016 9:56 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); 
draft-brockners-proof-of-tran...@tools.ietf.org<mailto:draft-brockners-proof-of-tran...@tools.ietf.org>;
 s...@ietf.org<mailto:s...@ietf.org>
Subject: Re: Question regarding Proof of Transit draft




>[SD] Ok. This is an interesting attack.
>
>Lets take correct path taken by Packet A  to be Path1 - ( 1,3,5,6) nodes.
>Lets assume incorrect path to be Packet B i.e. Path2 -  (1,2,3,6).
>
>If the attacker could take values from Path1 and reattach them to Path2 ,
>the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6).
>This could be compared with topology/policy db information for any policy
>violations. POT does not enforce a particular path to be taken.

So packet B skipped node 5 (e.g. the firewall SF), but the verifier believes it 
went through the correct path.
Would you agree?

[SD] The verifier only constructs the path the packet took accurately, it is 
upto the application to determine whether it violates any policies (I.e missing 
any function)
The bottom line is , an attacker taking a different path cannot get away with 
it ! The whole intent of “proof-of-transit” is to prove the path packet has 
taken exactly.
POT does not define whether it good/bad path. It is upto high level 
applications on what do with “reconstructed” path.


Hmmm… Let’s say we are talking about traffic at 10 Gbps, which is roughly 1 
million packets per second. That would mean the verifier has to store a million 
values of RND-2.
Moreover, every time a packet arrives, the verifier would have to compare its 
RND-2 value with the 1 million stored values, in order to verify there is no 
replay.
That does not sound feasible.
Am I missing something here?

[SD] Second level precision is only an example, we could use as much precision 
as we want to reduce the number of values to be cached !


Sashank



From: Sashank Dara (sadara) [mailto:sad...@cisco.com]
Sent: Tuesday, July 19, 2016 8:33 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); 
draft-brockners-proof-of-tran...@tools.ietf.org<mailto:draft-brockners-proof-of-tran...@tools.ietf.org>;
 s...@ietf.org<mailto:s...@ietf.org>
Subject: Re: Question regarding Proof of Transit draft

Inline ..


We have two consecutive packets, A and B:
- Packet A that went through the correct path and has a correct POT.
- Packet B that did not go through the correct path and does not have a correct 
POT.
 Now the attacker performs a ‘mix and match’ attack, by taking the correct POT 
from packet A and attaching it to packet B.
The attacker also terminates packet A.
There is no replay here, because the verifier receives the correct POT only 
once. The problem is that the correct POT happens to arrive with packet B. :(
Thus, packet B appears okay to the verifier, even though it did not go through 
the correct path.

Is there a way to mitigate this attack?

[SD] Ok. This is an interesting attack.

Lets take correct path taken by Packet A  to be Path1 - ( 1,3,5,6) nodes.
Lets assume incorrect path to be Packet B i.e. Path2 -  (1,2,3,6).

If the attacker could take values from Path1 and reattach them to Path2 , the 
reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6).
This could be compared with topology/policy db information for any policy 
violations. POT does not enforce a particular path to be taken.
 It just reconstructs the particular path taken by the packets.

Do you mean that there is a one-second-vulnerability for replay attacks?
One second is practically forever.

[SD] Not really , the verifier could cache the RND-2 numbers used in the time 
slice of one second and flush off after every second. There is no 
one-second-vulnerability as such, if the verifier caches those values.

Effective replay prevention is typically performed using a sequence number, 
with a sliding window to allow out-of-order packets. Wouldn’t it be possible to 
incorporate such a sequence number into your mechanism?

[SD] Time stamp is essentially at high level sequence number (at seconds 
level)! The challenge with using complete RND-2 as sequence number is that the 
differential analysis of CML values (across packets) becomes very easy  and 
predictable.
that’s reason we recommend using  ( Timestamp(/ sequence number) + RND )




From: Sashank Dara (sadara) [mailto:sad...@cisco.com]
Sent: Tuesday, July 19, 2016 1:11 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); 
draft-brockners-proof-of-tran...@tools.ietf.org<mailto:draft-brockners-proof-of-tran...@tools.ietf.org>;
 s...@ietf.org<mailto:s...@ietf.org>
Subject: Re: Question regarding Proof of Transit draft

Dear Tal,
Thank you for your interest in our work. More inline with [SD] ..


Right, I am referring to the former. The integrity check is not the issue.
Let’s say we have:
- Packet A that went through the correct path and has a correct POT.
- Packet B that did not go through the correct path and does not have a correct 
POT.

The attacker can ‘launder’ packet B by replacing the (incorrect) POT of packet 
B with the correct POT of packet A (and drop packet A).
Thus, packet B is verified correctly, even though it did not go through the 
correct path.

[SD] This is valid scenario and we have certain in-built mitigation techniques 
and recommendations for the same.
There are two scenarios here

Partial Replay of POT data (Replaying intermediate CMLs)

Attacker cannot reuse few intermediate node’s POT values (from older packet 
traces) as it would disrupt the POLY-3 construction.
On the other hand if the attacker tries to replay entire sequence of CML 
values, he cannot still , because notice that verifier also has a secret share 
of RND-1 and participates in the reconstruction of RND-3.
Verifier’s share of RND-3 is never on wire , so attacker cannot just observe 
the packet traces to reuse and replay it.

Total Replay of POT data (Replaying complete RND-2)

Another trick, attacker could do is by completely reusing RND-2 (but not 
intermediate CML values)
In order to prevent the “Reply Attacks” , we recommend that the RND-2 
(generated per packet) be a combination (I.e. RND2 = “Time Stamp + RND number”)
So in case a passive attacker tries to replay one of the correct but older 
RND-2, the verifier first could check the current timestamp against the 
timestamp retrieved from RND-2.
If the retrieved timestamp is older than current timestamp we drop/raise a flag 
!

There is still a small window , where the attacker could replay it within the 
valid time slice itself but by carefully choosing the time slice we can make it 
nearly impossible for the attacker to replay.
For example , if the Time Stamp chosen is 32 bits , we could get one seconds 
level precision in the time window . So it is highly impossible for the 
attacker to replay within such a small time at such a high packet rates.

Also , the verifier could cache, if needed, certain number of previously used 
RND-2 to mitigate replay attacks.

Hope this clarifies.

_______________________________________________
sfc mailing list
s...@ietf.org<mailto:s...@ietf.org>
https://www.ietf.org/mailman/listinfo/sfc

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com>
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------


________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede 
contener información privilegiada o confidencial y es para uso exclusivo de la 
persona o entidad de destino. Si no es usted. el destinatario indicado, queda 
notificado de que la lectura, utilización, divulgación y/o copia sin 
autorización puede estar prohibida en virtud de la legislación vigente. Si ha 
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente 
por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential 
information intended only for the use of the individual or entity named above. 
If the reader of this message is not the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this transmission in error, do not 
read it. Please immediately reply to the sender that you have received this 
communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode 
conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa 
ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica 
notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização 
pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem 
por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e 
proceda a sua destruição

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: diego.r.lo...@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to