D110 Comments from Francis
From: Francis Dupont
Subject: Re: [Mobike] WGLC on the design draft
Date: Wed, 21 Dec 2005 15:37:47 +0100
| Abstract
|
| ...
|
| This document discusses the involved network entities, and the
| relationship between IKEv2 signaling and information provided by
| other protocols. Design decisions for the MOBIKE protocol,
| background information and discussions within the working group are
| recorded.
There is nothing about the fact the design and the protocol are about
a first version of the MOBIKE tools. I support anyone who'd like to
make it an issue as the current solution addresses only one part of
the charter scenarios.
| 1. Introduction
|
| ...
| single pair in the outer IP headers. Existing documents make no
| provision to change this pair after an IKE SA is created.
This is not true: RFC 3775 and 3776 K bit stuff does exactly this.
| 3.2. Multihoming Scenario
|
| ...
| Note that MOBIKE does not aim to support load balancing between
| multiple IP addresses. That is, each peer uses only one of the
| available IP addresses at a given point in time.
This is not the common definition of load balancing (where the
restriction to only one address is per communication).
| 3.3. Multihomed Laptop Scenario
|
| ...
| GPRS adaptor, a Bluetooth interface or USB hardware. Not all
| interfaces are used for communication all the time for a number of
| reasons (e.g., cost, network availability, user convenience). The
"not all" is not "only one".
| 5.3. Scope of SA Changes
|
| ...
| If IPsec SAs should be updated separately then a more efficient
| format than the Notify payload is needed to preserve bandwidth. A
| Notify payload can only store one SPI per payload. A separate
| payload could have a list of IPsec SA SPIs and the new preferred
| address. If there is a large number of IPsec SAs, those payloads can
| be quite large unless ranges of SPI values are supported. If we
Ranges of SPI values don't make sense: please use a reasonnable
argument or no argument at all!
| automatically move all IPsec SAs when the IKE SA moves, then we only
| need to keep track of which IKE SA was used to create the IPsec SA,
| and fetch the IP addresses from the IKE SA, i.e. there is no need to
| store IP addresses per IPsec SA. Note that IKEv2 [I-D.ietf-ipsec-
I don't believe there is an implementation which doesn't store IP
addresses per IPsec SA.
| If we do allow address set of each IPsec SA to be updated separately,
| then we can support scenarios where the machine has fast and/or cheap
| connections and slow and/or expensive connections, and wants to allow
| moving some of the SAs to the slower and/or more expensive
| connection, and prevent the move, for example, of the news video
| stream from the WLAN to the GPRS link.
Exactly
| On the other hand, even if we tie the IKE SA update to the IPsec SA
| update, then we can create separate IKE SAs for this scenario, e.g.,
| we create one IKE SA which has both links as endpoints, and it is
| used for important traffic, and then we create another IKE SA which
| has only the fast and/or cheap connection, which is then used for
| that kind of bulk traffic.
We can drop the whole MOBIKE stuff using the same argument.
| The working group decided to move all IPsec SAs implicitly when the
| IKE SA address pair changes. If more granular handling of the IPsec
| SA is required, then multiple IKE SAs can be created one for each set
| of IPsec SAs needed.
Please keep this and not try to give poor arguments to defend
the decision (it is the WG decision ".")
From: Tero Kivinen
Subject: Re: [Mobike] WGLC on the design draft
Date: Tue, 3 Jan 2006 19:32:53 +0200
Francis Dupont writes:
| there is nothing about the fact the design and the protocol are about
| a first version of the MOBIKE tools. I support anyone who'd like to
| make it an issue as the current solution addresses only one part of
| the charter scenarios.
Jari has already several times asked me to remove all references to
the charter, thus I am not going to add anything new about the charter
or future work...
| | 1. Introduction
| | ...
| | single pair in the outer IP headers. Existing documents make no
| | provision to change this pair after an IKE SA is created.
|
| this is not true: RFC 3775 and 3776 K bit stuff does exactly this.
We are now talking about the IPsec. As far as I know those RFCs only
cover MOBILE IP case, thus they are not generic IPsec solutions. I
might be wrong, as I have not followed what was done there.
| | 3.2. Multihoming Scenario
| |
| | ...
| | Note that MOBIKE does not aim to support load balancing between
| | multiple IP addresses. That is, each peer uses only one of the
| | available IP addresses at a given point in time.
|
| This is not the common definition of load balancing (where the
| restriction to only one address is per communication).
I think we have discussed this enough earlier. If you have exact text
changes I can check them out, but I am not going to start discussion
about what is load balancing and what is not again.
| | 5.3. Scope of SA Changes
| ranges of SPI values don't make sense: please use a reasonnable
| argument or no argument at all!
Would you be happier if that would be list of ranges of SPI values?
Actually ranges makes perfectly sense there, as the end allocating
them can allocate them so that he can effectively move the SPIs he
wants to move by just having one range (or few ranges).
| | automatically move all IPsec SAs when the IKE SA moves, then we only
| | need to keep track of which IKE SA was used to create the IPsec SA,
| | and fetch the IP addresses from the IKE SA, i.e. there is no need to
| | store IP addresses per IPsec SA. Note that IKEv2 [I-D.ietf-ipsec-
|
| I don't believe there is an implementation which doesn't store IP
| addresses per IPsec SA.
Might be true now, but might be more common in the future, as they
might want to store the IP address to the shared state, so they can
update is very quickly for thousands of SAs (and save memory etc).
| | On the other hand, even if we tie the IKE SA update to the IPsec SA
| | update, then we can create separate IKE SAs for this scenario, e.g.,
| | we create one IKE SA which has both links as endpoints, and it is
| | used for important traffic, and then we create another IKE SA which
| | has only the fast and/or cheap connection, which is then used for
| | that kind of bulk traffic.
|
| We can drop the whole MOBIKE stuff using the same argument.
I think there is few orders of magnitude difference there. I would
guess there would be at most 2-3 different types of IPsec SAs which
would be moved separately. On the other hand there can be hundreds or
thousands of movements in quite short time in certain time period.
Thus we do need MOBIKE, but we might still be able to use only few IKE
SAs for different types of traffic.
Anyways this issue is already decided in the protocol draft (issue 8),
thus discussion of the issue itself is pointless. If you have exact
text changes to the document, then send them, but discussion about the
issue 8 should not be restarted.
| The working group decided to move all IPsec SAs implicitly when the
| IKE SA address pair changes. If more granular handling of the IPsec
| SA is required, then multiple IKE SAs can be created one for each set
| of IPsec SAs needed.
|
| Please keep this and not try to give poor arguments to defend
| the decision (it is the WG decision ".")
If you have good arguments in either direction which is not mentioned
in the draft, send text.
Working group did decided to select the issue 8 with all IPsec SAs
move when IKE SA move, so the arguments were enough for the working
group. I think the main reason was that it is simplier, and the
feature is not needed that much.
From: Francis Dupont
Subject: Re: [Mobike] WGLC on the design draft
Date: Wed, 04 Jan 2006 12:34:46 +0100
| Jari has already several times asked me to remove all references to
| the charter, thus I am not going to add anything new about the charter
| or future work...
To refer to the charter is only one way to solve the issue.
| We are now talking about the IPsec. As far as I know those RFCs only
| cover MOBILE IP case, thus they are not generic IPsec solutions. I
| might be wrong, as I have not followed what was done there.
I agree, IMHO the word "internal" (to IPsec) or something equivalent
is enough, for instance "Existing IPsec documents" works well.
| I think we have discussed this enough earlier. If you have exact text
| changes I can check them out, but I am not going to start discussion
| about what is load balancing and what is not again.
so the text should be more accurate about what it calls load balancing,
i.e., why not add this definition in the terminology section? (the idea is
the document may use what it likes as soon as it is either a common
term or a defined-within term).
| Would you be happier if that would be list of ranges of SPI values?
no, ranges don't make sense with pseudo-random values.
| Actually ranges makes perfectly sense there, as the end allocating
| them can allocate them so that he can effectively move the SPIs he
| wants to move by just having one range (or few ranges).
RFC 4302 says "arbitrary value". I am not convinced there is no
attack against predictable SPIs. As far as I know all implementations
use (pseudo) random SPIs... This is what I assume when I say ranges don't
make sense there.
| I think there is few orders of magnitude difference there. I would
| guess there would be at most 2-3 different types of IPsec SAs which
| would be moved separately. On the other hand there can be hundreds or
| thousands of movements in quite short time in certain time period.
| Thus we do need MOBIKE, but we might still be able to use only few IKE
| SAs for different types of traffic.
|
| Anyways this issue is already decided in the protocol draft (issue 8),
| thus discussion of the issue itself is pointless.
I am not against this "authority" argument, my concern is about a
poor argumentation to defend the decision, i.e., I strongly suggest
to remove the whole argumentation and just to say it is the WG decision.
| If you have exact text changes to the document, then send them, but
| discussion about the issue 8 should not be restarted.
I don't want to restart it this time, just to remove it (:-).
| If you have good arguments in either direction which is not mentioned
| in the draft, send text.
|
| Working group did decided to select the issue 8 with all IPsec SAs
| move when IKE SA move, so the arguments were enough for the working
| group. I think the main reason was that it is simplier, and the
| feature is not needed that much.
as your idea is to keep the cover on the pot you should follow my
suggestion: just keep the presentation of the issue and the decision.
From: Tero Kivinen
Subject: Re: [Mobike] WGLC on the design draft
Date: Thu, 5 Jan 2006 14:33:20 +0200
| I agree, IMHO the word "internal" (to IPsec) or something equivalent
| is enough, for instance "Existing IPsec documents" works well.
Changed to that "Existing IPsec document ...".
| so the text should be more accurate about what it calls load balancing,
| i.e., why not add this definition in the terminology section? (the idea is
| the document may use what it likes as soon as it is either a common
| term or a defined-within term).
Most comments have been that would need to remove extra terms from the
terminology section, so I do not think we need to add one more, that
is only in 1-2 places in the document.
| no, ranges don't make sense with pseudo-random values.
There are implementations who do allocate SPI values in groups, where
ranges makes perfect sense for the implementation allocating the SPIs.
For the other end ranges does not mean anything, but it does compress
the list of SPIs much smaller if SPI values are allocated knowing the
fact.
| RFC 4302 says "arbitrary value". I am not convinced there is no
| attack against predictable SPIs. As far as I know all
| implementations use (pseudo) random SPIs... This is what I assume
| when I say ranges don't make sense there.
RFC4302 also says:
However, the
creator of an SA may choose to interpret the bits in an SPI to
facilitate local processing.
which means that allocating SPIs of the high bandwidth SAs from range
0xe0000000-0xefffffff, and SPIs of the low bandwidth high availibility
SAs from range 0xd000000-0xdfffffff, would still be completely aligned
with the RFC4302. The idea is that SPI is arbitrary number and only
creator of the SPI can know why certain value was used.
Also SPIs allocated from those 24 bit ranges are still not
predictable. I still do not completely how you want to modify that
text, i.e. what is more efficient format than list of ranges that you
want to mention there?
| I am not against this "authority" argument, my concern is about a
| poor argumentation to defend the decision, i.e., I strongly suggest
| to remove the whole argumentation and just to say it is the WG
| decision.
The text there is not there to "defend" the decision, it is there for
background information, and to explain that we did consider these
things, and that we made this decision.
If you have better arguments for either side, feel free to submit
them, I can add them there too.