Tero Kivinen | 3 Jan 15:19 2006
Picon
Picon

Design draft comments

I now have put all the comments received during the working group last
call to separate issue page. I have not yet checked them out
properly, I simply just put them all there first, and next I will
start processing them.

The list of issues for the design draft can be found from the
http://www.kivinen.iki.fi/ietf/mobike-design-issues.html. 
--

-- 
kivinen <at> safenet-inc.com
Tero Kivinen | 3 Jan 16:16 2006
Picon
Picon

#D101: design draft issue: editorial

[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]

Jari Arkko writes:
> Abstract:
> ======
> 
> >    The MOBIKE (IKEv2 Mobility and Multihoming) working group is
> >    developing extensions for the Internet Key Exchange Protocol version
> >    2 (IKEv2).
> 
> For someone that reads this later the references to WG may not make a
> lot of sense. Rewrite as "MOBIKE (...) is an extension of the ...".

Done. 

> Section 1:
> ==========
> 
> > However, this can be problematic, as the device
> > might be too slow for this task.
> 
> Maybe "However, this is a relatively expensive operation,
> and can be problematic when such changes are frequent."

Done.

> >    The work of the MOBIKE working group and therefore this document is
> >    based on the assumption that the mobility and multi-homing extensions
(Continue reading)

Tero Kivinen | 3 Jan 16:26 2006
Picon
Picon

design draft issue: existing documents claim

Jari Arkko writes:
> >    IKEv2 assumes that an IKE SA is created implicitly between the IP
> >    address pair that is used during the protocol execution when
> >    establishing the IKEv2 SA.  This means that, in each host, only one
> >    IP address pair is stored for the IKEv2 SA as part of a single IKEv2
> >    protocol session, and, for tunnel mode SAs, the hosts places this
> >    single pair in the outer IP headers.  Existing documents make no
> >    provision to change this pair after an IKE SA is created.
> But doesn't NAT-T allow a limited form of changes?

There is text in the RFC 4306 section 2.23 saying that implementation
SHOULD dynamically update the address of the host behind NAT if they
detect it is changed, but that is only limited for the NAT-T case and
only so that host not behind NAT does that for host behind NAT.

I added text saying "(except for dynamic address update of NAT-T)" to
the end. 
--

-- 
kivinen <at> safenet-inc.com
Tero Kivinen | 3 Jan 17:04 2006
Picon
Picon

D103 design draft issue: terminology alignment

[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]

Jari Arkko writes:
> >
> >    Primary Path:
> The protocol draft uses the term "current path" (and so does
> the latest version of the SHIM6 draft where the primary path
> term was originally taken from).
> 
> Use the term "current path" instead here in Section 2 as well
> as in the rest of the document.

Changed to use current instead of primary.

> 
> >    Preferred Address:
> >
> >       The IP address of a peer to which MOBIKE and IPsec traffic should
> >       be sent by default.  A given peer has only one active preferred
> >       address at a given point in time, except for the small time period
> >       where it switches from an old to a new preferred address.  This
> >       definition is taken from [I-D.ietf-hip-mm] and adapted to the
> >       MOBIKE context.
> 
> The protocol draft does not use this term.

True, but design document do use this term when describing different
options we had. This document is not only describing what we have in
(Continue reading)

Tero Kivinen | 3 Jan 17:22 2006
Picon
Picon

D104 design draft issue: definition of load balancing

[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]

Jari Arkko writes:
> >    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 may not be exact enough. I suppose we mean "... only one
> of the available address pairs at a given point in time".

Changed. 
--

-- 
kivinen <at> safenet-inc.com
Tero Kivinen | 3 Jan 17:32 2006
Picon
Picon

D105 design draft issue: figure 3

[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]

Jari Arkko writes:
> >                            +-------------+       +---------+
> >                            |User-space   |       | MOBIKE  |
> >                            |Protocols    |  +-->>| Daemon  |
> >                            |relevant for |  |    |         |
> >                            |MOBIKE       |  |    +---------+
> >                            +-------------+  |         ^
> >    User Space                    ^          |         ^
> >    ++++++++++++++++++++++++++++ API ++++++ API ++++ PF_KEY ++++++++
> >    Kernel Space                  v          |         v
> >                                _______      |         v
> >        +-------------+        /       \     |    +--------------+
> >        |Routing      |       / Trigger \    |    | IPsec        |
> >        |Protocols    |<<-->>|  Database |<<-+  +>+ Engine       |
> >        |             |       \         /       | | (+Databases) |
> >        +-----+---+---+        \_______/        | +------+-------+
> >              ^   ^               ^             |        ^
> >              |   +---------------+-------------+--------+-----+
> >              |                   v             |        |     |
> >              |             +-------------+     |        |     |
> >       I      |             |Kernel-space |     |        |     |   I
> >       n      |   +-------->+Protocols    +<----+-----+  |     |   n
> >       t      v   v         |relevant for |     |     v  v     v   t
> >       e +----+---+-+       |MOBIKE       |     |   +-+--+-----+-+ e
> >       r |  Input   |       +-------------+     |   | Outgoing   | r
> >       f |  Packet  +<--------------------------+   | Interface  | f
(Continue reading)

