Re: [Lsr] Paul Wouters' Discuss on draft-ietf-lsr-isis-area-proxy-10: (with DISCUSS)

[Tony Li]

Paul,

There’s really no need for that to be a ‘MUST’. If multiple systems are 
advertising different proxy system identifiers, it should not 
cause confusion because all systems in the area should only use the identifier 
advertised by the area leader.  The other values are
irrelevant and should be ignored.

The only sane case where this might happen is if an area is being reconfigured 
to use a different proxy system identifier. This is a rare
case, to be sure, but it is definitely not an error. Thus, saying ‘MUST’ seems 
unnecessary.  Sane network managers should get the area
back into a consistent state in short order.

Regards,
Tony


> On Jan 21, 2024, at 5:52 PM, Paul Wouters  wrote:
> 
> 
> 
>> On Jan 21, 2024, at 20:45, Tony Li  wrote:
>> 
>> 
>> 
>> Hi Paul,
>> 
>> Already done.  Please see -12.
> 
> Thanks, I had a look. Why did the MUST get changed to a SHOULD? It is okay to 
> state a MUST as well as an action when that MUST is violated ?
> 
> Or was there another reason to change it ?
> 
> Paul
> 
> 
>> 
>> Thanks,
>> Tony
>> 
>> 
>>> On Jan 21, 2024, at 4:48 PM, Paul Wouters  wrote:
>>> 
>>> These changes look fine to me. Please cut another draft and I will update 
>>> my ballot to No Objection.
>>> 
>>> Paul
>>> 
>>> 
>>> 
>>> On Tue, Jan 9, 2024 at 4:15 PM Tony Li >> > wrote:
 
 Hi all,
 
 On second thought, I would like to retract and amend part of my answer to 
 Paul.
 
 
 >> I have a few minor discusses, which could be just because I'm not an 
 >> ISIS
 >> expert. Please bear with me :)
 >> 
 >>   Multiple proxy system identifiers in a single area is a
 >>   misconfiguration and each unique occurrence SHOULD be logged.
 >> 
 >> This does not really answer what systems should do in this case? Use 
 >> none
 >> of them? What would the implication be? Use the one advertised by most 
 >> nodes?
 >> What would the risk be with that? The answers would be great additions 
 >> to the
 >> Security Considerations :)
 > 
 > 
 > I propose to amend this to read:
 > 
 >  Multiple proxy system identifiers in a single
 >   area is a misconfiguration and each unique occurrence
 >   SHOULD be logged and the Area Leader MUST NOT generate the
 >  Proxy LSP.
 
 
 My proposal is unnecessarily draconian and disruptive. A better approach 
 would be:
 
Multiple proxy system identifiers in a single
area is a misconfiguration and each unique occurrence
SHOULD be logged. Systems should use the proxy system
identifier advertised by the Area Leader.
 
 I will maintain an increased level of caffeination. My apologies for the 
 confusion.
 
 Regards,
 Tony
 
 
>> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Paul Wouters' Discuss on draft-ietf-lsr-isis-area-proxy-10: (with DISCUSS)

[Paul Wouters]

On Jan 21, 2024, at 20:45, Tony Li  wrote:Hi Paul,Already done.  Please see -12.Thanks, I had a look. Why did the MUST get changed to a SHOULD? It is okay to state a MUST as well as an action when that MUST is violated ?Or was there another reason to change it ?PaulThanks,TonyOn Jan 21, 2024, at 4:48 PM, Paul Wouters  wrote:These changes look fine to me. Please cut another draft and I will update my ballot to No Objection.PaulOn Tue, Jan 9, 2024 at 4:15 PM Tony Li  wrote:
Hi all,

On second thought, I would like to retract and amend part of my answer to Paul.


>> I have a few minor discusses, which could be just because I'm not an ISIS
>> expert. Please bear with me :)
>> 
>>       Multiple proxy system identifiers in a single area is a
>>       misconfiguration and each unique occurrence SHOULD be logged.
>> 
>> This does not really answer what systems should do in this case? Use none
>> of them? What would the implication be? Use the one advertised by most nodes?
>> What would the risk be with that? The answers would be great additions to the
>> Security Considerations :)
> 
> 
> I propose to amend this to read:
> 
>          Multiple proxy system identifiers in a single
>           area is a misconfiguration and each unique occurrence
>           SHOULD be logged and the Area Leader MUST NOT generate the
>          Proxy LSP.


