Subject: [sfc] Question regarding Proof of Transit draft

From: Tal Mizrahi <[email-masked]>
Date: Mon, 18 Jul 2016 15:02:28 +0000

Dear Frank,

I have a question regarding draft-brockners-proof-of-transit.
(https://tools.ietf.org/html/draft-brockners-proof-of-transit-01)

Unless I am missing something, the proposed mechanism does not cryptographically protect the packet itself, right?
It seems that there is nothing that cryptographically binds the polynomial-based-metadata to the packet content.

It appears that if you have a legitimate packet that has been stamped with the proof-of-transport, a man-in-the-middle attacker can simply replace the packet payload with a previously stored packet that has not passed the entire service chain, thereby bypassing the service chain.

How can this threat be avoided?

Cheers,
Tal.

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Mon, 18 Jul 2016 16:39:55 +0000

Hi Tal,

thanks for your email. We need to differentiate

*       proving the path packets take, from

*       performing an integrity check on one or a set of packets.
The former is what we do with POT - the latter is something that would typically be up to the application, especially given that the content of the packet might even be transformed/changed as it traverses the network. That said, what the application could choose to do is use the unique sequence number of POT  (i.e. the identifier of the second, public polynomial - called "random" in the draft) in the packet to "link/associate" the content to this sequence number (i.e. "random") to detect whether the content of the packet has been corrupted or changed.

Regards, Frank

From: Tal Mizrahi [mailto:[email-masked]]
Sent: Montag, 18. Juli 2016 17:02
To: Frank Brockners (fbrockne) <[email-masked]>; [email-masked]; [email-masked]
Subject: Question regarding Proof of Transit draft

Dear Frank,

Cheers,
Tal.

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 18 Jul 2016 16:52:41 +0000

Hi Frank,

Many thanks for the prompt response.

>thanks for your email. We need to differentiate
**       proving the path packets take, from
**       performing an integrity check on one or a set of packets.

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.

>That said, what the application could choose to do is use the unique sequence number
>of POT  (i.e. the identifier of the second, public polynomial - called "random" in the
>draft) in the packet to "link/associate" the content to this sequence number (i.e.
>"random") to detect whether the content of the packet has been corrupted or changed.

I don't understand how that resolves the threat above. Would appreciate if you can explain further.

Cheers,
Tal.

From: Frank Brockners (fbrockne) [mailto:[email-masked]]
Sent: Monday, July 18, 2016 6:40 PM
To: Tal Mizrahi; [email-masked]; [email-masked]
Subject: RE: Question regarding Proof of Transit draft

Hi Tal,

Regards, Frank

From: Tal Mizrahi [mailto:[email-masked]]
Sent: Montag, 18. Juli 2016 17:02
To: Frank Brockners (fbrockne) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Question regarding Proof of Transit draft

Dear Frank,

Cheers,
Tal.

---

From: "Sashank Dara (sadara)" <[email-masked]>
Date: Mon, 18 Jul 2016 23:10:45 +0000

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

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

---

From: Tal Mizrahi <[email-masked]>
Date: Tue, 19 Jul 2016 05:40:03 +0000

Dear Sashank,

Thanks for the detailed response.

I am not sure we are on the same page.
The attack I was describing is not a replay attack.

Here is a more detailed description of the attack:

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?

Regarding the replay mechanism you described:

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

Do you mean that there is a one-second-vulnerability for replay attacks?
One second is practically forever.
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?

Thanks,
Tal.

From: Sashank Dara (sadara) [mailto:[email-masked]]
Sent: Tuesday, July 19, 2016 1:11 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); [email-masked]; [email-masked]
Subject: Re: Question regarding Proof of Transit draft

Dear Tal,

Hope this clarifies.

---

From: "Sashank Dara (sadara)" <[email-masked]>
Date: Tue, 19 Jul 2016 06:33:16 +0000

Inline ..

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

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

[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:[email-masked]]
Sent: Tuesday, July 19, 2016 1:11 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Question regarding Proof of Transit draft

Dear Tal,

Hope this clarifies.

---

From: Tal Mizrahi <[email-masked]>
Date: Tue, 19 Jul 2016 07:36:51 +0000

Dear Sashank,

I appreciate the detailed responses.

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

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?

Thanks,
Tal.

From: Sashank Dara (sadara) [mailto:[email-masked]]
Sent: Tuesday, July 19, 2016 8:33 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); [email-masked]; [email-masked]
Subject: Re: Question regarding Proof of Transit draft

Inline ..

Dear Tal,

Hope this clarifies.

---

From: "Sashank Dara (sadara)" <[email-masked]>
Date: Tue, 19 Jul 2016 07:55:54 +0000

[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

Inline ..

 Now the attacker performs a ‘mix and match’ attack, by taking the correct POT from packet A and attaching it to packet B.

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 )

Dear Tal,

Let’s say we have:

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.

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.

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 !

Hope this clarifies.

---

From: Tal Mizrahi <[email-masked]>
Date: Tue, 19 Jul 2016 08:28:24 +0000

Dear Sashank,

I really appreciate the quick and detailed responses.

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

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:[email-masked]]
Sent: Tuesday, July 19, 2016 9:56 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); [email-masked]; [email-masked]
Subject: Re: Question regarding Proof of Transit draft

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

Sashank

Inline ..

Dear Tal,

Hope this clarifies.

---

From: "Sashank Dara (sadara)" <[email-masked]>
Date: Tue, 19 Jul 2016 10:19:52 +0000

[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 <[email-masked]>
Date: Tue, 19 Jul 2016 15:43:43 +0000

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:[email-masked]]
Sent: Tuesday, July 19, 2016 12:20 PM
To: Tal Mizrahi; Frank Brockners (fbrockne); [email-masked]; [email-masked]
Subject: Re: Question regarding Proof of Transit draft

From: Tal Mizrahi
Sent: Tuesday, July 19, 2016 10:28 AM
To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); [email-masked]; [email-masked]
Subject: RE: Question regarding Proof of Transit draft

Dear Sashank,

Thanks,
Tal.

Sashank

Inline ..

Dear Tal,

Hope this clarifies.

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Tue, 19 Jul 2016 15:59:49 +0000

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:[email-masked]]
Sent: Dienstag, 19. Juli 2016 17:44
To: Sashank Dara (sadara) <[email-masked]>; Frank Brockners (fbrockne) <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Question regarding Proof of Transit draft

Hi,

Regards,
Tal.

From: Tal Mizrahi
Sent: Tuesday, July 19, 2016 10:28 AM
To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Question regarding Proof of Transit draft

Dear Sashank,

Thanks,
Tal.

Sashank

Inline ..

Dear Tal,

Hope this clarifies.

---

From: Tal Mizrahi <[email-masked]>
Date: Tue, 19 Jul 2016 16:14:30 +0000

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:[email-masked]]
Sent: Tuesday, July 19, 2016 6:00 PM
To: Tal Mizrahi; Sashank Dara (sadara); [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Question regarding Proof of Transit draft

Hi Tal,

Thanks,
Frank

From: Tal Mizrahi [mailto:[email-masked]]
Sent: Dienstag, 19. Juli 2016 17:44
To: Sashank Dara (sadara) <[email-masked]<mailto:[email-masked]>>; Frank Brockners (fbrockne) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Question regarding Proof of Transit draft

Hi,

Regards,
Tal.

From: Tal Mizrahi

Dear Sashank,

Thanks,
Tal.

Sashank

Inline ..

Dear Tal,

Hope this clarifies.

---

From: "Sashank Dara (sadara)" <[email-masked]>
Date: Wed, 20 Jul 2016 02:30:47 +0000

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

To: Tal Mizrahi; Sashank Dara (sadara); [email-masked]<mailto:[email-masked]>

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

Hi,

Regards,
Tal.

From: Tal Mizrahi

Dear Sashank,

>The whole intent of “proof-of-transit” is to prove the path packet has taken exactly.
>do with “reconstructed” path.

>>Hmmm… Let’s say we are talking about traffic at 10 Gbps, which is roughly

Thanks,
Tal.

Sashank

Inline ..

Dear Tal,

Hope this clarifies.

---

From: Tal Mizrahi <[email-masked]>
Date: Wed, 20 Jul 2016 04:30:28 +0000

Hi Sashank,

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

Cheers,
Tal.

From: Sashank Dara (sadara) [mailto:[email-masked]]
Sent: Wednesday, July 20, 2016 4:31 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Question regarding Proof of Transit draft

Regards,
Sashank

Thanks,
Tal.

Hi Tal,

Thanks,
Frank

Hi,

Regards,
Tal.

From: Tal Mizrahi

Dear Sashank,

Thanks,
Tal.

Sashank

Inline ..

Dear Tal,

Hope this clarifies.

---

From: "Sashank Dara (sadara)" <[email-masked]>
Date: Wed, 20 Jul 2016 06:23:59 +0000

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

To: Tal Mizrahi; Frank Brockners (fbrockne); [email-masked]<mailto:[email-masked]>

Regards,
Sashank

Thanks,
Tal.

Hi Tal,

Thanks,
Frank

Hi,

Regards,
Tal.

From: Tal Mizrahi

Dear Sashank,

Thanks,
Tal.

Sashank

Inline ..

Dear Tal,

Hope this clarifies.

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Wed, 20 Jul 2016 07:16:02 +0000

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:[email-masked]]
Sent: Dienstag, 19. Juli 2016 18:15
To: Frank Brockners (fbrockne) <[email-masked]>; Sashank Dara (sadara) <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Question regarding Proof of Transit draft

Hi Frank,

Thanks,
Tal.

Hi Tal,

Thanks,
Frank

Hi,

Regards,
Tal.

From: Tal Mizrahi

Dear Sashank,

Thanks,
Tal.

Sashank

Inline ..

Dear Tal,

Hope this clarifies.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 20 Jul 2016 08:18:08 +0100

What is worrying me in this conversations is the discrepancy between the stated
aim in draft-brockners-proof-of-transit and the function provided by the draft.
I'm not (at the moment ;-) picking hols in what the S**3 scheme achieves, but I
am questioning whether it provides enough to be useful in the context stated.
 
So draft-brockners-proof-of-transit says...
 
> This document defines mechanisms to
> securely prove that traffic transited the defined path.
 
and 
 
>  In certain cases regulatory
>  obligations or a compliance policy require operators to prove that
>  all packets that are supposed to follow a specific path are indeed
>  being forwarded across and exact set of pre-determined nodes.
 
Shamir as applied in this document does not meet those criteria. It only shows
that all members of a defined set of nodes were traversed at some point along
the path. It neither guarantees ordering, nor does it protect against the
insertion of additional nodes on the path.
 
Other parts of the document are more clear about exactly this point. it is not
clear to me, therefore, whether the intention is misstated in the text I quoted,
or whether the proposed solution (while good at what it does) is inadequate for
the purpose.
 
BTW,  think it is not clear in the text that the order of the polynomial must
count the verifying node. I.e., the verifying node must also insert a point on
the curve. This is needed because otherwise the full set of points is included
in a message on the wire and the polynomial becomes vulnerable.
 
Thanks,
Adrian
 
From: OPSAWG [mailto:[email-masked]] On Behalf Of Tal Mizrahi
Sent: 20 July 2016 05:30
To: Sashank Dara (sadara); Frank Brockners (fbrockne);
[email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [OPSAWG] Question regarding Proof of Transit draft
 
Hi Sashank,
 
>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.
 
Cheers,
Tal.

From: Sashank Dara (sadara) [mailto:[email-masked]] 
Sent: Wednesday, July 20, 2016 4:31 AM
To: Tal Mizrahi; Frank Brockners (fbrockne);
[email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
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:[email-masked]] 
Sent: Tuesday, July 19, 2016 6:00 PM
To: Tal Mizrahi; Sashank Dara (sadara);
[email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
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:[email-masked]] 
Sent: Dienstag, 19. Juli 2016 17:44
To: Sashank Dara (sadara) <[email-masked]>; Frank Brockners (fbrockne)
<[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
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:[email-masked]] 
Sent: Tuesday, July 19, 2016 12:20 PM
To: Tal Mizrahi; Frank Brockners (fbrockne);
[email-masked]; [email-masked]
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). 

 
From: Tal Mizrahi 
Sent: Tuesday, July 19, 2016 10:28 AM
To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne);
[email-masked]; [email-masked]
Subject: RE: Question regarding Proof of Transit draft
 
Dear Sashank,

 
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 
>[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:[email-masked]] 
Sent: Tuesday, July 19, 2016 9:56 AM
To: Tal Mizrahi; Frank Brockners (fbrockne);
[email-masked]; [email-masked]
Subject: Re: Question regarding Proof of Transit draft

 
>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:[email-masked]] 
Sent: Tuesday, July 19, 2016 8:33 AM
To: Tal Mizrahi; Frank Brockners (fbrockne);
[email-masked]; [email-masked]
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. L
Thus, packet B appears okay to the verifier, even though it did not go through
the correct path.

 
 
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. 

[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:[email-masked]] 
Sent: Tuesday, July 19, 2016 1:11 AM
To: Tal Mizrahi; Frank Brockners (fbrockne);
[email-masked]; [email-masked]
Subject: Re: Question regarding Proof of Transit draft
 
Dear Tal,

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 

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. 

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.

---

From: Tal Mizrahi <[email-masked]>
Date: Wed, 20 Jul 2016 07:57:16 +0000

Hi Frank,

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

Sent: Wednesday, July 20, 2016 9:16 AM

Hi Tal,

Thanks, Frank

To: Frank Brockners (fbrockne) <[email-masked]<mailto:[email-masked]>>; Sashank Dara (sadara) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Hi Frank,

Thanks,
Tal.

Hi Tal,

Thanks,
Frank

Hi,

Regards,
Tal.

From: Tal Mizrahi

Dear Sashank,

Thanks,
Tal.

Sashank

Inline ..

Dear Tal,

Hope this clarifies.

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Wed, 20 Jul 2016 08:51:20 +0000

Adrian,

Thanks - very helpful comments. Point well taken on the fact that POT using SSS is to verify that a specific set of nodes has been traversed - not all nodes, nor in a specific order. We'll definitively provide clearer and cleaner language in the next revision.
We'll also extend the draft with another approach (based on nested crypto) which would be order preserving, at the expense to be  computationally more intense.
Also per your note, we'll also expand on the role of the verifier in the next revision.

Frank

From: Adrian Farrel [mailto:[email-masked]]
Sent: Mittwoch, 20. Juli 2016 09:18
To: 'Tal Mizrahi' <[email-masked]>; Sashank Dara (sadara) <[email-masked]>; Frank Brockners (fbrockne) <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [OPSAWG] Question regarding Proof of Transit draft

What is worrying me in this conversations is the discrepancy between the stated aim in draft-brockners-proof-of-transit and the function provided by the draft. I'm not (at the moment ;-) picking hols in what the S**3 scheme achieves, but I am questioning whether it provides enough to be useful in the context stated.

and

>  being forwarded across and exact set of pre-determined nodes.

Shamir as applied in this document does not meet those criteria. It only shows that all members of a defined set of nodes were traversed at some point along the path. It neither guarantees ordering, nor does it protect against the insertion of additional nodes on the path.

Other parts of the document are more clear about exactly this point. it is not clear to me, therefore, whether the intention is misstated in the text I quoted, or whether the proposed solution (while good at what it does) is inadequate for the purpose.

BTW,  think it is not clear in the text that the order of the polynomial must count the verifying node. I.e., the verifying node must also insert a point on the curve. This is needed because otherwise the full set of points is included in a message on the wire and the polynomial becomes vulnerable.

Thanks,
Adrian

From: OPSAWG [mailto:[email-masked]] On Behalf Of Tal Mizrahi
Sent: 20 July 2016 05:30
To: Sashank Dara (sadara); Frank Brockners (fbrockne); [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [OPSAWG] Question regarding Proof of Transit draft

Hi Sashank,

Cheers,
Tal.

Regards,
Sashank

Thanks,
Tal.

Hi Tal,

Thanks,
Frank

Hi,

Regards,
Tal.

From: Tal Mizrahi

Dear Sashank,

Thanks,
Tal.

Sashank

Inline ..

Dear Tal,

Hope this clarifies.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 20 Jul 2016 09:33:46 +0000

Tal,

> On Jul 20, 2016, at 6:30 AM, Tal Mizrahi <[email-masked]> wrote:
> 
> Hi Sashank,
> 

Let’s step back a little — the “vulnerability” you are describing comes with the assumption that a MIIT attacker can intercept a packet, extract a TLV from the MD Type 2, drop the packet; then intercept another packet (with the knowledge that it took a different path, so maybe the attacker is using inband OAM as well :-), and insert (or modify) a TLV within the content of the MD Type 2 within the content of NSH, within a specific packet.

This sounds quite sophisticated.

Do you think that if an MIIT can have that surface of attack and sophistication, they can mess up with other even more critical things? Changing a Tenant ID, messing up with Policy Groups, etc? 

My point is that what you seem to be describing is a generic threat use case and not a specific vulnerability. Engineering is about trade-offs (i.e., solutions that have practical performance) and about placing the solution in the most effective place.

I’m not deflecting but at the same time, let’s understand the assumptions you are making for this potential attack you describe, as part of the threat analysis.

Thanks,

— Carlos.

>>>> Lets take correct path taken by Packet A  to be Path1 - ( 1,3,5,6) nodes

---

From: Tal Mizrahi <[email-masked]>
Date: Wed, 20 Jul 2016 09:42:53 +0000

Hi Carlos,

>Let’s step back a little — the “vulnerability” you are describing comes with the
>assumption that a MIIT attacker can intercept a packet, extract a TLV from
>the MD Type 2, drop the packet; then intercept another packet (with the
>knowledge that it took a different path, so maybe the attacker is using inband
>OAM as well :-), and insert (or modify) a TLV within the content of the MD
>Type 2 within the content of NSH, within a specific packet.
>

I am not sure I agree this is a 'sophisticated' attack.
The attack does not require any cryptographic or algorithmic functionality, and to that end it is very lightweight in terms of processing resources.

If this kind of attack is not within the scope here, then I would argue that you don't need a cryptographic mechanism at all. All you need is a TLV that specifies the list of nodes. However, I believe that you did want to try to mitigate MITM attackers. Correct me if I am wrong.

I fully agree that the threat model needs to be well-defined. I hope you will elaborate more on the threat model in the next version of the draft.

Cheers,
Tal.

>-----Original Message-----
>From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
>Sent: Wednesday, July 20, 2016 11:34 AM
>To: Tal Mizrahi
>Cc: Sashank Dara (sadara); Frank Brockners (fbrockne); draft-brockners-proof-
>[email-masked]; [email-masked]; [email-masked]; [email-masked]
>Subject: MD Type attack (Was: Question regarding Proof of Transit draft)
>
>Tal,
>
>>> 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.
>Let’s step back a little — the “vulnerability” you are describing comes with the
>assumption that a MIIT attacker can intercept a packet, extract a TLV from
>the MD Type 2, drop the packet; then intercept another packet (with the
>knowledge that it took a different path, so maybe the attacker is using inband
>OAM as well :-), and insert (or modify) a TLV within the content of the MD
>Type 2 within the content of NSH, within a specific packet.
>
>Do you think that if an MIIT can have that surface of attack and
>sophistication, they can mess up with other even more critical things?
>Changing a Tenant ID, messing up with Policy Groups, etc?
>
>My point is that what you seem to be describing is a generic threat use case
>and not a specific vulnerability. Engineering is about trade-offs (i.e., solutions
>that have practical performance) and about placing the solution in the most
>effective place.
>
>I’m not deflecting but at the same time, let’s understand the assumptions you
>are making for this potential attack you describe, as part of the threat
>analysis.
>
>Thanks,
>
>— Carlos.
>
>> Cheers,
>> Tal.
>>
>>
>> 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) .
>> 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.
>> To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-
>[email-masked]<mailto:draft-brockners-proof-of-
>[email-masked]>
>> Cc: [email-masked]<mailto:[email-masked]>;
>[email-masked]<mailto:[email-masked]>;
>[email-masked]<mailto:[email-masked]>
>> 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
>where the packet payload isn't changed across the path (which might not
>apply to certain deployment - e.g. WAN optimization / compression schemes).
>> To: Sashank Dara (sadara)
><[email-masked]<mailto:[email-masked]>>; Frank Brockners (fbrockne)
><[email-masked]<mailto:[email-masked]>>; draft-brockners-
>[email-masked]<mailto:draft-brockners-proof-of-
>[email-masked]>
>> Cc: [email-masked]<mailto:[email-masked]>;
>[email-masked]<mailto:[email-masked]>;
>[email-masked]<mailto:[email-masked]>
>> To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-
>[email-masked]<mailto:draft-brockners-proof-of-
>[email-masked]>; [email-masked]<mailto:[email-masked]>
>1,3,5,6) to packet B, will the verifier accept packet B and believe that its path
>was indeed (1,3,5,6)?
>>
>> 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).
>>
>> To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-
>[email-masked]<mailto:draft-brockners-proof-of-
>[email-masked]>; [email-masked]<mailto:[email-masked]>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 20 Jul 2016 09:51:05 +0000

Hi, Tal,

> On Jul 20, 2016, at 11:42 AM, Tal Mizrahi <[email-masked]> wrote:
> 
> Hi Carlos,
> 
> 

Sorry if I was not clear — I do not mean technological sophistication or massive processing resources required. I mean access and operational one.

> If this kind of attack is not within the scope here, then I would argue that you don't need a cryptographic mechanism at all. All you need is a TLV that specifies the list of nodes. However, I beli…

You seem to have missed quoting the important part of my response: "My point is that what you seem to be describing is a generic threat use case and not a specific vulnerability.”

Selectively dropping part of the response removes important context.

> I fully agree that the threat model needs to be well-defined.

The threat model for SFC MD, yes. Access to the POT comes with assumptions.

Thanks,

— Carlos.

> I hope you will elaborate more on the threat model in the next version of the draft.
> 
> Cheers,
> Tal.
> 
> 
>> [email-masked]

---

From: Tal Mizrahi <[email-masked]>
Date: Wed, 20 Jul 2016 10:09:47 +0000

Hi Carlos,

It all goes back to the threat model; which threats you want to address, and which ones you don't.

The way I see it, roughly speaking there are 3 classes of threats (there ae probably other threats, but these are the basic ones):
- Misroute / misconfiguration (not a security attack).
- Attacker with no on-path access.
- Man-in-the-middle (attacker *with* on-path access).

It looks like the third threat (man-in-the-middle) is currently not addressed by POT.
I certainly agree that this threat is the more difficult to implement of the three.

It would significantly clarify the picture if you specified in the draft which of the three classes you intend to address.

Thanks,
Tal.

>Sent: Wednesday, July 20, 2016 11:51 AM
>To: Tal Mizrahi
>Subject: Re: MD Type attack (Was: Question regarding Proof of Transit draft)
>
>Hi, Tal,
>
>>> Let’s step back a little — the “vulnerability” you are describing
>>> comes with the assumption that a MIIT attacker can intercept a
>>> packet, extract a TLV from the MD Type 2, drop the packet; then
>>> intercept another packet (with the knowledge that it took a different
>>> path, so maybe the attacker is using inband OAM as well :-), and
>>> insert (or modify) a TLV within the content of the MD Type 2 within the
>content of NSH, within a specific packet.
>>>
>> The attack does not require any cryptographic or algorithmic functionality,
>and to that end it is very lightweight in terms of processing resources.
>
>Sorry if I was not clear — I do not mean technological sophistication or
>massive processing resources required. I mean access and operational one.
>
>>
>> If this kind of attack is not within the scope here, then I would argue that
>you don't need a cryptographic mechanism at all. All you need is a TLV that
>specifies the list of nodes. However, I believe that you did want to try to
>mitigate MITM attackers. Correct me if I am wrong.
>>
>
>You seem to have missed quoting the important part of my response: "My
>point is that what you seem to be describing is a generic threat use case and
>not a specific vulnerability.”
>
>>> Cc: Sashank Dara (sadara); Frank Brockners (fbrockne);
>>> draft-brockners-proof- [email-masked]; [email-masked];
>>> [email-masked]; [email-masked]
>>>>> [SD] The attack is valid only if the attacker can get away
>>>>> bypassing a
>>> service function/node.
>>> desired path, the attacker can easily make you think that it *did* go
>>> through the desired path.
>>> Let’s step back a little — the “vulnerability” you are describing
>>> comes with the assumption that a MIIT attacker can intercept a
>>> packet, extract a TLV from the MD Type 2, drop the packet; then
>>> intercept another packet (with the knowledge that it took a different
>>> path, so maybe the attacker is using inband OAM as well :-), and
>>> insert (or modify) a TLV within the content of the MD Type 2 within the
>content of NSH, within a specific packet.
>>>
>>> My point is that what you seem to be describing is a generic threat
>>> use case and not a specific vulnerability. Engineering is about
>>> trade-offs (i.e., solutions that have practical performance) and
>>> about placing the solution in the most effective place.
>>>
>>> I’m not deflecting but at the same time, let’s understand the
>>> assumptions you are making for this potential attack you describe, as
>>> part of the threat analysis.
>>>
>>> Thanks,
>>>
>>> — Carlos.
>>>
>>>> Cheers,
>>>> Tal.
>>>>
>>>>
>>> through the firewall SF (even though it should). I believe this is
>>> exactly the problem you were aiming to address in this draft.
>>>>
>>> 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.
>>> 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).
>>> <[email-masked]<mailto:[email-masked]>>; Frank Brockners
>>> (fbrockne) <[email-masked]<mailto:[email-masked]>>;
>>> draft-brockners-
>>>> draft-brockners-proof-of-
>>> 1,3,5,6) to packet B, will the verifier accept packet B and believe
>>> that its path was indeed (1,3,5,6)?
>>>>
>>>> draft-brockners-

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 20 Jul 2016 10:21:41 +0000

Hi Tal,

> On Jul 20, 2016, at 12:09 PM, Tal Mizrahi <[email-masked]> wrote:
> 
> Hi Carlos,
> 

That’s a good point, indeed. The MIIM is one we should expand upon.

Thanks!

— Carlos.

---

From: "Sashank Dara (sadara)" <[email-masked]>
Date: Wed, 20 Jul 2016 11:06:07 +0000

On 20/07/16, 3:39 PM, "Tal Mizrahi" <[email-masked]> wrote:

>The way I see it, roughly speaking there are 3 classes of threats (there
>ae probably other threats, but these are the basic ones):

Thanks for such classification, we shall work on better threat modelling
and clarity in our next version.

Now , Can we put some concrete high level protocol names here that could
use POT and prone to MITM ?
Helps us understand the validity of the ³mix-and-match² attack you
described in a more concrete context.

>
>It would significantly clarify the picture if you specified in the draft
>which of the three classes you intend to address.
>
>Thanks,
>Tal.
>
>
>>draft-brockners-proof-
>>>> Let¹s step back a little ‹ the ³vulnerability² you are describing
>>Sorry if I was not clear ‹ I do not mean technological sophistication or
>>not a specific vulnerability.²
>>
>>‹ Carlos.
>>> I hope you will elaborate more on the threat model in the next version
>>>of
>>the draft.
>>>
>>> Cheers,
>>> Tal.
>>>
>>>
>>>> Let¹s step back a little ‹ the ³vulnerability² you are describing
>>>> I¹m not deflecting but at the same time, let¹s understand the
>>>> ‹ Carlos.
>>>>> 1.       A man-in-the-middle can replace the POT of packet A with
>>>>>the POT
>>of
>>>> packet B.
>>>>>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 20 Jul 2016 18:20:55 +0000

I suggest that while MITM is not the most common threat (there are more
attackers that are without on-path access) - it is still common and
dangerous *enough* to justify mitigating it, if at all possible.

At the very worst, clearly specify why you do not address this threat (but
again, I’d rather that you addressed it), and its potential consequences.
-- 
Regards,
Uri Blumenthal

On 7/20/16, 7:06 , "OPSAWG on behalf of Sashank Dara (sadara)"
<[email-masked] on behalf of [email-masked]> wrote:

>_______________________________________________
>OPSAWG mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/opsawg
>