Re: Mobile IPv6 - IPsec interaction.
Pekka Nikander <Pekka.Nikander@nomadiclab.com> Sun, 07 January 2001 22:45 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06700; Sun, 7 Jan 2001 14:45:13 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA13886 Sun, 7 Jan 2001 15:00:59 -0500 (EST)
Message-ID: <3A58CB69.9F8A36D2@nomadiclab.com>
Date: Sun, 07 Jan 2001 22:02:48 +0200
From: Pekka Nikander <Pekka.Nikander@nomadiclab.com>
X-Mailer: Mozilla 4.76 (Macintosh; U; PPC)
X-Accept-Language: en
MIME-Version: 1.0
To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Cc: Mohan Parthasarathy <Mohan.Parthasarathy@Eng.Sun.COM>, Richard Draves <richdr@microsoft.com>, ipsec@lists.tislabs.com
Subject: Re: Mobile IPv6 - IPsec interaction.
References: <200101071902.f07J2dO66629@givry.rennes.enst-bretagne.fr>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
[I don't think there is anything _very_ important in this message. I think the important discussion will handle the case of MN-temporary HA, and I will give it a separate thread. This message is more like a number of clarifications for minor points, and may not be that interested for some people. Most of the discussion concerns the disagreement between Francis and me about static vs dynamic IPv6 address assignment skenario.] --------- > I agree. It is one of the best impersonating tools. Unfortunately, > IPv6 offers you a number of almost equally good alternatives, > including the routing extension header and generic tunneling. > > => I disagree about routing header and tunneling because mobility > changes the ultimate destination itself. I don't think this belongs to the discussion about Mobile IPv6 - IPsec interaction. Thus, if you want to learn my argumentation, let's start a separate thread of discussion. --------- > Sure, there will be also static addresses like the addresses of > root name servers and many big web and corporate servers. > > => only root name servers must have a static address. Other addresses > will be rather static only because this is easier to manage static > addresses than highly dynamic addresses. I agree to a large degree. Well, maybe I would rather say that IF we do not specify otherwise, a rather static situation is likely, but I would consider it bad. (See below.) > But the majority of clients will use stateless autoconfiguration, ... > => The only case with frequent address changes is for privacy > (ie. draft-ietf-ipngwg-addrconf-privacy-xx.txt) but in this case > you don't want incoming connection or be registered in the DNS too. Well, that is, if you assume that the majority of clients will be static, i.e., non-mobile clients. I believe that the majority of clients will be mobile clients, and that some of them will not use any home addresses at all. But even if we assume that they will use home addresses (a large portion may, anyway), then the question of whether the home addresses will be static or dynamic is a policy question. I agree that using a static policy, i.e., always giving out the same home address for the same host, is the easiest and simplest from the engineering point of view. However, from the privacy point of view that may be a disaster. Since this is the ipsec mailing list, I assume that we should care about privacy, as I see privacy as a part of (personal) security. --------- > a1) During a certain period, i.e., address lifetime, I want to have > _some_ assurance that the packets sent to a certain address > will be received by the very same host. It seems like a > typical _client_ address lifetime will range from tens of > minutes to a few days. > > => this will kill the DNS for sure. How? As one approach, already know my laptop is know, at various times, as wsXXX.nomadiclab.com, where the XXX is likely to differ from time to time. As the other approach, you can configure W2K to do dynamic DNS registration whenever it gets a new (IPv4) address. I may be wrong, but my understanding is that DynDNS registration is not that much heavier than sending a BU to a home agent. (If I am wrong, please educate me and indicate the relevant sections of the drafts/RFCs.) And, you would not be sending DynDNS updates that often; I would guess that the average rate might be something like from one to a few times a day. ---------- > (Yes, I know, some people strongly disagree with me. They > want the client addresses to be static. But I don't believe > that they ever will.) > > => I want the address to be as static as possible because to get dynamic > addresses makes incoming connections too hard. Please teach me. I don't see how dynamic addresses will make handling of incoming connections any harder. Well, I can see how it makes address based filtering harder, but as I argued already, address based filtering is bad anyway, and should not be used. But how it will make it harder otherwise? ---------- > .... If we assume that the CN is a typical web server, > I cannot imagine how it could possibly care? To the web server, the > important thing is to get the content delivered. > > => for some contents it will be important to deliver them to the right place. Yes, for some content, sure. But if you want to know where you deliver your content, you need encryption, and then you need well authenticated (and authorized) IPSEC or SSL for all traffic, not just a (pair of) simple AH SA(s) for authenticating BUs. To clarify: I believe that MIP6 BUs could be authenticated with a "low security" SA. The samantics of the low security SA would be "this SA is authorized to send BUs for this Home Address." Such an SA would not necessarily need any global PKI or anything like that. For such an SA, it is not important whom the address belongs to. It is enough to bind the address and the SA (the key). On the other hand, if you want to know whom you send you content, you definitely want to know that the recipient is authorized to receive the content. For such a purpose, a "low security" SA is not enough. Maybe we should discuss this point separately? --------- > I really can't see > how its administrators would be careful enough to configure it to > check that an arbitrary mobile host is really entitled to use a > certain home address. > > => I believe its administrators will simply reject arbitrary IKE request > (the important thing is not to waste CPU cycles in big number computations :-). Well, I can't see most people taking that position for many many years. To them, taking that position would most probably mean that they lose business with almost all mobile hosts. Or that they are not able to use BUs and must send all traffic through the home agent, making most benefits of Mobile IPv6 void. But maybe it will be so, anyway, on the light of your next comment. (Yes, I know, IKE is not too DoS resistant today. But that problem should be fixed, anyway.) > On the other hand, I can easily imagine that the OS vendors, for the > sake of Internet integrity, would include some default mechanisms > in their IPv6 implementation. > > => for instance use DNSSEC to check the home address or simply reject > IKE phase II or the binding update (I expect to have Web servers rejecting > binding updates because common sessions are short term). Good point. I stand corrected. I must reconsider my position wrt. the typical usage skenarios for MIP6. Thank you. ---------- >> 3. MN--temporary HA I think that we are entering some very interesting discussion here. Thus, to keep the messages of manageable length, I will reply separately. --Pekka
- Mobile IPv6 - IPsec interaction. Mohan Parthasarathy
- Mobile IPv6 - IPsec interaction. Tero Kivinen
- RE: Mobile IPv6 - IPsec interaction. Franck.Le
- Re: Mobile IPv6 - IPsec interaction. Tero Kivinen
- RE: Mobile IPv6 - IPsec interaction. Tero Kivinen
- Re: Mobile IPv6 - IPsec interaction. Mohan Parthasarathy
- Re: Mobile IPv6 - IPsec interaction. Derek Atkins
- Re: Mobile IPv6 - IPsec interaction. Francis Dupont
- Re: Mobile IPv6 - IPsec interaction. Francis Dupont
- Re: Mobile IPv6 - IPsec interaction. Derek Atkins
- Re: Mobile IPv6 - IPsec interaction. Francis Dupont
- Re: Mobile IPv6 - IPsec interaction. Derek Atkins
- Re: Mobile IPv6 - IPsec interaction. Francis Dupont
- Re: Mobile IPv6 - IPsec interaction. Derek Atkins
- Re: Mobile IPv6 - IPsec interaction. Francis Dupont
- Re: Mobile IPv6 - IPsec interaction. Pekka Nikander
- Re: Mobile IPv6 - IPsec interaction. Angelos D. Keromytis
- Re: Mobile IPv6 - IPsec interaction. Pekka Nikander
- Re: Mobile IPv6 - IPsec interaction. Francis Dupont
- Re: Mobile IPv6 - IPsec interaction. Francis Dupont
- Re: Mobile IPv6 - IPsec interaction. Pekka Nikander