IKEv2 Mobility and Multihoming WG
IETF 62, 2005-03-07 09:00-11:30
Salon G, Hilton Minneapolis, Minneapolis, Minnesota
Chairs: Jari Arkko and Paul Hoffman
Scribes: Maureen Stillman and Kristian Slavov (during meeting),
Pasi Eronen (based on recording)
http://www.vpnc.org/ietf-mobike/
Minute editor's (Pasi Eronen) note: these minutes include mainly the comments,
questions and answers from the meeting, but do not repeat the
presentation slides. The timestamps refer to the raw recording of the
meeting, ietf62-ch5-mon-am.mp3.
1. Agenda and document status by chairs
(13:30-)
Francis Dupont: My draft about transport is not to apply MOBIKE
to transport, but rather describe all things you can do once MOBIKE
is more defined.
2. Design of the MOBIKE Protocol by Hannes Tschofenig
(18:45-)
Jari: The presentation starts with several examples, but let's
have the discussion only when we get to the issue slides.
Terminology and scope of MOBIKE work
23:05 comment from Francis
Issue discussion starts (30:00)
Paul: Only about 20 issues, half closed now. We'll discuss only
open issues during this meeting. Decisions are made on the mailing
list, not here or today.
Issue 20 (38:30-)
Pasi: The differences between these options happen only if
both ends have several addresses.
Jari: I like the initiator decides approach, one reason is
that when you have lots of clients connecting to a single gateway,
it's easier if the gateway does not do complex things and the
intelligence is in clients.
Bill Sommerfeld: I assume this is the IKE level initiator,
not phase 2 initiator?
Paul: Yes. This is a good question that recently came up
in IKEv2 bakeoff: there are two initiators, the initiator
of any given exchange, and the original initiator who started
the first IKE exchange. But yes, we're talking about the IKE
initiator, not exchange initiator here.
Francis: I don't understand what's the real difference between
primary address (editor's note: later called "option 5") and
initiator decides? Initiator decides is only for mobile to gateway
case, primary address is more general?
Hannes/Francis: (more discussion about this topic)
Francis: It seems initiator decides won't with two multihomed
gateways, because it makes one of the two peers more special than
the other.
Pasi: It does work, both ends can change addresses, but changing
addresses is separated from selecting which of the available
combinations to use. In option 2, each peer selects which of its own
addresses gets used, but this does not work, because we already
decided that we don't assume all combinations work.
Paul: So of these options, only option 3 makes one side more special.
Francis: We have to discuss this on the list, I don't quite see
what's the difference between the proposals.
Bill: If one of responder's addresses stops working, responder
can tell initiator, and initiator picks a new pair? I think that's
the right way to go, especially if you have a stateful firewall.
Paul: We will discuss NATs more later, but we should not pick any
proposal that completely breaks if there's a stateful firewall.
Jari: The difference between options 1 and 3, in option 1 both
peers make two decisions: what their own addresses are, and what
pair to use for traffic. In option 3, peers still decide their own
addresses, but initiator decides which pair to choose.
Francis: Option 2 is obviously broken. You should use primary
address given by the peer as destination, but choose source address
yourself, like source address selection in IPv6 (editor's note:
later posted to mailing list as "option 5").
Issues 18/6/15 about return routability (54:00-)
Paul: If address is in the certificate, it's not very relevant
especially if it's an address range.
Tero: Most certificates don't have address ranges, only
individual addresses.
Jari: Two different situations we are guarding against: complete
outsiders where cookie-based test helps; the remaining stuff is
about whether we trust the IKEv2 peer or not. In typical VPN case,
we do, but in BTNS or opportunistic IPsec cases we might not trust
the authenticated peer very much. So making this configurable might
be good.
Hannes: In mobile IP there are no return routability mechanisms
between mobile node and home agent.
..continues...
Francis: We have to be more accurate when we talk about testing
"before starting to use" or after; use for IKE or IPsec?
Paul: We're probably talking about IPsec, it's hard to bomb
someone with IKE traffic.
Jari: Yes, this is for IPsec packets.
Issue 11 about window size (61:30-)
Francis: This is a bit related to the previous issue. I believe
you don't need window size more than 1, you can retry the dead
peer detection using the new address.
Charlie: It would be better to retransmit one message than to
take advantage of a larger window size, since the protocol can't
make progress unless all messages are acknowledged eventually.
Pasi: Retransmitting previous message works fine if the message
was dead peer detection, but gets complicated if the message was
something whose processing on the receiving end depends on the IP
addresses in the IP header. Basically, MOBIKE messages for changing
paths. This is the tricky case, you've started to move the traffic,
but interface goes down before you've finished.
Jari: If we are in the middle of an exchange, and something bad
happens, we cannot do another mobike message exchange since the
previous packet is blocking it.
Paul: From the bakeoff, a number of implementors are not planning
to do window size greater than one.
Issue 19 (67:50-)
3. MOPO-IKE by Pasi Eronen
(70:20-)
Example about path test message (75:00)-
Paul: This is important issue, do we want to know the status of
all address pairs all the time, or it is enough to know one pair
that works.
Tero: What happens to the original information exchange? Do we
retransmit that using the new addresses?
Pasi: Good catch, the slide has a mistake. Yes, we retransmit
it using the new addresses before sending the change path message.
Tero: If we are going to retransmit the original message anyway,
why do we need a separate path test message?
Pasi: It works fine if the message was dead peer detection. One
case where a separate message helps is if you want to test the old
path to see if it has come back up before you decide to move the
traffic, and without disrupting the traffic on the working path.
Tero: I'm not sure a separate message is needed.
Pasi: It may be possible to avoid it, but probably complicates
the protocol.
Jari: What happens if the message was a MOBIKE message about
changing paths, instead of dead peer detection or creating a child
SA?
Pasi: In MOPO-IKE it actually works, because the IP addresses are
not inside the IKE payload, but in the IP header.
Return routability (83:45-)
Raj Patil: Is this to address same threats as in MIP?
Pasi: No, this is a different threat; MIP does not do return
routability between MN and HA, because that threat was not
considered important. Here it's not considered very important
either, but we do it anyway because it's easy.
Raj: What do you get by doing it?
Pasi: If I connect to my VPN gateway, I can't claim to be
somewhere that I'm not. Basically, authenticated client can't do
denial of service (on itself, really) so easily.
Jari: MIP does not do the test between MN and HA, but perhaps it
should have done. For VPNs, this does not matter that much, but for
some future zero-config things, we might not be able to trust the
other party that much.
Conclusions and moving forward (91:30-)
Jari: Interest usually comes with a window of opportunity, it
does not last forever. I agree that we should pick a good enough
solution rather than wait for a perfect one.
4. NAT-related issues from design presentation by Hannes Tschofenig
(95:00-)
UDP encapsulation (100:10-)
Jari: Is UDP encapsulation dictated by policy or detection of
NAT?
Hannes: You might want UDP encapsulation even if no NAT was
detected, if you have a stateful packet filtering firewall.
Pasi: In normal IKEv2 NAT traversal, client can claim to be
behind a NAT even if it isn't. This might be useful if a stateful
firewall wants to match incoming and outgoing packets, and it can't
do that with plain ESP.
..continues..
Pasi: Is there a need for more complex policies that NAT-T
on/off?
Hannes: Related to NAT prevention, if you are certain that you're
not behind a NAT, you could use information from IKE payload instead
from IP header.
Paul: Is that even allowed in IKEv2 NAT-T?
Pasi: NAT prevention is something you can do if you don't support
NAT-T.
Tero: For example, if you have two multihomed VPN gateways, and
you know there never are NATs, you can disable NAT traversal and, in
addition to that, authenticate the IP address changes. So you want
to move the information from IP header, which is not protected,
inside the payload.
Hannes: Another issue is whether we do NAT detection each address
pair.
Pasi: Yes, we don't have global NAT present/not present flag, but
flag for each address pair.
Paul: Why would you not do it, if you have the capability?
Responder behind NAT (108:50-)
Paul: BEHAVE WG is also working on NATs, but from a different
point of view.
Pasi: Much of the work in BEHAVE is for people who build NATs,
but we're not building NATs, but rather working with existing NATs.
Hannes: They also have terminology about classification of NATs
that we could use.
Francis: Two concerns about NAT traversal. We already have NAT-T
in IKEv2 which works well. And there is lots of IPR about that.
Paul: If you know about any IPRs about the things we're working
on, it's your responsibility to notify IETF. IETF web pages have
instructions.
Francis: I know only the IPRs which are already on the web page.
Pasi: Since MOPO-IKE reuses IKEv2 NAT traversal, same IPRs
obviously continue to apply. But it's good to keep implementing
NAT-T optional, so that you can implement MOBIKE without NAT-T if
you want.
James Kempf: Would it be sensible to have NAT support in a
separate draft?
Paul: Maybe, but maintaining many documents is a pain.
James: If NAT-T is holding up implementations then we should move
it to another draft.
Pasi: All the implementors I have heard of want NAT traversal,
and will not implement this without NAT support.
Jari: Agree with Pasi on that issue. About splitting the
document, base IKEv2 spec already has NAT-T in the same document;
we're trying to work with that, not respecify it.
Hannes: In basic IKEv2 NAT-T you do NAT detection in the
beginning, here we should do also when moving.
Conclusion
Jari: Next steps; it seems on most issues we have a common
understanding, so we'll try to get decisions made on the mailing
list.
Paul: If you have opinions about these issues, please post on the
mailing list, even if you have not been active in the mailing list
before. Even saying "yes, I agree" or "no, I disagree" is helpful.
(end at 123:10)