Re: [Last-Call] Tsvart last call review of draft-ietf-detnet-ip-05

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Bob,

Thanks for the great review comments; I repeated or referred to several of
them in my own review.  One note on the security considerations:

On Sun, Mar 15, 2020 at 03:57:31PM -0700, Bob Briscoe via Datatracker wrote:
> 
>    "To prevent DetNet packets
>    from being delayed by an entity external to a DetNet domain, DetNet
>    technology definition can allow for the mitigation of Man-In-The-
>    Middle attacks, for example through use of authentication and
>    authorization of devices within the DetNet domain."
>    Eh? What does mitigation of MITM attacks mean? Either they're prevented or
>    they're not. Mitigated implies just slightly prevented. How does mitigation
>    of MITM attacks prevent delay? Seems a rather big jump.

I believe this language is mostly copied from RFC 8655, and was added there
at my suggestion.  My understanding is that MITM attacks from non-DetNet
entities are prevented, but if there is a malicious device that has
credentials authorized to participate in the DetNet domain (e.g., a
compromised router), MITM attacks by that device are not prevented.

This is perhaps also in the context of the DetNet threat model being
intrinsically different from the normal BCP 72 one, since a BCP 72 attacker
can just drop all traffic and induce failure of the DetNet goals.  So in
order to have anything meaningful to say we are forced to consider a
weaker attacker that is, e.g., only on some parts of the network or does
not have full control over all devices not explicitly trusted.

-Ben

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux