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? >>> .. _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
