Fabien Seyfert

Matteo Oldoni

Martine Olivi

Sanda Lefteriu

Damien Pacaud

Deembedding of filters in multiplexers via rational approximation and interpolation

Keywords: Diplexer, filter tuning, fault diagnosis, Deembedding, Rational Approximation, Padé interpolation

In this paper we present a method to recover electrical parameters of filters embedded in a multiplexer for which scattering measurements are given. Unlike other approaches proposed for this problem, this method does not require a priori knowledge of the scattering parameters of the junction. This feature renders the procedure well suited for tuning purposes or for fault diagnosis. Technically the algorithm starts with a rational approximation step, in order to derive a rational representation of certain scattering parameters of the multiplexer. This representation is then used in a second step to identify the electrical model of each filter. This second step relies on a rational interpolation technique used to extract the filter's responses.

I. INTRODUCTION

Microwave multiplexers are present in nearly every transmission or reception unit of communication systems. The complex reciprocal loading effects of the filters connected via the junction (see Fig. 1) make their synthesis a difficult task: the latter commonly relies on computer-driven simulation, in the circuital and full wave domain, that are coupled to optimization methods [START_REF] Yu | Synthesis and beyond[END_REF]. The practical realization of such devices remains however a delicate matter, because of the inevitable dimension mismatch between the synthesized multiplexer and the realized one. The filters are therefore equipped with tuning elements (e.g. screws, irises) that need to be adjusted in the final manufacturing phase. When filters can be accessed and measured at their two ports, methods based on rational approximation have been developed ( [START_REF] Traina | Computer-aided tuning of gsm base-station filters -experimental results[END_REF], [START_REF] Miraftab | Fully automated rf/microwave filter tuning by extracting human experience using fuzzy controllers[END_REF]) to extract the electrical parameters of the measured filter, and have led to efficient tuning procedures. By contrast, when tuning a multiplexer, detaching filters from the common junction is however hardly a possible or suitable option. Note also that in the early stages of a fault diagnosis procedure on a damaged device, the ability to identify precisely the malfunctioning filter(s), without disassembling the entire multiplexer, might also be of great value. For all these reasons, important efforts have been spent on tuning techniques for multiplexers which rely only on external scattering measurements. Most of them are based on neural networks or on the minimization of a tuning criterion ( [START_REF] Michalski | Artificial neural network algorithm for automated filter tuning with improved efficiency by usage of many golden filters[END_REF], [START_REF] Yu | A fully automated filter tuning robots for wireless base station diplexers[END_REF]), which however might suffer from the presence of local minima and usually give no real insight about the internal state of the hardware. Other approaches ( [START_REF] Oldoni | Deembedding of filters' responses from diplexer measurements[END_REF]) have therefore been proposed in order to derive the filter's Fig. 1. Structure of the multiplexer and ports/filters numbering electrical parameters: these however necessitate the additional knowledge of the junction's scattering parameters, that might not be at hand in practice.

We describe here a method requiring the sole knowledge of the multiplexer's external scattering measurements, the filter's order and the coupling geometries (in-line, box section, triplets etc...) they implement. The procedure's output are most of the electrical parameters of the filters up to the resonating frequency offsets of the resonators closest to the junction and their associated output couplings. It is also analytically proven that this is the best that can be done when starting from external measurements. From the latter our algorithm derives polynomial models of certain of the device's scattering parameters, from which the rational scattering matrices of the filters can be extracted. Eventually the filter's scattering matrices extracted in this way are synthesized in terms of electrical circuits of coupled resonators with the specified topologies, yielding the coupling matrix of each filter.

II. FILTER'S RESPONSE EXTRACTION

We consider the situation depicted in Figure 2: • a filter is loaded on its second port by a unknown load • we have access to the reflexion parameter S 1,1 of this system (filter+load) at port one of the filter • we know about the filter's order N , its coupling topology, and the location of its transmission zeros This section will try to answer the following natural question: under these circumstances, what can we say about the filter's response itself? We call F 1,1 , F 1,2 , F 2,2 the filter's scattering parameters, and L 1,1 the reflexion parameter of the load. With these notations the reflexion parameter of the overall system expresses as:

S 1,1 = F 1,1 + (F 1,2 ) 2 L 1,1 1 -L 1,1 F 2,2 (1)
Evaluating the preceding expression at a transmission zero ω c of the filter is of interest in our situation, as it readily yields:

F 1,1 (ω c ) = S 1,1 (ω c ) F ′ 1,1 (ω c ) = S ′ 1,1 (ω c ) (2)
This indicates that the values and the derivatives of the reflexion coefficient of the filter at one of its finite or infinite transmission zeros can be deciphered from those of the system's reflexion at the same point. Note that if ω c is a zero of multiplicity m then the list of equalities ( 2) can be continued up to a derivative order 2m -1. This remark will be useful for transmission zeros at infinity: for example a filter of order N with an in-line coupling topology has a zero of order N at infinity. The rationality of F 1,1, = p/q leads us to consider the following interpolation problem: supposing (ω 1 , . . . ω l ) are all the filter's transmission zeros of respective order (m 1 , . . . m l ) ( m k = N ), find all the polynomials pairs (p, q) satisfying:

∀k ∈ {1 . . . l} ∀i ∈ {0 . . . 2m k -1} p q (i) (ω k ) = S (i) 1,1 (ω k ) (3)
The system (3) defines a rational interpolation problem, of Padé multipoint type [START_REF] Cheney | Introduction to Approximation Theory[END_REF], and can be solved classically using elementary methods from linear algebra. The system of equations (3) contains 2N equations compared to the 2N + 2 unknowns corresponding to the coefficients of polynomials p and q. It is therefore no surprise that the following holds:

Proposition 2.1: All the polynomial pairs (p, q) of degree at most N that solve (3) form a two dimensional space 1 . In particular there exist (p 1 , q 1 ) and (p 2 , q 2 ), such that for all complex numbers (α, β), the pair (p, q) defined as:

p = αp 1 + βp 2 q = αq 1 + βq 2 (4)
is a solution to (3). Moreover any two pairs of distinct solutions satisfy,

p 1 q 2 -q 1 p 2 = γ 2 r 2 (5)
where r is the transmission polynomial

r = ω k =∞ (s -ω k ) m k
and γ a complex number (depending on the special choice of the solution pair). 1 Strictly mathematically speaking this assertion is true, only generically (for almost all), with respect to the interpolation data

S i 1,1 (ω k )
The lack of uniqueness of the identified filter's reflexion coefficient is coherent with the following remark: one can always intercalate between the filter and the load (see Fig. 2) an arbitrary constant (independent of the frequency) chain matrix followed by its inverse, and this without changing the reflexion parameter S 1,1 of the system. The filter's response is therefore, at most recoverable up to the chaining of a constant chain matrix at its port two. The following proposition shows that this is the sole uncertainty on the filter's response: Proposition 2.2: In the notations of proposition (2.1), and for any two pairs a = (p 1 , q 1 ) and b = (p 2 , q 2 ) solutions of (3), the scattering matrix:

F a,b = 1 q 1 p 1 γr γr q 2 (6)
is a possible solution to our de-embedding problem, in the sense that:

• F a,b has ω k as transmission zeros • F a,b is of McMillan degree at most N (its determinant is a rational function of degree at most N ) • It satisfies equation ( 2) at every transmission zero ω k Moreover every solution in this sense to the de-embedding problem can be obtained like that. Eventually, for any two choices of solutions (a, b) and (a ′ , b ′ ), F a,b and F a ′ ,b ′ differ only up to the chaining of a constant chain matrix on their second port. In order to access the electrical parameters of the filter we need now to consider circuital realizations of the derived rational scattering matrices. The considered circuital realization consists in the classical low-pass prototype [START_REF] Cameron | Microwave Filters for Communication Systems : Fundamentals, Design and Applications[END_REF], made of coupled resonators with a specified coupling topology. Following proposition indicates that most of the electrical parameters of the filter are recovered.

Proposition 2.3: Suppose that the filter has at most N -2 transmission zeros at finite frequencies, in order to admit a circuital realization with no source-load coupling [START_REF] Cameron | Microwave Filters for Communication Systems : Fundamentals, Design and Applications[END_REF]. Suppose that the scattering matrix F is a possible solution of the de-embedding problem (in the sense of proposition 2.2) and admits a circuital representation characterized by a (N +2)×(N +2) coupling matrix M . Then any other scattering matrix F ′ , also solution of the de-embedding problem, admits a circuital representation with coupling matrix M ′ that differs from M only for:

• the frequency offset of the last cavity of the filter (nearest to the load), that is the value M N,N of the coupling matrix • the value of the output coupling represented by M N,L in the coupling matrix (see [START_REF] Cameron | Microwave Filters for Communication Systems : Fundamentals, Design and Applications[END_REF]) The preceding proposition indicates that the uncertainty on the scattering matrix of the filter has a very localized impact on its circuital representation. This is coherent with the fact that this uncertainty weighs on the value of a constant chain matrix plugged at its output port.

III. DE-EMBEDDING FILTERS FROM A MULTIPLEXER

The problem of de-embedding filters from a multiplexer, when starting from external measurements, is in many aspects similar to the simplified situation considered in section II. If we call G the scattering matrix of the multiplexer:

• Each filter appears to be loaded at its second port by a component regrouping the remaining filters connected via the junction • For all these sub-systems, composed of a filter loaded by an unknown component, the reflexion at port 1 is known.

For the first filter, it is for example given by the scattering parameter G 2,2 , for the second filter by G 3,3 etc... • The transmission zeros, for example of filter 1, are also present in the transmission parameters G 2,1 , G 2,3 , G 2,4 . . . . This property, as we will see, can be used to locate them. The core idea of the de-embedding algorithm is to perform a line-wise rational approximation of the scattering measurement of G: we will detail it from the perspective of the deembedding problem of filter 1.

We start with a rational approximation of the line

[G 2,2 , G 2,1 , G 2,3 . . . ].
The order of the rational approximation is chosen so as to get a proper fitting of the measurements and is in general higher than the filter's order: an additional increase in degree is introduced to approximate the effects of the loading. If the filter is expected to have finite transmission zeros, they can be identified using the following remark: the finite transmission zeros of filter 1 are the common zeros of the transmission parameters G 2,1 , G 2,3 , . . . (apart from unlikely situations where all the filters have the same transmission zeros, or the junction itself has a transmission zero). Their locations can therefore be obtained by analyzing the common zeros of the numerators of the rational approximations of G 2,1 , G 2,3 , . . . . Eventually the values and derivatives of the right hand term of (3) will be provided by evaluating the rational approximation of G 2,2 . Extraction of coupling parameters is then obtained following the procedure outlined in section II.

IV. PRACTICAL EXAMPLE: MEASURED DIPLEXER

We consider an example, made of a manifold diplexer manufactured in one piece shown in Figure .3. Both filters are of order 5 and implement an in-line coupling topology: all transmission zeros are therefore at infinity. To test our approach we ran several measurements of all the device's scattering parameters, while screwing in and out some tuning screws. Tuning screws entering laterally into the coupling windows between two cavities act like small capacities: when turned in, the corresponding coupling tend to augment. One can also expect the resonating cavities of the adjacent cavities to be slightly affected by the coupling screws. In order to get a reference, we therefore ran a first identification of filter 1 and found the following coupling matrix: We then turned in the coupling screw between the 3 rd and the 4 th cavity, measured the diplexer, and identified the coupling matrix of the first filter as: The predicted increase of the coupling M 3,4 is confirmed by the identification as well as a variation of the resonating frequency of the 4 th cavity. As explained in section II the identified element M 5,5 and M N,L should not be given attention to. Other similar examples, handling for example triplexer filters implementing finite transmission zeros in a "quartet" topology", have been de-embedded with success but are not reported here due to lack of space.

V. CONCLUSIONS

In this paper we presented a method to extract electrical parameters of the multiplexer's filters through the sole knowledge of external scattering measurements. The method can be seen as an analogue, in the context of system identification, of Darlington's extraction procedure [START_REF] Carlin | Wideband Circuit Design[END_REF] used in the context of filter synthesis. The method was validated on practical examples and is suited for applications in the context of computer assisted tuning and fault diagnosis. Although it has not been tested yet, application of the methodology to other complex devices combining filters that can be accessed by only one of their port seems promising.

Fig. 2 .

 2 Fig. 2. Filter with an arbitrary load on port 2

Fig. 3 .

 3 Fig. 3. Manufactured diplexer. Tuning screws are used to adjust couplings and resonating frequencies of the cavities


Ludovic Jacquin
email: ludovic.jacquin@gmail.com

Vincent Roca
email: vincent.roca@inria.fr

Jean-Louis Roch
email: jean-louis.roch@imag.fr

Too Big or Too Small? The PTB-PTS ICMP-based Attack against IPsec Gateways

This work introduces the "Packet Too Big"-"Packet Too Small" ICMP based attack against IPsec gateways. We explain how an attacker having eavesdropping and packet injection capabilities, from the insecure network where he only sees encrypted packets, can force a gateway to reduce the Path MTU of an IPsec tunnel to the minimum, which triggers severe issues for the hosts behind this gateway: depending on the Path MTU discovery algorithm in use, the attack either creates a Denial of Service or major performance penalties. This attack highlights two fundamental problems that we discuss, along with potential counter-measures to mitigate the attack while keeping ICMP benefits.

I. INTRODUCTION

IPsec and ESP [START_REF] Kent | Security architecture for the internet protocol[END_REF][2] offer a convenient secure tunnelling capability that is largely used to interconnect remote networks, or a remote host to its home network, throughout an unsecured network, typically the Internet.

Naturally IPsec interacts with the IP protocol suite, and in particular with the Internet Control Message Protocol (ICMP). A first goal of ICMP is to exchange control and error messages, like packet processing error notifications. ICMP is also involved in several functionalities and in particular the Path Maximum Transmission Unit discovery (PMTUd) mechanism [START_REF] Mogul | Path mtu discovery[END_REF], [START_REF] Luckie | Inferring and debugging path MTU discovery failures[END_REF], [START_REF] Luckie | Measuring path MTU discovery behaviour[END_REF] whose goal is to find the maximum packet size on a path that avoids packet fragmentation. Such a mechanism is essential from a performance point of view: if a packet is too large, its fragmentation and reassembly will negatively impact performance. At the other extreme, if a packet is significantly smaller than the maximum size permitted throughout the path, it will also negatively impact performance. Assessing the correct packet size on a path is therefore essential. But ICMP is also known to be a cause of attacks and therefore there is an incentive for a network administrator to filter out these packets. A balance is therefore required between these contradictory objectives, and it is recognized that only a subset of ICMP packets should be considered by IPsec gateways (we detail this in section III-C).

The problem this work addresses is the following: how can an attacker exploit ICMP to mount Denial of Service (DoS) attacks to the users of IPsec gateways? We assume the attacker is located in the Internet (the insecure network) and has realistic capabilities. Our contributions are threefold:

• we identify a new ICMP based attack on IPsec gateways, called "Packet Too Big"-"Packet Too Small" (PTB-PTS) that departs from the already known ICMP attacks. Our attack uses realistic assumptions in terms of the attacker capabilities, making it a realistic threat: eavesdropping and traffic injection capabilities in the untrusted network (where the attacker only sees ciphered packets) are sufficient, which is fulfilled for instance if the attacker and the target are both attached to the same insecure WiFi network;

• we give an account of a real exploit, on a testbed running a recent Debian distribution, with default system and IPsec configurations, where an external attacker can either stall TCP connections going through the IPsec tunnel, or create major performance penalties.

We show this attack is effective no matter whether the hosts, on the trusted networks, use the classic PMTUd or the new Packetization Layer PMTUd (PLPMTUd) algorithms;

• we analyze and discuss the two fundamental problems that made this attack possible, namely: (1) the impossibility to distinguish legitimate from illegitimate ICMP packets coming from the untrusted network, and

(2) the contradictions in the way Path MTU is managed by end hosts when this Path MTU approaches the minimum packet size any link should support, whereas at the same time tunnelling is needed on the path;

The paper is organized as follows: section II introduces the network and attacker model; section III describes IPsec and ICMP; section IV details our attack, illustrated with a real exploit; section V discusses the fundamental problems and some counter-measures; section VI position our work in front of related works; and finally we conclude.

II. NETWORK AND ATTACKER MODELS

A. The red-black network model

Our network model identifies two zones: the trusted areas, consisting of networks and hosts behind IPsec gateways, also called "red networks", and the outer world considered as untrusted, typically the Internet, also called "black network". Trusted areas are interconnected by gateways through IPsec tunnels (site-to-site configuration of Fig. 1). An isolated host having IPsec capabilities can also establish an IPsec tunnel to its remote home network (host-to-site configuration).

The aim of the IPsec gateway is to secure the traffic between remote trusted networks and/or hosts by encrypting packets sent over the untrusted black network. Since the gateways are directly connected to the black network, they are naturally the first line of defense against attackers.

B. The attacker model: a realistic scenario

Because of the network model, all the attacks are conducted by adversaries located on the external black network. We assume an attacker can both eavesdrop the traffic in the IPsec tunnel and inject forged packets (we justify these choices below). We also assume an attacker has no way to decrypt packets nor encrypt its own packets because the underlying IPsec cryptographic building blocks and key exchange protocols are considered secure. The goal of the attacker is to launch a DoS against the secure tunnel service provided by IPsec gateways, for both kinds of IPsec configurations: host-to-site and site-to-site. This is a realistic attacker model. For instance, the attacker can be located on a compromised router along the path followed by an IPsec tunnel, in the black network 1 . But more simply it can also be an attacker attached to the same insecure WiFi network (e.g. that does not use WPA/WPA2 security) as the target user that connects to his home network through an IPsec VPN, which is a rather common situation.

III. IPSEC AND ICMP IN A NUTSHELL

In this section we give some background on IPsec [START_REF] Kent | Security architecture for the internet protocol[END_REF], ICMP [START_REF] Postel | Internet control message protocol[END_REF], and the two standardized algorithms to discover the maximum packet size along a path. Then we discuss standard recommendations for ICMP processing policies within IPsec.

A. IPsec overview

IPsec has two core protocols, AH [START_REF] Kent | IP authentication header[END_REF] and ESP [START_REF] Kent | IP encapsulating security payload (ESP)[END_REF], and two modes of operation, transport and tunnel. In our work we consider the usual solution, IPsec/ESP in tunnel mode, where IPsec/ESP provide confidentiality, authentication, integrity and anti-replay services. More precisely, the incoming IP datagram (called inner IP packet) arriving at the tunnel endpoint is ciphered by ESP and tunneled in a new IP header (called outer IP packet). Upon leaving the other tunnel endpoint, the opposite operations take place.

IPsec requires three major databases: the Security Policy Database (SPD), the Security Association Database (SAD) and the Peer Authorization Database (PAD). Throughout the paper, we only focus on the SAD since it stores important information about active tunnels, like ciphering keys (initialized by the IKEv2 [8] protocol) and the PMTU (see section III-B1) for this tunnel, which plays a key role in our attack. Each entry in this SAD is identified by a Security Parameters Index (SPI), that is copied in clear in the outer IP packet header.

B. Path MTU discovery overview

Path MTU discovery (or PMTUd) is a key mechanism for optimum network performance since it enables a sender to determine the appropriate packet size along a path dynamically (the path may change over time) [START_REF] Egi | Understanding the packet Processing Capabilities of Multicore Servers[END_REF], [START_REF] Dobrescu | RouteBricks: exploiting parallelism to scale software routers[END_REF], [START_REF]Myricom 10-Gigabit Ethernet Performance Measurements[END_REF]. Two complementary PMTU discovery algorithms have been standardized and are in use nowadays.

1) The legacy PMTUd mechanism: PMTUd [START_REF] Mogul | Path mtu discovery[END_REF] is the legacy approach. Let us illustrate its behavior in an IPv4 (resp. IPv6) network. A sender sets the Don't Fragment (DF) bit in a packet 2 . If a router cannot transmit this packet because of its size, it must send back to the sender an ICMP "Destination unreachable"/"Fragmentation needed" packet (resp. an ICMPv6 "Packet Too Big"/"Fragmentation needed"), along with the next hop MTU information. In the following we will call these error packets ICMP PTB (Packet Too Big), regardless of whether IPv4 or IPv6 is used. Iteratively, upon receiving such an ICMP PTB packet, the sender decreases the packet size until it reaches the lowest MTU on the path to the destination. The PMTU is then found and will be used by the sender for outgoing packets sent to this destination. Since the path can change dynamically (e.g., due to re-routing), this process needs to be performed periodically. So we see that ICMP is heavily used in the this PMTUd algorithm.

Although efficient, the PMTUd approach suffers from several limits, mainly because ICMP packets are often filtered out by some routers/firewalls [START_REF] Jacquin | IBTrack: An ICMP Black holes Tracker[END_REF] along their route to the sender. In that case the sender needs another technique to discover the Path MTU.

2) The Packetization Layer PMTUd mechanism: To overcome these issues, the IETF developed a new Path MTU discovery mechanism that does not rely on ICMP, the Packetization Layer PMTUd (PLPMTUd) [START_REF] Mathis | Packetization layer path mtu discovery[END_REF]. Instead of using ICMP, it relies on a packetization layer protocol with an acknowledgement mechanism, such as TCP. Using this protocol (e.g. TCP), the sender sends probing packets of a specific size to the destination. If the probing packet is acknowledged, the sender validates that the PMTU is at least equal to the probing packet size, while a time-out indicates that the PMTU is smaller. With TCP, any data segment can be used as a probing packet if enough data is available to fill in the payload. Here also, because the path may change, the PLPMTUd process needs to be performed periodically.

C. ICMP processing in IPsec

IPsec specifies dedicated rules to process ICMP packets and administrators need to decide, through configuration, how to handle them. More precisely, a distinction is made between error and informational ICMP packets, as well where they are coming from ([1] Sections 5 and 8). The recommended treatments are summarized in Table I. For our attack, the most important row is the last one that corresponds to untrusted ICMP error packets. If the policy is unspecified, there are strong incentives to consider separately the case of ICMP PTB error packets in order to enable PMTUd [START_REF] Kent | Security architecture for the internet protocol[END_REF]. We now review two measures that help improving the security of ICMP PTB packets processing. a) Minimum sanity check for untrusted ICMP error packets: the processing of ICMP error packets coming from the untrusted network must satisfy the following sanity check ([14], section 2.3). ICMP requires that such an ICMP error packet include in its payload the beginning of the packet that triggered the error. Upon receiving the error packet, the IPsec protocol must verify that the outer header of the packet that triggered the error (i.e., contained in the ICMP payload) maps to a valid entry in the SAD, by checking the source/destination IP addresses and SPI. If not, the ICMP packet must be immediately discarded. b) Additional sanity checks: in addition to the minimum sanity check, some IPsec implementations (including the one we considered, see section IV) decrypt the ICMP packet payload, recover the inner IP packet header and verify that the source/destination IP addresses of the inner packet match the SAD entry associated to the SPI. If the check fails, the packet is immediately dropped. This is an easy solution to avoid blind attacks, coming from attackers that are not able to eavesdrop an active tunnel. However it offers no protection if the attacker is on the path followed by the IPsec tunnel (a feature our PTB-PTS attack relies on).

