Subject: [netlmm] Review of draft-giaretta-netlmm-dt-protocol-00

From: "Narayanan, Vidya" <[email-masked]>
Date: Sat, 8 Jul 2006 12:14:09 -0700

All,
I read the draft and am quite disappointed to see how complex it is! At
a high level, I was very surprised to see that the design team felt the
need to introduce 14 messages for mobility management! I'm writing a
quick review of the draft below, keeping the comments to a high level. I
hope that we can streamline the protocol into something more practical
and usable in future versions of the document not too long from now :) 

1. Why is the protocol UDP-based rather than utilizing the IPv6 Mobility
Header? It is, after all, a mobility management protocol. 

2. The entire initiation phase must be optional - in fact, I'd recommend
that the procedure of MAGs discovering and associating with LMAs be kept
out of the base protocol specification - this can happen in various ways
and I would expect this to be deployment specific anyway. It is good to
have one such initiation phase, but I see no reason for it to be part of
the base spec. 

3. The heartbeat messages, at best, must be optional. If there is a
routing infrastructure in place (when is there not?), the MAGs will
learn the LMA reachability via other means (e.g., OSPF). I see no need
for any heartbeats as part of this protocol. 

4. The operational phase, as I observed earlier, has way too many
messages, not all of which are actually needed. Here are some specific
comments on this phase: 

A. The purpose of the LMA Allocation Request/Reply messages seems to be
defeated by the fact that it is sent to *a* selected LMA. If this was
sent to an ALL_LMA_MULTICAST_ADDR or something, I can see some value.
What is the point of selecting an LMA and then asking for allocation?
I'd suggest removing these messages. If an LMA cannot serve an MN, it
will deny the request anyway. There can be some other document in future
that actually handles dynamic LMA assignment. 

B. I don't see a need for both Location Registration and MN address
setup message pairs. This introduces two roundtrips, which I think has
no value and is undesirable. In many systems, the MAG will know the
prefix that it is supposed to use for RAs. It seems wasteful to have to
retrieve this per MN. There are a set of prefixes served by each LMA and
beyond that, it is really a matter of policy, which may already be
available at the MAG. So, I think the location registration should be
done in one message that contains the IP address of the MN, after the
configuration of the IP address by the MN. 

C. Similar comment as B on Location De-registration/MN address remove
message pairs. 

D. I don't see a need in this specification for the Routing Setup/Ack
messages - I can see this being useful when GRE or MPLS like forwarding
is used to exchange the labels - but, these messages seem to be of no
value here. I suggest removing these and introducing them when there is
a need in future specifications. 

E. What is the difference between the MN address remove and Routing
Remove message pairs? Is it just the direction of the messages? If so,
I'd suggest removing the Routing Remove pair and just having one - I
don't see why it cannot be initiated by either entity, if that's the
idea. 

5. I'm not sure that the MN ID option is really needed. I can see this
being useful for multi-homing cases, but that's not supported in this
base spec anyway. If we can remove the per MN location registration
messages as suggested here, I don't see a need for this. 

6. I don't think this document needs to define the Routing Tag option -
it is not used here anyway. When a document describes the use of GRE or
MPLS, it can be introduced there. The protocol itself is extensible -
so, there should be no need to define options that aren't directly of
use to this specification. 

7. I saw text alluding to the fact that there may not always be a
lifetime. This is a bad idea - I think the protocol should be soft state
and should mandate a lifetime. 

8. The protocol does not mandate any security for signaling - I think
mandating an SA between MAG and LMA is a good idea. Otherwise, we are
likely to run into sloppy deployments that opens up the possibility of
all kinds of attacks. 

9. There is no reason that the MAG should be mandated to be the DHCP
relay agent for stateful address allocation - how the MAG learns about
the MN attachment is out of scope anyway. In reality, it may be
practical for the MAG to be the relay agent - but I don't see why this
needs to be mandated. 

10. The description of IP multicast seems confusing. I think there is a
need to clearly spell out neighbor discovery operation specifically to
avoid confusion. Data plane multicast can be described separately.
PIM-SM has been assumed to be the multicast routing protocol - while it
is the most widely adopted protocol, the description should not be tied
to PIM-SM. I think this needs more work in general. 

11. I don't think the MAG should be mandated to be the default gateway.
There are systems where people look for deployment of this protocol
without any IP level messaging upon handoff (i.e., no need for RS/RA
even). When the LMA is allowed to be the default gateway, such a
deployment is feasible. If the MAG needs to be the default gateway,
there will always be the need for an RA when the MN hands off from MAG
to MAG. It may be fine to recommend that the MAG be used as the default
gateway, but this should not be mandated. 

12. An important vulnerability here is that when a MAG is compromised,
it opens up the possibility of redirection attacks on any IP address in
the NetLMM domain. This should be described in the security
considerations section. Given that the MAG is an edge entity, this is an
important consideration for deployment. 

I hope that helps and I hope we can discuss these further in Montreal. 

Thanks,
Vidya

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

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 08 Jul 2006 16:59:24 -0400

Hi Vidya,

Some brief comments, inline.  Not all, but many of the issues you raise have
had long discussion threads in the design team - I think the most complete
response to several of these will be to open up the design team mailing
list archives.  But briefly:

> Header? It is, after all, a mobility management protocol. 

The MH is not a regular message transport protocol, and doesn't really
fit the bill if you look at the requirements more closely.  We had a
very long discussion regarding MH vs. UDP. vs. SCTP - the upshot is that
some of us would like to run this over SCTP in the future, but what we
could get consensus on was UDP.  Personally I think the MH idea is a
_vile_ idea, but others see it somewhat more positively.

> have one such initiation phase, but I see no reason for it to be part of

Letting it be optional I agree with, keeping it out of the base protocol
I definitely don't.  I think we need to understand that the NetLMM
protocol in many ways is closer to a routing protocol than it is to
various flavours of MIP, and tearing out anything which doesn't resemble
MIP sufficiently will leave us with only half a solution.

> for any heartbeats as part of this protocol. 

There is strong indication from some of the potential users (3GPP,
WiMAX) that operationally, some kind of liveness indication is needed.
Personally, I'd prefer to require that NetLMM be run over SCTP, which
would provide the needed indications without making them part of NetLMM;
but with the choice of UDP as transport, some liveness detection seems
indicated.

I don't think this is a vital part of the protocol, but I'm pretty
clearly in favour of keeping it, rather than discarding it.
(And as for most of the other questions, there are long threads in
the DT archives about this... ;-)

> messages, not all of which are actually needed. Here are some specific

As a general comment, I disagree.  For this statement to carry weight,
I'd prefer that you quantify 'Way too many messages', and explain what
number you would like, and why.  We could reduce the number of messages
to ONE, and instead add a number of options - this would appear to
satisfy your desire here, but would not make the protocol one whit
easier to understand -- quite to the contrary.

I would like to think of the messages here as designed not only from
the viewpoint of which atomic operations are needed, but also from
a viewpoint of plainly showing the operations needed.  We are already
aware of the need to optimize some messaging sequences, and already
have discussed various mechanisms for combining multiple messages in
one, in order to reduce the number of round trips.

However this is an OPTIMIZATION exercise, and it's bad engineering to
optimize before you have provided and verified the basic functionality.
Only then are you in the position of being able to analyze the possible
optimizations, and do meaningful optimizations as opposed to those
based on hunches, which often add complexity without providing better
performance.

> that actually handles dynamic LMA assignment. 

There are both deployment issues, error-handling issues and timing
issues involved in eliminating this message.  I'm strongly in favour
of keeping it, as it provides for cases where you may want to pre-
allocate a particular LMA which has some specific desired support
which is not generally available.  There are other issues with removing
this which have been raised by others.

> configuration of the IP address by the MN. 

See my note about optimization above.  I completely agree with respect
to providing a mechanism of sending these with one message pair, but
that doesn't change the fact that they are individual operations which
aren't always both needed at the same time.  We've tried to indicate
clearly that optimizations have been left out of the -00 draft on
purpose.  I think it would be good if we could focus on functionality,
not optimizations for now.

> C. Similar comment as B on Location De-registration/MN address remove

Similar response.

> a need in future specifications. 

I disagre.  If you remove these, you will need to introduce the
content in other messages, and you're back to doing premature optimization.

> don't see why it cannot be initiated by either entity, if that's the

Sure we could do this, with the result being that the protocol becomes
more difficult to understand.  Let me say this again: There is no
intrinsic value in reducing the number of messages, if the number of
identifiable distinct atomic operations which are needed remain the
same.  The semantics of the operations provided by the 2 message pairs
we discuss here are slightly different, so we have chosen to make that
plain in the protocol.  Using one message number instead of two distinct
ones only buy you a slight disadvantage when you need to debug an
installation; it buys you absolutely no reduction in complexity or
increase in performance.

> messages as suggested here, I don't see a need for this. 

Here I'm surprised.  You need to use some ID identity, and you definitely
don't want to pick a random IPvX address out of the many (or none) which
a mobile node might have and use that as the ID.  I don't see how you can
eliminate the MN ID.

> use to this specification. 

I agree with you here, but we didn't have DT consensus to remove this.

> and should mandate a lifetime. 

On the contrary, I think it's very arbitrary, and contrary to the basic
concept of a routing protocol to time out routes arbitrarily.  You'll
have to provide a good motivation why you feel that timing out routes
should be mandatory.

> likely to run into sloppy deployments that opens up the possibility of

I agree - we just didn't get that far.  I thought I added this to the
TODO section, but maybe I misremember.

> practical for the MAG to be the relay agent - but I don't see why this

I think you may be right, but it's not quite as easy as you make it out
to be here.  I think that if you don't require this, you instead need to
add some specification of how the MAG / LMA is informed of dhcp state
changes, in that case.

> to PIM-SM. I think this needs more work in general. 

I think I agree :-)

This was added very shortly before the submission deadline.  Did you
expect the -00 to be in shape to submit for publication already ;-)?

> gateway, but this should not be mandated. 

Hmm.  Interesting.  I think you may be right, but also thing that this
is far from obvious and need discussion.

> important consideration for deployment. 

Agreed.

> I hope that helps and I hope we can discuss these further in Montreal.

Right; and thanks for reading and commenting :-)

	Henrik

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Sat, 8 Jul 2006 14:52:11 -0700

Hi Henrik,
That was a quick response :) Please see inline. 

> 
> Some brief comments, inline.  Not all, but many of the issues 
> you raise have had long discussion threads in the design team 
> - I think the most complete response to several of these will 
> be to open up the design team mailing list archives.  But briefly:
> 

That is one of the caveats of having a design team - the DT gets to
explain many of the discussed issues to the rest of the WG again :) 

> > I read the draft and am quite disappointed to see how 
> complex it is! 
> > At a high level, I was very surprised to see that the 
> design team felt 
> > the need to introduce 14 messages for mobility management! 
> I'm writing 
> > a quick review of the draft below, keeping the comments to a high 
> > level. I hope that we can streamline the protocol into 
> something more 
> > practical and usable in future versions of the document not 
> too long 
> > from now :)
> > 
> > 1. Why is the protocol UDP-based rather than utilizing the IPv6 
> > Mobility Header? It is, after all, a mobility management protocol.
> 
> The MH is not a regular message transport protocol, and 
> doesn't really fit the bill if you look at the requirements 
> more closely.  

I can't think of any requirements in the draft-ietf-netlmm-no-host-reqs
that won't particularly be satisfied with MH - if you're referring to
any other requirements, then, I haven't seen those. 

> We had a very long discussion regarding MH vs. 
> UDP. vs. SCTP - the upshot is that some of us would like to 
> run this over SCTP in the future, but what we could get 
> consensus on was UDP.  Personally I think the MH idea is a 

I disagree. I find it odd to see that you seem to think of NetLMM being
analogous to routing protocols rather than mobility management
protocols. I strongly believe that NetLMM is a mobility management
protocol - otherwise, we'd be doing host-based routing. We are dealing
with mobile nodes roaming across the network here. It is about updating
the mobile node location and not really about host-based routes. 

> > 2. The entire initiation phase must be optional - in fact, I'd 
> > recommend that the procedure of MAGs discovering and 
> associating with 
> > LMAs be kept out of the base protocol specification - this 
> can happen 
> > in various ways and I would expect this to be deployment specific 
> > anyway. It is good to have one such initiation phase, but I see no 
> > reason for it to be part of the base spec.
> 
> Letting it be optional I agree with, keeping it out of the 
> base protocol I definitely don't.  I think we need to 
> understand that the NetLMM protocol in many ways is closer to 
> a routing protocol than it is to various flavours of MIP, and 
> tearing out anything which doesn't resemble MIP sufficiently 
> will leave us with only half a solution.
> 

I'm not sure I agree fully, but it must definitely be optional, if kept
within the spec. 

> Personally, I'd prefer to require that NetLMM be run over 
> SCTP, which would provide the needed indications without 
> making them part of NetLMM; but with the choice of UDP as 
> transport, some liveness detection seems indicated.
> 
> I don't think this is a vital part of the protocol, but I'm 
> pretty clearly in favour of keeping it, rather than discarding it.
> (And as for most of the other questions, there are long 
> threads in the DT archives about this... ;-)
> 

Not every protocol needs to have a liveness check. I cannot imagine the
resulting network conditions if every protocol deployed at every layer
has its own heartbeat - is the requirement for 3gpp or WiMAX
specifically for NetLMM liveness? What is the justification? 

