RE: [ititech:2679] Why no ATNA application acknowledgment?
Vassil Peytchev
Exactly, even with buffering, the sender knows if the message made it to the receiver or not (when using TCP). If there is a problem on the receiving side between the low-level communication stack and the ARR "application", a properly designed ARR will have a record of the issue. In fact, to me, a major reason for re-using an existing technology like syslog is to stay as close to the low levels of the OS as possible so that there is no "impedance mismatch" between communications and logging. The ARR should, in most cases, be just another service, and there should not be additional layers between the network service, file system service, and the logging service. This allows for further application using the log to be built (e.g. viewer, search, etc.), without affecting the actual logging service.
With regards to the requirement by Austrian law, here is my thought:
Let's look at the simplest case, there is a system where the information initially resides (information source), another system, where the information ends up (information consumer) and a user. The source system logs the fact that the information is transferred from the source system to the consumer system. The consumer system logs the fact that it received information from the source system. Note that up to this point there is no user who is presented with the information. When the user is presented with the information, a separate log is needed to indicate that action - and in many cases that will not be an ATNA log, as modern databases have various mechanisms for application action logging. Also, the fact that the information originally came from the source system is not relevant in the logging of the user access, which should be a separate action form the interoperability transaction, which is the scope of IHE.
Thanks,
--Vassil
-----Original Message-----
From: iti...@googlegroups.com [mailto:iti...@googlegroups.com] On Behalf Of Massimiliano Masi
Sent: Thursday, December 29, 2011 11:54 AM
To: Elliott L.
Cc: IHE ITI Technical Committee
Subject: Re: [ititech:2679] ATNA TLS Tests
Well,
Elliot, you are right. I simply forgot the receiving OS queue in my answer.
And I was also supposing a single connection for each audit, which is untrue in your case.
However, if client OS buffers data, in case of network problems the the client socket is notified.
Il giorno 29/dic/2011, alle ore 17:00, Elliott L. ha scritto:
> Vassil, you do NOT know that the receiving side has received the
> message. If there is an established connection and the receiver is not
> reading (at the application level, at least), transmissions will build
> up in the receiver's buffer. If the receiver then chooses to close
> the connection (or terminates for whatever reason), the sender gets no
> notification. If there are problems with the network connection, the
> sender's TCP stack may buffer some amount of data, which would get
> lost if the connection is terminated before transmission, again
> without notification to the sending application.
>
> It is only with some kind of application-level handshake that a sender
> can know that the data has been received.
>
> Elliott
>
> On Dec 28, 12:54 pm, Vassil Peytchev <vas...@epic.com> wrote:
>> I am not quite sure I understand the issue here. With TCP you know the receiving side has received the message and with a properly designed ARR that also means you will have a record in the ARR. Besides, the Austrian law is about delivering data to the user, not to a system, so why is logging of ITI transactions related to auditing user actions and user access to the data?
>>
>> From: iti...@googlegroups.com [mailto:iti...@googlegroups.com] On
>> Behalf Of Richard Mair
>> Sent: Tuesday, December 27, 2011 3:01 AM
>> To: 'Mark Sinke'; Steve Moore; IHE ITI Technical Committee
>> Subject: [ititech:2675] AW: [NA2012 Q&A: 56] Re: ATNA TLS Tests
>>
>> Hi Mark,
>>
>> I totally agree with you! For us the application layer ACK is one of the most important features that we are missing since the beginning of ATNA.
>>
>> Even ATNA now supports "real" secured communication via TCP and TLS we still don't use the ATNA transport protocol in real life installations just because of this reason.
>>
>> We support sending ANTA via TCP, TCP with TLS, UDP and additionally we have a proprietary WebService protocol (which is just a method audit(String message) that takes any message...). In productive use we ONLY use the WebService protocol because there we do get an application ACK! Actually the pre-connectathon tests showed us that importand logging information can get lost (and it really happens) in case there is no ACK!
>>
>> I don't like the idea at all to go to Connectathons to assure standard-conformance but not to use that standard out at the field. But in this certain case, we are forced to do so because of the Austrian data protection law (just one example).
>>
>> We must not deliver any data to any user if we can not assure that the audit message was properly stored within the ARR!
>>
>> An audit trail message protocol without a proper ACK does not fulfill our needs!
>>
>> We are working in some international projects where we are facing the same issue. So I am sure that is not only a matter with the Austrian data protection law.
>>
>> I already read some answers to your post but I think that the decision must not only be made because of technical issues. Especially in this delicate topic we need to respect legal aspects.
>>
>> So if there is the ambition to write a change proposal, we would be happy to support you and to write that proposal together with you because we really need that functionality!
>>
>> From my personal point of view - sending audit messages - is one of the most important tasks when we allow access to any PHI. So we definitely need to take this serious and it must be impossible to access data but not to leave traces!
>>
>> Thanks and best regards
>>
>> Richard (ITH-icoserve)
>>
>> ---
>>
>> DI Richard Mair
>>
>> Head of Software Development
>>
>> eHealth Solutions
>>
>> Phone +43 (0)50 8648-4131
>>
>> Fax +43 (0)50 8648-4539
>>
>> richard.m...@ith-icoserve.com<mailto:richard.m...@ith-icoserve.com>
>>
>> __________________________________________________
>>
>> ITH icoserve technology for healthcare GmbH
>>
>> 6020 Innsbruck, Innrain 98
>>
>> Firmenbuchnummer: FN 174117f
>>
>> Firmenbuchgericht: Innsbruck
>>
>> DVR: 0983039
>>
>> www.ith-icoserve.com<http://www.ith-icoserve.com>
>>
>> sense - smart ehealth solutions ...
>>
>> ... because networking in health care makes sense!
>>
>> -----Ursprüngliche Nachricht-----
>> Von: iti...@googlegroups.com<mailto:iti...@googlegroups.com>
>> [mailto:iti...@googlegroups.com]<mailto:[mailto:ititech@googlegroups
>> .com]> Im Auftrag von Mark Sinke
>> Gesendet: Montag, 19. Dezember 2011 12:33
>> An: Steve Moore; Connectathon 2012; IHE ITI Technical Committee
>> Betreff: [ititech:2661] RE: [NA2012 Q&A: 56] Re: ATNA TLS Tests
>>
>> Hi Steve, folks,
>>
>> Forgive me cross-posting, but I think this issue is too important to not get attention from the technical committee.
>>
>> A direct comment: if you close a TCP socket in a normal fashion (i.e., not a forced close), you will get a TCP-level handshake (FIN/ACK) that tries to make sure the packets are delivered. No need to tell people to keep the socket open "a little longer".
>>
>> @Tech Committee: *However*, this of course does not replace the need for a full application-level ACK, i.e., for the server to be able to say: "I cannot parse your message", or "Resource contention". Would it be sensible to file a CP on such an issue?
>>
>> Regards,
>>
>> Mark.
>>
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>>
>> From: Steve Moore [mailto:moo...@mir.wustl.edu]
>>
>> Sent: Tuesday, November 15, 2011 17:24
>>
>> To: Connectathon 2012
>>
>> Subject: [NA2012 Q&A: 56] Re: ATNA TLS Tests
>>
>> Lynn answered Muhammad privately, but I thought I would add a public response.
>>
>> This is based on my experience as a developer. If others can enlighten more, please let me know.
>>
>> TCP (and by extension) TLS does not have a mechanism that the server can use to guarantee that the client does not close the communication socket before the entire message is delivered. Other protocols that are layered on top of TCP (DICOM, HL7 MLLP) have an acknowledgement mechanism where the server is expected to send an acknowledgement for each message. That means the client would hold the connection open until it receives the acknowledgement.
>>
>> But..., the ATNA syslog mechanism does not have such an ACK.
>>
>> Therefore,
>>
>> 1. You are at the mercy of the clients.
>>
>> 2. We can (and will) work with clients to educate them about holding the socket open a little longer to deliver the message.
>>
>> The issue with #2 is how long is "a little longer"? That depends on your particular network configuration and the systems involved. If I am working on my University local network where everything is on the same subnet and physically connected to one switch, I expect one answer. I expect a different answer for Internet testing and yet a third answer when this is installed in a healthcare setting.
>>
>> Steve Moore
>>
>> On Nov 11, 12:48 pm, "Muhammad M. Kasamali"
>> <mmkassam...@gmail.com<mailto:mmkassam...@gmail.com>>
>>
>> wrote:
>>
>>> Hi,
>>
>>> I had a question about ATNA over TCP with TLS. When testing my ARR
>>
>>> using the "iheprofiles" project on openhealthtools, I noticed that
>>> the
>>
>>> unit tests in this project forcibly shut down the TCP connection
>>
>>> immediately after sending the ATNA messages. Sometimes this causes
>>> an
>>
>>> issue for my ARR which cannot receive the message because the
>>> channel
>>
>>> is forcibly closed so quickly. If I debug these same unit tests and
>>
>>> put a breakpoint after the ATNA message is sent but before the test
>>> is
>>
>>> complete and the TCP channel is closed, my ARR receives it fine.
>>
>>> I don't know if anyone is familiar enough with this iheprofiles
>>
>>> project to say whether this is a problem from their side or not?
>>
>>> Regardless, does the ATNA standard specify the manner in which the
>>> TCP
>>
>>> channel is to be closed? At the Connectathon is it expected that
>>
>>> systems would act in this manner - sending ATNA messages and then
>>
>>> immediately closing the channel?
>>
>>> Thanks!
>>
>> --
>>
>> You received this message because you are subscribed to the Google Groups "Connectathon 2012" group.
>>
>> To post to this group, send email to connectathon-2...@ihe.net<mailto:connectathon-2...@ihe.net>.
>>
>> To unsubscribe from this group, send email to connectathon-2012+unsubscr...@ihe.net<mailto:connectathon-2012+unsubscr...@ihe.net>.
>>
>> For more options, visit this group athttp://groups.google.com/a/ihe.net/group/connectathon-2012/?hl=en.
>>
>> --
>>
>> You received this message because you are subscribed to the Google Groups "IHE ITI Technical Committee" group.
>>
>> To post to this group, send email to iti...@googlegroups.com<mailto:iti...@googlegroups.com>.
>>
>> To unsubscribe from this group, send email to ititech+u...@googlegroups.com<mailto:ititech+u...@googlegroups.com>.
>>
>> For more options, visit this group athttp://groups.google.com/group/ititech?hl=en.
>>
>> --
>> You received this message because you are subscribed to the Google Groups "IHE ITI Technical Committee" group.
>> To post to this group, send email to iti...@googlegroups.com<mailto:iti...@googlegroups.com>.
>> To unsubscribe from this group, send email to ititech+u...@googlegroups.com<mailto:ititech+u...@googlegroups.com>.
>> For more options, visit this group athttp://groups.google.com/group/ititech?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups "IHE ITI Technical Committee" group.
> To post to this group, send email to iti...@googlegroups.com.
> To unsubscribe from this group, send email to ititech+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/ititech?hl=en.
>
--
Massimiliano Masi
Tiani "Spirit" GmbH
Guglgasse 6
Gasometer A
1110 Vienna
Austria/Europe
Moehrke, John (GE Healthcare)
cases. Although one system might have lost an audit event, the other party
will likely have succeeded in recording the event. Further, as Vassil also
points out each access to the data once it is inside the receiving system
must also be recorded. Among all of these audit records will be sufficient
information.
The security officer can also see that there is a missing audit event, as
all transactional events should be double, and can investigate the failure
that caused the event. If the failure continues to happen, then they have
knowledge to make the system that failed more robust. Like possibly putting
an ARR closer to the client, possibly inside on loopback with a filter
auto-forwarding robustly. Using a standard like SYSLOG allows for using
off-the-shelf building blocks.
I will point out that TCP protocol is a reliable transport, but this
reliability does require the sender to wait for the confirmation that the
connection was closed gracefully (SO_LINGER, or shutdown). I am disturbed by
assertions that if a receiver doesn't read their inbound queue and closes
the connection that the sender doesn't know that the data is lost. This is
simply not true, the TCP protocol very clearly indicates that this must be
indicated as a reset failure. Thus I am assuming that we have some
implementations that are not doing graceful shutdown so that they can notice
if the connection closed normally or was reset. It is very true if you don't
wait for a graceful shutdown to complete normally then you can't know if all
the data you have sent has been received, or if you have received all the
data the other side sent.
There is one case where the 'wait' can be very long and leave things
indeterminate. The case is well documented by one of the leading thought
leaders inside the SYSLOG community
http://blog.gerhards.net/2008/04/on-unreliability-of-plain-tcp-syslog.html
http://blog.gerhards.net/2008/05/why-you-cant-build-reliable-tcp.html
The case is where a network failure happens during communications. Normally
the ARR is only receiving, and thus there is no outbound TCP traffic from
the ARR to trigger a failure event. To protect these cases, the TCP protocol
implementations have added a SO_KEEPALIVE, that would have the TCP on the
ARR side sending negative traffic just to get a positive TCP-ACK or reset.
So, I would suggest that ARRs should be using SO_KEEPALIVE. The ARR would
know all the data that was received and that the connection terminated
non-gracefully. So the ARR side is detectable and deterministic.
The sending side would have data in the outbound queue, so this data in the
outbound queue will be retransmitted until the TCP on the sending side gives
up (yes, lots of retransmits later, with dynamic backoff). The sending side
can also notice that it's outbound wants to block, and based on application
logic (queue+time configurations) presume failure. So, the sending side will
know that failure has happened, just not 'when in the data stream'. Yes the
sending side is very blind to the TCP outbound queue inside the stack. Thus
for full record (which I argue above is not critical) the sending side would
need to re-send all un-recorded audit events, which it doesn't know how far
back to go.
Note that both the sending and ARR should really be recording this
connection anomaly as an event, thus flagging it for inspection by the
security officer.
As Massimiliano points out, if you want to make sure you have all your audit
events recorded, you could always gracefully close the SYSLOG connection
(ShutdownOutput, SO_LINGER). Open up a new one for new events, while
awaiting the graceful close notification on the old connection. Elliott
indicates he does this for every message, that seems excessive but is driven
more by his proprietary use of web-services. I could imagine a robust design
that has some outbound queue size or inactivity timeout that might be used
to cause this confirmation flush shutdown. In this case, the sending side
can know exactly all that should be re-sent if a network failure happens,
possibly delivering duplicates to the ARR (an easy thing to detect at the
ARR). This seems like a high level of logic to handle an event that doesn't
happen often, is detectable, and duplicate events protects against.
Note that we did originally specify the "Reliable SYSLOG" protocol, which
does include these application level controls. This protocol was rejected by
the IHE developers, and also by the general SYSLOG community. It was
considered too complex, and too hard to implement. The SYSLOG community may
continue to mature and head back to this more robust approach, but I don't
see that happening very fast. The reality is that the problem does exist,
but there are other ways to solve the problem without changing the protocol
completely.
John
Thanks,
--Vassil
Well,
ititech+u...@googlegroups.com<mailto:ititech+unsubscribe@googlegroups
.com>.
>>
>> For more options, visit this group
athttp://groups.google.com/group/ititech?hl=en.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
"IHE ITI Technical Committee" group.
>> To post to this group, send email to
iti...@googlegroups.com<mailto:iti...@googlegroups.com>.
>> To unsubscribe from this group, send email to
ititech+u...@googlegroups.com<mailto:ititech+unsubscribe@googlegroups