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

"Alvaro Retana (aretana)" <aretana@cisco.com> Mon, 17 August 2015 14:31 UTC

From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: "Acee Lindem (acee)" <acee@cisco.com>, The IESG <iesg@ietf.org>
Thread-Topic: Alvaro Retana's Yes on draft-ietf-ospf-prefix-link-attr-10: (with COMMENT)
Thread-Index: AQHQ1fmXYwG8fMqjhEys4ddRMwDFRZ4QjMwA///KmQA=
Date: Mon, 17 Aug 2015 14:30:43 +0000
Message-ID: <D1F763C0.C6062%aretana@cisco.com>
References: <20150813185510.2178.47613.idtracker@ietfa.amsl.com> <D1F6A062.2BA5E%acee@cisco.com>
In-Reply-To: <D1F6A062.2BA5E%acee@cisco.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <565662CB00412C43AECED21BF380448E@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/Hijgk5d24mc78bkxjkgOPbQBjZA>
Cc: "ospf@ietf.org" <ospf@ietf.org>, "draft-ietf-ospf-prefix-link-attr@ietf.org" <draft-ietf-ospf-prefix-link-attr@ietf.org>, "draft-ietf-ospf-prefix-link-attr.shepherd@ietf.org" <draft-ietf-ospf-prefix-link-attr.shepherd@ietf.org>, "draft-ietf-ospf-prefix-link-attr.ad@ietf.org" <draft-ietf-ospf-prefix-link-attr.ad@ietf.org>, "ospf-chairs@ietf.org" <ospf-chairs@ietf.org>
Subject: Re: [OSPF] Alvaro Retana's Yes on draft-ietf-ospf-prefix-link-attr-10: (with COMMENT)
Precedence: list

On 8/17/15, 9:41 AM, "Acee Lindem (acee)" <acee@cisco.com> wrote:

Acee:

Hi!

Thanks for looking into my comments!  Just one more thing below.

Alvaro.

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

. . .
>>4. Section 6. (Security Considerations)
>>
>>a. I think you should also point the readers at the considerations in
>>rfc5250.
>>
>>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.

Ahh..ok.

Still, explaining what to do with malformed information would be good.
This obviously goes back to the loss of information.

[OSPF] Alvaro Retana's Yes on draft-ietf-ospf-pre… Alvaro Retana
Re: [OSPF] Alvaro Retana's Yes on draft-ietf-ospf… Acee Lindem (acee)
Re: [OSPF] Alvaro Retana's Yes on draft-ietf-ospf… Alvaro Retana (aretana)
Re: [OSPF] Alvaro Retana's Yes on draft-ietf-ospf… Acee Lindem (acee)