IETF Logo Mail Archive

Re: [OSPF] [OSPFv3- Extended LSAs] Regarding Extended TLV validation procedure for malformed LSAs

Acee Lindem <acee.lindem@gmail.com> Mon, 03 April 2017 19:26 UTC

Return-Path: <acee.lindem@gmail.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5061294C7; Mon, 3 Apr 2017 12:26:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 nT9kllefs6wx; Mon, 3 Apr 2017 12:26:04 -0700 (PDT)
Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F311294C3; Mon, 3 Apr 2017 12:26:01 -0700 (PDT)
Received: by mail-qk0-x244.google.com with SMTP id p22so20820819qka.0; Mon, 03 Apr 2017 12:26:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=EVwIZNl0Xz6lhB/7cwDxoWwELEfp0oPLpQou8/78qYU=; b=jAIhBNnoI+1Uz7db3929qKUz5fPliHrNHREhkcAyId5eCa4yGaus89XiRYYzBxu42I rZnmwxZoT20JxmKhZb2HkKY0zSzDqwlH2nGGgiYOqHif3qtZYNWgS3m/3fnJjSjsi+IW BF9SllcxX+NFBsREKzM20/gjsKhVK3CV4O6S2m7EFBgSxczi7uCzK/0gGMoNOv0wr33N 0gCVwZ4gOcsTLAH52UHqNtod+ZLhRRhs/Y3U138QstLCaWXSL80qGc2astxl9Q2xNd6+ L4GXYlNLHviYcKzpwAWUpne7anFpWLxjtoPno6+syPpRFQFMxZ/9cGF/v1HQzYoyQ9cR 4qeA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=EVwIZNl0Xz6lhB/7cwDxoWwELEfp0oPLpQou8/78qYU=; b=LHW3n7UaA77P7osMv5G9JUxuqjsFvfcSw/lG4Si3w2qzsxW+VqtFtrGw+nUSMwgn4E iTkqbnE9YPyBDqOpIkbmp5nJ1coMhN637pk9m/nY0P39jyIOvwbsliTNbJ2qgnshs0zZ JIm56lKwGHe76MQCr9sdMQA5OCucVCAugBlZP6CwCdiZIzQAT3PSsO/LXAHlN/q8dp+0 gp/86ZFjTk5Z58U0XZNBJRJiNGXXL8UQVvCuACA+kZVEPIcO/Gu4UU5SgNvgvSJdQ5Ub 8lnWbOrq9o7jNgIq84IwWDYQQnCMTMBYb7gUXD/vLccKKaXryTDSBKiSXlHc5Xf3CTUM rH4g==
X-Gm-Message-State: AFeK/H3MLy9hE7pay26nRiaW9t2ehrsNp3/vx/PzG/Vn87iv71EUW/qF0sfaUfOVUaBogQ==
X-Received: by 10.55.8.5 with SMTP id 5mr6561283qki.265.1491247560270; Mon, 03 Apr 2017 12:26:00 -0700 (PDT)
Received: from rtp-acee-8814.cisco.com ([173.38.117.86]) by smtp.gmail.com with ESMTPSA id x19sm10215004qtc.23.2017.04.03.12.25.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Apr 2017 12:25:59 -0700 (PDT)
From: Acee Lindem <acee.lindem@gmail.com>
X-Google-Original-From: Acee Lindem <aceelindem@gmail.com>
Message-Id: <C9E686E0-BAA0-428E-874F-A14FB24E06F6@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FA035886-604C-45E9-9A0E-2AECE7E54406"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 03 Apr 2017 15:25:57 -0400
In-Reply-To: <73BFDDFFF499304EB26FE5FDEF20F7885088DEA9@blreml501-mbb>
Cc: "draft-ietf-ospf-ospfv3-lsa-extend.all@ietf.org" <draft-ietf-ospf-ospfv3-lsa-extend.all@ietf.org>, "ospf@ietf.org" <ospf@ietf.org>
To: Veerendranatha Reddy Vallem <veerendranatharv@huawei.com>
References: <73BFDDFFF499304EB26FE5FDEF20F7885088DEA9@blreml501-mbb>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/IcfXPTIYIoSCiehnlwJLgcwwI9w>
Subject: Re: [OSPF] [OSPFv3- Extended LSAs] Regarding Extended TLV validation procedure for malformed LSAs
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Apr 2017 19:26:07 -0000

Hi Veerendranatha, 

> On Apr 3, 2017, at 8:54 AM, Veerendranatha Reddy Vallem <veerendranatharv@huawei.com> wrote:
> 
> Dear Authors,
> Can you please confirm the actions need to take while validating extended TLVs for malformed extended LSA check while parsing the LSA.
> Can you please confirm which case we can discard LSA or in which case we will ignore  TLV, but LSA is consider as valid and processed other TLVs.
>  
> S.No            Scenario                                                                                                                              Action
> 1                     Sum of TLV lengths is more than total LSA body length                                        Discard the LSA by considering malformed packet, no ACK

I’d certainly agree with this. 


>  
> 2                     Sum of TLV lengths is same as total LSA  body length, but                                   Ignore the current TLV and continue to next TLV (or)
>                        Sub TLV length/ sum of sub TLV length in one TLV                                                 Discard the LSA by considering malformed packet with  no ACK??
>                         exceeds TLV length     


Unless the correct TLV length is known in advance, I don’t see how you can parse this correctly. I’d consider it a malformed packet. 



> 3.                    Sum of TLV and sub TLV lengths are  same as total LSA body length                
>                        But TLV length is not correct as per TLV type
>                       (Ex: Router Link TLV has fixed length of 16 bytes, but provided
>                        8 bytes data in one  of router Link TLV and TLV length also set as 8 bytes)      Discard the current TLV and continue to next TLV (or)
>                                                                                                                                                                   Discard the LSA by considering malformed packet with no ACK??


I’d just log an error in this case but certainly wouldn’t change the LSA content. Depending on the usage, the LSA can be marked as invalid. 




> 4.                   Sum of TLV and sub TLV lengths are  same as total LSA body length                
>                        TLV length is correct as per length of sub TLVs, but sub TLV length is
>                        not correct as per sub TLV type
>                       (Ex: Adj SID sub TLV has at least fixed length of 8 bytes, but provided
>                        4 bytes data in one  of Adj SID sub TLV and sub TLV length also set as 4 bytes)      Discard the current TLV and continue to next TLV (or)
>                                                                                                                                                                         Discard the LSA by considering malformed packet with no ACK??


Same as #3. 

Thanks,
Acee



>  
> Regards,
> Veerendranath
>                       
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org <mailto:OSPF@ietf.org>
> https://www.ietf.org/mailman/listinfo/ospf <https://www.ietf.org/mailman/listinfo/ospf>

v2.23.0 | Report a Bug | By Email