Re: [OSPF] Alvaro Retana's Yes on draft-ietf-ospf-prefix-link-attr-10: (with COMMENT)

"Acee Lindem (acee)" <> Mon, 17 August 2015 20:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EE0B01B2FCF; Mon, 17 Aug 2015 13:17:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sKET9yDAzfqn; Mon, 17 Aug 2015 13:17:01 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 180011B2FCD; Mon, 17 Aug 2015 13:17:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3962; q=dns/txt; s=iport; t=1439842621; x=1441052221; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3+y1+oDVwatiqbpkmxJAUmEBWJg+eCqecCqSqKIr5fc=; b=MF3k6P7RMN4IoG1Xq8vYACwrew8MgRl5fsdMMLeZWpSe7IQwkikmdyAi pxUqfOAE6ek3LhYO9I1FjFJS4LEW8y9UbfEAEckX9X3k6po7NlAqNVk9b c6ZiGLRA2Q5ArMVvgDPmbRfeNhftw/GyWVXkR7Sf4Hjvukjx1gBJthRI5 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.15,697,1432598400"; d="scan'208";a="178877514"
Received: from ([]) by with ESMTP; 17 Aug 2015 20:17:00 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t7HKH0wf015364 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 17 Aug 2015 20:17:00 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 17 Aug 2015 15:16:59 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 17 Aug 2015 15:16:59 -0500
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Mon, 17 Aug 2015 15:16:59 -0500
From: "Acee Lindem (acee)" <>
To: "Alvaro Retana (aretana)" <>, The IESG <>
Thread-Topic: Alvaro Retana's Yes on draft-ietf-ospf-prefix-link-attr-10: (with COMMENT)
Thread-Index: AQHQ1fmX9qzLUvViaUO6WvDXjCJuIZ4QSbsAgABQu4CAAB2uAA==
Date: Mon, 17 Aug 2015 20:16:59 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "" <>, "" <>, "" <>, "" <>
Subject: Re: [OSPF] Alvaro Retana's Yes on draft-ietf-ospf-prefix-link-attr-10: (with COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 Aug 2015 20:17:03 -0000

Hey Alvaro, 

On 8/17/15, 10:30 AM, "Alvaro Retana (aretana)" <> wrote:

>On 8/17/15, 9:41 AM, "Acee Lindem (acee)" <> wrote:
>Thanks for looking into my comments!  Just one more thing below.
>. . .
>>>2. Section 2.1. (OSPFv2 Extended Prefix TLV)
>>>a. For the Route Type, are those the only allowed values?  What happens
>>>if something else is used?
>>Yes - these are the only route types allowed. If an invalid type is
>>specified, the attributes will not be correlated with a route.
>I¹m glad you brought this up ‹ the correlation.  I should¹ve commented on
>this before..
>I don¹t think the draft talks about how to correlate the additional
>information back to the ³normal² LSAs.  Given that it is important for the
>route type and the prefix to match (anything else?), it would be good if
>it was called out somewhere.  I¹m assuming that the fact that the
>correlation is not made will just result in lost information ‹ but some
>application may really want this information, so loosing it could be
>importante for them.  Explaining the potential impact would be very good.
>Same comment for the other TLV..

Actually, our intent is not to limit these mechanisms to the existing
prefix and link types even though all the existing drafts dependent on the
mechanisms do require correlation. I will word the description of
route-type and link as such.

>. . .
>>>4. Section 6. (Security Considerations)
>>>a. I think you should also point the readers at the considerations in
>>>b. ³Šimplementations must assure that malformed TLV and Sub-TLV
>>>permutations do not result in errors that cause hard OSPF failures.²
>>>What does that mean?  That the software should be resilient?  Or are you
>>>pointing at just ignoring the information if there is a malformed
>>>TLV/sub-TLV (that is somehow salvageable)?  It would be vey nice is this
>>>draft set the example by specifying what to do in some cases (maybe not
>>>malformed, but incorrect/unknown as mentioned above).
>>This stems from prior attacks on routing protocols involved carefully
>>crafted malformed TLVs which could result in software crashes.
>Still, explaining what to do with malformed information would be good.

In general, an LSA that is malformed is not acknowledged, stored in the
LSDB, or flooded. There were some attack where implementations accesses
beyond the end of an OSPF packet and crashed (not my implementation ;^).
I’ll write to this.

I will reference the RFC 5250 security considerations. I will also note
that an applications using these extensions must describe the
considerations specific to that application.


>This obviously goes back to the loss of information.