From nobody Mon May 30 03:59:15 2016 Return-Path: X-Original-To: sigtran@ietfa.amsl.com Delivered-To: sigtran@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C868512D5B0 for ; Mon, 30 May 2016 03:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sg7zUXNXBgX for ; Mon, 30 May 2016 03:59:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B220812D59F for ; Mon, 30 May 2016 03:59:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CPV56262; Mon, 30 May 2016 10:59:08 +0000 (GMT) Received: from SZXEML428-HUB.china.huawei.com (10.82.67.183) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 30 May 2016 11:59:07 +0100 Received: from SZXEML512-MBS.china.huawei.com ([169.254.8.230]) by szxeml428-hub.china.huawei.com ([10.82.67.183]) with mapi id 14.03.0235.001; Mon, 30 May 2016 18:58:57 +0800 From: Nagesh shamnur To: "sigtran@ietf.org" Thread-Topic: Query regarding Interface Identifier parameter as per the RFC 4233/3057 Thread-Index: AdG6Yj8LY6dJlZmrRm2Fsf0R9kYAuQ== Date: Mon, 30 May 2016 10:58:56 +0000 Message-ID: <4AC96705FB868F42B2075BA50F806DEB55CE2179@szxeml512-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.209.60] Content-Type: multipart/alternative; boundary="_000_4AC96705FB868F42B2075BA50F806DEB55CE2179szxeml512mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.574C1CFC.02C0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.230, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 972e4c04b0b7f659c3a79abdd4580fe1 Archived-At: Cc: Javed siddiqui Subject: [Sigtran] Query regarding Interface Identifier parameter as per the RFC 4233/3057 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 10:59:14 -0000 --_000_4AC96705FB868F42B2075BA50F806DEB55CE2179szxeml512mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Group, As per as part of adhering to RFC 4233/ RFC 3057 regarding = Interface identifier, we have met a situation where I thought it would be a= pt to query the correct way in the group. The protocol definition for "Inte= rface Identify " as per the RFC is mentioned as integer range with value fr= om 0 UINT_MAX. While processing the ASPAC message, if the Interface identif= ier Start is given as 0 and Interface identifier End is given as UINT_MAX(2= %32), then it can result in a big loop in the code which can spike the CPU.= Is there any recommendations from the protocol side to avoid such a probl= em? 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xb) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Mode Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x1=3Dinteger) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifiers* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x8=3Dinteger range) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier Start1* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier Stop1* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier Start2* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier Stop2* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Regards, Nagesh. --_000_4AC96705FB868F42B2075BA50F806DEB55CE2179szxeml512mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Group,

        &nbs= p;       As per as part of adhering to RFC 4233/ RFC 3057 regarding Interface identi= fier, we have met a situation where I thought it would be apt to query the = correct way in the group. The protocol definition for "Interface = Identify " as per the RFC is mentioned as integer range with value from 0 UINT_MAX. While processing the ASPAC messa= ge, if the Interface identifier Start is given as 0 and Interface identifie= r End is given as UINT_MAX(2%32), then it can result in a big loop in the c= ode which can spike the CPU.  Is there any recommendations from the protocol side to avoid such a problem?<= o:p>

 

0       &nb= sp;           1 &nbs= p;            &= nbsp;    2        &n= bsp;          3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3= 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+

   |     &n= bsp;     Tag (0xb)      &= nbsp;    |        &n= bsp;    Length       &nbs= p;    |

   +-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+

   |     &n= bsp;            = ;   Traffic Mode Type       &n= bsp;            = ;     |

   +-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+

   |     Tag (0x= 1=3Dinteger)         |  &= nbsp;         Length  &nb= sp;          |

   +-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+

 

   |     &n= bsp;            = ;   Interface Identifiers*      &nb= sp;            = |

 

   +-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+

   |    Tag (0x8=3Din= teger range)    |       &= nbsp;    Length       &nb= sp;     |

   +-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+

   |     &n= bsp;           Interface = Identifier Start1*         &nb= sp;        |

   +-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+

   |     &n= bsp;            Inte= rface Identifier Stop1*        &nbs= p;         |

   +-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+

   |     &n= bsp;           Interface = Identifier Start2*         &nb= sp;        |

   +-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+

   |     &n= bsp;            Inte= rface Identifier Stop2*        &nbs= p;         |

   +-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+

 

Re= gards,

Na= gesh.

 

--_000_4AC96705FB868F42B2075BA50F806DEB55CE2179szxeml512mbschi_--