[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Mobile IPv6 - IPsec interaction.
In your previous mail you wrote:
[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.
=> MN-temporary HA is an optimization. The important point is
more scalable MN-CN IMHO.
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.]
> 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.
=> a mobile client can get a static address (the home address).
I don't believe you can bind mobility and dynamic address this way.
I believe that the majority of clients will be mobile clients, and
that some of them will not use any home addresses at all.
=> they will need static/home addresses for incoming calls.
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 disagree. There are many advantages to have a static home address
so users will ask for them.
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.
=> for the user point of view too.
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.
=> the privacy is the only argument in favor of dynamic address but
you can't have at the same time privacy and strong authentication
(so I suggest to put mobility support for private addresses into
the further study list because mobility requires strong authentication
at least.
> 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?
=> because this will require DNS TTL in order of minutes so a lot of
DNS traffic and the end of DNS caching.
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.
=> and how you can accept incoming connections? The Internet is an
end-to-end network (or should be), not an online service.
As the other approach, you can configure W2K to do dynamic
DNS registration whenever it gets a new (IPv4) address.
=> you should not use W2K about what to do with DNS (:-).
Seriously the purpose of DynDNS is more to provide an incremental
and light weight tool for zone management than to support nomadism
(it can do both but not with the same impact on the DNS infrastructure).
I may be wrong, but my understanding is that DynDNS registration is not
that much heavier than sending a BU to a home agent.
=> the indirect effect is very different (ie. short term DynDNS
registration will make DNS caching inefficient, BUs are burden
only for CNs which receive them).
(If I am wrong,
please educate me and indicate the relevant sections of the drafts/RFCs.)
=> RFC 1912 section 2.2 about TTL values (one day is considered as too short
for the default value in this document). Or any document about DNS
configuration...
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.
=> the problem of updates is not in their direct traffic but with their
indirect (ie. induced) traffic. The current DNS traffic is far higher
than it should be, don't make things worse...
> (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?
=> each time a dynamic address changes you need to update the DNS.
In order to get the old address expired in DNS (and application) caches
you must use very short TTLs. This makes the job of remote applications
very expensive, in fact they should ask the DNS for your address each time
they send a packet to you...
> .... 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,
=> no, you need only authentication by definition.
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.
=> I've already seen this argument. Personnally I have nothing but
to make as most as possible connections protected by IPsec (I don't
like SSL because it is too often misused and it doesn't protect
against some attacks like TCP resets, but this is out of the scope).
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).
=> what you are describing is a policy.
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.
=> again a policy issue.
Maybe we should discuss this point separately?
=> I agree and I don't know if this kind of policies is commonly
available/implemented (you have such a thing in SPDs but here you've
asked for a phase I / phase II interaction far more complex than
the one we need for mobility).
> 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.
=> I believe the web CN is not a very good example because MNs will use
web proxies. In fact the number of CNs used by a MN will be rather small,
even with a static station we use a relay MTA, DNS server, Web proxy,
..., and we have active connections to a small number of nodes, most of
them "well-known". Of course this won't be true with a mobile server...
Thanks
Francis.Dupont@enst-bretagne.fr
PS: about MN-temporary HA: this is not an important issue and a potential
temporary HA with a lot of MNs should be in a very special situation,
likely a part of the design of the temporary HA with nice tools like
a working AAA interfaced with IPsec and mobility (ie. we'll be allowed
to assume more in this specialized context).
References: