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. >-----Original Message----- >From: Carlos Pignataro (cpignata) [mailto:cpign...@cisco.com] >Sent: Wednesday, July 20, 2016 11:51 AM >To: Tal Mizrahi >Cc: Sashank Dara (sadara); Frank Brockners (fbrockne); draft-brockners-proof- >of-tran...@tools.ietf.org; s...@ietf.org; opsawg@ietf.org; n...@ietf.org >Subject: Re: MD Type attack (Was: Question regarding Proof of Transit draft) > >Hi, Tal, > >> On Jul 20, 2016, at 11:42 AM, Tal Mizrahi <ta...@marvell.com> wrote: >> >> 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. >>> >>> This sounds quite sophisticated. >> >> 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. > >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.” > >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. >> >> >>> -----Original Message----- >>> From: Carlos Pignataro (cpignata) [mailto:cpign...@cisco.com] >>> Sent: Wednesday, July 20, 2016 11:34 AM >>> To: Tal Mizrahi >>> Cc: Sashank Dara (sadara); Frank Brockners (fbrockne); >>> draft-brockners-proof- of-tran...@tools.ietf.org; s...@ietf.org; >>> opsawg@ietf.org; n...@ietf.org >>> Subject: MD Type attack (Was: Question regarding Proof of Transit >>> draft) >>> >>> Tal, >>> >>>> On Jul 20, 2016, at 6:30 AM, Tal Mizrahi <ta...@marvell.com> wrote: >>>> >>>> Hi Sashank, >>>> >>>>> [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. >>>> >>> >>> 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. >>> >>>> 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; opsawg@ietf.org; n...@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<mailto:draft-brockners-proof-of- >>> tran...@tools.ietf.org> >>>> Cc: s...@ietf.org<mailto:s...@ietf.org>; >>> opsawg@ietf.org<mailto:opsawg@ietf.org>; >>> n...@ietf.org<mailto:n...@ietf.org> >>>> Subject: RE: Question regarding Proof of Transit draft >>>> >>>> Hi Tal, >>>> >>>> thanks for the summary. We'll provide more details on 2. Per my >>>> earlier >>> point - 1. is an interesting discussion, given that we don't claim to >>> provide integrity protection for the packet payload. Or in other terms - to >be exact: >>> What POT provides is a proof that the POT-header/meta-data transited >>> all the required nodes. There is no association (and thus proof) >>> provided for the additional data carried along with the POT-header - >>> neither header nor payload. As a consequence, attacks which change >>> the packet payload won't be detected/mitigated. We'll explicitly >>> state this in the security considerations in the next rev of the document. >>>> What we could consider is linking the RND number to CRC across the >>>> packet >>> payload or similar - but that way we'd restrict the applicability to >>> deployments where the packet payload isn't changed across the path >>> (which might not apply to certain deployment - e.g. WAN optimization / >compression schemes). >>>> Do you think it is worthwhile to provide a solution for a deployment >>>> which is >>> expected to not alter the packet payload? >>>> >>>> Thanks, >>>> Frank >>>> >>>> From: Tal Mizrahi [mailto:ta...@marvell.com] >>>> Sent: Dienstag, 19. Juli 2016 17:44 >>>> To: Sashank Dara (sadara) >>> <sad...@cisco.com<mailto:sad...@cisco.com>>; Frank Brockners >>> (fbrockne) <fbroc...@cisco.com<mailto:fbroc...@cisco.com>>; >>> draft-brockners- >>> proof-of-tran...@tools.ietf.org<mailto:draft-brockners-proof-of- >>> tran...@tools.ietf.org> >>>> Cc: s...@ietf.org<mailto:s...@ietf.org>; >>> opsawg@ietf.org<mailto:opsawg@ietf.org>; >>> n...@ietf.org<mailto:n...@ietf.org> >>>> Subject: RE: Question regarding Proof of Transit draft >>>> >>>> Hi, >>>> >>>> To summarize my take on this thread: >>>> The proposed mechanism has two significant vulnerabilities that (in >>>> my >>> understanding) are currently not addressed: >>>> >>>> 1. A man-in-the-middle can replace the POT of packet A with the POT >of >>> packet B. >>>> >>>> 2. It is possible to replay POTs within a certain time window, whose >>> length is determined by the timestamp resolution. >>>> >>>> Sashank, thanks for agreeing to look into it further. I am looking >>>> forward to >>> your insights on this. >>>> >>>> Regards, >>>> Tal. >>>> >>>> Link to the draft: >>>> https://tools.ietf.org/html/draft-brockners-proof-of- >>> transit-01 >>>> >>>> >>>> >>>> From: Sashank Dara (sadara) [mailto:sad...@cisco.com] >>>> Sent: Tuesday, July 19, 2016 12:20 PM >>>> To: Tal Mizrahi; Frank Brockners (fbrockne); >>>> draft-brockners-proof-of- >>> tran...@tools.ietf.org<mailto:draft-brockners-proof-of- >>> tran...@tools.ietf.org>; s...@ietf.org<mailto:s...@ietf.org> >>>> Subject: Re: Question regarding Proof of Transit draft >>>> >>>> >>>> >>>> I want to ask a simple question: >>>> If the attacker attaches the POT of packet A (indicating the path >>>> through >>> 1,3,5,6) to packet B, will the verifier accept packet B and believe >>> that its path was indeed (1,3,5,6)? >>>> >>>> [SD] If the verifier is programmed to just validate the POT meta >>>> data against >>> {1,3,5,6} then yes it accepts it. >>>> If the verifier is programmed to consult a policy database to cross >>>> check if >>> the reconstructed path {1,3,5,6} is as per the policies then no , it drops >>> it . >>>> >>>> But I see your point , that the parameters used in POT data donot >>>> consider >>> the path or node-ids etc . We shall discuss this internally and get back. >>>> >>>> Also, We shall get back with more concrete numbers of the timestamp >>> resolution and cache sizes (or other better approaches). >>>> >>>> Thank you so much for all the inputs. >>>> >>>> >>>> >>>> From: Tal Mizrahi >>>> Sent: Tuesday, July 19, 2016 10:28 AM >>>> To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); >>>> draft-brockners- >>> proof-of-tran...@tools.ietf.org<mailto:draft-brockners-proof-of- >>> tran...@tools.ietf.org>; s...@ietf.org<mailto:s...@ietf.org> >>>> Subject: RE: Question regarding Proof of Transit draft >>>> >>>> Dear Sashank, >>>> >>>> I really appreciate the quick and detailed responses. >>>> >>>>>>> Lets take correct path taken by Packet A to be Path1 - ( >>>>>>> 1,3,5,6) nodes >> _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
