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

[Tobias Gondrom <[e-mail]>]

 Hello Sri,

thank you. I saw the updated draft 05 resolved all my editorial comments
(removed them from this email).
Still one thing remains nagging me:
I appreciate your answers in your email about the topic below, but we
seem to disagree whether that justifies an explanation in the security
considerations or not: I believe it should, but noticed that you didn't
add anything about this in the security considerations in version-05.

Note to the AD: please consider this note only as a COMMENT (not a
DISCUSS) as I still believe it would be good to reflect Sri's
explanations below in the Security considerations, but will not want to
insist on that point.
Btw. the argument that certain problems are not unique to this draft
does not mean you needn't point them out in the security considerations.
;-)

Kind regards and thanks, Tobias




On 10/04/2010 07:07 PM, Sriganesh Kini wrote:
>>
>>>> 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)
> [Sri] The weaker criteria of RFC 5443 does not ensure that the problem does not exist there. In fact the problem exists in a plain IP network with link-state IGP. If the directly connected path has a higher metric than an alternate path with TTL (say > 255) hops then the standard SPF will conclude that the shortest path is the alternate path although through this path the neighboring node is unreachable. Note that in this case the link is advertised with its normal metric yet there is unreachability in the network.
>>>> 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.
>>>