Re: [nvo3] [sfc] Question regarding Proof of Transit draft

[Diego R. Lopez]

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) 
> 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
  (section 3.3) that explains above operations.

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

Regards,
Sashank


From: "Diego R. Lopez" 
>
Date: Friday, 26 August 2016 at 6:21 PM
To: "Frank Brockners (fbrockne)" >
Cc: Tal Mizrahi >, sashank dara 
>, 
"draft-brockners-proof-of-tran...@tools.ietf.org"
 
>,
 "ops...@ietf.org" 
>, 
"nvo3@ietf.org" >, 
"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) 
> 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) >; 
Sashank Dara (sadara) >; 
draft-brockners-proof-of-tran...@tools.ietf.org
Cc: s...@ietf.org; 
ops...@ietf.org; nvo3@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 

Re: [nvo3] [sfc] Question regarding Proof of Transit draft

[Sashank Dara (sadara)]

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
  (section 3.3) that explains above operations.

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

Regards,
Sashank


From: "Diego R. Lopez" 
>
Date: Friday, 26 August 2016 at 6:21 PM
To: "Frank Brockners (fbrockne)" >
Cc: Tal Mizrahi >, sashank dara 
>, 
"draft-brockners-proof-of-tran...@tools.ietf.org"
 
>,
 "ops...@ietf.org" 
>, 
"nvo3@ietf.org" >, 
"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) 
> 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) >; 
Sashank Dara (sadara) >; 
draft-brockners-proof-of-tran...@tools.ietf.org
Cc: s...@ietf.org; 
ops...@ietf.org; nvo3@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
Cc: s...@ietf.org; 
ops...@ietf.org; nvo3@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