Hi, Tal, > On Jul 20, 2016, at 11:42 AM, Tal Mizrahi <[email protected]> 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:[email protected]] >> Sent: Wednesday, July 20, 2016 11:34 AM >> To: Tal Mizrahi >> Cc: Sashank Dara (sadara); Frank Brockners (fbrockne); draft-brockners-proof- >> [email protected]; [email protected]; [email protected]; [email protected] >> Subject: MD Type attack (Was: Question regarding Proof of Transit draft) >> >> Tal, >> >>> On Jul 20, 2016, at 6:30 AM, Tal Mizrahi <[email protected]> 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:[email protected]] >>> Sent: Wednesday, July 20, 2016 4:31 AM >>> To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of- >> [email protected] >>> Cc: [email protected]; [email protected]; [email protected] >>> 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 protected]] >>> Sent: Tuesday, July 19, 2016 6:00 PM >>> To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of- >> [email protected]<mailto:draft-brockners-proof-of- >> [email protected]> >>> Cc: [email protected]<mailto:[email protected]>; >> [email protected]<mailto:[email protected]>; >> [email protected]<mailto:[email protected]> >>> 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 protected]] >>> Sent: Dienstag, 19. Juli 2016 17:44 >>> To: Sashank Dara (sadara) >> <[email protected]<mailto:[email protected]>>; Frank Brockners (fbrockne) >> <[email protected]<mailto:[email protected]>>; draft-brockners- >> [email protected]<mailto:draft-brockners-proof-of- >> [email protected]> >>> Cc: [email protected]<mailto:[email protected]>; >> [email protected]<mailto:[email protected]>; >> [email protected]<mailto:[email protected]> >>> 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 protected]] >>> Sent: Tuesday, July 19, 2016 12:20 PM >>> To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of- >> [email protected]<mailto:draft-brockners-proof-of- >> [email protected]>; [email protected]<mailto:[email protected]> >>> 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- >> [email protected]<mailto:draft-brockners-proof-of- >> [email protected]>; [email protected]<mailto:[email protected]> >>> 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 [email protected] https://www.ietf.org/mailman/listinfo/opsawg