ICMP
[1] also recommends to "establish a minimum PMTU for the traffic (on a per destination basis), to prevent receipt of an unauthenticated ICMP from setting the PMTU to a trivial size". We will see in our attack that this is not necessarily sufficient.

IV. ATTACK DESCRIPTION BASED ON A REAL EXPLOIT

Our attack is designed to take place both in site-to-site or host-to-site configurations (Fig 1). It is carried out from the untrusted network, and through the IPsec gateway, the attack targets hosts in the trusted network, behind the gateway (i.e., in host-to-site configuration, the site is the target, not the isolated host). We assume the attacker can eavesdrop and inject traffic on the untrusted network, as described in section II-B. However a single ICMP packet is sufficient for the attack, which means it can easily remain unnoticed.

A. Experimental conditions

We illustrate the attack through an exploit, using two onthe-shelf IPsec gateways with their default configuration 3 . The gateways as well as the end machines are all running the stable "Squeeze" Debian distribution [START_REF]Debian -The Universal Operating System[END_REF], with Linux kernel 3.2.1 [START_REF]The Linux kernel[END_REF]. However this attack is not specific to this distribution. We exhibit the impacts of the attack on a user, in a trusted red network, that tries to establish an ssh connection with a machine located on the remote trusted red network, through the IPsec tunnel, using IPv44 .

In the next section, we assume that hosts rely on the classic PMTUd algorithm (the default) and show that it leads to a DoS since the attacker can easily prevent any new ssh connection from being established.

Then, in section IV-C, we consider the case where hosts rely on the PLPMTUd alternative and show that the attacker can slow down the ssh connection (6+ seconds of connection delay) as well as limiting the TCP segment size to a tiny value much lower than the minimum MTU size of IPv4 which negatively impacts the throughput 5 .

Finally we also tested with a bulk UDP flow. Here also, the attack leads to a major slow down of the connection since the gateway needs to further segment IP datagrams.

B. DoS on TCP connections with hosts using PMTUd

Let us assume that end-hosts use PMTUd. The attack is illustrated in Fig. 2 and the corresponding tcpdump traces, collected on the red network, are shown in Fig. 3. Note that the traces show the two TCP flows (connections are bidirectional), whereas Fig. 2 is simplified and only shows the flow being attacked. In particular the ssh connection establishment involves the exchange of 784 bytes in one direction (which hit the gateway PMTU entry) and 848 bytes in the other direction (this segment is not subject to PMTU restrictions). Fig. 2: Our attack on an IPsec gateway, PMTUd case 1) Forging an ICMP PTB packet from the untrusted network: the attacker first has to forge an appropriate ICMP PTB packet (a single packet is sufficient). This is done by eavesdropping a valid packet from the IPsec tunnel on the untrusted network. Then the attacker forges an ICMP PTB packet (step 1 in Fig. 2), specifying a very small MTU value equal or smaller than 576 with IPv4 (resp. 1280 with IPv6). The attacker uses 0 in this case. This packet spoofs the IP address of a router of the untrusted network (in case the source IP address is checked), and in order to bypass the IPsec protection mechanism against blind attacks, it includes as a payload a part of the outer IP packet that has just been eavesdropped. This is the only packet an attacker needs to send. The following steps do not involve any action from the attacker.

