Yes, SRH insertion is not discussed in this draft and not within its scope.
Darren > On Nov 4, 2018, at 11:55 PM, Chengli (Cheng Li) <[email protected]> wrote: > > so how to use SRH insertion? Out of scope of this draft? > > Cheng > > > -----邮件原件----- > 发件人: Darren Dukes (ddukes) [mailto:[email protected]] > 发送时间: 2018年11月3日 2:40 > 收件人: Chengli (Cheng Li) <[email protected]> > 抄送: Joel Halpern <[email protected]>; [email protected]; [email protected]; > Lizhenbin <[email protected]>; Mach Chen <[email protected]> > 主题: Re: SRv6 - SRH in encaps or base header - point 2 > > Hello Cheng, thanks for the review! Please see inline > >> On Oct 30, 2018, at 11:41 PM, Chengli (IP Technology Research) >> <[email protected]> wrote: >> >> Hi Darren, >> >> I think the text of encapsulating mode is clear for me. But I still have >> some questions of the insertion mode . >> >> 1.1 :<dd> Node 9 has a choice, encapsulate to node 3 or not. >> If node 9 does not encapsulate, it will inform the destination of the >> segments in the SRH and possibly leak them to intermediate nodes. >> >> If there is not indicator to make a choice of encapsulating or not, how the >> node to make the choice? Local policy? >> Or make it the same like the received packet? Encapsulate if received packet >> does, else, insert? > > A host needs many things to determine how to add an SRH to a packet it is > sending to a destination, at least it needs to learn SIDs for nodes and have > some logic in place to determine how and when to use a particular segment > list… That is well beyond this document and there is and will be more > innovative ways of determining when to add a SRH to a packet sourced by a > node. > > Therefore I’ll say this question is not within scope for this document, it > needs to be answered for specific use cases and applications of the SRH. > > That said there is ongoing work to define how a node may learn an SR Policy: > PCEP https://www.ietf.org/id/draft-negi-pce-segment-routing-ipv6-03.txt, > BGP-TE > https://www.ietf.org/id/draft-ietf-idr-segment-routing-te-policy-04.txt, > or “SDN” methods where some outside controller sets up a segment list via > some REST, CLI, netconf/yang interface to satisfy specific use cases. > > And when to use it: > BGP SRv6 services https://www.ietf.org/id/draft-dawra-idr-srv6-vpn-05.txt > > >> >> 1.2 : How to inform the destination of the segments in the SRH? Any >> indicator in SRH? Or through signaling? >> > > > Same answer as 1.1. > >> 2: Can a normal(non-SID) IPv6 address be added into SID list? >> >> I prefer yes. >> >> As section 4.3 says, it seems like we can do that. >> >> "When an SRv6-capable node receives an IPv6 packet, it performs a >> longest-prefix-match lookup on the packets destination address. This >> lookup can return any of the following: >> >> A FIB entry that represents a locally instantiated SRv6 SID >> A FIB entry that represents a local interface, not locally >> instantiated as an SRv6 SID >> A FIB entry that represents a non-local route >> No Match >> " >> Also, in section 5, we can see A9 can be added in SID list of a SR policy. >> >> So for the packet from A9 to A1, the address of A1 can be added as the last >> entry of SID list, right? >> >> If yes, address of A1 is not an instantiated SID, so not PSP flavor can be >> enabled. So the packet will be sent out by carrying the SRH after A1 is >> updated to the IPv6 DA. >> SRH will be leaked to outside of the SR domain, which will bring new >> security issues. >> > > Yes as the last segment in a segment list, and as RFC8200 section 4.4 > describes Routing Header processing when segments left is 0. > > It is up to the specific use case to determine if informing the destination > or intermediate nodes of the segment list used to reach it is a security > risk. > > Certainly on the larger internet this is an issue that needs to be > considered, but within an enterprise network or within a single providers > network crossing multiple domains, or even between providers the disclosure > may be acceptable or desired. > >> >> 3: For section 6.2, >> Nodes outside the SR Domain cannot be trusted. SR Domain Ingress >> routers SHOULD discard packets destined to SIDs within the SR Domain >> (regardless of the presence of an SRH) to avoid attacks on the SR >> Domain as described and referenced in [RFC5095]. >> >> As an additional >> layer of protection, SR Segment Endpoint nodes SHOULD discard packets >> destined to local SIDs from source addresses not part of the SR >> Domain. >> >> For a packet from A1 to A9, the packet is (A1, A9). Node3 will not drop the >> packet since the destination is A9 not S9. >> >> If node 3 insert a SRH in the original IPv6 packet, then the source Address >> will be A1. And the SID list can be <A9, S6 >. >> In this case, the packet will be dropped by node 6, since the source address >> is not part of the SR domain. [Section 6.2], right? >> >> IMHO, there are some problems about insertion mode. > > In the context of the SRH draft we do not make any mention or use of SRH > insertion. I.e. node 3 does not insert an SRH, it encapsulates in an outer > IPv6 header. > > Darren > >> >> Thanks, >> Cheng >> >> >> >> -----Original Message----- >> From: ipv6 [mailto:[email protected]] On Behalf Of Darren Dukes >> (ddukes) >> Sent: Wednesday, October 31, 2018 3:31 AM >> To: Joel Halpern <[email protected]> >> Cc: [email protected]; [email protected] >> Subject: Re: SRv6 - SRH in encaps or base header - point 2 >> >> I think we’re almost concluded so once more inline at <dd></dd> >> >>> On Oct 26, 2018, at 2:28 PM, Joel Halpern <[email protected]> wrote: >>> >>> (resending, +spring as requested) >>> >>> Thank you for the responses. I will respond in line, marked <jmh></jmh>. >>> I fear it will shortly get too deep, but the context is important. >>> >>> I will rephrase here an issue from another thread that I ahve not seen your >>> comments on. If Node 9 is sending traffic to Node 1 (for example, the >>> reverse traffic for the traffic from 1 to 9 in the examples below), it >>> presumably has an SR Policy to be applied. The issue I raised before is the >>> leakage issue. If 9 puts the SRH in its packet (as the document currently >>> mandates), then it will not be possible for 3 to remove the SRH. Thus, the >>> SRH will leak. >>> >>> Some have argued that is not a big deal. It seems to matter to me. But >>> there is an additional problem. A1 is not a SID. Therefore, 9 can not put >>> A1 into the SRH. If it can not put A1 into the SRH, and it does not >>> encapsulate the packet, where does it put A1. >> >> <dd> Node 9 has a choice, encapsulate to node 3 or not. >> If node 9 does not encapsulate, it will inform the destination of the >> segments in the SRH and possibly leak them to intermediate nodes. >> If node 9 does encapsulate, node 3 removes the outer header and node 1 would >> not learn the segment list. >> I think its choice should not be mandated in the draft. </dd> >> >>> >>> Yours, >>> Joel >>> >>> On 10/26/18 1:29 PM, Darren Dukes (ddukes) wrote: >>>> Hi Joel, you’ve described sections titled “Intra SR Domain Packet”, >>>> “Transit Packet Through SR Domain”, and "SR Source Nodes Not Directly >>>> Connected”. >>>> I’ve parsed them inline to the sections of the draft defining them and >>>> given more context where needed. >>>>> On Oct 22, 2018, at 8:49 PM, Joel M. Halpern <[email protected]> wrote: >>>>> >>>>> Rephrasing using the example from 5.2. Assuming that 8 and 9 are >>>>> SR Hosts (not just hosts within the domain, they are capable of and >>>>> expect to deal with SRHs, and therefore have local SIDs, ...) >>>>> >>>>> For traffic from 8 to 9 that needs an SRH, the SRH goes in the IPv6 >>>>> header sent my 8 to 9. When 9 processes the packet, it seems that it is >>>>> the last SID, figures out that there is no encapsulation, and send the >>>>> TCP / UDP / QUIC information to its internal protocols stacks. >>>> Yes, this is Section 5.3.1 “Intra SR Domain Packet”. >>> <jmh>Agreed as far as it goes. However, the existence of S9 and A9 >>> points to a problem. Node 8 is trying to put on an SRH going through >>> Sx, Sy, whatever for some reason. It can't put A9 into the SRH, as >>> AH is not a SID, it is an address. I presume node 8 got S9 from >>> whatever provided him the SR Policy that it is using. Does it simply >>> use S9 as the address for node 9, rather than A9 that it got from >>> DNS? And does the TCP stack know that this substitution is being >>> made? (This is another example of a problem that goes away if we >>> always encapsulate.) </jmh> >> >> <dd>Section 4.3.2 covers these questions, i.e. A9 can be placed in the >> SRH as the last segment, and this section describes how it’s >> handled.</dd> >> >>> >>>>> >>>>> For traffic from 1 to 9, where 3 adds an SRH, that SRH still presumably >>>>> ends at 9. 9 Receives the IP packet. Sees that it is addressed to >>>>> itself. Sees that the SRH is finished. And then notices that the >>>>> next-header is IPv6. Unwraps the header, checks that the inner >>>>> destination address is also itself, and passes the material carried by >>>>> the inner header up to the appropriate stack. >>>> So node 1 sends a packet to node 9 (A1,A9) IF there is some steering >>>> into an SR Policy at node 3 to reach node 9, this is identical to section >>>> 5.3.2 “Transit packet through SR domain”, except for destination of A9 via >>>> node 9 instead of A2 via node 4. >>> >>>>> >>>>> Thus, 9 needs to be able to check for both cases. We at least need to >>>>> tell implementors that. >>>> Well, 9 needs a SID S9 and Address A9. That is shown in Section 5.1 SID >>>> and address representation. >>> <jmh>So, let us assume that 3 has an SR policy it wants to apply to >>> the traffic from A1 to A9. In this case, the S9 / A9 dichotomy is >>> not a problem, I think. Node 3 encapsualtes the packet from A1 to >>> A9, uses S3 as the source address of the encapsulating header, and >>> ends the SID list in the SRH with S9. The unspecified part is that >>> node 9 needs to be prepared to receive such packets and do the double >>> processing. It is reasonable double processing. My only request >>> here is that we tell folks they need to support it. </jmh> >> >> <dd>Actually, node 3 uses A3 as its source address, but that’s minor. >> The double processing (lookup, do end processing, do another lookup) is >> documented in Section 4.3. >> Is there a need for more than what is currently specified? </dd> >> >>>>> >>>>> There is a further complication. 9 seems to need to have an address that >>>>> is a valid SID, so it can be the last entry in the SRH from 8 to 9. >>>> As described in the draft, Section 5.1 a node k has an address Ak and SID >>>> Sk. So node 9 has a valid SID. >>>> For traffic from 8 to 9, A9 is used as the destination as shown in section >>>> 5.3.1, 5.4 and 5.5. >>>>> However, if 1 were to send the packet to that SID for 9, router 3 would >>>>> be required by the rules we discussed in the other thread to discard the >>>>> packet as it is neither to prefix nor contains an HAMC. >>>>> And somehow, 8 and 1 need to each pick the right address to use for 9. >>>>> (split DNS maybe?) And 3 needs to be able to derive teh SID-formn >>>>> address for 9 from the non-SID form of the address so that it (3) can >>>>> build a proper SRH to get the packet to 9. >>> <jmh>I have retained your answer below for context, but I think that >>> answers the wrong question. I believe what is itnended is that only >>> A9 appears in DNS. So Node 1 will see 9 as A9, and will use that. >>> S9 will appear in SR Policies about traffic to node 9, but not in DNS. >>> That is what we need. I wish it were clearer in the text. </jmh> >>> >>> <jmh>If node 20 is generating SRHs with HMACs, then this is largely >>> the same as the case from 8 to 9, except that whomever creates the SR >>> Policy that 20 is using needs to also make sure that whatever the >>> first SID is in teh list, it processes HMACs and is recognizable to >>> node 3 as doing such processing. I am guessing that the reason for >>> allowing internal nodes to do the processing is to move the >>> verification load off the edge nodes. It does create significant >>> additional configuration complexity. </jmh> >> >> <dd>We didn’t see a reason to restrict the HMAC processing to only >> edge nodes when it was straight forward to define how they could be >> processed at non-edge nodes.</dd> >> >>> >>>> This is incorrect. >>>> See Section 6.2.1 “SR Source Nodes Not Directly Connected” I will expand >>>> on the example from that section. >>>> Node 20 sends a packet to A9 with SR Policy <H7> and an HMAC >>>> provided to node 20 by some yet to be defined method. Resulting in >>>> packet sent from node 20 >>>> P: (A20,H7)(A9;SL=1)(payload) >>>> Recall Hk is a SID at node k requiring HMAC verification, and it is >>>> covered by Prefix-H. >>>> Prefix-H is _not_ subject to ingress filtering at node 3. >>>> Therefore the packet P destined to H7 is not subject to ingress filtering >>>> at node 3. >>>> P is forwarded to node 7, where H7 is processed and the HMAC verified. >>>> If the HMAC can not be verified the packet is dropped, else it is >>>> forwarded to the next segment and destination, A9. >>>> Darren >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 10/22/18 8:04 PM, Darren Dukes (ddukes) wrote: >>>>>> inline. >>>>>>> On Oct 22, 2018, at 7:21 PM, Joel M. Halpern <[email protected]> >>>>>>> wrote: >>>>> .. >>>>>>> 2) Now let us look at packets arriving at and actually destined for an >>>>>>> SR Host in the SR Domain where that packet has an SRH. If the packet >>>>>>> is coming from another SR Host, the SRH will be in the base header, and >>>>>>> the host can simply check it for any violations, and continue. But, if >>>>>>> the packet came from outside the domain, then it will have an >>>>>>> encapsulating SRv6 header. So the host has to detect this case, check >>>>>>> and then peal off the encapsulating header, and then process the >>>>>>> received packet. Yes, it can do so. But nothing in teh document tells >>>>>>> implementors they have to deal with both cases. >>>>>>> >>>>>> Can you be more precise here. Perhaps use the example from section 5.2 >>>>>> or 6.2.1? >>>>> .. >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> [email protected] >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
