Tải bản đầy đủ - 0 (trang)
4 Improved-Positive/Negative Non-interference Based on Reveals and Excludes

4 Improved-Positive/Negative Non-interference Based on Reveals and Excludes

Tải bản đầy đủ - 0trang

Non-interference Notions Based on Reveals and Excludes



65



PNNI does not catch this kind of flow because “not excludes” does not mean

“not excludes in the future and in the past”. So we will require the negation of

both exf and exp between high and low transitions instead of only ex.

Definition 12. N is secure with respect to Improved-Positive/Negative NonInterference (I-PNNI) iff ∀l ∈ L, ∀h ∈ H : l tr h ∧ ¬(l exf h) ∧ ¬(l exp h).

Example 12. Let us consider the net in Fig. 5 and let t1 , t2 ∈ L and t3 ∈ H.

Then the net is not secure with respect to I-PNNI because t2 exf t3 , whereas it

is PNNI secure.

Obviously I-PNNI is stronger than RNI.



Fig. 11. Improved Positive/Negative Non Interference (I-PNNI)



Example 13. Both N11 and N12 in Fig. 11 are not I-PNNI secure since a low

transition l1 excludes a high transition h (both in the future and in the past).

Thus, by observing an occurrence of l1 , one can deduce that h did not occur and

will not occur. N13 in Fig. 12 is not secure with respect to I-PNNI because of

negative information flow: l2 excludes h1 , as well as h2 . An observer can deduce

that none of the high transitions occurred and they will not occur in the future

by observing l2 or l3 . This net is RNI, ERNI and ReRNI secure.

In the same figure, N14 is I-PNNI secure. No low transition reveals a high

transition, as well as no low transition excludes a high transition in the past or

in the future. However, an observer can deduce that h1 will inevitably occur by

observing the occurrences of both l2 and l3 , i.e., {l2 , l3 } tr {h1 }. In other words,

this net is not 2-ERN I while it is RNI and ReRNI secure.

Neither I-PNNI nor k-ERN I is stronger than the other for any k. The net N15

in Fig. 13 is both ERNI and I-PNNI secure, whereas N16 in Fig. 13 is not I-PNNI

secure, however it is ERNI secure. N14 of Fig. 12 is I-PNNI secure, whereas it

is not secure with respect to 2-ERN I as it is discussed in Example 13.

Similarly, neither I-PNNI nor n-ReRNI is stronger than the other one for

any n. A net which is both I-PNNI and ReRNI secure is the one in Fig. 6. The

net in Fig. 10 is not secure with respect to 3-ReRN I whereas it is I-PNNI secure.

If we add to the net another low transition l2 which consumes a token from p5 ,



66



L. Bernardinello et al.



Fig. 12. A comparison among notions of non interference



the net becomes not secure with respect to I-PNNI as well as with respect to

RNI, since l2 reveals h1 . N13 in Fig. 12 is not I-PNNI secure whereas it is ReRNI

secure.



5



Comparison of Non-interference Notions



We have introduced new notions of non-interference for Petri nets. These notions

are based on the reveals and the excludes relations and on the progress assumption.

One major difference between these notions with the existing ones, recalled

in Sect. 4, is that the new notions explicitly consider the information flow both

about the past and the future occurrences of high transitions. For example, if

a low user can tell that the occurrence of a high transition is inevitable in the

future, such a system is considered to be not secure according to the notions

we have here introduced, whereas it is considered secure by SNNI and PBNI.



Fig. 13. A comparison among notions of non interference



Non-interference Notions Based on Reveals and Excludes



67



Fig. 14. Relations among notions of non interference



Similarly, for the negative information flow, we consider both past and future

non-occurrences of high transitions.

Another important difference is shown by N4 in Fig. 6. This net is not secure

according to SNNI even if a low user cannot infer which high transitions actually occurred. On the other hand, it is secure with respect to all non-interference

notions based on reveals and excludes, since these require the capability of differentiating among the high transitions. Figure 14 illustrates the relation between

our notions and the other notions we have discussed so far. For the sake of simplicity, we only consider the weakest (SNNI ) and the strongest (PBNI ) notions

from the ones recalled in Sect. 4 and compare them with the weakest of the new

notions, i.e., RNI, and with the intersection set, denoted R-E in Fig. 14, of the

