Re: [Lsr] AD review of draft-ietf-lsr-isis-area-proxy-09

[Tony Li <[e-mail]>]

Hi John,

Thank you for your comments and suggestions.  I’m incorporating most of 
them and only responding to ones that warrant further discussion.

> ++---
> +jgs: I suggested changing 'should' to 'will' for two reasons. First,
> +and less important, there's the annoying risk of conflation with the
> +RFC 2119 SHOULD. Second, and more important, I think what you're
> +saying is that by using the proxy system ID, as a matter of course
> +this is what will happen. "Should" makes it sound like maybe it will
> +happen, maybe it won't. But in fact, if the outside edge routers do
> +anything other than what you've written, that would be a protocol 
> +error, wouldn't it? 
> ++---


Yes, it would. I’m fine with the wording change.


> @@ -302,14 +315,23 @@
>    value of the SRGB advertised by all Inside Nodes MUST start at the
>    same value.  The range advertised for the area will be the minimum of
>    all Inside Nodes.
> ++---
> +jgs: shouldn't the document say something about what to do if 
> +either one of the MUST requirements isn't met?
> ++---


If either is not met, it would be a protocol error and major malfunctions will occur. 
The network manager should remedy the problem. I’m not sure that needs to be 
called out.

If you’re suggesting that implementations should complain if those constraints are
not met, we did not specify that as that would require a walk through the LSDB
that is not otherwise required.


> @@ -533,6 +559,16 @@
>       Flags: 1 octet.
> 
>       SID/Index/Label: as defined in [RFC8667] Section 2.1.1.1
> ++---
> +jgs: I'm not very happy with this definition for the field. I realize
> +it was copied verbatim from RFC 8667, I've started a discussion with
> +the authors of that RFC,
> +https://mailarchive.ietf.org/arch/msg/lsr/56_LEEZvHDHrnkC98f7BtpOkkY0/
> +
> +Perhaps cite RFC 8667 section 2.1 instead. It's at least equally, and
> +arguably more correct, and if there is an erratum it could benefit
> +from that.
> ++---


Per our private discussion, I’ve left this unchanged.

I believe that amending the title of 2.1.1.1 is both necessary and sufficient. I propose:
“V-Flag, L-Flag, and the SID/Index/Label Field”.


> ++---
> +jgs: of greater concern, I'm wondering why you've elected to use
> +SHOULD and not MUST in many of the subsections. Is it the case that
> +for each field specified as SHOULD, if any or all of these are
> +omitted, the protocol will still operate correctly and usefully?
> +Is it the case for each field specified as SHOULD, the authors think
> +there are plausible circumstances under which the right thing would be
> +to omit the relevant field?
> ++---


A combination of things: first, omitting any one of them will not break things 
syntactically or from a protocol or feature semantics perspective. However,
they may be required from a network architecture perspective in some circumstances
and may become a scalability barrier in different circumstances. It seems like 
implementations may want to exhibit some latitude here.


> @@ -644,6 +701,28 @@
>    If the inside area supports Traffic Engineering (TE), the Area Leader
>    SHOULD copy TE related sub-TLVs [RFC5305] Section 3 to each Extended
>    IS Reachability TLV in the Proxy LSP.
> ++---
> +jgs: what is 4.4.4 and 4.4.5 are specified as MAY. According to the RFC
> +2119 definition of MAY,
> +
> +5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
> +   truly optional.
> +   [etc]
> +
> +That means it would be considered completely reasonable and OK for
> +the area leader to omit both the IS neighbors TLV and end the extended
> +IS neighbors TLV. Would the protocol still function correctly and
> +usefully if both of those TLVs were omitted from the Proxy LSP?  Seems
> +as though it wouldn't.
> +
> +I think probably what is going on here is that you're trying to say
> +that ordinarily, only one or the other would be expected, not both.
> +The RFC 2119 keywords seem like a poor fit for expressing this. This
> +seems like a good time to remind you that it's not mandatory to use
> +RFC 2119 keywords, and in cases like these where they hinder,
> +rather than help, clarity, it's worth considering whether you should
> +rewrite the affected text without relying on them.
> ++---


Yes, we would expect one and not both. There’s a sentence that even says
that. We intentionally selected 2119 keywords because we wanted to explicitly
say what is permissible.

Again, the protocol would work syntactically and semantically if things are
omitted, but not meet network architectural requirements. Additionally,
we did not want to preclude filtering, so we did not think that ‘MUST’ was called 
for.



> @@ -754,6 +846,15 @@
>    If the inside area supports SRv6, the Area Leader SHOULD copy all
>    SRv6 locator TLVs [I-D.ietf-lsr-isis-srv6-extensions] advertised by
>    Inside Routers to the Proxy LSP.
> ++---
> +jgs: Really? Isn't this tantamount to saying, advertise at least one 
> +route for every IS in the area, which kind of seems detrimental to the 
> +scaling goals? It also seems a little contrary to the model of 
> +representing the area as if it were a single router.
> ++---


I welcome alternative text that says something more intelligent. From
my naive understanding, it seems like it’s all or nothing and anyone using
SRv6 isn’t going to settle for nothing.


> @@ -820,6 +921,10 @@
>    which supports the proxy function.  The normal system id of the
>    Inside Edge Router MUST NOT be used as it will cause unnecessary
>    adjacencies to form and subsequently flap.
> ++---
> +jgs: I get why the normal system ID shouldn't be used, but I don't 
> +get why it would cause adjacency flapping?
> ++---


Ok, that’s not worth arguing about, comment withdrawn.


> @@ -914,6 +1019,23 @@
>    within a domain is already addressed as part of the routing protocols
>    themselves.  This document proposes no changes to those security
>    architectures.
> ++---
> +jgs: I'm not convinced this extension doesn't introduce any new attack
> +surfaces. For instance, a single compromised inside router can disable
> +the proxy functionality for the entire area by withdrawing its area
> +proxy router capability. That seems like a fairly bad attack, since it
> +takes the entire area off the air in effect... a case of a single bad
> +router spoiling a whole barrel, er, area. A related one is the
> +compromised router could announce and withdraw the area proxy router
> +capability repeatedly, with a period just slightly greater than the
> +delay mentioned in S. 4.3.1. Again, the functionality specified here
> +amplifies the gravity of the attack compared to what a single router
> +could do otherwise.
> +
> +This isn't so much a request for you to address this specific attack
> +(although that, too) as it is to think a little bit harder about what
> +new attack surfaces may have been introduced.
> ++—


Unless you want to get into byzantine correctness (ob. ref. Radia) of link state
protocols, any compromised router can take down the entire network, either by
withholding vital information, advertising bad information, sending too much
information, or flapping information. The exact syntax isn’t particularly relevant.

We traditionally have not asked implementations to address these attacks and
to do so would be extremely challenging without taking on the byzantine 
correctness problem.

Without those approaches, our security architecture is wholly dependent on the
integrity of the implementations plus the authentication mechanisms that we’ve
defined. Those are the hard crunchy shell around the remaining soft gooey interior.
The fact that we’re creating new mechanisms that could be used to break things
only adds to the gooey interior and in no way compromises our shell.

Yes, I realize that this is not an optimal situation, but until someone can 
design a lightweight link state protocol that exhibits some kind of defense in depth,
it’s our reality.

Regards,
Tony