Hi Tal, > On Jul 20, 2016, at 12:09 PM, Tal Mizrahi <[email protected]> wrote: > > 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. >
That’s a good point, indeed. The MIIM is one we should expand upon. Thanks! — Carlos. > Thanks, > Tal. > > >> -----Original Message----- >> From: Carlos Pignataro (cpignata) [mailto:[email protected]] >> Sent: Wednesday, July 20, 2016 11:51 AM >> To: Tal Mizrahi >> Cc: Sashank Dara (sadara); Frank Brockners (fbrockne); draft-brockners-proof- >> [email protected]; [email protected]; [email protected]; [email protected] >> Subject: Re: MD Type attack (Was: Question regarding Proof of Transit draft) >> >> 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
