List Info

Thread: using MH is not a magic "re-use"




using MH is not a magic "re-use"
user name
2006-11-14 07:57:07
 > >> How?  There isn't any way for LFNs to inform
MR about delegating
 > >>  authorization.
 > > 
 > > => Huh? What authorisation does the LFN
delegate for the MR to send
 > >  a BU for the entire prefix, including its own
address???
 > 
 > Because HA is sure that MR is allowed to send a BU for
that prefix as
 > suggested by the Prefix Table, which is hard-wired.

=> And if the prefix is already hardwired, then obviously
the MR is
authorised to bind addresses derived from that prefix. I
don't
understand what isn't clear here.

 > 
 > A HA wouldn't have a way to check addresses in the
flow bindings
 > unless the Prefix Table were extended.  And one can't
extend the
 > Prefix Table with hardwired preferences, because
there's no 
 > way for HA
 > to know in advance what apps may or may not run on
LFNs.

=> This is completely irrelevant, if the MR owns the
right to bind the
prefix then it has the same right for all addresses under
that prefix,
no knowledge of apps is necessary. If you have a specific
attack in mind
then share it with the list.

 > 
 > The MR doesn't inject any route without HA's prior 
 > hard-wired approval.
 > 
 > You seem to make a distinction between LFNs and MNNs. 

=> No I don't, not in the context of this discussion.

    Flow
 > preferencess of MNNs that are actually MNs (not LFNs)
can't be
 > pre-configured at MR's HA anyways.  So we're left with
LFN discussion
 > only.
 > 
 > One can't instruct a MR's HA about the flow
preferences of 
 > some random
 > MN that may come by.  And that MN's flow preferences
have no sense on
 > the MR.

=> I think you're confusing different issues here. Any
router on the
internet can inject routes for prefixes it is authorised to
route.
Routers also load balance flows all the time, nothing new
here. If an
MNN is served by the MR and it derives an address based on
the MNP then
the MR has the authority to route flows in the best way it
sees fit.
This is not a security discussion, if you have a threat
specific to this
discussion then share it with the list.

Hesham

 > 
 > Alex
 > 

_______________________________________________
Monami6 mailing list
Monami6ietf.org
https:
//www1.ietf.org/mailman/listinfo/monami6
using MH is not a magic "re-use"
user name
2006-11-14 14:20:36
Soliman, Hesham wrote:
>>>> How?  There isn't any way for LFNs to
inform MR about 
>>>> delegating authorization.
>>> 
>>> => Huh? What authorisation does the LFN
delegate for the MR to
>>>  send a BU for the entire prefix, including its
own address???
>> 
>> Because HA is sure that MR is allowed to send a BU
for that 
>> prefix as suggested by the Prefix Table, which is
hard-wired.
> 
> => And if the prefix is already hardwired, then
obviously the MR is
>  authorised to bind addresses derived from that prefix.
I don't 
> understand what isn't clear here.

It's not 'binding' as in binding updates.

The Prefix Table authorizes MR to setup forwarding
information about
its HoA and that MNP, but in no way about LFN (of that MNP).
 Flow
bindings on MR mean MR do stuff with the LFN address, for
which
there's no authorization.

Do you think a particular LFN should be imposed the MR's
interface
preference without giving it approval?  How would MR know
what apps
run on LFN?  Makes no sense to me.

>> A HA wouldn't have a way to check addresses in the
flow bindings 
>> unless the Prefix Table were extended.  And one
can't extend the 
>> Prefix Table with hardwired preferences, because
there's no way 
>> for HA to know in advance what apps may or may not
run on LFNs.
> 
> => This is completely irrelevant, if the MR owns the
right to bind
>  the prefix then it has the same right for all
addresses under that
>  prefix, no knowledge of apps is necessary. If you have
a specific
>  attack in mind then share it with the list.
> 
>> 
>> The MR doesn't inject any route without HA's prior
hard-wired 
>> approval.
>> 
>> You seem to make a distinction between LFNs and
MNNs.
> 
> => No I don't, not in the context of this
discussion.
> 
>> Flow preferencess of MNNs that are actually MNs
(not LFNs) can't
>>  be pre-configured at MR's HA anyways.  So we're
left with LFN 
>> discussion only.
>> 
>> One can't instruct a MR's HA about the flow
preferences of some 
>> random MN that may come by.  And that MN's flow
preferences have
>>  no sense on the MR.
> 
> => I think you're confusing different issues here.
Any router on 
> the internet can inject routes for prefixes it is
authorised to 
> route. Routers also load balance flows all the time,
nothing new 
> here. If an MNN is served by the MR and it derives an
address based
>  on the MNP then the MR has the authority to route
flows in the 
> best way it sees fit.

I don't think that way.  I think MR has no right to decide
on behalf
of LFN what interface is best appropriate for what
application.

Basically MR can't do anything about MNP more than just what
the
Prefix Table says.

You seem to think otherwise - that's ok.

> This is not a security discussion, if you have a threat
specific to
>  this discussion then share it with the list.

That's fine.  We may be running in circles...

Alex

_______________________________________________
Monami6 mailing list
Monami6ietf.org
https:
//www1.ietf.org/mailman/listinfo/monami6
using MH is not a magic "re-use"
user name
2006-11-14 14:20:36
Soliman, Hesham wrote:
>>>> How?  There isn't any way for LFNs to
inform MR about 
>>>> delegating authorization.
>>> 
>>> => Huh? What authorisation does the LFN
delegate for the MR to
>>>  send a BU for the entire prefix, including its
own address???
>> 
>> Because HA is sure that MR is allowed to send a BU
for that 
>> prefix as suggested by the Prefix Table, which is
hard-wired.
> 
> => And if the prefix is already hardwired, then
obviously the MR is
>  authorised to bind addresses derived from that prefix.
I don't 
> understand what isn't clear here.

It's not 'binding' as in binding updates.

The Prefix Table authorizes MR to setup forwarding
information about
its HoA and that MNP, but in no way about LFN (of that MNP).
 Flow
bindings on MR mean MR do stuff with the LFN address, for
which
there's no authorization.

Do you think a particular LFN should be imposed the MR's
interface
preference without giving it approval?  How would MR know
what apps
run on LFN?  Makes no sense to me.

>> A HA wouldn't have a way to check addresses in the
flow bindings 
>> unless the Prefix Table were extended.  And one
can't extend the 
>> Prefix Table with hardwired preferences, because
there's no way 
>> for HA to know in advance what apps may or may not
run on LFNs.
> 
> => This is completely irrelevant, if the MR owns the
right to bind
>  the prefix then it has the same right for all
addresses under that
>  prefix, no knowledge of apps is necessary. If you have
a specific
>  attack in mind then share it with the list.
> 
>> 
>> The MR doesn't inject any route without HA's prior
hard-wired 
>> approval.
>> 
>> You seem to make a distinction between LFNs and
MNNs.
> 
> => No I don't, not in the context of this
discussion.
> 
>> Flow preferencess of MNNs that are actually MNs
(not LFNs) can't
>>  be pre-configured at MR's HA anyways.  So we're
left with LFN 
>> discussion only.
>> 
>> One can't instruct a MR's HA about the flow
preferences of some 
>> random MN that may come by.  And that MN's flow
preferences have
>>  no sense on the MR.
> 
> => I think you're confusing different issues here.
Any router on 
> the internet can inject routes for prefixes it is
authorised to 
> route. Routers also load balance flows all the time,
nothing new 
> here. If an MNN is served by the MR and it derives an
address based
>  on the MNP then the MR has the authority to route
flows in the 
> best way it sees fit.

I don't think that way.  I think MR has no right to decide
on behalf
of LFN what interface is best appropriate for what
application.

Basically MR can't do anything about MNP more than just what
the
Prefix Table says.

You seem to think otherwise - that's ok.

> This is not a security discussion, if you have a threat
specific to
>  this discussion then share it with the list.

That's fine.  We may be running in circles...

Alex

_______________________________________________
Monami6 mailing list
Monami6ietf.org
https:
//www1.ietf.org/mailman/listinfo/monami6
[1-3]

about | contact  Other archives ( Real Estate discussion Medical topics )