[Mip6] Francis' Review of draft-irtf-mobopts-ro-enhancements (was Re: FW: Please review draft-irtf-mobopts-ro-enhancements-00.txt)

[Christian Vogt <[e-mail]>]

Hi,

I probably should have sent this to the MIP6 mailing list, too.

- Christian


-------- Original Message --------
Subject: Francis' Review of draft-irtf-mobopts-ro-enhancements (was Re: 
FW: Please review draft-irtf-mobopts-ro-enhancements-00.txt)
Date: Fri, 27 May 2005 09:22:23 +0200
From: Christian Vogt <[e-mail]>
To: Francis Dupont <[e-mail]>
CC: [e-mail], Jari Arkko <[e-mail]>, 
MOBOPTS <[e-mail]>

Hi Francis,

first of all, thanks for reviewing the document and commenting on it.
We revised the document and put the new, preliminary version here:

http://doc.tm.uka.de/2005/draft-irtf-mobopts-ro-enhancements-01-pre.txt

BTW, Vidya and James both did a review as well, so there is going to be
another round of revision.

Below are my responses to your, Francis', comments.

> - abstract: IMHO the goals of improvements/alternatives are in the
> wrong order: signaling messages/latency/etc can be improved only
> because the security is better. (same about 4.x section order)

Hmm, there wasn't actually an intention to prioritize the proposals,
Francis.  But it might be wise to do so.  Do you think that the order

(1) low latency
(2) increased security
(3) reduced signaling overhead

is capable of reaching agreement?  It seems that there is a common
ground to at least not increase the latency of standard Mobile IPv6.  In
other words, many of the described proposals have merits in terms of
reduced latency, even if their primary goal is to increase security.
(OMIPv6 is a good example.  If you combine it with Credit-Based
Authorization, which is what we will do in Mipshop, you get both, higher
security and lower latency.)

> - 1.introduction: to put HIP at the same level than Mobile IPv6 and 
> Mobile IP is a clear bias.

Ok, this document is about Mobile IPv6, so it should be made clear in
the introduction.  Re-wrote that part.

> - 1.introduction: IKE is only a standard way to dynamically establish
>  security associations. (same comment about section 3)

Right.

> - 2.3flooding attacks: arguments about amplification are specious: 
> the current real world threat is DDoS and the main defense against 
> it, the ingress filtering (BCPs 38 and 84), i.e., we are either 
> vulnerable or not vulnerable to both DDoS and RO reflection attacks 
> (modulo the use of "real" alternate care-of addresses). So I consider
>  the 2.3 section as delibarately incomplete.

Francis, I added a sub-section 1.1, "A Note on Source Address
Filtering", to the introduction that attends to the ongoing discussion
about whether or not ingress filtering is a suitable replacement for
care-of-address tests.  The estimate of many folks, that it is not, has
shaped the design of Mobile IPv6, and it was a basis for this document, too.

But you are right that one should render the assumption clearer, and
justify it, within this document.  I think that the new sub-section
accomplishes this.  Its signification is the same as section 1.1.1 in
draft-ietf-mip6-ro-sec-02, which Gabriel added for similar reasons.

I also added draft-dupont-mipv6-3bombing-01 to the references.

> - 3.1registration procedure: ESP (with non-null encryption and 
> authentication) support is mandatory for HAs and use is recommended 
> for mobile nodes. At least the word "optionally" before encrypted is
> wrong.

Are you positive, Francis?  As far as I know, use of ESP encryption is
not mandatory for both MN or HA.  This is what RFC 3775 says about this:

++++
5.1.  Binding Updates to Home Agents

    The mobile node and the home agent MUST use an IPsec security
    association to protect the integrity and authenticity of the Binding
    Updates and Acknowledgements.  Both the mobile nodes and the home
    agents MUST support and SHOULD use the Encapsulating Security Payload
    (ESP) [6] header in transport mode and MUST use a non-NULL payload
    authentication algorithm to provide data origin authentication,
    connectionless integrity and optional anti-replay protection.  Note
    that Authentication Header (AH) [5] is also possible but for brevity
    not discussed in this specification. [...]
++++

And RFC 3776 says in the introduction:

++++
    The control traffic between the mobile node and the home agent
    requires message authentication, integrity, correct ordering and
    anti-replay protection.  The mobile node and the home agent must have
    an IPsec security association to protect this traffic.  [...]
++++

I am not quite sure how this relates to what it says in section 4.3,
however:

++++
    The following requirements apply to both home agents and mobile
    nodes:

       [...]
       Mandatory support for encryption and integrity protection
       algorithms is as defined in RFC 2401 [2], RFC 2402 [8], and RFC
       2406 [3].  [...]
++++

Can you comment on this?

> - 3.2goals and assumptions: the discussion about the size of the PKI
> is misleading: first the number of certificates is the number of
> mobile nodes, not the number of possible home addresses [...]

Right, it's done.

> nodes, not the number of possible home addresses, second X.509 PKIs 
> are hierarchical and can handle very large numbers of end entities (I
> know examples of PKIs with millions of certificates). The only real
> issue is it seems a global PKI is not wanted by people (and not for
> security reasons :-) so should not be considered as available in any
> time scale.

The scalability issue is not so much meant to be a technical one, but is
more about acceptance, administrative feasibility, and performance.
But, yes, the text might have been a bit imprecise here.  So I
re-wrote it with your concerns in mind.  Here are the new paragraphs
from section 3.2:

++++
    Public-key cryptography requires some external binding between a
    public key and the identity this public key is supposed to protect.
    Certificates issued by a trusted authority can usually do this job,
    although there is little experience with using home addresses as
    identifiers in the certificates.  (E.g., the home address could be
    placed into a certificate's Subject AltName field.)  Given a
    certificate that binds a public key to a home address, the owner of
    this home address can authenticate itself as such by signing some
    arbitrary piece of data with its private key.  Since everybody can
    verify the signature with the mobile node's public key, this proves,
    in the end, that the mobile node actually knows the private key
    complementing the certified public key, and the certificate authority
    vouches that the public key, in turn, is associated with the home
    address.  The eventual decision to not depend the security of Mobile
    IPv6 on public-key cryptography was sparked by problems related to
    scalability, performance, administrative feasibility, and acceptance
    as explained next.

    There are differing opinions on whether public-key infrastructures
    (PKIs) could scale up to hundreds of millions of mobile nodes.  Some
    people argue they do, as there are already examples of PKIs with
    millions of certificates.  But apart from an increase just in the
    number of certificates, a shift in application patterns can be
    anticipated as well:  Public-key infrastructures (PKI) are nowadays
    used only for the types of applications that really can't go without
    the strong protection certificates provide.  But as soon as mobility
    joins the set of applications, not only does the number of nodes
    using certificates increase, but the new users, the mobile nodes,
    would also most likely have their certificates checked at a much
    higher frequency than other nodes use to do for other applications.
    It is unclear whether PKIs could handle this new workload.

    Another issue is performance from the user's perspective:
    Certificate verification takes some time, especially when multiple
    levels of PKI hierarchies are involved.  If this delay happens only
    at the beginning of a session, most users would probably come to
    terms with it.  If it happens in the middle of a session, or the
    session is very short-term anyway, it could have a disturbing effect.

    Moreover, while it is conceivable that mobile users be well-disposed
    to configuring certificates into their mobile nodes, busy servers
    functioning as correspondent nodes might not be willing to check the
    mobile nodes' certificates depending on the service they provide.
    Besides, it might not be easy to coordinate address assignment with
    certificate issuing.  Typically, the entities responsible for these
    tasks are not the same.  And finally, the bigger a PKI grows, the
    more attractive it becomes as an attack target, endangering the
    Internet as a whole.
++++

> - 3.2goals and assumptions: the argument that authentication can not
> help against flooding attacks is wrong: authentication can help but
> at the condition the care-of address is covered. This is usually not
> the case but this is a different argument.

Do you think about care-of addresses that mobile nodes own, or reserve,
at different networks to where they might roam at some point in the
future?  Or do you have in mind an extension to SeND through which a
remote correspondent node could verify a mobile node's presence at the
care-of address?  Note that CGAs alone do not solve the issue because
the addresses can be configured at any place.

I'm not sure if I see your point.  Could you please clarify this?

> - 3.2goals and assumptions: I reviewed a research paper proposing 
> certificate-based authorization of care-of addresses so the
> discussion about this concluding it is not possible is wrong.

Ah, ok.  So you mean special care-of addresses, owned by a mobile node,
which are verifiable through certificates.  Or you allow the
mobile node to configure any care-of address---with certain prefixes or
without contraints at all---and have some entity vouch for the mobile
node's sincerity.  Draft-qiu-mip6-certificated-binding-update-03.txt
proposes something like this, too.

> - 3.2...: the decision about ingress filtering refers to
> routing-routability design *only*. The idea that ingress filtering
> can't help and care-of address test is necessary is the own opinion
> of authors.

Ok, see new sub-section 1.1 for this matter.

> - 4.2signaling optimizations: bps is not an ISO unit.

Should be understandable now. ;)

> - 5.1ip-address tests: I suggest to add correspondent-driven tests to
>  this section, cf draft-dupont-mipv6-rrcookie-00.txt)

Agreed.  I added this paragraph to section 5.1:

++++
A home-address test can most efficiently be initiated by the mobile node
itself, as the correspondent node can thus delay state creation until
the mobile node has authenticated.  Yet, conceptually, either the mobile
node or the correspondent node could start a care-of-address test.  RFC
3775 uses mobile-node-initiated IP-address tests, whereas
[draft-dupont-mipv6-rrcookie] proposes a way to have the correspondent
node send the first message.  [draft-ietf-hip-mm] follows this latter
approach as well.  The correspondent-node-driven approach has advantages
when authentication is done through other means than a home-address
test.  Since RFC 3775 does use the home-address test for authentication,
letting the mobile node initiate both IP-address test allows for more
efficient parallelization.
++++

> - 5.10: acess -> access

Thanks.

> I have a real concern about this document: its title is for a WG
> document, reflecting a consensus of the WG, when what I can find in
> it is mainly the own opinion of authors.

Well, this is why we do reviews. ;)

I think there are now some substantial changes to the document (see the
link at the top of this email).  Underlying assumption are more clearly
expressed now, additional techniques have been included, and some
imprecisenesses have been corrected.  With the new "Note on Source
Address Filtering" within the Introduction, readers will become aware
that there is an ongoing debate about this topic, and that
assumptions about it may change as technology evolves.

Once again, thanks for the review!

Kind regards,

- Christian

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/



Francis Dupont wrote:
> Here are some notes taken when I received the call for review. I'll
> summarize in the list.
> 
> Some comments about draft-irtf-mobopts-ro-enhancements-00.txt: -
> abstract: IMHO the goals of improvements/alternatives are in the
> wrong order: signaling messages/latency/etc can be improved only
> because the security is better. (same about 4.x section order) -
> 1.introduction: to put HIP at the same level than Mobile IPv6 and 
> Mobile IP is a clear bias. - 1.introduction: IKE is only a standard
> way to dynamically establish security associations. (same comment
> about section 3) - 2.3flooding attacks: arguments about amplification
> are specious: the current real world threat is DDoS and the main
> defense against it, the ingress filtering (BCPs 38 and 84), i.e., we
> are either vulnerable or not vulnerable to both DDoS and RO
> reflection attacks (modulo the use of "real" alternate care-of
> addresses). So I consider the 2.3 section as delibarately incomplete.
>  - 3.1registration procedure: ESP (with non-null encryption and 
> authentication) support is mandatory for HAs and use is recommended 
> for mobile nodes. At least the word "optionally" before encrypted is
> wrong. - 3.2goals and assumptions: the discussion about the size of
> the PKI is misleading: first the number of certificates is the number
> of mobile nodes, not the number of possible home addresses, second
> X.509 PKIs are hierarchical and can handle very large numbers of end
> entities (I know examples of PKIs with millions of certificates). The
> only real issue is it seems a global PKI is not wanted by people (and
>  not for security reasons :-) so should not be considered as
> available in any time scale. - 3.2goals and assumptions: the argument
> that authentication can not help against flooding attacks is wrong:
> authentication can help but at the condition the care-of address is
> covered. This is usually not the case but this is a different
> argument. - 3.2goals and assumptions: I reviewed a research paper
> proposing certificate-based authorization of care-of addresses so the
> discussion about this concluding it is not possible is wrong. -
> 3.2...: the decision about ingress filtering refers to
routing-routability
> design *only*. The idea that ingress filtering can't help and care-of
>  address test is necessary is the own opinion of authors. -
> 4.2signaling optimizations: bps is not an ISO unit. - 5.1ip-address
> tests: I suggest to add correspondent-driven tests to this section,
> cf draft-dupont-mipv6-rrcookie-00.txt) - 5.10: acess -> access ...
> 
> I have a real concern about this document: its title is for a WG
> document, reflecting a consensus of the WG, when what I can find in
> it is mainly the own opinion of authors.
> 
> Regards
> 
> [e-mail]



_______________________________________________
Mip6 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mip6