Final meeting report

OKUBO Sakae okubo at mxz.mesh.ne.jp
Mon Sep 15 22:15:26 EDT 2008


Paul,

I think the Q22 meeting report did not alter the basic idea of the AVD-3541. The basic idea of AVD-3541 is that the SATC has a database stored the signature of copy-righted file, then if a pirated file transmitted and intercepted, it's signature must could not match with that stored in the database, then it is suspected as a pirated file and block it. so I think the words "if SATC finds a data stream carrying a content failing to match a kn
own signature, it will block the stream or mark it as being suspicious" in the meeting report is Ok.

As to the problem of needing a massive database, that is one of the reason why I try to store the "copy-righted file signature" but not the "pirated file signature”, I think this can decrease the size of database greatly. and for keeping the size in a acceptable scale, the file being protected should be selected carefully by the content provider, for example, only those video or audio that popular recently will be selected, I think it is re
asonable to do so, after all, the pirated version of the most popular video or audio is that the content provider care about mostly.

I agree with that using cipher or security tunnel will cause problem, in this case, the detecting based on signature hardly can handle it. But using cipher or security tunnel also will bring burden to the transmitting and propagating of pirated file.


----- 原邮件 -----
发件人: "Paul E. Jones" <paulej at packetizer.com>
日期: 星期四, 九月 11日, 2008 上午11:03
主题: RE: [itu-sg16] Q22 Question - SATC
收件人: 'zourong 52447' <zou.rong at huawei.com>
抄送: itu-sg16 at lists.packetizer.com

> Rong,
> 
> I think the meeting report is not exactly correct.  The Q22 
> meeting report
> said that SATC would block content that that failed to match a 
> signature.What you said is that SATC would block media content 
> that matches a "good"
> signature, but is apparently altered in some way.  That is, it 
> would block
> media that it can clearly identify as pirated content.
> 
> So, perhaps we should revise the wording that is presently in the Q22
> meeting report related to AVD-3541.  Can you consult Noah on what the
> correct statement should be?
> 
> As for whether this will work, I still have doubts.  Even storing 
> signaturesof all current media could be a massive database and, 
> quite likely, one that
> would need to be in memory, as you need real-time (and likely wire-
> speed)access to the signatures.
> 
> I have no objection to doing work on this: if you can meet a 
> particularbusiness requirement, great.  But, I personally think 
> that trying to match
> against signatures will not stop any serious pirate.  It might 
> stop the
> casual pirate, though.
> 
> A data stream of pirated content can be altered in so many ways 
> that it
> would be easy for somebody to create a program to stream pirated 
> contentthat does not match a signature in the database.  I could 
> run the media
> stream through a cipher algorithm, for example.  And, I could even 
> transmitthe cipher key as the last payload of the message: after 
> all, the entire
> file has been delivered!  Secrecy wasn't the purpose of the 
> encryption, but
> merely to disguise what is being transmitted until we've successfully
> bypassed the SATC "detectors".
> 
> Perhaps the simplest thing to do, actually, given the wide 
> proliferation of
> tools like OpenSSL, is to just use TLS between nodes that want to 
> transmitpirated content.  That provide more-than-acceptable level 
> of encryption.
> 
> In any case, I did not intend to bring the work to a halt, by any 
> means.But, be cognizant of the fact that this is a very complex 
> problem and I
> seriously doubt you can devise a method that would prevent a good 
> hackerfrom getting around the system.  At best, you will only stop 
> the casual
> "pirates".  You would not stop serious pirates or popular "file 
> sharing"software.  Such software would definitely employ 
> techniques to get around
> any detection/blocking logic in the router/switch.
> 
> What's more important right now is understanding what should have been
> stated in the meeting report.  I do not think this sentence is 
> accurate:
> “... if SATC finds a data stream carrying content failing to match 
> a known
> signature, it will block the stream or mark it as being suspicious.”
> 
> Paul
> 
> > -----Original Message-----
> > From: zourong 52447 [mailto:zou.rong at huawei.com]
> > Sent: Wednesday, September 10, 2008 4:05 AM
> > To: paulej at packetizer.com
> > Cc: itu-sg16 at lists.packetizer.com
> > Subject: [itu-sg16] Q22 Question - SATC
> > 
> > Paul,
> > really thanks your's comments, here is the clarification.
> > 1)	As to the circumventing problem, I really could not say their is
> > a perfect way that could not be circumvented. But I don’t think 
> it is
> > easy to do so. This scenario is attempted to provide a tool for 
> content> provider to prevent their “specially processed” content, 
> i.e. copy-
> > righted content from being pirated. It is assumed the “specially
> > processed” content have some characteristic information that 
> would be
> > destroyed by any piratical actio
> > n such as using a different decoding method, and these 
> characteristic> information or “signature” would be provided to 
> SATC system by content
> > provider. As to the compress scheme to circumvent, I think the SATC
> > could handle most of the common compress schemes such as winzar,
> > winzip, tar etc., but I also think it is impossible the SATC could
> > handle all compress schemes.
> > 2)	The method mentioned in AVD-3541 is not attempted to create a
> > database of all  pirated media, it’s a database that store the
> > signature of good media especially those most popular video or audio
> > recently, so the database will keep in a state of acceptable 
> size. The
> > periodical updating of the database is necessary just like the 
> IDS do
> > to update the anti-virus database.
> > 3)	The pirated media database could exist as an subsidiary database.
> > This was not mentioned in the AVD-3541 because I think it maybe too
> > detail to describe it in a scenario. The file transmitted will be
> > suspected as pirated file when satisfied following two points: (1)
> > There is a item in the “good media database” that means the file 
> is a
> > target of protecting. (2)the signature of the file transmitted 
> do not
> > match with that stored in the data
> > base. Then the suspected file could be blocked directly, or in a 
> more> prudent way, it could be just marked as suspicious and 
> search in a
> > subsidiary “pirated media database” to make sure it is a existing
> > pirated version or it maybe a new pirated version and need more 
> manual> analytical works of content provider.
> > 4)	As to the performance problem, I think this kind of inspection
> > may have some negative impact on the packet transmission but may 
> not as
> > terrible as thought, in fact, many DPI product in market can achieve
> > 10G to 40G, even 80G throughput, their process capability is
> > remarkable.
> > >
> > > 发件人: Paul E. Jones
> > > 发送时间: 2008-09-05 10:59:38
> > > 收件人: itu-sg16 at lists.packetizer.com
> > > 抄送:
> > > 主题: [itu-sg16] Q22 Question - SATC
> > >
> > > Q22 Experts,
> > >
> > > While reviewing the Q22 meeting report, I was intrigued by a
> > > comment related to AVD-3541.  This contribution proposes that SATC
> > > can be used to block illegal content from being transmitted over
> > > the Internet by examining the media flow and comparing that media
> > > flow (or some signature thereof) against a database.  SATC would
> > > then block content as appropriate.
> > >
> > > I would like to comment:
> > > 1)      I could easily circumvent any such measure, so any such
> > > system would prove to work only temporarily; and
> > > 2)      While a given copy of a digital copy of some content, such
> > > as music or a movie, will have a clearly recognizable signature,
> > > the same media can be “substantially” altered by merely using a
> > > different encoding method (e.g., a different video codec or
> > > compression scheme); and
> > > 3)      Actually attempting to create a database of all known
> > > pirated media, including all variations, would result in the
> > > creation of a massively huge database; and
> > > 4)      Maintenance of such a database would be a never-ending
> > > chore; and
> > > 5)      Notwithstanding the foregoing, while such a database could
> > > be constructed and flows could be examined, inspecting flows in
> > > real-time and trying to positively identify a given flow is a
> > > monumental task that will result in significantly negative impact
> > > on packet transmission performance, even if a bank of specialized
> > > network processors were employed per router or switch
> > >
> > > In short: do we really want to attempt this?  While it’s all
> > > technically possible (at the risk of turning a 1Gbps pipe into a
> > > 1Kbps pipe), I would argue that it’s not going to work.  I would
> > > be happy to be first in line to write the software necessary to
> > > circumvent such a system.  And I would do it just because I 
> can ;-)
> > >
> > > Having said that, the meeting report said that, the meeting report
> > > said that “if SATC finds a data stream carrying content 
> failing to
> > > match a known signature, it will block the stream or mark it as
> > > being suspicious.”
> > >
> > > I underlined the text of significance.  This suggests that the
> > > database would only be populated with signatures of known good
> > > media flows and would only block unrecognized flows.  This seems
> > > different than what I read and understood from AVD-3541.  What the
> > > meeting report suggests would be a simpler problem with a
> > > substantially smaller database.  So, what was actually discussed
> > > and decided for SATC?  A system that blocks unrecognized flows or
> > > a system that blocks recognized flows?
> > >
> > > Thanks,
> > > Paul
> > >
> > >
> > 
> 
> 
> 





More information about the sg16-avd mailing list