Jari explained how IPv6, DCHP, DNA etc together provide
a set of addresses and some local information about the
operational status.
He went on to explain how multihoming involves not just
a working/not working address but also address pairs
Jari suggested some design rules, including the one that MOBIKE
should rely on other parts of the stack to provide for the local
information, such as usable addresses (which is very different from
testing that a certain path works)
Paul Hoffman: Want to explain where mailing list has gone when
we have gone away from basics. A lot of proposals "you can do
this and you can tell what happens" comes from between
red lines between A and B. That's nice and may be true, but
doesn't cause interoperabilty. We should focus on the red line
near B. If we get away from nearness to A, we get away from
"it would have been nice if previous WG did such and such".
We need to focus this group on that problem if we get done.
James Kempf: Agree-needs to be end-to-end authentication.
Concern: mobile IP, had to define optional interface between
IPsec module and mobile IP module-- a little concerned that
something is being missed that might require this interface.
Jari: Can use IPsec for different purposes-- is that out of scope?
James: That interface came out of an interaction between
IPsec and mobile IP because of performance concerns. By saying
any suggestion is out of scope, may run into a performance
issue related to the API.
Pasi: We had this WG item PFKEY updates-- no one worked on that.
Clearly, getting something to work requires adding something
in yellow box.
Jari: Talked about a document about how IKEv2 and MOBIKE can
be used in conjunction with other protocols.
Vijay Devarapalli. Glad we had this discussion.
Charlie Kaufman: Confused.. beginning to think group is solving
different problem. Had assumed we had a mobility story that was
OK and IPsec story that was OK, and we needed to glue together.
Now, I think we are trying to construct a workable mobility
model (even if we were not negotiating any crypto). Is this
what you are trying to do? Is this building on top of perfectly
fine mobility, or not?
Paul: We are assuming that there is a mobility environment--not
that it is perfectly fine. We are not mandating a particular
mobility solution. We are using IKE to protect against
some of the mobility attacks.
Jari: We have several mobility stories in IETF. Some depend on
IPsec, like mobile IP, to secure its signaling.
Charlie: Would it work without IPsec but with security problems?
Paul: Yes, but from IETF perspective, then it doesn't work.
Pasi: Assuming that nowadays, a lot of times when you move,
you do have the keys, but you need to rebuild the VPN from
scratch. We are solving a very small problem-- not attempting
to be a general mobility solution.
Hannes: Surprised that many people got lost with a simple
problem. Mobile IP stuff-- in some environments, why do
you want to use MobIKE, on top the binding update, some naive
reader might wonder why you use Mobile IP at all?
Jari: Mobile IP does more.
Paul: Don't want to discuss this in our documents. Not precluding
any future working groups from doing that. This is to say:
"this does work and it does work securely, and to write out
the security properties."
Hannes: PFKey issue-- we have done some of that and it works-- not
a big deal.
Paul: Sounds like that might be a very short thing.
Pasi: Current PFKEY doesn't describe how implementations actually
work.
Paul: (?)
Mohan Parthasarathy (?): A and B connected by IPsec tunnel mode--
don't understand that. I don't know what it means to work with SCTP
multihoming then.
Pasi: Concern on mailing list that we will deal with tunnel mode first.
Jari: We haven't dealt with all of the issues there yet.
Francis Dupont: Mobile IP and MOBIKE are two incompatible solutions
for the same problem. hard to use both at same time.
Ashutosh Dutta: Is there a list of scenarios written down? Such
as, mobile is multihomed, move to external network? I think you are
mostly talking about starting from outside-- it works OK there. It is
harder when you start from internal.
Jari: If you have that situation, might or might not work. Not in our
scope.
Pasi: If you are not using IPsec inside, and you are outside, no,
we are not handling that case.
Paul: We are not going to go there, unless you have a protocol
proposal that doesn't affect our main protocol (to extend it). We are
not going to try to solve every possible mobility scenario. But we
might consider extending our charter downstream once we accomplish our
primary goal.
Pasi: I actually think, we should do this, then PFKEY, and go home.
Greg: i) how do we know that a problem exists? Our experience is that
you need a bunch of mechanisms from layer-2 up to potentially
application layer signaling. What would be helpful for me to understand
is some sort of OSI map, and that we are doing this much of it.
Pasi: Application service layer is up to IKE.
Greg: We set up large IPsec VPN, and people want to use a whole bunch
of different things to determine whether to take which tunnel paths, how
to define when an interface is no good anymore.
Jari: Which ones of this layer are mandatory to implement in the
context of MOBIKE? I think we can't mandate this. But I think we
need to assume dead peer detection, or some things have gone away.
Paul: If IKE module can take hints to do that, nothing in protocol
to say "don't think you're mobile only from the IKE info."
Gregory: Was expecting a slide to show those boundaries, would like
to know where those boundaries are.
Michael Richardson: We might take info from below, not above?
Paul: No, I said it was easier to take from below than from above.
Subir Das: Is it correct that I move to another link and inform.
Does Mobike validate that path or reachability?
Pasi: At some point, there will be IKE message somewhere-- if it
doesn't get through, it doesn't work (implicit path validation).
IKEv2 has DPD on that link anyway.
Gregory: Clarify-- "we do not want want to reinvent DHCP"
Today we have configuration payload..
Jari: Yes, but that is inside the tunnel.
Paul: Can you see a scenario for changing the inner configuration?
Gregory: Come from outside to inside (now on an inside address).
Jari: Doesn't necessarily work if you disable or enable IPsec
on these movements-- we are out of scope there.
(end)