2) Reset of the PMTU on the gateway: this ICMP packet is processed by the IPsec gateway. As the packet appears to belong to an active tunnel, the gateway stores the following PMTU value in its SAD (step 2):

PMTU SAD = max(MTU ICMP PTB , 576) = 576
It is important to note that the gateway does not store a proposed value smaller than the minimum guaranteed MTU (the attacker proposed 0 but 576 has been stored).

At this point, the traffic is not blocked in any way between the targeted gateway and the remote end of the tunnel. Nevertheless the throughput is reduced on the IPsec tunnel as any packet exceeding the PMTU SAD size must be fragmented (usually by the end-host as the DF bit is set).

3) Drop of the first large TCP segment: let us consider an ssh connection from outside, to a server located in the red network. The TCP three-way handshake happens normally because these TCP segments are tiny. However any further bulk data transfer on this connection is impacted. This is the case of the 784 + 52 = 836 byte packet (52 bytes for the TCP/IP headers, including TCP options) of step 3, which exceeds the PMTU SAD value stored in the SAD. Due to the encapsulation header (whose size depends on the chosen ciphering algorithm), the gateway restricts the MTU value to 514 bytes. Looking at Fig. 3, we see that the 8th packet (784 byte TCP segment) is immediately followed by an ICMP error packet with that MTU information. Therefore the TCP segments are fragmented (remember that the host sets the DF bit to be sure that no fragmentation appears later on in the network for performance reasons). Nevertheless, instead of creating 514 byte packets, as requested by the gateway, the host generates 500 + 52 = 552 byte packets (step 5). Since it remains too large, they are dropped by the gateway and this latter replies with ICMP PTB packets. After 2 minutes of failures, the ssh server initiates a half-close (FIN/ACK exchange) (but the other side of the TCP connection curiously remains open).

To conclude, the TCP connection is completely blocked and the DoS is successful.

C. Attack on TCP connections with hosts using PLPMTUd

As the DoS attack relies on a maximum packet size feature, we also experiment with the second path MTU discovery algorithm, PLPMTUd. The attack is illustrated in Fig. 4 and the corresponding tcpdump traces, collected on the red network, are shown in Fig. 5. We show below that the attack does have severe consequences even if it does not result on a DoS: (1) it considerably slows down the ssh connection opening and (2) it limits the TCP segment size to a tiny value which generates more overhead and reduces the maximum throughput.

The first two steps involving the attacker, identical to the PMTUd case, are omitted.

1)

Fragments handling by the gateway: due to the PLPM-TUd algorithm that progressively increases the segment size, the host now fragments the 784 byte ssh message into two TCP segments of size 500 and 284 bytes respectively (steps 3 and 3' of Fig. 4). The 500 byte size is typically a probing size, chosen by PLPMTUd, in order to test this small value. The 2) Large segment and ICMP PTB: the ICMP PTB packet is ignored as the PLPMTUd component only relies on acknowledgments and delay expirations. In our test, after expiration of the timeout for the first packet (at time 0.21s), the host sends an identical 552 byte packet to the gateway (step 5) because PLPMTUd already used the minimal size allowed by the host configuration. This pattern happens 5 times, generating a total of 5 ICMP PTB packets.

3) Further reduction of the segment size: 6.59s after the TCP connection establishment, the PLPMTUd component decides to drastically reduce the segment size: instead of a single 500 byte segment, it now sends a 256 byte TCP segment (step 13) followed by a 244 byte TCP segment. Being small enough, both of them are forwarded by the IPsec gateway. The ssh connection finishes after a few additional segments and a prompt appears in the terminal.

To conclude a huge delay of 6.59s was required for data to arrive to the destination. Additionally, any packet leaving the host after this initial delay contains at most 256 byte of data, which drastically reduces the TCP throughput and consumes more resources in the forwarding nodes 7 .

D. Attack on a bulk UDP flow

Let us now consider a UDP flow, where the application submits 1,100 byte data chunks to the UDP socket. The beginning of the attack is the same. Then the host sends a 1100 + 28 = 1128 byte IP packet with the DF bit set to 1 (no fragmentation). The IPsec gateway discards this packet and returns an ICMP PTB packet with the same 514 byte MTU indication as before. The following UDP datagram is fragmented into three IP packets of size 548, 548 and 72 bytes respectively. This time the DF bit is set to 0 in all three packets (fragmentation is authorized), probably to reduce the risks that these packets be dropped. At the gateway, it turns out that after encapsulation, the first two IP packets are again too large compared to the PMTU value of the SAD. Since fragmentation is authorized, they are once again fragmented into two packets each, of size 528 and 60 bytes respectively. At the end, the initial large UDP datagram is transmitted in the IPsec tunnel in five medium size or tiny IP packets (548, 60, 548, 60 and 112 bytes respectively), instead of a single packet (without the attack).

To conclude, our attack has different severe effects, depending on the transport protocol and PMTUd algorithm used, ranging from throughput reduction to DoS.

V. BACK TO THE FUNDAMENTAL PROBLEM HIGHLIGHTED BY THE ATTACK

The comprehensive analysis of our attack in section IV highlights two fundamental issues that we successively discuss, before considering potential counter-measures.

A. Issue 1: determining the legitimacy of untrusted ICMP packets

The first problem is the impossibility, for an IPsec gateway, to determine whether an ICMP PTB packet, coming from the black untrusted network, is legitimate (i.e., has been triggered by a valid transmission error) or not (i.e., has been forged by an attacker on the path to the destination). The two security measures discussed in section III-C (i.e., outer header verification and payload verification) are essential to avoid blind attacks, but not sufficient if the attacker is on the path followed by the IPsec tunnel as we have shown (in particular in presence of an unsecured WiFi network, see Section II-B). This is a fundamental limit given the current IPsec specifications. At the same time, filtering out all ICMP packets is not a solution as many hosts still rely on the traditional PMTUd algorithm. Another approach is required.

B. Issue 2: dealing with minimum Path MTU in presence of a tunnel

When the Path MTU advertised to the IPsec gateway approaches the minimum MTU each link technology should support (i.e., 576 bytes with IPv4, 1280 with IPv6), problems can arise as IPsec tunnelling adds the IP/IPsec/ESP headers.

There are two sides to the problem. First of all, we observe that the end-host does not accept the Path MTU advertised by the IPsec gateway if it is smaller than the minimum MTU configured locally. Indeed, the local component that takes this decision is not aware that the gateway operates an IPsec tunnel and needs some additional room. With the PMTUd approach, the compliance on the minimum MTU is strict and a DoS results. With the PLPMTUd approach, the end-host pragmatically uses (after some time) a TCP segment size significantly lower than this minimum MTU, no matter the local PMTU information. Communications are therefore feasible, although in a sub-optimal way.

The second side of the problem is that the IPsec gateway should not accept from the black network an ICMP PTB asking to reduce the MTU to 576 bytes, since the gateway will not be able to offer a minimum MTU at least equal to 576 bytes to the hosts on the red network. However there is a fundamental contradiction here since 576 bytes is a valid MTU value for a link. This is typically a situation where an alarm should be sent to the IPsec gateway administrator for this later to analyze the situation and decide what to do. The current situation where this contradiction is silently ignored is definitively not appropriate.

C. A (trivial) counter-measure: ignoring the DF bit

Several trivial counter-measures exist. One of them consists in configuring the IPsec gateway in such a way packets are fragmented regardless of the original DF bit setting. In our three scenarios, all the data packets sent by the endhost would have been fragmented silently as soon as they exceed the local 514 byte threshold. This is feasible (and recommended) with Cisco IOS 12.2(11)T and above ( [START_REF]IPsec Data Plane Configuration Guide[END_REF], "DF Bit Override Functionality with IPsec Tunnels" section). The attack is mitigated, but as mentioned in this reference, "a significant performance impact occurs at a high data rate". In some sense, the attack has succeeded since it may remain unnoticed for a long period while seriously impacting the VPN performance.

D. Another counter-measure: confirming the ICMP PTB information with a gateway probing mechanism

An approach to the problem is the following: since the legitimacy of an untrusted ICMP packet cannot be determined, the idea is to confirm an ICMP PTB information with a side mechanism. Therefore we propose that the IPsec gateway uses a PLPMTUd-like probing mechanism. It works as follows. The gateway generates a probing packet of a certain size and sends it on a given path. In order to determine if this size is compatible with this path, the remote IPsec gateway is supposed to acknowledge it upon reception, otherwise a timeout is supposed to be triggered at the gateway. If the PLPMTUd probing does not confirm the ICMP PTB information, then this ICMP packet is declared erroneous and should be ignored. For this mechanism to be effective, the attacker should not be able to identify in real time the probing packets in the tunnel in order to discard them selectively and let the gateway think the probe is actually too large 8 .

In some situations, this gateway level probing, done periodically, could totally replace the ICMP mechanism. However ICMP (if ICMP packets are not already filtered out by Internet routers) may be more reactive than a periodic probing, and we believe that both mechanisms can safely work in parallel.

VI. RELATED WORK

IPsec has attracted the attention of the security and cryptography communities. Some works describe attacks related to the misuse of cryptographic primitives in IPsec. The authors of [START_REF] Degabriele | Attacking the IPsec Standards in Encryption-only Configurations[END_REF], [START_REF] Degabriele | On the (in)security of IPsec in MAC-then-encrypt configurations[END_REF] have discovered several weaknesses related to an incorrect usage of encryption. [START_REF] Mccubbin | Initialization Vector Attacks on the IPsec Protocol Suite[END_REF], [START_REF] Nikov | A DoS Attack Against the Integrity-Less ESP (IPSec)[END_REF] focus on DoS attacks against the "encryption only" configuration of IPsec. These works are based on the possibility of a forgery attack on the Initialization Value to change an inner header field. Our work follows a purely network approach to uncover weaknesses.

ICMP has been used for DoS and distributed DoS attacks for a long time (ping flood is detailed in every network security textbooks [START_REF] Northcutt | Network Intrusion Detection[END_REF]). DoS attacks such as Smurf attack [START_REF]Smurf IP Denial-of-Service Attacks[END_REF] and Tribe Flood Network attack [START_REF]Similar Attacks Using Various RPC Services[END_REF] are respectively based on ICMP "Echo Request" using a spoofed IP source (the victim) plus a broadcast IP destination, and ICMP "Echo Reply" plus a botnet. Both attacks aim to flood the target with ICMP packets. Many implementations of ICMP do not handle correctly packets larger than the maximal value recommended by the RFCs. These oversized ICMP packets, well-known as "Ping of Death", can disable a host. Otherwise flooding the victim with "Echo Request/Reply" packets has long been considered. But this is also easily avoided with appropriate filtering rules in the IPsec gateway. A more advanced attack detection mechanism [START_REF] Barbhuiya | An Active Detection Mechanism for Detecting ICMP Based Attacks[END_REF] relies on the response of monitored systems to probes but does not propose any algorithm to handle the ICMP PTB packets attacks. We see that our work totally departs from these "traditional" attacks and uses techniques that bypass the counter measures.

The authors of [START_REF] Mogul | Path mtu discovery[END_REF], [START_REF] Mccann | Path mtu discovery for ip version 6[END_REF] acknowledge the existence of threats related to the use of ICMP PTB packets (e.g. for blind throughput-reduction attack against TCP [START_REF] Gont | ICMP attacks against TCP[END_REF]). The authors of [START_REF] Gont | Recommendations for filtering ICMP messages[END_REF] detail for the various ICMP packets the associated threats and provide advice to mitigate them. Our work goes more deeply in this direction and introduces a new threat associated to the ICMP PTB packets.

VII. CONCLUSION

In this work we show that the ICMP PTB (Packet Too Big) messages are an efficient attack vector against IPsec gateways, as soon as an attacker has eavesdropping and traffic injection capabilities in the "black" untrusted network, which we believe are realistic assumptions (e.g. in an insecure WiFi network). We demonstrate the PTB-PTS attack an exploit in a Debian-based testbed. We show the attack results in either a DoS or major performance penalties, for both TCP and UDP flows.

The PTB-PTS attack highlights two fundamental problems: the impossibility to determine the legitimacy of untrusted ICMP packets, and issues in dealing with minimum Path MTU in presence of a tunnel. We therefore suggest a counter measure at the IPsec gateways that consists in confirming the information carried by ICMP PTB packets with an active probing approach. Future works will enlarge the scope of this study, by considering other Operating Systems as well as tests with IPv6. We will also experiment with the gateway-level counter measure that we propose.

Fig. 1 :

 1 Fig. 1: Network model showing the site-to-site (bottom) and host-to-site (top) configurations.

Fig. 3 :

 3 Fig. 3: tcpdump trace on the red network during the attack, PMTUd case. Here the remote client machine with IP address a.b.10.7 tries to ssh to the local machine with IP address a.b.11.5, located behind the IPsec gateway with IP address a.b.11.4. (NB: non required information has been removed from these traces)

4 )

 4 ICMP PTB error packet on the trusted network: therefore the IPsec gateway emits an ICMP PTB packet (step 4) with the following MTU indication: MTU = PMTU SAD -size encapsulation IP/IP sec/ESP

5 )

 5 Deadlock on the red network: upon receiving this ICMP PTB packet, the host computes the PMTU to use 6 : PMTU = max(MTU ICMP PTB , MTU config. ) = 552

Fig. 5 :

 5 Fig. 5: tcpdump trace on the red network during the attack, PLPMTUd case. Notations are consistent with Fig. 3

Fig. 4 :

 4 Fig. 4: Our attack on an IPsec gateway, PLPMTUd case

TABLE I :

 I Recommended ICMP processing rules in IPsec.

  0.000000 a.b.10.7.48058 > a.b.11.5.ssh: S * : * (0) win 17920 <mss 8960,sackOK,timestamp 1245892 0,nop,wscale 7> (DF) 0.000146 a.b.11.5.ssh > a.b.10.7.48058: S * : * (0) ack * win 17896 <mss 8960,sackOK,timestamp 1319280 1245892,nop,wscale 7> (DF) 0.000304 a.b.10.7.48058 > a.b.11.5.ssh: . ack 1 win 140 <nop,nop,timestamp 1245892 1319280> (DF) 0.004561 a.b.11.5.ssh > a.b.10.7.48058: P 1:33(32) ack 1 win 140 <nop,nop,timestamp 1319281 1245892> (DF) 0.004698 a.b.10.7.48058 > a.b.11.5.ssh: . ack 33 win 140 <nop,nop,timestamp 1245893 1319281> (DF) 0.004773 a.b.10.7.48058 > a.b.11.5.ssh: P 1:33(32) ack 33 win 140 <nop,nop,timestamp 1245893 1319281> (DF) 0.004858 a.b.11.5.ssh > a.b.10.7.48058: . ack 33 win 140 <nop,nop,timestamp 1319281 1245893> (DF) 0.004933 a.b.11.5.ssh > a.b.10.7.48058: P 33:817(784) ack 33 win 140 <nop,nop,timestamp 1319281 1245893> (DF) 0.004953 a.b.11.4 > a.b.11.5: ICMP ERROR: a.b.10.7 unreachable -need to frag (mtu 514) [tos 0xc0] 0.004998 a.b.10.7.48058 > a.b.11.5.ssh:

			P 33:881(848) ack 33 win 140 <nop,nop,timestamp 1245893 1319281> (DF)
	0.005084 a.b.11.5.ssh	> a.b.10.7.48058: . 33:533(500) ack 33 win 140 <nop,nop,timestamp 1319281 1245893> (DF)
	0.005092 a.b.11.4	> a.b.11.5:	ICMP ERROR: a.b.10.7 unreachable -need to frag (mtu 514) [tos 0xc0]
	0.005095 a.b.11.5.ssh	> a.b.10.7.48058: P 533:817(284) ack 33 win 140 <nop,nop,timestamp 1319281 1245893> (DF)
	0.005228 a.b.10.7.48058 > a.b.11.5.ssh:	. ack 33 win 140 <nop,nop,timestamp 1245893 1319281,nop,nop,sack 1 {533:817} > (DF)
	0.043580 a.b.11.5.ssh	> a.b.10.7.48058: . ack 881 win 154 <nop,nop,timestamp 1319291 1245893> (DF)
	0.215586 a.b.11.5.ssh	> a.b.10.7.48058: . 33:533(500) ack 881 win 154 <nop,nop,timestamp 1319334 1245893> (DF)
	0.215594 a.b.11.4	> a.b.11.5:	ICMP ERROR: a.b.10.7 unreachable -need to frag (mtu 514) [tos 0xc0]
	0.639580 a.b.11.5.ssh	> a.b.10.7.48058: . 33:533(500) ack 881 win 154 <nop,nop,timestamp 1319440 1245893> (DF)
	0.639586 a.b.11.4	> a.b.11.5:	ICMP ERROR: a.b.10.7 unreachable -need to frag (mtu 514) [tos 0xc0]

The

revelations about large scale surveillance demonstrate this assumption is realistic.

This is useless in IPv6 since fragmentation is not supported any more.

Since we assume that most administrators do not change the default IPsec policies with regard to ICMP processing, we did not change them.

In this configuration, the attacker targets the gateway of the ssh server. We also tested the symmetric configuration (gateway of the ssh client). Since the results are exactly the same, they are not shown.

We show an exploit with an interactive ssh connection for which throughput is not an issue. But the attack consequences will be more serious with an application doing bulk data transfer on top of TCP or HTTP.

The 552 value comes from the default Debian configuration, but a recent Linux (here FedoraCore 20) uses the same value: cat /proc/sys/net/ipv4/route/min_pmtu returns 552. This value can be changed by the administrator.

Router performance (number of packets per second) is relatively independent of the packet size, but the lower the size, the lower the throughput.

Note that these capabilities go much farther than what is permitted in our attacker model (section II-B).