Subject: [dtn] BPbis rules for future extension blocks

From: Magnus Westerlund <[email-masked]>
Date: Fri, 20 Nov 2020 14:55:41 +0000

Hi WG,

So in the discussion of BPv7 Extension in todays meeting some people did draw
some parallels to IPv6 Extension headers. Ben Kaduk reminded me that there is
one important aspect of that discussion that can hint at an issue. If you are
following 6man and/or Spring WG you would know about the big discussion related
to addition and removal of some IPv6 extension headers by anything other than
the endpoints that IPv6 Segment routing proposal has caused.

So the existing Extension headers are all being changed interally and at least
"received from" will be added by a forwarder which isn't the originating
endpoint.  So the question to the WG and especially the authors. Is it really
clear that Extension bundle blocks MAY be added by any node? Which nodes MAY
remove a Extension bundle block? What controls if a Extension Bundle Block can
be removed by an intermediate node. I do note taht the Block Processing Control
Flags do not have a flag for "MUST NOT be removed, even if not understood". 

I would encourage the WG to think if there need to be any clarification of this
now. If we are missing a control flag I think it is easier to add it now. Also
to clarify what the general rules are for Extension Blocks so that this
discussion don't show up a bit down the line here. 

Cheers

Magnus

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Fri, 20 Nov 2020 16:00:52 +0000

Thanks, Magnus.  As a starting point for this discussion, here is the text that I would propose to use in place of the current first paragraph of section 4.3:

<start>
"Extension blocks" are all blocks other than the primary and payload blocks. Three types of extension blocks are defined below.  All implementations of the Bundle Protocol specification (the present document) MUST include procedures for recognizing, parsing, and acting on, but not necessarily producing, these types of extension blocks.

The specifications for additional types of extension blocks must indicate whether or not BP implementations conforming to those specifications must recognize, parse, act on, and/or produce block of those types.  As not all nodes will necessarily instantiate BP implementations that conform to those additional specifications, it is possible for a node to receive a bundle that includes extension blocks that the node cannot process. The values of the block processing control flags indicate the action to be taken by the bundle protocol agent when this is the case.

No mandated procedure in this specification is unconditionally dependent on the absence or presence of any extension block.  Therefore any bundle protocol agent MAY insert or remove any extension block in any bundle, subject to all mandates in the Bundle Protocol specification and all extension block specifications to which the node's BP implementation conforms.  Note that removal of an extension block will probably disable one or more elements of bundle processing that were intended by the BPA that inserted that block.  In particular, note that removal of an extension block that is one of the targets of a BPsec security block may render the bundle unverifiable.  
<end>

Scott

-----Original Message-----
From: dtn <[email-masked]> On Behalf Of Magnus Westerlund
Sent: Friday, November 20, 2020 6:56 AM
To: [email-masked]
Subject: [EXTERNAL] [dtn] BPbis rules for future extension blocks

Hi WG,

So in the discussion of BPv7 Extension in todays meeting some people did draw some parallels to IPv6 Extension headers. Ben Kaduk reminded me that there is one important aspect of that discussion that can hint at an issue. If you are following 6man and/or Spring WG you would know about the big discussion related to addition and removal of some IPv6 extension headers by anything other than the endpoints that IPv6 Segment routing proposal has caused.

So the existing Extension headers are all being changed interally and at least "received from" will be added by a forwarder which isn't the originating endpoint.  So the question to the WG and especially the authors. Is it really clear that Extension bundle blocks MAY be added by any node? Which nodes MAY remove a Extension bundle block? What controls if a Extension Bundle Block can be removed by an intermediate node. I do note taht the Block Processing Control Flags do not have a flag for "MUST NOT be removed, even if not understood". 

I would encourage the WG to think if there need to be any clarification of this now. If we are missing a control flag I think it is easier to add it now. Also to clarify what the general rules are for Extension Blocks so that this discussion don't show up a bit down the line here. 

Cheers

Magnus

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 23 Nov 2020 15:10:06 +0000

Hi,

Scott, thanks for the text proposal. I am still thinking that the last 
paragraph of your proposals do raise the question if there is need to define a 
"MUST NOT be removed" flag for the block control flags. WG please think this 
over. I understand that there might not be any intermediate usage of this 
flag, but adding it later might be far from trivial.

Cheers

Magnus

> From: Burleigh, Scott C (US 312B)
> <scott.c.burleigh=[email-masked]>
> Sent: den 20 november 2020 17:01
> To: Magnus Westerlund <[email-masked]>; [email-masked]
> Subject: RE: BPbis rules for future extension blocks
>
> Thanks, Magnus.  As a starting point for this discussion, here is the text 
> that I
> would propose to use in place of the current first paragraph of section 4.3:
>
> <start>
> "Extension blocks" are all blocks other than the primary and payload blocks.
> Three types of extension blocks are defined below.  All implementations of
> the Bundle Protocol specification (the present document) MUST include
> procedures for recognizing, parsing, and acting on, but not necessarily
> producing, these types of extension blocks.
>
> The specifications for additional types of extension blocks must indicate
> whether or not BP implementations conforming to those specifications must
> recognize, parse, act on, and/or produce block of those types.  As not all
> nodes will necessarily instantiate BP implementations that conform to those
> additional specifications, it is possible for a node to receive a bundle 
> that
> includes extension blocks that the node cannot process. The values of the
> block processing control flags indicate the action to be taken by the bundle
> protocol agent when this is the case.
>
> No mandated procedure in this specification is unconditionally dependent on
> the absence or presence of any extension block.  Therefore any bundle
> protocol agent MAY insert or remove any extension block in any bundle,
> subject to all mandates in the Bundle Protocol specification and all 
> extension
> block specifications to which the node's BP implementation conforms.  Note
> that removal of an extension block will probably disable one or more
> elements of bundle processing that were intended by the BPA that inserted
> that block.  In particular, note that removal of an extension block that is 
> one
> of the targets of a BPsec security block may render the bundle unverifiable.
> <end>
>
> Scott
>
> So in the discussion of BPv7 Extension in todays meeting some people did
> draw some parallels to IPv6 Extension headers. Ben Kaduk reminded me that
> there is one important aspect of that discussion that can hint at an issue. 
> If
> you are following 6man and/or Spring WG you would know about the big
> discussion related to addition and removal of some IPv6 extension headers
> by anything other than the endpoints that IPv6 Segment routing proposal has
> caused.
>
> clear that Extension bundle blocks MAY be added by any node? Which nodes
> MAY remove a Extension bundle block? What controls if a Extension Bundle
> Block can be removed by an intermediate node. I do note taht the Block
> Processing Control Flags do not have a flag for "MUST NOT be removed, even
> if not understood".
>
> now. If we are missing a control flag I think it is easier to add it now. 
> Also to
> clarify what the general rules are for Extension Blocks so that this 
> discussion