Re: [OPSAWG] MD Type attack (Was: Question regarding Proof of Transit draft)

["Sashank Dara (sadara)" <[e-mail]>]

On 20/07/16, 3:39 PM, "Tal Mizrahi" <[e-mail]> 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:[e-mail]]
>>Sent: Wednesday, July 20, 2016 11:51 AM
>>To: Tal Mizrahi
>>Cc: Sashank Dara (sadara); Frank Brockners (fbrockne);
>>draft-brockners-proof-
>>[e-mail]; [e-mail]; [e-mail]; [e-mail]
>>Subject: Re: MD Type attack (Was: Question regarding Proof of Transit
>>draft)
>>
>>Hi, Tal,
>>
>>> On Jul 20, 2016, at 11:42 AM, Tal Mizrahi <[e-mail]> 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:[e-mail]]
>>>> Sent: Wednesday, July 20, 2016 11:34 AM
>>>> To: Tal Mizrahi
>>>> Cc: Sashank Dara (sadara); Frank Brockners (fbrockne);
>>>> draft-brockners-proof- [e-mail]; [e-mail];
>>>> [e-mail]; [e-mail]
>>>> Subject: MD Type attack (Was: Question regarding Proof of Transit
>>>> draft)
>>>>
>>>> Tal,
>>>>
>>>>> On Jul 20, 2016, at 6:30 AM, Tal Mizrahi <[e-mail]> 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:[e-mail]]
>>>>> Sent: Wednesday, July 20, 2016 4:31 AM
>>>>> To: Tal Mizrahi; Frank Brockners (fbrockne);
>>>>> draft-brockners-proof-of-
>>>> [e-mail]
>>>>> Cc: [e-mail]; [e-mail]; [e-mail]
>>>>> 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:[e-mail]]
>>>>> Sent: Tuesday, July 19, 2016 6:00 PM
>>>>> To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-
>>>> [e-mail]<mailto:draft-brockners-proof-of-
>>>> [e-mail]>
>>>>> Cc: [e-mail]<mailto:[e-mail]>;
>>>> [e-mail]<mailto:[e-mail]>;
>>>> [e-mail]<mailto:[e-mail]>
>>>>> 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:[e-mail]]
>>>>> Sent: Dienstag, 19. Juli 2016 17:44
>>>>> To: Sashank Dara (sadara)
>>>> <[e-mail]<mailto:[e-mail]>>; Frank Brockners
>>>> (fbrockne) <[e-mail]<mailto:[e-mail]>>;
>>>> draft-brockners-
>>>> [e-mail]<mailto:draft-brockners-proof-of-
>>>> [e-mail]>
>>>>> Cc: [e-mail]<mailto:[e-mail]>;
>>>> [e-mail]<mailto:[e-mail]>;
>>>> [e-mail]<mailto:[e-mail]>
>>>>> 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:[e-mail]]
>>>>> Sent: Tuesday, July 19, 2016 12:20 PM
>>>>> To: Tal Mizrahi; Frank Brockners (fbrockne);
>>>>> draft-brockners-proof-of-
>>>> [e-mail]<mailto:draft-brockners-proof-of-
>>>> [e-mail]>; [e-mail]<mailto:[e-mail]>
>>>>> 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-
>>>> [e-mail]<mailto:draft-brockners-proof-of-
>>>> [e-mail]>; [e-mail]<mailto:[e-mail]>
>>>>> 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
>>>
>