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

From: "Kaz Ozawa" <[email-masked]>
Date: Sat, 24 Mar 2001 19:54:47 -0700

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]

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

---

From: "Loukianov, Dmitrii" <[email-masked]>
Date: Mon, 26 Mar 2001 09:23:36 -0800

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

Thanks,
kaz

Kaz Ozawa

---

From: Steve Malenfant <[email-masked]>
Date: Fri, 30 Mar 2001 08:00:17 -0800

Kaz, SNMP should be able to accept this 1487 without any problem.  Packet
will be fragmented yes.  Packet can be lost, yes...

What happen if you try to set this mibs from a dial-up connection which has
a lower MTU?

If the certificate is sent in the wrong fragmented order, it will be
discarded anyway...

Tools seems to be the problem here, not able to set more than xxx bytes,
they crash.

Steve

-----Original Message-----
From: Kaz Ozawa [mailto:[email-masked]]
Sent: Friday, March 30, 2001 8: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

> 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
>
> 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
>
>

---

From: "White, David" <[email-masked]>
Date: Fri, 30 Mar 2001 10:48:27 -0600

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

Thanks,
kaz