> As a general comment, I disagree.  For this statement to 
> carry weight, I'd prefer that you quantify 'Way too many 
> messages', and explain what number you would like, and why.  
> We could reduce the number of messages to ONE, and instead 
> add a number of options - this would appear to satisfy your 
> desire here, but would not make the protocol one whit easier 
> to understand -- quite to the contrary.
> 
> I would like to think of the messages here as designed not 
> only from the viewpoint of which atomic operations are 
> needed, but also from a viewpoint of plainly showing the 
> operations needed.  We are already aware of the need to 
> optimize some messaging sequences, and already have discussed 
> various mechanisms for combining multiple messages in one, in 
> order to reduce the number of round trips.
> 
> However this is an OPTIMIZATION exercise, and it's bad 
> engineering to optimize before you have provided and verified 
> the basic functionality.
> Only then are you in the position of being able to analyze 
> the possible optimizations, and do meaningful optimizations 
> as opposed to those based on hunches, which often add 
> complexity without providing better performance.
> 

It is the "way too many messages" that I've attempted to explain in A
through D below :) 

> > A. The purpose of the LMA Allocation Request/Reply messages 
> seems to 
> > be defeated by the fact that it is sent to *a* selected 
> LMA. If this 
> > was sent to an ALL_LMA_MULTICAST_ADDR or something, I can 
> see some value.
> > will deny the request anyway. There can be some other document in 
> > future that actually handles dynamic LMA assignment.
> 
> There are both deployment issues, error-handling issues and 
> timing issues involved in eliminating this message.  I'm 
> strongly in favour of keeping it, as it provides for cases 
> where you may want to pre- allocate a particular LMA which 
> has some specific desired support which is not generally 
> available.  There are other issues with removing this which 
> have been raised by others.
> 

I'm not sure I understand the above. I'd like to better understand the
issues. If the LMA is pre-allocated, why is this message needed? 

> > prefix that it is supposed to use for RAs. It seems 
> wasteful to have 
> > to retrieve this per MN. There are a set of prefixes served by each 
> > LMA and beyond that, it is really a matter of policy, which may 
> > already be available at the MAG. So, I think the location 
> registration 
> > should be done in one message that contains the IP address 
> of the MN, 
> > after the configuration of the IP address by the MN.
> 
> See my note about optimization above.  I completely agree 
> with respect to providing a mechanism of sending these with 
> one message pair, but that doesn't change the fact that they 
> are individual operations which aren't always both needed at 
> the same time.  We've tried to indicate clearly that 
> optimizations have been left out of the -00 draft on purpose. 
>  I think it would be good if we could focus on functionality, 

It is not just about optimizations - I think there is no need to retrive
a prefix on a per-MN basis. So, I don't think that the Location
Registration messages are needed at all. The protocol seems very complex
as written now. 

> > messages - I can see this being useful when GRE or MPLS like 
> > forwarding is used to exchange the labels - but, these 
> messages seem 
> > to be of no value here. I suggest removing these and 
> introducing them 
> > when there is a need in future specifications.
> 
> I disagre.  If you remove these, you will need to introduce 
> the content in other messages, and you're back to doing 
> premature optimization.
> 

What part of the content do we need to carry in other messages? I don't
see a need for the content carried in these messages, unless you have
MPLS labels to inform or something similar. 

> Sure we could do this, with the result being that the 
> protocol becomes more difficult to understand.  Let me say 
> this again: There is no intrinsic value in reducing the 
> number of messages, if the number of identifiable distinct 
> atomic operations which are needed remain the same.  The 
> semantics of the operations provided by the 2 message pairs 
> we discuss here are slightly different, so we have chosen to 
> make that plain in the protocol.  Using one message number 
> instead of two distinct ones only buy you a slight 
> disadvantage when you need to debug an installation; it buys 
> you absolutely no reduction in complexity or increase in performance.
> 

I have quite the opposite view on complexity :) As written now with
these two messages, it is confusing. If we say that there is an MN
address remove message, for e.g., to remove an MN from the list and it
can be initiated by the MAG or LMA, it is clearer, IMO. 

> Here I'm surprised.  You need to use some ID identity, and 
> you definitely don't want to pick a random IPvX address out 
> of the many (or none) which a mobile node might have and use 
> that as the ID.  I don't see how you can eliminate the MN ID.
> 

Let me think more about this. 

> > 6. I don't think this document needs to define the Routing 
> Tag option 
> > - it is not used here anyway. When a document describes the 
> use of GRE 
> > or MPLS, it can be introduced there. The protocol itself is 
> extensible 
> > - so, there should be no need to define options that aren't 
> directly 
> > of use to this specification.
> 

I guess we'll have to revisit this for WG consensus :) Seriously though,
there needs to be a good reason why this belongs in this document and so
far, I haven't seen one. 

> > lifetime. This is a bad idea - I think the protocol should be soft 
> > state and should mandate a lifetime.
> 
> On the contrary, I think it's very arbitrary, and contrary to 
> the basic concept of a routing protocol to time out routes 
> arbitrarily.  You'll have to provide a good motivation why 
> you feel that timing out routes should be mandatory.
> 

Here is the motivation - we are dealing with nomadic nodes here - this
protocol is not about static nodes. Nodes roam around and leave without
notice. Hence, a soft state protocol is what makes the most sense to me,
so that states can be cleaned up. That is why it is *not* a routing
protocol. A routing protocol is meant for a network that is fairly
static and stable. If it is in fact a routing protocol, why not use OSPF
host-based routes? Why are we re-inventing a protocol here? 

> I agree - we just didn't get that far.  I thought I added 
> this to the TODO section, but maybe I misremember.
> 

OK. 

> I think you may be right, but it's not quite as easy as you 
> make it out to be here.  I think that if you don't require 
> this, you instead need to add some specification of how the 
> MAG / LMA is informed of dhcp state changes, in that case.
> 

We can talk about this more then. 

> > 10. The description of IP multicast seems confusing. I 
> think there is 
> > a need to clearly spell out neighbor discovery operation 
> specifically 
> > to avoid confusion. Data plane multicast can be described 
> separately.
> > PIM-SM has been assumed to be the multicast routing 
> protocol - while 
> > it is the most widely adopted protocol, the description 
> should not be 
> > tied to PIM-SM. I think this needs more work in general.
> 
> I think I agree :-)
> 

Ok. 

> This was added very shortly before the submission deadline.  
> Did you expect the -00 to be in shape to submit for 
> publication already ;-)?
> 

No, just making an observation :) 

> > to MAG. It may be fine to recommend that the MAG be used as the 
> > default gateway, but this should not be mandated.
> 
> Hmm.  Interesting.  I think you may be right, but also thing 
> that this is far from obvious and need discussion.
> 

Ok, we can discuss this more. 

> > it opens up the possibility of redirection attacks on any 
> IP address 
> > in the NetLMM domain. This should be described in the security 
> > considerations section. Given that the MAG is an edge 
> entity, this is 
> > an important consideration for deployment.
> 
> Agreed.
> 

Good. 

Vidya

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 10 Jul 2006 00:22:33 -0700

My comments below might apply to much of the IETF work, but we have 
to start somewhere:

>list archives.  But briefly:

I find the concept of DTs terribly disturbing at this point.  I have 
read the RFC which talks about the advantages of DTs.  But, given 
that most of the "active" contributors of a WG are typically on the 
DT and given that the few remaining interested parties seem to get 
the "that has been discussed in the DT" response, it seems that DTs 
are not really constructive or useful.  For one thing, they are 
closed with a secretive selection process and with the notion that 
after a while people cannot get on them.  In fact, the nature of that 
operation makes the IETF more of a "closed" body than the many SDOs 
IETF seems to look down upon.

The least we can do is to make the DT mailing list archive 
public.  The best thing is to scrap them.  Appointing a few editors 
and running discussions on the WG mailing list might be a better way 
to do things.

>TODO section, but maybe I misremember.

This saddens me a bit.  Again, please note that these comments might 
apply to other WGs also.  Why is security an afterthought?  Given 
that the threats document has been written, and given that the DT has 
many members, surely some of them could have worked on the security 
aspects from the get go, so it is an integral part of the design.

regards,
Lakshminath

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 10 Jul 2006 07:16:37 -0400

Hello Lakshminath,

> and running discussions on the WG mailing list might be a better way 

I'm happy to see that you have the solution to everything.

I'm also happy to see that you've understood the important basic idea
that DT mailing list archives are *not* secret, and are opened after
the DT effort in order to have thorough documentation of the reasoning
and effort.  The only reason to have them temporarily closed is to give
the DT an opportunity to do focused work for a limited period of time.

So taking the coming public state of the DT archives as a given, I even
dared to indicate *that it might be a good idea for people to look at them*.

I'm sorry if this troubles you.

> aspects from the get go, so it is an integral part of the design.

So, the fact that we didn't have time to write this down in the document
immediately has you mis-characterizing this as "an afterthought"?

Might it not be appropriate to first inquire if we had in fact discussed
and thought about this, which we have?

I see that you seem very eager to launch an attack at the design team
while you haven't given one single comment on the technical work.

Till this changes, I'm afraid I'm not going to consider your comments as
serious contribution to this work, but rather as a possible DoS attack.

	Henrik

---

From: "James Kempf" <[email-masked]>
Date: Mon, 10 Jul 2006 04:52:47 -0700

Lakshminath,

As I have said once before on this list, if you have a process issue, Phil 
and I would appreciate if you would speak with with us about it privately. 
If our answers don't satisfy you, then you can speak with the AD (Jari in 
this case). If you are still not satisifed, you are then free to file an 
appeal with the IESG.

The mailing list is for technical discussion, not process discussion. I have 
seen WGs get derailed completely for 6 months or more by process discussion 
on the mailing list. So far, NETLMM has an excellent track record for good, 
focussed technical discussion on the mailing list. Phil and I would like to 
keep it that way.

Phil and I will be around in Montreal. I'm leaving Tues. afternoon, but Phil 
will be here the entire week, so I'd suggest you send email and let us know 
when and if you want to talk.

Thanx.

            jak

----- Original Message ----- 
From: "Lakshminath Dondeti" <[email-masked]>
To: "Henrik Levkowetz" <[email-masked]>; "Narayanan, Vidya" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Monday, July 10, 2006 12:22 AM
Subject: Re: [netlmm] Review of draft-giaretta-netlmm-dt-protocol-00

> My comments below might apply to much of the IETF work, but we have to 
> start somewhere:
>
> I find the concept of DTs terribly disturbing at this point.  I have read 
> the RFC which talks about the advantages of DTs.  But, given that most of 
> the "active" contributors of a WG are typically on the DT and given that 
> the few remaining interested parties seem to get the "that has been 
> discussed in the DT" response, it seems that DTs are not really 
> constructive or useful.  For one thing, they are closed with a secretive 
> selection process and with the notion that after a while people cannot get 
> on them.  In fact, the nature of that operation makes the IETF more of a 
> "closed" body than the many SDOs IETF seems to look down upon.
>
> The least we can do is to make the DT mailing list archive public.  The 
> best thing is to scrap them.  Appointing a few editors and running 
> discussions on the WG mailing list might be a better way to do things.
>
>
>
>
> This saddens me a bit.  Again, please note that these comments might apply 
> to other WGs also.  Why is security an afterthought?  Given that the 
> threats document has been written, and given that the DT has many members, 
> surely some of them could have worked on the security aspects from the get 
> go, so it is an integral part of the design.
>
> regards,
> Lakshminath
>

---

From: Jari Arkko <[email-masked]>
Date: Mon, 10 Jul 2006 08:38:10 -0400

Folks,

Design teams are one of the tools that we use in the IETF. They
are not a perfect tool, but they can often bring together sufficient
cycles to work on a major specification, create interest in
individuals working together, etc.

However, the results of the design teams are always subject
to the WG process. The situation is not very different from an
individual submission. Also, like individual drafts, design team
drafts can too be early, initial versions. Do not treat the result
as the final output from the WG, treat it as an input to the WG.
If the input has a problem, bring up an issue. If the input is
not ready in some aspects, I hope the design team makes clear
where this is the case. Or others may point it to them.

And like all inputs to the working group, its often useful to
discuss the background and rationale for design decisions.
I would be very surprised if such discussion in the WG
doesn't change some of the decisions, in fact. Design
decisions that can not be backed up by rational
explanations can rightfully be challenged.

In short, I would urge everyone to focus on the technical
evaluation of the design team draft.

--Jari

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 10 Jul 2006 05:57:29 -0700

Hi Henrik,

Given the tone of your response, I don't expect any meaningful 
exchange with you, but here goes:

One of the things I am curious about is the issue of MAG compromise: 
how does an LMA know that a MAG is not lying about a node's 
attachment?  Is the answer,

"See the DT archive"

"This is out of scope and/or the question sounds like a DoS attack"

"use IPsec"

"use 3971"

"All of the above"

"None of the above"

best regards,
Lakshminath

---

From: "Roberts Phil-APR042" <[email-masked]>
Date: Mon, 10 Jul 2006 09:06:00 -0400

None of the above is the answer I believe.

I would like to understand the question better.  Is it any different
than the question of how one router knows whether or not another router
is lying about a node attached to it?

> -----Original Message-----
> From: Lakshminath Dondeti [mailto:[email-masked]]
> Sent: Monday, July 10, 2006 7:57 AM
> To: Henrik Levkowetz
> Cc: [email-masked]
> > >> > mandating an SA between MAG and LMA is a good idea. Otherwise,
we
> are
> > >> > likely to run into sloppy deployments that opens up the
possibility
> of

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 10 Jul 2006 09:25:40 -0400

Hi Lakshminath,

> "This is out of scope and/or the question sounds like a DoS attack"

I appreciate the way you have posed this question.  Are these all the
options I get?

I have a personal opinion, but I'm not going to go there until I
understand what kind of exchange you want here.  If you want a real
technical discussion, let's start it as a proper such, not with a
multiple-choice-test imitation.

This is my last message to you on this topic.

	Henrik

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 10 Jul 2006 06:36:54 -0700

>None of the above is the answer I believe.

Thanks :).  My answer might be different, but anyway.

>is lying about a node attached to it?

Similar, but different.  The scope of the attack is larger.  In a 
way, my concerns about security issues stem from there.  Given that 
NETLMM expands the scope of such attacks, it seems to make sense to 
think about those issues sooner rather than later.  Perhaps the WG 
decides to punt on those, but that should happen after understanding 
the extent of the problem.  Others may think that this is not an 
issue.  I am curious to hear those arguments at the moment than anything.

regards,
Lakshminath

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 10 Jul 2006 06:52:40 -0700

I am fine with design teams in the IETF. I have participated
in a number of them. you can made good progress in a very
short time compared to the mailing list. but I have always
seen design teams formed ad hoc when there a number of
solutions and it is hard getting consensus on the solution.

but the NETLMM case is bizarre. the first charter proposal
explicitly spoke above a forming a design team and doing
the work in the design team even before there was a problem
statement. even before there were multiple solutions. I had
protested about this when the NETLMM WG was being chartered.
but folks didnt seem to care.

I hope NETLMM is an exception and we won't form design teams
like this again.

Vijay

ps: I am setting in the NETLMM WG meeting and it appears to
me that one of the design team members is giving a NETLMM
tutorial to the rest of the WG. :(

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 10 Jul 2006 06:59:56 -0700

Well, actually I don't like to be confrontational, but I saw your 
message as heading in that direction and more than that frustrated by 
the allusions to DT discussions (as yet inaccessible -- or am I 
wrong, have the archives been made available?) as responses to most questions.

In the interest of actually having a technical discussion, here goes:

attachment?

Thoughts?  (If you prefer, you might also start with a response to my 
note to Phil).  Thanks in advance.

best regards,
Lakshminath

At 06:25 AM 7/10/2006, Henrik Levkowetz wrote:
> possibility of

---

From: "Roberts Phil-APR042" <[email-masked]>
Date: Mon, 10 Jul 2006 10:20:31 -0400

> issue.  I am curious to hear those arguments at the moment than
anything.

I agree that it's an issue and that we shouldn't punt on it.  I'm not
sure I agree that the scope is larger, perhaps you could clarify that?

> > > > >>Some brief comments, inline.  Not all, but many of the issues
you
> > > > raise have
> > > > >>had long discussion threads in the design team - I think the
most
> > > complete
> > > > >>response to several of these will be to open up the design
team
> > > mailing
> > > > > I find the concept of DTs terribly disturbing at this point.
I
> >have
> > > > > that most of the "active" contributors of a WG are typically
on
> >the
> > > > > the "that has been discussed in the DT" response, it seems
that
> >DTs
> > > > > after a while people cannot get on them.  In fact, the nature
of
> >that
> > > > > and running discussions on the WG mailing list might be a
better
> >way
> > > >and effort.  The only reason to have them temporarily closed is
to
> >give
> > > >So taking the coming public state of the DT archives as a given,
I
> >even
> > > >dared to indicate *that it might be a good idea for people to
look at
> > > them*.
> > > > >> > 8. The protocol does not mandate any security for signaling
- I
> > > think
> > > > >>I agree - we just didn't get that far.  I thought I added this
to
> >the
> > > > > that the threats document has been written, and given that the
DT
> >has
> > > >Till this changes, I'm afraid I'm not going to consider your
comments
> >as

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 10 Jul 2006 10:45:04 -0400

> wrong, have the archives been made available?) as responses to most questions.

I understand.  I was trying to say that there was much more details in
the archives, and I fully expected the archives to be made available.
If you go back, you'll note that I was *also* trying to reply to Vidya
directly in-line.

Making the archives public has not been done yet, but I'd suggest it be
done swiftly now.

> how does an LMA know that a MAG is not lying about a node's

There are three potential questions here:
  1 How can the LMA know that the information sent by the MAG is received
    uncorrupted,
  2 How can the LMA know that the MAG hasn't been subverted in place,
  3 How can the LMA know that the MAG hasn't been covertly replaced

I think the question you're asking is either number 2 or 3, or both,
but to give you my view of all three:

1. I expect this to be handled by either signed or encrypted communication
between the MAG and LMA.  One way is by using IPsec for all control
signalling.  There are others.  I don't think this is a basically hard
problem today.

2. This is a very hard problem, because if the MAG is subverted in place,
the attacker / subverter will gain access to any keys or shared secrets
and will be able to lie very convincingly.  I don't have a good answer
to this.

3. In this case, supposing the attacker doesn't also have gained access
to private keys or shared secrets, then requiring signed or encrypted
control messages should handle this - the replaced MAG will not be able
to impersonate the original convincingly.

Have I understood your question correctly?

	Henrik

>> most complete
>> look at them*.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 10 Jul 2006 08:24:19 -0700

>and will be able to lie very convincingly.  I don't have a good answer

It's really #2 above.  Just like IP address authorization, this might 
be a difficult problem.  My goal is to have that described early 
enough so people can start thinking about it.

Lakshminath

> team mailing

---

From: "Roberts Phil-APR042" <[email-masked]>
Date: Mon, 10 Jul 2006 11:26:56 -0400

OK, Thanks for responding.

I guess I still disagree that it's larger (we could make an analogy from
routing) but I'm not sure that's a really productive discussion.  So
let's go with just saying that it's different but perhaps similar?

Thanks for your input on RPSEC.  I can see how a different solution
might be needed for each different routing protocol, and since we have a
new protocol it might demand its own solution.  It would be good to
leverage knowledge about problems and solutions that others have already
worked through.

> Sent: Monday, July 10, 2006 10:09 AM
> To: James Kempf; Roberts Phil-APR042; Henrik Levkowetz
> Cc: [email-masked]
> Subject: Re: Mitigating the threat of MAG compromise (was: Re:
[netlmm]
> Review of draft-giaretta-netlmm-dt-protocol-00)
> 
> I will use this thread (the subject line is more indicative of the
> discussion) to continue on this topic:
> 
> Phil wrote:
>  >"I agree that it's an issue and that we shouldn't punt on it.  I'm
not
>  >sure I agree that the scope is larger, perhaps you could clarify
that?"
> 
> I should clarify first that there are aspects to this beyond just the
> scope being larger.  I am not sure how current my NETLMM terminology
> is (at some point, I've read most of the protocol proposals and
> recently skipped through the dt-protocol draft), but here goes:
> 
> So, first the scope is indeed larger.  A malicious MAG can claim
> attachment of any mobile node within an LMM domain and the LMA might
> give equal weight to all such claims.  There is probably no easy way
> to solve the problem other than forwarding data through all those
> tunnels (assuming that at least one such claim is legitimate).  The
> scope is larger in the sense that the "attack" is now expanded to the
> LMM domain.
> 
> Next there is the work in RPSEC, but at first look you'll note that
> the problem and the solution space is different for each of the
> various types of routing protocols.  BGP has its own issues and OSPF
> has its own.  I heard from James that this topic might be forwarded
> to the RPSEC WG.  I realize that you don't want to hear process stuff
> here, but I must say that given the history of that group, I am not
> really encouraged by that direction.
> 
> As Vidya notes the MAG is a first hop entity and yes, that makes this
> a more difficult, but at the same time a focused problem than generic
> routing protocol security.  For instance Radia's Byzantine failure
> model aims at being able to communicate as long as there is a path
> between a source and a destination.  In that sense, the goal of the
> NETLMM protocol might be for an LMA to find the MAG that is
> functional when there are conflicting claims of association.  That
> might not be such a difficult problem to solve.
> 
> Hope that helps.
> 
> regards,
> Lakshminath
> 
> 
> At 07:04 AM 7/10/2006, James Kempf wrote:
> >>decides to punt on those, but that should happen after
> >>understanding the extent of the problem. Others may think that this
> >>is not an issue.  I am curious to hear those arguments at the
> >>moment than anything.
> >
> >Thanx for raising this issue. I think we've identified the theat of
> >MAG compromise in the threats draft, I'll check to make sure if the
> >specific consequences you've raised are there as well..
> >
> >In general, this is a difficult problem. Sam had some comments on
> >the general issue of router security during the IESG review of the
> >PS draft and what specifically NETLMM needs for it. There is a
> >discussion going on in the Routing Area (rpsec WG) on this issue,
> >and Sam would like us to contribute any NETLMM specific requirements
> >to that discussion. There is a question of how much NETLMM can or
> >should do to mitigate the threats involved in router compromise, and
> >how much needs to be part of a more general router security
> >solution. If you have any thoughts on that, I'd like to hear them,
> >specifically with regard to Phil's question. How is a MAG compromise
> >different from, say, compromise of a NAS or router that lies about a
> >node's attachment?
> >
> >            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 10 Jul 2006 10:36:43 -0700

> attachment of any mobile node within an LMM domain and the LMA might give 
> equal weight to all such claims.  There is probably no easy way to solve 
> the problem other than forwarding data through all those tunnels (assuming 
> that at least one such claim is legitimate).  The scope is larger in the 
> sense that the "attack" is now expanded to the LMM domain.
>

So how is this different from a compromised NAS or AAA server that can claim 
network access authentication of any mobile node within its scope of 
control?

            jak

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 10 Jul 2006 10:37:42 -0700

>let's go with just saying that it's different but perhaps similar?

Actually, I'd like to hear the case that it's similar in scope.  I 
will promise to not respond to that so as to not prolong that aspect 
of this discussion. :)

>leverage knowledge about problems and solutions that others have already

Sure, I think then the next step would be to document the problem and 
discuss the similarities and differences between securing the NETLMM 
protocol and other routing protocols that RPSEC is considering (in so 
far as we want to re-use solutions being developed there).

regards,
Lakshminath

---

From: "Roberts Phil-APR042" <[email-masked]>
Date: Mon, 10 Jul 2006 13:45:34 -0400

> far as we want to re-use solutions being developed there).

I agree that we should document this in our threats document, what the
problem is and what its implications are.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 10 Jul 2006 10:49:20 -0700

At 10:36 AM 7/10/2006, James Kempf wrote:
>>attachment of any mobile node within an LMM domain and the LMA 
>>might give equal weight to all such claims.  There is probably no 
>>easy way to solve the problem other than forwarding data through 
>>all those tunnels (assuming that at least one such claim is 
>>legitimate).  The scope is larger in the sense that the "attack" is 
>>now expanded to the LMM domain.
>
>So how is this different from a compromised NAS or AAA server that 
>can claim network access authentication of any mobile node within 
>its scope of control?

There are similarities to NAS compromise in that the MAG and the NAS 
are "edge" entities.  Compromise of a NAS has implications (allows 
any MN to access the network; the network provided loses money), and 
there are different mitigation strategies for it.  The MAG can 
conceivably redirect traffic of any node in the LMM domain.

regards,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 10 Jul 2006 08:09:06 -0700

Phil wrote:
 >"I agree that it's an issue and that we shouldn't punt on it.  I'm not
 >sure I agree that the scope is larger, perhaps you could clarify that?"

Hope that helps.

regards,
Lakshminath

---

From: "James Kempf" <[email-masked]>
Date: Mon, 10 Jul 2006 11:10:55 -0700

> There are similarities to NAS compromise in that the MAG and the NAS are 
> "edge" entities.  Compromise of a NAS has implications (allows any MN to 
> access the network; the network provided loses money), and there are 
> different mitigation strategies for it.  The MAG can conceivably redirect 
> traffic of any node in the LMM domain.
>

What are the mitigation strategies for NAS compromise? Are any of them 
possible for the MAG as well?

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 10 Jul 2006 07:04:13 -0700

> Similar, but different.  The scope of the attack is larger.  In a way, my 
> concerns about security issues stem from there.  Given that NETLMM expands 
> the scope of such attacks, it seems to make sense to think about those 
> issues sooner rather than later.  Perhaps the WG decides to punt on those, 
> but that should happen after understanding the extent of the problem. 
> Others may think that this is not an issue.  I am curious to hear those 
> arguments at the moment than anything.
>

Thanx for raising this issue. I think we've identified the theat of MAG 
compromise in the threats draft, I'll check to make sure if the specific 
consequences you've raised are there as well..

In general, this is a difficult problem. Sam had some comments on the 
general issue of router security during the IESG review of the PS draft and 
what specifically NETLMM needs for it. There is a discussion going on in the 
Routing Area (rpsec WG) on this issue, and Sam would like us to contribute 
any NETLMM specific requirements to that discussion. There is a question of 
how much NETLMM can or should do to mitigate the threats involved in router 
compromise, and how much needs to be part of a more general router security 
solution. If you have any thoughts on that, I'd like to hear them, 
specifically with regard to Phil's question. How is a MAG compromise 
different from, say, compromise of a NAS or router that lies about a node's 
attachment?

            jak

---

From: Jari Arkko <[email-masked]>
Date: Mon, 10 Jul 2006 19:50:42 -0400

> possible for the MAG as well?

Well, one obvious strategy is having the home entity actually
authenticate the client entity, rather than relying on a statement
from the NAS that the client in question just entered this network.

This might be something for NETLMM to consider too, at least in
certain deployments. (E.g., if the identity of the mobile node is
provided as a result of its L2 authentication.)

(This does not address all issues. Additional attacks exist, some
with solutions and some with not. In any case, what I described
above is what is in practise deployed in AAA-based networks
today.)

--Jari

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 11 Jul 2006 10:14:59 -0700

I'm just catching up with this discussion. I don't think the scope of
the threat in NETLMM is the same as in routing protocols. In routing
protocols, it takes more than one entity in the network to be lying
about reachability to prefixes for the routing protocol to actually
converge on those fake routes. Doing a rough math, it seems to me that
about 1/3rd of the routers in an OSPF area, for instance, would have to
lie about reachability to a given fake prefix in order for any
meaningful forwarding to the fake prefix to be set up in the network. 

In NETLMM, it only takes the compromise of one MAG to redirect traffic
for any NETLMM address of any MN towards itself. So, I don't think there
is an equality in scope here. 

Am I missing something? 

Vidya

> From: Roberts Phil-APR042 [mailto:[email-masked]] 
> Sent: Monday, July 10, 2006 8:27 AM
> To: Dondeti, Lakshminath; James Kempf; Henrik Levkowetz
> Cc: [email-masked]
> Subject: [netlmm] RE: Mitigating the threat of MAG compromise
> 
> 
> routing) but I'm not sure that's a really productive 
> discussion.  So let's go with just saying that it's different 
> but perhaps similar?
> 
> Thanks for your input on RPSEC.  I can see how a different 
> solution might be needed for each different routing protocol, 
> and since we have a new protocol it might demand its own 
> solution.  It would be good to leverage knowledge about 
> problems and solutions that others have already worked through.
> 
> 
> 
> 
> 
> > has its own.  I heard from James that this topic might be 
> forwarded to 
> > the RPSEC WG.  I realize that you don't want to hear process stuff 
> functional 
> > when there are conflicting claims of association.  That 
> might not be 
> understanding 
> > >general issue of router security during the IESG review of the PS 
> > >draft and what specifically NETLMM needs for it. There is a 
> > >discussion going on in the Routing Area (rpsec WG) on this 
> issue, and 
> > >Sam would like us to contribute any NETLMM specific 
> requirements to 
> > >that discussion. There is a question of how much NETLMM 
> can or should 
> > >do to mitigate the threats involved in router compromise, and how 
> > >much needs to be part of a more general router security 
> solution. If 
> > >you have any thoughts on that, I'd like to hear them, specifically 
> > >with regard to Phil's question. How is a MAG compromise different 
> > >from, say, compromise of a NAS or router that lies about a node's 
> > >attachment?
> > >
> > >            jak
> 
>

---

From: "James Kempf" <[email-masked]>
Date: Tue, 11 Jul 2006 16:43:49 -0700

But I think that the threat of a compromised MAG would be the equivalent of 
a compromised NAS or AAA server lying about the right of a node to enter the 
network, right?

Also, since an access router is, in effect doing host routes incoming, a 
single compromised access router could fake IP addresses on its stub subnet.

I think the general point here I'm trying to make that there is some part of 
the problem that is similar, if not the same. I think we need to clearly 
articulate what the differences are, if any.

            jak

----- Original Message ----- 
From: "Narayanan, Vidya" <[email-masked]>
To: "Roberts Phil-APR042" <[email-masked]>; "Dondeti, 
Lakshminath" <[email-masked]>; "James Kempf" 
<[email-masked]>; "Henrik Levkowetz" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 11, 2006 10:14 AM
Subject: RE: [netlmm] RE: Mitigating the threat of MAG compromise

Am I missing something?

Vidya

---

From: Christian Vogt <[email-masked]>
Date: Wed, 12 Jul 2006 11:10:13 +0200

>                                 Doing a rough math, it seems to me
> that about 1/3rd of the routers in an OSPF area, for instance, would
> have to lie about reachability to a given fake prefix in order for
> any meaningful forwarding to the fake prefix to be set up in the
> network.

Hi Vidya,

not sure why a single compromised access router couldn't inject an
illegitimate prefix into an OSPF area.

Note that the compromised router in this case is an /access/ router,
i.e., all other routers in the OSPF area expect the compromised router
to be the only one adjacent to the advertised bogus prefix.

If the compromised OSPF access router lies about a certain prefix, the
false routing information will be flooded across the OSPF area.  The
bogus OSPF packets are correctly authenticated because the compromised
routers knows the appropriate keys.  Other routers basically have no
choice but to believe in the illegitimate prefix.

Furthermore, if we compare the OSPF scenario with the NETLMM scenario,
the illegitimate OSPF prefix is likely to be a host route, i.e., a
prefix of 128 bit length.  (In NETLMM, a compromised MAG would likewise
install false host routes by setting up incorrect LMA-to-MAG tunnels.)
The bogus 128-bit prefix is most specific and will hence take precedence
over other, possibly legitimate prefixes.

A difference between the NETLMM scenario and the OSPF scenario is that a
compromised MAG can act from an off-path position in NETLMM, but the
link-state mapping in OSPF makes off-path attacks more difficult if not
impossible.

Am I missing something?

- Christian

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

Narayanan, Vidya wrote:
> converge on those fake routes. Doing a rough math, it seems to me
> that about 1/3rd of the routers in an OSPF area, for instance, would
> have to lie about reachability to a given fake prefix in order for
> any meaningful forwarding to the fake prefix to be set up in the
> network.
> 
> In NETLMM, it only takes the compromise of one MAG to redirect
> traffic for any NETLMM address of any MN towards itself. So, I don't
> think there is an equality in scope here.
> 
> Am I missing something?
> 
> Vidya

---

From: Christian Vogt <[email-masked]>
Date: Wed, 12 Jul 2006 18:19:15 +0200

> specific consequences you've raised are there as well..

Yes, section 2.1 of the Threats draft describes malicious/unauthorized
packet redirection at the LMA, which a compromised MAG could initiate.

We have so far extended the section slightly for the forthcoming version
02 of the draft.  Here is a preview:

   2.1  Unauthorized AR

   An AR that is not authorized to propagate NETLMM routing updates can
   result in serious damage to the security of a localized mobility
   management domain.  The AR can redirect traffic from MNs on the AR's
   first-hop link arbitrarily, without authorization from the MN.  The
   AR can ignore routing updates from the LMA so that the victim MNs
   lose their traffic.  An unauthorized AR can also intercept, inspect,
   and redirect data plane traffic for mobile nodes on its last hop
   interface, but this threat is common for any last hop router.

   Furthermore, a bogus AR may be able to cause interruption to a MN by
   deregistering the MN from the NETLMM domain, pretending that the MN
   has powered down.  The MN would then have to go through the network
   access authentication procedure again when it moves to a different
   AR.  It should be able to handle that situation, but the process of
   finding out that something is wrong and then performing re-
   authentication is likely to take some time and hence impair ongoing
   communication sessions.

   Note that this threat applies not just to an AR that is compromised,
   but also to an off-path attacker that manages to forge the identity
   of an authorized AR, and thereby spoof the LMA into conducting NETLMM
   protocol signaling as if the attacker were legitimate.  Such an
   attack could be conducted transiently, to selectively disable traffic
   for particular mobile nodes at particular times.

Depending on the outcome of this thread, there may have to be another
paragraph comparing the NETLMM-specific threat to the similar, possibly
OSPF-based threat in a general IPv6 domain.

And yes, we'll have to do a s/AR/MAG/. ;-)

Regards,
- Christian

-- 
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/

"Everything should be made as simple as possible, but not simpler."
(Albert Einstein)

James Kempf wrote:
> discussion going on in the Routing Area (rpsec WG) on this issue, and
> Sam would like us to contribute any NETLMM specific requirements to
> that discussion. There is a question of how much NETLMM can or should
> much needs to be part of a more general router security solution. If

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 12 Jul 2006 11:15:37 -0700

Hi Christian,

> > have to lie about reachability to a given fake prefix in 
> order for any 
> not sure why a single compromised access router couldn't 
> inject an illegitimate prefix into an OSPF area.
> 
> Note that the compromised router in this case is an /access/ 
> router, i.e., all other routers in the OSPF area expect the 
> compromised router to be the only one adjacent to the 
> advertised bogus prefix.
> 
> If the compromised OSPF access router lies about a certain 
> prefix, the false routing information will be flooded across 
> the OSPF area.  The bogus OSPF packets are correctly 
> authenticated because the compromised routers knows the 
> appropriate keys.  Other routers basically have no choice but 
> to believe in the illegitimate prefix.
> 

If a stub router in an OSPF area advertised a prefix that it doesn't
have reachability to, but is a valid prefix advertised by some other
router in the network, the link state won't converge and that can be
detected. If the stub router advertised reachability to a prefix that
doesn't exist in the network, it is a non-issue with respect to any
redirection attacks, since there really aren't nodes attaching to a
non-existent prefix. 

However, in the NETLMM case, a compromised MAG can redirect traffic
belonging to a valid IP address anywhere in the domain. Hence the
problem. 

> Furthermore, if we compare the OSPF scenario with the NETLMM 
> scenario, the illegitimate OSPF prefix is likely to be a host 
> route, i.e., a prefix of 128 bit length.  (In NETLMM, a 
> compromised MAG would likewise install false host routes by 
> setting up incorrect LMA-to-MAG tunnels.) The bogus 128-bit 
> prefix is most specific and will hence take precedence over 
> other, possibly legitimate prefixes.
> 
> A difference between the NETLMM scenario and the OSPF 
> scenario is that a compromised MAG can act from an off-path 
> position in NETLMM, but the link-state mapping in OSPF makes 
> off-path attacks more difficult if not impossible.
> 

This is true as well, but I meant more the former stuff. 

Regards,
Vidya

> Am I missing something?
> 
> - Christian
> 
> --
> Christian Vogt, Institute of Telematics, University of 
> Karlsruhe www.tm.uka.de/~chvogt/pubkey/
> 
> 
> 
> Narayanan, Vidya wrote:

---

From: Christian Vogt <[email-masked]>
Date: Wed, 12 Jul 2006 22:16:42 +0200

Hi Vidya!

>> If the compromised OSPF access router lies about a certain prefix, 
>> the false routing information will be flooded across the OSPF area.
>>  The bogus OSPF packets are correctly authenticated because the 
>> compromised routers knows the appropriate keys.  Other routers 
>> basically have no choice but to believe in the illegitimate prefix.
>> 
> 

Yes, that's right.

However, a compromised access router in an OSPF area doesn't need
support from any other router if it incorrectly advertises a more
specific sub-prefix of an existing prefix.  This more-specific prefix
doesn't necessarily have to be a host route.

>> route, i.e., a prefix of 128 bit length.  (In NETLMM, a compromised
>>  MAG would likewise install false host routes by setting up 
>> incorrect LMA-to-MAG tunnels.) The bogus 128-bit prefix is most 
>> specific and will hence take precedence over other, possibly 
>> legitimate prefixes.
>> 
>> A difference between the NETLMM scenario and the OSPF scenario is 
>> that a compromised MAG can act from an off-path position in NETLMM,
>>  but the link-state mapping in OSPF makes off-path attacks more 
>> difficult if not impossible.
> 

Right.  My point was that, with OSPF, a compromised access (or stub)
router can do the same damage as a compromised MAG can do in NETLMM,
namly, injecting illegitimate host routes.

And as you say, if a compromised stub router is supported by roughly
1/3rd of all routers in an OSPF area, than the stub router can do even
more damage than a compromised MAG could do in NETLMM.

So it seems that NETLMM is even slightly more secure than pure OSPF in
that a compromised MAG cannot redirect an entire prefix even if it was
supported by a high number of routers in the NETLMM domain.  At least
not for data traffic of mobile nodes.

Of course, OSPF may also be used inside the NETLMM domain...

Regards,
- Christian

Narayanan, Vidya wrote:
> Hi Christian,
> 
>>> Doing a rough math, it seems to me that about 1/3rd of the 
>>> routers in an OSPF area, for
>> 
>> instance, would
>> 
>>> meaningful forwarding to the fake prefix to be set up in
>> 
>> the network.
>> 
>> Hi Vidya,
>> 
>> compromised router to be the only one adjacent to the advertised 
>> bogus prefix.
>> 
>> If the compromised OSPF access router lies about a certain prefix, 
>> the false routing information will be flooded across the OSPF area.
>>  The bogus OSPF packets are correctly authenticated because the 
>> compromised routers knows the appropriate keys.  Other routers 
>> basically have no choice but to believe in the illegitimate prefix.
>> 
> 
> 
>  detected. If the stub router advertised reachability to a prefix
> that doesn't exist in the network, it is a non-issue with respect to
> any redirection attacks, since there really aren't nodes attaching to
> a non-existent prefix.
> 
>> route, i.e., a prefix of 128 bit length.  (In NETLMM, a compromised
>>  MAG would likewise install false host routes by setting up 
>> incorrect LMA-to-MAG tunnels.) The bogus 128-bit prefix is most 
>> specific and will hence take precedence over other, possibly 
>> legitimate prefixes.
>> 
>> A difference between the NETLMM scenario and the OSPF scenario is 
>> that a compromised MAG can act from an off-path position in NETLMM,
>>  but the link-state mapping in OSPF makes off-path attacks more 
>> difficult if not impossible.
> 
> 
> Regards, Vidya
>> -- Christian Vogt, Institute of Telematics, University of Karlsruhe

---

From: Christian Vogt <[email-masked]>
Date: Fri, 14 Jul 2006 23:06:57 +0200

> provided as a result of its L2 authentication.)

E.g., if the MAG solicits an authenticated NA from the MN prior to
sending the Location Registration message to the LMA, the MAG can attach
that NA to the Location Registration message as a proof of the MN's
presence at its local link.

When verifying the signature in the piggybacked NA, the LMA must ensure
that the MAG did not use the same nonce before.  The MAG could otherwise
replay an old NA.  In order to limit the state that the LMA needs for
storing old nonces, nonces may be some function of the current time.  If
that function is one-way, the MAG would have to also include in the
Location Registration message the timestamp based on which the nonce was
computed.

Alternatively, the LMA may send the MAG a nonce to be used in the next NS.

Regards,
- Christian