From nobody Mon Jun 6 01:27:03 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 1279D12D0A0 for ; Mon, 6 Jun 2016 01:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.055 X-Spam-Level: X-Spam-Status: No, score=-0.055 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=no 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 rKL8C6PkbhVJ for ; Mon, 6 Jun 2016 01:26:59 -0700 (PDT) Received: from smtp-out4.electric.net (smtp-out4.electric.net [192.162.216.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AFD712B02E for ; Mon, 6 Jun 2016 01:26:59 -0700 (PDT) Received: from 1b9ps8-0001ZB-Ue by out4d.electric.net with emc1-ok (Exim 4.87) (envelope-from ) id 1b9ps9-0001d5-Ua for sigtran@ietf.org; Mon, 06 Jun 2016 01:26:57 -0700 Received: by emcmailer; Mon, 06 Jun 2016 01:26:57 -0700 Received: from [213.249.233.130] (helo=AcuExch.aculab.com) by out4d.electric.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1b9ps8-0001ZB-Ue; Mon, 06 Jun 2016 01:26:56 -0700 Received: from ACUEXCH.Aculab.com ([::1]) by AcuExch.aculab.com ([::1]) with mapi id 14.03.0123.003; Mon, 6 Jun 2016 09:24:56 +0100 From: David Laight To: 'Nagesh shamnur' , "sigtran@ietf.org" Thread-Topic: Query regarding Interface Identifier parameter as per the RFC 4233/3057 Thread-Index: AdG6Yj8LY6dJlZmrRm2Fsf0R9kYAuQFapzUw Date: Mon, 6 Jun 2016 08:24:56 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6D5F4CFB3F@AcuExch.aculab.com> References: <4AC96705FB868F42B2075BA50F806DEB55CE2179@szxeml512-mbs.china.huawei.com> In-Reply-To: <4AC96705FB868F42B2075BA50F806DEB55CE2179@szxeml512-mbs.china.huawei.com> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] X-Outbound-IP: 213.249.233.130 X-Env-From: David.Laight@ACULAB.COM X-PolicySMART: 3396946, 3397078 MIME-Version: 1.0 Content-Language: en-US Content-Type: multipart/alternative; boundary=_000_063D6719AE5E284EB5DD2968C1650D6D5F4CFB3FAcuExchaculabco_ Archived-At: Cc: Javed siddiqui Subject: Re: [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, 06 Jun 2016 08:27:01 -0000 --_000_063D6719AE5E284EB5DD2968C1650D6D5F4CFB3FAcuExchaculabco_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Scan through the assigned numbers. From: Sigtran [mailto:sigtran-bounces@ietf.org] On Behalf Of Nagesh shamnur Sent: 30 May 2016 11:59 To: sigtran@ietf.org Cc: Javed siddiqui Subject: [Sigtran] Query regarding Interface Identifier parameter as per th= e RFC 4233/3057 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_063D6719AE5E284EB5DD2968C1650D6D5F4CFB3FAcuExchaculabco_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Scan through the assig= ned numbers.

 

From: Sigtran [mailto:sigtran-bounces@ietf.org] On Behalf Of Nagesh shamnur
Sent: 30 May 2016 11:59
To: sigtran@ietf.org
Cc: Javed siddiqui
Subject: [Sigtran] Query regarding Interface Identifier parameter as= per the RFC 4233/3057

 

Hi Group,

     &= nbsp;          As per as part of adhering to RFC 4233/ RFC 3= 057 regarding Interface identifier, 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 RF= C is mentioned as integer range with value from 0 UINT_MAX. While processin= g the ASPAC message, if the Interface identifier 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.&nb= sp; Is there any recommendations from the protocol side to avoid such a pro= blem?

 

0     =             &nb= sp; 1           &nbs= p;       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

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

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

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

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

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

   |   = ;  Tag (0x1=3Dinteger)        = |            Length=              |<= o:p>

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

 

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

 

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

   |   = ; Tag (0x8=3Dinteger range)    |    &nbs= p;       Length     =         |

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

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

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

   |   = ;            &n= bsp;  Interface Identifier Stop1*      &= nbsp;           |

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

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

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

   |   = ;            &n= bsp;  Interface Identifier Stop2*      &= nbsp;           |

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

 

Regards,<= /o:p>

Nagesh.=

 

Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, M= K1 1PT, UK
Registration No: 1397386 (Wales)

P = Please consider the environment and don't print this e-mail = unless you really need to

--_000_063D6719AE5E284EB5DD2968C1650D6D5F4CFB3FAcuExchaculabco_--