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

Comments enclosed ...

> 
> 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.

So, as we have done thus far, maybe we should have a document that
documents current CDN threat models and then expand on that within
the framework of the existing documents we have to document threat
models for CDI.  Just a .01 thought.

>  > 
>  > 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. 

I agree with this approach.  Beyond this, has anybody done an analysis
of the threats that caches/proxies/replicas come under beyond the
the threats to the underlying system?

> 
>  > 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.
> 
>  > 
>  > 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.

One thing that seems to be missing here is the notion of a trust model.
Is it okay to assume that content peering nodes have a trust relationship
with a a peer in the neighboring CDN?  Is there something we can learn
from Network Peering today?

> 
>  > 
>  > 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.
> 
>  > 
>  > --- point the difference between "termination of 
>  > peering relationship with the gateway involved" and terminating 
>  > peer-to-peer relationship with the CDN involved.
>  > 
>  > - A peer can always (intentionally or unintentionally)
>  > send incorrect advertisements which might lead to incorrect
>  > selections being made. E.g. a CDN might incorrectly advertise low load,
>  > low cost and good coverage and therefore attract a large
>  > proportion of traffic. This problem can be somewhat mitigated
>  > through filtering of advertisements and local policies but
>  > ultimately comes down to a trust relationship between
>  > peers.
>  > 
>  > Migration of policy (might be generic CDN issue not CDI):
>  > If there is a certain trust relationship between content
>  > provider and consumer this relationship should be maintained
>  > when content is distributed via a CDN. (example from CDI arch
>  > draft).
>  >  - This relationship should also be preserved when content moves 
>  > between peering CDNs (policy migration).
>  > 
>  > Authoritative:
>  > Q: Do we need a mechanism to allow a CDN to prove that it
>  > is authoritative to distribute content?
> 
> I don't think we do. That should be done by the above mentioned 
> policy and trust relationships. In BGP there is also no proof
> required that an particular AS origins a prefix.
> 
>  > 
>  > Q: What does it mean to be authorized to distribute content?
> 
> I would say it means you talk to somebody who trusts you and
> you advertise it. I think all the policy part has to be
> done in a legal fashion similar to BGP peering.
> 
> 
> 
> Q: Are there any DOS attacks we have to consider?
> Q: Do we need some way of querying the view of our peers?
>  
> 
> Oliver
> 

Michael