Subject: [Idr] Robustness of NLRI encoding in draft-ietf-idr-add-paths

From: Daniel Ginsburg <[email-masked]>
Date: Tue, 23 Nov 2010 09:23:29 +0000

Hi,

Assume that peers A and B mishandle their ADD-PATH capability
negotiation and A thinks that B is willing to receive NLRIs encoded in
add-path style, while in fact B isn't. Buggy implementations that may
mishandle capabilities are not unheard of and we all have observed
capabilities misnegotiations happen in the field.

So, when A sends NLRIs with Path Identifier, B tries to interpret them
according to regular encoding rules. It is quite possible for B not to
notice that NLRI is syntactically incorrect (with "right" values of PI
and the rest of NLRI) and to interpret an add-path'ed NLRI as a set of
regular NLRIs. Such misinterpretation might make B accept completely
wrong routes and possibly propagate them to B's peers. That might create
a massive routing disruption, possibly even an Internet-wide.

I would suggest adding a "robustness marker" to the add-path NLRI
encoding. Such marker should make even a half-sane implementation notice
syntactic incorrectness and drop the session, thus limiting damage.

For example for IPv4 NLRI it can be
+------------------------------------+
| Robustness marker (1 octet) = 0xff |
+------------------------------------+
| Path Identifier (4 octets)         |
+------------------------------------+
| Length (1 octet)                   |
+------------------------------------+
| Prefix (variable)                  |
+------------------------------------+

Value of robustness marker is chosen to be 0xff, since no correct IPv4
NLRI can have this length.

Alternatively, to preserve compatibility with existing implementations,
the encoding can be changed to something like
+------------------------------------+
| Robustness marker (1 octet) = 0xff |
+------------------------------------+
| Path Identifier (3 octets)         |
+------------------------------------+
| Length (1 octet)                   |
+------------------------------------+
| Prefix (variable)                  |
+------------------------------------+

-- 
Daniel Ginsburg
Resident Engineer, Professional Services EMEA
Juniper Networks

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 23 Nov 2010 14:48:23 +0100

Hi Daniel,

IMHO protection from possible implementation errors or bugs is an 
important point when designing any new protocol extension. Reg your 
below suggestion I do agree with you, but not at the level of proposed 
NLRI granularity.

Do you really think that sending the robustness marker for _each_ NLRI 
what essentially means for each path of each prefix is a right thing to do ?

So while we are looking to change the NLRI format let me point out 
another observation of current add-paths proposal .. it allows to work 
on a per AFI/SAFI level only. If I have 1 million of IPv4 routes and 
10-50 voice gateways prefixes I particularly care about I do not have a 
way to continue sending my 1 million of IPv4 routes (less the 50 voice 
gateways) the old MP_REACH way with single best path only, with packing 
enabled and without path_id attached.

Add-paths must be as defined today enabled for all IPv4 unicast SAFI and 
what's worse with current implementations enabled uniformly ... that 
means if I need to send all paths for my voice gateways it will also 
result in distribution of all paths for the entire address family.

Therefor combining your point with my point leads to pretty straight 
forward conclusion that add-paths should use it unique 
MP_ADD-PATHS_REACH and MP_ADD-PATHs_UNREACH attributes which would be 
separate from current MP_REACH and MP_UNREACH.

That way there would be no need for any robustness markers.

On the topic of enabling add-paths uniformly today the spec pretty much 
does not provide any option to enable add-paths other then by manual 
configuration at each bgp speaker.

I think we should do better then that and in order to protect from node 
by node misconfiguration be able to mark prefixes for add-paths 
eligibility when they are originated or received into given domain. Base 
add-paths spec should be amended to provide such option.

Many thx,
R.

---

From: Daniel Ginsburg <[email-masked]>
Date: Tue, 23 Nov 2010 14:32:00 +0000

Hi Robert,

I agree with your point. In fact, a few years ago I imagined add-path to
be implemented similarly to you suggestion about MP_ADD_PATHS_REACH and
MP_ADD_PATHS_UNREACH attributes. And indeed no robustness marker is
needed here. However, I can see few things to think about if we go this
way. For instance, what if the same NLRI is advertised in a regular way
as well as within MP_ADD_PATHS_REACH? Should we ignore the regular path?
Or the add-path'ed one? Should we accept both and combine them? What if
the NLRI is being withdrawn by MP_UNREAD and at the same time advertised
by MP_ADD_PATHS_REACH or vice versa? Etc, etc, etc.

Sure, nothing is unsolvable here. We can just set the rules and be done
with it.

As to robustness marker, I must admit it is a sort of a hack. My goal
was to fix the specific issue with robustness without making too
intrusive changes. The second alternative in my email can be easily
implemented (just set the MSB of PI to 0xff) and is compatible with the
existing implementations (if I'm not mistaken, there is at least one
publicly available). However I don't insist on this particular way to
tackle with the issue. There're lots of way to deal with it, including
yours, which is nice and clean and provides additional benefits.

> -----Original Message-----
> From: Robert Raszuk [mailto:[email-masked]]
> Sent: Tuesday, November 23, 2010 4:48 PM
> To: Daniel Ginsburg
> Cc: [email-masked]
> Subject: Re: [Idr] Robustness of NLRI encoding in draft-ietf-idr-add-
> paths
> 
> Hi Daniel,
> 
> what essentially means for each path of each prefix is a right thing
to
> do ?

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 23 Nov 2010 15:57:07 +0100

Hi Daniel,

 > However, I can see few things to think about if we go this way.

I would recommend a very simple solution.

For add-paths enabled prefixes use MP_ADD_PATHS_REACH and 
MP_ADD_PATHS_UNREACH attributes even if there is only a single best path 
there attached.

For prefixes not enabled for add-paths use traditional MP_REACH and 
MP-UNREACH attributes.

Moreover this separation offers a very clear protection and stability of 
best path Internet routing when we start looking at using add-paths over 
EBGP boundaries for selective applications.

Many thx,
R.

---

From: John Scudder <[email-masked]>
Date: Tue, 23 Nov 2010 11:59:51 -0800

Robert,

On Nov 23, 2010, at 8:48 AM, Robert Raszuk wrote:
...
> enabled and without path_id attached.

I don't know what you mean by "with packing enabled"?  You are correct that if you enable add-paths for a given AFI/SAFI the path_id as to be attached for all routes of that AFI/SAFI; however, there isn't any requirement to send multiple paths for all routes.  If you didn't want to send multiple paths, you could certainly send the path_id as zero (or any other fixed value) and essentially ignore it in every other respect.

> Add-paths must be as defined today enabled for all IPv4 unicast SAFI 

I'm not sure what you mean by this either.  There is no requirement in the spec to enable it for any particular AFI/SAFI.

> and
...

As you observe, this is an implementation choice and not fundamental to the protocol.  As I point out above, an implementation is free to pick and choose which prefixes it sends multiple paths for.  (This might be a topic to be mentioned in the add-paths-guidelines draft, though?)

Regards,

--John

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 23 Nov 2010 21:30:40 +0100

Hi John/Enke,

It is indeed right that one may send with current encoding single path 
for a given net and the price of this would be the extra 4 octets per 
those nets.

If add-paths is enabled per net or per SAFI is on the border of 
implementation choice vs operation requirements of the network .. and I 
think the former is currently winning :)

Last if we acknowledge that add-paths may be useful to be enabled for 
some specific prefixes I think it would be worth to standardize in base 
add-paths encoding document an explicit way to enable such behaviour 
domain wide instead of counting for consistent explicit configuration on 
each bgp speaker. Set of defined standard communities each indicating 
the number of required paths per prefix it is attached to would be 
sufficient.

 > I'm not sure what you mean by this either.  There is no requirement
 > in the spec to enable it for any particular AFI/SAFI.

That was specific to the example provided.

Many thx,
R.

 > Robert,
>
> On Nov 23, 2010, at 8:48 AM, Robert Raszuk wrote: ...
>> another observation of current add-paths proposal .. it allows to
>> work on a per AFI/SAFI level only. If I have 1 million of IPv4
>> routes and 10-50 voice gateways prefixes I particularly care about
>> I do not have a way to continue sending my 1 million of IPv4 routes
>> (less the 50 voice gateways) the old MP_REACH way with single best
>> path only, with packing enabled and without path_id attached.
>
> I don't know what you mean by "with packing enabled"?  You are
> correct that if you enable add-paths for a given AFI/SAFI the path_id
> as to be attached for all routes of that AFI/SAFI; however, there
> isn't any requirement to send multiple paths for all routes.  If you
> didn't want to send multiple paths, you could certainly send the
> path_id as zero (or any other fixed value) and essentially ignore it
> in every other respect.
>
> I'm not sure what you mean by this either.  There is no requirement
> in the spec to enable it for any particular AFI/SAFI.
>
>> and what's worse with current implementations enabled uniformly ...
>> that means if I need to send all paths for my voice gateways it
>> will also result in distribution of all paths for the entire
>> address family.
> ...
>
> As you observe, this is an implementation choice and not fundamental
> to the protocol.  As I point out above, an implementation is free to
> pick and choose which prefixes it sends multiple paths for.  (This
> might be a topic to be mentioned in the add-paths-guidelines draft,
> though?)
>
> Regards,
>
> --John

---

From: "Shyam Sethuram (shsethur)" <[email-masked]>
Date: Wed, 24 Nov 2010 00:24:40 -0800

Hi Robert,
IMO the use of two different MP attributes to encode prefixes
belonging to the same afi/safi can lead to consistency issues.
Consider a prefix that currently is advertised using MP_REACH.
Suppose that prefix is now 'enabled' for add-paths. Would there
be an explicit MP_UNREACH followed by MP_ADD_PATHS_REACH ? And
vice-versa...

The only 'drawback' I see with the current scheme, as you also
noted, is the extra 4 bytes per NLRI if there's only
a bestpath to advertise.
Coming back to the original issue of mishandled capability
negotiation, that is akin to handling of 4byte AS capability
and AS_PATH. I'm not entirely sure we need to address a way
around implementation bugs for this particular case. But if
there's a dire need to do so using separate MP attribute types,
then we need to make the use of MP_REACH and MP_ADD_PATHS_REACH
mutually exclusive on a given session for a given afi/safi.

thanks--shyam

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
Robert Raszuk
>(raszuk)
>Sent: Tuesday, November 23, 2010 12:31 PM
>To: John Scudder
>Cc: Daniel Ginsburg; [email-masked]
>Subject: Re: [Idr] Robustness of NLRI encoding in
draft-ietf-idr-add-paths
>_______________________________________________
>Idr mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/idr