Subject: [ipcdn] Re: Max Length of X509Certificate in BPI+ MIB

From: Sudhir Pendse <[email-masked]>
Date: Fri, 30 Mar 2001 23:14:39 +0000

Dave,

I believe the historical reason for the < 1500 byte 
limit in SNMP comes from the argument that when the
network is very congested, you still want SNMP packets
to go through.  If the SNMP packets are large and they
become fragmented and put in multiple ethernet frames,
then the chances of them going through are lesser than 
if the entire SNMP packet fit into one ethernet frame.

Infact in the SNMPv1 spec (RFC1157) the minimum mandatory
message length to be supported is 484.

   (RFC1157)
   ...

   4.  Protocol Specification

   .....
   ..................  An implementation of this protocol need not
   accept messages whose length exceeds 484 octets.  However, it is
   recommended that implementations support larger datagrams whenever
   feasible.

A similar logic is reflected in the SNMPv2 (RFC1905) specs...

   (RFC 1905)
   .....

   2.5.  Message Sizes

   The maximum size of a SNMPv2 message is limited to the minimum of:

   (1)  the maximum message size which the destination SNMPv2 entity can
        accept; and,

   (2)  the maximum message size which the source SNMPv2 entity can
        generate.

   The former may be known on a per-recipient basis; and in the absence
   of such knowledge, is indicated by transport domain used when sending
   the message.  The latter is imposed by implementation-specific local
   constraints.

   Each transport mapping for the SNMPv2 indicates the minimum message
   size which a SNMPv2 implementation must be able to produce or
   consume.  Although implementations are encouraged to support larger
   values whenever possible, a conformant implementation must never
   generate messages larger than allowed by the receiving SNMPv2 entity.

   One of the aims of the GetBulkRequest-PDU, specified in this
   protocol, is to minimize the number of protocol exchanges required to
   retrieve a large amount of management information.  As such, this PDU
   type allows a SNMPv2 entity acting in a manager role to request that
   the response be as large as possible given the constraints on message
   sizes.  These constraints include the limits on the size of messages
   which the SNMPv2 entity acting in an agent role can generate, and the
   SNMPv2 entity acting in a manager role can receive.

   However, it is possible that such maximum sized messages may be
   larger than the Path MTU of the path across the network traversed by
   the messages.  In this situation, such messages are subject to
   fragmentation.  Fragmentation is generally considered to be harmful
   [4], since among other problems, it leads to a decrease in the
   reliability of the transfer of the messages.  Thus, a SNMPv2 entity
   which sends a GetBulkRequest-PDU must take care to set its parameters
   accordingly, so as to reduce the risk of fragmentation.  In
   particular, under conditions of network stress, only small values
   should be used for max-repetitions.

   2.6.  Transport Mappings

   It is important to note that the exchange of SNMPv2 messages requires
   only an unreliable datagram service, with every message being
   entirely and independently contained in a single transport datagram.
   Specific transport mappings and encoding rules are specified
   elsewhere [5].  However, the preferred mapping is the use of the User
   Datagram Protocol [6].

The transport mapping document (RFC 1906) has this to say about SNMP 
over UDP...

   (RFC 1906)

   3.  SNMPv2 over UDP

   ......

   When an SNMPv2 entity uses this transport mapping, it must be capable
   of accepting messages that are at least 484 octets in size.
   Implementation of larger values is encouraged whenever possible.

In SNMPv3 to make things easier, the SNMPv3 header itself has the
msgMaxSize which gives an indication of how large a response the
requester can handle...

   (RFC 2572)

   6.3.  msgMaxSize

   The msgMaxSize field of the message conveys the maximum message size
   supported by the sender of the message, i.e., the maximum message
   size that the sender can accept when another SNMP engine sends an
   SNMP message (be it a response or any other message) to the sender of
   this message on the transport in use for this message.

   When an SNMP message is being generated, the msgMaxSize is provided
   by the SNMP engine which generates the message.  At the receiving
   SNMP engine, the msgMaxSize is used to determine the maximum message
   size the sender can accommodate.

As you can see from above, the message size is a function of what each
entity can accept.  To be compliant with the protocol each side at the
bare minimum only needs to support 484 byte messages (if using UDP
transport).

Now in reality, most applications support more than 484 byte messages.
What that number is, grows with the overall industry requirements or
general consensus.  Up until now, it used to be around 1500.  With the 
increase in reliability of networks and need to make the data transfer 
more efficient, the 1500 number will slowly grow also.  

SimpleSoft's tools will be changed to support the new consensus. It
is probably just ignoring the larger size responses today, although
I doubt if it crashes.

But management entities supporting a smaller MTU than 1500 can hardly be
deemed "broken".  In a heterogenous world, to ensure interoperability,
one has to atleast consider being able to exchange information with
others how might be "buffer size challenged".

Kind Regards,
-sudhir

