Re: [secdir] Secdir review of draft-ietf-mpls-ldp-igp-sync-bcast-04

[Tobias Gondrom <[e-mail]>]

 Answers inline [tg]
BR, Tobias

On 10/01/2010 09:08 PM, Sriganesh Kini wrote:
> Hello Tobias,
>
> Pls see inline at [Sri].
>
> Thanks
>
>> -----Original Message-----
>> From: Tobias Gondrom [mailto:[e-mail]]
>> Sent: Monday, September 27, 2010 4:37 AM
>> To: [e-mail]; [e-mail]
>> Cc: [e-mail];
>> Sriganesh Kini; Wenhu Lu; [e-mail]; [e-mail]; 
>> [e-mail]; [e-mail]
>> Subject: Secdir review of draft-ietf-mpls-ldp-igp-sync-bcast-04
>>
>>
>>  I have reviewed this document as part of the security directorate's 
>> ongoing effort to review all IETF documents being processed by the 
>> IESG.  These comments were written primarily for the benefit of the 
>> security area directors.
>> Document editors and WG chairs should treat these comments just like 
>> any other last call comments.
>>
>>
>> draft-ietf-mpls-ldp-igp-sync-bcast-04
>> LDP IGP Synchronization for broadcast networks
>>
>> the draft updates RFC 5443 (LDP IGP Synchronization) It basically 
>> proposes the following mechanism: "If an interface is not a 'cut-edge'
>> then the updating of the LSA with that link to the pseudo-node is 
>> postponed until LDP is operational."
>>
>> The document states that there would be no security considerations 
>> beyond RFC5443.
>> I am not certain of that. Although the idea behind bcast is good, it 
>> adds a new mechanism beyond 5443.
>> To make sure the security considerations are accurate, I'd like to 
>> raise two questions for the authors/WG:
>> 1. Which security implications does the WG see for removing a coming 
>> up link from the LSDB?
> [Sri] Since the link is only delayed from being added to the LSDB we don't believe there are any new/additional security implications.
[tg] still the delay is in theory not time limited, but based on the
condition of LDP of the link. In combination with #2 (below) that the
cut-edge of the network may actually be calculated falsely, can this be
exploited or lead to unreachability?
Note: although your remark is right regarding similarities with 5443,
the criteria in 5443 is much weaker as it only increases its metric, but
does not remove it from LSDB/hold back its entry. Again, I am not an
expert on that layer, but I am still uncertain that no security
considerations derive from that. Did you consider this scenario when you
wrote the draft? Is it unrealistic that it could be exploited with bad
intentions?
If not, which would be the underlying implied pre-conditions to be met
to avoid such or under which pre-conditions could such a problem occur?
(potential input for the security considerations section)
 
>> 2. Can there be a gap between the algorithm to determine "cut-edge" 
>> and TTL (e.g. may not qualify for "cut-edge" and thus be removed from 
>> LSDB, but have a large number of links and effectively not be 
>> reachable)?
> [Sri] This problem is not unique to this draft. Even in RFC 5443 when the link has high metric, an alternate path with num hops > 255 (but a lower path metric than the directly connected link's max metric) can result in unreachability.
>
>> and three minor editorial comments:
>> - section 3, last paragraph:
>> s/Since A's cost to reach B not high/Since A's cost to reach B is not 
>> high
> [Sri] Accepted
>
>> - Appendix A: Computation of 'cut-edge'
>> there should be an informative reference for mentioned "Dijkstra's 
>> algorithm"
> [Sri] Accepted. Will refer to RFC 2328 sec 16.1
>
>> - abbreviation "SPF" should list the its expanded term (Shortest Path
>> First) at first mentioning.
> [Sri] Accepted.
>
>> Best regards, Tobias
>>
>>
>>
>>
>>