RE: DDOS and TRP Error Handling Spec Draft

["Moberg, Dale" <Dale_Moberg@stercomm.com>]

I think that Chris F. could split the difference
with David B by saying:

1. When the error destination is "slowly changing"
put it in the TPA and protect it.
2. If you need a dynamic error destination (to
aid in tracking state, for example) use
an optional header field (but if you
are worried about the Ferris DDOS attack,
don't reuse it etc.). 

Dale

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
Sent: Wednesday, September 06, 2000 12:16 PM
To: ebXML Transport (E-mail)
Subject: Re: DDOS and TRP Error Handling Spec Draft


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