Brian E Carpenter <brian.e.carpen...@gmail.com> wrote:
tte> So, the question is what attack vector we would open up if we used
tte> sequential session-ids. Given how the signature protects the
tte> message, i will claim there is no new attack vector as long as the
tte> signature is checked. But if GRASP forwarders do not check the
tte> signature, then the sequential allocation could increase the risk
tte> that an attacker tries to stop valid flooded messages by
tte> "pre-flooding" faked messages with the guessed session-ids.
bc> Right. So I'm not yet convinced we should repurpose the session ID for
bc> this. If we're going to focus on signing objectives, maybe we need to
bc> decouple this aspect completely from the session ID?
I am sitting on the fence still here.
I think that during flooding, that the whole point is to replay the object
until all interested parties have seen it :-)
Aside from the anti-replay aspect, it would be nice to be able to avoid
having to have a cache of every flooded message since the dawn of time.
For that reason, it's probably good to have an Epoch ID as a separate object,
so that when it changes, then you can safely throw away your session-id cache.
>> Now, some part of this "pre-flooding" risk exists today: If i am a bad
>> ANI node, i receive the valid flood-message, and i have a second
>> connection to another part of the network, i can pre-flood a broken
>> message and stop that the real message makes it to that part of the
>> network. Aka: This is an argument to actually do check signature when
>> flooding them. The argument, why checking signature would be 'free'
>> is that for most flooded messages the ANI node would not only be
>> flooding, but also receivign/using. And those nodes would need to
>> check signature anyhow.
> Possibly. But from an implementer's viewpoint, the relay path doesn't
> decode the message - it just decrements the loop count and resends
> immediately on all the other interfaces. It's a quite separate code
> path that decodes (parses) the message and would verify the signature.
> I'm not saying it can't be done, but it's like the fast path/slow path
> argument for routers. This puts relaying on the "slow" path.
I'd argue for always checking signatures if they are there before flooding.
If it's too expensive, then I think that I'd rather lower the strength of the
signature until it's cheap enough. If it's a thing that has security
critical information, then if some ASA finds that the signature is too weak,
then it could just do some unicast GRASP with a stronger signature.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