"White, David" wrote:
> 
> Kaz,
>         I believe the motivation for trimming the size of X.509 certs
> is so that SNMP response PDUs do not cause certain SNMP agent tester
> tools to crash. I believe the root of the problem lies neither in the
> DOCSIS spec., nor in SNMP, nor in any other standard. The problem is
> that the SNMP agent tester tools and/or managers have assumed the
> maximum sized SNMP GetResponse will be 1500 bytes, not including the
> MAC header.
>         Cadant has asked SimpleSoft to fix this exact bug. I'm assuming
> that fixing the UCD bug would involve going into the source code
> (which is freely available) and upping their receive buffer size to
> something more appropriate of dynamically allocating a buffer based
> upon the number of bytes received from the UDP layer.
>         UDP has a maximum size of 64k, so 1487 is no problem for UDP.
> Ethernet (not to be confused with 802.3) has an MTU of 1500 bytes.
> IEEE 802.2/802.3 CSMA/CD has an MTU of 1492. The smallest and
> most common IPv4 header is 20 bytes. UDP has a header of 8 bytes.
> 
>                   sizeof(Ethernet MTU)
>         - sizeof(smallest IPv4 header)
>         -           sizeof(UDP header)
>     ----------------------------------
>  = max_sizeof(proposed new X.509 cert)
> 
>                                  1500
>                                  - 20
>                                  -  8
>                                  ----
>                                = 1472
> 
> However, this does not even include the SNMP header, whether it be
> v1, v2c, or v3. So, 1472 still won't work.
>         If DOCSIS must bend over backwards to work around known bugs in
> SNMP agent tester tools and/or managers, then I propose we decrease the
> size of X.509 certs to 800 bytes, even though it still won't solve the
> problem in all cases. A single GetBulk of just 2 X.509 certs of 800 bytes
> each would still be around 1700 bytes, which would still cause certain
> tools and/or managers to crash.
> 
> David White
> [email-masked]
> 
> -----Original Message-----
> From: Kaz Ozawa [mailto:[email-masked]]
> Sent: Friday, March 30, 2001 9:07 AM
> To: IETF Ipcdn; DOCSIS OSS Mailing List; DOCSIS Security Mailing List
> Cc: Steve Malenfant; 'Loukianov, Dmitrii'
> Subject: RE: Max Length of X509Certificate in BPI+ MIB
> 
> I would like to hear more feedback to make sure the following points.
> (1) 1487 octets, the current maximum length of X509Certificate in
> BPI+ MIB cannot fit in the single UDP packet.
> (2) If we change the maximum length from 1487 octets to 1472 octets,
> it fits in the single UDP packet.
> (3) If the long MIB data is spited into two UDP packets, CMTS/CM
> vendors need to implement extra protocol to handle the special case
> in which the order of two UDP packets is switched or one of them is
> missed. (Dmitrii's point)
> (4) The new maximum length 1472 octets is enough for DOCSIS Certificates.
> If all of the above points are correct, we should change the maximum
> length to 1472 octets.
> I will very much appreciate your review and feedback.
> 
> Thanks,
> kaz
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of
> > Steve Malenfant
> > Sent: Monday, March 26, 2001 11:06 AM
> > To: 'Loukianov, Dmitrii'; 'Kaz Ozawa'; IETF Ipcdn; DOCSIS OSS Mailing
> > List; DOCSIS Security Mailing List
> > Subject: [ipcdn] RE: Max Length of X509Certificate in BPI+ MIB
> >
> >
> > The current Test Docsis Root CA that we have signed with 2048 bits doesn't
> > go up to 1000 bytes...  So other certificates shouldn't be
> > bigger, except if
> > you fill out your organization name with 200 caracters...
> >
> > It will also depends on the MTU size of the CM...
> >
> > Steve
> > Com21
> >
> > -----Original Message-----
> > From: Loukianov, Dmitrii [mailto:[email-masked]]
> > Sent: Monday, March 26, 2001 10:24 AM
> > To: 'Kaz Ozawa'; IETF Ipcdn; DOCSIS OSS Mailing List; DOCSIS Security
> > Mailing List
> > Subject: RE: Max Length of X509Certificate in BPI+ MIB
> >
> >
> > Ooops! SNMP works on top of UDP protocol, which does not
> > guarantee that the
> > packets
> > will arrive in the order sent. Having the packet split in two will require
> > modification of the SNMP protocol internals, including out-of-order packet
> > delivery.
> >
> > Therefore it is necessary to reduce the maximum size to fit into
> > one single PDU, or split certificate into two independent MIBs
> > (not a great
> > idea).
> >
> > Dmitrii Loukianov,
> > Intel.
> >
> > -----Original Message-----
> > From: Kaz Ozawa [mailto:[email-masked]]
> > Sent: Saturday, March 24, 2001 7:55 PM
> > To: IETF Ipcdn; DOCSIS OSS Mailing List; DOCSIS Security Mailing List
> > Subject: Max Length of X509Certificate in BPI+ MIB
> >
> >
> > The BPI+ MIB draft-ietf-ipcdn-bpiplus-mib-03.txt specifies as follows.
> >
> > > -- Textual conventions
> > >
> > > X509Certificate ::= TEXTUAL-CONVENTION
> > >      STATUS    current
> > >      DESCRIPTION
> > >          "An X509 digital certificate encoded as an ASN.1 DER
> > >      object."
> > >      SYNTAX    OCTET STRING (SIZE (0..1487))
> >
> > 1487 octets is the maximum length of the DER encoded digital
> > certificate which fits the Auth Request message and Auth Reply
> > message.
> >
> > Recently, we realized that there are very few SNMP tools which
> > (stably) supports this maximum length. Most of the BPI+ MIB
> > objects with this X509Certificate syntax are very important for
> > both testing and operation. Therefore, we need to request the
> > SNMP tool suppliers to support this long string.
> >
> > By the way, I heard that the MIB command with 1473 octets or
> > longer string does not fit the single PDU and will be divided
> > into two PDU. Therefore, changing the maximum length from 1487
> > octets to 1472 octets could help the SNMP tool suppliers to
> > support the maximum length earlier. I would like to hear any
> > opinion on the possibility of this change.
> >
> > Thanks,
> > kaz
> >
> > Kaz Ozawa
> > Toshiba Visiting Engineer at CableLabs
> > (303) 661-3860 (direct); -9199 (fax)
> > [email-masked] / [email-masked]
> >

-- 
Sudhir Pendse                   Tel:   (650) 965-4515
SIMPLESOFT Inc.                 Fax:   (650) 965-4505
http://www.smplsft.com          Email: [email-masked]

_______________________________________________
IPCDN mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/ipcdn