Threats relating to IPv6 multihoming solutions
draft-nordmark-multi6-threats-02
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2005-01-02
|
02 | (System) | Document has expired |
2004-10-28
|
02 | David Kessens | State Changes to Dead from IESG Evaluation by David Kessens |
2004-10-27
|
02 | David Kessens | Removed from agenda for telechat - 2004-10-28 by David Kessens |
2004-10-27
|
02 | Russ Housley | [Ballot comment] Comments include ones from SecDir review by Rob Austein. The title and abstract are a bit confusing unless one already understands … [Ballot comment] Comments include ones from SecDir review by Rob Austein. The title and abstract are a bit confusing unless one already understands the subject of the document. The document is really pretty specific to issues surrounding locator/identifier split and redirection attacks. The document says: : : identifier - an IP layer identifier for an IP layer endpoint : (stack name in [NSRG]). The transport endpoint 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 : interfaces per stack/per host. : s/interfaces/identifiers/ ? Probably not, but the text is a bit confusing, since the very next sentence says that identifiers aren't associated with an interface. Please clarify. In section 4.1, please be blunt in pointing out the man-in-the- middle potential in all of the redirection attacks. |
2004-10-27
|
02 | Russ Housley | [Ballot comment] Comments include ones from SecDir review by Rob Austein. The title and abstract are a bit confusing unless one already understands … [Ballot comment] Comments include ones from SecDir review by Rob Austein. The title and abstract are a bit confusing unless one already understands the subject of the document. The document is really pretty specific to issues surrounding locator/identifier split and redirection attacks. The document says: : : identifier - an IP layer identifier for an IP layer endpoint : (stack name in [NSRG]). The transport endpoint 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 : interfaces per stack/per host. : s/interfaces/identifiers/ ? Probably not, but the text is a bit confusing, since the very next sentence says that identifiers aren't associated with an interface. Please clarify. In section 4.1, please be blunt in pointing out the man-in-the- middle potential in all of the redirection attacks. |
2004-10-27
|
02 | Russ Housley | [Ballot discuss] In addition to the TBD already identified by Scott, I have a few other concerns. This document is, perhaps necessarily, somewhat … [Ballot discuss] In addition to the TBD already identified by Scott, I have a few other concerns. This document is, perhaps necessarily, somewhat incomplete. It is difficult to do a real analysis without pinning down specific protocol details, which this draft cannot do given the topic it is trying to cover. It includes a general analysis of redirection attacks based on multihoming solutions that allow locator changes. As such, it should point out that additional work is needed, especially in the following areas: 1) If we were to make the split between locators and identifiers, then we probably want to tie most application security mechanisms to the identifier, not to the locator. Therefore, work is needed to understand how attacks on the identifier mechanism affect security, especially, in my mind, attacks on any mechanism(s) that bind locators to identifiers. 2) Does multicast make matters worse? It usually does. 3) Connectionless transport protocols need more attention. They are already difficult to secure, even without a locator/identifier split. |
2004-10-27
|
02 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded for Russ Housley by Russ Housley |
2004-10-27
|
02 | Ted Hardie | [Ballot discuss] None of these issues are reasons to block this document, but the combination was enough to put this into DISCUSS rather than Comment. … [Ballot discuss] None of these issues are reasons to block this document, but the combination was enough to put this into DISCUSS rather than Comment. After we've had a chance to discuss them, I anticipate shifting to no-ob or yes. In section 2., the draft says: address - an IP layer name that contains both topological significance and acts as a unique identifier for an interface. Is it important that it be a unique identifier? I know of cases where the same IP address is bound both to an ethernet interface and a tunnel interface. Those interfaces are unique at some layer, just not at the IP layer. I'm not sure the distinction is worth raising here, in the terminology section, but I also wasn't sure how important "unique" was to the authors. In section 3.1, the draft says: Applications that use security mechanisms, such as IPsec or TLS, with mutual authentication have the ability to "bind" the FQDN to the cryptographic keying material, thus compromising the DNS and/or the routing system can at worst cause the packets to be dropped or delivered to an entity which does not posses the keying material. The binding isn't always to the FQDN; it can be to an address. Could this be rephrased as: Applications that use mutually authenticating 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. This section also uses "class of applications", where I believe they are talking about "class of security configurations for applications". The same application (or class of applications) could employ each of these. Do the authors consider "leap of faith" trust arrangements to fall into their 5th category? They certainly lack strong identity, but they seem to provide assurance that a particular peer is the same peer over a number of interactions; there may be no assurance as to who that peer is with reference to an external system, but that may not be required. 4.1.2 touches on this, but it wasn't clear to me whether these trust arrangements fell under 5 or were some other category. In Section 7, the draft says: 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. Does this mean simultaneous hosts/locators? I'm concerned that a combination here of a DoS and impersonation could make simultaneous appearance rare: A is talking to B; X DoS'es A while impersonating A to B; B sees a "new A", but no longer has the ability to verifiy the first A. |
2004-10-27
|
02 | Ted Hardie | [Ballot Position Update] New position, Discuss, has been recorded for Ted Hardie by Ted Hardie |
2004-10-25
|
02 | Scott Hollenbeck | [Ballot comment] Missing IANA Considerations. |
2004-10-25
|
02 | Scott Hollenbeck | [Ballot discuss] Section 3.1 asks this unresolved question: [TBD: Does one-way authentication, without mutual authentication, add a different class of applications?] This should be cleaned … [Ballot discuss] Section 3.1 asks this unresolved question: [TBD: Does one-way authentication, without mutual authentication, add a different class of applications?] This should be cleaned up before IESG review. |
2004-10-25
|
02 | Scott Hollenbeck | [Ballot Position Update] Position for Scott Hollenbeck has been changed to Discuss from Undefined by Scott Hollenbeck |
2004-10-25
|
02 | Scott Hollenbeck | [Ballot Position Update] New position, Undefined, has been recorded for Scott Hollenbeck by Scott Hollenbeck |
2004-10-21
|
02 | David Kessens | [Ballot comment] The draft doesn't have an IANA Considerations section, which should be a null one if present. Also Appendix A will need to be … [Ballot comment] The draft doesn't have an IANA Considerations section, which should be a null one if present. Also Appendix A will need to be removed. |
2004-10-21
|
02 | David Kessens | Area acronymn has been changed to ops from gen |
2004-10-21
|
02 | David Kessens | [Ballot Position Update] New position, Yes, has been recorded for David Kessens |
2004-10-21
|
02 | David Kessens | Ballot has been issued by David Kessens |
2004-10-21
|
02 | David Kessens | Created "Approve" ballot |
2004-10-21
|
02 | (System) | Ballot writeup text was added |
2004-10-21
|
02 | (System) | Last call text was added |
2004-10-21
|
02 | (System) | Ballot approval text was added |
2004-10-21
|
02 | David Kessens | Area acronymn has been changed to ops from gen |
2004-10-21
|
02 | David Kessens | Area acronymn has been changed to ops from gen |
2004-10-21
|
02 | David Kessens | Draft Added by David Kessens in state IESG Evaluation |
2004-06-09
|
02 | (System) | New version available: draft-nordmark-multi6-threats-02.txt |
2004-06-04
|
01 | (System) | New version available: draft-nordmark-multi6-threats-01.txt |
2003-10-22
|
00 | (System) | New version available: draft-nordmark-multi6-threats-00.txt |