On 20/07/16, 3:39 PM, "Tal Mizrahi" <ta...@marvell.com> 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. 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. > > >>-----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
