RE: minutes of cdi threat model call 08-16 monday

["Oskar Batuner" <batuner@attbi.com>]

> -----Original Message-----
> From: Oliver Spatscheck [mailto:spatsch@research.att.com]
> Sent: Thursday, August 29, 2002 9:48 AM
> To: Abbie Barbir
> Cc: 'cdn@ops.ietf.org'; Kobus van der Merwe; Oskar Batuner; Mark Day
> Subject: minutes of cdi threat model call 08-16 monday
> 
> 
> 
> Enclosed some comments:
> 
> Abbie Barbir writes:
>  > 
>  > 
>  > About scope of this work:
>  > Is limited to developing a threat model for CDI
>  > (not providing solutions).
>  > Q: Is the threat model limited to CDI or should we
>  > also cover theats related to CDNs in general?
>  > Might be difficult to understand the additional
>  > threats posed by CDI without understanding
>  > the threat model for CDNs.
>  > 
>  > Things specifically considered out of scope:
>  > - Gaurantees regarding content integrity in case
>  > of content transformations in the network.
>  > - The security of CDN such as surrogates (i.e. can not improve
>  > on the security of the original system)
>  > 
> 
> I think this is fine as long as we state that at the beginning. 

In the absence of CDN threat model I'd state that creation of such 
model is (currently) not a goal rather than stating that this is 
a non-goal.

> 
>  > Threats fall in two categories namely,
>  > network level threats and content level threats.
>  > Within both of these the distinction can be made between
>  > threats from outsiders (parties not taking part
>  > in the content peering arrangement) and from insiders
>  > (those taking part in content peering).
>  > This breakdown covers both intentional threats (i.e.
>  > malicious attacks) as well as unintentional threats
>  > (i.e. those due to system malfunction, programming error,
>  > configuration error etc).
> 
> I am not quite sure what an outsider content level thread would be.
> Is not by definition a content level thread always done by an insider
> since s/he needs network level connectivity to execute that thread.

Maybe we should extend this definition by stating that insider is 
a legal (trusted) party while an outsider is not part of CDI 
(an attacker).

> 
>  > 
>  > Threats from outsiders can be mitigated by using strong
>  > authentication and encryption.
>  > Q: Is this sufficient protection?
>  > Q: Do we want to make strong authentication and encryption
>  > a requirement?
>  > Q: Is both IPSec and TLS appropriate/scalable?
>  > Q: Should we (at this point) decide/debate above point?
> 
> 
> If my above statement holds by definition all outsider threads are
> network level threads which can be addresses by above means. At
> this point I don't think we have to decide how to solve it 
> (TLS/IPSEC) but we can require that the solution has to scale.

There was some argument about that during our conf call. 
While prolonged discussion at requirements level seems to me 
counterproductive now I see an argument for keeping 
both TLS/IPSec and leaving the choice to implementer: 
existing CDI documents (cdi-request-routing-reqs, 
cdi-known-request-routing) mention both and we should not 
tighten this requirement. 

BTW, I think we should clearly point out that the goal of this 
draft is thread discovery/analysis, not a solution. Proposed 
remedies are viewed not as design recommendations but more as 
illustrations to the nature of threats.   

> 
>  > 
>  > Threats from insiders are harder to deal with because
>  > of the trust relationship required for content internetworking.
>  > 
>  > - Treatment of malformed messages: following the BGP model
>  > it is suggested that receival of a malformed message result
>  > in termination of peering relationship with the gateway
>  > involved. Malformed message could be as result of gateway
>  > being compromised, buggy implementation etc. Since it is
>  > impossible to tell the difference terminating this peer-to-peer
>  > relationship appears to be the only safe way to handle this.
> 
> Does that mean terminate it alltogether or just that connection?
> What I mean is are the two sides allowed to reastablish a new
> peering relationship automatically? 
> 
> Does that not lead to easy DOS attacks? If all I have to 
> do is send you a mailformed IPSEC packet to terminate
> your peering relationship then I don't think that is acceptable. So 
> I would at least limit that to mailformed on the application level.

See the last paragraph of the original message:

Peering agreements may be vital for CDN functionality. This makes 
peering reliability a security issue: easy disintegration caused by 
attack on (or malfunctioning of) a single point of failure may 
result in global DoS

- Oskar