At 10:35 PM +0100 3/14/12, Eric Osterweil wrote:
...
So, what happens (for example) when a sig on an update can't be
verified? Is an update not processed and applied as it otherwise
would be? I guess it seems to me that the semantics of an update
have changed if a new portion of that update (the sig) can cause
interpretation of the meaning of that update to change (i.e. drop
updates with unverifiable sigs, update RIB if the sigs are
verifiable).
I see your point, but disagree. Let me try to explain.
Whenever we add secruity mechanisms to a protocol we create new ways
to cause the protocol to fail to forward data, fail to establish a
connection, etc. The model I have long (>30 years) employed is that
if the secruity checks succeed, the protocol should operate as before
(i.e., w/o the added secruity mechanisms), because the environment is
seen as benign. If the checks fail, the protocol should behave
differently, e.g., something should fail, because the environment is
now perceived as hostile and the protocol (w/o benefit of the
secruity mechanisms) was not engineered to work properly in a hostile
environment.
Consider for example the fact that many protocols incorporate an
integrity check. If the check fails, that causes a packet to be
dropped. Typically the integrity check mechanism is not secure
against attacks; is just a mechanism designed to detect benign
errors. We frequently introduce crypto-based integrity mechanisms
when we want to counter attacks. Those mechanisms will cause the
protocol to behave differently in attack scenarios, e.g., an attack
that might have yielded a valid checksum will yield an invalid HMAC,
and that will cause a packet to be dropped. This is generally viewed
not as a change to the protocol semantics, but rather an appropriate
and natural effect of operating the protocol in a secure manner.
I'd like to think that the BGPSEC mechanisms are being developed in a
way that tries to adhere to this paradigm.
...
>
Add which "things?"
When you break the paragraph up, the pronouns are not as easy to
associate w/ their common nouns. ;) "Things," was referring to
"data, semantics, and processes."
I read the text before the paragraph was sliced and diced, and I felt
that "things" was ambiguous. Now that the ambiguity is removed, I
just disagree with your reading of the text :-).
.
I think we agree that defining leaks and discussing any mechanisms
to remediate them are separate.
separate, but very interdependent. If the definition is squishy,
countermeasures are likely to be messy, at best.
Steve
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
