About DHTs, byzantine robustness, and security (was Re: A roadmap for end-point identifiers? ...)
Iljitsch van Beijnum wrote: The basic assumption in byzantine robustness is that as long as the number of dishonest participants do not exceed a treshold ratio (e.g. one third of all participants), the system does not fail. Ok, I'm going to read up on this stuff but in the mean time: it's pretty obvious that if you want to be sure that a certain node doesn't deceive you, you must check with a significant number of different nodes to see if they agree. This is going to cost you performance. It is going to cost some performance, I agree. However, if you arrange your data so that it is self authenticating, then the only reason for byzantine robustness is protection from DoS and negative answers. That is, if you can arrange your data so that if you do receive a positive response, you can check that the response is genuine, then the task is somewhat simplified. Whether you can arrange your data to be self authenticating or not depends on many factors. One factor is whether your primary identifiers are cryptographic in nature or not. In the case of DHT servers, the more servers there are, the less likely it is that the treshold would be exceeded. Hence, even if you are relying on strangers, you are relying on them in a random manner, making any collusion highly unlikely, and impossible in practise. I just don't see it happening. If we reach a million multihomers, 900,000 of which are SOHO/private persons at some point in the future, and every piece of information is replicated in 10 places, there is still a 35% chance that a fortune 500 company has to rely on basement multihomers exclusively for this incredibly sensitive stuff. And remember: no SLAs, nothing. I do understand your view. But I don't share it. I am sure someone will sooner or later produce a statistical analysis that can be used to quantify the danger. We have to remember that even if we took the very simplistic approach and distributed the data over all of those basement servers, data about each separate identifier would be located on different basement servers. Furthermore, the exact set of servers serving data about a particular identifier would be extremely dynamic, since hosts would be joining and leaving the DHT service network all the time. Hence, even though I agree that such an arrangement might scare pants off from an IT manager, it might actually work extremely well and be extremely robust in practise. I think we need some experimentation first. Maybe set up a shadow DNS that uses DHT? Excellent idea. I wish I had more time to study the few ongoing DHT experiments that there are. Yes, mobility is complex. But don't you have the home agent as a fallback? So even in this case the regular PA home address should work most of the time. Well, yes, you would need some kind of a home agent for rendezvous. However, if you bind your identity to your initial rendezvous server, you create an additional single point of failure. That happens to be one of the problems with the current MIP and MIPv6 practises. On the other hand, if you do separate your identifiers and locators, you can move around your home servers, or even have multiple of them, thereby increasing resiliancy. So you're saying: use PI first, PA as fallback? I am saying that depending on application. No, that's no way to build something reliable. Either you always first do PA and only use the potentially non-routable addresses as a fallback, or you need two faced DNS or complex IGP tricks. I agree that you need two faced DNS. I don't see any specific reason why you should always do PA first and then PI, or vice versa. You do feed the DNS names to your applications anyway, and you can do what I proposed (before you have real identifiers), if you wish. That is one reason why I see some value of using PI addresses temporarily (for 3-5 years or so) as identifiers. And that is one reason why I understand that many network managers would like to have them. Personally, I don't much like PI addresses. IMHO, they seem to create more complications than solve. However, as a step towards a proper separation of identifiers and locators, they are probably needed. Not by me, but by many network managers. We need to protect the infrastructure. As I wrote, the danger is not that much to the communicating hosts but to the infrastructure. I'm not sure what you mean. Routers? DNS servers? All end-hosts and all subnets. Basically, everything. an attacker may launch a denial-of-service attack on a given node A by contacting a large number of nodes, claiming to be A, and subsequently diverting the traffic at these other nodes so that A is harmed. Not really big news. ... But it has nothing to do with multihoming, mobility or IPv6. It may not be big news, but it was news back when MIPv6 was at the IESG for the first time. And yes, what I am writing about has everything to do with mobility and multi-homing. And perhaps even IPv6. Unfortunately neither IPsec
Re: A roadmap for end-point identifiers? (was Re: where the indirection layer belongs)
spend a few years trying to make one that is all things to all people, I think we should start by making the simplest one we can possibly make and let everyone who feels they can do better have a go after that. I am always in favour of beauty contests and market evaluations. I'm not worried about security as these are end-to-end mechanisms. If two hosts feel they don't have to protect their communication, who are we to say that they must? We need to protect the infrastructure. As I wrote, the danger is not that mcuh to the communicating hosts but to the infrastructure. Some excepts from the above mentioned draft: 2.1 Target Basically, the target of an attack can be any node or network in the Internet (stationary or mobile). The basic differences lie in the goals of the attack: does the attacker aim to *divert* (steal) the traffic destined to and/or sourced at the target node, or does it aim to cause denial-of-service to the target node or network. The target does not typically play much of a active role attack. As an example, an attacker may launch a denial-of-service attack on a given node A by contacting a large number of nodes, claiming to be A, and subsequently diverting the traffic at these other nodes so that A is harmed. A itself need not be involved at all before its communications start to break. Furthermore, A is not necessarily a mobile node; it may very well be stationary. 3.1.2 Stealing addresses of stationary nodes The attacker needs to know or guess the IP addresses of both the source of the packets to be diverted (A in the example above) and the destination of the packets (B). This means that it is difficult to redirect *all* packets to or from a specific node because the attacker would need to know the IP addresses of all the nodes with which it is communicating. Nodes with well-known addresses, such as servers and those using stateful configuration, are most vulnerable. Nodes that are a part of the network infrastructure, such as DNS servers, are particularly interesting targets for attackers, and particularly easy to identify. If you feel a mechanism is too insecure, either slap some additional IPsec or TLS on top of it, or don't use the mechanism. Unfortunately neither IPsec nor TLS pixie dust helps here. --Pekka Nikander IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
A roadmap for end-point identifiers? (was Re: where the indirection layer belongs)
[Please direct replies either to the IPv6 or the IETF mailing lists, but not both. The default should be IPv6, imho.] Pekka Nikander wrote: Now, even though I believe that we should solve the problems (and apparently believe that there are sensible solutions), achieving consensus on solutions that require architectural change may take too long. Hence, I also believe that we need some kind of a road map, with some temporary or intermediate solutions along the way to a more long-standing set of solutions. Robert Honore replied: I agree, and your statement corresponds to what Keith Moore says about the solutions fitting into a framework that is yet to be specified. I believe specification of that framework begins with our defining what an end-point is. Good that we agree on a need for a roadmap. Now, I want to return back to your original problem analysis: *Stable (or reliable) end-point identifiers *Resiliency of application (protocol) in the face of sudden IP address changes *Self-organised networks These are the goals that we need to focus on. While designing the longer term architectural solutions, we need to preserve the current functionality, and think about transition mechanisms. From this point of view, the only (semi-)stable end-point identifiers we have today are IP addresses. We both agree, and I think quite a few others agree, that IP addresses are not very good end-point identifiers. However, they are used as such today. Furthermore, it will take quite a long time to get something to replace the IP addresses as end-point identifiers. As has been discussed several times, domain names do not work well enough, and therefore we need a new name space, I think. Consequently, we have to provide (semi-)stable IP addresses for IPv6 networks. Based on the recent discussion at the IPv6 WG, apparently people think that PA addresses are not stable enough. Hence, at least to me, the Hinden/Haberman addresses look like a good temporary solution. It seems to provide stable IP addresses, which can temporarily be used as end-point identifiers, with the expectation that they will be eventually replaced with proper end-point identifiers. What comes to application resiliency, Christian Huitema's approach of (mis)using Mobile IP may work well enough for a while. However, it has a number of architectural problems that make me to think about it only as a temporary solution. Going further, if we did not have any other reasons for proper end-point identifiers, I think that Dave Croker's MAST might be good next step. However, since I do think that we most probably do need stable and secure end-point identifiers, I think that something like HIP will be more appropriate. [I'm relatively ignorant to the exact details of self-organized networks, and therefore I don't want to comment that.] Given the above, I think we could have a roadmap that might look something like the following: Stable identifiers:Hinden/Haberman - New name space for end-point Resiliency on Huitema MIPv6 -- (MAST) --- identifiers address changes: multi-homing (maybe HIP) --Pekka Nikander IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Mumbles about HIP (was Re: apps people?)
Fred, Fred Templin wrote: There was a HIP mailing list for a long time @lists.freeswan.org. Yes, I'm subscribed to that list - since 7/16/2002, actually. There was a pretty healthy amount of traffic between 3/14/03 - 3/26/03 and then it went silent. I guess the list crashed at 3/26/03, short shortly thereafter. Your address probably got lost already then, since it did have some more traffic afterwards. Then it crashed again sometime in July, and AFAIK it has not been restored after that. Since then, I have received two messages - one on 6/29/03 and another on 8/10/03 (only two days ago) - both messages were from you, actually. I never saw any announcement of the new list... Those must have been crossposted to some other list. The 8/10/03 message I meant to crosspost to the new list (not the old one), but my fingers made a mistake. The other list the message was crossposted to was multi6. I don't remember about the 6/29/03 one. (I've been spending time with my family all the summer, and reading mail at odd hours without enough of coffee.) We announced the new list on the new list :-) My intention is to annouce it elsewhere, too, but that is just still in my pipeline. --Pekka Nikander IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Mumbles about HIP (was Re: apps people?)
Fred,
Fred Templin wrote:
... but do you truly have an alternate proposal that
will work for intermittently-connected/disconnected sites, sites that
frequently change provider points of attachment, multi-homed sites,
etc? I asked others the same question and they mumbled something
about HIP but ducked my pointed questions as to how soon we could
expect to see an alternate proposal.
As far as I see, HIP does not currently provide anything for
intermittently-conneted/disconnnected sites. Perhaps it could,
but AFAIK nobody has *seriously* considered that question.
(My gut feeling is that if HIP was adopted, the nature of this
and many other questions would change quite a lot. But that
is just an educated guess, at best.)
So,
unless there is some grand solution currently being architected in some
skunkworks project out of the public eye ... (And if there is such a stealth
mode project in the works, I think it high time that it be fully disclosed
to the community in good faith.)
I don't know about any skunkwork projects. However, since HIP was
mentioned, perhaps I should try to clarify the situation.
There was a HIP mailing list for a long time @lists.freeswan.org.
However, due to hardware problems the list crashed three times during
the last year or so, losing its membership at least once, and the
archive at least once, too. (I don't remember the details).
Anyway, there is now a new HIP mailing list @honor.trusecure.com,
see http://honor.trusecure.com/mailman/listinfo/hipsec
We tried to subscribe everybody we knew about to the new mailing
list, but I am sure some addresses just got lost. If you
are interested, please join to the new mailing list. It is currently
very low volume, but may get some traffic fairly soon (see below).
However, I don't expect it to get anywhere near IPNG volumes...
What comes to the architecture and base protocol specs, they are
fairly close to be ready for experimental. On the other hand,
serious work on multi-homing, mobility, IPv4 NAT traversal and
DNS issues has only recently begun, and requires lots of work
before completed.
As I mentioned at the multi6 meeting in Vienna, there are currently
four interoperating implementations, at least two of which also
support limited HIP based mobility. At least one even supports
mobility between IPv6 and IPv4. I am not aware of any implementations
that would seriously support multi-homing, even though some support
for that is in draft-nikander-hip-mm-00.txt
There are also some discussions going on with some ADs about the
possibility of a working group that would produce experimental RFCs.
However, it is not clear whether such a group, if created, should be
a working group or an IRTF research group. That is an issue that
should be discussed fairly soon at the hipsec ML.
--Pekka Nikander
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
Summary: Reason for the explicit link-layer address options in ND?
Thanks, Jim and Francis, for your timely answers to my question. Yes, like Jari pointed out, we are working on using IPsec for SEND, and we need to understand ND better to make it *right*. However, that discussion belongs to the very silent SEND mailing list, and should be continued only there, IMHO. (I've inserted Reply-To: headers to facilitate that...) Now, the ND specs as such are clear. No problem with that. It is just that the design rationale behind the specs in not written anywhere (as usual), and that was the reason for asking my question. We are not attempting to redefine or even revise the ND architecture, we are attempting to understand it fully so that we can design proper security for it. Now, if I read correctly what you Jim and Francis are saying, there seems to be a number of reasons for the design. Please correct me if I get this wrong; I am rewriting what I read to see if I understand it correctly. 1. Architecture It was deemed architecturally good to place ND at the IP/ICMP layer rather than below it. The main benefits from this are the following: - allows extension headers to be used - allows IPsec protection for ND - allows using routing and destination options 2. Implementation Early implementation experience showed that as a consequence of the design, implementation becomes simpler. In particular, NUD and prefix assimilation become part of the IP layer. I have one further question about that: what do you mean with prefix assimilation? I didn't find the term in RFC2461 or RFC2462. The reasons for the link layer address options were the following: 3. Extensibility (with extension headers etc). This seems to be a direct consequence of the architectural design decision. 4. Support for future functionality like proxy ND Again, this seems to follow the architectural principle layed out above. 5. Better support for the Override bit Now, I have a question about the Override bit. I didn't quite understand how it could be used for node discovery during first phase when link-layer addresses are not shared. What did you mean with that, Jim? Finally, the reasons for not peeking at the actual link layer addresses used in the link layer frame can be summarized as follows: 6. Separation of function This again follows the architectural principle. Especially, it was viewed that checking the link-layer addresses is a link layer function, and it should be separate from the IP layer. Is that all or am I missing something? Or is there something above that doesn't belong there? Now, if you want to discuss how security fits in this all, may I suggest that we do it on the SEND list? (Personally I have trouble in keeping track with the IPv6 list volume, as I have also other things to do but participate to the IETF work.) --Pekka Nikander IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Reason for the explicit link-layer address options in ND?
On the behalf of the SEND DT, I'd like to get a clarification to the current ND design from those who were around back when RFC2461 and RFC2462 were written. Specifically, we'd like the know the exact reasons why RFC2461 uses separate source/target link layer address options instead of relying on the actual source link layer addresses used in the link layer frame? Furthermore, why are the actual link layer addresses used in the link layer frame completely ignored, and not checked to match with the options? Is this just a layering question, an attempt to avoid layer violations? Or were there behind other goals, like allowing proxy ND? The reason why I am asking this is that the current situation makes security design tricky. That is, the Secure ND part of SEND (as opposed to Secure RD) is all about creating a secure binding between an IP address and a link layer address. The WG decided to pursue the idea of using public key based AH to secure the NA (and NS) messages. That requires that the hosts learn the public keys of the other hosts on the local link. Basically, there are two know methods for distributing the public keys: Using certificates and relying on a (local) CA, or using Cryptographically Generated Addresses (CGA). Now, for zero-config operation, we would like to use the CGA ideas. Furthermore, there is a possible attack against link local addresses, and that attack can be partially dwarfed if we bind both the link layer address and the public key to the IP address in CGA. Under the current design, the CGA processing at the AH layer becomes very tricky, if we attempt to include the link layer address into the CGA process. --Pekka Nikander IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: globally unique site local addresses
Michel, Michel Py wrote: I think that the split space is better, for the following reason: truly unique is a paid feature. People that pay for the feature will want a guarantee that they will get what they paid for, which is truly unique, which means the only model that works is split space. Michel Py wrote: Since truly unique would have a fee, the people that pay the fee will finance the development effort. From an enterprise standpoint, $50 a year is not significant if it buys the *guarantee* that the address is unique. The truly unique feature is like insurance. Let me try to understand why exactly some people would be willing to pay a fee for truly uniqueness. I'm probably missing some issues here; your input is valued. First of all, there is no such thing as an absolute guarantee for global uniqueness. Misconfigurations happen. Thus, the real difference between the split space and mixed space model is that in the split space model, *nobody* is *supposed* to configure or use a registered prefix, while in the mixed space model someone *may* legitimitely use it. However, even in the mixed space model the party having preformed the registration has some kind of ownership/moral property rights over the prefix, giving them more rights over those that haven't registered the prefix but happen to be using it anyway. Thus, whatever you pay, you don't have any absolute guarantee that nobody else is using your prefix. What you have is some kind of right over the prefix, the right having been aquired by registering and paying. Now, the case seems to depend on psychology and the formulation of rights. In the split space case the rights are easier to formulate, more natural, and stronger in that sense. Nobody is supposed to use your prefix, and therefore they are wrong if they use your prefix, and you can sue them (or, in Europe, you can dispise and ignore them :-) As far as I understand, it would be possible to come fairly close to that even in the mixed space model. If you have registered a prefix, nobody else can register the same prefix, and if you ever see someone using you prefix, they are wrong by letting the prefix to leak, and you can sue them (or at least dispise and ignore them :-) So, to me, it looks like the only thing truly uniqueness buys is that if your prefix is ever leaked by someone else but you, you may have better chances to shut them down, since you can morally require them to change their prefix. The cost of tracking down the party leaking the prefix seems to be the same. In both cases registration buys you the assurance that you do not need to renumber you prefix, ever. --Pekka Nikander IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: unique enough [RE: globally unique site local addresses]
Michel, My $0.02 about the hash/random/collision issue: It's a non-issue. I would agree with you, but only if I shared the same view of the GUPI prefix usage. That is, if GUPIs are really used only by explicit administrator action in big corporations, then fine. But unfortunately I don't believe so. The prefix generation happens only one time for the site. Collisions would not be detected until two sites merge or establish a VPN connection. Agreed. Though, I can vision dynamic sites that are created and dismissed fairly often. OTOH, if we decide to define a GUPI address space, we can formulate the usage guidelines so that they should not be used in such a case, and that a still another type of addresses are needed for such sites. The site gets its GUPI /48 prefix once, then the network administrator configures all routers within the site with subnets that fit in that prefix. This could be automated, but the fact of the matter is that there needs to be a router somewhere that seeds this prefix. If what you are talking about is automatic subnet number generation, this would be a zeroconf issue. Agreed. But I can also see a semi-automatic case; a SOHO or non-IT company configuring their network, and pushing a button to generate a site prefix for their network. Most probably they would not want to pay the *trouble* of registering their prefix; still the fee might be a non-issue for them. A site note: The reason for the registration fee is to discourage prefix hoarding. The fee can be lower than the trouble needed for registering a single prefix. (When registering multiple prefixes, the trouble for the subsequent prefixes is much lower than in the beginning, since learning is a big part of the initial trouble.) Besides the fact that making site-locals too easy is bad, I don't see why obtaining the prefix should be generated by a router. It is clear that the first thing the network administrator would do is to write down the /48 s/he will be using, and would be the one requesting the prefix in the first place. Hmm. I would agree that this is the case today, more or less. But, iff small sites become common, the situation would be different. If I remember correctly, one of the design goals in the whole IPv6 standardization has been minimization of human intervention. That's the reason why we have address autoconfiguration, that's the reason why we have been developing router renumbering etc. Or am I mistaken? Thus, I think that *if* we create these GUPI prefixes, their creation should be semi-automatic. Not fully automatic since they are not always needed. But, sure, we can start with a completely manual process and revise it later, if people feel that there is some danger is such a semi-automatic creation. Also, whatever the random/hash algorithm is chosen and published, it also is clear that the first thing that the network administrator would do is to go to the web to find if someone has already written an applet that would do the job. There will be sites that do not have Internet access at the time they want to configure their prefix. Either they will hand pick one, most probably causing unnecessary collisions, or the process should be semi-automatic, with built-in assistance in routers or in router configuration software. --Pekka Nikander IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Summary some possible long term consequences of GUPI prefixes
I'm trying to understand this whole GUPI prefix business. I have to say that I'm fairly confused, and therefore this attempt to summarize and envision the case. Please correct wherever I've mistaken. The GUPI proposal seems to have grown from the concerns regarding site locals. (I have to confess that I still do not quite understand why some people think that site locals are that bad; I guess there have been too many messages. I am still looking for the pro and cons drafts Margaret(?) suggested/asked for a few hundred messages back. Anyway, that's not the point here.) The GUPI prefixes seem to have a lot of desirable properties. Leaking GUPI addresses are less likely to cause confusion than leaking SL addresses. Site merger is easier with GUPI prefixes than without. GUPI prefixes allow limited inter-site communication through direct peering or tunneling. Statistically unique GUPI prefixes would be easy to generate. etc. Some people seem to think that GUPIs would reduce the need for IPv6 NAT. Maybe so, maybe not. More below. Requiring mandatory registration for GUPIs may make it easier to track down people leaking GUPI routes, but not necessarily so. But at least that would give us a scape goat, someone to yell at if a prefix is leaked. OTOH, mandatory registration would make it very hard to use them at non-connected sites. Now, suppose for a moment that we do have such GUPI prefixes. That is, prefixes that are (statistically) globally unique, provider independent, free, forever valid requiring never renumbering, and easy to generate even for non-connected sites. I guess almost everyone would start using them. At least I would personally, just for my personal VPN between my office and home. Thus, there would be millions of these prefixes in use. With some more invention, such as using them for PANs or semi-stable ad hoc networks, there would be billions of dynamic sites using these prefixes. From a site multi-homing (multi6) perspective, it might become again a (not so) good idea to perform prefix translation at the site exit routers. If you configure your network so that all hosts defend the same IID with the GUPI prefix and the global prefixes, thereby making IIDs unique within the site, you could fairly safely translate a GUPI prefix in source addresses into your global prefix for outgoing packets and vice versa for incoming packets. MULTI6 solved :-) From a mobile networks (nemo) perspective, you could use your GUPIs inside your mobile network (airplane, car), and again perform prefix translation at the site exit router. NEMO solved :-) (For those you missed the irony: I know pretty well that prefix translation would not solve the problems multi6 or nemo are addressing. I just want to point out that GUPIs might make people to consider prefix translation more seriously, since it would look safer with GUPIs.) More seriously, there would be a tendency to consider GUPI addresses as immutable identifiers for hosts, making the aggretable global PA addresses mere locators. Thus, it might form a step towards an architecture where identifiers and locators are separated. Now, honestly, I do not know if that would be a good step or not. We just have to understand that there would be a strong temptation to view the situation so. Furthermore, I guess that many people might just start using the GUPI addresses so, without thinking too much about the architectural consequences. --Pekka Nikander IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: globally unique site local addresses
Michel, In any case, a modest suggestion: Let's separate the GUPI prefix generation and registration processes, and make them sequential. I have another suggestion: Let's split the FEC0::/10 space in two parts: One for the unregistered good-enough and one for the registered truly unique. By default, the good enough would be used and a random/hash method would be used. But the network administrator would have a choice of getting a truly unique registered prefix instead. This would likely need to access some web page and pay a nominal fee. If the address space is split, then we have a guarantee that the hash process used for good enough will not grab addresses in the range that is used for truly unique. Let me try to briefly analyse the differences between the methods, the mixed space and the split space methods: - In either method, you can generate a prefix and register it as a GUPI prefix belonging to you right away. - In the mixed space method, you may have to need a couple of prefixes before you get one registered. OTOH, if you really need a registered prefix, you can combine generation and registration, and start configuring your routers only once you have got a prefix registered. Thus, no big difference in practise. - In the mixed space method, you can generate a prefix now and try to register it later, with a fairly large probability of succeeding. In the split space method, if you only later need a genuinely globally unique address and are not willing to pay for one now, you have to renumber. - In the split space method, you can tell directly from a prefix whether it is genuinely globally unique or not. In the mixed space method you can query the registry whether the prefix has been registered, but even if it is, there may be also other sites that are using the prefix. The probability of the existence of such sites is low, though. - In the split space method, you can be almost sure that nobody else is using your globally unique prefix, and if they do, they do it in error. In the mixed space method, you cannot be sure that nobody else is using your prefix, but if they do, you know that they cannot register it. Thus, from my point of view, the differences seem to boil down into two issues: 1. In the mixed space method, you can defer your registration and still have a fairly large probability of succeeding later in registration. 2. In the split space method, you can have more confidence that no-one else is using your truly unique prefix. I can't say which is better. --Pekka Nikander IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: globally unique site local addresses
Michel Py wrote: There is room for both models at the same, and good enough is not going to be good enough for everybody. Margaret Wasserman wrote: I would need to see a very compelling case for why two types of globally-unique/provider-independent addressing are needed before I would like to see two models. Good enough ones are easy to generate without too much human intervention, for example, without any connection to the registry. OTOH, they are not necessarily unique, and therefore not good enough for some people. IMHO, both types are needed. I think that one of the benefits of globally-unique/provider- independent addresses over site-locals is that it is possible to tell (when one is leaked in any of the possible ways) exactly where the address came from... This would, of course, work best if the addresses were actually unique, rather than mostly-unique. Requiring that everybody registers their GUPI addresses will not make everyone to register them. OTOH, you could argue that if we mandate registration, and someone uses some prefix without registering them, it's their problem. In any case, a modest suggestion: Let's separate the GUPI prefix generation and registration processes, and make them sequential. The prefix generation could be a semi-automatic hashing based process, generating a prefix that is only statistically unique. If real uniqueness is required, the administrator could take the generated prefix and attempt to register it against a modest fee. It that succeeds, good. If that particular prefix is already taken, the admin can generate a new prefix and try again. Registration would require not only registering the prefix but also showing the input. That would discourage people from hoarding easy prefixes or adjacent prefixes, since looking for suitable hash input for such prefixes would not be that easy. Furthermore, if really needed, the fee can be gradually raised as the registry starts to fill up, thereby discouraging new registrations. The basic benefit of this method is that there would be only one way of generating GUPI addresses, and that would be an easy one. Additionally, the method would initially keep the GUPI prefix space sparce and evenly distributed; that might be advanteous. For example, deferring regisration of one's prefix would not be that risky, since the probability of succeeding later would be still fairly high. --Pekka Nikander IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: unique enough [RE: globally unique site local addresses]
Margaret, It is actually my (weak) understanding that taking more inputs does not actually result in more uniqueness, at least for random number generation. Does anyone know how that works for hashing? AFAIK, the bigest problem with random number generation is non-random seed data. Adding more sources of randomness helps in that. In this case, relying in just one MAC address as a seed for a hash function is probably not good enough, but e.g. taking the MAC address *and* the machine's current idea of date time in millisecond precision probably is. As another issue, just picking a cryptographically strong hash function and using it as a random number generator is typically *not* good enough for many uses of random numbers, but IMHO it is OK for generating these kinds of identifiers. Thus, if we want a method for automatically generating prefixes for globally unique enough site local addresses, a decent method might be sha1( current date and time in ms | interface MAC ) where the date time would be a 64 bit integer and the MAC address either 48 or 64 bit MAC, the 48 bit version enlarged to 64 bits. Note that there is no need for time synchronization. If there are more implementations of MD5 than SHA-1, MD5 would be good here, too. In the case of a collision, the algorithm can be simply rerun. The new result will be completely different. --Pekka Nikander IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Reminder: Secure Neighbor Discovery (SEND) BOF tomorrow Tuesday at5pm
(Apologies for the cross posting.) Folks, I just want to remind you that a BOF on Securing IPv6 Neighbor Discovery (SeND) is going to talk place tomorrow (on Tuesday) at 5pm in room 303. The mailing list archive is available at http://standards.ericsson.net/lists/ietf-send/maillist.html There are only about 30 messages at the archive. Other than the archive, there aren't any specific web pages for the BOF, yet. The proposed charter can be found in a recent message, at http://standards.ericsson.net/lists/ietf-send/msg00029.html The BOF agenda, with the required reading list, is available at http://standards.ericsson.net/lists/ietf-send/msg00030.html We have only one hour available for the BOF, and a largish number of presentations. Thus, it is highly adviced to read the drafts beforehand. Most of the drafts are short; none of them are over 20 pages, and many less than 10. --Pekka Nikander (co-chair) IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Using a bit as a protection against bidding down / for something else
Keith, if yahoo.com thinks there's any value at all in the client's IP address, they're deluded. the only way to reliably know a client is if the client presents you with cryptographic proof that they sent that message, and you trust the keying material on which that proof is based. I completely agree with you if the goal is to know *who* the client is, for any reasonable meaning of *who*. But that is *NOT* the goal. For MIPv6, the *final* goal is to learn if the client is *authorized* to create bindings, i.e. source routes, for the _home address_ that it is using. The process to learn whether it is authorized or not is basically a two step process: Step 1. Detect if the client wants to use the default authorization mechanism, i.e. RR, or something stronger. Step 2. Use the authorization mechanism to detect if the client is really authorized. It was an _explicit_ IESG requirement that the authorization mechanism MUST NOT rely on trusted third parties, i.e. on a security infrastructure. Hence the infrastructureless methods. If we want to take the security-infrastructureless route, we have little to build up but the routing infrastructure and the addresses. (The secure ND case does not apply for an arbitrary client for contacting yahoo.com. I'm too tired to try to think generally right now, and to work out more generic examples.) --Pekka Nikander IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Using a bit as a protection against bidding down / for somethingelse
Keith Moore wrote: so rather than trying to squeeze a protocol negotiation bit into the address, maybe folks should be trying to add the necessary information to DNS so that it can be verified by DNSSEC. That can be done. For MIPv6 it just requires that we have fully deployed secure reverse DNS. I realize it's ugly to add more frobs to DNS, but IMHO trying to further constrain the use of the IPv6 address space is far uglier. The bit method is also a performance issue. Do we want a server to do a DNS lookup each and every time someone talking with it wants to do MIPv6 RO? Do we want to include DNS lookups in Secure ND? --Pekka Nikander IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
CGA vs. Zero-conf security (was Re: Using a bit as a ....)
[I changed the subject since the topic was changed.] James, You are reading that I were saying more than I am, probably since the word security is so ill defined. I even catch myself using it in different meanings, and it is sometimes very hard to unambiguosly understand the exact meaning. Thus, this all is really about zero-configuration security. Such security, by nature, is never strong by the strict definition of strong, but it can be *much* stronger than the current no-security situation. Basically, such security can provide quite a lot of defence against various DoS attacks. I think you are making too strong a claim here. It looks like you are reading my statement somehow differently than I am. All that CGA does is allow a node to know that a packet came from a node claiming to possess a certain public key. The packet could have been rewritten in transit, or the public key may not come from a reliable source, etc. Right, in a way. But maybe wrong, in another way. To be more precise, CGA + self signed certificate that contains the CGA address shows that somebody has, once but maybe 10 years ago, taken the effort to create a public key pair, an CGA address based on the public key, and signed a statement containing the CGA address using the private key corresponding to the public key. The security of this statement relies on cryptographic primitives, i.e. public key crypto and the hardness of reversing even around 60 bit one-way-function. Thus, the security here is an *economic* function, a function of the fact that creating such a stament for any *given* address would be prohibitively costly for most if not all organizations. To say anything more than that, you have to a) define exact semantics for the self-signed cert, and b) run a cryptographic challenge-response protocol that provides a timeliness proof about the availability of the private key. That allows you to do more, but it certainly does not allow you to do end-to-end security for many meanings of that phrase. Real end to end security requires being able to authenticate that the packet contents were not modified in transit, i.e. a digital signature, and that the public key can be trusted. If a signature is used, then Diffie-Hellman or another protocol is required, and both sides must agree on the protocol and the parameters, e.g. p and g if Diffie-Hellman is used, and that the public key came from a trusted source. I am not quite sure what you are exactly saying, but to the extend I understand I think that we agree. That is, I think that you are basically saying that CGA as such is not enough, but we need a cryptographic protocol on the top of that. That I agree with. What comes to trusted source, I am not sure. Trust and trusted are also terms that are a lot misused in security literature. Indeed, the crusial issue here is trust. However, trust is *not* a binary, non-qualified thing. It is a quite complex phenomenon both in technical and psyco/sociological sense, but let's not go there. For now it is sufficient to understand that Alice trusts Bob for some things but not for others. The issue here is that you can *choose* to trust public keys for *certain* purposes, just based on the belief that it would be sufficiently hard for an attacker to break the assumed cryptographic scenario, e.g. CGA. I think CGA is a good solution to the MIPv6 BU security problem, and maybe for ND security as well, but I think it is prudent to not overstate the case. I did not mean to overstate. I am sorry that my original sayings about zero-conf security could be read so. Generic zero-conf end-to-end confidentiality and integrity does not exist, since the *application* that requires confidentiality and integrity has application level access control and authorization requirements. On the other hand, it seems to be possible to create zero-conf security for certain signalling tasks, such as mobility and maybe ND. BTW, MIPv6 CGA is not the best example of zero-conf mobility security, HIP is a much better one. --Pekka IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Using a bit as a protection against bidding down / for something else
Steve, I think that making such a reservation is not *quite* as harmless as you imply. If I understand correctly, if we were to agree today to reserve a bit in the IPv6 IID (or a subrange of the IID space), the Mobile IP folks would then immediately proceed to put some language in the Mobile IPv6 spec requiring (or forbidding) certain behavior for packets carrying (or not carrying) IIDs from that reserved space. ... You are right, of course. It is good that you say that so clearly. To me this has been too implicit, and I couldn't have expressed it. Just two observations: 1. Having a switch that suddenly *allows* RR to be used for the reserved space is much easier than vise versa. Such a switch can be a MUST in MIPv6. 2. RO (and hence RR) is an optimization. An optimization that people want, but an optimization anyway. If two hosts don't do RO, they can still communicate. --Pekka Nikander IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Using a bit as a protection against bidding down / for something else
Folks, I am getting tired in trying to argue for splitting the IPv6 address space into two subsets, and for perhaps reserving a bit in the IID, for the purpose of providing footing for work on security MIPv6 and ND, and perhaps also securing other signalling functions. To me, the problems with end-host mobility and end-host multihoming are just two faces of a more generic problem, the end-point naming problem. In that arena I am very much in favour of Noel Chiappa's thinking. I think that we need a new end-point name space, and we even have a decent candidate for that: HIP. From that point of view, Mobile IPv6 and CGA are just stepping stones towards the direction that I personally believe that we will head sooner or later anyway. I think that CGA and ABK are great ideas that could make the current architecture quite a bit more secure before doing the big transition into separate end-point name space. What comes to ND, securing ND is a hard matter as long as the hosts do not have cryptographic end-point identities. Once they do, the problem is *much* simpler to solve. CGA and ABK seem to help in this area quite much by providing a means to still use addresses as primary end-point identifiers, and to convert the addresses into public keys. If we take the other approach of using public keys as primary end-point identifiers, we do not any more have that problem. Or at least the problem is different. Thus, with these observations and expressions of my personal beliefs, I hereby withdraw back to my humble researcher chamber, and don't bother your standardization work with too radical issues. Yours sincerely, --Pekka Nikander A poor researcher exhausted in the mill IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Using a bit as a protection against bidding down / for something else
Brian, Hesham Soliman (ERA) wrote: The scenario Brian mentioned will not be an issue for bidding down attacks related to mobility. Brian E Carpenter wrote: Can you explain? I don't see why you can't have an evil MitM intercepting binding updates and bidding them down. This is really a question of perception and threat model. Technically you are right. An evil MitM can intercept binding updates and bid them down. However, the evil MitM can do worse things, like prevent communication altogether. It can also perform a classic MitM attack, changing message contents on the fly. The goal of MIPv6 security is not to protect against classic MitM attacks. It is designed to secure mobility signalling, i.e. messages that change a node's (CNs) internal routing information. That is, the goal is to prevent false bindings from being created at a CN, and thereby prevent traffic diversion and DoS, among other things. Now, the design goal for the MIPv6 security design was do no harm, meaning that MIPv6 must not make Internet any less secure than it is already now. From that point of view, the selected MIPv6 security mechanism, Return Routability (RR), is approaching the goal from below. That is, it still allows time shifting attacks where an attacker is able to create a binding when a Mobile Node is not active, and thereby prevent the legitimite MN from communicating with the CN once it becomes active. (There are also other DoS concerns involved where other hosts or parts of the network become victims of DDoS attacks.) Now, RR reaches the goal by reducing the time window for the time shifting attacks to a few minutes. Thus, RR as such, is insecure. A MitM can break it easily. Now, one goal of the bit method was to reserve some footing for the more secure protocols. That is, if we assume that there are two types of mobile nodes, weak ones and strong ones, but only one type of corresponding nodes, ones that are able to act either as weak or strong, the bit method does indeed seem to create some footing. When a strong MN talks to the CN, a MitM can still prevent all communications between the MN and the CN and it can change MN's address into a weak one on packets flowing MN-CN and back to the strong one on packets flowing on CN-MN. However, if we consider our security goal, that doesn't matter. Our goal was prevent the creation of false bindings. The MitM cannot create a false binding for the MN at the CN, and it cannot fool the MN to believe that it has succesfully created a binding at the CN. The crusial assumptions here are the following: 1. We want to prevent the MitM from creating bindings for some addresses even if it is able to break the weak method. This creates some footage for the strong methods. 2. The MNs make an a priori decision whether they want to use a strong or the weak method. 3. Our goal is to allow the MN to securely indicate the CN whether it wants to use the weak or strong method. Now, under these specific conditions the bit method seems to work. Not perfectly, but well enough. On the other hand, the bit method *cannot* be used as a generic bidding down protection, as I mistakenly thought for a couple of weeks. And of course it is possible that there is still some flaw in my thinking and/or in the explanation above. If that is the case, I'd be happy if you or anyone could please point that out. Well, personally I consider the bit method as a gross hack, and really wish that we can create something better. The need is there. We just need a method. --Pekka Nikander IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Using a bit as a protection against bidding down / for something else
Tony, I agree with you that the bit method is not a good method. On the effective value of the method I have to *disagree*, though. There is, however, a need to divide the IP addresses into two sets: 1. Addresses for which CGA (or something similar) is *required*. 2. Addresses for which CGA (or somethign similar) is not used or is optional. The reason for this is the bidding down attack. The fundemental decision comes down to; does the MN generate a CGA, and send a PK to the CN, or not. If it does the CN has what it needs to verify the IID, and if it doesn't then the receiver might waste a few cycles deciding that the IID is not based on a PK. The action the receiver takes at that point will be exactly the same as if it had seen the proposed bit cleared. THE BIT PROVIDES NO VALUE TO THIS PROCESS. Here I have to *strongly* disagree. The bit is one method for providing protection against the bidding down attack. It effectively creates two IP address spaces, those for which the receiver *requires* CGA, and those for which it does not. If we do *not* do this distinction, a Man-in-the-Middle can claim, for *any* IP address, that CGA (or something similar) is not used. That reduces the security of all addresses to the same base line, effectively creating a situation where CGA (or similar) does not provide any additional value at all. Ergo, *something* that divides the IP address set into two distinct sets *is* needed, or otherwise CGA and related methods bring no additional value. If everybody agrees that CGA (and any security that is *not* based on an external infrastructure but on intrinsic cryptography) is a bad idea, then fine with me. Let's forget this discussion. But then we are effectively saying that zero-configuration security is a bad idea and we don't want it. Thus, this all is really about zero-configuration security. Such security, by nature, is never strong by the strict definition of strong, but it can be *much* stronger than the current no-security situation. Basically, such security can provide quite a lot of defence against various DoS attacks. This two-address-space thing is only required for those recipients that support both the current nodes with no understanding about zero-conf security and the future nodes that do care about zero-conf security. As I noted before, it requires that the initiator commits a priori either to the weak method or the strong method. The details differ, quite a lot in fact, depending on whether we speak about MIPv6 or something else, e.g. secure Neighbor Discovery. But the same need: dividing the address space into two distinct sets, is there. Or at least that is my current understanding. Maybe I am wrong. Personally, I do not believe that any bold statements help here. At least to me, this whole zero-conf security business is so new that at least I need to have very humble attitude here. I learn new issues all the time. On the other hand, IMHO we really want to go towards zero-conf security. And if we do, we need some kind of transition mechanism. Dividing the IPv6 address space seems to serve as an important piece of such a transition mechanisms. Of course, there are different ways of dividing the IPv6 address space. If everybody thinks that using a bit in the IID is a bad idea, then maybe we should consider distinct routing prefixes for mobile hosts, and distinct link local addresses for secure ND. --Pekka IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Using a bit as a protection against bidding down / for somethingelse
Bob, This is staring to sound a lot more like a research project than something the IETF should be considering standardizing now. I wonder if it might be better to complete the research and then decide the best way to signal it's usage (e.g., bit, control protocols, etc.). You may be right that *how* exactly to *use* the bit is more a research issue than a standardization issue. At least we should get much more peer-review from the security people on CGA and any other such methods. However, what Erik and the MIPv6 Design Team suggested is that the bit is *reserved* at this time for future use. From the MIPv6 point of view, it *also* acts as a safeguard against the possible future situation where RR becomes the weakest link in IPv6 security, e.g. because ND gets secured. It would allow gradual shift-out from RR at that point of time. Basically, it looks like we are not much going anywhere: - The currently known alternatives to RR do not seem to get accepted at the MIPv6 WG due to IPR issues. Personally I consider it very unlikely that new similar methods would magically emerge without IPRs. - Thus, MIPv6 Route Optimization cannot move forward unless RR can be made secure enough. - It looks like some people (me included) would not like to see RR widely deployed *unless* there is a clear way out of it. A way that does *not* require world-wide security infrastructure. - The bit method is one such a way, but nobody wants to adopt it, at least not for MIPv6 RR. - Ergo, MIPv6 is stuck, again. Actually, it *may* be possible to augment RR design so that no such external safeguard, as the bit, is needed. We are looking at that, right now. Unfortunately there are some IPR issues on that path, too, and I don't know if they can be resolved. However, even if we could fix RR, that does *not* remove the need for other zero-conf security solutions (such as Secure ND), as I explained in the other note to Tony. Thus, I really think that we should make such a bit *reservation* for two reasons: Firstly, to provide a migration path to zero-conf security, e.g. Secure ND, and secondly, to provide a controlled way of disabling RR for certain *addresses*. (Note that it must be disabled for *addresses*, not nodes, due to MitM and impersonation attacks.) If it later turns out that the reservation does not need to be used, after all, the better. Then release it or use it for something even more productive. --Pekka Nikander IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Using a bit as a protection against bidding down / for something else
Tony, Brian, and others, Sorry about this volume, but let me try to simplify once more. I am now shifting quite far away from the immediate need, MIPv6, whose issues *may*, perhaps, be solved otherwise, and argue more for the other thing, Secure ND, and other related zero-conf security protocols. Firstly, assume that there is no external infrastructure that we may rely on. That is, we are playing zero-conf game. Now, what we want to do is to create two playgrounds: 1. The current non-secure playground 2. A new zero-conf-secure playground We can make these completely distinct. The nodes (childs?) in the new playground only communicate there, and the nodes in the current one only here. In this case there is no problem the zero-conf nodes refuse to talk to the non-secure nodes, and that's it. What we want to achieve, though, is a situation where the zero-conf nodes can also talk to the non-secure nodes. If a zero-conf node initiates the communication, this is probably not a problem, since it needs to look up some properties of the recipient anyway, and these properties can include credentials that identify the recipient as a zero-conf node. (Maybe these credentials can also be secured with a zero-conf method, and if so, naming seems to *help* there, too. But it certainly does not solve all problems.) The problematic case is when some stranger contacts a zero-conf node. It must be able to tell if that new node is a zero-conf node or a non-secure node. And this becomes tricky due to the possibility of man-in-the-middle and masquerade attacks. Relying on looking up credentials each and every time is one possibility. But that is inefficient; large servers are unlikely to do that. Naming the nodes in the playgrounds differently, as suggested, seems to provide *some* help. It is definitely not a panacea, MitM and masquarading attacks can still play *some* nasty games. However, the cannot steal zero-conf addresses, because zero-conf addresses are explicitly named as zero-conf addresses and because the attackers cannot provide the cryptographic credentials required from zero-conf addresses. (The latter is an intrinsic property that defines zero-conf security addresses.) Maybe that approaches the essense of the issue. The issue was initially about MIPv6 RR vs. other MIPv6 security methods. However, the issue seems to be more and more shifting towards this zero-conf (secure ND) vs. current situation issue. Or so at least in my mind, I don't know about others. I hope that this helps, or that it at least leads us to collectively learn something. --Pekka Nikander IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Using a bit as a protection against bidding down / for somethingelse
John, My understanding of this entire discussion was that the bit method was more along these lines: 1. Addresses for which something stronger than Return Routability is needed. 2. Addresses for which Return Routability is sufficient. It originally certainly was. However, at least my thinking has evolved since then. That is, it *may* be possible, perhaps, to solve the RR bidding down issue separately. We still don't know. I'll let Jari's reply to stand for the rest. --Pekka Nikander IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Allocating a bit in the RFC2374 Interface Identifier
Brian, No. Quoting Pekka Nikander's original description of the bidding-down attack: Note that an active attacker at the path between Alice and Bob is able o clear a set bit. However, that changes the address, and Alice is not going to answer to any possible replies sent by Bob. Thus, the bit prevents the attacker from impersonating as Alice and fooling Bob to use the less secure protocol. This doesn't satisfy me. If the attacker is capable of clearing the bit in the source address of packets from Alice to Bob, it is equally capable of setting the bit in the destination address of packets from Bob to Alice. (The proof of concept here is every NAT box sold so far.) So I don't see why the attacker can't conduct a complete bidding-down attack in which Alice sees only packets with the bit set, and Bob sees only packets with the bit cleared. Alice will believe she has asserted strong security available, Bob will believe the opposite, and both will be fooled. I am tired, and probably the situation is more complex, but this my initial reaction. It looks like in the scenario you describe Alice and Bob would end up running different protocols: Alice the strong one, which the attacker presumedly cannot break, and Bob the not-so-strong one, which the attacker presumedly can break. Thus, Bob would end up running the not-so-strong protocol with the attacker, but the address used would not be Alice's address. But I start to believe that I am missing here things, and that the reality is more complex than what we thought at the MIPv6 DT. That is, at least we need a mechanism for Alice to securely learn about the mechanisms Bob supports. Maybe we could use the bit here, too, but my brains just fail to analyze what happens to the address-spoofing MitM in that case; maybe you could perform the attack in both directions? But would that matter? If there is an attacker that can spoof packets and break the less secure protocol, it can create security associations with the less-secure protocol anyway, be there the legitimite peer or not. Erik, Jari, or Gab, I guess it's your turn :-) --Pekka Nikander IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Allocating a bit in the RFC2374 Interface Identifier
Erik, Perhaps the question was about the whole address and not just the interface ID. You've described how the interface ID is crypgraphically tied to a public key. But this doesn't per-se prevent somebody fabricating a CGA address using an arbitrary prefix. You are right. Michael Tuomas suggested that stuff included also the prefix, hence iid = low64(hash(PK, prefix, stuff)) mask This makes it harder to transfer iids from one link to another, or to create pre-computed iids. But it doesn't prevent fabricanting CGA addresses; they are all fabricated by the host itself, after all. That is explained in detail in draft-roe-mobileip-updateauth-02.txt. What CGA is all about is that it is (believed to be) hard to create two create two PK, stuff pairs that happen to have the same IID, or -- more importantly -- to find a PK, stuff pair that yields a given IID. That also set some restrictions on what one can include in stuff. The way to avoid this for MIPv6 is to do a return routability test when the CGA address is verified. The RR test would ensure that the peer is reachable at the prefix. (And the RR test would essentially be done as part of the challenge to have the peer sign the nonce using the private key.) That's right. CGA alone doesn't really show that somebody owns an address. In the non-local case, you must always perform the RR test also, they way you note. --Pekka IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Allocating a bit in the RFC2374 Interface Identifier
Glenn Morrow wrote: In which case, I violently agree with Keith. We've already overloaded IP addresses with two functions - locator and identifier. I would rather see the WG focus on the value of using a bit to specify whether the address is intended to be both a locator and identifier or just a locator. I personally believe this would be a far better use of real estate than the other proposal. I certainly wouldn't expect any dicision soon on either proposed use, though. Well, the original idea was to reserve a bit to indicate that the address is Cryptographically Generaged Address (CGA), basically meaning that if the bit is set, then interface id = low64(hash(PK, stuff)) mask where PK is a public key to be used as an identifier for the host stuff is contains other parameters (see the earlier messages) hashis a cryptographic hash function, e.g. SHA1 low64 is a function that takes lowest 64 bits maskindicates that we have to clear/set some bits of the iid In essense, that would allow anyone to determine if a given public key belongs to a host, just inspecting the public key, the address, and the stuff above. See e.g. Michale Roe and Greg O'Shea, Childproof authentication for MIPv6, Computer Communications Review, April 2001, http://www.research.microsoft.com/users/gregos/CAM-v9.pdf or Pekka Nikander, Denial-of-Service, Address Ownership, and Early Authentication in the IPv6 World, Cambridge Protocols Workshop, April 2001, http://www.tml.hut.fi/~pnr/publications/cam2001.pdf for research papers touching the idea. There is also a number of internet drafts that describe in more detail how CGA could be used for a number of purposes, including but not limited to Mobile IPv6. Unfortunately, this method is encumbered by IPR claims from Microsoft and Ericsson, and therefore it received violent opposition at the mobile-ip working group. As a result, the MIPv6 Design Team resolved to the more modest proposal of just allocating the bits, in the hope that the IPR issues could be dealed in a way or another. --Pekka Nikander IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Allocating a bit in the RFC2374 Interface Identifier
Pekka Savola wrote: We MUST NOT reserve bits in the address to support IPR'd mechanisms. Actually, the intention is just the reverse. The intention is to reserve a bit (or bit pattern) so that the IPR'd mechanims NEED NOT to be used for future better security protocols. CGA can be used independent on whether there are any bits reserved or not. The bit method would leave the door open to any future security mechanisms, including those based on AAA and CGA. But I think Erik is better in expressing the issue, he first proposed the bit method anyway. --Pekka Nikander IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Allocating a bit in the RFC2374 Interface Identifier
Mohan Parthasarathy wrote: Now, when bob receives the packet sent by Alice, he has no other knowledge about Alice except the packet itself. In particular, the only information he has about Alice is the source IP address in the packet. I am missing something here. Isn't the packet carrying any other information at all ? An attacker can change any field in the packet. However, if the attacker changes the source address, the packet is not about Alice any more. Thus, the packet does carry information, but the only piece of information that can be _securely_ relied on is the address. I think others, like Dave Thaler, are saying this more clearly here, probably due to my shortcomings in handling the English language. --Pekka IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Allocating a bit in the RFC2437 Interface Identifier
cannot ask Alice, since an attacker impersonating as Alice would lie, and say that Alice supports only the default, less secure protocol. In other words, there must be a method, independent on Alice's actions, that securely gives Bob reliable information about the protocols Alice supports. If such a method does not exist, and there is an attacker that can break one of the protocols, the attacker can claim that Alice supports only the protocol that it is able to break, thereby making it impossible for Bob to use the other more secure protocols. This is the essense of the bidding down attack: an attacker that is able to break one of a number of security protocols can impersonate Alice to Bob unless Bob can learn, independent of Alice, what protocols Alice supports. See http://playground.sun.com/mobile-ip/WG-archive/frm05357.html and http://www.piuha.net/~jarkko/publications/mipv6/Bidding_down.txt for more details. Note that with respect to the bidding down attack the discussing about allowing Bob to determine, by looking at the address, whether Alice is satisfied with the default protocol or not. That allows Bob to continue quickly in the default case. What to do, in exact terms, in the non-default case (other than not using the default protocol) is beyond the scope of this note. Especially, we are *not* suggesting that there should be additional bit(s) reserved for specific needs. Specific needs == Currently there seems to be only one situation where we want to introduce a default, not-so-good-but-good-enough security protocol that anybody can use, with the anticipation that in the future there will be a number of better-and-more-secure variants. This is the Mobile IPv6 situation, where Return Routability (RR) will be the baseline security protocol. However, the situation is in no way specific to Mobile IP. There will clearly be other needs too, e.g., secure multicast or anycast might have the same need. In the case of Mobile IP, we definitely want to have a method where it is possible to tell whether a given Mobile Node wants to use RR or not. In this case, the most secure security protocol is to disallow the function completely, i.e., say that Mobile IP Route Optimization MUST NOT be used for this host. For example, stationary hosts most probably want to forbid Mobile IP Route Optimization. However, if we want universal deployment for Mobile IPv6, the default clearly cannot be to disallow Mobile IP. Instead, the default case clearly needs to be the lowest common denominator, Return Routability (RR), and it is up to each host to separately indicate when it wants to use some more secure protocol, including the no-RO at all choice. The suggestion == Now, Mobile IPv6 Security Design Team has discussed whether it would be possible to allocate a bit (or a bit pattern) on the IPv6 64 bit Interface Identifier field, with the intention of later defining a method that allows peer hosts to securely find out what security protocols, and perhaps other functional features, the host using the address supports. That is, if the bit is cleared, the host is happy to rely on the default security protocols and semantics, as defined in the base IPv6 RFCs. Thus, its peers are allowed to use the default semantics and protocols when dealing with this host. If the bit is set, on the other hand, the host instructs its peers that the host is not happy with the default semantics and protocols, and instructs the peers to look for more information. The exact way of how to look for this information is to be defined later. Note that an active attacker at the path between Alice and Bob is able to clear a set bit. However, that changes the address, and Alice is not going to answer to any possible replies sent by Bob. Thus, the bit prevents the attacker from impersonating as Alice and fooling Bob to use the less secure protocol. The immediate intention at the mobile-ip WG is to the define the Return Routabilility (RR) security method as the default Mobile IP Route Optimization methods, to be used by all hosts that have the said bit cleared. If the bit is set, the corresponding hosts must go to find out what Mobile IP security method the mobile node supports. If the corresponding node cannot find out this information securely, it MUST NOT use Return Routability. This effectively blocks the bidding down attack, as discussed above. --Pekka Nikander on the behalf of the MIPv6 Security Design Team IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Allocating a bit in the RFC2374 Interface Identifier
Brian E Carpenter wrote: I must say I don't understand the reference to RFC2437... presumably you mean 2374, which will be obsoleted anyway. 2437 was a mistake, pardon my poor sleep deprived brain. The subject line should now have the right reference. In which case, I violently agree with Keith. We've already overloaded IP addresses with two functions - locator and identifier. We've been rebuffing various suggestions for yet more overloading for years (the porno bit for example) and this is in the same category - not the right place to put a security hint. It's quite inappropriate to damage the opaqueness of a pure ID field in such a way. If a security hint is needed, it should be somewhere else. A security hint is needed. Please read the bidding down notes to see why. For reference, here are the URLs again: http://playground.sun.com/mobile-ip/WG-archive/frm05357.html http://www.piuha.net/~jarkko/publications/mipv6/Bidding_down.txt If you don't agree with the argumentation, please let us know, in detail, where you disagree. What comes to the method of passing the hint, I (and the whole design team) really wish the hint could be placed somewhere else. However, we just haven't been able to find such a way. We would be more than happy to use some other method, but we just haven't been able to find one, given the constraints. On a practical point, I don't see how this fits with the addressing architecture (draft-ietf-ipngwg-addr-arch-v3-07.txt) which requires that For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. It also doesn't fit with the RFC 3041 privacy extensions. I'll let Erik to address this one, my knowledge fails here. --Pekka IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Securing Neighbor Discovery
Dan McDonald wrote: Your attacker is often a legitimate user of the link. James Kempf wrote: Right, that's the point I was trying to bring up in my response to Alex. Just because someone has undergone AAA successfully doesn't mean that they won't disrupt the link. I completely agree. Additionally, I'd like to see an infrastructureless solution to be used anywhere possible. Why? Basically because an infrastructureless solution means that we can make it to work with zero configuration, while any infrastructure necessarily needs that either the initial credentials must be configured or that new nodes must learn the credentials of the infrastructure through leap of faith. Dan McDonald wrote: In a perfect world, ND would allow a host to only do host-type things, and then only on behalf of the host itself. ... Solve the aforementioned Jeff Schiller problem, and you probably can secure ND. If you can't, all such solutions will just limit your troublemakers to who is allowed on the LAN. ... James Kempf wrote: What we were trying to do in the ABK draft was provide a way that a node on the link could determine definitively that a particular ND/RA message came from the node/router possessing that identity. There main issue is some way to establish the right of the node to possess that identity beforehand, and we included sketches of a couple ways that seem consistent with current practice. We probably need to flesh these out some. That said, ABK is a new an largely unknown technology. In the security area, old and well trusted technologies are often easier to make work, because the holes are well known and can be patched around. So a solution based on IPsec, should it be possible to make it work and prove secure, would certainly be of interest. Already a year ago I tried to point out that CGA can be used to solve the ND security problem. Since CGA is able to securely bind a public key to a interface ID, you can use CGA to verify that the right party speaks for the interface ID. That seems to be sufficient to solve ND. However, it doesn't help much with router discovery. Personally, I think that ABK might have great potential for router discovery, since ABK can to convert even network prefixes into public keys. Now, if we just could figure out how we could use ABK to somehow express trust relationships between more covering prefixes (e.g. 3ff0::/16) and subprefixes (e.g. 3ff0:1::/20), then we would have something... Back then I also wrote an I-D, which describes one method how CGA can be used for ND. For various reasons that I-D never got published, but it has been available and is still available at http://www.tml.hut.fi/~pnr/publications/draft-nikander-ipng-pbk-addresses-00.txt The basic ideas are also described in Pekka Nikander, Denial-of-Service, Address Ownership, and Early Authentication in the IPv6 World, presented at Cambridge Security Protocols Workshop 2001, April 25-27, 2001, Cambridge University. To be published in the workshop proceedings at the LNCS series. A pre-publication version of the paper is available at http://www.tml.hut.fi/~pnr/publications/cam2001.pdf --Pekka Nikander IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: [mobile-ip] Re: IPv6 ingress filtering early access
Michael Thomas wrote: So here's a most-likely crazy idea: why can't we treat the ingress filtering router like a CN which must first be sent a BU which it verifies in whatever manner the CN would? This already has a requirement to not be bound to mythical PKI's, etc. Given FMIP, the access routers are probably going to end up having to process things like BU's anyway. I was drifting into this direction myself. But how? Introduce a new ICMP message saying: send me a BU if you want to use HAO? Also: if we have ingress filtering taken care of directly, is there any reason to preserve the HAO at all? I thought its entire raison d'etre was to provide a means of coexisting with ingress filtering -- which we've already proven is just shifting the problem around instead of providing something useful. Now THAT sounds like the most reasonable thing that I have heard about ingress filtering for a long time! To me, it seems like combinding RR and CGA, the ingress filtering router can fairly easily determine that the MN really owns the home address, and thereafter pass it. As an immediate reaction, the only problem seems to be that CGA requires fairly heavy CPU load. Could RR be enough in this case, since the CoA and HoA are on the different sides of the router? --Pekka Nikander IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: IPv6 ingress filtering early access
Francis, I wrote: Thus, making your system to help at all, it would require that EVERYBODY ELSE FORBIDS Home Address Option altogether. Francis Dupont wrote: = everybody else is better than everybody (:-). I think the main reason for our disagreement is that you mostly seem to think that MIPv6 will be employed by operators. I don't. If MIPv6 will ever become common, I certainly want to run my own MIPv6 Home Agent, in the same way I am running my own DNS server, my own SMTP server, etc. That is, the only service that I buy is IP connectivity, and I really really really want to have an Internet that allows you to buy IP connectivity, and provide all of the rest of the infrastructure yourself. I don't want to be part of a global AAA. [Personally, I would consider such a requirement fascist.] Now, returning to the real issue. I just want to second Jari Arkko's statement: A. We seem to agree that HAO may be dangerous since it potentially makes IP traceback more difficult. B. There seems to be two possible solutions: B.1 Make the Binding Cache hard state instead of a cache. That is, mandate that CN accepts HAO if and only if there is a corresponding binding in the binding cache. (Or, at minimum, that it keeps trace of received HAOs for traceback purposes.) B.2 Mandate that every ingress router everywhere in the Internet either checks that the HAO is legitimate, or drops it. That is, my (possibly flawed) understanding of your ingress filtering draft requires B.2. If B.2 was mandated, the CN could accept HAO and rely that it is authentic. On the B.1 case, on the other hand, it is the CN's responsibility to decide whether to rely on HAO or not. As far as I can see, that is the difference. As a practical result, B.1 allows anybody to use MIPv6 security protocols (whatever it will be), establish bindings, and use HAOs. B.2, on the other hand, would restrict where you can use BUs, and that your home agent must be part of the still-not-existing global AAA infrastructure so that you could use HAO. As a result, all the work that we have done with RR and CGA would be unnecessary, since you would mandate AAA, and while you are mandating it, you just could use it for basic MIPv6 security as well. Francis, if you insist to keep your opinion that B.2 with all its consequences is better, there is nothing I can do. On the other hand, if I have really misunderstood the practical consequences of your draft, please enlighten me, and explain in detail how you expect it to work so that MIPv6 route optimization could still be used by private persons and small organizations that are not part of the alledged global AAA infrastructure. --Pekka Nikander IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: IPv6 ingress filtering early access
I wrote: The draft is quite nice, thanks for writing it. There are a few problems, though, that I see. Firstly, I really do find it unrealistic to assume that each and every site in the world would understand AAA, and change their ingress filtering rules based on AAA information. Francis Dupont wrote: = this is not exactly I propose, my idea is: - to do better ingress filtering based on AAA for sites where there are some mobile nodes (aka visited sites). Why do you assume that AAA would be used everywhere where there are mobile nodes? For example, if I am visiting with my friends at their place, why couldn't I just use their private WLAN to connect my wireless PDA to the Internet? If I could not use their private WLAN, I would consider that as a flaw in the design if the Internet. Similarily, our local university campus provides open WLAN for anyone, for anyone to connect to the Internet. It is so much simpler to run these kinds of networks without any kinds of authentication that they will continue to exist, even though many current open WLAN networks may turn into requiring some kind of authentication. But even when they start to require authentication and/or authorization, that authentication or authorization is more likely to be based on 802.1x or PANA than AAA, and even if RADIUS/DIAMETER is used, the non-ISP connectivity providers are unlikely to be part of the AAA infrastruture. For example, I run an open WLAN at my home, and even though I may require some kind of authentication in the future, it is very unlikely that I would run RADIUS or DIAMETER. Thus, making your system to help at all, it would require that EVERYBODY ELSE FORBIDS Home Address Option altogether. It is not only a mobile host that can send HAO, any host can send it. If an intruder can break into 10 million poorly protected home PCs, they can be converted into MN looking devices that send fake HAOs. Sure the ISP can drop all packets containing HAO sent from their home customer sites, but that would break the ability to use your PDA/other device through your friend's WLAN while visiting at their place. Do you see my point now? - to do better anti-spoofing filtering for sites from where some mobile nodes are (aka home sites). I do not argue with that part. You draft may well have some value protecting the home sites of MNs. There is no constraint on sites where are the regular correspondent nodes (aka correspondent domains) which should be the vast majority of sites. As I said above, either you must assume that any site can host MNs (in addition to CNs), ---or--- you must forbid sending HAO containing packets from those sites that are assumed not tho host MNs. My main point is that forbidding HAOs to be sent from the majority of the Internet would largely foil the purpose of Mobile IPv6. I don't know how this is done everywhere but in many sites I can see a special network for nomadic nodes with special network access control and small priviledges just because by definition local network managers have not the control of them, so IMHO this is not unrealistic to ask to sites which welcome mobile nodes to have a responsible attitude towards security. My point is that almost every home will, in the future, be a potential site hosting MNs. Secondly, such a the proposed practice would basically foil all of the designed zero-configuration nature of IPv6. That is, the reason for IPv6 stateless autoconfiguration is to allow hosts to be plugged in to a IPv6 network without any prior configuration. IMHO, such a practice would be very good in many environments, even in public access WLANs. (I know that some people disagree with me.) = this is very unrealistic because this forgets the third letter of AAA. And of course this doesn't go well with the responsible use of the network principle. Most homes do not even know about responsible use of network principle. It is just that since you can buy an Apple Airport (or whatever) from your local shop, and set it up within minutes, that will happen. Actually, it is already happening in many places in the US and scandinavia. Remember me setting up an WLAN access point at IPCN'2001 in Paris? - Now, the point is that those are also exactly the organizations that are most _unlikely_ to use advanced ingress filtering methods, = the solution in this case is just to filter out HAO, i.e. to refuse mobile nodes. ... and what I am saying, such a practise is unreasonable and would severly restrict our possibility to use the future Internet. In other words, madating that ingress filtering MUST refuse HAO (unless special means is used to ensure that the Home Address is valid), besides being expensive and unrealistic, would result in MIPv6 being used only be the telecom vendors, not by the rest of us. --Pekka Nikander
IPv6 address ownership and autoconfig problems (was Re: [mobile-ip] Routing header Vs tunneling
Glenn, [I am redirecting this to ipng, in addition to mobile-ip, since the address ownership problems are a larger issue than just a Mobile IPv6 security thing.] Glenn Morrow writes: What prevents a node from obtaining and using any number of free or not free (i.e. in use by another legitimate node) IP addresses such that they can spoof addresses albeit only on the same subnet IF INGRESS FILTERING is used on the first hop. Use of IPSEC is not mandated. Use of INGRESS FILTERING is not mandated, either. What is the interaction with control lists, etc.. etc.. etc.. Are there any provisions for anti-mac-spoofing, etc.. etc.. etc.. Pekka's draft which detailed most of the holes has expired, perhaps he is listening and will republish it. The old address-ownership draft is available at http://www.tml.hut.fi/~pnr/publications/draft-nikander-ipng-address-ownership-00.txt If there is demand I'd be happy to revise it. Would it be useful to revise it and publish it as an informational RFC? Please note that many of the issues discussed in that draft are also discussed in my Cambridge Security Protocols Workshop paper, which will eventually be published in the LNCS series. A pre-publication version of that is available at http://www.tml.hut.fi/~pnr/publications/cam2001.pdf BTW, while you consider ingress filtering etc, you may find it entertaining to read our recent half-serious half-joking paper titled IPv6 Source Addresses Considered Harmful, available at http://www.tml.hut.fi/~pnr/publications/nordsec2001.pdf --Pekka Nikander IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Comments to draft-castelluccia-sgmv6-00.txt
Claude, [I am not a member in msec or smug, and therefore I don't know if this point has been taken up there already. It may even be that my message is rejected from those list due to my non-membership status.] I find the idea presented in the draft very refreshing and beautiful. The fact that multicast group IDs are 112 bits (instead of 64 bits) makes it work even better than for basic SUCV/CAM. On the other hand, since I am no expert in multicast and have only a very bad understanding on how you create new multicast groups in the first place, I cannot comment that side. Anyway, in Section 5.3 you write: 2. The private key, the public key, the counter and the GroupID are distributed to the (authorized) group members. Note that private key requires confidentiality because it only has to be known to the authorized group members. The public key, the counter and the GroupID can be sent in clear but require integrity. Now, I was left wondering why to send the private key itself? If we assume that all the hosts in the multicast group have their own public/private key pair (e.g. for basic SUCV or in order to authenticate them for some other reason), wouldn't it be easier just to delegate the right to join the multicast group? That is, instead of sending the private key, you would send an SPKI or KeyNote2 certificate stating that the public key of the host is authorized to join the multicast group represented by the group key? Delegation would make key distribution easier. Instead of sending the private key in a secure channel you just distribute the certificate. You don't even need to authenticate the member host if you know its public key beforehand. The certificate could take care of the integrity of the group public key, the counter and the GroupID, i.e. it would basically be a self-signed certificate. Furthermore, the delegation model would have additional benefits, i.e. it would allow better control of membership. If you add validity time to the certificate, you could control how long the hosts are members of the group. Secondly, if you distribute the private key, any host in the group can leak the private key, and you don't know who it was. In the delegation model, if a host leaks its own private key, you definitely know who it was, and you don't renew that host's certificate when it expires. (I assume, here, of course that the certificates would have relatively short lifetime, e.g. in the order of minutes or hours.) The delegation approach would also help with the replay attack problem (Section 6.3), since it would effectively limit the validity of the reports with the validity of the certificate. I am not so sure about the anycast case, though. My understanding about anycast is that in anycast you want all anycast hosts to behave equally. Therefore they should look the same, and distributing the private key might actually be a good idea. --Pekka Nikander IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: draft-kempf-ipng-netaccess-threats-00.txt
If somebody wants to build a network where anybody can walk up and connect yet want to limit the damage one visitor can do to another, it seems like assuming pre-configured IPsec SAs for the multicast addresses used by Neighbor Discovery is a non-starter. I completely argree. You may also want to have a look at my Cambridge Security Protocols Workshop 2001 paper. Pekka Nikander, Denial-of-Service, Address Ownership, and Early Authentication in the IPv6 World,, presented at Cambridge Security Protocols Workshop 2001, April 25-27, 2001, Cambridge University. To be published in the workshop proceedings at the LNCS series. http://www.tml.hut.fi/~pnr/publications/cam2001.pdf --Pekka IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
A method to prevent DoS in IPv6 DAD and Mobile IPv6
A number of recent ID:s have shown a number of potential security deficiencies in the way IPsec is used in a number of IPv6 signalling functions, including Duplicate Address Detection (DAD) and Mobile IPv6 Binding Updates (BUs). The relevant drafts include the following. draft-arkko-icmpv6-ike-effects-00.txt draft-nikander-ipng-address-ownership-00.txt The so called PBK-keys (draft-bradner-pbk-frame-00.txt) attemts to solve the Mobile IPv6 related problem by proposing a new class of identifiers, EIDs. In some respects that approach is similar to the HIP approach. While thinking about the problem, an idea of using the IPv6 interface identifier as a cryptographic token appeared to me. That is, by generating the interface identifier from components using a cryptographic one-way function, one can "bind" the interface identifier to the components, and the base security on the components. The idea is very new, and comments are solicited. Currently a working copy of the forthcoming -00 drafts is available at http://www.tml.hut.fi/~pnr/publications/draft-nikander-ipng-pbk-addresses-00.txt I'll be working with the draft during my flights to Minneapolis, posting is as soon as drafts are accepted again. There is currently a plan to discuss related issues at the Mobile IP WG meeting and the SAAG session on Thursday. --Pekka Nikander Ericsson IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
A new I-D on authorization issues in IPv6
[My aplogies for sending this to three separage lists, but IMHO this is really relevant to all of them.] A have submitted a new I-D concerning a number of authorization issues in IPv6 related signalling, including Mobile IPv6 Binding Updates. The purpose of the I-D is to summarize and clarify the situation from this specific security point of view. As it has not appeared in the archieves yet, it is also available at http://www.nomadiclab.com/~pnr/publications/\ draft-nikander-ipng-address-ownership-00.txt I hope that the draft can act as one input to the the forthcoming Mobile IPv6 discussion to be held at Minneapolis, and clarify some issues related to using IPsec in IPv6 to protect various kinds of signalling messages. For your convenience, I've included the draft abstract below. --Pekka Nikander Abstract This document seeks to clarify a number of problems related to authorization of changing local routing information in the current IPv6 architecture. This document does not (currently) cover actual routing protocols. Instead, in IPv6, there are a number of additional mechanisms that allow local routing information to be changed. Some mechanisms are meant to be used only locally, while someof them allow changes to be initiated from a remote location; in the latter case, IPsec is used to protect the relevant signalling messages. However, the current specifications are partially obscure about the actual authorization requirements that must be met in order to be actually secure. The purpose of this document is to clarify the situation, and foster understanding of the potential attacks and required countermeasures. In this document, we first collect together and summarize the non-routing-protocol mechanisms that allow routing information to be changed. After that, we classify the mechanisms using a couple of orthogonal dimensions. Finally, we discuss the authorization requirements for the different mechanisms. It is important to note that the security problems discussed in this document become relevant only when we start to consider multiple security domains. As long as the mechanisms are used only within a single security domain, where all nodes are equally trusted, the problem does not exist. However, if several security domains are connected together, or if anything like "opportunistic IPsec", as promoted by John Gilmore, becomes reality, the problems discussed in this document will become very real. An other way of expressing the scope of the problems is to say that the attacks can be characterized as insider attacks. In general, the IPsec architecture, as it stands today, is relatively good in keeping outsiders out. However, it is currently not nearly as good at dealing with attacks from within. In a way, when IPsec is used to protect application level traffic, the applications are assumed to take care of their specific protection needs, e.g., in the form of user names, passwords, and application or operating system access control lists. Unfortunately, when IPsec is used to protect traffic signalling, as discussed in this document, the controls do not seem to be adequate. Basically, this is an authorization problem. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
