Re: [nvo3] Question regarding Proof of Transit draft

2016-07-20 Thread Tal Mizrahi 
Hi Frank,

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

In a nutshell, YES.
I don't think integrity protection is a requirement here.
Path validation is the requirement that you guys have raised, and I believe it 
is an important requirement.
Integrity protection is a way to satisfy the requirement.

Cheers,
Tal.


From: Frank Brockners (fbrockne) [mailto:fbroc...@cisco.com]
Sent: Wednesday, July 20, 2016 9:16 AM
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,

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 - 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) >; Frank 
Brockners (fbrockne) >; 
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,

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);

Re: [nvo3] Question regarding Proof of Transit draft

2016-07-20 Thread Frank Brockners (fbrockne) 
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 - 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) >; Frank 
Brockners (fbrockne) >; 
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,

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

Re: [nvo3] Question regarding Proof of Transit draft

2016-07-20 Thread Sashank Dara (sadara) 


>[SD] The attack is valid only if the attacker can get away bypassing a service 
>function/node.
>For example, if the attacker bypasses a node and if POT determines it did not 
>bypass is a valid attack on the system.

I would phrase it this way: *Given* a packet that did not go through its 
desired path, the attacker can easily make you think that it *did* go through 
the desired path.
Sounds like a very significant vulnerability.


If a packet did not go through the firewall (for one reason or another), the 
attacker will make you think that it did go through the firewall.


[SD]  At a high level , looks like it is , Because each node did not really 
digitially sign the packet that it infact went through it .
We shall investigate what light weight mitigation techniques could be 
incorporated as we wanted to avoid heavy encryptions doing this inband at each 
node.


Thanks again for point this .

Regards,
Sashank



Cheers,
Tal.


From: Sashank Dara (sadara) [mailto:sad...@cisco.com]
Sent: Wednesday, July 20, 2016 4:31 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); 
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



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.

[SD] The attack is valid only if the attacker can get away bypassing a service 
function/node.
For example, if the attacker bypasses a node and if POT determines it did not 
bypass is a valid attack on the system.

In the current state, there is no way an attacker can get away as we determine 
the exact path the packet travelled (aim of the draft) .
I reiterate that the verifier needs to handle what to do with the path 
reconstructed !
We could emphasize this in our next draft , but it would be beyond scope of POT 
to determine what to do with the path constructed.
IMO, It would be highly application specific.


Regards,
Sashank



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 – 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) >; Frank 
Brockners (fbrockne) >; 
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,

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)

Re: [nvo3] Question regarding Proof of Transit draft

2016-07-19 Thread Sashank Dara (sadara) 


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.

[SD] The attack is valid only if the attacker can get away bypassing a service 
function/node.
For example, if the attacker bypasses a node and if POT determines it did not 
bypass is a valid attack on the system.

In the current state, there is no way an attacker can get away as we determine 
the exact path the packet travelled (aim of the draft) .
I reiterate that the verifier needs to handle what to do with the path 
reconstructed !
We could emphasize this in our next draft , but it would be beyond scope of POT 
to determine what to do with the path constructed.
IMO, It would be highly application specific.


Regards,
Sashank



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 – 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) >; Frank 
Brockners (fbrockne) >; 
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,

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;
 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;
 s...@ietf.org
Subject: RE:

Re: [nvo3] Question regarding Proof of Transit draft

2016-07-19 Thread Tal Mizrahi 
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 - 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) >; Frank 
Brockners (fbrockne) >; 
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,

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

Re: [nvo3] Question regarding Proof of Transit draft

2016-07-19 Thread Frank Brockners (fbrockne) 
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) ; Frank Brockners (fbrockne) 
; 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,

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

Re: [nvo3] Question regarding Proof of Transit draft

2016-07-19 Thread Tal Mizrahi 
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; 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; 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;
 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