[Mipshop] Review of draft-arkko-mipshop-cga-cba-04

Summary: 
---------
Overall, I do believe that MIP6 RO needs to be revised for better
security and optimization. I think using CGAs to generate HoAs is a good
step towards that. From that perspective, this draft is good. I do,
however, think that we don't need any CoA tests (more on that in the
details below). By using CGAs and signed proof to verify HoAs and an
initial HoA test, the CN gets the same assurance about the addresses of
an MN as the HA. That alone is sufficient to generate a binding and
optionally exchange a symmetric key. Hence, I think the "cga" part of
the draft is useful, while the "cba" part is non-essential. 

Having said that, I think it would be best if this document actually
takes a two-step process, going through experimental track first. That
would give us the opportunity to mature the concept and have a solid
proposal for MIP6 RO. I don't think we should target a proposed standard
right away - I think in this case, going to an experimental RFC first is
useful (as we've done before with mobility optimizations such as FMIP
and HMIP). 

Detailed comments  
-----------------

(I've limited these to sections 1 to 3, since that captures the concept)

Major: 
------

1. After some thought, I think we don't need CoA tests (and
consequently, CBA) at all here. In MIP6, CoA test makes sense, since an
attacker has to be present both on the link between the MN and the CN
and on the link between the MN and HA to successfully arrive at the Kbm.
Without the HoTi/HoT or CoTi/CoT, this becomes easier for the attacker,
since presence is required only on one link. However, if the MN's HoA
can be cryptographically verified and the initial HoA test can be done
to (indirectly) prove the existence of a valid registration at the HA,
there should be no need for CoTi/CoT. For e.g., the HA today does not do
a CoA verification - it goes to the same point as in 1 above that if the
MN wants to flood another node by claiming a wrong CoA, it can do that
anyway by other means. 

2. The text under "Initial home address tests" in section 3 is
confusing. I'm not sure I understand the flooding attack as described.
If the goal is to flood any network, as I said in my first point above,
it doesn't need to be done with MIP6. What is more important is ensuring
that an MN that does not have a binding with its HA doesn't end up
creating a binding with a random CN. The fact that the MN has a valid
binding with its HA implies a couple of things - that it has been
authenticated and authorized for MIP6 use and that it is not claiming
another node's HoA. 

Given that, the initial home address test will achieve this - it is just
that the motivation seems to differ in my mind. 

Not-so-major (not-so-minor :))
------------------------------

3. Section 2.2 talks about redirection of an MN's communications to a
third party, thereby flooding the victim (2nd bullet). In my view, this
is not a threat that MIP6 brings. If a malicious node has a goal of
flooding a given node, it doesn't need MIP6 to achieve that. It can send
packets to that IP address and those will do. There isn't a real need to
set up a bogus MIP6 binding to realize that attack. So, I think that
paragraph should be removed. 

4. Also, the point about DoS attacks may stay - but, it is probably
worth mentioning that DoS attacks are achieved by a variety of other
means, some of them, much simpler than engaging in expensive
computations. 

5. Section 3 talks about cryptographically generated home addresses
providing authentication - CGAs provide address ownership validation,
but not really authentication. In order to authenticate a node (i.e., to
verify the node is "who" it claims to be), a verification of its
identity needs to occur - which implies a shared key or a public/private
key pair endorsed by a certificate. I'm assuming this section meant to
really talk about HoA ownership validation? 

Vidya

_______________________________________________
Mipshop mailing list
Mipshop@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop