[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Mobile IPv6 - IPsec interaction.
[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
Follow-Ups:
References: