Subject: [Idr] RFC-compliant use of Extended Length for new BGP attributes

From: Marcelo Schmidt <[email-masked]>
Date: Thu, 13 Mar 2008 08:48:49 -0700

I  am  interested  in input from the list on loose behavior we've seen
from various BGP specs.  The specific example in question is a case we
are seeing in the wild where a NEW_AS_PATH attribute has 8 data bytes,
but  sets the Extended Length bit and uses a 2-byte length field.  RFC
1771 explicitly states "Extended Length may be used only if the length
of  the  attribute value  is  greater  than 255 octets."  However, the
superceding  RFC  4271 does not have this explicit language, therefore
would  imply that  either  of the following cases would technically be
compliant:

A.  Ext-Len is set (1), 2-byte length field is used, regardless of
length of attribute

B.    Ext-Len   is   clear  (0),  1-byte  length  field  is  uses,
and attribute is <= 255 bytes

Furthermore, I've      seen      loose      language,      such     as
draft-kumaki-pce-bgp-disco-attribute-00.txt  that  seems  to  imply to
always set Ext-Len bit regardless.

Specifically,   is  anyone  aware  of  any  new  BGP  extensions  that
would REQUIRE  Ext-Len  to  be set, even if attribute is <= 255 bytes?
Our  thought  is  that if we receive a case A above with length <= 255
bytes,  we  are  free to propogate to downstream neighbors as a case B
(generically, for any attribute in BGP)."

-- 
-m

====================================================================
Key fingerprint = 8E48 6CD0 6D2B 538E 264B  D1D0 21E2 E7EE A40F 2A0B
gpg --keyserver wwwkeys.pgp.net --recv-keys 0xA40F2A0B
====================================================================

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 13 Mar 2008 10:08:53 -0700

Hi Marcelo,

RFC4271 obsoletes RFC1771. In my view as the RFC4271 does not mention
the "Extended Length" restriction as defined below in RFC1771, the
restriction no longer applies to RFC4271.

"Extended Length may be used only if the length of the attribute value
is greater than 255 octets."

I agree clarification on the same would have been good though.

Thanks,
Vishwas

---

From: Marcelo Schmidt <[email-masked]>
Date: Thu, 13 Mar 2008 10:37:05 -0700

Hi Vishwas,

If the restriction defined in RFC1771 is not longer valid, that means we
can expect to receive an update with Extended Length bit set, but e.g. length 
of only 6?  This is one case where I see this needs a clarification: 

what should outgoing updates do when the Extended Length bit is set but
but length <= 255 oct?

Ignore it, accept updates with Extended Length even when <= 255 octets anyways?

This could cause a packet malformed if the implementaion uses RFC1771 where
Extended Length bit is being checked before sending the update.

-m

with length of 6 we only use a 1-byte (i.e. non-extended) length field

On Thu, Mar 13, 2008 at 10:08:53AM -0700, Vishwas Manral wrote:
>    >  [1]https://www.ietf.org/mailman/listinfo/idr
>    >
>    >
>    No virus found in this incoming message.
>    Checked by AVG.
>    Version:  7.5.518  /  Virus  Database:  269.21.7/1327  - Release Date:
>    3/12/2008 1:27 PM
> 
> References
> 
>    1. https://www.ietf.org/mailman/listinfo/idr

-- 
-m

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 13 Mar 2008 10:48:12 -0700

Hi Marcelo,

You are right. This does cause non-interoperability between RFC1771
and RFC4271 related implementations and could be clarified.

However my take is we should accept Extended length even if it is
lesser than 255. It would be an easier option to have the code under
some run time flag of RFC1771 compatible versus RFC4271 compatible.

Thanks,
Vishwas

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 13 Mar 2008 13:56:45 -0400

Marcelo,

> what should outgoing updates do when the Extended Length bit is set but

Expect the attribute length to be 2 octets and calculate the total path
attribute length accordingly.

> Ignore it, accept updates with Extended Length even when <= 255 octets anyways?

I'd certainly hope so.

> Extended Length bit is being checked before sending the update.

The packet is well formed.  As you say, by 1771 rules, it is
semantically incorrect.  The only implementation I would expect to do
anything about this would be the ones run by conformance validation tools.

One reason why implementors may wish to just use the extended length
value always is that it reduces the possible code paths for packet
construction.  Length errors when constructing TLVs are a class of bugs
that crop up all too often in networking.

Of course, even an implementation that always sent using the extended
length bit must be able to receive without it.

-- Jeff

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 13 Mar 2008 11:11:24 -0700

Hi Jeff,

>  anything about this would be the ones run by conformance validation tools.
I agree to all you say. However I would say all implementations
following RFC1771 strictly would break.

Thanks,
Vishwas

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 13 Mar 2008 11:21:11 -0700

Hi Jeffrey,

One correction to what you said.
>  that crop up all too often in networking.
In going with the principle of being conservative in what we send out
and liberal in what we accept, I would say an implementation should
not use Extended Length field if the length is lesser than 255 and an
Extended Length when it is more. While accepting ofcourse, we should
try to be more liberal there.

Thanks,
Vishwas

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 13 Mar 2008 14:47:49 -0400

> following RFC1771 strictly would break.

Implementations that strictly followed RFC 1771 wouldn't have
interoperated well with much of the Internet.  Consider the fact that
AS_PATH length is not one of the inputs to route selection.

Also keep in mind that RFC 2119 wouldn't be published for almost 2 more
years after 1771.

It's probably best to keep in mind that 1771 was known to have bugs -
enough bugs for 26 consequent drafts to fix them.  There are still bugs
in 4271 although their magnitude is probably significantly less on an
interoperability basis.  Conformance to the spec to the exclusion of
interoperating with other vendors may earn you friends with the test
tool manufacturers but it certainly won't make your customers happy.

-- Jeff

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Thu, 13 Mar 2008 12:06:56 -0700

>tool manufacturers but it certainly won't make your customers happy.

[SC>] Agree. Is there any interop event or any consortium that arranges for
RFC4271 or other BGP related interop event ?

Thanks,
-Samita

---

From: Paul Jakma <[email-masked]>
Date: Mon, 24 Mar 2008 10:18:03 +0000 (GMT)

On Thu, 13 Mar 2008, Marcelo Schmidt wrote:

> from various BGP specs.  The specific example in question is a case 
> we are seeing in the wild where a NEW_AS_PATH attribute has 8 data 
> bytes, but sets the Extended Length bit and uses a 2-byte length 
> field.

Post-AS4_ASPATH Quagga does this for AS_PATH and AS4_PATH.

> RFC 1771 explicitly states "Extended Length may be used only if the 
> length of the attribute value is greater than 255 octets."

> However, the superceding RFC 4271 does not have this explicit 
> language, therefore would imply that either of the following cases 
> would technically be compliant:

Right. Further, it'd be an extremely strange 1771 speaker that got 
confused by an extended length being less than 255. It'd have to go 
out of its way to enforce a fairly useless restriction.

> always set Ext-Len bit regardless.

That seems a good idea to me. Different length length fields is just 
asking for the odd boundary-case bug.

> Specifically, is anyone aware of any new BGP extensions that would 
> REQUIRE Ext-Len to be set, even if attribute is <= 255 bytes? Our 
> thought is that if we receive a case A above with length <= 255 

There doesn't seem to be any reason you can't do that.

Any drafts that try to add their own interpretation on how the 
attributes TLV is to be used are simply over-reaching and wrong on 
that matter, and should be stripped of such language. 1771 is the 
canon here really, and must be in order, e.g., for unknown transitive 
attributes to be able to propogate.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
No matter how subtle the wizard, a knife in the shoulder blades will seriously
cramp his style.
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr