[Moims-sc] Options for MO MAL Binding to HTTP Transport

Tue Aug 18 14:16:30 UTC 2015

Dear Mehran,

my 2 cents.

I agree with you that we should avoid solution 3 i.e. the mixture that complicates (necessarily in my view) the 
binding and its specification.

Regarding the choice between  1 (more conservative) or 2 (more “modern”) and 
given the fact that the envisage use of MAL is not from corporate network but from dedicated ones I
would expect in principle that the user (we) is able to specify a network configuration that is “fit for purpose” 
and allows the necessary protocol to be used so I would prefer solution 2.

I understand that this might be problematic on legacy networks oron shared network where security 
criteria can be stricter or outside the control. In that case then the functionality associated to these 
service will not be available. So we might be in situation where some user is able to use all MAL 
interaction patterns while some other might not. It is to be assessed if this limitation is acceptable. 
As an example today from within ESA Corporate RSTP protocol is not possible so streaming has to be 
done differently or is not at all. Since this is acceptable
for our (ESA) operation this is not a problem and the RSTP service is not available) on the other hand 
when we needed remote connectivity to our protected Copernicus network to perform test a request 
was made to open specific ports/protocols on both corporate and  Copernicus GS network and it was granted
(even if it required quite some paperwork..).

I will try to check from our DMZ at ESTEC what is the status.

Michele

> On 13 Aug 2015, at 15:52 , mehran.sarkarati at esa.int wrote:
> 
> Dear SM&C WG, 
> 
> As mentioned during the technical meetings in Pasadena and in the last web-ex, we have started the work on ESA side to define a binding between MAL and HTTP transport. 
> 
> The main motivation for this binding is to use mainstream Internet infrastructure on the ground. 
> HTTP protocol is based on a request/response model. 
> For all MAL interaction patterns except for INVOKE, PUBSUB and PROGRESS, there is a simple mapping to the HTTP Request/Response model. 
> 
> It gets more complicated for the above mentioned three interaction patterns, when the provider needs to asynchronously initiate a connection to the consumer for delivering a response (request in the other direction). This is specially problematic when the consumer/provider are behind firewalls and also when consumers are dynamically added and removed (hence the firewalls cannot be configured statically). 
> The options we have been discussing are: 
> 
> a) implement a mapping to pure HTTP request/response model for all MAL interaction patterns. For INVOKE, PUSUB and PROGRESS use active/long poling if the consumer is not addressable or behind a firewall (the OASIS WS Make Connection specification can be the model, which uses additional headers to correlate the messages). 
> b) implement a mapping to HTTP request/response for all MAL interaction patterns except for INVOKE, PUBSUB and PROGRESS. For these use web-sockets. Web-Sockets are a different protocol than HTTP. It is a message oriented bi-directional protocol on top of tcp/ip. It uses HTTP for initiating the connection and then establishes a bi-directional connection, using the tcp/ip channel below, which was opened by the HTTP. 
> 
> Long polling is clearly less elegant than web-sockets. At the other side for many of our space domain scenarios the consumer and provider are known to each other and the firewalls must be configured anyway. 
> If I take the example of ESA data distribution systems (DDS/EDDS) on the DMZ, even for making a simple http request/response to the DDS, the consumer IP address must to be added to a white list. 
> 
> The scenarios translate therefore to: 
> 
> 1. HTTP Request/Response based mapping to all MAL interaction patterns: This is either when 
>         a) there are no firewalls involved (not very realistic) : No polling involved, simple http request/response 
>         b) consumer and provider are known up front and firewalls are configured accordingly to allow the traffic pass through in both directions (in my opinion more likely/realistic case): no polling involved, simple http request/response 
>         c) consumers are added and removed dynamically at run-time and firewalls do not allow out-bound connection initiation from provider side: Only for this particular case pooling techniques shall be adopted on top of simple HTTP request/response pattern 
> 
> 2. HTTP Request/Response based mapping to all MAL interaction patterns except for INVOKE/PROGRESS and PUBSUB for which web-sockets shall be used: this would use web-sockets for any scenario (even for scenario a and b, where it would not be necessary and one could do simple http request/response with no polling) 
> 
> 3. A mixture of 1 and 2. Baseline is (1) but for PUBSUB and PROGRESS the consumer can decide if it wants to use web-sockets or long polling. This would be indicated with a header field in the initiating HTTP request (which is needed for both cases). I am not sure if this 3 option is possible without over complicating the binding. 
> 
> I would like to ask you to 
> 
> a) check the setup of the DMZ and firewalls in your organisation and tell us if in your today's setup the firwall/IDS would let web-socket traffic through or would detect and prevent it for port that is specified as http port (e.g. port 80) 
> b) Which of the three options you think we should take for MAL to http binding. 
> 
> I would appreciate your feedback by mid September. 
> 
> Kind Regards 
> Mehran
> This message and any attachments are intended for the use of the addressee or addressees only.
> The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
> content is not permitted.
> If you received this message in error, please notify the sender and delete it from your system.
> Emails can be altered and their integrity cannot be guaranteed by the sender.
> 
> Please consider the environment before printing this email.
> _______________________________________________
> Moims-sc mailing list
> Moims-sc at mailman.ccsds.org
> http://mailman.ccsds.org/mailman/listinfo/moims-sc

-----------------------------------------
Michele Zundo

Head of Ground System Definition and Verification Office
EOP-PEP
European Space Agency, ESTEC
e-mail: michele.zundo at esa.int

This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-sc/attachments/20150818/5a0e4d1d/attachment.html>