RFC4218 日本語訳
4218 Threats Relating to IPv6 Multihoming Solutions. E. Nordmark, T.Li. October 2005. (Format: TXT=75969 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Nordmark
Request for Comments: 4218 Sun Microsystems
Category: Informational T. Li
October 2005
Network Working Group E. Nordmark Request for Comments: 4218 Sun Microsystems Category: Informational T. Li October 2005
Threats Relating to IPv6 Multihoming Solutions
Threats Relating to IPv6 Multihoming Solutions
Status of This Memo
Status of This Memo
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (2005).
Copyright (C) The Internet Society (2005).
Abstract
Abstract
This document lists security threats related to IPv6 multihoming. Multihoming can introduce new opportunities to redirect packets to different, unintended IP addresses.
This document lists security threats related to IPv6 multihoming. Multihoming can introduce new opportunities to redirect packets to different, unintended IP addresses.
The intent is to look at how IPv6 multihoming solutions might make the Internet less secure; we examine threats that are inherent to all IPv6 multihoming solutions rather than study any specific proposed solution. The threats in this document build upon the threats discovered and discussed as part of the Mobile IPv6 work.
The intent is to look at how IPv6 multihoming solutions might make the Internet less secure; we examine threats that are inherent to all IPv6 multihoming solutions rather than study any specific proposed solution. The threats in this document build upon the threats discovered and discussed as part of the Mobile IPv6 work.
Table of Contents
Table of Contents
1. Introduction ....................................................2
1.1. Assumptions ................................................3
1.2. Authentication, Authorization, and Identifier Ownership ....4
2. Terminology .....................................................5
3. Today's Assumptions and Attacks .................................6
3.1. Application Assumptions ....................................6
3.2. Redirection Attacks Today ..................................8
3.3. Packet Injection Attacks Today .............................9
3.4. Flooding Attacks Today ....................................10
3.5. Address Privacy Today .....................................11
4. Potential New Attacks ..........................................13
4.1. Cause Packets to Be Sent to the Attacker ..................13
4.1.1. Once Packets Are Flowing ...........................13
4.1.2. Time-Shifting Attack ...............................14
4.1.3. Premeditated Redirection ...........................14
4.1.4. Using Replay Attacks ...............................15
1. Introduction ....................................................2 1.1. Assumptions ................................................3 1.2. Authentication, Authorization, and Identifier Ownership ....4 2. Terminology .....................................................5 3. Today's Assumptions and Attacks .................................6 3.1. Application Assumptions ....................................6 3.2. Redirection Attacks Today ..................................8 3.3. Packet Injection Attacks Today .............................9 3.4. Flooding Attacks Today ....................................10 3.5. Address Privacy Today .....................................11 4. Potential New Attacks ..........................................13 4.1. Cause Packets to Be Sent to the Attacker ..................13 4.1.1. Once Packets Are Flowing ...........................13 4.1.2. Time-Shifting Attack ...............................14 4.1.3. Premeditated Redirection ...........................14 4.1.4. Using Replay Attacks ...............................15
Nordmark & Li Informational [Page 1] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
Nordmark & Li Informational [Page 1] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
4.2. Cause Packets to Be Sent to a Black Hole ..................15
4.3. Third Party Denial-of-Service Attacks .....................16
4.3.1. Basic Third Party DoS ..............................17
4.3.2. Third Party DoS with On-Path Help ..................18
4.4. Accepting Packets from Unknown Locators ...................19
4.5. New Privacy Considerations ................................20
5. Granularity of Redirection .....................................20
6. Movement Implications? .........................................22
7. Other Security Concerns ........................................23
8. Security Considerations ........................................24
9. Acknowledgements ...............................................24
10. Informative References ........................................25
Appendix A: Some Security Analysis ................................27
4.2. Cause Packets to Be Sent to a Black Hole ..................15 4.3. Third Party Denial-of-Service Attacks .....................16 4.3.1. Basic Third Party DoS ..............................17 4.3.2. Third Party DoS with On-Path Help ..................18 4.4. Accepting Packets from Unknown Locators ...................19 4.5. New Privacy Considerations ................................20 5. Granularity of Redirection .....................................20 6. Movement Implications? .........................................22 7. Other Security Concerns ........................................23 8. Security Considerations ........................................24 9. Acknowledgements ...............................................24 10. Informative References ........................................25 Appendix A: Some Security Analysis ................................27
1. Introduction
1. Introduction
The goal of the IPv6 multihoming work is to allow a site to take advantage of multiple attachments to the global Internet, without having a specific entry for the site visible in the global routing table. Specifically, a solution should allow hosts to use multiple attachments in parallel, or to switch between these attachment points dynamically in the case of failures, without an impact on the transport and application layer protocols.
The goal of the IPv6 multihoming work is to allow a site to take advantage of multiple attachments to the global Internet, without having a specific entry for the site visible in the global routing table. Specifically, a solution should allow hosts to use multiple attachments in parallel, or to switch between these attachment points dynamically in the case of failures, without an impact on the transport and application layer protocols.
At the highest level, the concerns about allowing such "rehoming" of packet flows can be called "redirection attacks"; the ability to cause packets to be sent to a place that isn't tied to the transport and/or application layer protocol's notion of the peer. These attacks pose threats against confidentiality, integrity, and availability. That is, an attacker might learn the contents of a particular flow by redirecting it to a location where the attacker has a packet recorder. If, instead of a recorder, the attacker changes the packets and then forwards them to the ultimate destination, the integrity of the data stream would be compromised. Finally, the attacker can simply use the redirection of a flow as a denial of service attack.
At the highest level, the concerns about allowing such "rehoming" of packet flows can be called "redirection attacks"; the ability to cause packets to be sent to a place that isn't tied to the transport and/or application layer protocol's notion of the peer. These attacks pose threats against confidentiality, integrity, and availability. That is, an attacker might learn the contents of a particular flow by redirecting it to a location where the attacker has a packet recorder. If, instead of a recorder, the attacker changes the packets and then forwards them to the ultimate destination, the integrity of the data stream would be compromised. Finally, the attacker can simply use the redirection of a flow as a denial of service attack.
This document has been developed while considering multihoming solutions architected around a separation of network identity and network location, whether or not this separation implies the introduction of a new and separate identifier name space. However, this separation is not a requirement for all threats, so this taxonomy may also apply to other approaches. This document is not intended to examine any single proposed solution. Rather, it is intended as an aid to discussion and evaluation of proposed solutions. By cataloging known threats, we can help to ensure that all proposals deal with all of the available threats.
This document has been developed while considering multihoming solutions architected around a separation of network identity and network location, whether or not this separation implies the introduction of a new and separate identifier name space. However, this separation is not a requirement for all threats, so this taxonomy may also apply to other approaches. This document is not intended to examine any single proposed solution. Rather, it is intended as an aid to discussion and evaluation of proposed solutions. By cataloging known threats, we can help to ensure that all proposals deal with all of the available threats.
Nordmark & Li Informational [Page 2] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
Nordmark & Li Informational [Page 2] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
As a result of not analyzing a particular solution, this document is inherently incomplete. An actual solution would need to be analyzed as part of its own threat analysis, especially in the following areas:
As a result of not analyzing a particular solution, this document is inherently incomplete. An actual solution would need to be analyzed as part of its own threat analysis, especially in the following areas:
1) If the solution makes the split between locators and identifiers,
then most application security mechanisms should be tied to the
identifier, not to the locator. Therefore, work would be needed
to understand how attacks on the identifier mechanism affect
security, especially attacks on the mechanism that would bind
locators to identifiers.
1) If the solution makes the split between locators and identifiers, then most application security mechanisms should be tied to the identifier, not to the locator. Therefore, work would be needed to understand how attacks on the identifier mechanism affect security, especially attacks on the mechanism that would bind locators to identifiers.
2) How does the solution apply multihoming to IP multicast?
Depending on how this is done, there might be specific threats
relating to multicast that need to be understood. This document
does not discuss any multicast-specific threats.
2) How does the solution apply multihoming to IP multicast? Depending on how this is done, there might be specific threats relating to multicast that need to be understood. This document does not discuss any multicast-specific threats.
3) Connection-less transport protocols probably need more attention.
They are already difficult to secure, even without a
locator/identifier split.
3) Connection-less transport protocols probably need more attention. They are already difficult to secure, even without a locator/identifier split.
1.1. Assumptions
1.1. Assumptions
This threat analysis doesn't assume that security has been applied to other security relevant parts of the Internet, such as DNS and routing protocols; but it does assume that, at some point in time, at least parts of the Internet will be operating with security for such key infrastructure. With that assumption, it then becomes important that a multihoming solution would not, at that point in time, become the weakest link. This is the case even if, for instance, insecure DNS might be the weakest link today.
This threat analysis doesn't assume that security has been applied to other security relevant parts of the Internet, such as DNS and routing protocols; but it does assume that, at some point in time, at least parts of the Internet will be operating with security for such key infrastructure. With that assumption, it then becomes important that a multihoming solution would not, at that point in time, become the weakest link. This is the case even if, for instance, insecure DNS might be the weakest link today.
This document doesn't assume that the application protocols are protected by strong security today or in the future. However, it is still useful to assume that the application protocols that care about integrity and/or confidentiality apply the relevant end-to-end security measures, such as IPsec, TLS, and/or application layer security.
This document doesn't assume that the application protocols are protected by strong security today or in the future. However, it is still useful to assume that the application protocols that care about integrity and/or confidentiality apply the relevant end-to-end security measures, such as IPsec, TLS, and/or application layer security.
For simplicity, this document assumes that an on-path attacker can see packets, modify packets and send them out, and block packets from being delivered. This is a simplification because there might exist ways (for instance, monitoring capability in switches) that allow authenticated and authorized users to observe packets without being able to send or block the packets.
For simplicity, this document assumes that an on-path attacker can see packets, modify packets and send them out, and block packets from being delivered. This is a simplification because there might exist ways (for instance, monitoring capability in switches) that allow authenticated and authorized users to observe packets without being able to send or block the packets.
Nordmark & Li Informational [Page 3] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
Nordmark & Li Informational [Page 3] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
In some cases it might make sense to make a distinction between on-path attackers, which can monitor packets and perhaps also inject packets, without being able to block packets from passing through.
In some cases it might make sense to make a distinction between on-path attackers, which can monitor packets and perhaps also inject packets, without being able to block packets from passing through.
On-path attackers that only need to monitor might be lucky and find a non-switched Ethernet in the path, or use capacitive or inductive coupling to listen on a copper wire. But if the attacker is on an Ethernet that is on the path, whether switched or not, the attacker can also employ Address Resolution Protocol/Neighbor Discovery (ARP/ND) spoofing to get access to the packet flow which allows blocking as well. Similarly, if the attacker has access to the wire, the attacker can also place a device on the wire to block. Other on-path attacks would be those that gain control of a router or a switch (or gain control of one of the endpoints), and most likely those would allow blocking as well.
On-path attackers that only need to monitor might be lucky and find a non-switched Ethernet in the path, or use capacitive or inductive coupling to listen on a copper wire. But if the attacker is on an Ethernet that is on the path, whether switched or not, the attacker can also employ Address Resolution Protocol/Neighbor Discovery (ARP/ND) spoofing to get access to the packet flow which allows blocking as well. Similarly, if the attacker has access to the wire, the attacker can also place a device on the wire to block. Other on-path attacks would be those that gain control of a router or a switch (or gain control of one of the endpoints), and most likely those would allow blocking as well.
So the strongest currently known case where monitoring is easier than blocking, is when switches and routers have monitoring capabilities (for network management or for lawful intercept) where an attacker might be able to bypass the authentication and authorization checks for those capabilities. However, this document makes the simplifying assumption treat all on-path attackers the same by assuming that such an attacker can monitor, inject, and block packets. A security analysis of a particular proposal can benefit from not making this assumption, and look at how on-path attackers with different capabilities can generate different attacks perhaps not present in today's Internet.
So the strongest currently known case where monitoring is easier than blocking, is when switches and routers have monitoring capabilities (for network management or for lawful intercept) where an attacker might be able to bypass the authentication and authorization checks for those capabilities. However, this document makes the simplifying assumption treat all on-path attackers the same by assuming that such an attacker can monitor, inject, and block packets. A security analysis of a particular proposal can benefit from not making this assumption, and look at how on-path attackers with different capabilities can generate different attacks perhaps not present in today's Internet.
The document assumes that an off-path attacker can neither see packets between the peers (for which it is not on the path) nor block them from being delivered. Off-path attackers can, in general, send packets with arbitrary IP source addresses and content, but such packets might be blocked if ingress filtering [INGRESS] is applied. Thus, it is important to look at the multihoming impact on security both in the presence and absence of ingress filtering.
The document assumes that an off-path attacker can neither see packets between the peers (for which it is not on the path) nor block them from being delivered. Off-path attackers can, in general, send packets with arbitrary IP source addresses and content, but such packets might be blocked if ingress filtering [INGRESS] is applied. Thus, it is important to look at the multihoming impact on security both in the presence and absence of ingress filtering.
1.2. Authentication, Authorization, and Identifier Ownership
1.2. Authentication, Authorization, and Identifier Ownership
The overall problem domain can be described using different terminology.
The overall problem domain can be described using different terminology.
One way to describe it is that it is necessary to first authenticate the peer and then verify that the peer is authorized to control the locators used for a particular identifier. While this is correct, it might place too much emphasis on the authorization aspect. In this case, the authorization is conceptually very simple; each host (each identifier) is authorized to control which locators are used for itself.
One way to describe it is that it is necessary to first authenticate the peer and then verify that the peer is authorized to control the locators used for a particular identifier. While this is correct, it might place too much emphasis on the authorization aspect. In this case, the authorization is conceptually very simple; each host (each identifier) is authorized to control which locators are used for itself.
Nordmark & Li Informational [Page 4] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
Nordmark & Li Informational [Page 4] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
Hence, there is a different way to describe the same thing. If the peer can somehow prove that it is the owner of the identifier, and the communication is bound to the identifier (and not the locator), then the peer is allowed to control the locators that are used with the identifier. This way to describe the problem is used in [OWNER].
Hence, there is a different way to describe the same thing. If the peer can somehow prove that it is the owner of the identifier, and the communication is bound to the identifier (and not the locator), then the peer is allowed to control the locators that are used with the identifier. This way to describe the problem is used in [OWNER].
Both ways to look at the problem, hence both sets of terminology, are useful when trying to understand the problem space and the threats.
Both ways to look at the problem, hence both sets of terminology, are useful when trying to understand the problem space and the threats.
2. Terminology
2. Terminology
link - a communication facility or medium over which nodes
can communicate at the link layer, i.e., the layer
immediately below IPv6. Examples are Ethernets
(simple or bridged); PPP links; X.25, Frame Relay,
or ATM networks; and Internet (or higher) layer
"tunnels", such as tunnels over IPv4 or IPv6 itself.
link - a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IPv6. Examples are Ethernets (simple or bridged); PPP links; X.25, Frame Relay, or ATM networks; and Internet (or higher) layer "tunnels", such as tunnels over IPv4 or IPv6 itself.
interface - a node's attachment to a link.
interface - a node's attachment to a link.
address - an IP layer name that has both topological
significance (i.e., a locator) and identifies an
interface. There may be multiple addresses per
interface. Normally an address uniquely identifies
an interface, but there are exceptions: the same
unicast address can be assigned to multiple
interfaces on the same node, and an anycast address
can be assigned to different interfaces on different
nodes.
address - an IP layer name that has both topological significance (i.e., a locator) and identifies an interface. There may be multiple addresses per interface. Normally an address uniquely identifies an interface, but there are exceptions: the same unicast address can be assigned to multiple interfaces on the same node, and an anycast address can be assigned to different interfaces on different nodes.
locator - an IP layer topological name for an interface or a
set of interfaces. There may be multiple locators
per interface.
locator - an IP layer topological name for an interface or a set of interfaces. There may be multiple locators per interface.
identifier - an IP layer identifier for an IP layer endpoint
(stack name in [NSRG]), that is, something that
might be commonly referred to as a "host". The
transport endpoint name is a function of the
transport protocol and would typically include the
IP identifier plus a port number. There might be
use for having multiple identifiers per stack/per
host.
identifier - an IP layer identifier for an IP layer endpoint (stack name in [NSRG]), that is, something that might be commonly referred to as a "host". The transport endpoint name is a function of the transport protocol and would typically include the IP identifier plus a port number. There might be use for having multiple identifiers per stack/per host.
An identifier continues to function regardless of
the state of any one interface.
An identifier continues to function regardless of the state of any one interface.
Nordmark & Li Informational [Page 5] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
Nordmark & Li Informational [Page 5] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
address field
- the source and destination address fields in the
IPv6 header. As IPv6 is currently specified, these
fields carry "addresses". If identifiers and
locators are separated, these fields will contain
locators.
address field - the source and destination address fields in the IPv6 header. As IPv6 is currently specified, these fields carry "addresses". If identifiers and locators are separated, these fields will contain locators.
FQDN - Fully Qualified Domain Name [FYI18]
FQDN - Fully Qualified Domain Name [FYI18]
3. Today's Assumptions and Attacks
3. Today's Assumptions and Attacks
The two interesting aspects of security for multihoming solutions are (1) the assumptions made by the transport layer and application layer protocols about the identifiers that they see, and (2) the existing abilities to perform various attacks that are related to the identity/location relationship.
The two interesting aspects of security for multihoming solutions are (1) the assumptions made by the transport layer and application layer protocols about the identifiers that they see, and (2) the existing abilities to perform various attacks that are related to the identity/location relationship.
3.1. Application Assumptions
3.1. Application Assumptions
In the Internet today, the initiating part of applications either starts with a FQDN, which it looks up in the DNS, or already has an IP address from somewhere. For the FQDN to perform IP address lookup, the application effectively places trust in the DNS. Once it has the IP address, the application places trust in the routing system delivering packets to that address. Applications that use security mechanisms, such as IPSEC or TLS, have the ability to bind an address or FQDN to cryptographic keying material. Compromising the DNS and/or routing system can result in packets being dropped or delivered to an attacker in such cases, but since the attacker does not possess the keying material, the application will not trust the attacker, and the attacker cannot decrypt what it receives.
In the Internet today, the initiating part of applications either starts with a FQDN, which it looks up in the DNS, or already has an IP address from somewhere. For the FQDN to perform IP address lookup, the application effectively places trust in the DNS. Once it has the IP address, the application places trust in the routing system delivering packets to that address. Applications that use security mechanisms, such as IPSEC or TLS, have the ability to bind an address or FQDN to cryptographic keying material. Compromising the DNS and/or routing system can result in packets being dropped or delivered to an attacker in such cases, but since the attacker does not possess the keying material, the application will not trust the attacker, and the attacker cannot decrypt what it receives.
At the responding (non-initiating) end of communication today, we find that the security configurations used by different applications fall into approximately five classes, where a single application might use different classes of configurations for different types of communication.
At the responding (non-initiating) end of communication today, we find that the security configurations used by different applications fall into approximately five classes, where a single application might use different classes of configurations for different types of communication.
The first class is the set of public content servers. These systems provide data to any and all systems and are not particularly concerned with confidentiality, as they make their content available to all. However, they are interested in data integrity and denial of service attacks. Having someone manipulate the results of a search engine, for example, or prevent certain systems from reaching a search engine would be a serious security issue.
The first class is the set of public content servers. These systems provide data to any and all systems and are not particularly concerned with confidentiality, as they make their content available to all. However, they are interested in data integrity and denial of service attacks. Having someone manipulate the results of a search engine, for example, or prevent certain systems from reaching a search engine would be a serious security issue.
Nordmark & Li Informational [Page 6] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
Nordmark & Li Informational [Page 6] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
The second class of security configurations uses existing IP source addresses from outside of their immediate local site as a means of authentication without any form of verification. Today, with source IP address spoofing and TCP sequence number guessing as rampant attacks [RFC1948], such applications are effectively opening themselves for public connectivity and are reliant on other systems, such as firewalls, for overall security. We do not consider this class of configurations in this document because they are in any case fully open to all forms of network layer spoofing.
The second class of security configurations uses existing IP source addresses from outside of their immediate local site as a means of authentication without any form of verification. Today, with source IP address spoofing and TCP sequence number guessing as rampant attacks [RFC1948], such applications are effectively opening themselves for public connectivity and are reliant on other systems, such as firewalls, for overall security. We do not consider this class of configurations in this document because they are in any case fully open to all forms of network layer spoofing.
The third class of security configurations receives existing IP source addresses, but attempt some verification using the DNS, effectively using the FQDN for access control. (This is typically done by performing a reverse lookup from the IP address, followed by a forward lookup and verifying that the IP address matches one of the addresses returned from the forward lookup.) These applications are already subject to a number of attacks using techniques like source address spoofing and TCP sequence number guessing since an attacker, knowing this is the case, can simply create a DoS attack using a forged source address that has authentic DNS records. In general this class of security configurations is strongly discouraged, but it is probably important that a multihoming solution doesn't introduce any new and easier ways to perform such attacks. However, we note that some people think we should treat this class the same as the second class of security configurations.
The third class of security configurations receives existing IP source addresses, but attempt some verification using the DNS, effectively using the FQDN for access control. (This is typically done by performing a reverse lookup from the IP address, followed by a forward lookup and verifying that the IP address matches one of the addresses returned from the forward lookup.) These applications are already subject to a number of attacks using techniques like source address spoofing and TCP sequence number guessing since an attacker, knowing this is the case, can simply create a DoS attack using a forged source address that has authentic DNS records. In general this class of security configurations is strongly discouraged, but it is probably important that a multihoming solution doesn't introduce any new and easier ways to perform such attacks. However, we note that some people think we should treat this class the same as the second class of security configurations.
The fourth class of security configurations uses cryptographic security techniques to provide both a strong identity for the peer and data integrity with or without confidentiality. Such systems are still potentially vulnerable to denial of service attacks that could be introduced by a multihoming solution.
The fourth class of security configurations uses cryptographic security techniques to provide both a strong identity for the peer and data integrity with or without confidentiality. Such systems are still potentially vulnerable to denial of service attacks that could be introduced by a multihoming solution.
Finally, the fifth class of security configurations uses cryptographic security techniques, but without strong identity (such as opportunistic IPsec). Thus, data integrity with or without confidentiality is provided when communicating with an unknown/unauthenticated principal. Just like the first category above, such applications can't perform access control based on network layer information since they do not know the identity of the peer. However, they might perform access control using higher-level notions of identity. The availability of IPsec (and similar solutions) together with channel bindings allows protocols (which, in themselves, are vulnerable to man-in-the-middle (MITM) attacks) to operate with a high level of confidentiality in the security of the identification of the peer. A typical example is the Remote Direct Data Placement Protocol (RDDP), which, when used with opportunistic IPsec, works well if channel bindings are available. Channel
Finally, the fifth class of security configurations uses cryptographic security techniques, but without strong identity (such as opportunistic IPsec). Thus, data integrity with or without confidentiality is provided when communicating with an unknown/unauthenticated principal. Just like the first category above, such applications can't perform access control based on network layer information since they do not know the identity of the peer. However, they might perform access control using higher-level notions of identity. The availability of IPsec (and similar solutions) together with channel bindings allows protocols (which, in themselves, are vulnerable to man-in-the-middle (MITM) attacks) to operate with a high level of confidentiality in the security of the identification of the peer. A typical example is the Remote Direct Data Placement Protocol (RDDP), which, when used with opportunistic IPsec, works well if channel bindings are available. Channel
Nordmark & Li Informational [Page 7] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
Nordmark & Li Informational [Page 7] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
bindings provide a link between the IP-layer identification and the application protocol identification.
bindings provide a link between the IP-layer identification and the application protocol identification.
A variant of the fifth class are those that use "leap-of-faith" during some initial communication. They do not provide strong identities except where subsequent communication is bound to the initial communication, providing strong assurance that the peer is the same as during the initial communication.
A variant of the fifth class are those that use "leap-of-faith" during some initial communication. They do not provide strong identities except where subsequent communication is bound to the initial communication, providing strong assurance that the peer is the same as during the initial communication.
The fifth class is important and its security properties must be preserved by a multihoming solution.
The fifth class is important and its security properties must be preserved by a multihoming solution.
The requirement for a multihoming solution is that security be no worse than it is today in all situations. Thus, mechanisms that provide confidentiality, integrity, or authentication today should continue to provide these properties in a multihomed environment.
The requirement for a multihoming solution is that security be no worse than it is today in all situations. Thus, mechanisms that provide confidentiality, integrity, or authentication today should continue to provide these properties in a multihomed environment.
3.2. Redirection Attacks Today
3.2. Redirection Attacks Today
This section enumerates some of the redirection attacks that are possible in today's Internet.
This section enumerates some of the redirection attacks that are possible in today's Internet.
If routing can be compromised, packets for any destination can be redirected to any location. This can be done by injecting a long prefix into global routing, thereby causing the longest match algorithm to deliver packets to the attacker.
If routing can be compromised, packets for any destination can be redirected to any location. This can be done by injecting a long prefix into global routing, thereby causing the longest match algorithm to deliver packets to the attacker.
Similarly, if DNS can be compromised, and a change can be made to an advertised resource record to advertise a different IP address for a hostname, effectively taking over that hostname. More detailed information about threats relating to DNS are in [DNS-THREATS].
Similarly, if DNS can be compromised, and a change can be made to an advertised resource record to advertise a different IP address for a hostname, effectively taking over that hostname. More detailed information about threats relating to DNS are in [DNS-THREATS].
Any system that is along the path from the source to the destination host can be compromised and used to redirect traffic. Systems may be added to the best path to accomplish this. Further, even systems that are on multi-access links that do not provide security can also be used to redirect traffic off of the normal path. For example, ARP and ND spoofing can be used to attract all traffic for the legitimate next hop across an Ethernet. And since the vast majority of applications rely on DNS lookups, if DNSsec is not deployed, then attackers that are on the path between the host and the DNS servers can also cause redirection by modifying the responses from the DNS servers.
Any system that is along the path from the source to the destination host can be compromised and used to redirect traffic. Systems may be added to the best path to accomplish this. Further, even systems that are on multi-access links that do not provide security can also be used to redirect traffic off of the normal path. For example, ARP and ND spoofing can be used to attract all traffic for the legitimate next hop across an Ethernet. And since the vast majority of applications rely on DNS lookups, if DNSsec is not deployed, then attackers that are on the path between the host and the DNS servers can also cause redirection by modifying the responses from the DNS servers.
In general, the above attacks work only when the attacker is on the path at the time it is performing the attack. However, in some cases it is possible for an attacker to create a DoS attack that remains at least some time after the attacker has moved off the path. An
In general, the above attacks work only when the attacker is on the path at the time it is performing the attack. However, in some cases it is possible for an attacker to create a DoS attack that remains at least some time after the attacker has moved off the path. An
Nordmark & Li Informational [Page 8] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
Nordmark & Li Informational [Page 8] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
example of this is an attacker that uses ARP or ND spoofing while on path to either insert itself or send packets to a black hole (a non-existent L2 address). After the attacker moves away, the ARP/ND entries will remain in the caches in the neighboring nodes for some amount of time (a minute or so in the case of ARP). This will result in packets continuing to be black-holed until ARP entry is flushed.
example of this is an attacker that uses ARP or ND spoofing while on path to either insert itself or send packets to a black hole (a non-existent L2 address). After the attacker moves away, the ARP/ND entries will remain in the caches in the neighboring nodes for some amount of time (a minute or so in the case of ARP). This will result in packets continuing to be black-holed until ARP entry is flushed.
Finally, the hosts themselves that terminate the connection can also be compromised and can perform functions that were not intended by the end user.
Finally, the hosts themselves that terminate the connection can also be compromised and can perform functions that were not intended by the end user.
All of the above protocol attacks are the subject of ongoing work to secure them (DNSsec, security for BGP, Secure ND) and are not considered further within this document. The goal for a multihoming solution is not to solve these attacks. Rather, it is to avoid adding to this list of attacks.
All of the above protocol attacks are the subject of ongoing work to secure them (DNSsec, security for BGP, Secure ND) and are not considered further within this document. The goal for a multihoming solution is not to solve these attacks. Rather, it is to avoid adding to this list of attacks.
3.3. Packet Injection Attacks Today
3.3. Packet Injection Attacks Today
In today's Internet the transport layer protocols, such as TCP and SCTP, which use IP, use the IP addresses as the identifiers for the communication. In the absence of ingress filtering [INGRESS], the IP layer allows the sender to use an arbitrary source address, thus the transport protocols and/or applications need some protection against malicious senders injecting bogus packets into the packet stream between two communicating peers. If this protection can be circumvented, then it is possible for an attacker to cause harm without necessarily needing to redirect the return packets.
In today's Internet the transport layer protocols, such as TCP and SCTP, which use IP, use the IP addresses as the identifiers for the communication. In the absence of ingress filtering [INGRESS], the IP layer allows the sender to use an arbitrary source address, thus the transport protocols and/or applications need some protection against malicious senders injecting bogus packets into the packet stream between two communicating peers. If this protection can be circumvented, then it is possible for an attacker to cause harm without necessarily needing to redirect the return packets.
There are various levels of protection in different transport protocols. For instance, in general TCP packets have to contain a sequence that falls in the receiver's window to be accepted. If the TCP initial sequence numbers are random, then it is very hard for an off-path attacker to guess the sequence number close enough for it to belong to the window, and as a result be able to inject a packet into an existing connection. How hard this is depends on the size of the available window, whether the port numbers are also predictable, and the lifetime of the connection. Note that there is ongoing work to strengthen TCP's protection against this broad class of attacks [TCPSECURE]. SCTP provides a stronger mechanism with the verification tag; an off-path attacker would need to guess this random 32-bit number. Of course, IPsec provides cryptographically strong mechanisms that prevent attackers, on or off path, from injecting packets once the security associations have been established.
There are various levels of protection in different transport protocols. For instance, in general TCP packets have to contain a sequence that falls in the receiver's window to be accepted. If the TCP initial sequence numbers are random, then it is very hard for an off-path attacker to guess the sequence number close enough for it to belong to the window, and as a result be able to inject a packet into an existing connection. How hard this is depends on the size of the available window, whether the port numbers are also predictable, and the lifetime of the connection. Note that there is ongoing work to strengthen TCP's protection against this broad class of attacks [TCPSECURE]. SCTP provides a stronger mechanism with the verification tag; an off-path attacker would need to guess this random 32-bit number. Of course, IPsec provides cryptographically strong mechanisms that prevent attackers, on or off path, from injecting packets once the security associations have been established.
Nordmark & Li Informational [Page 9] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
Nordmark & Li Informational [Page 9] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
When ingress filtering is deployed between the potential attacker and the path between the communicating peers, it can prevent the attacker from using the peer's IP address as source. In that case, the packet injection will fail in today's Internet.
When ingress filtering is deployed between the potential attacker and the path between the communicating peers, it can prevent the attacker from using the peer's IP address as source. In that case, the packet injection will fail in today's Internet.
We don't expect a multihoming solution to improve the existing degree of prevention against packet injection. However, it is necessary to look carefully at whether a multihoming solution makes it easier for attackers to inject packets because the desire to have the peer present at multiple locators, and perhaps at a dynamic set of locators, can potentially result in solutions that, even in the presence of ingress filtering, make packet injection easier.
私たちは、マルチホーミング解決がパケット注射に対して既存の度合いの防止を改良すると予想しません。 マルチホーミング解決で複数のロケータにおいて恐らく動力において出席している同輩がいる願望がロケータをセットしたので攻撃者がパケットを注入するのが、より簡単になるかどうかが注意深く見るのがしかしながら、潜在的にイングレスフィルタリングがあるときさえパケット注射をより簡単にするソリューションはもたらすことができるのが必要です。
3.4. Flooding Attacks Today
3.4. 今日のフラッディング攻撃
In the Internet today there are several ways for an attacker to use a redirection mechanism to launch DoS attacks that cannot easily be traced to the attacker. An example of this is to use protocols that cause reflection with or without amplification [PAXSON01].
インターネットに、攻撃者が容易に攻撃者にたどることができないDoS攻撃に着手するのにリダイレクションメカニズムを使用するいくつかの方法が今日、あります。 この例は増幅[PAXSON01]のあるなしにかかわらず反射を引き起こすプロトコルを使用することです。
Reflection without amplification can be accomplished by an attacker sending a TCP SYN packet to a well-known server with a spoofed source address; the resulting TCP SYN ACK packet will be sent to the spoofed source address.
TCP SYNパケットをよく知られるサーバに送る攻撃者は偽造しているソースアドレスで増幅のない反射を実行できます。 結果として起こるTCP SYN ACKパケットを偽造しているソースアドレスに送るでしょう。
Devices on the path between two communicating entities can also launch DoS attacks. While such attacks might not be interesting today, it is necessary to understand them better in order to determine whether a multihoming solution might enable new types of DoS attacks.
また、2の間の実体を伝える経路のデバイスはDoS攻撃に着手できます。 そのような攻撃は今日、おもしろくないかもしれませんが、それらをより理解するのが、マルチホーミング解決が新しいタイプのDoS攻撃を可能にするかもしれないかどうか決定するのに必要です。
For example, today, if A is communicating with B, then A can try to overload the path from B to A. If TCP is used, A could do this by sending ACK packets for data that it has not yet received (but it suspects B has already sent) so that B would send at a rate that would cause persistent congestion on the path towards A. Such an attack would seem self-destructive since A would only make its own corner of the network suffer by overloading the path from the Internet towards A.
例えば、AがBで交信する予定であるなら、今日、AはBからA.まで経路を積みすぎようとすることができます。If TCPが使用されている、インターネットからAに向かって経路を積みすぎることによって、Aはそれ自身のネットワークの角に苦しまれるだけでしょう、Aがそれがまだ受け取っていないデータのためにパケットをACKに送ることによって、これができて(それは、Bが既に発信したと疑います)、したがって、したがって、BがA.Suchに向かった経路における永続的な混雑に攻撃を引き起こすレートで発信するように自己破壊的に思えるでしょう。
A more interesting case is if A is communicating with B and X is on the path between A and B, then X might be able to fool B to send packets towards A at a rate that is faster than A (and the path between A and X) can handle. For instance, if TCP is used, then X can craft TCP ACK packets claiming to come from A to cause B to use a congestion window that is large enough to potentially cause persistent congestion towards A. Furthermore, if X can suppress the packets from A to B, it can also prevent A from sending any explicit
よりおもしろいケースがAがBで交信する予定であり、Xが経路にAとBとの間にあるということである、レートでAに向かってパケットを送るA(そして、AとXの間の経路)が扱うことができるより速い馬鹿Bにとって、その時、Xはできるかもしれません。 例えば、工芸品のTCP ACKパケットが、Bが潜在的にA.Furthermoreに向かって永続的な混雑を引き起こすことができるくらい大きい混雑ウィンドウを使用することを引き起こしにAから来ると主張して、TCPが使用されているなら、Xは防ぐことができます、XがAからBまでパケットを抑圧できるなら、それによって、また、Aはいずれも明白な状態で送ることができません。
Nordmark & Li Informational [Page 10] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
NordmarkとIPv6マルチホーミングソリューション2005年10月への李情報[10ページ]のRFC4218Threats
"slow down" packets to B; that is, X can disable any flow or congestion control mechanism such as Explicit Congestion Notification [ECN]. Similar attacks can presumably be launched using protocols that carry streaming media by forging such a protocol's notion of acknowledgement and feedback.
Bへの「遅く」パケット。 すなわち、Xは、どんな流れや混雑もExplicit Congestion Notification[電子証券取引ネットワーク]などの制御機構であると無効にすることができます。 おそらく、プロトコルの承認とフィードバックのそのような概念を作り出すことによってストリーミング・メディアを運ぶプロトコルを使用することで同様の攻撃に着手できます。
An attribute of this type of attack is that A will simply think that B is faulty since its flow and congestion control mechanisms don't seem to be working. Detecting that the stream of ACK packets is generated from X and not from A might be challenging, since the rate of ACK packets might be relatively low. This type of attack might not be common today because, in the presence of ingress filtering, it requires that X remain on the path in order to sustain the DoS attack. And in the absence of ingress filtering an attacker would need either to be present on the path initially and then move away, or to be able to perform the setup of the communication "blind", i.e., without seeing the return traffic (which, in the case of TCP, implies guessing the initial sequence number).
このタイプの攻撃の属性はAが、流れと混雑制御機構が働いているように思えないのでBが不完全であると単に思うということです。 ACKパケットの流れがAから生成されるのではなく、Xから生成される検出はやりがいがあるかもしれません、ACKパケットのレートが比較的低いかもしれないので。 イングレスフィルタリングがあるときXがDoS攻撃を支えるために経路に残るのが必要であるので、このタイプの攻撃は今日、一般的でないかもしれません。 そして、イングレスがないとき攻撃者をフィルターにかけるのは、初めは、経路に存在していて、次に、遠くに移行するか、または「ブラインド」というコミュニケーションのセットアップを実行できる必要があるでしょう、すなわち、リターントラフィックを見ないで(どれ、初期シーケンス番号を推測しながらTCPの場合で含意するか、)
The danger is that the addition of multihoming redirection mechanisms might potentially remove the constraint that the attacker remain on the path. And with the current, no-multihoming support, using end-to-end strong security at a protocol level at (or below) this "ACK" processing would prevent this type of attack. But if a multihoming solution is provided underneath IPsec that prevention mechanism would potentially not exist.
危険はマルチホーミングリダイレクションメカニズムの追加が潜在的に、攻撃者が経路に留まるという規制を取り除くかもしれないということです。 そして、現在のマルチホーミングがないサポートで、(or below)でプロトコルレベルにおける終わりから終わりへの強いセキュリティを使用して、この"ACK"処理はこのタイプの攻撃を防ぐでしょう。 しかし、IPsecの下でマルチホーミング解決法を提供するなら、その防止メカニズムは潜在的に存在していないでしょう。
Thus, the challenge for multihoming solutions is to not create additional types of attacks in this area, or make existing types of attacks significantly easier.
したがって、マルチホーミング解決のための挑戦は、この領域で追加タイプの攻撃を作成しないで、また既存のタイプの攻撃をかなり簡単にしないことです。
3.5. Address Privacy Today
3.5. 今日のアドレスプライバシー
In today's Internet there is limited ability to track a host as it uses the Internet because in some cases, such as dialup connectivity, the host will acquire different IPv4 addresses each time it connects. However, with increasing use of broadband connectivity, such as DSL or cable, it is becoming more likely that the host will maintain the same IPv4 over time. Should a host move around in today's Internet, for instance, by visiting WiFi hotspots, it will be configured with a different IPv4 address at each location.
今日のあるインターネットでは、ホストがダイアルアップの接続性などのように入手するいくつかの場合では、異なったIPv4がその都度それを扱うのでインターネットを使用するときホストを追跡する限られた能力は接続します。 しかしながら、DSLかケーブルなどの広帯域の接続性の増加する使用に従って、ホストが時間がたつにつれて同じIPv4をより維持しそうになっています。 例えば、今日のWiFiホットスポットを訪問するのによるインターネットでのホストおよそ移動であり、それは各位置の異なったIPv4アドレスによって構成されるべきです。
We also observe that a common practice in IPv4 today is to use some form of address translation, whether the site is multihomed or not. This effectively hides the identity of the specific host within a site; only the site can be identified based on the IP address.
また、私たちは、今日のIPv4の一般的な習慣が何らかの敬称翻訳を使用することになっているのを観測します、サイトが「マルチ-家へ帰」るか否かに関係なく。 事実上、これはサイトの中に特定のホストのアイデンティティを隠します。 IPアドレスに基づいてサイトしか特定できません。
Nordmark & Li Informational [Page 11] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
NordmarkとIPv6マルチホーミングソリューション2005年10月への李情報[11ページ]のRFC4218Threats
In the cases where it is desirable to maintain connectivity as a host moves around, whether using layer 2 technology or Mobile IPv4, the IPv4 address will remain constant during the movement (otherwise the connections would break). Thus, there is somewhat of a choice today between seamless connectivity during movement and increased address privacy.
ホストが動き回るので層2の技術かモバイルIPv4を使用するか否かに関係なく、接続性を維持するのが望ましい場合では、動きの間、IPv4アドレスは一定のままで残るでしょう(さもなければ、接続は中断しているでしょう)。 したがって、動きの間のシームレスの接続性と増強されたアドレスプライバシーの間には、いくぶん選択が今日、あります。
Today when a site is multihomed to multiple ISPs, the common setup is that a single IP address prefix is used with all the ISPs. As a result it is possible to track that it is the same host that is communication via all ISPs.
今日、サイトが複数のISPと「マルチ-家へ帰」ると、一般的なセットアップはただ一つのIPアドレス接頭語がすべてのISPと共に使用されるということです。 その結果、それがすべてのISPを通したコミュニケーションであるのと同じホストであることは追跡するのにおいて可能です。
However, when a host (and not a site) is multi-homed to several ISPs (e.g., through a General Packet Radio Service (GPRS) connection and a wireless hot spot), the host is provided with different IP addresses on each interface. While the focus of the multihoming work is on site multihoming, should the solution also be applicable to host multihoming, the privacy impact needs to be considered for this case as well.
しかしながら、aであるときに、ホスト(そして、サイトでない)がそうである、マルチ、家へ帰り、いくつかのISP(例えば、汎用パケット無線システム(GPRS)接続とaワイヤレスのホットスポットを通る)、ホストにとって、異なったIPアドレスで、各インタフェースは、あって、オンです。 また、ソリューションもホストマルチホーミングに適切であるなら、マルチホーミング仕事の焦点は現場のマルチホーミングですが、プライバシー影響は、このような場合また、考えられる必要があります。
IPv6 stateless address auto-configuration facilitates IP address management, but raises some concerns since the Ethernet address is encoded in the low-order 64 bits of the IPv6 address. This could potentially be used to track a host as it moves around the network, using different ISPs, etc. IPv6 specifies temporary addresses [RFC3041], which allow applications to control whether they need long-lived IPv6 addresses or desire the improved privacy of using temporary addresses.
IPv6の状態がないアドレス自動構成は、IPアドレス管理を容易にしますが、イーサネット・アドレスがIPv6アドレスの下位の64ビットでコード化されるので、いくつかの関心を高めます。 異なったISPなどを使用して、ネットワークの周りで移行するときホストを追跡するのに潜在的にこれを使用できました。 IPv6は仮の住所[RFC3041]を指定します。(アプリケーションは、仮の住所から彼らが長命のIPv6アドレスを必要とするか、または一時的なアドレスを使用する改良されたプライバシーを望んでいるかを制御できます)。
Given that there is no address privacy in site multihoming setups today, the primary concerns for the "do no harm" criteria are to ensure that hosts that move around still have the same ability as in today's Internet to choose between seamless connectivity and improved address privacy, and also that the introduction of multihoming support should still provide the same ability as we have in IPv6 with temporary addresses.
サイトマルチホーミングセットアップにアドレスプライバシーが全く今日なければ、動き回る評価基準がそれを確実にすることになっている「危害を加えないでください」ホストに関するプライマリ心配には、マルチホーミングサポートの導入がシームレスの接続性と改良されたアドレスプライバシーを選んで、また、それを提供するために私たちがIPv6で提供したようにまだ同じ能力を今日のインターネットに提供しているべきであるような同じ能力が仮の住所と共にまだあります。
When considering privacy threats, it makes sense to distinguish between attacks made by on-path entities observing the packets flying by, and attacks by the communicating peer. It is probably feasible to prevent on-path entities from correlating the multiple IP addresses of the host; but the fact that the peer needs to be told multiple IP addresses in order to be able to switch to using different addresses, when communication fails, limits the ability of the host to prevent correlating its multiple addresses. However, using multiple pseudonyms for a host should be able address this case.
プライバシーが脅威であると考えるとき、それは経路の実体によってされた攻撃を見分ける意味をパケットが近くを飛んでいるのを観測して、交信している同輩による攻撃にします。 経路の実体がホストの複数のIPアドレスを関連させるのを防ぐのはたぶん可能です。 しかし、同輩が、コミュニケーションが失敗するとIPが異なったアドレスを使用するのに切り替わることができるように扱う倍数がホストが複数のアドレスを関連させるのを防ぐ能力を制限すると言われる必要があるという事実。 しかしながら、倍数を使用して、ホストができるべきであるので、匿名は本件を扱います。
Nordmark & Li Informational [Page 12] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
NordmarkとIPv6マルチホーミングソリューション2005年10月への李情報[12ページ]のRFC4218Threats
4. Potential New Attacks
4. 潜在的新しい攻撃
This section documents the additional attacks that have been discovered that result from an architecture where hosts can change their topological connection to the network in the middle of a transport session without interruption. This discussion is again framed in the context where the topological locators may be independent of the host identifiers used by the transport and application layer protocols. Some of these attacks may not be applicable if traditional addresses are used. This section assumes that each host has multiple locators and that there is some mechanism for determining the locators for a correspondent host. We do not assume anything about the properties of these mechanisms. Instead, this list will serve to help us derive the properties of these mechanisms that will be necessary to prevent these redirection attacks.
このセクションはホストが彼らの位相的な接続を変えることができるアーキテクチャからネットワークまで発見されて、それが結果として生じるということである追加攻撃を間断ないことの輸送セッションの途中に記録します。 この議論は再び位相的なロケータが輸送と応用層プロトコルによって使用されるホスト識別子から独立しているかもしれない文脈で縁どられます。 伝統的なアドレスが使用されているなら、これらの攻撃のいくつかが適切でないかもしれません。 このセクションは各ホストが複数のロケータを持って、通信員のホストのためにロケータを決定するための何らかのメカニズムがあると仮定します。 私たちはこれらのメカニズムの特性に関して何も思いません。代わりに、このリストは、私たちがこれらのリダイレクション攻撃を防ぐために必要になるこれらのメカニズムの特性を引き出すのを助けるのに役立つでしょう。
Depending on the purpose of the redirection attack, we separate the attacks into several different types.
リダイレクション攻撃の目的によって、私たちはいくつかの異なったタイプに攻撃を切り離します。
4.1. Cause Packets to Be Sent to the Attacker
4.1. 攻撃者に送られる原因パケット
An attacker might want to receive the flow of packets, for instance to be able to inspect and/or modify the payload or to be able to apply cryptographic analysis to cryptographically protected payload, using redirection attacks.
攻撃者はパケットの流れを受けたがっているかもしれません、例えば、ペイロードを点検する、そして/または、変更するか、または暗号で保護されたペイロードに暗号の分析を適用できるように、リダイレクションを使用するのが攻撃されます。
Note that such attacks are always possible today if an attacker is on the path between two communicating parties, and a multihoming solution can't remove that threat. Hence, the bulk of these concerns relate to off-path attackers.
攻撃者が2の間のパーティーを伝える経路にいるなら、そのような攻撃が今日いつも可能であることに注意してください。そうすれば、マルチホーミング解決はその脅威を取り除くことができません。 したがって、これらの関心の大半がオフ経路攻撃者に関連します。
4.1.1. Once Packets Are Flowing
4.1.1. 一度、パケットは流れています。
This might be viewed as the "classic" redirection attack.
これは「古典的な」リダイレクション攻撃として見なされるかもしれません。
While A and B are communicating X might send packets to B and claim: "Hi, I'm A, send my packets to my new location." where the location is really X's location.
AとBが交信している間、XはBとクレームにパケットを送るかもしれません: 「こんにちは、私はAであり、新しい位置にパケットを送ります」。. 位置が本当にXの位置であるところ。
"Standard" solutions to this include requiring that the host requesting redirection somehow be verified to be the same host as the initial host that established communication. However, the burdens of such verification must not be onerous, or the redirection requests themselves can be used as a DoS attack.
これへの「標準」のソリューションは、リダイレクションを要求するホストがコミュニケーションを確立した初期のホストと同じホストになるようにどうにか確かめられるのが必要であることを含んでいます。 しかしながら、そのような検証の負担が煩わしいはずがありませんか、またはDoSが攻撃するとき、リダイレクション要求自体は使用できます。
Nordmark & Li Informational [Page 13] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
NordmarkとIPv6マルチホーミングソリューション2005年10月への李情報[13ページ]のRFC4218Threats
To prevent this type of attack, a solution would need some mechanism that B can use to verify whether a locator belongs to A before B starts using that locator, and be able to do this when multiple locators are assigned to A.
このタイプの攻撃を防ぐために、ソリューションは、Bが使用できる何らかのメカニズムがBがそのロケータを使用し始める前にロケータがAに属すかどうか確かめて、複数のロケータがAに割り当てられるときこれができる必要があるでしょう。
4.1.2. Time-Shifting Attack
4.1.2. タイム・シフト攻撃
The term "time-shifting attack" is used to describe an attacker's ability to perform an attack after no longer being on the path. Thus, the attacker would have been on the path at some point in time, snooping and/or modifying packets; and later, when the attacker is no longer on the path, it launches the attack.
「タイム・シフト攻撃」という用語は、もう後に経路にありながら攻撃を実行する攻撃者の能力について説明するのに使用されます。 したがって、パケットを詮索する、そして/または、変更して、時間内に、攻撃者は何らかのポイントの経路にいたでしょう。 そして、後で、攻撃者がもういずれの経路にもいないとき、それは攻撃に着手します。
In the current Internet, it is not possible to perform such attacks to redirect packets. But for some time after moving away, the attacker can cause a DoS attack, e.g., by leaving a bogus ARP entry in the nodes on the path, or by forging TCP Reset packets based on having seen the TCP Initial Sequence Numbers when it was on the path.
現在のインターネットでは、パケットを向け直すためにそのような攻撃を実行するのは可能ではありません。 しかし、遠くに移行した後のいつかの時間、攻撃者は、例えば、経路のノードでにせのARPエントリーを出るか、またはそれが経路にあったときTCP Initial Sequence民数記を見たことに基づいてTCP Resetパケットを鍛造することによって、DoS攻撃を引き起こす場合があります。
It would be reasonable to require that a multihoming solution limit the ability to redirect and/or DoS traffic to a few minutes after the attacker has moved off the path.
いくつかへのトラフィックが攻撃者の後に書き留めるマルチホーミングソリューション限界の向け直す能力、そして/または、DoSが経路から離れたのが必要であるのは妥当でしょう。
4.1.3. Premeditated Redirection
4.1.3. 計画的なリダイレクション
This is a variant of the above where the attacker "installs" itself before communication starts.
これはコミュニケーションが始まる前に攻撃者がそれ自体を「インストールするところ」の上記の異形です。
For example, if the attacker X can predict that A and B will communicate in the (near) future, then the attacker can tell B: "Hi, I'm A and I'm at this location". When A later tries to communicate with B, will B believe it is really A?
例えば、攻撃者Xが、AとBが(近い)未来に交信すると予測できるなら、攻撃者はBを言うことができます: 「こんにちは、私はAです、そして、この位置に、います。」 Aが後でBで交信しようとするとき、Bは、それが本当にAであると信じるでしょうか?
If the solution to the classic redirection attack is based on "prove you are the same as initially", then A will fail to prove this to B because X initiated communication.
古典的なリダイレクション攻撃へのソリューションが「同じくらい初めは同じであると立証してください」に基づいていると、Xがコミュニケーションを開始したので、AはBにこれを立証しないでしょう。
Depending on details that would be specific to a proposed solution, this type of attack could either cause redirection (so that the packets intended for A will be sent to X) or they could cause DoS (where A would fail to communicate with B since it can't prove it is the same host as X).
提案されたソリューションに特定の詳細によって、このタイプの攻撃がリダイレクションを引き起こす場合がありましたか(Aのために意図するパケットをXに送るように)、またはそれらはDoSを引き起こす場合がありました(それを立証できないのでAがどこでBで交信しないかは、Xと同じホストです)。
To prevent this attack, the verification of whether a locator belongs to the peer cannot simply be based on the first peer that made contact.
この攻撃を防ぐために、ロケータが同輩のものであるかどうかに関する検証は接触を作った最初の同輩に絶対に基づくことができません。
Nordmark & Li Informational [Page 14] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
NordmarkとIPv6マルチホーミングソリューション2005年10月への李情報[14ページ]のRFC4218Threats
4.1.4. Using Replay Attacks
4.1.4. 反射攻撃を使用します。
While the multihoming problem doesn't inherently imply any topological movement, it is useful to also consider the impact of site renumbering in combination with multihoming. In that case, the set of locators for a host will change each time its site renumbers, and, at some point in time after a renumbering event, the old locator prefix might be reassigned to some other site.
マルチホーミング問題は本来少しの位相的な運動も含意しませんが、また、マルチホーミングと組み合わせたサイトの番号を付け替えることの影響を考えるのは役に立ちます。 その場合、ホストのためのロケータのセットはサイトが番号を付け替えさせる各回を変えるでしょう、そして、番号を付け替えるイベントの後に時間内にの何らかのポイントでは、古いロケータ接頭語はある他のサイトに再選任されるかもしれません。
This potentially give an attacker the ability to replay whatever protocol mechanism was used to inform a host of a peer's locators so that the host would incorrectly be led to believe that the old locator (set) should be used even long after a renumbering event. This is similar to the risk of replay of Binding Updates in [MIPv6], but the time constant is quite different; Mobile IPv6 might see movements every second while site renumbering, followed by reassignment of the site locator prefix, might be a matter of weeks or months.
これは、ホストが、古いロケータ(設定する)が番号を付け替えるイベントのずっと後にさえ使用されるべきであると信じているように不当に導かれるように同輩のロケータについてホストに知らせるために潜在的に使用されたどんなプロトコルメカニズムも再演する能力を攻撃者に与えます。 これは[MIPv6]のBinding Updatesの再生のリスクと同様ですが、時定数は全く異なっています。 サイトロケータ接頭語の再割当てがあとに続いたサイトの番号を付け替えるのは何週間もの何カ月もの問題であるかもしれませんが、モバイルIPv6は毎秒の動きを見るかもしれません。
To prevent such replay attacks, the protocol used to verify which locators can be used with a particular identifier needs some replay protection mechanism.
そのような反射攻撃を防ぐために、特定の識別子と共にどのロケータを使用できるかを確かめるのに使用されるプロトコルは何らかの反復操作による保護メカニズムを必要とします。
Also, in this space one needs to be concerned about potential interaction between such replay protection and the administrative act of reassignment of a locator. If the identifier and locator relationship is distributed across the network, one would need to make sure that the old information has been completely purged from the network before any reassignment. Note that this does not require an explicit mechanism. This can instead be implemented by locator reuse policy and careful timeouts of locator information.
また、このスペースでは、人は、そのような反復操作による保護とロケータの再割当ての管理行為との潜在的相互作用に関して心配する必要があります。 識別子とロケータ関係がネットワークの向こう側に分配されるなら、人は、旧情報がどんな再割当ての前にもネットワークから完全に追放されたのを確実にする必要があるでしょう。 これが明白なメカニズムを必要としないことに注意してください。 ロケータ情報のロケータ再利用方針と慎重なタイムアウトは代わりにこれを実装することができます。
4.2. Cause Packets to Be Sent to a Black Hole
4.2. ブラックホールに送られる原因パケット
This is also a variant of the classic redirection attack. The difference is that the new location is a locator that is nonexistent or unreachable. Thus, the effect is that sending packets to the new locator causes the packets to be dropped by the network somewhere.
また、これは古典的なリダイレクション攻撃の異形です。 違いは新しい位置が実在しないか、または手が届かないロケータであるということです。 したがって、効果はネットワークが新しいロケータにパケットを送るのにパケットをどこかに下げるということです。
One would expect that solutions that prevent the previous redirection attacks would prevent this attack as a side effect, but it makes sense to include this attack here for completeness. Mechanisms that prevented a redirection attack to the attacker should also prevent redirection to a black hole.
人は、前のリダイレクション攻撃を防ぐソリューションが副作用としてこの攻撃を防ぐでしょうが、完全性のためにここにこの攻撃を含む意味になると予想するでしょう。 また、リダイレクション攻撃を攻撃者に防いだメカニズムはブラックホールにリダイレクションを防ぐはずです。
Nordmark & Li Informational [Page 15] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
NordmarkとIPv6マルチホーミングソリューション2005年10月への李情報[15ページ]のRFC4218Threats
4.3. Third Party Denial-of-Service Attacks
4.3. 第三者サービス不能攻撃
An attacker can use the ability to perform redirection to cause overload on an unrelated third party. For instance, if A and B are communicating, then the attacker X might be able to convince A to send the packets intended for B to some third node C. While this might seem harmless at first, since X could just flood C with packets directly, there are a few aspects of these attacks that cause concern.
攻撃者は、関係ない第三者でオーバーロードを引き起こすのに履行能力リダイレクションを使用できます。 例えば、AとBが交信する予定であるなら、Xが、Aがパケットを送ると納得させることができるかもしれない攻撃者は初めにBのために、無害な状態でこれが思えるかもしれないノードC.Whileをいくつかの3番目まで意図しました、XがパケットでCをただ直接あふれさせることができたので心配をかけるこれらの攻撃のいくつかの局面があります。
The first is that the attacker might be able to completely hide its identity and location. It might suffice for X to send and receive a few packets to A in order to perform the redirection, and A might not retain any state on who asked for the redirection to C's location. Even if A had retained such state, that state would probably not be easily available to C, thus C can't determine who the attacker was once C has become the victim of a DoS attack.
1番目は攻撃者がそのアイデンティティと位置を完全に隠すことができるかもしれないということです。 リダイレクションを実行して、XがいくつかのパケットをAに送って、受けるように、それは十分であるかもしれません、そして、だれがCの位置にリダイレクションを求めたかに関してAは少しの状態も保有しないかもしれません。 Aがそのような状態を保有したとしても、その状態がたぶん容易にCに利用可能でないだろう、その結果、CがいったんDoS攻撃の犠牲者になると、Cは攻撃者がだれであったかを決定できません。
The second concern is that, with a direct DoS attack from X to C, the attacker is limited by the bandwidth of its own path towards C. If the attacker can fool another host, such as A, to redirect its traffic to C, then the bandwidth is limited by the path from A towards C. If A is a high-capacity Internet service and X has slow (e.g., dialup) connectivity, this difference could be substantial. Thus, in effect, this could be similar to packet amplifying reflectors in [PAXSON01].
2番目の関心はXからCまでのダイレクトDoS攻撃による攻撃者がそれ自身の経路の帯域幅によって攻撃者のC.Ifに向かって制限されるのがCにトラフィックを向け直すためにAなどの別のホストをだますことができて、次に、帯域幅が経路によってAからC.Ifに向かって制限されて、Aが高容量インターネットのサービス的であり、Xには遅い(例えば、ダイアルアップ)接続性があって、この違いが実質的であるかもしれないということであるということです。 このようにして、そして、事実上、これは[PAXSON01]で反射鏡を増幅するパケットと同様であるかもしれません。
The third, and final concern, is that if an attacker only need a few packets to convince one host to flood a third party, then it wouldn't be hard for the attacker to convince lots of hosts to flood the same third party. Thus, this could be used for Distributed Denial-of- Service attacks.
3番目の、そして、最終的な関心は攻撃者が第三者をあふれさせるように1人のホストを説得するためにいくつかのパケットを必要とするだけであるなら攻撃者が、同じ第三者をあふれさせるように多くのホストを説得しにくくないだろうということです。 その結果、Distributed Denialにこれを使用できた、-、サービス攻撃について。
A third party DoS attack might be against the resources of a particular host (i.e., C in the example above), or it might be against the network infrastructure towards a particular IP address prefix, by overloading the routers or links even though there is no host at the address being targeted.
第三者DoS攻撃が特定のホスト(すなわち、上記の例のC)のリソースに反対しているかもしれませんか、または特定のIPアドレス接頭語に向かったネットワークインフラに反対しているかもしれません、ホストが全く狙うアドレスにいませんが、ルータかリンクを積みすぎることによって。
In today's Internet, the ability to perform this type of attack is quite limited. In order for the attacker to initiate communication, it will in most cases need to be able to receive some packets from the peer (the potential exception being techniques that combine this with TCP-sequence-number-guessing techniques). Furthermore, to the extent that parts of the Internet uses ingress filtering [INGRESS], even if the communication could be initiated, it wouldn't be possible to sustain it by sending ACK packets with spoofed source addresses from an off-path attacker.
今日のインターネットでは、このタイプの攻撃を実行する能力はかなり限られています。 多くの場合、攻撃者がコミュニケーションを開始するように、それは、同輩(TCP系列数の推測のテクニックにこれを結合するテクニックである潜在的例外)からいくつかのパケットを受けることができる必要があるでしょう。 その上、インターネットの地域がコミュニケーションを開始できても[INGRESS]をフィルターにかけるイングレスを使用するという範囲には、偽造しているソースアドレスがあるパケットをオフ経路攻撃者からACKに送ることによってそれを支えるのが可能でないでしょう。
Nordmark & Li Informational [Page 16] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
NordmarkとIPv6マルチホーミングソリューション2005年10月への李情報[16ページ]のRFC4218Threats
If this type of attack can't be prevented, there might be mitigation techniques that can be employed. For instance, in the case of TCP a partial defense can be constructed by having TCP slow-start be triggered when the destination locator changes. (Folks might argue that, separately from security, this would be the correct action for congestion control since TCP might not have any congestion-relation information about the new path implied by the new locator.) Presumably the same approach can be applied to other transport protocols that perform different forms of (TCP-friendly) congestion control, even though some of them might not adapt as rapidly as TCP. But since all congestion-controlled protocols probably need to have some reaction to the path change implied by a locator change, it makes sense to think about 3rd party DoS attacks when designing how the specific transport protocols should react to a locator change. However, this would only be a partial solution since it would probably take several packets and roundtrips before the transport protocol would stop transmitting; thus, an attacker could still use this as a reflector with packet amplification. Thus, the multihoming mechanism probably needs some form of defense against third party DoS attacks, in addition to the help we can get from the transport protocols.
このタイプの攻撃を防ぐことができないなら、使うことができる緩和のテクニックがあるかもしれません。 例えば、TCPの場合では、目的地ロケータが変化するときTCP遅れた出発を引き起こさせることによって、部分的なディフェンスを構成できます。 (人々はそれについて論争するかもしれなくて、TCPが新しいロケータで新しい経路のどんな混雑関係情報も含意させないかもしれないので、別々に、これは輻輳制御のためのセキュリティからの、正しい動作でしょう。) 異なった形式の(TCPに優しい)の輻輳制御を実行する他のトランスポート・プロトコルにおそらく同じアプローチを適用できます、それらのいくつかがTCP急速に適合しないかもしれませんが。 しかし、すべての混雑で制御されたプロトコルが、たぶんロケータ変化で経路変化への何らかの反応を含意させる必要があるので、それは特定のトランスポート・プロトコルがどうロケータ変化に反応するべきであるかを設計するとき第3パーティーDoSについて考える意味を攻撃にします。 トランスポート・プロトコルが、伝わるのを止める前にたぶんいくつかのパケットと往復旅行を取るでしょう、しかしながら、したがって、これは部分的解決にすぎないでしょう。 したがって、攻撃者は反射鏡としてパケット増幅でまだこれを使用できました。 したがって、マルチホーミングメカニズムは第三者DoS攻撃に対してたぶん何らかの形式のディフェンスを必要とします、私たちがトランスポート・プロトコルから得ることができる助けに加えて。
4.3.1. Basic Third Party DoS
4.3.1. 基本的な第三者DoS
Assume that X is on a slow link anywhere in the Internet. B is on a fast link (gigabits; e.g., a media server) and A is the victim.
Xがインターネットでどこでも遅いリンクの上にあると仮定してください。 速いリンク(ギガビット; 例えば、メディアサーバ)の上にBがあります、そして、Aは犠牲者です。
X could flood A directly but is limited by its low bandwidth. If X can establish communication with B, ask B to send it a high-speed media stream, then X can presumably fake out the "acknowledgements/feedback" needed for B to blast out packets at full speed. So far, this only hurts X and the path between X and the Internet. But if X could also tell B "I'm at A's locator", then X has effectively used this redirection capability in multihoming to amplify its DoS capability, which would be a source of concern.
Xは、Aを直接あふれさせることができましたが、低い帯域幅によって制限されます。 XがBとのコミュニケーションを確立できるなら、高速メディアストリームをそれに送るようにBに頼んでください、そして、おそらく、次に、XはBが全速力で出ているパケットを爆破するのに必要である「承認/フィードバック」をだますことができます。 今までのところ、これはXとインターネットの間のXと経路に害を与えるだけです。 しかし、また、「私はAのロケータにいます」と、XがBに言うことができるなら、事実上、Xは、DoS能力を増幅するのにマルチホーミングでこのリダイレクション能力を使用しました。(それは、悩みの種でしょう)。
One could envision rather simple techniques to prevent such attacks. For instance, before sending to a new peer locator, perform a clear text exchange with the claimed new locator of the form "Are you X?" resulting in "Yes, I'm X.". This would suffice for the simplest of attacks. However, as we will see below, more sophisticated attacks are possible.
人は、そのような攻撃を防ぐためにかなり簡単なテクニックを思い描くことができました。 例えば、フォーム「あなたはXですか?」の結果になることの要求された新しいロケータが「はい、私はX.です」にある状態で、新しい同輩ロケータに発信する前に、クリアテキスト交換を実行してください。 これは最も簡単な攻撃に十分でしょう。 しかしながら、私たちが以下を見るように、より洗練された攻撃は可能です。
Nordmark & Li Informational [Page 17] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
NordmarkとIPv6マルチホーミングソリューション2005年10月への李情報[17ページ]のRFC4218Threats
4.3.2. Third Party DoS with On-Path Help
4.3.2. ヘルプが経路にある第三者DoS
The scenario is as above, but, in addition, the attacker X has a friend Y on the path between A and B:
シナリオが同じくらい上にありますが、さらに、攻撃者Xは経路にAとBとの間に友人Yがいます:
----- ----- -----
| A |--------| Y |--------| B |
----- ----- -----
/
/
/
/
/
/
-----
| X |
-----
----- ----- ----- | A|--------| Y|--------| B| ----- ----- ----- / / / / / / ----- | X| -----
With the simple solution suggested in the previous section, all Y might need to do is fake a response to the "Are you X?" packet, and after that point in time Y might not be needed; X could potentially sustain the data flow towards A by generating the ACK packets. Thus, it would be even harder to detect the existence of Y.
簡単なソリューションで、前項で示されて、Yが、する必要があるかもしれないのは、「あなたはXですか?」パケットへの応答を見せかけて、時間Yのその時点の後に必要でないかもしれないことです。 Xは、ACKパケットを生成することによって、潜在的にAに向かってデータフローを支えることができるでしょう。 したがって、Yの存在をさらに検出しにくいでしょう。
Furthermore, if X is not the actual end system but an attacker between some node C and B, then X can claim to be C, and no finger can be pointed at X either:
その上、Xは、Xが実際のエンドシステムではなく、いくつかのノードCとBの間の攻撃者であるならCであると主張できます、そして、どんな指もXを指すことができません:
----- ----- -----
| A |--------| Y |--------| B |
----- ----- -----
/
/
/
/
/
/
----- -----
| C |-------| X |
----- -----
----- ----- ----- | A|--------| Y|--------| B| ----- ----- ----- / / / / / / ----- ----- | C|-------| X| ----- -----
Thus, with two attackers on different paths, there might be no trace of who did the redirection to the 3rd party once the redirection has taken place.
したがって、リダイレクションがいったん行われるとだれが3番目のパーティーにリダイレクションをしたかに関する跡が全く異なった経路の2人の攻撃者と共にいないかもしれません。
A specific case of this is when X=Y, and X is located on the same LAN as B.
この特定のケースはいつX=Yであるか、そして、XはBと同じLANに位置しています。
Nordmark & Li Informational [Page 18] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
NordmarkとIPv6マルチホーミングソリューション2005年10月への李情報[18ページ]のRFC4218Threats
A potential way to make such attacks harder would be to use the last received (and verified) source locator as the destination locator. That way, when X sends the ACK packets (whether it claims to be X or C) the result would be that the packet flow from B would switch back towards X/C, which would result in an attack similar to what can be performed in today's Internet.
そのような攻撃をより困難にする潜在的方法は目的地ロケータとして最後の容認された(そして、確かめられる)ソースロケータを使用するだろうことです。 XがそれがパケットであったならACKパケット(それが、XかCであると主張するか否かに関係なく)に結果を送るとき、そのように、Bからの流れはX/Cに向かって元に戻るでしょう。Cは今日のインターネットで実行できることと同様の攻撃をもたらすでしょう。
Another way to make such attacks harder would be to perform periodic verifications that the peer is available at the locator, instead of just one when the new locator is received.
そのような攻撃をより困難にする別の方法は新しいロケータが受け取られているとき、ちょうど1の代わりにロケータで利用可能な状態で同輩がそうである周期的な検証を実行するだろうことです。
A third way that a multihoming solution might address this is to ensure that B will only accept locators that can be authenticated to be synonymous with the original correspondent. It must be possible to securely ensure that these locators form an equivalence class. So in the first example, not only does X need to assert that it is A, but A needs to assert that it is X.
マルチホーミング解決がこれを扱うかもしれない3番目の方法はBが、認証できるロケータがオリジナルの通信員と同義であると受け入れるだけであるのを保証することです。 これらのロケータが同値類を形成するのをしっかりと保証するのは可能であるに違いありません。 そのように、最初の例では、Xは、それがAであると断言する必要があるだけではなく、Aが、それがXであると断言する必要があります。
4.4. Accepting Packets from Unknown Locators
4.4. 未知のロケータからパケットを受け入れます。
The multihoming solution space does not only affect the destination of packets; it also raises the question from which sources packets should be accepted. It is possible to build a multihoming solution that allows traffic to be recognized as coming from the same peer even if there is a previously unknown locator present in the source address field. The question is whether we want to allow packets from unverified sources to be passed on to transport and application layer protocols.
マルチホーミングソリューションスペースはパケットの目的地に影響するだけではありません。 また、それはソースパケットが受け入れられるべきである疑問を引き起こします。 トラフィックがソースアドレス・フィールドの現在の以前に未知のロケータがあっても同じ同輩から来ると認識されるのを許容するマルチホーミング解決を組み込むのは可能です。 質問は非検証されたソースからのパケットが輸送と応用層プロトコルに通過されるのを許したいと思うかどうかということです。
In the current Internet, an attacker can't inject packets with arbitrary source addresses into a session if there is ingress filtering present, so allowing packets with unverified sources in a multihoming solution would fail our "no worse than what we have now" litmus test. However, given that ingress filtering deployment is far from universal and ingress filtering typically wouldn't prevent spoofing of addresses in the same subnet, requiring rejecting packets from unverified locators might be too stringent.
現在のインターネットでは、マルチホーミング解決で非検証されたソースがあるパケットを許容すると私たちの「私たちが現在持っているものほど悪くない」リトマス試験が失敗されて、存在しているイングレスフィルタリングがあれば、攻撃者は任意のセッションまでのソースアドレスをパケットに注射できません。 しかしながら、展開をフィルターにかけるのが普遍的にかけ離れていて、イングレスフィルタリングが偽造するのを通常防がない同じサブネットにおけるアドレスのそのイングレスを考えて、非検証されたロケータからパケットを拒絶するのが必要であるのは厳し過ぎるかもしれません。
An example of the current state are the ability to inject RST packets into existing TCP connections. When there is no ingress filtering in the network, this is something that the TCP endpoints need to sort out themselves. However, deploying ingress filtering helps in today's Internet since an attacker is limited in the set of source addresses it can use.
現状に関する例は既存のTCP接続にRSTパケットを注ぐ能力です。 ネットワークでフィルターにかけられるイングレスが全くないとき、これはTCP終点が自分たちを整理するために必要とする何かです。 しかしながら、攻撃者がそれが使用できるソースアドレスのセットが制限されるので、イングレスがフィルタリングであると配布するのが今日のインターネットで助けます。
Nordmark & Li Informational [Page 19] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
NordmarkとIPv6マルチホーミングソリューション2005年10月への李情報[19ページ]のRFC4218Threats
A factor to take into account to determine the "requirement level" for this is that when IPsec is used on top of the multihoming solution, then IPsec will reject such spoofed packets. (Note that this is different than in the redirection attack cases where even with IPsec an attacker could potentially cause a DoS attack.)
これのために「要件レベル」を決定するために考慮に入れる要素は次に、IPsecがマルチホーミング解決の上で使用されるときIPsecがパケットであると偽造されたそのようなものを拒絶するということです。 (これがリダイレクション攻撃ケースより中IPsecがあっても、攻撃者が潜在的にDoS攻撃を引き起こす場合があった異なっていることに注意してください。)
There might also be a middle ground where arbitrary attackers are prevented from injecting packets by using the SCTP verification tag type of approach [SCTP]. (This is a clear-text tag which is sent to the peer which the peer is expected to include in each subsequent packet.) Such an approach doesn't prevent packet injection from on-path attackers (since they can observe the verification tag), but neither does ingress filtering.
また、妥協点が任意の攻撃者がアプローチ[SCTP]のSCTP検証タグタイプを使用することによってパケットを注入するのが防がれるところにあるかもしれません。 (これは同輩がそれぞれのその後のパケットに含んでいると予想される同輩に送られるクリアテキストタグです。) そのようなアプローチは経路の攻撃者からパケット注射を防ぎませんが(彼らが検証タグを観察できるので)、イングレスフィルタリングも防ぎません。
4.5. New Privacy Considerations
4.5. 新しいプライバシー問題
While introducing identifiers can be helpful by providing ways to identify hosts across events when its IP address(es) might change, there is a risk that such mechanisms can be abused to track the identity of the host over long periods of time, whether using the same (set of) ISP(s) or moving between different network attachment points. Designers of solutions to multihoming need to be aware of this concern.
識別子を紹介するのがイベントの向こう側にホストを特定するIPアドレス(es)が変化するかもしれなくて、リスクがある方法にそれを提供することによって役立っている場合がある間、同じように(セットされる)ISPを使用するか、または異なったネットワーク付着点の間で移行することにかかわらず長期間の間、ホストのアイデンティティを追跡するためにそのようなメカニズムを誤用できます。 マルチホーミングへの解決のデザイナーは、この関心を意識している必要があります。
Introducing the multihoming capability inherently implies that the communicating peers need to know multiple locators for each other in order to be resilient to failures of some paths/locators. In addition, if the multihoming signaling protocol doesn't provide privacy, it might be possible for 3rd parties on the path to discover many or all the locators assigned to a host, which would increase the privacy exposure compared to a multihomed host today.
本来マルチホーミング能力を導入するのは、交信している同輩が、互いでいくつかの経路/ロケータの失敗に弾力があるように複数のロケータを知る必要であるのを含意します。 さらに、マルチホーミングシグナリングプロトコルがプライバシーを提供しないなら、経路の3番目のパーティーが多くか今日「マルチ-家へ帰」っているホストと比べて、プライバシ暴露を増強するだろうホストに割り当てられたすべてのロケータを発見するのは、可能であるかもしれません。
For instance, a solution could address this by allowing each host to have multiple identifiers at the same time and perhaps even changing the set of identifiers that are used over time. Such an approach could be analogous to what is done for IPv6 addresses in [RFC3041].
例えば、ソリューションは、各ホストには同時にの複数の識別子と恐らく変化さえあるのを許容するのによるこれが時間がたつにつれて使用される識別子のセットであると扱うかもしれません。 そのようなアプローチは[RFC3041]のIPv6アドレスのために行われることに類似しているかもしれません。
5. Granularity of Redirection
5. リダイレクションの粒状
Different multihoming solutions might approach the problem at different layers in the protocol stack. For instance, there have been proposals for a shim layer inside IP, as well as transport layer approaches. The former would have the capability to redirect an IP address while the latter might be constrained to only redirect a single transport connection. This difference might be important when it comes to understanding the security impact.
異なったマルチホーミング解決はプロトコル・スタックの異なった層で問題にアプローチするかもしれません。 例えば、トランスポート層アプローチと同様にIPの中に詰め物の層のための提案がありました。 前者には、後者が単独の輸送接続を向け直すだけであるのが抑制されるかもしれませんが、IPアドレスを転送する能力があるでしょう。 セキュリティ影響を理解することとなると、この違いは重要であるかもしれません。
Nordmark & Li Informational [Page 20] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
NordmarkとIPv6マルチホーミングソリューション2005年10月への李情報[20ページ]のRFC4218Threats
For instance, premeditated attacks might have quite different impact in the two cases. In an IP-based multihoming solution a successful premeditated redirection could be due to the attacker connecting to a server and claiming to be 'A', which would result in the server retaining some state about 'A', which it received from the attacker. Later, when the real 'A' tries to connect to the server, the existence of this state might mean that 'A' fails to communicate, or that its packets are sent to the attacker. But if the same scenario is applied to a transport-layer approach, then the state created due to the attacker would perhaps be limited to the existing transport connection. Thus, while this might prevent the real 'A' from connecting to the server while the attacker is connected (if they happen to use the same transport port number), most likely it would not affect 'A's ability to connect after the attacker has disconnected.
例えば、計画的な攻撃には、2つの場合における全く異なった影響力があるかもしれません。 IPベースのマルチホーミングソリューションaうまくいっている計画的なリダイレクションに、サーバに接続して、'A'であると主張するのが(それが攻撃者から受けた'A'に関して何らかの状態を保有するサーバをもたらすでしょう)攻撃者のためにあるかもしれません。 本当の'A'がその後サーバに接続しようとするとき、この状態の存在は、'A'が交信しないか、またはパケットが攻撃者に送られることを意味するかもしれません。 しかし、同じシナリオがトランスポート層アプローチに適用されるなら、攻撃者のため創設された状態は恐らく既存の輸送接続に制限されるでしょう。 したがって、これは、攻撃者が接続されている間(彼らがたまたま同じ輸送ポートナンバーを使用するなら)、本当の'A'がサーバに接続するのを防ぐかもしれませんが、たぶん、それは'攻撃者が切断した後に接続するAの能力'に影響しないでしょう。
A particular aspect of the granularity question is the direction question: will the created state be used for communication in the reverse direction of the direction when it was created? For instance, if the attacker 'X' suspects that 'A' will connect to 'B' in the near future, can X connect to A and claim to be B, and then have that later make A connect to the attacker instead of to the real B?
粒状質問の特定の局面は方向質問です: それが作成されたとき、作成された状態は方向の反対の方向によるコミュニケーションに使用されるでしょうか? 例えば、攻撃者'X'がその'近さで''Bに接続する'未来を疑うなら、Xで、Aに接続して、Bであると主張して、次に、Aは後で本当のBの代わりにそれで攻撃者に接できますか?
Note that transport layer approaches are limited to the set of "transport" protocols that the implementation makes aware of multihoming. In many cases there would be "transport" protocols that are unknown to the multihoming capability of the system, such as applications built on top of UDP. To understand the impact of the granularity question on the security, one would also need to understand how such applications/protocols would be handled.
トランスポート層アプローチが実装がマルチホーミングを意識するようにする「輸送」プロトコルのセットに制限されることに注意してください。 多くの場合、システムのマルチホーミング能力において、未知であることの「輸送」プロトコルがあるでしょう、UDPの上で組立てられたアプリケーションなどのように。 また、セキュリティの粒状問題の影響を理解するために、人は、そのようなアプリケーション/プロトコルがどのように扱われるかを理解する必要があるでしょう。
A property of transport granularity is that the amount of work performed by a legitimate host is proportional to the number of transport connections it creates that uses the multihoming support, since each such connection would require some multihoming signaling. And the same is true for the attacker. This means that an attacker could presumably do a premeditated attack for all TCP connections to port 80 from A to B, by setting up 65,536 (for all TCP source port numbers) connections to server B and causing B to think those connections should be directed to the attacker and keeping those TCP connections open. Any attempt to make legitimate communication more efficient (e.g., by being able to signal for multiple transport connections at a time) would provide as much relative benefit for an attacker as the legitimate hosts.
輸送粒状の特性は正統のホストによって実行された仕事量がマルチホーミングサポートを使用するそれが創造する輸送の接続の数に比例しているということです、そのような各接続が何らかのマルチホーミングシグナリングを必要とするでしょう、したがって。 そして、攻撃者にとって、同じくらいは本当です。 これは、すべてのTCP接続がAからBまで80を移植するようにおそらく、攻撃者が計画的な攻撃ができたことを意味します、6万5536(すべてのTCPソースポート番号のための)の接続をサーバBにセットアップして、Bが攻撃者に向けられるべきであり、それらのTCP接続を開くように保つそれらの接続を考えることを引き起こすことによって。 正統のコミュニケーションをより効率的に(例えば、一度に複数の輸送の接続のために合図できるのによる)するどんな試みも正統のホストと攻撃者にとっての同じくらい多くの相対的な利益を提供するでしょう。
Nordmark & Li Informational [Page 21] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
NordmarkとIPv6マルチホーミングソリューション2005年10月への李情報[21ページ]のRFC4218Threats
The issue isn't only about the space (granularity), but also about the lifetime component in the results of a multihoming request. In a transport-layer approach, the multihoming state would presumably be destroyed when the transport state is deleted as part of closing the connection. But an IP-layer approach would have to rely on some timeout or garbage collection mechanisms, perhaps combined with some new explicit signaling, to remove the multihoming state. The coupling between the connection state and multihoming state in the transport-layer approach might make it more expensive for the attacker, since it needs to keep the connections open.
問題は、スペース(粒状)だけに関してありませんが、マルチホーミング要求の結果における生涯コンポーネントに関してもあります。 トランスポート層アプローチでは、輸送状態が接続を終える一部として削除されるとき、おそらく、マルチホーミング状態は破壊されるでしょう。 しかし、IP-層のアプローチは、マルチホーミング状態を取り除くために恐らく何らかの新しい明白なシグナリングに結合されたいくらかのタイムアウトかガーベージコレクションメカニズムを当てにしなければならないでしょう。 トランスポート層アプローチにおける接続州とマルチホーミング状態の間のカップリングで攻撃者には、より高価になるかもしれません、接続を開くように保つのが必要であるので。
In summary, there are issues we don't yet understand well about granularity and reuse of the multihoming state.
概要には、私たちがマルチホーミング状態の粒状と再利用に関してまだよく理解していない問題があります。
6. Movement Implications?
6. 動き含意?
In the case when nothing moves around, we have a reasonable understanding of the security requirements. Something that is on the path can be a MITM in today's Internet, and a multihoming solution doesn't need to make that aspect any more secure.
何も動き回らないときの場合では、私たちはセキュリティ要件の合理的な理解を持っています。 経路にある何かが今日のインターネットのMITMであるかもしれません、そして、マルチホーミング解決で、その局面はそれ以上安全になる必要はありません。
But it is more difficult to understand the requirements when hosts are moving around. For instance, a host might be on the path for a short moment in time by driving by an 802.11 hotspot. Would we or would we not be concerned if such a drive-by (which many call a "time-shifting" attack) would result in the temporarily on-path host being able to act as a MITM for future communication? Depending on the solution, this might be possible if the attacker causes a multihoming state to be created in various peer hosts while the attacker was on the path, and that state remained in the peers for some time.
しかし、ホストが動き回っているとき、要件を理解しているのは、より難しいです。 例えば、ホストは、時間内に短い少しの間、経路に802.11ホットスポットを通り過ぎることによって、いるかもしれません。 または、私たち、近くそのようなドライブ(多くが「タイム・シフト」攻撃を呼ぶ)が将来のコミュニケーションのためのMITMとして機能できる一時経路のホストをもたらすなら、私たちは関係がないでしょうか? ソリューションによって、攻撃者が様々な同輩ホストにマルチホーミング状態を創設させるなら、攻撃者が経路にいて、その状態がしばらく同輩に残っていた間、これは可能であるかもしれません。
The answer to this question doesn't seem to be obvious even in the absence of any new multihoming support. We don't have much experience with hosts moving around that are able to attack things as they move. In Mobile IPv6 [MIPv6] a conservative approach was taken that limits the effect of such drive-by attacks to the maximum lifetime of the binding, which is set to a few minutes.
この質問の答えはどんな新しいマルチホーミングサポートがないときでさえ明白であるように思えません。 私たちには、移行するときものを攻撃できる動き回るホストの多くの経験がありません。 モバイルIPv6[MIPv6]では、数分に設定される結合の最大の生涯までそのような通り過ぎている攻撃の効果を制限する保守的なアプローチを取りました。
With multihoming support the issue gets a bit more complicated because we explicitly want to allow a host to be present at multiple locators at the same time. Thus, there might be a need to distinguish between the host moving between different locators, and the host sending packets with different source locators because it is present at multiple locators without any topological movement.
マルチホーミングサポートで、ホストが同時に複数のロケータに出席しているのを明らかに許したいと思うので、問題はもう少し複雑になります。 したがって、それが複数のロケータに少しも位相的な運動なしで存在しているので、異なったロケータの間でホスト移行を見分けて、異なったソースロケータでホスト送付パケットを見分ける必要があるかもしれません。
Nordmark & Li Informational [Page 22] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
NordmarkとIPv6マルチホーミングソリューション2005年10月への李情報[22ページ]のRFC4218Threats
Note that the multihoming solutions that have been discussed range from such "drive-by" attacks being impossible (for instance, due to a strong binding to a separate identifier as in HIP, or due to reliance on the relative security of the DNS for forward plus reverse lookups in NOID), to systems that are first-come/first-serve (WIMP being an example with a separate ID space, a MAST approach with a PBK being an example without a separate ID space) that allow the first host that uses an ID/address to claim it without any time limit.
そのようなものからの議論された範囲であるマルチホーミング解決が不可能な(例えばHIPか、NOIDの前進の、そして、逆のルックアップのためのDNSの相対的なセキュリティへの信用のため別々の識別子との強い結合のため)攻撃を「通り過ぎる」と述べてください; 最初に、最初に来ている/サーブ(PBKに関するMASTアプローチが別々のIDスペースがなければ例であり別々のIDスペースがある例であるWIMP)であるシステムに、第1代ID/アドレスを使用するホストはそれから少しもタイムリミットなしでそれを要求できます。
7. Other Security Concerns
7. 他の安全上の配慮
The protocol mechanisms added as part of a multihoming solution shouldn't introduce any new DoS in the mechanisms themselves. In particular, care must be taken not to:
マルチホーミング解決の一部がメカニズム自体で少しの新しいDoSも導入するべきでないので、プロトコルメカニズムは加えました。 特に、以下のことのために注意しなければなりません。
- create state on the first packet in an exchange, since that could
result in state consumption attacks similar to the TCP SYN
flooding attack.
- 交換における最初のパケットに状態を創設してください、それがTCP SYNフラッディング攻撃と同様の州の消費攻撃をもたらすかもしれないので。
- perform much work on the first packet in an exchange (such as
expensive verification)
- 交換における最初のパケットに対する多くの仕事をしてください。(高価な検証などの)
There is a potential chicken-and-egg problem here, because potentially one would want to avoid doing work or creating state until the peer has been verified, but verification will probably need some state and some work to be done. Avoiding any work does not seem possible, but good protocol design can often delay state creation until verification has been completed.
潜在的因果関係の分からない問題がここにあります、同輩が確かめられましたが、検証がたぶん何らかの状態といくらかのやるべき仕事を必要とするまで、人は、する仕事か状態を創設するのを潜在的に避けたがっているでしょう、したがって。 どんな仕事も避けるのは可能に思えませんが、検証が終了するまで、良いプロトコルデザインは州の作成をしばしば遅らせることができます。
A possible approach that solutions might investigate is to defer verification until there appears to be two different hosts (or two different locators for the same host) that want to use the same identifier. In such a case one would need to investigate whether a combination of impersonation and DoS attack can be used to prevent the discovery of the impersonation.
ソリューションが調査するかもしれない可能なアプローチは同じ識別子を使用したがっている2人の異なったホスト(または、同じホストのための2つの異なったロケータ)が現れるだろうまで検証を延期することです。 このような場合には人は、ものまねの発見を防ぐのにものまねとDoS攻撃の組み合わせを使用できるかどうか調査する必要があるでしょう。
Another possible approach is to first establish communications, and then perform verification in parallel with normal data transfers. Redirection would only be permitted after verification was complete, but prior to that event, data could transfer in a normal, non-multihomed manner.
別の可能なアプローチは、最初にコミュニケーションを確立して、次に、正常なデータ転送と平行して検証を実行することです。 検証が完全になった後にリダイレクションは受入れられるだけでしょうが、そのイベントの前に、データは正常で、非「マルチ-家へ帰」っている方法で移されることができるでしょう。
Finally, the new protocol mechanisms should be protected against spoofed packets, at least from off-path sources, and replayed packets.
最終的に、新しいプロトコルメカニズムは偽造しているパケットに対して少なくともオフ経路ソースと、再演されたパケットから保護されるべきです。
Nordmark & Li Informational [Page 23] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
NordmarkとIPv6マルチホーミングソリューション2005年10月への李情報[23ページ]のRFC4218Threats
8. Security Considerations
8. セキュリティ問題
In section 3, the document presented existing protocol-based redirection attacks. But there are also non-protocol redirection attacks. An attacker that can gain physical access to one of
セクション3では、ドキュメントは既存のプロトコルベースのリダイレクション攻撃を示しました。 しかし、また、非プロトコルリダイレクション攻撃があります。 それが1つへの物理的なアクセスを得ることができる攻撃者
- the copper/fiber somewhere in the path,
- 経路のどこかの銅/ファイバー
- a router or L2 device in the path, or
- または経路のルータかL2デバイス。
- one of the end systems
- エンドシステムの1つ
can also redirect packets. This could be possible, for instance, by physical break-ins or by bribing staff that have access to the physical infrastructure. Such attacks are out of scope of this discussion, but are worth keeping in mind when looking at the cost for an attacker to exploit any protocol-based attacks against multihoming solutions; making protocol-based attacks much more expensive to launch than break-ins/bribery type of attacks might be overkill.
また、パケットを向け直すことができます。 例えば、これは物理的な不法侵入か物的なインフラに近づく手段を持っているスタッフを贈賄することによって、可能であるかもしれません。 そのような攻撃は、この議論の範囲の外にありますが、攻撃者がマルチホーミング解決に対してどんなプロトコルベースの攻撃も利用するように費用を見るとき、覚えておく価値があります。 プロトコルベースの攻撃をして、攻撃の不法侵入/贈収賄タイプよりはるかに高価な着手は過剰殺傷であるかもしれません。
9. Acknowledgements
9. 承認
This document was originally produced by a MULTI6 design team consisting of (in alphabetical order): Iljitsch van Beijnum, Steve Bellovin, Brian Carpenter, Mike O'Dell, Sean Doran, Dave Katz, Tony Li, Erik Nordmark, and Pekka Savola.
このドキュメントがそうであった、元々生産されたa MULTI6は(アルファベット順に)チームの成ることを設計します: IljitschはBeijnum、スティーブBellovin、ブライアンCarpenter、マイク・オデル、ショーン・ドラン、デーヴ・キャッツ、トニー・李、エリックNordmark、およびペッカSavolaをバンに積みます。
Much of the awareness of these threats come from the work on Mobile IPv6 [MIPv6, NIKANDER03, AURA02].
これらの脅威の認識の多くがモバイルIPv6[MIPv6、NIKANDER03、AURA02]への作業から来ます。
As the document has evolved, the MULTI6 WG participants have contributed to the document. In particular: Masataka Ohta brought up privacy concerns related to stable identifiers. The suggestion to discuss transport versus IP granularity was contributed by Marcelo Bagnulo, who also contributed text to Appendix B. Many editorial clarifications came from Jari Arkko.
ドキュメントが発展したとき、MULTI6 WG関係者はドキュメントに貢献しました。 特に: Masataka太田は安定した識別子に関連するプライバシーの問題を持って来ました。 IP粒状に対して輸送について議論する提案はマルセロBagnuloによって寄付されました。(また、BagnuloはManyの編集の明確化がヤリArkkoから来させたAppendix B.にテキストを寄付しました)。
Nordmark & Li Informational [Page 24] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
NordmarkとIPv6マルチホーミングソリューション2005年10月への李情報[24ページ]のRFC4218Threats
10. Informative References
10. 有益な参照
[NSRG] Lear, E. and R. Droms, "What's In A Name: Thoughts from
the NSRG", Work in Progress, September 2003.
[NSRG] リア、E.、およびR.Droms、「名前には何がありますか?」 「NSRGからの考え」は進歩、2003年9月に働いています。
[MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility
Support in IPv6", RFC 3775, June 2004.
[MIPv6] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[AURA02] Aura, T. and J. Arkko, "MIPv6 BU Attacks and Defenses",
Work in Progress, March 2002.
[AURA02] 「MIPv6 BU攻撃とディフェンス」という香気、T.、およびJ.Arkkoは進歩、2002年3月に働いています。
[NIKANDER03] Nikander, P., T. Aura, J. Arkko, G. Montenegro, and E.
Nordmark, "Mobile IP version 6 Route Optimization
Security Design Background", Work in Progress, December
2003.
[NIKANDER03] Progress(2003年12月)のNikanderとP.とT.AuraとJ.Arkko、G.モンテネグロとE.Nordmark、「モバイルIPバージョン6Route Optimization Security Design Background」Work。
[PAXSON01] V. Paxson, "An Analysis of Using Reflectors for
Distributed Denial-of-Service Attacks", Computer
Communication Review 31(3), July 2001.
[PAXSON01]V.パクソン、「分散型サービス妨害攻撃のための使用反射鏡の分析」、コンピュータコミュニケーションレビュー31(3)、2001年7月。
[INGRESS] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP
Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[イングレス]のファーガソン、P.、およびD.Senieは「以下をフィルターにかけるイングレスをネットワークでつなぎます」。 「IP Source Address Spoofingを使うサービス妨害Attacksを破ります」、BCP38、RFC2827、2000年5月。
[SCTP] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[SCTP] スチュワート、R.、シェ、Q.、K.の、そして、鋭いMorneault、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、および「ストリーム制御伝動プロトコル」、RFC2960(2000年10月)対パクソン
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001.
[RFC3041] NartenとT.とR.Draves、「IPv6"での状態がないアドレス自動構成のためのプライバシー拡大、RFC3041、2001年1月。」
[DNS-THREATS] Atkins, D. and R. Austein, "Threat Analysis of the
Domain Name System (DNS)", RFC 3833, August 2004.
[DNS-脅威] アトキンスとD.とR.Austein、「ドメインネームシステム(DNS)の脅威分析」、RFC3833、2004年8月。
[FYI18] Malkin, G., "Internet Users' Glossary", RFC 1983,
August 1996.
[FYI18] マルキン、G.、「インターネットユーザの用語集」、RFC1983、1996年8月。
[ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The
Addition of Explicit Congestion Notification (ECN) to
IP", RFC 3168, September 2001.
[電子証券取引ネットワーク] Ramakrishnan、K.、フロイド、S.、およびD.黒、「明白な混雑通知のIPへの追加(電子証券取引ネットワーク)」、RFC3168(2001年9月)。
[OWNER] Nikander, P., "Denial-of-Service, Address Ownership,
and Early Authentication in the IPv6 World", Security
Protocols 9th International Workshop, Cambridge, UK,
April 25-27 2001, LNCS 2467, pages 12-26, Springer,
2002.
Securityプロトコル第9国際Workshop、ケンブリッジイギリス(2001LNCS2467 4月25日〜27日)は、[OWNER]Nikanderと、P.と、「サービス妨害、アドレス所有権、およびIPv6世界での早めの認証」と呼び出します。12-26、Springer、2002。
Nordmark & Li Informational [Page 25] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
NordmarkとIPv6マルチホーミングソリューション2005年10月への李情報[25ページ]のRFC4218Threats
[RFC1948] Bellovin, S., "Defending Against Sequence Number
Attacks", RFC 1948, May 1996.
[RFC1948]Bellovin S. (「一連番号攻撃に対して防御すること」でのRFC1948)は1996がそうするかもしれません。
[PBK] Scott Bradner, Allison Mankin, Jeffrey Schiller, "A
Framework for Purpose-Built Keys (PBK)", Work in
Progress, June 2003.
[PBK] スコット・ブラドナー、アリソン・マンキン、ジェフリー・シラー、「特注のキー(PBK)のためのフレームワーク」は進歩、2003年6月に働いています。
[NOID] Erik Nordmark, "Multihoming without IP Identifiers",
Work in Progress, July 2004.
「IP識別子のないマルチホーミング」という[NOID]エリックNordmarkは進歩、2004年7月に働いています。
[HIP] Pekka Nikander, "Considerations on HIP based IPv6
multi-homing", Work in Progress, July 2004.
[HIP]ペッカNikander、「HIPの上の問題はIPv6マルチホーミングを基礎づけた」Progress、2004年7月のWork。
[WIMP] Jukka Ylitalo, "Weak Identifier Multihoming Protocol
(WIMP)", Work in Progress, June 2004.
「弱い識別子マルチホーミングプロトコル(弱虫)」という[弱虫]ユッカYlitaloは進歩、2004年6月に働いています。
[CBHI] Iljitsch van Beijnum, "Crypto Based Host Identifiers",
Work in Progress, February 2004.
[CBHI]Iljitschは2004年2月にProgressでBeijnum、「暗号のベースのホスト識別子」、Workをバンに積みます。
[TCPSECURE] M. Dalal (ed), "Transmission Control Protocol security
considerations", Work in Progress, November 2004.
[TCPSECURE]M.Dalal(教育)、「通信制御プロトコルセキュリティ問題」、Progress、2004年11月のWork。
Nordmark & Li Informational [Page 26] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
NordmarkとIPv6マルチホーミングソリューション2005年10月への李情報[26ページ]のRFC4218Threats
Appendix A: Some Security Analysis
付録A: 何らかの証券分析
When looking at the proposals that have been made for multihoming solutions and the above threats, it seems like there are two separable aspects of handling the redirection threats:
マルチホーミング解決と上の脅威のためにされた提案を見るとき、リダイレクションの脅威を扱う2つの分離できる局面があるように見えます:
- Redirection of existing communication
- 既存のコミュニケーションのリダイレクション
- Redirection of an identity before any communication
- どんなコミュニケーションの前のアイデンティティのリダイレクション
This seems to be related to the fact that there are two different classes of use of identifiers. One use is for:
これは識別子で役に立つ2つの異なったクラスがあるという事実に関連したように思えます。 使用がある1:
o Initially establishing communication; looking up an FQDN to find
something that is passed to a connect() or sendto() API call.
o 初めは、コミュニケーションを確立します。 aに通過される何かを見つけるためにFQDNを見上げて、()かsendto()API呼び出しを接続してください。
o Comparing whether a peer entity is the same peer entity as in some
previous communication.
o 同輩実体が前の何らかのコミュニケーションのように同じ同輩実体であるか否かに関係なく、比較すること。
o Using the identity of the peer for future communication
("callbacks") in the reverse direction, or to refer to a 3rd party
("referrals").
o 反対の方向による将来のコミュニケーション(「コールバック」)か3番目のパーティー(「紹介」)について言及するのに同輩のアイデンティティを使用します。
The other use of identifiers is as part of being able to redirect existing communication to use a different locator.
異なったロケータを使用するために既存のコミュニケーションを向け直すことができる一部として識別子のもう片方の使用はあります。
The first class of use seems to be related to something about the ownership of the identifier; proving the "ownership" of the identifier should be sufficient in order to be authorized to control which locators are used to reach the identifier.
使用の一流は識別子の所有権に関して何かに関連したように思えます。 識別子の「所有権」を立証するのは、どのロケータが識別子に達するのに使用されるかを制御するのが認可されるために十分であるべきです。
The second class of use seems to be related to something more ephemeral. In order to redirect the existing communication to some other locator, it seems to be sufficient to prove that the entity is the same as the one that initiated the communication. One can view this as proving the ownership of some context, where the context is established around the time when the communication is initiated.
使用の二等は何かよりはかないものに関連したように思えます。 ある他のロケータに既存のコミュニケーションを向け直すために、それは実体がコミュニケーションを開始したものと同じであると立証するために十分であるように思えます。 人は文脈が時コミュニケーションが開始される頃確立される何らかの文脈の所有権を立証するとこれをみなすことができます。
Preventing unauthorized redirection of existing communication can be addressed by a large number of approaches that are based on setting up some form of security material at the beginning of communication, and later using the existence of that material for one end to prove to the other that it remains the same. An example of this is Purpose Built Keys [PBK]. One can envision different approaches for such schemes with different complexity, performance, and resulting
それが同じままで残っているともう片方に立証するために個人的には終わる、コミュニケーションの始めに何らかの形式のセキュリティの材料をセットアップするのに基づいていて、後でその材料の存在を使用する多くのアプローチで既存のコミュニケーションの権限のないリダイレクションを防ぐのを扱うことができます。 この例はPurpose Builtキーズ[PBK]です。 人はそのような体系のための異なった複雑さ、性能、および結果になるのに関する異なるアプローチを思い描くことができます。
Nordmark & Li Informational [Page 27] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
NordmarkとIPv6マルチホーミングソリューション2005年10月への李情報[27ページ]のRFC4218Threats
security such as anonymous Diffie-Hellman exchange, the reverse hash chains presented in [WIMP], or even a clear-text token exchanged at the initial communication.
[WIMP]で寄贈された、匿名のディフィー-ヘルマンの交換、逆などのセキュリティハッシュチェーン、または初期のコミュニケーションで交換されたクリアテキストトークンさえ。
However, the mechanisms for preventing unauthorized use of an identifier can be quite different. One way to prevent premeditated redirection is to simply not introduce a new identifier name space, and instead to rely on existing name space(s), a trusted third party, and a sufficiently secure way to access the third party, as in [NOID]. Such an approach relies on the third party (DNS in the case of NOID) as the foundation. In terms of multihoming state creation, in this case premeditated redirection is as easy or as hard as redirecting an IP address today. Essentially, this relies on the return-routability check associated with a roundtrip of communication, which verifies that the routing system delivers packets to the IP address in question.
しかしながら、識別子の無断使用を防ぐためのメカニズムは全く異なっている場合があります。 計画的なリダイレクションを防ぐ1つの方法は既存の名前スペース、信頼できる第三者機関、および第三者にアクセスする十分安全な方法を当てにするために代わりに新しい識別子名前スペースを絶対に導入しないことです、[NOID]のように。 そのようなアプローチは基礎として第三者(NOIDの場合におけるDNS)に頼ります。 マルチホーミング州の作成では、計画的なリダイレクションは、この場合、今日IPアドレスを転送するのと同じくらい簡単であるか、または同じくらい固いです。 本質的には、これはルーティングシステムが問題のIPアドレスにパケットを提供することを確かめるコミュニケーションの往復旅行に関連しているリターン-routabilityチェックに依存します。
Alternatively, one can use the crypto-based identifiers such as in [HIP] or crypto-generated addresses as in [CBHI], which both rely on public-key crypto, to prevent premeditated attacks. In some cases it is also possible to avoid the problem by having one end of the communication use ephemeral identifiers as the initiator does in [WIMP]. This avoids premeditated redirection by detecting that some other entity is using the same identifier at the peer and switching to use another ephemeral ID. While the ephemeral identifiers might be problematic when used by applications, for instance due to callbacks or referrals, note that for the end that has the ephemeral identifier, one can skirt around the premeditated attacks (assuming the solution has a robust way to pick a new identifier when one is in use/stolen).
あるいはまた、1つは[CBHI]のように[HIP]や暗号生成アドレスなどの暗号ベースの識別子を使用できます。(ともに、それは、計画的な攻撃を防ぐために公開鍵暗号を当てにします)。 いくつかの場合、また、創始者が[WIMP]でするようにコミュニケーションの片端にはかない識別子を使用させることによって問題を避けるのも可能です。 これは、同輩で同じ識別子を使用して、別のはかないIDを使用するために切り替わりながら、ある他の実体がそうである検出するのによる計画的なリダイレクションを避けます。 アプリケーションで使用されると、はかない識別子は問題が多いかもしれませんが、例えば、コールバックか紹介のため、はかない識別子を持っている終わりに1つが計画的な攻撃(ソリューションには1つが使用中であるか盗まれるとき新しい識別子を選ぶ強健な方法があると仮定する)を回避できることに注意してください。
Assuming the problem can't be skirted by using ephemeral identifiers, there seem to be 3 types of approaches that can be used to establish some form of identity ownership:
問題を仮定するのにはかない識別子を使用することによって、周囲を通らされることができません、と何らかのフォームのアイデンティティ所有権を証明するのに使用できるアプローチのタイプは3になるようにそこで思えます:
- A trusted third party, which states that a given identity is
reachable at a given set of locators, so the endpoint reached at
one of this locators is the owner of the identity.
- 終点にこのロケータの1つで達して、信頼できる第三者機関(与えられたアイデンティティが与えられたセットのロケータで届いていると述べる)はアイデンティティの所有者です。
- Crypto-based identifiers or crypto-generated addresses where the
public/private key pair can be used to prove that the identifier
was generated by the node knowing the private key (or by another
node whose public key hashes to the same value)
- 識別子がノードの知るのによる秘密鍵であると生成されたと立証するのに公衆/秘密鍵組を使用できる暗号ベースの識別子か暗号生成アドレス(または同じくらいへのハッシュが公開鍵を評価する別のノードで)
- A static binding, as currently defined in IP, where you trust that
the routing system will deliver the packets to the owner of the
locator, and since the locator and the identity are one, you prove
identity ownership as a sub-product.
- 静的な結合、現在あなたが、ルーティングシステムがロケータの所有者にパケットを提供すると信じるIPで定義されて、ロケータとアイデンティティが1であるので、あなたはサブ製品としてアイデンティティ所有権を立証します。
Nordmark & Li Informational [Page 28] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
NordmarkとIPv6マルチホーミングソリューション2005年10月への李情報[28ページ]のRFC4218Threats
A solution would need to combine elements that provide protection against both premeditated and ongoing communication redirection. This can be done in several ways, and the current set of proposals do not appear to contain all useful combinations. For instance, the HIP CBID property could be used to prevent premeditated attacks, while the WIMP hash chains could be used to prevent on-going redirection. And there are probably other interesting combinations.
ソリューションは、計画的なものと同様に進行中のコミュニケーションリダイレクションに対する保護を提供する要素を結合する必要があるでしょう。 これはいくつかの方法で終わることができます、そして、現在の提案はすべての役に立つ組み合わせを含むように見えません。 例えば、計画的な攻撃を防ぐのにHIP CBIDの特性を使用できました、継続しているリダイレクションを防ぐのにWIMPハッシュチェーンを使用できましたが。 そして、たぶん、他のおもしろい組み合わせがあります。
A related, but perhaps separate aspect, is whether the solution provides for protection against man-in-the-middle attacks with on-path attackers. Some schemes, such as [HIP] and [NOID] do, but given that an on-path attacker can see and modify the data traffic whether or not it can modify the multihoming signaling, this level of protection seems like overkill. Protecting against on-path MITM for the data traffic can be done separately using IPsec, TLS, etc.
関連しますが、恐らく別々の局面はソリューションが経路の攻撃者と共に介入者攻撃に対する保護に備えるかどうかということです。 [HIP]や[NOID]などのいくつかの体系が見えますが、それがマルチホーミングシグナリングを変更できるか否かに関係なく、経路の攻撃者がデータ通信量を見て、変更できるなら、このレベルの保護は過剰殺傷のように見えます。 別々にIPsec、TLSなどを使用するのを経路のMITMからデータ通信量に守ることができます。
Finally, preventing third party DoS attacks is conceptually simpler; it would suffice to somehow verify that the peer is indeed reachable at the new locator before sending a large number of packets to that locator.
最終的に、第三者DoS攻撃を防ぐのは概念的により簡単です。 それは、多くのパケットをそのロケータに送る前に本当に、同輩が新しいロケータで届いていることをどうにか確かめるために十分でしょう。
Just as the redirection attacks are conceptually prevented by proving at some level the ownership of the identifier or the ownership of the communication context, third party DoS attacks are conceptually prevented by showing that the endpoint is authorized to use a given locator.
ちょうどリダイレクション攻撃がある意味で識別子の所有権かコミュニケーション文脈の所有権を立証することによって概念的に防がれるように、終点が与えられたロケータを使用するのが認可されるのを示すことによって、第三者DoS攻撃は概念的に防がれます。
The currently known approaches for showing such authorization are:
そのような承認を示しているための現在知られているアプローチは以下の通りです。
- Return routability. That is, if an endpoint is capable of
receiving packets at a given locator, it is because he is
authorized to do so. This relies on routing being reasonably hard
to subvert to deliver packets to the wrong place. While this
might be the case when routing protocols are used with reasonable
security mechanisms and practices, it isn't the case on a single
link where ARP and Neighbor Discovery can be easily spoofed.
- routabilityを返してください。 すなわち、終点が与えられたロケータでパケットを受けることができるならそれは彼がそうするのに権限を与えられるからです。 これは間違った場所にパケットを提供するために合理的に打倒しにくいルーティングを当てにします。 ルーティング・プロトコルが妥当なセキュリティー対策と習慣と共に使用されるとき、これはそうであるかもしれませんが、それは容易にARPとNeighborディスカバリーを偽造することができる単一のリンクの上のケースではありません。
- Trusted third party. A third party establishes that a given
identity is authorized to use a given set of locators (for
instance the DNS).
- 信頼できる第三者機関。 第三者は、与えられたアイデンティティが与えられたセットのロケータ(例えば、DNS)を使用するのが認可されるのを確証します。
Nordmark & Li Informational [Page 29] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
NordmarkとIPv6マルチホーミングソリューション2005年10月への李情報[29ページ]のRFC4218Threats
Authors' Addresses
作者のアドレス
Erik Nordmark Sun Microsystems, Inc. 17 Network Circle Mountain View, CA 94025 USA
エリックNordmarkサン・マイクロシステムズ・インク17ネットワーク円のカリフォルニア94025マウンテンビュー(米国)
Phone: +1 650 786 2921 Fax: +1 650 786 5896 EMail: erik.nordmark@sun.com
以下に電話をしてください。 +1 650 786、2921Fax: +1 5896年の650 786メール: erik.nordmark@sun.com
Tony Li EMail: Tony.Li@tony.li
トニー李EMail: Tony.Li@tony.li
Nordmark & Li Informational [Page 30] RFC 4218 Threats to IPv6 Multihoming Solutions October 2005
NordmarkとIPv6マルチホーミングソリューション2005年10月への李情報[30ページ]のRFC4218Threats
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Nordmark & Li Informational [Page 31]
Nordmarkと李Informationalです。[31ページ]
一覧
スポンサーリンク
