[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A method to prevent DoS in IPv6 DAD and Mobile IPv6

Wow! I came up with the same scheme, although as part of a slightly more general mechanism.
I've only been discussing with a couple of folks including Claude Castellucia and Erik Nordmark.
But your  message prompts me to send my stuff in as well. We should  talk in Minneapolis.
I had to name these things something, and based on the fact that what's important about them
is the fact that they are: statistically unique and cryptographically verifiable, I just called them
SUCV's. So we have SUCV identifiers and SUCV addresses. The latter are the ones you
mentioned in your previous note.

I attach my notes, although they are not yet complete nor in internet draft format.

The attachments are:

     1. my notes on pekka's address ownership, PBK and claude's privacy extension drafts
     2. proposal and thoughts on SUCV's

-gabriel
--
Gabriel Montenegro (Sun Microsystems Laboratories, Europe)
29, chemin du Vieux Chene         Email: gab@sun.com
38240 Meylan, FRANCE              Mobile: +33 673 99 56 62
Office: +33 476 18 80 45 (sun internal: x38045)
Fax:    +33 476 18 88 88
Notes on V6 address ownership problems http://search.ietf.org/internet-drafts/draft-nikander-ipng-address-ownership-00.txt * protection against hijacking of valid addresses requires cryptographic authorization for operations that modify routing (BU's, source routing, etc) * quoting from above draft: "Currently there exists no specified mechanism for proving address ownership in Internet-wide scale." Mini Proposal: * remaining use of redirect operations: they are only allowed with non-global addresses which are bound (via a cryptographically sound binding) to anonymous or pseudonymous addresses * the above constitues perhaps the only rule that operates by default, allowing any other more dangerous operation only if authorized by strong cryptographic mechanisms Notes on PBK http://search.ietf.org/internet-drafts/draft-bradner-pbk-frame-00.txt * temporary public/private pair * EID = hash(publicComponent) * Initiator sends EID to Responder * Initiator sends publicComponent to Responder Note This exchange must be secure, but it is an improvement over cookies. * Initiator sends (BU, EID)Priv to Responder Problems: * does NOT really address the address ownership problem of any publicly routable addresses * it is not specified how the EID and public component of the PK are sent by the initiator to the responder * preventing hijacking and MIM attacks depend on this sequence if not clearly specified * might as well make it secure: use HIP and its sequence Notes on simple privacy extension for Mobile IP v6 http://search.ietf.org/internet-drafts/draft-castelluccia-mobileip-privacy-00.txt What it hides: home address in the following two situations: * MN initiated traffic: hides home address from CN (a server?) and eavesdroppers * CN initiated traffic: hides home addr from eavesdropper (not from CN) What it does not hide: home address from initiating CN's when the MN is a server/responder Basics: * MN's instead of their home address use a 128 bit identifier called TMI * digest for TMI' = MD5 ( Home address | digest of TMI ) * define a new TLA (16 bits) for TMI address space * [why not SHA-1 (also required by IPSEC) given the collision resistance issues with MD5?] Works as follows: * mobile initiator * uses TMI as home address. * CN sends to TMI@COA (where the addr before the @ is carried within the home address option * mobile responder * "CN knows the MN's identity by definition" (?) * [Maybe not, if the CN can initiate to a HIP (or TMI) entity and resolve the COA by some other means.] * In this case, the MN can still hide its location (COA) by using a bi-directional tunnel with its HA and not sending any BU's to the CN. * traffic MN to CN would be of the form: homeAddr@TMI@COA * requires a new destination option to carry the real homeAddr * subsequent packets have just the TMI (essentially an SA), [so why not just use IPSEC]? Still has problems * TMI does not prevent hijacking as explained in the nikander draft on addr ownership * this is the problem our new default trust rule addresses (in conjunction with HIP) * There may be issues with its use of MD5: WeaknessInMd5 Proposal Given that: * The addr ownership problem is real. BU's and other exchanges which alter routing or tunneling open up DOS attacks. PBK attempts to solve these, but does not succeed for globally routable addresses. * Privacy concerns are also real, and the privacy extensions aim to solve this. * Neither of the above solves both at the same time, yet independently, both require non-trivial changes to BU's and other formats, as well as to the handling of SA's and IPSEC. The obvious solution is to address both: * Privacy * Address ownership In one common mechanism. I suggest it be based on HIP: * For all the cases at hand (v6 based) the HIP handshake provides for a very good and DOS-resistant sequence. * For new application layer cases (hinted at by PBK, and applicable to P2P, for example), the sequence must not be left up to the application. This may be easier to do with TCP in which existing frameworks could be extended (BEEP, TLS), but not immediately obvious how to accomplish it for UDP traffic. SCTP is another matter. -- GabrielMontenegro - 18 Mar, 2001 - 12:40:30 Statistical Uniqueness and Cryptographic Verifiability The Need for a Common Solution The idea is to propose one common mechanism that can solve two problems dealt with in AddressOwnershipAndPrivacyForMipV6: * address ownership: Given the different ways of altering routing information, and in particular, binding updates received at a correspondent node, how does this CN decide if it should heed it? * privacy for MIPv6: Mobile IP allows a node to keep the same home address as it changes its point of attachment to the network (care-of address or COA). There are proposals to solve each of the above. However, these proposals require modifying Mobile IP v6 and/or IPSEC separately. Instead, this is an attempt at using a common mechanism to achieve both of those goals. This note does not look at the problem from the point of view of practical Mobile IPv6 deployment, as it could be applied to, say, 3G or 4G wireless networks. Here, the assumption is that we have a network in which the nodes inherently distrust each other, and in which a global or centralized PKI or KDC will never be available. This is more akin to Peer-to-peer and to opportunistic networking. The goal is to arrive at some fundamental assumptions about trust on top of which one can build some useful communication. Statistically Unique Cryptographically Verifiable ID's (SUCV ID's) How does a node preclude other parties (eavesdroppers, correspondent nodes, etc) from gleaning too much information about its identity, or its home address or its whereabouts? The latter concern leads to ephemeral forms of addresses which typical proposals base on cryptographic hashes. These identifiers (or EID's or TMI's or HIT's) can have several interesting characteristics: * they are distinguishable from globally routable addresses * they are doled out from a separate TLA (TMI's) * they have a special form which may include an administrative prefix (HIT's) * because they are based on cryptographic hashes, they are statistically unique * this, of course, depends on the anti-collision properties of good hash functions * perhaps MD5 is to be avoided because of some concerns in this regard: WeaknessInMd5 ( http://www.cs.ucsd.edu/users/bsy/dobbertin.ps ) * they are the hashes of a public component of a self-generated Public Key (perhaps unsigned Diffie-Hellman) So these identifiers have a strong cryptographic binding with their public components (of their private-public keys). This is exactly the purpose that certificates have. There is a catch, as always. The name or identity must be communicated securely, otherwise there is a possibility of man-in-the-middle attack (which is reduced if the initiator also signs the source address, and if there is ingress filtering, etc). Whereas in other applications of self-signed certificates it is possible to secure this step, in the situation at hand (opportunistic security) there is no practical way to do this. Instead, the initiator must communicate its identity/name to the responder using in-band mechanisms. Barring this detail, the initiator proves he owns this self-signed certificate by signing stuff with his private key, and given the algorithmic characteristics of the hash used, he further shows that his identity is statistically unique (within bounds set approximately by the birthday paradox). Let's call them Statistically Unique Cryptographically Verifiable ID's, or SUCV ID's. Because of this, once a CN obtains information about one of these identifiers, it has a strong cryptographic assurance about which entity created it. Not only that, it knows that this identifier is owned and used exclusively by only one node in the universe: its peer in the current exchange. Thus, it is safe to allow that peer to effect changes (via BU's, for example) on how this address or identifier is routed to. Notice that with publically routable addresses, this assurance is much harder to arrive at, given that the address may be 'loaned' to (not owned by) the peer in question, perhaps thanks to the good service of a friendly DHCP server, for example. Despite the fact that currently there is no way to prove address ownership in the Internet, these considerations lead to the following fundamental assumption: * redirect operations are only allowed with SUCV ID's The above constitutes perhaps the only rule that operates by default, allowing any other more dangerous operation only if authorized by strong cryptographic mechanisms SUCV ID's versus SUCV Addresses What should one use: pure identifiers with no routing significance or addresses? For example, in the Mobile IPv6 case, a node could just start using its current care-of address (CoA?) as if it were its home address, and issue binding updates accordingly when it moved in the future. Of course, regular CoA?'s will not qualify under the rule above, so it would mean it might be very difficult (impossible?) for whoever sends this BU to prove that it 'owns' that CoA? address and can rightfully send redirects for it. The most the node can do is to establish some cryptographic evidence that it is sitting on that CoA? address. And it is sitting on as opposed to owning , because the former more accurately describes what is going on (from the CN's point of view at least, and maybe also in reality). With a CoA? that is not an SUCV ID it is never evident to the CN that whoever was sitting on that address actually owns it. At the very most, the CN's peer can prove that at some point it was sitting on CoA?, and later it can prove it is still the same node, but now sitting on another CoA?. But it cannot prove ownership. It may have obtained the CoA? from a DHCP server, for example. Ignoring this subtle distinction leads to DOS and hijacking attacks. Problems may also arise because of honest mistakes in configuration. For example, say node A was originally sitting on CoA?, and then moved on to CoA?'. Suppose it then asks its CN's to redirect traffic to CoA?'. In the meanwhile, the original CoA? may have been assigned to another node B, perhaps by the DHCP server that rightfully 'owns' that address. The result is that now traffic meant for B has been redirected to A at its new location. Relying on ingress filtering may limit the risk, but essentially, the only way for a node to prove ownership of an identifier (in the absence of any other centralized or global mechanism), is for it to prove that it created this statistically unique series of bits. Once you bite into using a 'home address' that is not really your home address, then what you're really trying to do is to use some identity instead of an address. And if you use identities that satisfy the conditions outlined above, then you suddenly gain the tremendous advantage that anybody can safely believe you when you claim you own that identity. Hence they can safely heed your redirects when you say that your identity is now available at some different CoA? (and later at another). Furthermore, you do not rely on ingress filtering to limit exposure. The only advantage to using an address is that the data traffic need not carry extra information in the packet to guarantee proper delivery by routing. One could, perhaps try to achieve both purposes by creating CoA?'s that can serve as both an address and as an SUCV ID. This could be accomplished by: * using the top 64 bits from your routing prefix (as in rfc3041) * defining the bottom 64 bits as an SUCV ID Using the resultant 128 bit field gives you an identifier that is routable, avoiding the need for taking extra space in the packet by sending routing options UNTIL you move and send a BU indicating this identifier is now available at another CoA?. This would leak information as to your whereabouts (or at least where you were at some point) to eavesdroppers. The top 64 bits also tells them where that identity began to be used, which could be very important information. On the other hand, if you use a 'pure' SUCV ID (without any routing significance), then your packets will always need extra information somewhere to assure they are routed properly. Eavesdroppers may still know where that identity is at any particular point in time. This is unavoidable. But at least they will not know where (under what prefix) that identity began to be used. When to use SUCV ID's versus SUCV addresses All in all, if one is more concerned about privacy then using an SUCV ID with no routing significance seems preferable. As often (perhaps even more), nodes are not particularly interested in privacy. But they (rather their users) are definitely interested in using Mobile IP v6 such that their BU's are heeded. Since this implies proving address ownership, these nodes would want to use SUCV home addresses . If they do so, CN's can safely heed BU's for these addresses, because they have reasonable confidence that in doing so they are not unwittingly participating in some DOS or hijacking attack. This follows because of the SUCV property of the lower 64 bits within the address. This SUCV-ness, by solving the address ownership problem, helps in both cases: * applications in which routing redirects need to be heeded (of which MIPv6 BU's are but one example), and * applications in which privacy is the main concern Only that in the former(no privacy, regular use) you want a routable address for optimization as in an SUCV home address, and in the latter you want an SUCV ID. With CoA?'s it is perhaps a little different in the sense that you nodes no not have to prove ownership, so SUCV may not be as necessary. However, if privacy is a concern then randomized CoA?'s (SU CoA?, without the CV part) are quite useful (as has been pointed out elsewhere). Proposal for a Solution Using these ID's or addresses depends on also communicating safely the SUCV portion, and this, in turn is dependent on the packet sequencing, etc. These concerns are not addresses at all in the PBK draft. On the other hand, HIP includes mechanisms and detailed considerations in this regard (protection against replay, DOS and MITM attacks). This is why this note proposes that a solution be drafted based heavily on HIP: * http://search.ietf.org/internet-drafts/draft-moskowitz-hip-03.txt * http://search.ietf.org/internet-drafts/draft-moskowitz-hip-arch-02.txt * http://search.ietf.org/internet-drafts/draft-moskowitz-hip-impl-01.txt We assume MIPv6 * Use HIP identities, in particular, anonymous HI's * since we assume v6 here, use HIT the 128 bit long operational representation of HI's * HIT takes the place of EID's in PBK or of TMI's in the privacy for mip6 draft TODO: continue this entire section! -- GabrielMontenegro - 18 Mar, 2001 - 13:22:02
References: