Couple of comments going back to the beginning of this thread.
There are several technologies in the DMZ that inspect traffic as it goes
through. DataPower excels at inspection of XML payloads and can weed out a
malicious payload that would bring even a very big WAS server to its knees
instantly. Similarly, Deep Packet Inspection looks at traffic to filter out
malicious payloads. It's actually not uncommon for security people who are
used to dealing with these technologies to ask about protocol-level
inspection of MQ traffic. However, as Jeff alludes to below, this works
better for stateless traffic such as HTTP. Start deleting messages from the
channel batch and MQ won't be your friend anymore. I've had good results
when asked about protocol-level inspection of WMQ traffic by explaining the
stateful nature of the connections.
Although it's not good to have lots of messages stuck in the DMZ, this
should not automatically exclude putting a QMgr there. What I usually
recommend is to tune queue depth down to about (Channel batch * 2.5),
disable the DLQ, minimize log sizes, use circular logs, and lots of other
tuning designed to keep messages from piling up there in the event of a
problem. I believe most of this made it into the Scenarios Redbook so there
is guidance on how to do this for those who wish to do so. Given the
problems with IPT at the time of writing, the team felt putting a QMgr in
the DMZ was the better option.
http://www.redbooks.ibm.com/abstracts/sg248069.html?Open
The inability of MQIPT to support multi-instance CONNAMES was raised as an
issue by a few customers well before we wrote about it in the Redbook. But
when we tried to figure out how to work around it, the scenario we came up
with was fairly kludgey. (I say "we" here like I actually did any of the
work. Credit goes to Neil, Joergen, Glenn, Long and Morten.) I'd like to
think that the Redbook scenario had something to do with the announcement
Mark Taylor made at IMPACT Meet the Experts that a new version of MQIPT had
been committed in plan. Hopefully it will support at least 2 CONNAMES,
possibly more than two. Once MQIPT catches up to v7.1 and v7.5 channel
features, and has a modern crypto provider, perhaps it will be a better
choice in the DMZ than a QMgr. At the moment though MQIPT and a real QMgr
are the only two supported options for the DMZ if you want to pass WMQ
formats and protocols.
Regarding the many IP addresses, when I was at BofA our external-facing QMgr
was served by redundant networks that each were served by redundant
circuits. So a single business partner queue manager could have 4 IP
addresses punched through the firewall, and that was before multi-instance
was available. I can see 8 (or some other power of two) but not sure what
configuration gets you to 10 without having multiple distinct QMgrs which,
as Jeff rightly points out, would be a Bad Thing.
-- T.Rob
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Jefferson Lowrey
Sent: Wednesday, June 19, 2013 12:20 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQ Proxy
I'm confused as to how MQIPT could give you any other options.
Only MQ Client connections can connect to one or more different queue
managers, regardless of qmgr name and destination address. MQ Server
connections are stateful and must always connect to a specific qmgr that has
a specific ip address and port - you can't say "connect to any qmgr named
BOB that lives at any one of these sets of addresses".
Even with an MQ Cluster, you end up having direct connections established
between every queue manager in the cluster.
At a slightly higher level, would you really want to be able to configure
MQIPT to let you randomly connect to Vendor A or Vendor B or Vendor C? I
think you'd always want to know that if you were trying to send messages to
Vendor A, that they always went to Vendor A.
So, yes, for every external qmgr you connect to, you need a unique and
distinct address, because every external qmgr is a unique and distinct
entity.
If you want to isolate all of the complexities of those unique and distinct
entities from your internal qmgrs and internal MQ applications, you can look
at MQ clusters and multi-hop architectures and MQ name resolution.
Thank you,
Jeff Lowrey
From: Huy Nguyen <ace321-8a+***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 06/19/2013 10:08 AM
Subject: Re: [MQSERIES] MQ Proxy
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>
_____
Hi Neil/Jeff Lowrey,
I agree that MQIPT is the ideal solution for us. However, the limitation we
have seen with MQIPT is that there is a 1-to-1 relationship between an MQIPT
listening port and the destination IP/port (defined as an MQIPT route). That
means if our external party provides us with multiple destination IPs
(primary/failover/DR/prod/beta), we will end up with multiple MQIPT
listening ports, just for that one particular external party. And we connect
to many, many external parties.
So in the end, on average, we'll have to use about 10 MQIPT routes per
external party we connect to. When you use simply an estimate of 100
external parties, that's 1000 ports we have to maintain across our MQIPT
cluster, and it grows linearly with the growth of number of external
parties. And that's the scale issue we can see.
Appreciate your feedback,
Huy.
Post by Neil CaseyHello Huy,
I quite agree with your reasons for using a proxy, especially for not
placing a queue manager in an internet or even business partner facing
tier 1 network zone (DMZ).
The only MQ aware proxy that I have seen is MQIPT. Your requirement is
basically an exact match for at least one of the MQIPT use cases.
In addition, MQIPT allows you to have fine control of the certificate
presented to each partner (a queue manager will always have only one
certificate) and also the trust associated with each partner (a queue
manager only has one trust store). It lets you terminate the SSL sessions
in the DMZ, which is a standard security requirement at many sites.
So, MQIPT is the tool for the job. I am not sure I understand what your
scalability issues are, but perhaps you need to think about how to work
with MQIPT rather than look for a replacement.
For a bit of an "off the wall" thought, if you happen to meet some pretty
unusual conditions, there may be an option...
If...
you have or plan to have DataPower Integration/SOA/B2B appliances
(xi50/xi52/xb60 etc) in the DMZ
you have a close relationship with your business partner, so they will
allow you to have a client connection to their QM
you don't require certainty of delivery (DP doesn't support
transactionality with more than one resource manager)
then you could use multi-protocol gateways in the DataPower appliance to
GET messages from one side, and PUT to the other.
This would give you the SSL termination in the DMZ (like MQIPT) and also
the ability to do full application level message validation there too,
which MQIPT can't do. What you lose is reliable delivery, because the
units of work can't be coordinated. You either have to accept the
possibility of message loss, or of message duplication, and your
application needs to be able to cope.
Regards
Neil Casey
Technical Consultant Messaging
Phone: +61-3-8641-1068 | Mobile: +61-438-573-152
c/- NAB 14/555 Collins St
Melbourne, Vic 3000
Australia
Date: 19/06/2013 01:50
Subject: Re: MQ Proxy
@Paul Clarke: We only want to forward MQ traffic through, not every TCP/IP
packets through, so ideally the proxy service would filter that for us.
That's why we'd like to use an "MQ-aware" proxy.
@Bruce: We thought about using "shell" gateway queue managers as proxy,
but
when communication fails between those gateway queue managers and the
back-end queue managers, MQ messages will get stuck on the gateway queue
managers (which are exposed to external networks). So that's a security
risk
we'd like to avoid by using proxy and only hold the messages on the
back-end.
Thanks for your suggestion.
Huy.
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at <http://www.lsoft.com/>
http://www.lsoft.com
Post by Neil CaseyArchive: <http://listserv.meduniwien.ac.at/archives/mqser-l.html>
http://listserv.meduniwien.ac.at/archives/mqser-l.html
Post by Neil Caseyin the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at <http://www.lsoft.com/>
http://www.lsoft.com
Post by Neil CaseyArchive: <http://listserv.meduniwien.ac.at/archives/mqser-l.html>
http://listserv.meduniwien.ac.at/archives/mqser-l.html
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at <http://www.lsoft.com/>
http://www.lsoft.com
Archive: <http://listserv.meduniwien.ac.at/archives/mqser-l.html>
http://listserv.meduniwien.ac.at/archives/mqser-l.html
_____
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries>
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
<http://www.lsoft.com/resources/manuals.asp>
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html