Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion

From: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
Date: Mon, 8 Oct 2001 12:02:56 -0500

Comments inline:

Michael Thomas [[email-masked]] wrote:
>
>Patil Basavaraj (NET/Dallas) writes:
> > Completely agree with what you are saying and I did not mean to
imply
> > that we should be ignoring the MN-HA security. 
> > Since the MN and HA share keys or certs or have other means of
> > establishing an SA, securing the BUs sent to the HA is considerably
> > easier. The MN->CN BUs are much more difficult to deal with and this
> > is what the IESG has expressed concerns about and what the WG sould
be
> > focusing on.
>
>   The problem is that it isn't this simple. All of the
>   same IPsec considerations that apply to the CN/MN
>   also apply to HA/MN since I could, for example, have
>   a telnet session to my HA while I'm mobile. Thus the
>   piggybacking and authorization issues rear their head
>   again.
>

Piggybacking issues, selector granularity and others exist for all
BUs that use IPsec to secure them. Authorization by the HA for the
address being sent in the BU? The HA would know if a MN sending a BU
is authorized to use that address as its home address. Do you believe
authorization is an issue w.r.t the HA as well?

But the point I was trying to make with the earlier e-mail or in this
thread I guess is that we should try to develop a scheme that works
for securing BUs in the absence of IPsec (I am repeating here). 

Solving the other IPsec issues (that you raise) is required, but lets
not get stuck on trying to make MIPv6 work only with IPsec. We could
do that as a separate effort. Whether the solution implies no
piggybacking, a new next header etc. can be dealt with separately. As
long as the non-IPsec solution does not prevent or cause problems in
sing IPsec we should go forward in getting that solution done.

>   On the other hand, I believe that a small set of
>   rules that have been discussed here ad infinitum
>   should solve this problem for both, and that
>   they can be added to the draft with minimal
>   fuss. If they must be a separate draft, we
>   should at least give them the same priority 
>   for completion.
>

Priority should be to get a solution for BUs that allows the MIPv6
spec to move forward. Why bind that to getting the IPsec solution
done? Not to say that the IPsec solution is not important, but there
is no need to create a normative reference between the MIPv6 spec and
the IPsec solution for BUs.

>	Mike

-Basavaraj

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 08 Oct 2001 10:54:08 -0700

> sing IPsec we should go forward in getting that solution done.

Auth Data Suboption is a very good alternative for securing the BUs.
lets work on it and move the MIPv6 spec forward.

IMO, auth data suboption can also be used to secure the BU to the home
agent.

Vijay

---

From: Michael Thomas <[email-masked]>
Date: Mon, 8 Oct 2001 17:27:39 -0700 (PDT)

> authorization is an issue w.r.t the HA as well?

   Yes. There's no reason that my linux box at
   home shouldn't be able to function as my home
   agent as well, right? My linux box is loaded 
   up with all kinds of other goodies which don't
   necessarily have same security requirements.

 > for securing BUs in the absence of IPsec (I am repeating here). 

   I understand, it's just that I think they need to
   be given equal priority because they're both important
   pieces of the whole solution. It _would_ be nice to
   get back to the CN/MN problem though.

 > sing IPsec we should go forward in getting that solution done.

   I'd be *very* reluctant to axe the strong
   authentication mechanism out of the main MIP
   draft, which is the way I'm reading this
   (correct me if I'm wrong). I think there's a
   lot of danger of not getting wide scale
   deployment if it isn't in the spec, and most
   especially if mipv6 allows the use of the weak
   variety (<-- should I read the requirement
   draft as forbidding that???)

 > the IPsec solution for BUs.

   We have no other solution that gives strong
   authentication and is backed with key
   distribution protocols. I do not see how
   we can avoid this to move mipv6 forward.

	  Mike