Subject: Re: [spring] AD Review of draft-ietf-spring-segment-routing-ldp-interop-09

From: Alvaro Retana <[email-masked]>
Date: Thu, 10 May 2018 16:41:53 -0400

On April 11, 2018 at 10:22:46 PM, Ahmed Bashandy ([email-masked])
wrote:

Ahmed:

Hi!  How are you?

I still have a couple of comments below…but nothing that should hold up
process at this point.  I’ll start the IETF Last Call.

Thanks!

Alvaro.

...

M2.1.2. "At least one SRMS MUST be present in the routing domain.
Multiple SRMSs SHOULD be present for redundancy.”  These MUST|SHOULD seem
to indicate a statement of fact.  Again, from a specification point of
view, what can be enforced?  s/MUST|SHOULD/must|should. Note also that in
7.2 the text says that "Multiple SRMSs can be provisioned in a network for
redundancy.”, which seems to be the right thing (no Normative language).

#Ahmed
I removed these two statements. Instead I modified the 3rd paragraph in
Section 4.2 to indicate that there must be at least one SRMS server in the
domain

The modification of that 3rd paragraph now reads: "At least one SRMS server
MUST exist in a routing domain…”, which really just moved the issue I was
pointing to from 4.2.1 to 4.2.  As I asked before, how can that “MUST” be
enforced?

Note that the sentence following this new text says: "Multiple SRMSs may be
present in the same network (for redundancy).”  I think that’s the right
way to express what is needed (no Normative language).

M2.2. Section 7.2. says that "a preference mechanism may also be used among
SRMSs so to deploy a primary/secondary SRMS scheme”…but no other details
are included.  This document is where the SRMS is first defined, so I would
expect this detail to also be included here.  I note that Section 3.1. (SID
Preference) of draft-ietf-spring-conflict-resolution contains the
preference specification. Please move that section to this document.

Ahmed: agreed. But since section 7.2 is under the manageability
consideration, IMO it should really not contain much specification.
Instead, I modified section  4.2.2 specify how to prefer SRMS
advertisements and removed section 7.2 completely. Section 7.2 in version
11 is section 7.3 in version 10

Ok.

I see that some of the text came from §3.1 in
draft-ietf-spring-conflict-resolution, but not all of that section made it
— specifically the part about the implicit preference values.  Why?

I didn’t check, but I’m assuming that the text that was moved here is not
also in draft-ietf-spring-segment-routing-mpls.  Is that true?

...

M4. Security Considerations.  I tend to agree that this document doesn’t
introduce anything new…but it does specify something different.  The base
SR-related advertisement by an IGP is done for the segments belonging to
the local node, but the SRMS lets a node (any node, multiple nodes) adverse
any mapping (for nodes that may be anywhere in the network) which may
result in conflicting advertisements (in the best case), or even false
ones.  Cryptographic authentication (any any other current security
mechanisms in IGPs) only verify that the information was not changed, but
it doesn’t validate the information itself, which can then lead to
conflicting and or false advertisements, which could “compromise traffic
forwarding”.  You should at least recognize that the risk exists, even if
no specific mitigation (except maybe strict configuration/programmability
control by the operator) can be mentioned.

#Ahmed: Agreed. Added text to indicate what you mentioned

Thanks for adding some text…but I think you should still say more.  The
risk is of course that a rogue router can inject any mapping it wants:
logging, control, etc..help avoid mistakes, but it doesn’t help in the case
where the incorrect/false mapping is advertised on purpose.  This last case
is something I would like to see mentioned explicitly.

...

P2. Please add References for "RSVP-TE, BGP 3107, VPNv4”.   BTW, note that
rfc3107 has been obsoleted by rfc8277 — you make references to “BGP3107”
routes/label.

#Ahmed Removed VPNv4 and added references to the others

I think that by "BGP [RFC8277]” you really didn’t meant just “BGP”, but
“BGP and Labeled Address Prefixes” (or something like that).

There are still 4 occurrences of “BGP3107".

---

From: Ahmed Bashandy <[email-masked]>
Date: Fri, 11 May 2018 08:04:45 -0700

Thanks you very much

I will take care of the comments below in the next version that I plan 
to put out in next week

Ahmed

On 5/10/18 1:41 PM, Alvaro Retana wrote:
> On April 11, 2018 at 10:22:46 PM, Ahmed Bashandy 
> ([email-masked] <mailto:[email-masked]>) wrote:
>
> Ahmed:
>
> Hi!  How are you?
>
> I still have a couple of comments below…but nothing that should hold 
> up process at this point.  I’ll start the IETF Last Call.
>
> Thanks!
>
> Alvaro.
>
> ...
>>> Multiple SRMSs SHOULD be present for redundancy.”  These MUST|SHOULD 
>>> seem to indicate a statement of fact.  Again, from a specification 
>>> point of view, what can be enforced?  s/MUST|SHOULD/must|should. 
>>> Note also that in 7.2 the text says that "Multiple SRMSs can be 
>>> provisioned in a network for redundancy.”, which seems to be the 
>>> right thing (no Normative language).
>> #Ahmed
>> I removed these two statements. Instead I modified the 3rd paragraph 
>> in Section 4.2 to indicate that there must be at least one SRMS 
>> server in the domain
>
> The modification of that 3rd paragraph now reads: "At least one SRMS 
> server MUST exist in a routing domain…”, which really just moved the 
> issue I was pointing to from 4.2.1 to 4.2.  As I asked before, how can 
> that “MUST” be enforced?
>
> Note that the sentence following this new text says: "Multiple SRMSs 
> may be present in the same network (for redundancy).”  I think that’s 
> the right way to express what is needed (no Normative language).
>
>
>>> M2.2. Section 7.2. says that "a preference mechanism may also be 
>>> used among SRMSs so to deploy a primary/secondary SRMS scheme”…but 
>>> no other details are included.  This document is where the SRMS is 
>>> first defined, so I would expect this detail to also be included 
>>> here.  I note that Section 3.1. (SID Preference) 
>>> of draft-ietf-spring-conflict-resolution contains the preference 
>>> specification. Please move that section to this document.
>> advertisements and removed section 7.2 completely. Section 7.2 in 
>> version 11 is section 7.3 in version 10
>
> Ok.
>
> draft-ietf-spring-conflict-resolution, but not all of that section 
> made it — specifically the part about the implicit preference values.  
> Why?
>
> I didn’t check, but I’m assuming that the text that was moved here is 
> not also in draft-ietf-spring-segment-routing-mpls.  Is that true?
>
>
> ...
>
>>> M4. Security Considerations.  I tend to agree that this document 
>>> doesn’t introduce anything new…but it does specify something 
>>> different. The base SR-related advertisement by an IGP is done for 
>>> the segments belonging to the local node, but the SRMS lets a node 
>>> (any node, multiple nodes) adverse any mapping (for nodes that may 
>>> be anywhere in the network) which may result in conflicting 
>>> advertisements (in the best case), or even false ones.  
>>> Cryptographic authentication (any any other current security 
>>> mechanisms in IGPs) only verify that the information was not 
>>> changed, but it doesn’t validate the information itself, which can 
>>> then lead to conflicting and or false advertisements, which could 
>>> “compromise traffic forwarding”.  You should at least recognize that 
>>> the risk exists, even if no specific mitigation (except maybe strict 
>>> configuration/programmability control by the operator) can be mentioned.
> Thanks for adding some text…but I think you should still say more.  
> The risk is of course that a rogue router can inject any mapping it 
> wants: logging, control, etc..help avoid mistakes, but it doesn’t help 
> in the case where the incorrect/false mapping is advertised on 
> purpose.  This last case is something I would like to see mentioned 
> explicitly.
>
>
> ...
>
>>> P2. Please add References for "RSVP-TE, BGP 3107, VPNv4”.   BTW, 
>>> note that rfc3107 has been obsoleted by rfc8277 — you make 
>>> references to “BGP3107” routes/label.
> I think that by "BGP [RFC8277]” you really didn’t meant just “BGP”, 
> but “BGP and Labeled Address Prefixes” (or something like that).
>