Re: DDOS and TRP Error Handling Spec Draft

[Christopher Ferris <chris.ferris@east.sun.com>]

Dale,

I don't disagree that having a location for reporting errors
is a good thing, I just don't believe that it belongs in the
message headers. It belongs in the TPA since it is NOT likely
to change on a per-message instance basis. It is more likely to
remain static over an extended period. Hence, it is:
	- a waste of bandwidth to retransmit the same information	
	with EACH message
	- a potential DDoS attack exploitation 

Cheers,

Chris

"Moberg, Dale" wrote:
> 
> I think that if lessening the chances of a DDOS are within the scope
> of TRP, it is certainly an issue for the security focused sub group.
> 
> The adversary currently is assumed to have acquired the destination URLs
> for many ebXML speakers and then proceeds to go on to submit
> bad data, directing error responses to some unfortunate other victim.
> 
> The intended victim's destination URL for errors is also presumed static
> and known by the adversary.
> 
> While I think in general that there are far too many other ways to launch
> a DDOS, I suppose it is worth thinking about what can be done to block
> the adversary's approach.
> 
> 1. The destination URLs can be made hard to find. This means a problem
> for the Registry; the TPA template access needs to be defined.
> 
> 2. The URL for an error reply can be made per message specific and
> dynamically
> generated so that every error gets a non-reused URL for any errors. So
> even if the adversary manages to snoop out one error destination URL,
> all the error responses after the first get a 404 or similar refusal.
> In other words, don't reuse the error destination URL when
> the DDOS threat is regarded as significant.
> 
> 3. There are surely other mechanisms that will lessen the threat, including
> screening submissions for HTTP authentication from ebXML request messages,
> checking SSL certificates during session setup, and so on. But clearly
> all these things should be addressed as part of the overall security
> TRP sub workgroup. There will be a lot of opportunities potentially for
> man in the middle style malaciousness as well as more standard DDOS.
> 
> I don't think that the security environment for the messaging is well enough
> defined that we can throw out useful messaging constructs based on the
> alleged defects of the non-defined security apparatus.

-- 
    _/_/_/_/ _/    _/ _/    _/ Christopher Ferris - Enterprise Architect
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903