minutes of cdi threat model call 08-16 monday

[Oliver Spatscheck <spatsch@research.att.com>]

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. 

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

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