My proposal is unnecessarily draconian and disruptive. A better approach would be:

           Multiple proxy system identifiers in a single
           area is a misconfiguration and each unique occurrence
           SHOULD be logged. Systems should use the proxy system
           identifier advertised by the Area Leader.

I will maintain an increased level of caffeination. My apologies for the confusion.

Regards,
Tony



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Paul Wouters' Discuss on draft-ietf-lsr-isis-area-proxy-10: (with DISCUSS)

[Tony Li]

Hi Paul,

Already done.  Please see -12.

Thanks,
Tony


> On Jan 21, 2024, at 4:48 PM, Paul Wouters  wrote:
> 
> These changes look fine to me. Please cut another draft and I will update my 
> ballot to No Objection.
> 
> Paul
> 
> 
> 
> On Tue, Jan 9, 2024 at 4:15 PM Tony Li  > wrote:
>> 
>> Hi all,
>> 
>> On second thought, I would like to retract and amend part of my answer to 
>> Paul.
>> 
>> 
>> >> I have a few minor discusses, which could be just because I'm not an ISIS
>> >> expert. Please bear with me :)
>> >> 
>> >>   Multiple proxy system identifiers in a single area is a
>> >>   misconfiguration and each unique occurrence SHOULD be logged.
>> >> 
>> >> This does not really answer what systems should do in this case? Use none
>> >> of them? What would the implication be? Use the one advertised by most 
>> >> nodes?
>> >> What would the risk be with that? The answers would be great additions to 
>> >> the
>> >> Security Considerations :)
>> > 
>> > 
>> > I propose to amend this to read:
>> > 
>> >  Multiple proxy system identifiers in a single
>> >   area is a misconfiguration and each unique occurrence
>> >   SHOULD be logged and the Area Leader MUST NOT generate the
>> >  Proxy LSP.
>> 
>> 
>> My proposal is unnecessarily draconian and disruptive. A better approach 
>> would be:
>> 
>>Multiple proxy system identifiers in a single
>>area is a misconfiguration and each unique occurrence
>>SHOULD be logged. Systems should use the proxy system
>>identifier advertised by the Area Leader.
>> 
>> I will maintain an increased level of caffeination. My apologies for the 
>> confusion.
>> 
>> Regards,
>> Tony
>> 
>> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Paul Wouters' Discuss on draft-ietf-lsr-isis-area-proxy-10: (with DISCUSS)

[Paul Wouters]

These changes look fine to me. Please cut another draft and I will update
my ballot to No Objection.

Paul



On Tue, Jan 9, 2024 at 4:15 PM Tony Li  wrote:

>
> Hi all,
>
> On second thought, I would like to retract and amend part of my answer to
> Paul.
>
>
> >> I have a few minor discusses, which could be just because I'm not an
> ISIS
> >> expert. Please bear with me :)
> >>
> >>   Multiple proxy system identifiers in a single area is a
> >>   misconfiguration and each unique occurrence SHOULD be logged.
> >>
> >> This does not really answer what systems should do in this case? Use
> none
> >> of them? What would the implication be? Use the one advertised by most
> nodes?
> >> What would the risk be with that? The answers would be great additions
> to the
> >> Security Considerations :)
> >
> >
> > I propose to amend this to read:
> >
> >  Multiple proxy system identifiers in a single
> >   area is a misconfiguration and each unique occurrence
> >   SHOULD be logged and the Area Leader MUST NOT generate the
> >  Proxy LSP.
>
>
> My proposal is unnecessarily draconian and disruptive. A better approach
> would be:
>
>Multiple proxy system identifiers in a single
>area is a misconfiguration and each unique occurrence
>SHOULD be logged. Systems should use the proxy system
>identifier advertised by the Area Leader.
>
> I will maintain an increased level of caffeination. My apologies for the
> confusion.
>
> Regards,
> Tony
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Paul Wouters' Discuss on draft-ietf-lsr-isis-area-proxy-10: (with DISCUSS)

[Tony Li]

Hi all,

On second thought, I would like to retract and amend part of my answer to Paul.


>> I have a few minor discusses, which could be just because I'm not an ISIS
>> expert. Please bear with me :)
>> 
>>   Multiple proxy system identifiers in a single area is a
>>   misconfiguration and each unique occurrence SHOULD be logged.
>> 
>> This does not really answer what systems should do in this case? Use none
>> of them? What would the implication be? Use the one advertised by most nodes?
>> What would the risk be with that? The answers would be great additions to the
>> Security Considerations :)
> 
> 
> I propose to amend this to read:
> 
>  Multiple proxy system identifiers in a single
>   area is a misconfiguration and each unique occurrence
>   SHOULD be logged and the Area Leader MUST NOT generate the
>  Proxy LSP.


My proposal is unnecessarily draconian and disruptive. A better approach would 
be:

   Multiple proxy system identifiers in a single
   area is a misconfiguration and each unique occurrence
   SHOULD be logged. Systems should use the proxy system
   identifier advertised by the Area Leader.

I will maintain an increased level of caffeination. My apologies for the 
confusion.

Regards,
Tony


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Paul Wouters' Discuss on draft-ietf-lsr-isis-area-proxy-10: (with DISCUSS)

[Tony Li]

Hi Paul,

Thank you for your comments.

> --
> DISCUSS:
> --
> 
> I have a few minor discusses, which could be just because I'm not an ISIS
> expert. Please bear with me :)
> 
>Multiple proxy system identifiers in a single area is a
>misconfiguration and each unique occurrence SHOULD be logged.
> 
> This does not really answer what systems should do in this case? Use none
> of them? What would the implication be? Use the one advertised by most nodes?
> What would the risk be with that? The answers would be great additions to the
> Security Considerations :)


I propose to amend this to read:

   Multiple proxy system identifiers in a single
   area is a misconfiguration and each unique occurrence
   SHOULD be logged and the Area Leader MUST NOT generate the
   Proxy LSP.


>The Area Leader and other candidates for Area Leader MAY withdraw
>the Area Proxy System Identifier when one or more Inside Routers
>are not advertising the Area Proxy Router Capability. This will
>disable Area Proxy functionality.
> 
> Wouldn't this allow a malicious Inside Router to completely disable the Area
> Proxy functionality? Could this be part of an attack? Can this be mitigated
> somehow? Is there something to say about this for the Security Considerations?



Before we get into this specific question, we should talk about the security of
link state protocols in general. We do have authentication mechanisms in place 
to
ensure that all routers are known participants. However, once inside that 
crunchy
shell of authentication, there is a very soft, gooey interior.

Any node can advertise anything. Sane or not. Correct or not. Consistent or 
not. 
And an authenticated node can trivially DoS attack the entire domain. 
There are even configuration commands defined to do so ( “redistribute bgp …”).

This applies to both IS-IS and OSPF.

Now, to your point: yes, a malicious Inside Router can trivially disable Area 
Proxy 
functionality, there is no question about that. Could that be an attack? Yes, 
certainly.
It would be quite obvious and public as all of the LSDB is completely visible.

Is this worth mitigating? IMHO no. This is no better or worse than any other 
attack
that a malicious IS-IS router can launch. It’s exactly on-par with everything 
else
that’s in the protocol today.

Is this worth discussing in the Security Considerations?  IMHO no.  We decided a
long time ago that we were not going to chase the Byzantine Generals problem 
and 
that hasn’t proven to be problematic in practice.


> 
>0   1   2
>0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |  Type | Length|Proxy System ID|
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |   Proxy System Identifier continued   |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> This diagram seems incorrect. It shows 4 fields instead of 3.
> I suggest using:
> 
>0   1   2
>0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |  Type | Length|   |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Proxy System Identifier   |
>   |   |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Thank you for the suggestion, adopted.


Tony

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Paul Wouters' Discuss on draft-ietf-lsr-isis-area-proxy-10: (with DISCUSS)

[Paul Wouters via Datatracker]

Paul Wouters has entered the following ballot position for
draft-ietf-lsr-isis-area-proxy-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/



--
DISCUSS:
--

I have a few minor discusses, which could be just because I'm not an ISIS
expert. Please bear with me :)

Multiple proxy system identifiers in a single area is a
misconfiguration and each unique occurrence SHOULD be logged.

This does not really answer what systems should do in this case? Use none
of them? What would the implication be? Use the one advertised by most nodes?
What would the risk be with that? The answers would be great additions to the
Security Considerations :)

The Area Leader and other candidates for Area Leader MAY withdraw
the Area Proxy System Identifier when one or more Inside Routers
are not advertising the Area Proxy Router Capability. This will
disable Area Proxy functionality.

Wouldn't this allow a malicious Inside Router to completely disable the Area
Proxy functionality? Could this be part of an attack? Can this be mitigated
somehow? Is there something to say about this for the Security Considerations?

0   1   2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type | Length|Proxy System ID|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Proxy System Identifier continued   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This diagram seems incorrect. It shows 4 fields instead of 3.
I suggest using:

0   1   2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type | Length|   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Proxy System Identifier   |
   |   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr