Re: [secdir] secdir review of draft-ietf-spring-segment-routing-13

[David Mandelberg <[e-mail]>]

Thanks, I didn't know it was in the IGP specs. If the usage you describe 
would be clear to anybody using this, then I think you've fully 
addressed my original comment.

On 03/23/2018 06:43 PM, Les Ginsberg (ginsberg) wrote:
> David -
> 
> Thanx for the very prompt response.
> 
> If a controller (for example) is defining a SID stack for an SR Policy, it can choose to use an  Adj-SID which is advertised as Persistent and be confident that the SID will not be reused for some other purpose no matter what happens on the owning node.
> 
> BTW, the flag isn’t new - it has been part of the IGP specifications for quite a long while. It just wasn't mentioned in the SR Architecture in earlier versions.
> 
> HTH
> 
>       Les
> 
>> -----Original Message-----
>> From: David Mandelberg <[e-mail]>
>> Sent: Friday, March 23, 2018 3:17 PM
>> To: Les Ginsberg (ginsberg) <[e-mail]>; [e-mail];
>> [e-mail]; [e-mail]
>> Subject: Re: secdir review of draft-ietf-spring-segment-routing-13
>>
>> Hi,
>>
>> How will the indication of persistence be used? I scanned the changes from -13
>> to -15, but I didn't notice any other text about the new flag.
>>
>> On 03/23/2018 06:34 AM, Les Ginsberg (ginsberg) wrote:
>>> David -
>>>
>>> Apologies. It appears that I neglected to respond to this old review
>>> comment.
>>>
>>> This was not intentional. Authors actively discussed your comment
>>> promptly and we did add text in V14 of the draft to address this point:
>>>
>>> Please see:
>>> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15#secti
>>> on-3.4
>>>
>>> /o  Indication whether the Adj-SID is persistent across control plane/
>>>
>>> /      restarts.  Persistence is a key attribute in ensuring that an
>>> SR/
>>>
>>> /      Policy does not temporarily result in misforwarding due to/
>>>
>>> /      reassignment of an Adj-SID./
>>>
>>> //
>>>
>>> Please let us know if this adequately addresses your comment.
>>>
>>> Again, apologies for the long delay.
>>>
>>>      Les
>>>
>>>   > -----Original Message-----
>>>
>>>   > From: David Mandelberg <[e-mail]>
>>>
>>>   > Sent: Thursday, November 02, 2017 10:53 AM
>>>
>>>   > To: [e-mail]; [e-mail]; draft-ietf-spring-segment-
>>>
>>>   > [e-mail]
>>>
>>>   > Subject: secdir review of draft-ietf-spring-segment-routing-13
>>>
>>>   >
>>>
>>>   > 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.
>>>
>>>   >
>>>
>>>   > The summary of the review is Ready with nits.
>>>
>>>   >
>>>
>>>   > This document affects routing within a trusted domain, and the
>>> security
>>>
>>>   > considerations section adequately talks about filtering at the
>>> border of a trusted
>>>
>>>   > domain.
>>>
>>>   >
>>>
>>>   > I do have one question about something I didn't see in the
>>> document, what
>>>
>>>   > happens when SIDs change while packets are in transit? Here's a
>>> hypothetical
>>>
>>>   > situation that could be bad for security, but I'm not sure whether
>>> or not it could
>>>
>>>   > happen: 1. An internal node calculates an SR Policy and sends out a
>>> packet that
>>>
>>>   > will eventually egress towards a BGP peer. 2. Multiple links on the
>>> BGP router go
>>>
>>>   > down and then back up, but are allocated different PeerAdj SIDs
>>> than they had
>>>
>>>   > before. 3. The packet reaches the BGP router, but egresses to the
>>> wrong BGP
>>>
>>>   > peer because the original PeerAdj SID is now mapped to a different
>>> PeerAdj
>>>
>>>   > segment.
>>>
>>>   >
>>>
>>>   > --
>>>
>>>   > Freelance cyber security consultant, software developer, and more
>>>
>>>   > https://david.mandelberg.org/
>>>
>>
>>
>> --
>> Freelance cyber security consultant, software developer, and more
>> https://david.mandelberg.org/


-- 
Freelance cyber security consultant, software developer, and more
https://david.mandelberg.org/