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

["Acee Lindem (acee)" <[e-mail]>]

Hey Alvaro, 

On 8/17/15, 10:30 AM, "Alvaro Retana (aretana)" <[e-mail]> wrote:

>On 8/17/15, 9:41 AM, "Acee Lindem (acee)" <[e-mail]> 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..

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

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.

Thanks,
Acee 


>This obviously goes back to the loss of information.
>