[regrep-comresolve] Proposed resolution to 156 and 167

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

Attached is my private response to Duane. This is also the proposed
resolution for the issues based on previous email discussions with the
team prior to this alias being established.

--
Regards,
Farrukh

---

• From: Farrukh Najmi <Farrukh.Najmi@Sun.COM>
• To: Duane Nickull <duane@xmlglobal.com>
• Date: Tue, 05 Mar 2002 17:05:03 -0500

Duane,

Here is a private reply to the concren you had expressed. I am awaiting the
resolution of a official process to respond before making
a public response. Let me know privately what you think before I make a
public response. Thanks again for your thoughtful feedback.

--------------------

Thanks for your comments on the OASIS ebXML Registry V2.0 specifications.

Please see my response inline below.

Duane Nickull wrote:

> Hello all:
>
> In reviewing the latest Registry specification,  I noticed that section
> 8.4 is a little sparse.  I read the lines between 3560 - 3568 in version
> 2.0 and have a question.
>
> My intepretation of this means that a Registry client can issue a
> <GetContentRequest> to an ebXML regsitry.  The Query Manger interface
> would take my request and find the metadata for the objects from the
> RIM.  To return the content ( in this case the actual Registry
> Object(s)),  the query manager (the interface responsible for resolving
> the <GetCOntentRequest> message) must resolve the link to the object,
> then  retrieve it and package it in an outgoing message and send that
> message back to the address specified in the original message (which in
> itself could be spoofed).

Here is a slightly modified version of your understanding that fixes some
terminology issues etc. in your statement above:

A Registry client can issue a <GetContentRequest> to an ebXML registry.  The
request contains a collection
of <ObjectRef> elements each containing a UUID.

The Query Manger interface take each UUID specified in the request and uses
it to resolve the link to the corresponding repository item in the
repository.

It then fetches each repository item from the repository and package each as

an additional payload in the outgoing response message. Note that no
metadata is involved
in this operation other than the supplied ids.

Finally, the QueryManager sends the response message back to the requester.

In case the message came over a SOAP interface the response is a synchronous
with respect to the request.
SOAP response is sent to the actual sender of the request (no spoofing
possible).

In case the message came over an ebXML Messaging interface the response is
sent asynchronously as a separate message to the address specified in the
original message. Any spoofing issues are dealt with by the ebXML Messaging
provider in that
scenario.

For example the ebXML Messaging provider may sign messages to ensure
on-the-wire integrity.

>
>
> I question this methodology for a number of reasons:
>
> 1.  IMHO - it creates a bottleneck in the system.  A better architecture
> might be to have the QueryManager interface do nothing other than return
> a traversable link to the actual content, then have the Registry Client
> issue the necessary request directly to that link, whether it be
> intrinsic or extrinsic. One good reason for this is a person might get
> an unexpectedly very large response back from the current
> <GetContentRequest> request.  This is the  model that Search engines use
> for consumer actors today.  It let's the user then issue the trigger to
> perform the final object retrieval (clicking on a hyperlink).  This
> example is meant to be illustrative and I am not likening the ebXML
> Regsitry to a commercial HTTP Search Engine.

First, let me point out that there is a work item planned for our V3 specs
that will enable URI based access to RegistryObjects and Repository Items.
That said, the
reason we are providing them is not because we perceive a bottleneck in the
SOAP
interface. The reason is that having URI access enables better
interoperability with other
registries such as UDDI and allows more options for clients. Different
interfaces to the registry
have different strengths and weaknesses.

So we do not see URI interface to the registry as better or worse than the
SOAP or ebXML Messaging interface.

Second point is that if the request results in a large amount of data over
one interface (SOAP) it would do the same over another (URI). In either case
the user issues the
trigger to perform the final object retrieval. The only difference is the
interface used by the user.
So again there is no difference between URI interface Vs. SOAP/ebXML MS
interface.

>
>
> 2.  This also creates a potential way for hackers to make "denial of
> service" attacks.  Any unauthenticated guest can send in a message with
> a bogus <reply-to> address and request 1,000 + Registry Objects be
> returned as part of a large <GetContentRequest> message.   That will bog
> down the Regsitry.

The scenario you describe is equally unlikely for an HTTP/URI based
interface as it is over synchronous SOAP based interface (GetContentRequest
over SOAP interface).
The response always goes to the requester synchronously (No spoofing
possible).

For the ebXML Messaging interface, the ebXML Messsaging provider provides
the additional security features such as
on-the-wire-integrity/confidentiality etc.. In the unlikely
event that ebXML Messaging cannot prevent such DOS attacks then that would
be a failing of that specification
rather than ebXML Registry specifications and all services that use that
specification would be vulnerable.

>
>
> I hope I have intepretted this section in error.  If not,  may I have
> some comments from the team addressing my concerns.

We are grateful for your comments. We do however feel that the concerns you
articulated may be a misunderstanding of the specifications rather than a
flaw in the ebXML
Registry architecture. Please let us know if you have any followup questions
or comments.

>
>
> Respectfully
>
> Duane Nickull
>
> --
> CTO, XML Global Technologies
> ****************************
> Transformation - http://www.xmlglobal.com/prod/foundation/
> ebXML Central - http://www.xmlglobal.com/prod/central/
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

--
Respectfully,
Farrukh

---