Subject: RE: [Mobike] about draft-ietf-mobike-protocol-01.txt (issue 40)

From: <[email-masked]>
Date: Wed, 7 Sep 2005 19:20:46 +0300

My apologies for the long delay (I was on vacation most of
August, and your email somehow slipped through my mind).  I've
now filed your comments as issue 40 (although since you had
quite many comments, some of them might need separate issue
numbers later).

> - IMHO the WG should pay (again) more attention to its
> charter: multihoming support is in it and to mention
> multihoming just before explaining it has nothing to do with
> the main scenario (and in fact with the document) is not
> right. So please really fix the Abstract!

Ok, I'll try to rephrase this in the next version.

> - motivation 2nd paragraph: the "another example" is a very
> limited view of what multihoming support needs. I'd like to
> see the mobike protocol supporting simultaneous multiple peer
> addresses.  (I use the term "peer address" from pki4ipsec
> documents because it could not confused with addresses in
> traffic selectors).

Since the first version of MOBIKE only deals with the outer
(tunnel header) addresses, using multiple addresses for an IPsec
SA simultaneously would probably mean either load balancing
(explicitly ruled out in the WG charter) or sending copies of a
single ESP packet over several paths (nobody has expressed any
interest in this so far).

But this is probably not what you meant... ?

> - in 2.1 the NAT_XXX_IP notifications are mandatory because it
> is the way the IP addresses in the IP header can be protected
> against en route modification (what I called the transient NAT
> attack). As the NAT_DETECTION_* could be interpreted as NAT-T
> is supported the NAT prevention stuff was introduced... This
> doesn't matter as soon as the IP addresses which will become
> the initial peer addresses are reflected in an integrity
> check.

You're right, I forgot to show the NAT_PREVENTION notification
in Section 2.1 (Section 2.6 did say that it's also included in
IKE_SA_INIT). I'll fix this...

> - in 2.2 why the ADDITIONAL_*_ADDRESS are limited to IKE_AUTH?
> (2.4 is too far, please add a pointer to it)

Ok, I'll add a pointer.

> - IMHO we need the capability to remove addresses too. Some
> care should be taken if we remove all or "important"
> addresses.  (same: pointer to 2.4)

We already have the _capability_ to remove addresses (you send a
new address list that does not contain the address you want to
remove).  The same capability could be implemented by more
complex protocol mechanisms, but I don't currently see any
reason to do so...

>- 2.2 is enough to make the transport mode with mobike I-D 
> applicable, so we should progress it?

A good question, I'll leave this to the WG chairs...

> - in 2.3 the SPD entries have to be updated too or expired SAs
> will be renewed with wrong addresses.

I'll add a clarification about this (where exactly the
addressses have to be updated depends a lot on the
implementation; e.g. the VPN client I have on my PC treats the
IPsec tunnel as a virtual interface, and stores some of the
information RFC 2401 would call "SPD" in what the implementation
calls "routing table").

> - in 2.3 it should be clearer that NAT_XXX notifications are
> mandatory.

Do you mean the NAT_DETECTION_*_IP or NAT_PREVENTION
notifications?

Currently the idea is that if you support NAT-T, you include
NAT_DETECTION_*_IP payloads; if you don't want NAT-T and do want
the "NAT prevention" feature, you include NAT_PREVENTION (but
not NAT_DETECTION_*).

> - the link between 2.2 and 2.3 is not explained because the
> new addresses are taken from the IP header. BTW I am afraid
> the main scenario is the only supported scenario as a
> consequence...

Could you give a concrete example of a scenario that can't be
done currently?

> - another limitation of 2.3 is it cannot update selectively a
> subset of SAs: again a case only is handled!

Yes, and this is intentional (there was rough consensus in issue
8 to do it this way -- if you want to update a subset of SAs,
you need to have several IKE_SAs).

>  - in 2.4 the case where there is a UPDATE_SA_ADDRESSES before
>  should be explained. I propose to explain that the current
>  peer addresses are IKE_SA parameters and the
>  UPDATE_SA_ADDRESSES echange defines their initial values.

I'll try to clarify 2.4 in the next version..

> - the address update by the responder is a bit complex. It
> seems to work but I am afraid it should be hard to explain, so
> I'd like to get a simpler mechanism (IMHO this is again a
> symptom of mobility vs multihoming problem of the document).

I agree the explanation is quite complex. I'll try to simplify
it in the next version...

> - 2.7 is not sound with 2.3 (IMHO the problem is in the
> wording because the way a NAT_PREVENTION can be associated
> with a UPDATE_SA_ADDRESSES is clear but is not as described in
> 2.7).  BTW I agree with the TBD (:-).

Quite right. I'll work on this for -02.

> - section 4 misses one of the mobility specific points: the
> initiator peer address (the MN care-of address) is
> dynamic/unknown so could not be verified by the responder (VPN
> server). This is why the protection performed by NAT_XXX
> notifications are necessary (BTW I have no concern to make it
> mandatory even in pure multihoming cases).

I'm updating the security considerations section in the next
version (see also issues 27 and 28), I hope the new text better
takes this into account.

> - the fact the ingress filtering works for UPDATE_SA_ADDRESSES
> because the new addresses are from the IP header should be
> mentioned (as a justification of this choice or as a
> point-to-solve if the choice will be changed).

Good point, I'll add this to the security considerations
section.

> - requires != SHOULD. BTW I am against the idea to make MOBIKE
> less efficient than mobility just because of the FUD of third
> party flooding attacks.

I fully agree that these flooding attacks are mostly FUD, and I
would not mind changing the "return routability check SHOULD be
done before updating.." to a MAY or something. But on the other
hand, you can ignore the SHOULD if want, too.

Best regards,
Pasi
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Thu, 08 Sep 2005 11:58:28 +0200

In your previous mail you wrote:

   
   
=> I am afraid that the issue is not only on wording, i.e.,
if you change the wording to reflect the real goal of the
document we'll be in real trouble with the charter (the IETF
one).

   
   
=> no, I mean simultaneous multiple peer addresses for different
IPsec SAs, something I've called the SCTP model for multihoming
(note it is not only for SCTP, it was just accurately described
in SCTP documents).

   > addresses.  (same: pointer to 2.4)
   
   We already have the _capability_ to remove addresses

=> this is covered by my "pointer to 2.4". IMHO some introduction
statements will be fine...

   
=> IMHO there is no choice here: the formal description is in 2401bis
and we have to use it even when we know the implementations have only
to provide the same behavior and can use very different structures.

   
=> yes.

=> I agree, my concern is there must be no case without any NAT_XXX.

   
=> multihoming.

   
=> the problem is if the intention is not to support multihoming
(and it seems there is a rough consensus about this :-) the charter
must be updated. Or we'll get IESG comments or even an appeal
about the document and its lack of support for anything else
than mobility.

   
=> as I wrote the term here is "requires" which is stronger than
the SHOULD we agree about.

Thanks

[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Thu, 08 Sep 2005 16:11:58 +0300

This slipped away from my processing queue
too, sorry Francis. Many thanks however for
your careful review, it seems that you caught
many issues that will lead to a document
change.

Here are some comments and suggested
changes, embedded in Pasi's comments.

>Ok, I'll try to rephrase this in the next version.
Here's a suggested edit:

   ... MOBIKE is making it possible for a remote access VPN user to move
   from one address to another while keeping the connection with the VPN
   gateway active.

=>

   ... MOBIKE is making it possible for a remote access VPN user
   to maintain a single VPN connection with a gateway, despite
   moving from one address to another or having multiple addresses.

Similar change in Section 1.1. Is there anything else Francis?

>But this is probably not what you meant... ?
The charter indeed limits us to "failover" semantics
of multihoming. But perhaps this is about IPsec
SA movement granularity? But we already discussed
that earlier and arrived at a conclusion.

>IKE_SA_INIT). I'll fix this...
Sounds clear.

>complex protocol mechanisms, but I don't currently see any
I tend to agree that its better to have a single mechanism
that simply replaces the set, rather than a "diff" scheme.
The latter would work better when there's a very large
set of addresses, but I think simplicity is more valuable
than covering that case. In any case, we know that there
are other limitations in our technology for dealing with
large address sets, e.g, ability to probe for a working
address pair.

>A good question, I'll leave this to the WG chairs...
I'm not sure I understand how Section 2.2 specifically
helps this, but I think our plan is to work on the transport
mode document once we finish this one -- and we are
hopefully not too far off from this. I'd like to do a WGLC
in September, and if all goes well we might be finished
prior to Vancouver -- so get your transport mode document
polished so that we'll have something to discuss there!

>information RFC 2401 would call "SPD" in what the implementation
Hm. I'm not sure I understand this. I thought SPD
deals with the unprotected packets, rather than the
outer addresses, which I think we are working with.
I would understand the SPD entry update if we
were talking about transport mode, however.

>the "NAT prevention" feature, you include NAT_PREVENTION (but
The document does not appear to say this explicitly,
or did I miss something? Add text...

>Could you give a concrete example of a scenario that can't be
I think the link is explained. 2.2 says: "The recipient
stores this information, but no other action is taken
at this time." Presumably somewhere else we have
text about what to do when you fail.

Suggestion: unless we can see a more specific
case where there's a problem, I don't see a need
to change the document on this point.

>you need to have several IKE_SAs).
Yes. Btw, we do intend to be fairly strict about
re-opening issues. (We will re-open an issue only if
we detect a new and/or serious technical problem.)

>I'll try to clarify 2.4 in the next version..
Ok.

>it in the next version...
Ok.

>Quite right. I'll work on this for -02.
Ok.

>version (see also issues 27 and 28), I hope the new text better
Good.

>Good point, I'll add this to the security considerations
Right.

>hand, you can ignore the SHOULD if want, too.
We have existing consensus on this issue. Lets
work with that and not re-open that one.

--Jari

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 8 Sep 2005 16:18:14 +0300

> to provide the same behavior and can use very different structures.

The 2401bis describes one way of implementing IPsec, it is not the
only way to do it. It itself says:

   "The model described below is nominal; implementations need not
   match details of this model as presented, but the external behavior
   of implementations MUST correspond to the externally observable
   characteristics of this model in order to be compliant."

Also the mobike extends some aspects of IPsec in way that they cannot
be expressed as rfc2401bis PAD/SPD/SAD model (i.e dynamic updating of
the PAD, SPD, SAD etc databases for example), thus implementations
supporting 2401bis and mobike need to make extensions to the
PAD/SPD/SAD. Thus Pasi's clarifications of the what possible tables or
databases needs to be updated in when the addresses are changed should
be in this document, and it does not need to be restricted in the
2401bis language and model. It should include the 2401bis model too
when applicable, but it can also provide other implementaqtion
instructions. 

> about the document and its lack of support for anything else

We do support multihoming, we do not support simultaneous use of
multiple addresses (as it would be load balacing that was explictly
forbidden by the charter). We do allow traffic to move from one
interface to the another (that is not mobility, it is multihoming).
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Thu, 08 Sep 2005 17:42:27 +0200

It should include the 2401bis model too when applicable, but it can
   also provide other implementation instructions.

=> I agree with this conclusion including its keywords.
   
   We do support multihoming, we do not support simultaneous use of
   multiple addresses (as it would be load balacing that was explictly
   forbidden by the charter).

=> I can't see why you believe that multiple addresses implies load
balancing, so I can't understand why you miss the fact that multiple
addresses is the way multihoming is handled in IPv6.

   We do allow traffic to move from one interface to the another (that
   is not mobility, it is multihoming).

=> this is not multihomong, it is a small and not essential part of
what is called multihoming (which is fortunately defined at the IETF,
cf MULTI6 WG & its successor(s)).

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sun, 11 Sep 2005 10:48:53 +0200

Here's a suggested edit:

   =>

   
=> are you joking? Either we really take multihoming into account
or we don't claim we deal with more than mobility.

   of multihoming.

=> you already know that I don't argue for load balancing but
for support of what I call the SCTP model of multihoming.

   But perhaps this is about IPsec SA movement granularity?

=> yes

   But we already discussed that earlier and arrived at a conclusion.

=> this is this conclusion I contest. BTW the charter explicitely
mentions SCTP so either we fix the charter or we follow it or we
make clear the document describes a partial solution and the work
about the full solution will be done later (i.e., a change in the
milestones).
   
   than covering that case.

=> this is a matter of taste. I am not convinced that sending the
whole set at any change is really simpler than sending diffs but
both give the same capability...

   In any case, we know that there are other limitations in our
   technology for dealing with large address sets, e.g, ability to
   probe for a working address pair.
   
=> this is just a side-effect of the "IKE will do everything by itself"
direction which of course can't deal with large address sets.

   helps this,

=> Section 2.2 is about the management of a peer address set and
the transport document relies only on this mechanism.

   so get your transport mode document polished so that we'll have
   something to discuss there!
   
=> IMHO the wording can be better (help me!), the references
shall be fixed as soon as the protocol is published, I can't see
something else.

=> the SPD-S entries have two main parts:
 - conditions: traffic selectors which are translated into TS payloads
 - an action, i.e., parameters for the protection with the IPsec
   protocol to use, ..., and the tunnel endpoint addresses.
In the ASN.1 syntax we get:
SPDEntry->IPsecEntry->processing->TunnelOptions->TunnelAddresses

=> no, this is explicitely about the tunnel mode and we speak about
SPD entries only because this is the place the tunnel endpoint
addresses are in the 2401bis formal description (this is why
we also speak about better implementation dependent hints).

   >>- in 2.3 it should be clearer that NAT_XXX notifications are

=> I should have written recommended, i.e., a SHOULD but not a MUST.

=> I'll ask the IESG what to do when a WG ignores its IETF charter.
My concern here is we can't work about SCTP/multihoming support
in IKEv2 (RFC 3554 for IKEv2 for instance) because it is in the
MOBIKE charter.

Regards

---

From: Jari Arkko <[email-masked]>
Date: Mon, 12 Sep 2005 16:57:00 +0300

>or we don't claim we deal with more than mobility.
Francis, it seems that we have multiple definitions
of multihoming. Or multiple levels of support we could
provide. I think it would be more productive to argue
what type of multihoming to support, than to argue
that we do or don't support multihoming.

I suspect that the group's desire to do any specific
type of multihoming relates very much to the expected
usage.

Ok.

>=> this is this conclusion I contest. 
>
Yes. But I'm sure you also understand that we
can't keep on arguing over an issue for ever, we
need to make decisions at certain points in time,
even if sometimes there are people who disagree
with those decisions.

>BTW the charter explicitely
I think we have a pending milestone change coming in any
case. E.g., what's the timeplan and interest for reduced
tunnel overhead and pfkey work? Should the transport doc
be in the milestones?

I see the SCTP support as one of the use cases in the
charter, along with the main use case of roaming VPN
users. My understanding has been that we are not
required to cover everything that we need to do in
one document. Indeed the transport document has
already been discussed as an extension over base
MOBIKE.

>shall be fixed as soon as the protocol is published, I can't see
Ok. I'll take a look.

>we also speak about better implementation dependent hints).
Ok. Thanks for the clarification.

>in IKEv2 (RFC 3554 for IKEv2 for instance) because it is in the
The charter allows and requires us to work on SCTP
support. But it does not promise that our first document
delivers this support. In fact, the charter makes it quite
clear what the main scenario is.

This should not prevent later support for SCTP,
Mobile IP and other specific applications, however.

--Jari

---

From: Francis Dupont <[email-masked]>
Date: Mon, 19 Sep 2005 17:06:53 +0200

=> failover, SCTP-like and load balancing (cf your previous message).

   
=> you have to choose a position, for instance fix the charter.
You should not use contradictory arguments to answer to my issue.

   one document.

=> so the issue is "closed" only for the current document?
   
Regards

---

From: Jari Arkko <[email-masked]>
Date: Wed, 28 Sep 2005 18:41:18 +0300

Right.

--Jari