Re: Guaranteeing adjacency for PIM routers--some questions

Hello,

See inline, please.

Liu Ya wrote:
> Hi Bill,
> 
> See inline please. 
> 
> JW Atwood wrote:
>> ...
>> A solution to this problem will be applicable to
all exchanges with
>> "adjacent" routers.  Thus, the work could
be useful in securing
> PIM-SM
>> link-local exchanges, OSPFv3 exchanges (see RFC
4552) and (possibly)
>> other peer exchanges.
>>
> Agree. I'm working on OSPFv3 automated group key
management, where
> dynamically building up router topology image would be
used either.

May I know the draft-xxx identifier for this work?  I did
not find 
anything in the ospf WG or the msec WG.

> 
>> The basic principle is simple: whenever a router
will be added or
>> joined, the GCKS will create a new SA for the SSM
group for which
> the
>> added or joined router will be the speaker, and
distribute
>> the necessary
>> information to the listeners (all the adjacent
routers).  The
> question
>> to be resolved is how will the GCKS get the list of
adjacent
>> routers to
>> the newly joined router?  Two options are
possible:
>>
>> a) Dynamic mode: Take the arrival of a message from
a peer as prima
>> facie evidence that the peer is adjacent. 
> 
> I don't understand your point well . More detailed
classifications are
> welcome 

Dynamic case: Build up knowledge of the adjacency from
observing the 
messages that arrive.
Static case: Only acknowledge (or allow) the adjacencies
that are 
pre-installed by the system administrator.
> 
>> (This implies two
>> assumptions: 1) that routers will not forward
link-local messages,
> and
>> 2) that no "rogue" router is on the
subnet.)  In this case, the only
>> property of the peer to be verified is whether the
peer is
>> "legitimate"
>> (which should eliminate "rogue" routers).
It permits only
>> validating the
>> router itself, not its adjacency matrix.  However,
the "authority"
>> (typically the GCKS) could build up dynamically an
image of
>> the topology
>> by examining the requests for validation.
>>
>> The "legitimacy" of a particular router
could be based on some
>> pre-configured secret, stored in a configuration
file on the
>> router, or
>> in a unique hardware device associated with the
router.
> 
> It is a router peer authentication issue. GDOI Phase II
protocol meets
> this requirement.

I will have to read GDOI again before I can (hopefully)
understand. 
Here is my concern.  I say, "I am a valid router".
 My peer says, "Prove 
it."  How do I do this?  This would seem to be
independent of GDOI.

> 
> LIU Ya
> 
>> b) Static mode: The GCKS or "authority"
will maintain an adjacency
>> matrix (which in turn requires that the system
administrator
> maintain
>> the information in a machine-accessible format).
However, it permits
>> maintaining significantly more control over the
router-to-router
>> communication within the network.
>>
>> Clearly the first option requires that less
information be
>> maintained by
>> the "authority", whereas the second
option may reduce the
>> traffic flow.
>>
>> Our primary question is, "Is it worthwhile
exploring none, the
> first,
>> the second, or both options?"  A secondary
question is, "Will any of
>> these options be operationally viable, or will they
require the
>> maintenance of information where the average
systems
>> administrator will
>> find it difficult to justify the time
expenditure?"
>>
>>
>> Any comments from the list will be most
appreciated, and will guide
> us
>> in our development of a solution to the link-local
security problem.
>>
>>
>> --
>>
>> Dr. J.W. Atwood, Eng.             tel:   +1 (514)
848-2424 x3046
>> Professor Emeritus                fax:   +1 (514)
848-2830
>> Department of Computer Science
>>    and Software Engineering
>> Concordia University EV 3.185     email: billcse.concordia.ca
>> 1455 de Maisonneuve Blvd. West    http:
>> //users.encs.concordia.ca/~bill
>> Montreal, Quebec Canada H3G 1M8
>>
>>
>> _______________________________________________
>> MSEC mailing list
>> MSECietf.org
>> https://w
ww1.ietf.org/mailman/listinfo/msec
> <https
://www1.ietf.org/mailman/listinfo/msec> 
> 
> 

-- 

Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424
x3046
Professor Emeritus                fax:   +1 (514) 848-2830
Department of Computer Science
    and Software Engineering
Concordia University EV 3.185     email: billcse.concordia.ca
1455 de Maisonneuve Blvd. West    http://users.enc
s.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

_______________________________________________
MSEC mailing list
MSECietf.org
https://w
ww1.ietf.org/mailman/listinfo/msec