Hi Frank,
>Hence, I'd like to come back to my question asked below:
>Do you (and the entire SFC team here) think it is worthwhile to provide
>a solution for a deployment which is expected to *not* alter the packet
>payload?
In a nutshell, YES.
I don't think integrity protection is a requirement
Hi Tal,
well... if you could protect the integrity of the data stream between source
and destination, you would not be able to swap the content of a packet - which
is what your attack is all about. Rather than continue arguing the point, let's
acknowledge that it is a valid attack and let's
>[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
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
Hi Frank,
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
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
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
