A timestamp model for determining real-time communications in intelligent networks

A timestamp model for determining real-time communications inintelligent networks

A. Patel*, S. O’Connell

Computer Networks and Distributed Systems Research Group, Department of Computer Science, University College Dublin, Dublin 4, Ireland

Received 28 June 1996

Abstract

The provision of services such as credit card facilities using Intelligent Networks (IN) depends upon the ability to process real-time data. Iftheir data is deliberately delayed during transit, these services may not be able to function accurately. This paper examines INs and highlightstheir vulnerability to network delay attacks. In particular, the nature of real-time communications and the main approach that has beendeveloped to determine whether received data is being sent in real-time or not is discussed. The deficiencies in this approach in terms of itsability to counteract the different forms of a network delay attack are highlighted and an alternative method which addresses these drawbacksis presented. Finally, the results achieved following the implementation and subsequent testing of the alternative approach are discussed.q 1997 Elsevier Science B.V.

Keywords:Real-time communications; IN; Network delay attack; Clock synchronisation

1. Introduction

Intelligent networks began to emerge in the United Statesfollowing the liberalisation of the telecommunicationsinfrastructure in the 1980s. The traditional use of PlainOld Telephony Service (POTS) points was no longer ableto meet the demand for new telephony services. INs wereable to solve this problem by providing a platform for therapid development and deployment of new telecommunica-tion services, such as Free Phone. INs enable service provi-ders to deploy new services in a fraction of the time requiredusing the POTS. This was achieved by removing the logicwhich controlled call processing from the network infra-structure switches and exchanges and centralising it. Inthis manner, a new service could be managed centrallyrather than having the service logic distributed betweenmultiple exchanges. The typical structure of an IN is illu-strated in Fig. 1.

In the IN architecture the subscribers access the servicevia the service access points. For example, for a Free-Phoneor Emergency service these access points are typically atelephone. When the service request is detected by the tele-communications infrastructure, the request is passed ontothe service switching point in order to determine at whichcontrol point the necessary service logic is located to enable

the request to be processed. The data associated with theoperation of the service is maintained at the service datapoint. This may include the names of other service controlpoints to be accessed before the service request is handled.Furthermore, the deployed services can be managed cen-trally at the service management point. From this architec-ture, it is obvious that it is much easier to deploy a newservice at the service control and switching points ratherthan having to access and configure the individualexchanges or switches themselves.

A high degree of security is necessary in today’s INs toreduce the possibility of large monetary losses being suf-fered by the telecommunications organisations. For exam-ple, according to the report in the newspaper, The IrishTimes [1], Eircell, Ireland’s Mobile Telephone Service, suf-fered a loss of IR£ 292 000 due to the efforts of three intru-ders who used equipment worth only IR£ 3000 to attack themobile telecommunications network to make internationaltelephone calls while using false identities. The issue ofsecurity in INs has not received significant attention in thecurrent ITU-T Capability Set or Advanced Intelligent Net-works (AIN) standards for INs [2]. Typically, networksecurity is regarded as an add-on service rather than aninherent feature of all service data exchanges. In particular,if any of the service data which traverses the various com-munications links, as indicated in Fig. 1, is deliberatelydelayed while handling the requested service, the resultant

Computer Communications 20 (1997) 211±218

0140-3664/97/$17.00q 1997 Elsevier Science B.V. All rights reservedPII S0140-3664(97)00011-X

* Corresponding author. E-mail: [email protected]

side-effect would be to reduce the overall service perfor-mance, i.e. the service subscribers would not be able to usethe service in a real-time manner.

By real-time is generally meant that, when a message issent to a remote system, it should be possible to determinewhether it has arrived within a predetermined period oftime. If not, it is said that the message was not sent inreal-time. The aim of real-time is at best to prevent a net-work based intruder from being able to delay a message or atleast to prevent a message from being delayed for more thana specific period of time without detection before arriving atthe receiver.

For the benefit of this paper, a basic data interchangemodel is assumed, i.e., there are two computer hosts, aninitiator (e.g. a telephone exchange) and a responder (e.g.a service switching point). The initiator establishes an asso-ciation with the responder and sends it a message. Uponreceiving it, the responder performs some local processingand then returns a reply, at which time a new message maybe issued. Furthermore, the interconnecting network willonly deliver uncorrupted data.

2. The different forms of the message-stream delayattack

From [3], there are three main forms of these delayattacks: single association delay, reordering through delayand suppress-forward.

• Single association delayinvolves the intruder suppres-sing the transmission of a particular message. After aspecific time interval has elapsed, the delayed message

is re-issued into the network for subsequent reception bythe destination host.

• The reordering through delayattack involves the intru-der selecting a point on the interconnecting network(called the network reference point) to carry out thisattack. The transmission of a number of messages ofdifferent associations are delayed by varying amountsof time as they pass this point. In this manner, it ispossible for a specific message sent by a particular initia-tor to be received, processed and replied to before any ofthe others are received at the same responder host. Thisattack is carried out by monitoring a specific associationfor any messages being transmitted (called the filteredmessages). When one is detected, those message beingsent on other associations that have not fully passed thenetwork reference point are delayed by the amount oftime it takes for the filtered message to be replied to. Thedelay experienced by the messages under attack will beproportional to the volume of filtered messages beingissued and the amount of processing time required toservice each such message at the responder host. Thenet effect of this attack is to reorder the transmittedmessages such that those issued on behalf of a particularinitiator host will be handled before those of all the otherinitiators.

• Although analogous to the threat of a single associationdelay, the suppress-forward network attack (asdescribed in [4] is specific to the situation where syn-chronised clocks are being used. In the former method,each message is sent with an attached timestamp so thatit will arrive (if not interfered with during transmission)within the time window maintained at the receiver. The

Fig. 1. The architecture of an IN.

212 A. Patel, S. O’Connell/Computer Communications 20 (1997) 211–218

time window is used to determine if the message isrecent. The bigger the time window, the longer an intru-der may delay a message without detection. However,with the latter method, each message is sent with a gen-uine timestamp, but, this time, the message will not beacceptable within the time window because, due to clockdrift between the communicating hosts, etc. it will beregarded as being too early. The incorrectly assignedtimestamp is due to the fact that the initiator’s localclock has failed and its time has ‘gone ahead’ of thelocal clock associated with the synchronising responderor the responder clock synchronisation process hasfailed and its local time has ‘lapsed behind’ the synchro-nised time associated with the other communicatinginitiator hosts. In either case, the receiving host deter-mines that the message must be post-dated and willreject it. An intruder can exploit this by being able tosuppress the message transmission and then forward it toits original destination so that is appears ‘recent’ atthe receiver (i.e. the message’s timestamp fallswithin the receiver’s current time window at the timeof reception).

By the very nature of these three forms of message delayattacks the responder host is denied the ability to receivereal-time data from a number of remote initiator sites. Thiscan be critical in a IN. For instance, if a service request for aparticular emergency service was delayed, then lives can beplaced at risk.

3. Detecting the message stream delay attacks

To counteract these forms of delay attacks, the Denningand Sacco method was identified in [3] as the main approachbeing used in today’s security systems. This method, pre-sented in [5], involves the use of synchronised clocks. Eachmessage is associated with a timestamp,Tm, which is thelocal time at the sender when the message was created. Areceiving host can verify that a received message was notdelayed if its associated timestamp satisfies the followinginequality:

Clock¹ (Dt1 þ Dt2) , Tm # Clock, (1)

where

Clock ¼ time at the receiver when the message arrives for processing;Dt1 ¼ normal clock skew which is to be expected between any

number of synchronised clocks;Dt2 ¼ average network delay associated with each message

transmission.

It is assumed that the value ofDt2 applies to the worstcase scenario of global network delay that may be experi-enced by a particular message during transmission betweentwo interconnected hosts. The reason for this is that noprocedure is described in [5] on how it could be calculated

on a per-association basis. A number of disadvantages havebeen identified with this approach. These include thefollowing.

3.1. Dependence on the use of clock synchronisation

This method is totally dependent upon using clock syn-chronisation in order to ensure that a maximum clock skew,Dt1, only exists between the local times associated with anumber of interconnected host systems. However, despitethe fact that the current algorithms are insecure, there are anumber of other important reasons why the use of clocksynchronisation should be avoided.

• Clock synchronisation within an independent adminis-trative domain can be assumed to be possible since asingle administration can ensure that a commonalgorithm is operating normally on all its machines.However, in a large autonomously administered multi-domain environment such an assumption cannot bemade. The results from a number of clock synchronisa-tion experiments [6], carried out by DARPA show thateven when time servers [7] and clock synchronisationprotocols are available, the host systems seldom main-tain closely synchronised clocks. This is not due to thesynchronisation algorithms used but, rather, the lack ofadequate system management and network failures. Theresults of the study carried out over an extended periodof time showed that, despite the fact that the most up-to-date algorithms were being used, the majority of thehosts end up being loosely synchronised with the Co-ordinated Universal Time (UTC), i.e. most clocksdeviated with the time servers by between 1–13 min;10% of the hosts actually differed by more than 13 min.

• Although synchronisation may become secure over thenetwork, human users of the host systems will haveaccess to their local time, and whenever the lack ofsynchrony would benefit them, it would be easy tochange the local time. For example, a user could changethe clock’s rate or invoke a system command to reset thelocal time. To enforce this level of control across anopen multi-domain environment is difficult since eventhe administration staff of the various domains cannot befully trusted.

• Most host systems that try to have synchronised clocks doso according to their geographical timezone or UTC time.The majority of these algorithms require the availability ofa time reference which can act as a highly accurate sourceof time, for example, a caesium beam clock. However,these reliable clocks which tend to have a typical timeloss resolution of 1ms per year, are very expensive and anumber of them may be required in a large distributedenvironment (e.g. Telecom Eireann, Ireland’s public tele-communications operator, requires the use of two of theseclocks, to ensure that their various telephone exchangesand peripheral equipment remain synchronised).

213A. Patel, S. O’Connell/Computer Communications 20 (1997) 211–218

3.2. Possible attacks

Due to the fact that clock synchronisation is required withthis mechanism, any messages exchanged could be success-fully subjected to a suppress-forward attack by violating thesynchronisation process. In addition, sinceDt2 is based on aworse case global network delay value, it would be muchlarger than required for short distance transmissions. As aresult, the order in which a number of concurrently trans-mitted messages are received and processed could bechanged without detection by deliberately enforcing differ-ent delays on each association.

Using the above analysis, there are a number of reasonswhich clearly support the need for an alternative approach todetecting real-time communications. These include:

• From the breakdown of the various forms of delay attackthat can take place, it is evident that these threats need tobe counteracted.

• The Denning and Sacco approach is not capable of ade-quately counteracting the different forms of the messagedelay attack.

• There is no ISO, ANSI, ITEF or ITU standard methodfor detecting the real-time exchange of data.

• Finally, all of the approaches examined, depend uponthe use of synchronised clocks for counteracting themessage delay attacks. There are a number of reasons,given as part of the disadvantages of the various meth-ods, which highlight the resultant vulnerabilities to anysecurity system that adopts these approaches. To addressthese problems, the use of synchronised clocks should beavoided.

Given these specific reasons, it is evident that an alter-native method for detecting the real-time communication ofdata is necessary.

4. Specifying the alternative approach

The approach taken to specify a suitable real-time dataexchange definition which addresses the deficienciesidentified with the Denning and Sacco method, is to expand

on an existing definition that is suitable for an environmentwhere synchronised clocks are present. The reason for thisis because no suitable mathematical definition was foundin the surveyed literature, where the dependency onsynchronised clocks was removed. The definition beingused in this paper is called the Real-Time Consistency Prop-erty, while synchronised clocks are present. This is definedin [8], in the form of the following inequality:

T ¹ t . d þ «: (2)

This inequality assumes that the local clocks of any twocommunicating hosts are synchronised to within a time dif-ference,«. Furthermore, letd represent the average end-to-end network delay when no failure occurs,T the time whenthe particular message is received andt the local time at thesender which is attached to the message before transmis-sion. If the value oft does not satisfy this inequality, thereceived message is treated as a late arrival.

The Real-Time Consistency Property, as described byinequality (2), is dependant upon synchronised clocksbeing maintained between the communicating hosts and ageneric value being selected for the network delay,d. How-ever, sinced is a gross over estimation of what it should be(thus giving an intruder the opportunity to delay a messagemore on fast links than on slow ones) and a bound on theclock skew « cannot be maintained when synchronisedclocks are not present, this inequality is inadequate. Toovercome this, an alternative mathematical approach isrequired which allows the network delay to be variableand the host systems to maintain their own independentvalue of time, which is subject to clock drift, etc.

4.1. Calculating the service delay

Rather than considering the network delay which onlydetermines the time for a particular message to traverse anetwork link, it is more relevant to consider the servicedelay, denoted as Serv_Delay. This alternative value is asummation of the time to assemble and dissemble theexchanged messages, link traversal delay and the delayexperienced while interfacing with the network from thehost system. To calculate this service delay value, the

Fig. 2. NTP parameter calculation model.


Internet Network Time Protocol [9], was adopted. NTP is aspecialised protocol that aims to maintain synchronisedclocks among a group of interconnected host systemsusing varying clock offsets and network delays. Althoughthe model is based upon calculating the network delay, it isequally valid to re-apply the NTP equations to determine theservice delay, provided the calculation is carried out withinthe service layer of the communications stack sharedbetween the communicating hosts. For example, within anOSI environment, the Application layer would be appropri-ate. The model is summarised in Fig. 2.

The NTP equation for calculating the network delay isgiven by:

Network_Delay¼[t4 ¹ t1] ¹ [t3 ¹ t2]

2

� �(s), (3)

where (all time values are expressed in terms of a secondscount with a granularity of 10¹3 s), t1 is the time at theinitiator host when the message was submitted for transmis-sion, t2 is the time at the responder when the message wasreceived in full,t3 is the time at the responder when a replyis submitted for transmission, andt4 is the time at the initia-tor host when the reply is subsequently received in full.

Furthermore, due to the fact that the service delay willvary for different sized messages, it is important to initiallycalculate Serv_Delay for 1 bit of data, and then multiply therespective delay value by the size of subsequently receivedmessages, in order to determine the actual service delay fora particular message. This bit representing value is denotedby Serv_Delay/bit and is calculated using the followingequation, which is adopted from Eq. (3):

Deviations in this service delay value can be caused bymultiplexing service requests in the underlying networkinfrastructure, transmission and queuing delays at the recei-ver and/or sender due to the presence of multiple concurrentservices which are multitasking on one or both communi-cating hosts, etc. The possibility of these deviations occur-ring must be taken into account for the two communicatinghosts and are denoted respectively asDServ_Delay(I) andDServ_Delay(R). Due to the unpredictability of the networkinfrastructure it is not possible to accurately calculate thesevalues for a particular association. The reason for this is thatunexpected delays caused by network congestion and multi-plexing of transmitted data in the interconnecting networkwill occur, which is outside the control of the initiator orresponder hosts. However, an upper-bound approach ofthese values is adopted, such that if these bounds areexceeded, a recovery procedure is invoked.

4.2. Handling the clock drift

Differences between the communicating hosts in terms ofthe values of their system clocks and the constant presenceof relative clock drift must also be taken into account. Theclock offset is denoted by Clock_offset and is defined for aparticular association as the difference between the initia-tor’s local clock value and the responder’s local time at theinstant the association is being established. This value maybe positive or negative, depending on the time zones. Theclock offset can be calculated using the following NTPequation:

Clock_offset¼[t2 ¹ t1] ¹ [t3 ¹ t4]

2

� �(s): (5)

The relative clock drift denoted byDClock_offset, isdefined as the maximum allowable time by which thevalue of Clock_offset is allowed to drift positively whilean association exists. For example, the value ofDClock_offset could be set to 1 s. This deviation may be causedby clock drift occurring at the initiator and/or the responderhost systems. As a result, if the value ofDClock_offsetexceeds the maximum allowable deviation then, eitherthe association must be terminated or a new clock offsetvalue needs to be calculated (i.e. the association isre-initialised).

4.3. Representing the inequality values

All processes communicating with one another in an openinterconnected service environment generally use the

Abstract Syntax Notation No. 1 (ASN.1) to represent thedata being exchanged.Within thisstandard, it is recommendedto senda timestamp or the local host time in either the form of aGeneralised Time or Universal Time Code (UTC) data type.However, the method used to calculate the clock offset andservice delay value requires that each timestamp (i.e.t1, t2, t3,etc.) must be sent in the form of a seconds count with a highlevel of granularity. The granularity required is in the order of10¹3 s which is based on the NTP time scale [9], that repre-sents the local time as the number of seconds that haveelapsed since 00:00, 1 January 1972.

The two ASN.1 defined types for handling the distribu-tion of time, are not suitable for supporting this time scale,since the GeneralisedTime ASN.1 type, although having therequired granularity, represents time as a textual string (i.e.YYYYMMDDHHMMSS.SSS), while the UTC type onlyhas a maximum granularity of 1 s. To overcome this issue,

Serv_Delay=bit ¼(t2 ¹ t1)=Size_Tx_message(bits) þ (t4 ¹ t3)=Size_Rev_reply(bits)

2

� �s=bit: (4)


the definition of a timestamp, given by ISO in the TimeManagement document [10], is adopted which recommendsthat each timestamp should be represented as a 64 bit string.Such timestamps will have a validity period of 600 yearsand a granularity of 1 ns. As a result, the ASN.1 BITSTRING type is used to exchange the various timestamps.Furthermore, in order to avoid the use of a complex ASN.1structure to carry the related data, including Serv_Delay/bitandDServ_Delay(I or R), the BIT STRING type is selectedto represent their values. This does not increase the level ofsecurity provided but, allows the amount of processing timethe receiver must spend on extracting the time related infor-mation to be kept to a minimum, so that a timestampreceived in real-time is not flagged as being invalid.

4.4. The definition for real-time communications

From inequality (2) it is now possible to define the math-ematical approach for determining real-time data exchange.For messages of q bits in size, being sent by the initiator andsubsequently received at the responder host, the real-timeinequality is defined by:

T(Local_time) ¹ T(I ) # Clock_offset

þ [DClock_offsetþ Serv_Delay=bit 3 q

þ DServ_Delay(I ) þ DServ_Delay(R)], ð6Þ

and the timestamp acceptance window range for the messa-ge’s timestamp,T(I), at the responder host is expressed interms of its local system time,T(Local_time), by the follow-ing inclusive limits:

T(Local_time) ¹ Clockoffset¹ J # T(I ) # T(Local_time)

¹ Clockoffset, ð7Þ

where

J ¼ [DClock_offsetþ Serv_Delay=bit 3 q

þDServ_Delay(I ) þ DServ_Delay(R)]:

Furthermore, for replies being sent back from the responderhost to the initiator, a separate inequality is required. Thereason for this is that inequality 6 will not hold true in thecase of a negative value for Clock_offset, and will not allowfor the detection of a real-time message transmission in thecase of a positive value for Clock_offset. As a result, inorder to determine the real-time transmission of the repliessent by the responder to the initiator, the following inequal-ity is defined:

T(R) ¹ T(Local_time) $ Clock_offset

¹ [DClock_offsetþ Serv_Delay=bit 3 q

þDServ_Delay(I ) þ DServ_Delay(R)]: ð8Þ

The timestamp acceptance window range for the reply’stimestamp,T(R), is expressed by the following inclusive

limits, whereT(Local_time) is the local system time at theinitiator’s host when the reply is received:

T(Local_time) þ Clock_offset¹ J # T(R) # T(Local_time)

þ Clock_offset: ð9Þ

The reason for the inequality sign is to allow for a maximumdeviation in the clock offset and service delay to take placeduring a message/reply exchange and still enable it to beacceptable at the receiving host. These four inequalitiesderived for detecting real-time communications are referredto hereafter as the Real-Time Conditionals. To understandhow they work, consider the case of a negative time differ-ence between two communicating hosts, A and B, with thefollowing configuration:

Initiator A : Responder B:

DServ_Delay(I ) ¼ 1 s DServ_Delay(R) ¼ 1:5 s

DClock_offset¼ 1 s DClock_offset¼ 1 s

Serv_Delay=bit ¼ 0:0006 s Serv_Delay=bit ¼ 0:0006 s:

The clock offset between A and B is¹ 100 s, i.e. the localhost times are 600 s and 500 s, respectively (assuming smallvalues for the purpose of representing local times) at theassociation establishment stage. If the initiator sends a mes-sage of 80 bytes to the responder with an associated time-stamp (8 bytes) value of 600.000 s, but if the messagearrives at the responder latter than 503.922 s (from inequal-ity (6)) it will be flagged as being invalid. An alternativeway of examining this would be, when the message arrivesat the responder, a timestamp acceptance window is calcu-lated using inequality (7). If the timestamp falls within theinclusive range of this window, then it is accepted. Forexample, if the message arrives at time 503.922 s (assuminga maximum deviation in the service delay and clockoffset parameters), its timestamp would be acceptedsince it falls within the calculated timestamp window of[600.000, 603.922]. However, if the message was delayeden route for a further 1 s, the timestamp window calculatedwhen the message is subsequently received at 504.922 swould be [601.00, 604.922], a range within which theoriginal timestamp of 600.000 does not fall and thereforethe message would be flagged as having an invalidtimestamp.

When the responder returns a reply of 160 bytes to theinitiator with an associated timestamp of 505.000 s, if it isreceived before 609.306 s, (using inequality (8)) then thereply is accepted. Alternatively, if the received timestampfalls within the timestamp window calculated by theinitiator (using inequality (9)) upon receipt of the reply, itis also accepted as being sent in real-time, i.e. if the replyarrives back at time 609.306 s, the timestamp acceptancewindow for the message will be [505.000, 509.306]. As aresult, the timestamp is still acceptable within this range.However, if the reply is delayed by 0.1 s and, therefore,


arrives instead at 609.406 s, the timestamp received with thereply will not be acceptable, since it will not fall within therange of the resultant new timestamp window, i.e. [505.100,509.406]. The above timestamp validation process alsoholds for situations between communicating hosts wherethe Clock_offset$ 0.

5. Evaluating the approach

The above approach for detecting the real-time exchangeof data was integrated into an Remote Operations (RO)service that was supported by ROSE and ACSE. A completedescription of the implementation work carried out is givenin [3]. The purpose of this implementation stage was todetermine the effectiveness of the alternative approach tocounteract the different forms of the message delay attack.

In order to carry out the necessary experiments, a demon-stration RO initiator and responder were installed onto anumber of SUN Sparc stations including an IPX (A) andtwo Sparcs 5 (B and C), which were interconnected usingboth X.25 and TCP/IP. Both A and B were based in Dublin.The third, C, was located in Copenhagen which was actingas a file server and, therefore, had a varying workload. Thismeant that its value ofDServ_Delay would have to be sethigher than the rest of the test machines. Furthermore, usinga machine in Copenhagen guaranteed that several differenttypes of international networks would be used to carry theRO data. The demonstration RO initiator enables an asso-ciation to be established and a continuous stream of ROrequests to be issued to a responder with the use of thereal-time checking facility turned on or off for differentassociations.

The three different forms of message delay attacks werecarried out on the RO service by interfering with the ROrequests and their respective replies in the Network Layer ofthe OSI stack which connected hosts A and B. By enforcingthe use of the Real-Time Conditional inequalities, preventedthe suppression forward and the one-way version of thesingle association network delay attack being successful.However, if all of the data exchanges going in both direc-tions between the initiator and responder hosts are delayedby an equal amount of time, then the two-way single asso-ciation delay attack is successful. The reason for this is thatthe service delay value calculated would be over-estimatedby the initiator host, thus enabling the message exchanges tobe delayed by the number of seconds given by the differencein the real service delay value and the over-estimate.

Although a number of different schemes were examinedincluding the use of a database that maintained a servicedelay entry for each remote host, this proved to be uselesssince, in a large computing network such as the Internet, it isnot possible to determine the expected service delay prior toestablishing a connection because it is dependant upon awide number of unpredictable factors, including the work-load associated with the host systems, underlying network

congestion, use of inter-domain security protection, etc.Deviations of several seconds can be expected for evenshort distance connections. However, in order to be success-ful, an intruder must delay all the messages being exchangedwith a particular host by the same amount of time in bothdirections for each active association. Otherwise, the attackwill be detectable.

A reordering through delay attack, was found to besuccessful since there is no monotonic order check carriedout on the received timestamps. The extent of the delay thatcan be applied is limited by the enforcement of the Real-Time Conditionals. However, if the approach was extendedto include such a check, this form of delay attack would becounteracted.

6. Discussion and conclusion

The Denning and Sacco method of counteracting the mes-sage delay attacks is the main one adopted by the morepopular security utilities developed for today’s networks[3]. As a result, those systems which they are protectingare vulnerable to the network delay attacks which includesINs. To address this issue, an alternative approach called theReal-Time Conditionals is presented that counteracts thesespecific attacks and does not rely on the presence of syn-chronised clocks.

Furthermore, of the literature surveyed, no formal defini-tion of what is meant by real-time communications whensynchronised clocks are not available was found. This paperpresents such a definition. However, this definition is onlyapplicable to a connection oriented telecommunicationsenvironment and will not work when using connectionlessprotocols. Further research is required to determine if it ispossible to extend the definition to cope with the additionaltransmission issues associated with connectionless associa-tions. For example, the predictability of the service delay foreach message transmission cannot be guaranteed.

With regard the international standards, there is currentlyno ISO, ITU, ANSI or ECMA security-related standard thatspecifies how these message stream delay attacks should becounteracted for INs, other than the fact that it is identifiedthat a timestamping mechanism should be used. The mostrelevant work currently being carried out, is by ISO with theTime Management function (currently in draft form in [10]),which looks at providing synchronised time in a distributedenvironment upon which a timestamping mechanism couldbe based. However, no international effort has been identi-fied, during the course of this paper, that examines the use ofsuch a mechanism without the presence of synchronisedclocks, despite the fact that the arguments for this approachhave been presented in [11]. There is a clear need for aninternational standard which details the functionality of thetimestamping mechanism, how it should be used in suchenvironments as INs and most importantly, how it workswith and without synchronised clocks. It is important that, in


a world which is rapidly becoming computerised, thatresearch of this nature is carried out in concert with theinternational standards bodies in order to provide guidancein the formulation of emerging standards, and to identifyany shortcomings in the existing ones. Otherwise, the intro-duction of these types of mechanisms will become proprie-tary and therefore hinder the development of an openinterconnected computerised international market place.

References

[1] C. Murphy, How the mobile phone frauds were cracked, The SundayTribune Newspaper, Dublin, February 6th, 1994, p. C4.

[2] C. Sharpe K. Clegg, Advanced intelligent networks – Now a reality,Electronics and Communication Engineering Journal (1994).

[3] S. O’Connell, The development of a timestamping mechanism forremote operations in an OSI environment, M.Sc. Thesis, Departmentof Computer Science, University College Dublin, Ireland, 1995.

[4] Li. Gong, A security risk of depending on synchronised clocks, Oper-ating Systems Review 26 (1) (1992) 49–53.

[5] D. Denning, G. Sacco, Timestamps in key distribution protocols,Communication of the ACM 24 (8) (1981).

[6] D. Mills, Measured performance of the network time protocol in theInternet system, DARPA Network Working Group Report, RFC-1128, University of Delaware, United States, October 1989.

[7] K. Harrenstein, Time server, DARPA Network Working GroupReport, University of Delaware, United States, RFC-738, October,1977.

[8] M. Alford, J. Ansart, G. Hommel, L. Lamport, B. Liskov, G. Mullery,F. Schneider, Paradigms for distributed programs, in: Lecture Notes inComputer Science, Distributed Systems, Springer-Verlag, Berlin,1985, Ch. 8.

[9] D. Mills, Internet time synchronisation – The network time protocol,RFC-1129, DARPA Network Working Group, University of Dela-ware, United States, October 1989.

[10] Open systems interconnection, data management and open distributedprocessing, time management function, ISO/IEC JTC 1/SC21 N7961,WG4 Meeting, Geneva, June 1993.

[11] S. O’Connell, Realising security in a telecommunications manage-ment network (TMN), Communicate 1 (2) (1994).

Ahmed Patel received his M.Sc. and Ph.D. inComputer Science from Trinity CollegeDublin in 1977 and 1984, respectively.From 1978–1982, he was responsible fordeveloping the Irish Universities Data Net-work and from 1982–1985 he developedEuroKom computer conferencing and elec-tronic mail service used by R&D projects inEurope. At UCD he is a lecturer in ComputerScience, and head of CNDSRG, and centredirector of Teltec Ireland. He is involved invarious multi-national R&D projects in

ESPRIT, RACE/ACTS, INFOSEC, AIM, COST and the Irish nationalIT and Telecommunications programmes. His main research interestsinclude network management, security, protocols, performance evalua-tion, intelligent networks, CSCW and open distributed processingsystems.

Sean O’Connell received his B.Sc. (Hons.) inComputer Science from University CollegeDublin (UCD) in 1991. He worked asresearch assistant with the Computer Net-works and Distributed Systems ResearchGroup (CNDSRG), located in UCD, until1994. During this period he was involvedin the AIM project SEISMED and variousinternal security related projects. He joinedBroadcom Eireann Research Ltd. in 1994where he was responsible for the researchwork carried out in several security projects

in EURESCOM and RACE. Since April 1995, he has been working atSoftware and Systems Engineering, where he holds the position of Soft-ware Engineer in the Secure Messaging Group. His interests includecryptography, international communication standards, real-time sys-tems, emerging public key infrastructure standards, network manage-ment and security evaluation techniques. He has recently received aM.Sc. in Computer Security at UCD.


Documents

A timestamp model for determining real-time communications in intelligent networks