Subject: RE: [Mip6] Draft on Securing Home Agent List

From: [email-masked]
Date: Mon, 18 Jul 2005 10:01:20 +0300

James,

> > This reminds me of an argument that I often see in the IETF,
> > "implementations aren't doing RFC XXXX, so we have to develop
> > RFC YYYY to fix that". Needless to say, its often the case that
> > thereafter the implementations aren't doing either XXXX or
> > YYYY :-)
> >
> > In some cases (perhaps with SEND too) one may wonder if
> > a complicated piece of other functionality is needed to implement
> > something simple. In such cases it may make some sense to
> > develop alternative schemes. However, in this particular case
> > it would suffice to implement a very small part of SEND, just the
> > RA security and only on the home agents, not on all nodes.
> > The scalability and ease of configuration of that part of SEND
> > is probably close to what any other cryptographic solution would
> > be able to offer, so working on other cryptographic solutions
> > would probably not make much sense. A non-cryptographic, liveness
> > based scheme might be OK, but they don't seem to address
> > the threat that people wanted to fix, so unless we invent something
> > new I don't think we want to go there.
> >
> 
> Yes, that's true.
> 
> Though the WG did have a discussion about whether or not to use IPsec on the
> HA to MN connection, nobody seemed to be making the case that "we shouldn't
> mandate using IPsec in Mobile IP" (though of course now we have the
> mip6-auth option). 

My feeling is that the WG had no choice in this matter - I doubt that MIP would
have gotten through a security review without it.

> I know protocol designers like to avoid "dependencies",
> people are constantly trying to avoid using TCP and then they end up
> reinventing congestion control.
> 
> My point was that if there is an existing protocol that solves the problem,
> then why not use it?

I'm not sure that I buy this argument.  Basically, TCP is available in almost
all (if not all) OSes, so its other considerations that make people forgo
TCP, usually based on performance reasons (including local OS performance
issues like wanted to do everything inside kernal space).  I'm not
sure that's why Jari was discussing about.

> > Anyway, in this discussion I think we should first focus on
> > figuring out if a protocol mechanism is needed at all
> > rather than arguing what it should be. (A protocol mechanism
> > is not needed if, for instance, addition of some configuration
> > information to the implementations would avoid the need to
> > trust RAs. I'm not saying this solves this problem, but at least
> > we should look at it.)
> >
> 
> Well it is always good to have a clear and concise statement of the problem
> before attempting to solve it. If the problem lends itself to a
> configuration solution rather than a protocol solution, then so much the
> better.

My feeling is that if SEND is available, using it to solve this problem
is a good idea; however also stating that if SEND is not available, then
some configuration mechanisms probably will solve this issue.  I think
this is relevant information to the problem - for example even if you
have SEND implemented and use it to Secure the Home Agent list - what
happens when you roam to a network without SEND? A hostile network probably
wouldn't deploy SEND in the first place, so the mobile node would not
have the ability to secure its home agent list.

John

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

---

From: Jari Arkko <[email-masked]>
Date: Mon, 18 Jul 2005 12:11:28 +0300

Hi John,

>some configuration mechanisms probably will solve this issue.  I think
To me, SEND is the right choice, if people think the configuration
scheme is insufficient as a solution. But I think it would be
helpful for the IETF to decide what level of a solution they want
and recommend that, rather than providing a number of
different solutions.

>have the ability to secure its home agent list.
The intent of this draft was to secure the process where
the home agents on the home link discover each others'
presence. As a result, its only the home network admins who
get to decide how to do it; the availability of various tools
in the visited networks is not an issue.

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Mon, 18 Jul 2005 09:19:14 -0700

> My point was that if there is an existing protocol that solves the
problem,

I'm not sure that I buy this argument.  Basically, TCP is available in
almost

jak>> Sometimes these arguments are valid, other times they are just because
engineers like inventing things and therefore want to do a congestion
control algorithm or they mistrust TCP  and SCTP or are misinformed about
how TCP and SCTP work (or, at least, I've seen a couple cases where I would
judge that this was the motivation). The IESG is often quite good at seeing
through this kind of motivation, but it does tend to delay the approval of
drafts.

jak>> As I understand the problem, there is no issue except on the home
link? So only the home link need deploy SEND (and of course the MN), which
is why I think the analogy with IPsec is pretty close.

jak>> Again, a good problem statement should help to clarify the issue. If
the problem can be solved by configuration, as Jari mentioned, that is an
even better solution.

jak>> The metapoint I was trying to make is that saying "we should not have
a dependency between our protocol and others" should not be an acceptable
argument for ignoring a standards-track, RFC-ed protocol that solves the
problem. This point goes beyond SEND, and beyond this particular problem.

            jak

---

From: Sachin Dutta <[email-masked]>
Date: Mon, 18 Jul 2005 21:43:06 -0700

> jak>> The metapoint I was trying to make is that saying "we should not

> jak>> have
> a dependency between our protocol and others" should not be an
acceptable > argument for ignoring a standards-track, RFC-ed protocol
that solves the > > problem. This point goes beyond SEND, and beyond
this particular problem.

Sachin >>> Jak I agree by you that standard tracks should not be ignored
at the same time as Jari also put forward I believe Complexity of the
problem vs Complexity of solution should be measured. 

It is upto WG to decide the complexity of the issue but I personally
feel in this case that MIP6 protocol can come up with some parallel
solution to address this issue rather then implementing complete SEND

~Sachin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
James Kempf
Sent: Monday, July 18, 2005 09:19
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Mip6] Draft on Securing Home Agent List

I'm not sure that I buy this argument.  Basically, TCP is available in
almost
all (if not all) OSes, so its other considerations that make people
forgo
TCP, usually based on performance reasons (including local OS
performance
issues like wanted to do everything inside kernal space).  I'm not
sure that's why Jari was discussing about.

jak>> Sometimes these arguments are valid, other times they are just
because
engineers like inventing things and therefore want to do a congestion
control algorithm or they mistrust TCP  and SCTP or are misinformed
about
how TCP and SCTP work (or, at least, I've seen a couple cases where I
would
judge that this was the motivation). The IESG is often quite good at
seeing
through this kind of motivation, but it does tend to delay the approval
of
drafts.

happens when you roam to a network without SEND? A hostile network
probably

jak>> As I understand the problem, there is no issue except on the home
link? So only the home link need deploy SEND (and of course the MN),
which
is why I think the analogy with IPsec is pretty close.

jak>> Again, a good problem statement should help to clarify the issue.
If
the problem can be solved by configuration, as Jari mentioned, that is
an
even better solution.

jak>> The metapoint I was trying to make is that saying "we should not
have
a dependency between our protocol and others" should not be an
acceptable
argument for ignoring a standards-track, RFC-ed protocol that solves the
problem. This point goes beyond SEND, and beyond this particular
problem.

            jak