Subject: Re: [Mobike] WGLC on the design draft

From: Tero Kivinen <[email-masked]>
Date: Tue, 3 Jan 2006 19:32:53 +0200

[issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html
 working copy of document:
 http://www.kivinen.iki.fi/ietf/draft-ietf-mobike-design-06.txt]

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.
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 3 Jan 2006 19:46:22 +0200

Francis Dupont writes:
> > 6.4.  Updating address list
> >
> s/list/set/ (this is important because lists should be ordered but
> not sets). Here we have sets with a particular element.

Done. 

> >    MOBIKE could send the full peer address list every time any of the IP
> 
> s/full/whole/ ?

Done.

> > 7.  Security Considerations
> > 
> >    As all the messages are already authenticated by IKEv2 there is no
> >    risk that any attackers would modify the contents of the packets.
> 
> as messages and packets are not the same this is not correct
> (as the following show), so s/packets/messages/

Done.

> >    The IP addresses in the IP header of the packets are not
> >    authenticated, thus the protocol defined must take care that they are
> >    only used as an indication that something might be different, and
> >    that do not cause any direct actions, except when doing NAT
> >    Traversal.
> 
> I strongly disagree: not authenticate the IP addresses just leaves
> the protocol vulnerable to attacks modifying them, i.e., you can
> establish the IKE SA and IPsec SAs with a bad address (cf what I call

The IP addresses in the IP header are not authenticated. That is state
of fact.

Only solution to fix that would be running MOBIKE over AH, which would
authenticate the IP address in the *IP header*.

So this text here tells that if protocol uses those address from the
*IP header* it needs to take care. 

>  - reflect the IP address in messages in order to detect changes.
>    This is the option used by Mobike which requires either NAT dectection
>    or NAT prevention

This option does not make IP addresses in the *IP header*
authenticated. It will make separate copy of the IP addresses in the
payload, which will be then authenticated, and those can be used in
places where the unauthenticatede IP addresses from the *IP header*
cannot be used.

> So please update the design security considerations!

If you have exact text changes, please send them. 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Wed, 04 Jan 2006 12:34:46 +0100

In your previous mail you wrote:

   
=> to refer to the charter is only one way to solve the issue.

   
=> I agree, IMHO the word "internal" (to IPsec) or something equivalent
is enough, for instance "Existing IPsec documents" works well.

   
=> 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).

   
=> no, ranges don't make sense with pseudo-random values.

=> 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.

   
   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 (:-).

   

=> 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.

Regards

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

---

From: Francis Dupont <[email-masked]>
Date: Wed, 04 Jan 2006 12:43:14 +0100

=> yes but the protocol document addresses this issue so I simply suggest
to put the same text into the design document.

   
=> I agree but to explain how is not bad, is it?

   
=> strictly you're right but this is not how it is implemented (as the
options are not copies but hashes of the IP addresses the IP addresses
from the IP header are used but only after being checked against the
authenticated "copies").

=> I keep this message and I'll try to propose something.

Regards

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

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 5 Jan 2006 14:33:20 +0200

Francis Dupont writes:
> I agree, IMHO the word "internal" (to IPsec) or something equivalent

Changed to that "Existing IPsec document ...". 

> so the text should be more accurate about what it calls load balancing,

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

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. 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 5 Jan 2006 14:58:35 +0200

> to put the same text into the design document.

This document is not meant to be limited to the specific protocol, it
tries to be more generic one. The protocol document provided solution
to that and the text describing that solution belongs to that
document. 

> from the IP header are used but only after being checked against the

Actually current draft-ietf-mobike-protocol-07 do copy the addresses
and ports from the IP header to the NO_NATS_ALLOWED payload (without
any hashes or similar). It will return error
(UNEXPECTEED_NAT_DETECTED) if those do not match. But as these are
things that can change so it is better that the generic design
document does not mention those, but simply mentions that there is
problem, and the actual protocol document needs to take care of them.

We do now have text:
----------------------------------------------------------------------
   See Security considerations section of [I-D.ietf-mobike-protocol] for
   more information about security considerations of the actual
   protocol.
----------------------------------------------------------------------
at the end of security considerations section.
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Thu, 05 Jan 2006 23:07:30 +0100

=> but you should agree we have a more technical and detailed discussion
now than when before the decision was made (:-).

=> the issue is we already have too many arguments and none can be as
good as the "authority" one.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Thu, 05 Jan 2006 23:19:59 +0100

any hashes or similar).

=> only in the NAT prevention case, in the NAT detection case a hash
is used in order to hide the real address.

   It will return error
   
=> we agree.

   We do now have text:
         ^^^

=> this is a fine way to have to present problems but not the solutions
(so to keep what has to be in the document).

Regards