new notions RNI, k-ERN I, n-ReRN I, PNNI and I-PNNI.

We will examine three examples to discuss the differences of these classes.

A net which is secure with respect to all notions based on reveals and excludes

and which is not secure with respect to SNNI is denoted by X in Fig. 14 and

it is the one in Fig. 6. We consider this net secure since an observer cannot

differentiate among the high transitions even if he can know some high actions

have been performed (or will be performed). However, this net is not secure with

respect to SNNI.

The net denoted by Y in Fig. 14 is secure with respect to all non-interference

notions based on reveals and excludes as well as with respect to PBNI. This

net can be N15 in Fig. 13. This net is secure since no low transition reveals a

high transition (alone or together with another transition) as well as no low

transition excludes a high transition. Thus there is neither positive nor negative

information flow. It is also secure with respect to PBNI due to the fact that

there is no active causal or active conflict place.

Two nets which are secure with respect to PBNI but not secure with respect

to any of the non-interference notions based on reveals and excludes, denoted

by Z in Fig. 14, are for example N6 in Fig. 7 and N12 in Fig. 11.



6



Conclusion



In this paper, we have introduced two new relations with their variants and

applied them into the formal notion of non-interference in Petri nets. The first

one is an adaptation to Petri nets of the reveals relation, previously defined on



68



L. Bernardinello et al.



occurrence nets and applied in fault diagnosis. In particular, we have introduced

a class of parametrized reveals relations for modeling positive information flow

in Petri nets. The second relation is called excludes and it has been introduced

here with the aim of modeling negative information flow.

On the basis of the new relations, we have proposed a collection of new

notions of non-interference for Petri nets, and compared them with notions

already proposed in the literature. In this approach, the transitions of a system net are partitioned into two disjoint sets: the low and the high transitions.

A system net is considered secure, or free from interference, if, from the observation of the occurrence of a low transition, or a set of low transitions, it is not

possible to infer information on the occurrence of a high transition. Our new

non-interference notions rely on net unfolding and on reveals and excludes.

The notion of RNI states that a net is secure if no low transition reveals any

high transition. We have shown that this notion captures some situations which

were not captured by the existing notions. We also propose more restrictive

notions: k-ERN I based on observing occurrences of multiple low transitions

and n-ReRN I based on the ability of the low user to count the occurrences of a

low transition.

By adding the excludes relation to the picture, we allow one to infer negative

information, namely the fact that a high transition has not occurred and will not

occur. This is the basis of I-PNNI. The paper includes a comparison between

the notions introduced here and those found in the literature on the subject.

The notions proposed in this paper, and further variants of them, should now

be tested on more realistic cases. Our aim is to build a collection of different

non-interference properties, so that a system designer, or a system analyzer, can

choose those more appropriate to a specific case. A generalization could be a noninterference notion based on a parametric reveals relation between multisets of

transitions.

We are currently exploring algorithms to check non-interference. In particular, we consider using finite prefixes of net unfoldings, similarly to [3]. In [19], a

method based on finite prefixes of net unfoldings has been proposed by adapting

the diagnosis algorithm introduced in [18] to the problem of checking reveals and

excludes relations. We are also interested in further investigating the excludes

relation and the possibility to apply it in different contexts.

Acknowledgements. This work was partially supported by MIUR and by MIUR PRIN 2010/2011 grant ‘Automi e Linguaggi Formali: Aspetti Matematici e Applicativi’, code H41J12000190001.



References

1. Balaguer, S., Chatain, T., Haar, S.: Building tight occurrence nets from reveals

relations. In: Caillaud, B., Carmona, J., Hiraishi, K. (eds.) 11th International

Conference on Application of Concurrency to System Design, ACSD 2011,

Newcastle Upon Tyne, UK, pp. 44–53. IEEE, 20–24 June 2011. http://doi.

ieeecomputersociety.org/10.1109/ACSD.2011.16



Non-interference Notions Based on Reveals and Excludes



69



2. Balaguer, S., Chatain, T., Haar, S.: Building occurrence nets from reveals relations.

Fundam. Inform. 123(3), 245–272 (2013). http://dx.doi.org/10.3233/FI-2013-809

3. Baldan, P., Carraro, A.: Non-interference by unfolding. In: Ciardo, G., Kindler,

E. (eds.) PETRI NETS 2014. LNCS, vol. 8489, pp. 190–209. Springer, Heidelberg

(2014)

4. Bernardinello, L., Kılın¸c, G., Pomello, L.: Non-interference notions based on reveals

and excludes relations for Petri nets. In: Proceedings of the International Workshop

on Petri Nets and Software Engineering (PNSE 2015), Brussels, Belgium, pp. 59–

78, 22–23 June 2015

5. Best, E., Darondeau, P.: Deciding selective declassification of Petri nets. In:

Degano, P., Guttman, J.D. (eds.) Principles of Security and Trust. LNCS, vol.

7215, pp. 290–308. Springer, Heidelberg (2012)

6. Best, E., Darondeau, P., Gorrieri, R.: On the decidability of non interference over

unbounded Petri nets. In: Chatzikokolakis, K., Cortier, V. (eds.) Proceedings 8th

International Workshop on Security Issues in Concurrency, SecCo 2010, Paris,

France, vol. 51, pp. 16–33. EPTCS, 30 August 2010. http://dx.doi.org/10.4204/

EPTCS.51.2

7. Bryans, J., Koutny, M., Mazar´e, L., Ryan, P.Y.A.: Opacity generalised to transition systems. Int. J. Inf. Sec. 7(6), 421–435 (2008).

http://dx.doi.org/10.1007/s10207-008-0058-x

8. Bryans, J., Koutny, M., Ryan, P.Y.A.: Modelling opacity using

Petri nets. Electr. Notes Theor. Comput. Sci. 121, 101–115 (2005).

http://dx.doi.org/10.1016/j.entcs.2004.10.010

9. Busi, N., Gorrieri, R.: A survey on non-interference with Petri nets. In: Desel, J.,

Reisig, W., Rozenberg, G. (eds.) Lectures on Concurrency and Petri Nets. LNCS,

vol. 3098, pp. 328–344. Springer, Heidelberg (2004)

10. Busi, N., Gorrieri, R.: Positive non-interference in elementary and trace nets.

In: Cortadella, J., Reisig, W. (eds.) ICATPN 2004. LNCS, vol. 3099, pp. 1–16.

Springer, Heidelberg (2004)

11. Engelfriet, J.: Branching processes of Petri nets. Acta Inf. 28(6), 575–591 (1991).

http://dx.doi.org/10.1007/BF01463946

12. Focardi, R., Gorrieri, R.: A classification of security properties for process algebras.

J. Comput. Secur. 3(1), 5–34 (1995)

13. Focardi, R., Gorrieri, R.: Classification of security properties (Part I: information

flow). In: FOSAD [14], pp. 331–396

14. Focardi, R., Gorrieri, R. (eds.): FOSAD 2000. LNCS, vol. 2171, pp. 331–396.

Springer, Heidelberg (2001)

15. Goguen, J.A., Meseguer, J.: Security policies and security models. In: IEEE Symposium on Security and Privacy, pp. 11–20 (1982)

16. Gorrieri, R., Vernali, M.: On intransitive non-interference in some models of concurrency. In: Aldini, A., Gorrieri, R. (eds.) FOSAD 2011. LNCS, vol. 6858, pp.

125–151. Springer, Heidelberg (2011)

17. Haar, S.: Unfold and cover: qualitative diagnosability for Petri nets. In: Proceedings

of 46th IEEE Conference on Decision and Control (2007)

18. Haar, S., Rodr´ıguez, C., Schwoon, S.: Reveal your faults: it’s only fair! In: Carmona,

J., Lazarescu, M.T., Pietkiewicz-Koutny, M. (eds.) 13th International Conference

on Application of Concurrency to System Design, ACSD 2013, Barcelona, Spain,

pp. 120–129. IEEE, 8–10 July 2013. http://dx.doi.org/10.1109/ACSD.2013.15

19. Kılın¸c, G.: Formal notions of non-interference and liveness for distributed systems.

Ph.D. thesis, Universitdegli Studi di Milano-Bicocca (2015)



70



L. Bernardinello et al.



20. Mazar´e, L.: Using unification for opacity properties. In: Proceedings of WITS, pp.

165–176 (2004)

21. Roscoe, A.W.: CSP and determinism in security modelling. In: IEEE Symposium

on Security and Privacy, pp. 114–127. IEEE Computer Society (1995)

22. Rushby, J.: Noninterference, transitivity, and channel-control security policies.

Technical report. http://www.csl.sri.com/papers/csl-92-2/

23. Ryan, P.Y.A.: Mathematical models of computer security. In: Focardi, R., Gorrieri,

R. (eds.) [14], pp. 1–62

24. Ryan, P.Y.A., Schneider, S.A.: Process algebra and non-interference. In: CSFW,

pp. 214–227. IEEE Computer Society (1999)

25. Schneider, S., Sidiropoulous, A.: CSP and anonymity. In: Martella, G., Kurth, H.,

Montolivo, E., Bertino, E. (eds.) ESORICS 1996. LNCS, vol. 1146, pp. 198–218.

Springer, Heidelberg (1996)

26. Sutherland, D.: A model of information. In: Proceedings of National Computer

Security Conference, pp. 175–183 (1986)



Validating DCCP Simultaneous Feature

Negotiation Procedure

Somsak Vanit-Anunchai(B)

School of Telecommunication Engineering, Institute of Engineering,

Suranaree University of Technology, Nakhon Ratchasima 30000, Thailand

somsav@sut.ac.th



Abstract. This paper investigates the feature negotiation procedure of

the Datagram Congestion Control Protocol (DCCP) in RFC 4340 using

Coloured Petri Nets (CPNs). After obtaining a formal executable CPN

model of DCCP feature negotiation, we analyse it using state spaces.

The experimental result reveals that simultaneous negotiation may be

incorrect and broken on even a lossless FIFO channel. In the undesired

terminal states, the confirmed feature values of the client and the server

do not match. To fix this problem we suggest two solutions. Firstly, sending a Change option when an endpoint changes its preference. Secondly,

an endpoint in STABLE does not discard non-reordered Confirm options.

We have applied our suggested changes to the constructed CPN models.

The formal verification of the revised models shows that the undesired

terminal states have been eliminated.

Keywords: Datagram Congestion Control Protocol

tion · Coloured Petri Nets · State space analysis



1



· Feature negotia-



Introduction



In 2006, the Internet Engineering Task Force (IETF) published a set of standards for the Datagram Congestion Control Protocol (DCCP) [15] comprising

RFC 4336 [7]; RFC 4340 [16]; RFC 4341 [8] and RFC 4342 [10]. RFC 4336 discusses problems and disadvantages of existing transport protocols and the motivation for designing a new transport protocol for unreliable datagrams. RFC

4340 specifies reliable connection management procedures; reliable negotiation

of options; acknowledgement and optional mechanisms used by the congestion

control mechanisms. RFC 4340 also provides the extension for modular congestion control, called Congestion Control Identification (CCID) but the congestion

control mechanisms themselves are specified in other RFCs. Currently there are

three published standards, RFC 4341, CCID2: TCP-like congestion control [8],

RFC 4342, CCID3: TCP-Friendly Rate Control [10] and CCID4: RFC 5622

TCP-Friendly Rate Control for Small Packets [9].

This work is supported by Research Grant no. TRG5380023 from the Thai Network

Information Center Foundation and the Thailand Research Fund.

c Springer-Verlag Berlin Heidelberg 2016

M. Koutny et al. (Eds.): ToPNoC XI, LNCS 9930, pp. 71–91, 2016.

DOI: 10.1007/978-3-662-53401-4 4



72



S. Vanit-Anunchai



Unlike TCP, DCCP does not impose flow control on the data transfer. But

state information such as the sequence number sent and received is still used

in order to trace packet loss which is crucial for congestion control. From the

sequence number variables, a sequence number validity window is set up [16]

to protect against attacks. Thus connection management procedures specified

in RFC 4340 are used to set up and clear the state information. Apart from

the reliable connection management, both sides must choose congestion control

mechanisms and agree upon the same CCID. This requires a reliable negotiation

procedure called Feature Negotiation which is also specified in RFC4340. If both

sides are not aware of reaching an agreement with different CCIDs, the situation

will be very harmful1 and currently there is no recovery mechanisms. Hence it

is vital to verify that the DCCP feature negotiation procedure works correctly.

In this paper we use Coloured Petri Nets (CPNs) [13,14] to formally model and

analyse DCCP feature negotiation procedures.

Formal methods [1] are techniques based on mathematically defined syntax

and semantics for the specification, development and verification of software and

hardware systems. They remove ambiguities and are indispensable for checking

correctness of high-integrity systems. Coloured Petri Net (CPN) [13,14] is a

formal method which is widely used [2,3,6,18] to model and analyse concurrent

and complex systems. An important advantage of CPNs is its graphical notation

with abstract data types providing a high level of expressive modelling power.

CPNs and their analysis techniques have been used to verify many industrial

scale protocols such as the Wireless Application Protocol (WAP) [11], TCP [12],

DCCP [22] and SCTP [24]. The application of CPNs and related techniques for

validation of the protocol design were illustrated in [17]. In addition to focusing on the four projects: the DYMO routing protocol, Generic Access Network

(GAN) Architecture, Routing Interoperability protocol (RIP) and Edge Router

Discovery Protocol (ERDP), they reviewed various work related to validation of

the protocol design.

DCCP connection management operating over reordering channels with no

loss was studied in [22] using Coloured Petri Nets. Later, the work [22] was

extended by including DCCP simultaneous open procedure (RFC 5596) and

Network Address Translators (NAT) in [23]. However, regarding DCCP feature

negotiation procedure, there are very few articles [20,21] investigating it. The

background information on feature negotiation was summarized and the algorithms for processing the feature negotiation options were illustrated in [20].

Interaction between the DCCP feature negotiation and the protocol procedures

was discussed in [21]. As far as we are aware of, DCCP feature negotiation has

not been formally modelled and analysed before.

The contribution of this paper is threefold. First, as far as we are aware of

this paper presents the first formal executable model of DCCP feature negotiation. Second, the formal analysis helps us identify an error in the specification.

1



It is difficult to justify the consequence when the CCIDs of both side do not match

because it depends on the applications. However, we envisage that the receiver could

submit garbage to the application while no one realizes the problem.



Validating DCCP Simultaneous Feature Negotiation Procedure



73



Third, conducting the state space analysis provides us insight as to the causes

the error. We suggest two solutions to fix the error. After incorporating the

suggested changes, our analysis shows the absence of undesired terminal states.

This paper is organised as follows. Section 2 provides an overview of the protocol and packet format. Section 3 briefly describes the DCCP feature negotiation

procedure. The description of the CPN model of DCCP feature negotiation is

described in Sect. 4, which starts with modelling assumptions and specification

interpretation. Section 5 discusses analysis result and insight. Section 6 discusses

the lessons learned and perspectives. Section 7 presents the conclusion of this

paper and future work. We assume that the readers have knowledge of Coloured

Petri Nets [13,14] and CPN Tools [5].



2



DCCP Overview



The Internet protocol architecture is organized into five layers known as the

TCP/IP reference model. While TCP is a transport protocol that provides the

reliable delivery of a byte stream, DCCP is a transport protocol for the timely but

unreliable delivery of datagrams. DCCP can be viewed as an upgraded version

of UDP equipped with new facilities for connection management, acknowledgement, feature negotiation and congestion control.

DCCP exchange packets over the Internet Protocol between a client and

a server. The protocol uses 11 packets to setup and release connections and

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1



Source Port



Data Offset

Generic

Header

Res



Packet X

Type =

1



Destination Port



CcVal CsCov



Reserved



Checksum



Sequence Number (high bits)



Sequence Number (low bits)

DCCP

Header

Reserved



Acknowledge Number



(high bits)

Acknowledge Number (low bits)



Option Type



Length



Feature No.



Values

Options

and Padding



...

Application Data

Application

Data



...

Fig. 1. DCCP packet format.



74



S. Vanit-Anunchai



transfer data. RFC 4340 [16] defines a DCCP packet as a sequence of 32 bit

words comprised of a DCCP Header and an Application Data area as shown in

Fig. 1. The header comprises a generic header (applicable to all packets), followed

by an acknowledgement number (if any) and then the options field. The length

of the Option and Application Data fields can vary.

The DCCP header contains source and destination port numbers, and a

checksum. A data offset indicates the length in 32-bit words from the beginning of the Header to the beginning of the Application data. CCVal is a value

used by the congestion control mechanisms [10]. Checksum Coverage (CsCov)

specifies the part of the packet being protected by the checksum. The Packet

Type field specifies the type of the packet: Request, Response, Data, DataAck,

Ack, CloseReq, Close, Reset, Sync, SyncAck and Listen. Request and Data packets do not include acknowledgement numbers. The sequence numbers of Data

packets and the sequence numbers and acknowledgement numbers of Ack and

DataAck packets can be reduced to 24-bit short sequence numbers when setting

the Extend Sequence Number (X) field to 0.

The Options field contains state information or commands for applications

to negotiate various features such as the Congestion Control Identifier (CCID)

and the width of the Sequence Number validity window [16].



3



Feature Negotiation Procedure



DCCP allows both the client and the server to negotiate their parameters called

features using the options field. The option field shown in Fig. 1 is a multiple of

32-bit words which may contain more than one option. Because each option consists of a multiple of 8 bits, the field may need to be padded to the word boundary.

The first byte is an option type. The second byte is the length in bytes of each

option including the option type field, the length and data of the option. The

data part comprises a feature number and feature values. The feature negotiation can happen any time but is typically done during connection establishment.

Each entity can initiate the negotiation of two kinds of feature numbers: local

features (L)-the initiator’s features and remote features (R)-the other side’s features. Four particular options are dedicated to feature negotiations; Change L,

Confirm L, Change R and Confirm R. The option types have values of 32, 33,

34 and 35, respectively. The format of Confirm or Change Options including a

feature number and feature values are shown in Fig. 2(a). Figure 2(b) shows the

six 8-bit values representing a Change L option when negotiating CCID. The

meaning of each 8-bit value is shown in Fig. 2(c).

The feature number identifies the feature. For instance, 1 refers to CCID and

2 means short sequence numbers are allowed. The complete list of features is

given in [16]. To reach agreement on a feature value, a reconciliation rule known

to both sides is required. Currently, RFC 4340 defines two reconciliation rules:

server priority and non-negotiable. Figure 3 shows a typical message sequence

chart of each rule.



Validating DCCP Simultaneous Feature Negotiation Procedure

a)



Option Length

Type



b)



3 2



c)



6



Feature

Number

1



75



Feature values



2



3



4



(Change L, 6, CCID, [2, 3, 4])



Fig. 2. Option format in DCCP header and an example of a Change L option.



(a)



(b)



Fig. 3. Examples of the feature negotiation: (a) the server priority (b) the nonnegotiable.



The server priority rule: This rule is applied when the feature value is a fixedlength byte string. During negotiation, DCCP entity keeps an ordered preference

list of the feature values. The initiator sends a Change option containing its

preference list. The receiver responds with the Confirm option containing an

agreed value followed by its preference list. Thus the agreed value will appear

twice in the Confirm option. The agreed value is defined as the first element in

the server’s list that matches any element in the client’s list. If there is no match,

the agreed value remains the existing feature value.

For example, the client sends 32,6,1,2,3,4 corresponding to Change L(32),

length(6), CCID(1), the client’s preference list(2,3,4). This means the client proposes to change its CCID and the preferred CCIDs are CCID#2, CCID#3 and

CCID#4 respectively. The server responds 35,7,1,3,3,4,2 corresponding to Confirm R(35), length(7), CCID (1), agreed value (3) and the server’s preference list

(3,4,2). According to the client’s and server’s preference lists in this example,

the client must use CCID#3.

Non-negotiable rule: The Change and Confirm options under this rule contain

only one feature value which is a byte string. After receiving the Change L from

the feature local, the feature remote must accept the valid value and reply with

Confirm R containing this value. If the received feature value is invalid, the

feature remote must send an empty Confirm R. This non-negotiable rule must

not be used with Change R and Confirm L options.

For example the client sends 32,9,3,0,0,0,0,4,0 corresponding to Change

L(32), length(9), Sequence number window (3), value of window size(1024). The

server replies with 35,9,3,0,0,0,0,4,0.



Tài liệu bạn tìm kiếm đã sẵn sàng tải về

4 Improved-Positive/Negative Non-interference Based on Reveals and Excludes

Tải bản đầy đủ ngay(0 tr)

×