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

[David Mandelberg <[e-mail]>]

No worries about the delay. And I'm just a secdir reviewer, not an IESG 
member, so I can't do anything about a DISCUSS.

On 03/23/2018 07:02 PM, Les Ginsberg (ginsberg) wrote:
> David -
> 
> Yes - IGP specs have this. See (for example):
> 
> https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-15#section-2.2.1
> 
> If this suffices please clear your DISCUSS on the draft.
> 
> Again, apologies for the long delay in responding - it was not intentional.
> 
>      Les
> 
>> -----Original Message-----
>> From: David Mandelberg <[e-mail]>
>> Sent: Friday, March 23, 2018 3:57 PM
>> To: Les Ginsberg (ginsberg) <[e-mail]>; [e-mail];
>> [e-mail]; [e-mail]
>> Subject: Re: secdir review of draft-ietf-spring-segment-routing-13
>>
>> 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#sec
>>>>> ti
>>>>> 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/


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