OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Proposal for handling large messages


Hi all,

as agreed at our April meeting I would look into the options for handling large messages with a focus on using the external payload reference and alternatively HTTP restart.

When creating a profile for handling large message with external payload references I think the target is that the MSH will completely handle the processing of the message which includes on the sending side that the external payload must be made available to the receiver and on the receiving side to download the payload(s). 
Making the payload available to the receiver is strictly seen not necessary because the sending MSH could also use the already uploaded payload for its processing. That however has two drawbacks: first the producer application has to arrange for making the payload available to the receiver and second the MSH has to retrieve the payload from this location. 
If the producer has to arrange for the payload being available for download by the receiver it gets involved in the message transport itself, if only limited, and I think the case for using ebMS is that the business application should not concerned about the transport of the message.
That the sending MSH must also retrieve the payload from the location where it is made available by the producer application is not very efficient especially when the payload is hosted in the cloud. In that case the payload is first uploaded by the producer and then downloaded again by the MSH for processing (signing). It may also cause issues with network security because both the producer application and MSH must have access to external networks. Of course this is all solvable but it gets complicated and our target should be to create a profile that is simple.

As already noticed during the call an exchange that uses external payloads is always a kind of pull exchange as the payload must be retrieved by the receiver of the message. This will limit the usability of the external payload if the sending MSH can only push message and can not operate as a server. A possible solution is to upload the payload to the cloud. I think this should be included in a profile although it will make it more complex (because an MSH must be able to upload the payload to the cloud and we need to determine which upload protocols must be supported).
However a bigger issue that limits the usability of the external payload is that the URL included in the user message may not be accessible by the receiver when operating in a multi-hop context. For example because endpoints are in different networks and can not access resources out of their network. Because the URL is included in a possibly signed message the intermediary can not change it.

I therefore think that a possibility to restart a transmission on the http level is better to meet the objective of a reliable transfer of large messages that works in a multi-hop environment and that does not create dependencies between endpoints. Because the restart function applies to the transport level it can be used only for the hops that need it. 
Because the restart takes place at the http level it is transparant to the ebMS processing and therefor does not requires changes to already implemented ebMS processing. Only the correct configuration for http transmission needs to be set.

Attachment: Pasted Graphic 1.pdf
Description: Adobe PDF document


Part 2 of the ebMS spec already mentions the possibility of using AS2 Restart. The problem however with AS2 restart is that it only applies to push exchanges as it only defines restart for the entity of a POST method request and not for the response entity. So for restarting a pull additional specification is need. This could however be based on the http range request as defined in RFC7233. Although this RFC only defines the range request for the GET method it can also be implemented for the response entity of a POST method. The restart of a pull request would then look like in the following diagram.

Attachment: Pasted Graphic 2.pdf
Description: Adobe PDF document


The restart request in this diagram uses the POST method but it could also use GET to make it a more regular range request. This is possible because the restart is on the http level only so there is no need to resend the PullRequest and therefore there is no entity needed in restart request.
Enabling such a restart opens the possibility for an attacker to sent a restart request asking for a restart from the beginning, i.e. with Range: bytes=0- http header. Possible counter measures are restricting restarts from a certain number of bytes or securing the http connection with SSL/TLS. I think this is no greater issue than normal since an attacker that can already read the communication between the MSHs can also replay complete PullRequests.  

An advantage I see with the HTTP restart is that it can be implemented using proxies as well so support can be implemented without modifying the current implementation.

Because this solution fits very well with requirements I have been told by several people I would like to the create a specification for this http restart function rather than for the external payload option. 

Looking forward to comments.

Regards
Sander

Attachment: smime.p7s
Description: S/MIME cryptographic signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]