Re: [Idr] WG Last Call on Extened Message Support

["Jakob Heitz (jheitz)" <[e-mail]>]

Sue,

Sorry if I'm a bit behind, but could you elaborate the problem with BGP-LS please. Can you give some examples of a BGP-LS NLRI and associated path attribute that will not fit 4096 bytes?

Thanks,
Jakob.


On Feb 11, 2019, at 11:18 PM, Susan Hares <[e-mail]<mailto:[e-mail]>> wrote:

Jakob:

Thanks for mentioning the correct information the BGPSec as far as the specifications.  Whether or not the RSA-2048 would have been useful to BGPSec, is left for the OPS group handling SIDR deployment.

The focus of this discussion is to remove any future obstacles to the use of BGP-LS attributes/NLRI.  Two potential limits exist:  a) message size (greater than 4096) and b) error handling.

Sue Hares

From: Idr [mailto:[e-mail]] On Behalf Of Jakob Heitz (jheitz)
Sent: Monday, February 4, 2019 3:14 PM
To: Dongjie (Jimmy); Susan Hares; 'Borchert, Oliver (Fed)'; [e-mail]<mailto:[e-mail]>; 'Borchert, Oliver (Fed)'
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] WG Last Call on Extened Message Support

BGPSec dropped the requirement for extended messages because the
signature was changed from RSA-2048 (256 byte sig) to ECDSA P-256 (64 byte sig).
https://mailarchive.ietf.org/arch/msg/sidr/LRHPuO5MF0u-vWuhNAVeVN_8fIU

There is no mention of extended messages in https://tools.ietf.org/html/rfc8205
All mention of it was struck out in:
https://tools.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-protocol-23.txt

Regards,
Jakob.

From: Idr <[e-mail]<mailto:[e-mail]>> On Behalf Of Dongjie (Jimmy)
Sent: Friday, February 1, 2019 10:45 PM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>; 'Borchert, Oliver (Fed)' <oliver.borchert=[e-mail]<mailto:oliver.borchert=[e-mail]>>; [e-mail]<mailto:[e-mail]>; 'Borchert, Oliver (Fed)' <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] WG Last Call on Extened Message Support

Hi Sue,

Thanks for updating the implementation report.

My understanding was that bullet 4 was to cover the behavior of section 5 paragraph 1, bullet 5 was to cover the behavior of section 5 paragraph 2.

But after rereading section 5, I realize that both paragraph 1 and 2 are talking about the behavior of a BGP speaker which does not advertise the extended message capability to its peer, so perhaps bullets 4 and 5 in the implementation report could be merged as below:

4. When receives an extended message without advertising the BGP Extended Message Capability to this peer (Error Handling).
4a. Accepts the extended message if the BGP speaker is able to process extended message (but was configured not to advertise the capability)   [Section 5, paragraph 1 MAY]
4b. Does not accept the extended message, follows RFC4271 handling and sends Bad Message Length Notification [Section 5, paragraph 1 SHOULD NOT, and paragraph 2 MUST)

Hope this helps to reduce the confusion.

Best regards,
Jie


From: Susan Hares [mailto:[e-mail]]
Sent: Friday, February 01, 2019 11:03 PM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; 'Borchert, Oliver (Fed)' <oliver.borchert=[e-mail]<mailto:oliver.borchert=[e-mail]>>; [e-mail]<mailto:[e-mail]>; 'Borchert, Oliver (Fed)' <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [Idr] WG Last Call on Extened Message Support

JIe, Bruno and Oliver:

Thank you for your input.   You are correct that the error handling behavior was unclear based on the questions in the chart.   The purpose of the chart is to provide other BGP WGs (Bess, SPRING, LSVR) a clear indication of changes to the base BGP specification.

I’ve reformatted sections 4 and 5 of the chart.

To section 4 I’ve added:
4c            Does send Extended Message  - with a yes from all implementations (based on their email)

Section 5, I’ve alter to be:
5              Error handing
5a           Accepts Extended message without receiving
             BGP Extended Message Capability [Section 5 paragraph 1 MAY]

5b           If receives Extended Message without BGP extended message support,
             follows RFC4271 handling and sends Bad message length Notification
            [section 5 paragraph 2 MUST]

Oliver – if you would read the current text and let me know the updated message.  I believe the answer for all 3 implementations is “yes” due to 4b.   Please let me know and I will update the information in the chart.

To follow-up on Jie’s comments, the text did not accurately represent the error handling.   Section 5, paragraph 1 has a “SHOULD NOT” modified by a “MAY”, which results in simply a “MAY”.   For readability, I think the “SHOULD NOT” provides useful information  to the implementer,  but it cannot be tested accurately when combined with the “MAY”.

Let me give you an example of that:
If the peer did not send a BGP Extended Message capability, and it accepts the extended message (with a length of 10,000 bytes), it could have a liberal policy of MAY as a default in the implementation.   The “on-wire” observations cannot tell – only the implementation’s policy (default + configured).

I also broke out the management information away from the specification information.

Sue Hares

From: Dongjie (Jimmy) [mailto:[e-mail]]
Sent: Wednesday, January 30, 2019 8:53 PM
To: Borchert, Oliver (Fed); Susan Hares; [e-mail]<mailto:[e-mail]>; Borchert, Oliver (Fed)
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [Idr] WG Last Call on Extened Message Support

Hi Oliver, Bruno and Sue,

To my understanding, bullet 5/5a/5b in the implementation report is corresponding to the second paragraph in section 5 “Error Handling”:

A BGP speaker that does not advertise the BGP Extended Messages
   capability might also genuinely not support Extended Messages.  Such
   a speaker MUST follow the error handling procedures of [RFC4271] if
   it receives an Extended Message.  Similarly, any speaker that treats
   an improper Extended Message as a fatal error, MUST treat it
   similarly.

Thus it is to describe the error handling behavior of an implementation version which does not support extended message.

While I agree this could be misleading for a report of implementation which supports extended message capability, maybe it could be used to verify the behavior of an old version which does not support this capability?

Best regards,
Jie

From: Idr [mailto:[e-mail]] On Behalf Of Borchert, Oliver (Fed)
Sent: Wednesday, January 30, 2019 4:35 AM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Borchert, Oliver (Fed) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] WG Last Call on Extened Message Support

Bruno and Susan,

I cannot speak for the ExaBGP Implementation but for BGPSEC-IO and QuaggaSRx.
I believe when I compiled the report, I mis-read 5a and overlooked the “not” and read instead: “Does send Extended Message Capability”.
Therefore the implementation report for section 5a must be corrected from “Yes” into “No” for both BGPSEC-IO and QuaggaSRx

BGPSEC-IO and QuaggaSRx, both do send the extended message capability if so configured.
I just checked the code and run it again. I copy/pasted the relevant output generated by BGPSEC-IO,

Oliver

-----  output of BGPSEC-IO  -------

./bgpsecio -f bgpsecio.test.cfg.qsrx
Starting bgpsecio 0.2.0.25...
Send:  (Open message send from BGPSEC-IO to QuaggaSRx)
OPEN Message
  +--marker: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
…
     +--Optional Parameter: Capability
     |  +--Type: Capability (2)
     |  +--Length: 2
     |  +--Capability: Extended message support capability
     |     +--Type: Extended message support capability (6)
     |     +--Length: 0
…

Received: (Open message send from QuaggaSRx and received by BGPSEC-IO)
OPEN Message
  +--marker: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
…
     +--Optional Parameter: Capability
        +--Type: Capability (2)
        +--Length: 2
        +--Capability: Extended message support capability
           +--Type: Extended message support capability (6)
           +--Length: 0
BGP-receiver thread created!



From: Idr <[e-mail]<mailto:[e-mail]>> on behalf of Susan Hares <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, January 29, 2019 at 11:43 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Idr] WG Last Call on Extened Message Support

Bruno:

Thank you for your comments on this topic – as I think

I did receive reports privately that we have 1 full implementations of draft-ietf-idr-bgp-extended-messages off list which is not listed in this report.   I hope those implementers will volunteer this information on the list.   If not, I will share this information with Alvaro and the IESG.

The SIDR work did define draft-ietf-bgp-extended-messages as a requirement and only moved to not specifying it when we could not quickly pass this through WG LC.

The real needs are a growing BGP-LS that may run out of BGP message space.  As my previous email to IDR indicates, I was hoping this handles an BGP message whose length is bigger than 4096 bytes.   Thank you for the correction of:

“The issue is not specific to attributes bigger than 4096 octets, but to BGP message whose length is bigger than 4096, irrespective of the size of each attribute.”


As to your comment:

“Why is this limited to future specifications? A priori, using existing BGP mechanism (AFI/SAFI, attributes, * communities) one could exceed the size of 4096 octets. How does the BGP speaker supposed to behave in this case? This should be described in this specification. Note that this is not a case of error handling, as every BGP speaker is behaving as specified.”

This problem has been true for years, and thus as co-chairs had hoped to have the draft-ietf-bgp-extended-messages passed years ago.   As BGP-LS attributes grow use and in number, the potential of exceeding the BGP message limit increases.  It seems like a good direction to prevent issues.

I hope the authors will comment on the changes you suggested to the text.

Cheers,
Susan Hares



From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]
Sent: Tuesday, January 29, 2019 8:33 AM
To: Susan Hares
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [Idr] WG Last Call on Extened Message Support

Hi WG,

Please find below some comments.
As of today, I don’t believe this specification is ready to be progressed to IESG/RFC, especially for a document updating RFC 4271 (core BGP spec).

> The WG chairs intend to forward this draft to the IESG with the current level of implementation.

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fidr%2Fwiki%2Fdraft-ietf-idr-bgp-extended-implementations&data=02%7C01%7Coliver.borchert%40nist.gov%7C40bb8a943e614b1637f308d68608d6cd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636843769859165043&sdata=hXBbOXqwvXqtCV%2B9PbP%2F7IE6WJjWUA2boM33Kds%2Bgh4%3D&reserved=0> says : 5a

Does not send Extended Message capability

Yes

Yes

Yes


I may be misunderstanding the implementation report, but my reading of the above is that none of the reported implementations sends the capability hence no implementation supports draft-ietf-idr-bgp-extended-messages.. Here this document is updating RFC 4271, so it is not a minor extension for a niche use case. So I don’t see the arguments for not requiring the IDR’s usual two interoperable implementations.

----
§ 1
“ As BGP is extended to support newer AFI/SAFIs and
   newer capabilities (e.g., [I-D.ietf-sidr-bgpsec-protocol<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-idr-bgp-extended-messages-27%23ref-I-D.ietf-sidr-bgpsec-protocol&data=02%7C01%7Coliver.borchert%40nist.gov%7C40bb8a943e614b1637f308d68608d6cd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636843769859165043&sdata=uZS%2BbN9v5cir2o5L3U3jP2xFPbY4Tz%2FNnBPfdH7iDf0%3D&reserved=0>]), there is
   a need to extend the maximum message size beyond 4096 octets.  “

https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-27#section-1<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-idr-bgp-extended-messages-27%23section-1&data=02%7C01%7Coliver.borchert%40nist.gov%7C40bb8a943e614b1637f308d68608d6cd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636843769859165043&sdata=YVWHAFbYRjG%2FlWPbpw2rW8uGQ6QXss3dufm%2FqHgRvDw%3D&reserved=0>


[I-D.ietf-sidr-bgpsec-protocol<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-idr-bgp-extended-messages-27%23ref-I-D.ietf-sidr-bgpsec-protocol&data=02%7C01%7Coliver.borchert%40nist.gov%7C40bb8a943e614b1637f308d68608d6cd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636843769859165043&sdata=uZS%2BbN9v5cir2o5L3U3jP2xFPbY4Tz%2FNnBPfdH7iDf0%3D&reserved=0> is now RFC 8205 (thanks for updating the reference). It has removed the normative/any reference to draft-ietf-idr-bgp-extended-messages. So presumably BGP Sec does not need draft-ietf-idr-bgp-extended-messages.
Can we have an update on this?
Can the introduction of draft-ietf-idr-bgp-extended-messages be updated to introduce on the real reasons/needs?

----
§4

§3 says “A peer which does not advertise this capability MUST NOT send BGP
   Extended Messages, and BGP Extended Messages MUST NOT be sent to it.”

Fine. Text in §4 should probably be aligned with the above ..e.g.

OLD: A BGP speaker
   MAY send Extended Messages to its peer only if it has received the
   Extended Message Capability from that peer.

NEW:
A BGP speaker
   MAY send Extended Messages to its peer only if it has sent and received the
   Extended Message Capability to and from that peer.

----

“   Applications generating information which might be encapsulated
   within BGP messages MUST limit the size of their payload to take the
   maximum message size into account.”

I don’t see what new behavior is been defined here. If there is none, I would suggest to remove this sentence

----
   A BGP announcement will, in the normal case, propagate throughout the
   BGP speaking Internet; and there will undoubtedly be BGP speakers
   which do not have the Extended Message capability.  Therefore,
   putting an attribute which can not be decomposed to 4096 octets or
   less in an Extended Message is a likely path to routing failure.


The issue is not specific to attributes bigger than 4096 octets, but to BGP message whose length is bigger than 4096, irrespective of the size of each attribute.
Please elaborate on what you mean by “an attribute which can not be decomposed to 4096 octets”

---
“   It is RECOMMENDED that BGP protocol developers and implementers are
   conservative in their application and use of Extended Messages.”

What does this mean exactly? That they don’t use this extension? That they don’t use this extension unless XX_TO BE SPECIFIED_XX?

---
  Future protocol specifications will need to describe how to handle
   peers which can only accommodate 4096 octet messages.

Why is this limited to future specifications? A priori, using existing BGP mechanism (AFI/SAFI, attributes, * communities) one could exceed the size of 4096 octets. How does the BGP speaker supposed to behave in this case? This should be described in this specification. Note that this is not a case of error handling, as every BGP speaker is behaving as specified.


----
Depending on the above specification, a section describing the operational consequences in a network (such as the Internet, BGP Enabled ServiceS/VPN networks) is probably needed. Possible consequences could be BGP NLRI being removed in the middle of such network, or (extended) community (such as Route Targets) been removed. Both having significant consequences on the availability provided by the network.

---
§4
OLD: The Extended Message Capability only applies to all messages except for the OPEN message.
Probably
NEW: The Extended Message Capability applies to all message types except for the OPEN message (type 1).
----
§8

“This extension to BGP does not change BGP's underlying security issues »

Before evaluating this, I think this document should first specified how a BGP messages bigger than 4096 octets is handled when it needs to be sent to a received not supporting this extension.

Nits:
OLD : to reduce compexity
NEW : to reduce complexity

Thanks,
--Bruno

From: Idr [mailto:[e-mail]] On Behalf Of Susan Hares
Sent: Tuesday, January 29, 2019 12:33 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [Idr] WG Last Call on Extened Message Support


This begins a 2 week WG LC on Extended Message Support for BGP (draft-ietf-idr-bgp-extended-messages-27).  You can access the draft at:

https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-idr-bgp-extended-messages%2F&data=02%7C01%7Coliver.borchert%40nist.gov%7C40bb8a943e614b1637f308d68608d6cd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636843769859321289&sdata=okjTeLe6DcTaRV2USy2My6HXDRynupmXlB0i7gUwynA%3D&reserved=0>

The authors should indicate whether they know of any IPR.   Implementers are encouraged to update the  implementation data at:

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fidr%2Fwiki%2Fdraft-ietf-idr-bgp-extended-implementations&data=02%7C01%7Coliver.borchert%40nist.gov%7C40bb8a943e614b1637f308d68608d6cd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636843769859321289&sdata=PoRyFofs04%2FC%2F%2FgbXL2zyED3SW6MrESpHiIE2e7p4cA%3D&reserved=0>

The draft provides a means for expanding the BGP message to 65535 octets for all messages except OPEN messages.  BGP message space is running short for all of the potential attributes or additions proposed by BGP-LS features.

The WG chairs intend to forward this draft to the IESG with the current level of implementation.

As you comment on the draft, please consider if: a) the technology is mature, b) the additional space in a BGP message would be helpful for those deploying BGP-LS or SR, and c) if the specification is ready for publication.

Sue Hares (WG Chair, Shepherd)



_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.