Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
  • H04L63/1441—Countermeasures against malicious traffic
  • H04L63/1458—Denial of Service
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L61/00—Network arrangements, protocols or services for addressing or naming
  • H04L61/35—Network arrangements, protocols or services for addressing or naming involving non-standard use of addresses for implementing network functionalities, e.g. coding subscription information within the address or functional addressing, i.e. assigning an address to a function
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
  • H04L63/0227—Filtering policies
  • H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
  • H04L63/0227—Filtering policies
  • H04L63/0245—Filtering by information in the payload
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
  • H04L63/0227—Filtering policies
  • H04L63/0263—Rule management
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
  • H04L63/101—Access control lists [ACL]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
  • H04L63/1441—Countermeasures against malicious traffic
  • H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L2101/00—Indexing scheme associated with group H04L61/00
  • H04L2101/60—Types of network addresses
  • H04L2101/695—Types of network addresses using masks or ranges of addresses

Definitions

• the field of the invention is that of communications within a communication network, for example an IP network, and in particular that of value-added IP services.
• the invention offers a solution for verifying the validity of an IP resource associated with a domain, ie, verifying that an IP address, an IP prefix (set of IP addresses), a domain name, etc. , is effectively associated with this domain.
• the invention finds in particular, but not exclusively, applications in the field of mitigation of attacks by distributed denial of services (in English DDoS, for “Distributed Douai of Service”), in particular for facilitating the coordination of mitigation actions . It can in particular be implemented before or during a mitigation procedure.
• a DDoS attack is an attempt to make resources, for example network or computing resources, unavailable to their users.
• resources for example network or computing resources
• Such attacks can be massively deployed by compromising a large number of hosts, and by using these hosts to amplify attacks.
• DDoS Protection Services In order to overcome these DDoS attacks, services for detecting and mitigating DDoS attacks are offered by certain access or service providers to their customers. Such mitigation services (in English DPS for "DDoS Protection Services”) can be hosted within the infrastructures operated by access providers or in the “cloud” (in French “cloud”). They allow in particular to distinguish “legitimate” traffic, i.e., data consented by the user, from “suspicious” traffic.
• DOTS DDoS Open Threat Signaling
• a DOTS client attached to that client domain can send a message to the DOTS server asking for help.
• the latter coordinates, with a mitigation entity (in English “mitigator”), the actions to be carried out so that the suspicious traffic, associated with the denial of service attack, is no longer routed to the client domain, while the traffic legitimate continues to be routed normally to the client domain.
• a mitigation entity in English “mitigator”
• This solution uses two communication channels between the DOTS client and the server
• DOTS Signal Channel a DOTS signaling channel
• DOTS Data channel in English "DOTS Data Channel”
• the DOTS signaling channel is only used when a DDoS attack is in progress.
• a DOTS client can use this channel to request assistance from the DOTS server.
• a DOTS client uses this signaling channel to send a request to its server informing it that the prefix "1.2.3.0/24" is undergoing a DDoS attack, so that the server can take actions to end the attack.
• Such a signaling channel is described in particular in the document “Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification”, draft-ietf-dots-signal-channel, Reddy, T. et al., January 2018.
• DDoS Distributed Denial-of-Service Open Threat Signaling
• the DOTS data channel is used when no DDoS attack is in progress. Classes.
• a DOTS client can use this channel to install filtering rules, such as filtering traffic received from certain addresses or traffic destined for a given node.
• a DOTS client can use this DOTS data channel to request the server to block all traffic to the prefix "1.2.3.0/24".
• Such a data channel is described in particular in the document “Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel”, draft-ietf-dots-data-channel, Reddy, T. et al., December 2017.
• the server does not have a mechanism to verify that the prefix "1.2.3.0/24" is actually associated with the domain of the DOTS client, service disruptions may be observed by the legitimate owner of this prefix (ie, the entity in charge of managing this prefix, for example the access provider).
• the nodes to which an address extracted from this prefix is allocated may no longer receive traffic in the event of the implementation of traffic circumvention measures associated with this prefix or of filtering on all traffic having a destination address falling under this prefix.
• the DDoS mitigation service may be billed to legitimate owners, even though they were not the source of the mitigation request.
• the IETF recommends activating BCP 38 ("Network Ingress Filtering: Defeating Douai of Service Attacks which employ IP Source Address Spoofing", P. Ferguson et al. , May 2000), and the uRPF (“Unicast Reverse Path Forwarding” function, RFC2504: “Users' Security Handbook” E. Guttman et al., February 1999).
• BCP 38 Network Ingress Filtering: Defeating Douai of Service Attacks which employ IP Source Address Spoofing
• uRPF Unicast Reverse Path Forwarding
• SAVI Session Description Protocol
• SIP Session Initiation Protocol
• DOTS DOTS
• the validation of the addresses is done on the basis of the source address of a packet, the available databases, for example a database managed by a RIR ("Regional Internet Registry"), are informed by the resource owners IP (i.e., generally, operators) or provide only the identity of the owners of IP resources,
• the invention provides a new solution for verifying the validity of an IP resource associated with a client domain, i.e., for verifying the membership of an IP resource in a client domain.
• an IP resource belongs to the group comprising:
• IP address for example an IPv4 or IPv6 address
• IP prefix for example an IPv4 or IPv6 prefix
• a method for verifying the validity of an IP resource associated with a client domain implements the following steps in a server, called an access control server:
• a method for declaring an IP resource associated with a client domain implements the following steps in a client node of the client domain:
• the access control server is configured to verify that said at least one IP resource is associated with the client domain.
• a method of processing a request for validation of an IP resource associated with a client domain implements the following steps in a relay node of the client domain, associated with at least one selected IP resource by a access control server from a list of at least one IP resource associated with the client domain, previously transmitted from a client node of the client domain to the access control server:
• a method of verifying the validity of an IP resource associated with a client domain implements the following steps in a validation server associated with at least one IP resource selected by a control server d access from a list of at least one IP resource associated with the client domain, previously transmitted from a client node of the client domain to the access control server:
• identification of the client domain from information representative of the identity of the client domain
• the verification method further comprises the transmission of a confirmation message or an error message to the access control server.
• the proposed solution thus makes it possible to verify that an IP resource is actually (and legitimately) associated with a client domain.
• the proposed solution makes it possible to check whether the IP resource identifying the at least one other node is effectively associated with the client domain, for example allocated to at least one node in the client domain, or if the traffic destined for this IP resource is legitimately routed to this client domain.
• the access control server can verify whether a mitigation or filtering request transmitted by a client node of the client domain, actually concerns this client node or another node of the domain client, before taking any action so that suspicious traffic is no longer routed to the client domain.
• the proposed solution does not require to use the infrastructure of the access provider.
• the proposed solution makes it possible to verify the validity of an IP resource associated with a client domain, whether the DPS mitigation service is hosted within the infrastructure operated by the access provider, in the "cloud", or elsewhere.
• the proposed solution makes it possible to improve the reliability, the robustness and / or the efficiency of the responses to DDoS attacks.
• the method of verifying the validity of an IP resource makes it possible to verify in real time the information relating to allocating IP resources to customers, without disclosing their identity, including in the context of dynamic allocation of IP resources.
• the list is updated periodically and / or if an IP resource associated with the client domain is added, deleted or modified.
• the proposed solution allows to validate an IP resource regularly, and / or in case of addition, deletion or modification of an IP resource associated with the client domain.
• the access control server can automatically delete the IP resource or resources concerned from its tables at the end of the validity period.
• a client node can update the list of IP resources associated with the client domain without waiting for the expiration of the validity period.
• a resource validation is obsolete, which is particularly of interest in the case of networks with frequent renumbering (that is to say, the IP addresses or prefixes allocated to the nodes of the network are frequently changed).
• the access control server must check at time Tl that the 1.2.3.0/24 prefix is always associated with the same client domain to decide whether to filter or route traffic to this 1.2.3.0/24 prefix.
• the method of verifying the validity of an IP resource also takes account of at least one previously defined data filtering rule.
• inventions relate to an access control server, a client node, a relay node, and a corresponding validation server.
• the invention relates to one or more computer programs comprising instructions for implementing a method for verifying the validity of an IP resource associated with a client domain according to at least one mode for carrying out the invention, one or more computer programs comprising instructions for implementing a method for declaring an IP resource associated with a client domain according to at least one embodiment of the invention, one or more computer programs comprising instructions for implementing a method for processing at least one request for validation of an IP resource associated with a client domain according to at least one embodiment of the invention , when this or these programs is / are executed by a processor.
• the invention relates to one or more non-removable, or partially or completely removable, information carriers, readable by a computer, and comprising instructions for one or more computer programs for execution steps of the method of verifying the validity of an IP resource associated with a client domain, and / or of the method of declaring an IP resource associated with a client domain and / or of the method of processing at least one request validation of an IP resource associated with a client domain according to at least one embodiment of the invention.
• the methods according to the invention can therefore be implemented in various ways, in particular in wired form and / or in software form.
• FIG. 1 illustrates an example of a communication network implementing a method for verifying the validity of an IP resource associated with a client domain, according to an embodiment of the invention
• FIG. 2 presents the main steps of the method for verifying the validity of an IP resource associated with a client domain, according to at least one embodiment of the invention
• FIGS 3 and 4 illustrate two embodiments of the invention
• FIG. 5 presents the main steps implemented by a DOTS client for the declaration of IP resources associated with a DOTS domain, according to one embodiment;
• Figures 6A and 6B illustrate two examples of declaring IP resources;
• FIG. 7 illustrates a detection of address conflicts between several domains
• Figure 8 illustrates the removal of IP resources that are not part of the list declared by a DOTS client
• FIG. 9 illustrates the refusal of a request for mitigation on an address which is not part of the list declared by a DOTS client
• FIG. 10 illustrates the communications authorized or not between client nodes and relay nodes
• FIGS 11 to 15 show examples of implementation of the verification procedure according to a first embodiment called "DOTS Probing"
• FIG. 16 shows an example of implementation of the verification procedure according to a second embodiment called "Cooperating DOTS / ISPs"
• FIG. 17 shows the simplified structure of an access control server, validation server, client node or relay node according to a particular embodiment.
• the general principle of the invention is based on a declaration to a server, called an access control server, of the IP resources associated with a client domain, and on a verification of the validity of these IP resources, ie, verification that the declared resources are actually associated with the client domain.
• FIG. 1 We present in relation to FIG. 1 various pieces of equipment of a communication network implementing a method of verifying the validity of an IP resource associated with a client domain.
• the client domain 11 comprises one or more machines, also called nodes.
• the client domain includes at least one RI relay node 112.
• domain means a set of machines or nodes placed under the responsibility of the same entity.
• a first access provider 12 has equipment allowing customers to client domain 11 to access the Internet network 13 to which the access control server 14 is connected. According to at least one embodiment, the first access provider 12 comprises at least one validation server VI 121.
• the access control server 14 does not belong to the client domain 11, and can therefore be connected to the Internet network 13 via a second access provider. According to another example not illustrated, the access control server 14 may belong to the client domain, or else to another domain connected to the Internet network 13 through the first access provider 12.
• FIG. 2 illustrates the main steps implemented for the verification of an IP resource associated with a client domain 11.
• a node of the client domain 11 obtains (21 c) a list of at least one IP resource associated with the client domain 11.
• a list includes the IP addresses of the various nodes of the domain client 11, an IP prefix associated with a connection router in the client domain 11, a domain name associated with the client domain 11, etc.
• the client node Cl 111 transmits (22c) this list to a server, for example the access control server 14.
• the client node Cl 111 declares to the access control server 14 the IP resources associated with the client domain 11.
• the source address is therefore the address of the client node, but the IP resources to be validated are those transmitted to the access control server, in the content of the message.
• the declaration of IP resources can be explicit (using a dedicated message) or be implicit (part of a signaling request or filtering request).
• the list of at least one IP resource associated with the client domain is transmitted in a single message.
• a single request say aggregated request, can be sent to the access control server.
• the list of at least one IP resource associated with the client domain is distributed in a plurality of messages. In this case, several separate requests can be sent to the access control server.
• the access control server 14 therefore receives ( $ 23) the list of at least one IP resource associated with the client domain 11, transmitted from a client node of the client domain 11 to the access control server 14.
• the access control server 14 selects ( $ 24) at least one IP resource to validate from the list.
• the access control server 14 transmits ( $ 25) to the client node Cl 111 the or the selected IP resources.
• the client node C1 111 therefore receives (26 c) the IP resource or resources selected by the access control server 14.
• the access control server 14 then checks ( $ 27) the validity of said at least one selected IP resource. In other words, the access control server checks whether the selected IP resource is actually associated with the client domain 11.
• Figures 3 and 4 illustrate two embodiments of the invention.
• the first embodiment makes it possible to dispense with the access provider managing the client domain for the validation of the IP resources associated with this client domain.
• the second embodiment makes it possible to use the equipment of the access provider for the validation of the IP resources associated with a client domain, while preserving the confidentiality of the identity of the client domain.
• FIG. 3 illustrates the main steps of the method for verifying the validity of the IP resource according to the first embodiment.
• the verification ( $ 27) of the validity of the selected IP resource or resources, implemented by the access control server 14, is based on the transmission ( $ 31) of at least one request to said IP resource to be validated, received or intercepted by at least one relay node in the client domain associated with said at least one selected IP resource, for example the relay node RI 112.
• the relay node RI 112 and the client node Cl 111 are the same.
• the relay node RI 112 and the client node Cl 111 are two separate nodes belonging to the same domain.
• the client node and the relay node can be two software instances embedded in the same physical node.
• the selected IP resource can be an IP address.
• the access control server transmits the request to the IP address.
• the selected resource can also be an IP prefix.
• the access control server transmits the request to one or more addresses extracted from this prefix; these requests will typically be intercepted by the client domain connection router (s) to the Internet.
• the selected resource can also be a domain name.
• the access control server can implement a resolution procedure (for example, DNS), to obtain the IP address of the entity managing the associated domain (access provider).
• DNS resolution procedure
• Such a request includes a message or control data.
• a control message can be associated with any information enabling the request to be identified unambiguously.
• this control message should not be trivial to avoid its usurpation.
• such a control message is generated randomly.
• the relay node RI 112 intercepts (32R) therefore at least one request from the access control server 14, and comprising the control message.
• the request can be sent directly to the relay node if the destination address is allocated to the machine where the relay node resides.
• the relay node RI 112 transmits (33R) the request or requests to the client node C1 111, i.e., relays the request or requests coming from the access control server 14.
• the client node Cl 111 receives (34V) therefore at least one request from the access control server, and comprising the message or control data, via at least one relay node of the client domain associated with at least one IP resource. , selected by the access control server from the list.
• the exchanges between the relay node RI 112 and the client node Cl 111 can be implemented via a secure connection.
• the client node Cl 111 directly receives the request from the access control server 14, or the request is relayed internally.
• the client node C1 111 responds by transmitting (35V) to the access control server 14 a response including information characteristic of the message or of the control data.
• the access control server 14 receives (36 $ ) the response including the characteristic information of the control message, coming from the client node Cl 111.
• the characteristic information of the control message can be identical or different from the control message .
• the access control server 14 performs a correlation ( $ 37) of the request and the response, or more particularly of the control data conveyed in the request and of the information characteristic of the control data conveyed in the response, and validate or not the membership of the selected IP resource in the client domain.
• This second embodiment involves a validation server associated with the access provider, for example the validation server VI 121 associated with the first access provider 12 in the client domain 11.
• the verification 27 of the validity of the selected IP resource or resources, implemented by the access control server 14, is based on the reception ( $ 41) of representative information the identity of the client domain.
• information is representative of the identity of the client domain or of the entity which manages the client domain, such as a subscriber to a connectivity service.
• information is a digest, or "hash", of the identity of the client domain 11 or of the entity which manages the client domain.
• the access control server S 14 also implements the identification ( $ 42) of at least one validation server associated with the IP resource or resources selected in step $ 24, for example the validation server VI 121.
• the access control server S 14 transmits ( $ 43) to the validation server (s) identified at least one request comprising, on the one hand, information representative of the identity of the client domain. and on the other hand the selected IP resource (s).
• the request is therefore not sent to a destination address extracted from an IP prefix or from a list of IP addresses to be validated, but to a validation server.
• such a request includes a control message associated with any information allowing the request to be identified unambiguously.
• a control message can be generated randomly.
• the validation server V 121 associated with at least one IP resource selected by the access control server 14 from the list of at least one IP resource associated with the client domain (list previously sent by the client node C1 111 to the server access control S 14), receives (44v) the request or requests comprising, on the one hand, information representative of the identity of the client domain, and, on the other hand, the selected IP resource or resources.
• the validation server V 121 can identify (45v) the client domain.
• the validation server V 121 can check (46v) the association / membership of the selected IP resource or resources with the client domain, taking account of the identity of the client domain.
• the validation server VI 121 can implement the determination (401v) of information representative of the identity of the client domain 11, directly or at the request of a client of the client domain.
• information is representative of the identity of the client domain or of the entity which manages the client domain, and may for example take the form of a digest of the identity of the client domain 11.
• the validation server VI 121 transmits (402v) to the client domain 11, for example to client node Cl 111, the information representative of the identity of the client domain.
• the client node C1 111 receives (403c) therefore the information representative of the identity of the client domain from the validation server attached to the client domain 11, and can transmit it (404c) to the access control server 14, directly or on request from the access control server 14.
• these preliminary steps of determining 401v and of transmitting 402v / receiving 403c of information representative of the identity of the client domain 11 can be implemented during an initialization phase, or when a client domain 11 is connected to a network activating a validation server, or when a mitigation procedure is triggered, etc.
• DOTS DOTS type architecture
• the client node Cl 111 is a DOTS client
• the access control server S 14 is a control server.
• DOTS access allowing the client node C1 111 to inform the access control server S 14 that the client domain is undergoing a DDoS attack and that appropriate actions are required.
• the client node C1 111 and the access control server S 14 can thus communicate via the DOTS signaling and data channels defined in relation to the prior art.
• At least one embodiment of the invention can be implemented to verify the validity of the IP resources associated with a client domain when the DPS mitigation services are not hosted within the infrastructures operated by the provider. access connected to the client domain (ie, if the DOTS access control server is not operated by the access provider connected to the client domain), but in the infrastructures operated by another access provider or in the " cloud ”.
• a DOTS request can be, for example:
• an alias management message for example intended to associate an identifier with one or more network resources located in the client's domain
• a signaling message to request the mitigation of a denial of service attack with a DOTS access control server, the access control server being able, on reception of such a message, to trigger the actions necessary to end the attack, or
• a message to manage filtering rules such as a request from a DOTS access control to install (or have installed) an access control list (ACL).
• ACL access control list
• a DOTS request can be sent from a DOTS client, belonging to a DOTS client domain, to a DOTS access control server or a plurality of DOTS access control servers.
• a DOTS domain can accommodate one or more DOTS clients.
• several client nodes in a client domain can have DOTS functions.
• DOTS communications between a client domain and an access control server can be direct, or established via DOTS gateways (in English "DOTS gateways"). These gateways can be hosted within the client domain, the access control server domain, or both.
• DOTS gateways in English "DOTS gateways"
• a client domain node can communicate directly with the access control server, or transmit a request to a client domain gateway which communicates directly with the access control server or with a domain gateway server, or transmit a request to a gateway in the server domain which communicates with the access control server.
• a DOTS gateway located in a client domain is considered by a DOTS access control server as a DOTS client.
• a DOTS gateway located in a server domain is considered by a DOTS client to be a DOTS access control server. If there is a DOTS gateway in a server domain, authentication of DOTS clients can be entrusted to the DOTS gateway in the server domain.
• a DOTS access control server can be configured with the list of active DOTS gateways within its domain and the access control server can delegate some of its functions to these trusted gateways. In particular, the access control server can safely use the information provided by a gateway appearing in a list declared to the access control server and maintained by it, by means of an ad hoc authentication procedure (for example, explicit configuration of the list by the authorized administrator of the access control server, retrieval of the list from an authentication server such as an AAA server for "Authentication, Authorization and Accounting", etc. ).
• DOTS distributed Denial-of-Service Open Threat Signaling
• DOTS agents clients (s), access control server (s)
• DOTS access control server s
• a secure communication channel for example of the (D) TLS type, between a DOTS client and a DOTS access control server.
• the DOTS client obtains (21 Q ) a list of at least one IP resource associated with the DOTS domain, then transmits it (22c) to one or more DOTS access control server (s), for example using DOTS data or signaling communication channels.
• a DOTS client can therefore declare to the DOTS access control server the IP resources that it manages, or more generally the IP resources that are associated with the domain. DOTS customer.
• An advantage of such an IP resource declaration is that it makes it possible to trigger the verification of the validity of the associated IP resources without waiting for the reception of a DOTS request and therefore without waiting for an attack to be in progress. As a result, signaling messages transmitted from the DOTS client to the DOTS access control server to request mitigation of a denial of service attack can be processed quickly.
• IP resources can be IP addresses, IP prefixes or domain names. Domain names can be resolved to IP addresses.
• IP prefixes denote the IP prefixes directly communicated by a DOTS client or the addresses retrieved via a name resolution system (eg DNS).
• DNS name resolution system
• the prefixes can be from the same address family or belong to different families (IPv4, IPv6). IP prefixes are not necessarily contiguous, nor managed by the same access provider.
• these prefixes can be PA type prefixes (in English “Provider Assigned”), that is to say prefixes owned by the service provider, or PI type prefixes (in English “Provider Independent”) ), that is to say prefixes allocated at the request of a client, for example by an organization of the Regional Internet Registry type, or RIR, independently of the access provider.
• PA type prefixes in English “Provider Assigned”
• PI type prefixes in English “Provider Independent”
• step 51c secure communication channels between the DOTS client and one or more DOTS access control server (s) are established.
• I e DOTS customer gets the list of IP resources it manages, or more generally, the IP resource list associated with his field (client) DOTS .
• I e DOTS customer declares the list of IP resources by transmitting to one or more server (s) DOTS access control.
• I e DOTS client verifies the validity of entries in the list or finding new resources.
• This updating step can be carried out periodically, and / or with each addition, modification, deletion of an IP resource associated with the domain.
• the list is again transmitted to the DOTS access control server according to the transmission step 53c. This transmission can be implemented periodically or as soon as an update of the list is performed.
• the DOTS client When transmitting the list of IP resources to the access control server (s), the DOTS client can indicate the validity period associated with this list, or with certain IP resources from this list, for example in a "Lifetime" field. Such a period of validity is expressed for example in minutes.
• the DOTS access control server can automatically remove the associated IP resource (s) (s) of its active prefix / resource tables for this client / client domain.
• the "Lifetime” field can indicate the value "-1" to indicate an indefinite period of validity.
• separate requests can be sent by the DOTS client to declare to the access control server (s) each of the IP resources associated with the DOTS domain of the DOTS client (a first request to declare the address "1.2.3.4” and a second request to declare the address "11.22.33.44" for example).
• a single request can be sent to declare all the IP resources associated with the DOTS domain of the DOTS client (a single request to declare the address "1.2.3.4” and the address "11.22.33.44" for example).
• IP resources can be carried out by one or more clients.
• declarations are, by default, associated with the domain and not with a DOTS client.
• a DOTS access control server is capable of identifying DOTS clients in the same domain. To do this, the DOTS access control server relies on the security keys used for authentication, such as for example the public key information SPKI (“Subject Public Key Information”) of a certificate associated with the DOTS client (for example the X.509 certificate, as defined in document RFC 5280 entitled “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", D. Cooper et al., May 2008), or the PSK shared key identifiers (“PSK Identity”) used by customers during the authentication procedure (“TLS ClientKeyExchange”).
• SPKI Subject Public Key Information
• X.509 certificate for example the X.509 certificate, as defined in document RFC 5280 entitled "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", D. Cooper et al., May 2008
• PSK Identity PSK shared key identifiers
• the list of IP resources associated with the client domain can be updated regularly and / or each time an IP resource associated with the client domain is added / modified / deleted.
• acquisition operations can give rise to the allocation and use of new IP resources, for example new prefixes which are managed by an active DOTS client.
• the DOTS client can declare such new prefixes. To do this, the DOTS client can for example send a POST message.
• a DOTS client can also update the list of IP resources by removing those that are no longer valid (for example, a prefix that is no longer delegated by the access network, or whose duration of validity has expired).
• the DOTS client can delete the IP resource (s) which are no longer valid without waiting for the expiration of the validity date indicated during the declaration.
• / prefixes / prefix-list my_first_prefix HTTP / l .1
• IP resources associated with a domain have been declared by the DOTS client to a DOTS access control server
• the DOTS access control server can verify that the declared resources are actually associated with the declaring client domain.
• the DOTS access control server can select one or more IP resources to validate from the list (step $ 24 with reference to FIG. 2), then apply a verification procedure to each of the selected IP resources.
• the verification procedure applies to other entries maintained by the access control server (for example, filtering entries, or entries from other clients belonging to the same domain).
• generalizing the verification procedure to the other types of entries maintained by an access control server is advantageous for clients who do not support the procedure for declaring IP resources. It is indeed possible to check the validity of the IP resources managed by a client who is not able to implement the procedure for declaring IP resources, if another client in the domain has previously declared all of the IP resources. associated with this area.
• the DOTS access control server can systematically execute the verification procedure upon receipt of a declaration from a client, or during the period of validity of the filtering or signaling rules, or both;
• the DOTS access control server can implement the verification procedure periodically to ask DOTS clients to confirm the validity of the filtering rules, particularly the destination addresses entered in the filtering rules;
• the access control server can select all or part of the entries to be validated; to do this, the access control server performs a selection procedure, such as random mode, selection of the entries having exceeded a certain lifetime (while remaining theoretically valid by virtue of the value of the "Lifetime" parameter allocated by the access control server when creating the entry), etc .;
• the DOTS access control server can implement the verification procedure on detection of conflict between the destination addresses indicated by clients belonging to separate DOTS domains.
• a DOTS access control server can detect an address conflict between several domains by comparing the destination prefix or prefixes indicated in the DOTS requests. For example, a first client C1, belonging to a first domain 71, indicates the destination address "1.2.3.4/32" in a DOTS request, while this address is covered by the request of a second client C2, belonging to a second domain 72, for the prefix "1.2.3.0/24". As the two clients C1 and C2 do not belong to the same domain, the access control server S can detect a conflict between the destination addresses and not select any destination address as "IP resource to be validated".
• the DOTS access control server implements a verification of the validity of the selected resource (s) (step 27 $ with reference to FIG. 2 ).
• the DOTS access control server can, before or simultaneously with the verification procedure, delete the DOTS entries indicating IP resources which are not part of the list declared by a DOTS client.
• the access control server detects an anomaly in the filtering rules associated with the Cl client and can proceed to delete the corresponding entries from its tables.
• the access control server can send a notification to the client to report on the cleaning operation.
• DOTS requests indicating an IP resource that is not part of the declared IP resources may be rejected by the access control server, before or simultaneously with the verification procedure.
• the access control server can refuse the signaling request because the address indicated as the target of the attack in the request does not appear in the list of IP resources declared by the Cl client or the clients belonging to the same client domain.
• the first embodiment called “DOTS probing”, the main steps of which are illustrated in FIG. 3, makes it possible to dispense with the access provider for the validation of IP resources.
• the second embodiment known as “Cooperating DOTS / ISPs”, the main steps of which are illustrated in FIG. 4, makes it possible to process the data maintained by an access provider without infringing the privacy of the customers.
• the first embodiment (“DOTS probing") is described below in more detail.
• At least one node in the client domain activates a "DOTS_CHECK_RELAY" function allowing the incoming traffic to be inspected and redirected to a client node.
• a node is subsequently called a “relay node”.
• a client domain connected to the Internet via several links can activate the “DOTS_CHECK_RELAY” function on all the nodes connecting it to the Internet.
• a DOTS client can coexist with the "DOTS_CHECK_RELAY” function.
• a client node can activate the "DOTS_CHECK_RELAY” function, for example when the DOTS client is embedded in a network connection router such as a residential gateway ("Customer Premises Equipment").
• the client node is then a relay node.
• the DOTS client is advantageously located on the path of all traffic intended for the client domain.
• a DOTS client has the list of relay nodes activating the "DOTS_CHECK_RELAY" function.
• This relay list can contain one or more relays, and can be declared explicitly to the client (static configuration) or supplied dynamically (for example, using the resources of a DHCP option). However, it is not necessary to communicate such a relay list to the access control server.
• additional information may be filled in, for example, the service listening port number or the list of IP resources managed by a relay node.
• a DOTS client can use this relay for all IP resources associated with the domain.
• the "DOTS_CHECK_RELAY" function can be: a software module dedicated to the DOTS service,
• a traffic capture function activated on a node in the client domain, for example one of the routers connecting the client domain to the Internet.
• the communication between the relays activating the "DOTS_CHECK_RELAY” function and the DOTS clients in the domain can be secured.
• a relay activating the "DOTS_CHECK_RELAY” function can communicate information or receive requests to / duly authorized trusted customers.
• the messages coming from the clients Cl and Cm of the client domain 11 are authorized by the relays RI and Ri, while the messages coming from a usurper client "F_C" are rejected by the relays RI and Ri .
• the “DOTS_CHECK_RELAY” function can be activated on demand. According to this mode, the activation of this function is controlled by at least one DOTS client in the domain. The function is activated for a limited time; it is then deactivated. This mode is preferably used to associate an address or a temporary prefix with the relay activating this function.
• the “DOTS_CHECK_RELAY” function can be activated permanently. According to this mode, the "DOTS_CHECK_RELAY” function can be achieved by reusing the traffic capture functions. This mode is preferably used when the relay node activating the "DOTS_CHECK_RELAY” function is located on a path which makes it possible to route all or part of the traffic intended for the client domain (for example a router for connection to the Internet network, such as a CPE). The use of temporary addresses / prefixes is not necessary for this mode.
• the access control server receives (23 $ ) a list of at least one IP resource associated with the client domain, and selects (24 $ ), from the list, one or more IP resources to be validated. It is noted that the content of this list can vary over time, since the list can be updated (step 54c of FIG. 5).
• the latter upon identification of a DOTS entry to be validated by the access control server, the latter extracts associated destination prefixes.
• the access control server communicates the list of IP resources (or the associated prefixes / IP addresses) thus selected to the client (step 25 $ in FIG. 2).
• a list can be communicated to the client in the case of the deployment of a module.
• software dedicated to the DOTS service which exploits, for example, virtualization techniques to dynamically instantiate service functions (“on demand” mode above).
• these service functions can be configured to intercept traffic intended for at least one of the addresses communicated by the DOTS access control server.
• the client can configure the "DOTS_CHECK_RELAY" function (s) in accordance with the instructions of the access control server.
• the client can inform the access control server that the client domain is ready to process IP resource validation messages.
• the access control server can implement verification ( $ 27) of the validity of the selected IP resource (s), or addresses / prefixes associates.
• the access control server sends requests having as destination address said address to be validated (ie, an address extracted from a selected IP resource), and intercepted by the identified relay node (s) (step $ 31 in Figure 3).
• validation messages "DOTS_PROBE_REQUEST" are transmitted to each of the addresses in the list of selected IP resources.
• the access control server can send validation messages "DOTS_PROBE_REQUEST" as soon as the IP resources to be validated are selected, or after a certain delay, or upon receipt of a message from the client, for example a message confirmation of receipt when the access control server communicates the list of selected IP resources to the client ( $ 25).
• the sending of such messages to the nodes identified by the selected IP resource or resources can be carried out successively or simultaneously.
• validation messages include a control message associated with any information making it possible to identify the validation message unambiguously.
• the DOTS access control server generates "DOTS_PROBE_REQUEST" messages with random payloads to prevent suspicious clients from easily guessing messages and sending spoofed responses.
• the access control server can:
• identifiers such as identifiers of type UUID - Universally Unique Identifier - version 4 (as described in document RFC 4122 “A Universally Unique IDentifier (UUID) URN Namespace” P. Leach, July 2005), randomly generated:
• digests SHA-256 calculate one or more digests that it inserts in the message "DOTS_PROBE_REQUEST", such as digests SHA-256:
• a random file for example an image
• the generation of a validation message "DOTS_PROBE_REQUEST" by the DOTS access control server includes:
• the definition of the destination address (address of the relay node identified by the selected IP resource);
• the same message can be transmitted several times, in particular in the case where one of the messages was destroyed during its routing towards its destination.
• the access control server receives an error message (via the ICMP protocol, for example);
• the access control server can conclude that the address associated with the DOTS_PROBE_REQUEST message is not legitimately associated with the DOTS client.
• the access control server can thus invalidate the corresponding entries in its tables.
• Other actions can be taken, for example, blocking the DOTS client who indicated this address / prefix.
• At least one domain relay can intercept the DOTS_PROBE_REQUEST message (s) (step 32R of FIG. 3). These messages can be explicitly intended for the relay (on-demand mode) or for relays with a domain address. In both cases, these messages must be relayed (33R) to the DOTS client. Preferably, the content of the DOTS_PROBE_REQUEST message is not modified by the relay.
• the DOTS client Upon receipt (34V) of the DOTS_PROBE_REQUEST message by the client, the DOTS client sends (35c) a DOTS_PROBE_REPLY response to the access control server.
• the content of the message is not modified by the client.
• the response includes information characteristic of the control message.
• the access control server On reception (36 $ ) of the DOTS_PROBE_ REPLY message by the access control server, the access control server correlates (37 $ ) the response (DOTS_PROBE_REPLY) with the request (DOTS_PROBE_REQUEST) to verify the authenticity and message integrity.
• the associated IP resource is validated.
• processing of a "DOTS_PROBE_REPLY" response message by the DOTS access control server includes:
• checking the integrity of the message content if the message content is not correlated with the control message, the corresponding IP resource is discarded; checking the content of the tables: if the IP resource does not correspond to any of the entries in the table maintained by the access control server, then this corresponding IP resource is discarded; validation of the corresponding IP resource.
• FIGS. 11 to 15 show examples of implementation of the verification procedure according to this first embodiment ("DOTS Probing").
• Figure 11 illustrates an example of successful validation of all IP resources associated with a DOTS client. It is assumed in this example that the access control server 14 informs the client of the list of addresses selected to be validated ( $ 25), for example the addresses PI to Pi. It will be recalled that this step is optional. On reception (26V) of this list, the DOTS client proceeds to the configuration ("Setup") of the relays necessary so that they are ready to receive validation messages DOTS_PROBE_REQUEST. A "ACK" confirmation message can be sent by the DOTS client to the access control server to indicate that the client domain is ready. Then, the access control server can send (31s) DOTS_PROBE_REQUEST validation messages to the relay (s) for each of the addresses to be validated.
• Setup the configuration
• a "ACK" confirmation message can be sent by the DOTS client to the access control server to indicate that the client domain is ready.
• the access control server can send (31s) DOTS_PROBE_REQUEST validation messages to the relay (s) for each of the
• Figure 12 illustrates another example of successful validation of all IP resources associated with a DOTS client.
• the DOTS_PROBE_REQUEST validation messages are transmitted ( $ 31) to the same relay and without prior notification to the client.
• the state of the addresses PI to Pi is also "validated".
• Figure 13 illustrates an example of partial address validation success. Only the PI address is validated while the Pi address is not. The state of the PI address is therefore "validated” while the state of the address at Pi is "not validated”.
• the access control server concludes that this IP resource is not associated with this DOTS client domain. It thus proceeds to the deletion of said address in its tables.
• FIG. 14 illustrates an example of address validation failure, in the case where the access control server does not receive responses to the DOTS_PROBE_REQUEST messages. The state of the PI and Pi addresses is therefore "not validated".
• Figure 15 illustrates another example where a client generates DOTS_PROBE_REPLY response messages to simulate that relays in their domain have actually received DOTS_PROBE_REQUEST validation messages. These DOTS_PROBE_REPLY messages are not validated by the access control server, because the payloads of the DOTS_PROBE_REQUEST and DOTS_PROBE_REPLY messages are not correlated.
• This second embodiment consists in requesting the access providers to verify that an address or a prefix declared by a DOTS client is actually allocated by this provider to this client.
• This mode assumes that access providers expose a programming interface (API) to offer third-party value-added services such as the validation of IP resources. Also, and in order to preserve the confidentiality of customer data, certain information is not disclosed to these third parties, or only on the express agreement of customers. In addition, and in order to avoid data theft, customer information is not passed on to third parties.
• API programming interface
• the steps of reception (23 $ ), by the access control server, of a list of at least one IP resource associated with the client domain, of selection (24 $ ) of at least one IP resource to be validated among the list, and optionally of transmission (25 $ ) of the IP resource (s) selected to validate to DOTS clients, are also implemented according to this second embodiment, and are similar to those implemented according to the first embodiment .
• the verification step ( $ 27) of the validity of the selected IP resource (s) involves one or more validation servers.
• the access control server receives ( $ 41), according to this second embodiment, information representative of the identity of the client domain or of the entity which manages the client domain.
• the DOTS access control server retrieves the identity of the supplier (s) owning the IP resource. Such information may indeed be publicly available. To do this, the access control server interrogates, for example, the base of European IP Networks (RIPE).
• RIPE European IP Networks
• An example of a request using the resources of the RIPE database to retrieve the identity of the client domain or of the entity that manages the IP resource "80.12.102.157" of the client domain is given below:
• this second embodiment assumes that the access providers expose a programming interface (API) for the validation of IP resources, for example in one or more validation servers hosted by these access providers.
• API programming interface
• the addresses of the validation servers are also accessible / available to the customers of these access providers.
• the response to this request indicates that the IP resource "80.12.102.157” is allocated, according to this example, to the access provider "Orange SA", and that the validation server (s) for this IP resource are located by the addresses "80.12.102.15” and "80.12.102.16".
• the DOTS access control server communicates ( $ 25) to the DOTS client, optionally, the selected IP resource, or the list of selected IP resources.
• the server of DOTS access control also identifies (42 $ ) the owner of the resource and at least one associated validation server.
• the validation server determines (401v) a unique digest of the identity of the client domain. A period of validity can be assigned to the digest.
• the validation server can generate a digest corresponding to the entity which manages the client domain whose identifier is “45979230632” with a time stamp “2018-02- 08T00: 00: 11Z” according to the nomenclature “subscriber_45979230632_timestamp_2018-02 - 08T00: 00: 11Z ":
• the DOTS client can obtain (403V) the digest if it is a client of the access provider hosting the validation server.
• the IP resource is not validated.
• This / these digest (s) are then transmitted (404c) to the DOTS access control server by the client.
• the DOTS access control server On receipt ( $ 41) of the digest, the DOTS access control server sends ( $ 43) validation messages DOTS_PROBE_REQUEST to the validation servers RI, ..., Ri. These messages include the digest previously communicated by the client, as well as the IP resource to be validated. In the absence of a digest, the access control server cannot identify the client concerned, and the IP resource is not validated.
• a validation server Ri On receipt (44v) of a validation message by a validation server Ri, the latter checks whether the IP resource to be validated (address / prefix) is actually allocated to the client identified by said digest.
• a confirmation message (DOTS_PROBE_REPLY) or an error message can be transmitted to the access control server.
• Figure 16 illustrates an example of successful validation of all IP resources associated with a DOTS client. It is assumed in this example that the access control server 14 informs the client of the list of addresses selected to be validated ( $ 25), for example the addresses RI to Ri. Remember that this step is optional. On receipt of this list, the DOTS client interrogates the validation servers VI of a first access provider 12 and Vi of an i-th access provider 16, associated with the IP resources RI, ..., Ri to validate, to obtain (403c) information representative of the identity of the client domain, and then transmits (404V) this information to the access control server.
• the access control server can send ( $ 43) DOTS_PROBE_REQUEST validation messages to the validation server (s), carrying the IP resource to be validated and the information representative of the identity of the client domain.
• the validation server (s) verify that the IP resource carried by the DOTS_PROBE_REQUEST validation message is effectively associated with the domain identified by the information representative of the identity of the client domain. If this is the case, the state of the addresses RI to Ri is therefore "validated".
• the validation server (s) send a DOTS_PROBE_REPLY response to the DOTS access control server.
• an access control server comprises a memory $ 171 comprising a buffer memory, a processing unit $ 172, equipped for example with a programmable calculation machine or a dedicated calculation machine, for example a processor P, and controlled by the computer program 173 $ , implementing steps of the method for verifying the validity of an IP resource according to an embodiment of the invention.
• the code instructions of the computer program 173 $ are for example loaded into a RAM memory before being executed by the processor of the processing unit 172 $ .
• the processor of the processing unit 172 $ implements steps of the method for verifying the validity of an IP resource described above, according to the instructions of the computer program 173 $ , for: receiving a list of at least one IP resource associated with a client domain, transmitted from a client node of the client domain to the access control server;
• a client node comprises a memory 171V comprising a buffer memory, a processing unit 172c, equipped for example with a programmable calculation machine or with a dedicated calculation machine, for example a processor P, and controlled by the computer program 173c, implementing steps of the method for declaring an IP resource according to an embodiment of the invention.
• the computer 173c program code instructions are F or example loaded into a RAM before being executed by the processor of the processing unit 172c-
• the processor of the processing unit 172c implements steps of the reporting process of an IP resource described above, according to the instructions of the computer program 173c, T o:
• a relay node comprises a memory 171R comprising a buffer memory, a processing unit 172R, equipped for example with a programmable calculation machine or with a dedicated calculation machine, for example a processor P, and controlled by the computer program 173R, implementing steps of the method for processing a request for validation of an IP resource according to an embodiment of the invention.
• the code instructions of the computer program 173R are for example loaded into a RAM memory before being executed by the processor of the processing unit 172R.
• the processor of the processing unit 172R implements steps of the method for processing a request for validation of an IP resource described above, according to the instructions of the computer program 173R, for:
• the relay node being associated with at least one IP resource selected by the access control server from a list of at least one IP resource associated with the client domain, the list being previously transmitted from a client node of the client domain to the server access control.
• such a relay node can activate the “DOTS_CHECK_RELAY” function defined above.
• a validation server comprises a memory 171v comprising a buffer memory, a processing unit 172v, equipped for example with a programmable calculation machine or with a dedicated calculation machine, for example a processor P , and controlled by the computer program 173v, implementing steps of the method for verifying the validity of an IP resource according to an embodiment of the invention.
• the code instructions of the computer program 173v are for example loaded into a RAM memory before being executed by the processor of the processing unit 172v-
• the processor of the processing unit 172v implements steps of the method for verifying the validity of an IP resource described above, according to the instructions of the computer program 173v, for:

Landscapes

• Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Computer Hardware Design (AREA)
• Computing Systems (AREA)
• General Engineering & Computer Science (AREA)
• Business, Economics & Management (AREA)
• General Business, Economics & Management (AREA)
• Data Exchanges In Wide-Area Networks (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=63722563

Family Applications (1)

Country Status (5)

Families Citing this family (1)

Family Cites Families (11)

• 2018
  • 2018-06-29 FR FR1856015A patent/FR3081573A1/fr not_active Withdrawn
• 2019
  • 2019-06-28 US US17/256,386 patent/US20210273974A1/en active Pending
  • 2019-06-28 EP EP19750134.9A patent/EP3815335A1/de active Pending
  • 2019-06-28 CN CN201980051584.6A patent/CN112514350B/zh active Active
  • 2019-06-28 WO PCT/FR2019/051609 patent/WO2020002856A1/fr active Application Filing

Also Published As

Similar Documents

Legal Events