Tero Kivinen | 3 Jan 17:38 2006
Picon
Picon

D106 design draft issue: nat-p

[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]

Jari Arkko writes:
> >   This gives extra
> >    protection against 3rd party bombing attacks (the attacker cannot
> >    divert the traffic to some 3rd party). 
> 
> 
> This seems inaccurate, or at least too strong. We have
> other mechanisms to prevent that, and the NAT-T based
> attack only works for on-path attackers. Just say
> "This avoids any possibility of on-path attackers modifying
> addresses in headers" and refer to Francis's pseudonat
> attack draft.

Why do you think that NAT-preventation does not protect against 3rd
party bombing attacks?

If we do put all IP addresses used inside the packets, and
cryptographically integrity protect them, and we enable NAT
preventation, which means we do not allow NATs, how can attacker
divert the traffic to some 3rd party?
--

-- 
kivinen <at> safenet-inc.com
Tero Kivinen | 3 Jan 17:47 2006
Picon
Picon

D107 design draft issue: section 5.5 nits

[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]

Jari Arkko writes:
> >    If the addresses are part of the certificate then it is
> >    not necessary to execute the weaker return routability check.  The
> >    return routability check is a form of authorization check, although
> >    it provides weaker guarantees than the inclusion of the IP address as
> >    a part of a certificate.  If multiple addresses are communicated to
> >    the remote peer then some of these addresses may be already verified
> >    even if the primary address is still operational.
> 
> s/the weaker/the/ (the strength is explained in next sentence)

Done.

> Also, it seems like there is some text missing here that we
> had in the protocol draft about the need to have some authority
> involved in the certs... surely the pure inclusion of data in
> a self-signed certificate, for instance, does not make the
> data reliable.

I think adding that text to the protocol draft was completely
unnessarely in the first place, as of course certificates needs to be
validated before you use them. 

> I do not understand the last sentence. I guess you are trying
> to say that verification can take place in parallel with ongoing
> use of another, current address pair?
(Continue reading)

Tero Kivinen | 3 Jan 18:01 2006
Picon
Picon

D108 design draft issue: ikev2 payloads

[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]

Jari Arkko writes:
> >    Some implementations might have problems parsing more
> >    than certain number of IKEv2 payloads, but if the sender sends them
> >    in the most preferred first, the receiver can only use the first
> >    addresses, it was willing to parse.
> 
> 
> Hmm... the IKEv2 spec seems to say that you MUST
> be able to reject Critical=1 payloads that you don't
> recognize. This seems to imply that you must go through
> all the payloads, or am I missing something?

You need to go through all payloads to check the critical bit and that
the payload chaining is correct. On the other hand you do not need to
parse 256 status notifications or 100 certificates the other end
decided to send to you. You only need to parse first certificate
payload, as it is end entity certificate, and you can ignore the rest,
and fetch the certificates from some other source if you want.

I do know there was some IKEv1 implementations that refused to parse
some of our packets as they did have fixed limit of number of
certificate payloads they accepted, or they had fixed limit of number
of SA proposal you could have etc. I wouldn't be suprised that there
would be implementation out that has fixed number of status
notifications it will parse or decode.
--

-- 
(Continue reading)

Tero Kivinen | 3 Jan 18:12 2006
Picon
Picon

D109 design draft issue: security considerations

Jari Arkko writes:
[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]

> > 7.  Security Considerations
> 
> This section seems weak compared to the one in
> the protocol draft. Consider simply referring to the
> protocol spec unless there is some new information
> (e.g. design decisions not covered in the protocol
> spec).

As we do not really define protocol here, there is not that much of
real security considerations. The current security considerations
lists the generic problems against all protocols of this type.

I am not sure adding pointer to the protocol document helps that much,
as I assume people will read the protocol document anyways, but
perhaps adding text "See Security considerations section of <xref
target="I-D.ietf-mobike-protocol"/> for more information about
security considerations of the actual protocol." helps. 
--

-- 
kivinen <at> safenet-inc.com

Gmane