Re: [spring] SRv6 - SRH in encaps or base header - point 2

["Joel M. Halpern" <[e-mail]>]

Thank you.  That does address my concern about those exchanges.
Yours,
Joel

On 11/3/18 2:50 AM, Darren Dukes (ddukes) wrote:
> Joel, For our last remaining item in this thread, *re: communication 
> from 1 to 9 and 9 to 1.*
> 
> Lets add the following since we don’t discuss traffic from a host within 
> the SR Domain to a host outside the SR Domain.
> 
> <NEW TEXT>
> *5.3.3 Inter SR Domain Packet*
> Host 9 sends a packet to host 1 (outside the SR Domain) via an SR Policy 
> <S6,S3>.
> Host 9 encapsulates an inner packet from 9 to 1 in an outer IPv6 header 
> and adds an SRH for the SR Policy.
> 
>     P7: (A9,S6)(S3,S6; SL=1)(A9,A1)
> 
> A host implementation MUST support addition of the outer IPv6 
> encapsulation to avoid leaking SIDs to nodes outside the SR Domain.
> 
> For return traffic to A9, an outer IPv6 header may be applied by the SR 
> Domain ingress node.  This outer IPv6 header may terminate at node 9, 
> therefore a host implementation MUST support decapsulation of an outer 
> IPv6 header and processing of the inner header.
> </NEW TEXT>
> 
> For traffic destined within the SR Domain it’s still up to the host or 
> controller providing the SR Policy to determine whether or not they must 
> encapsulate in an outer IPv6 header.
> 
> Darren
> 
>> On Oct 30, 2018, at 3:42 PM, Joel M. Halpern <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> I am not sure I agree that the allowance for handling the HMAC 
>> elsewhere is straightforward.  For example, I think the range of 
>> implementation strategies for border nodes and the intersection of 
>> that with the range of operational and deployment strategies is going 
>> to actually make it harder to get multi-vendor deployments.  Having 
>> said that, the approach in the document will work.  And I can live 
>> with it.
>>
>> On the choice of encaps or not encaps (from node 9 to external node 1) 
>> there are two issues.
>> The important issue is that node 9 needs to be able to encaps. 
>> Otherwise there is no decision availabe, and the nodes software is 
>> forcing the operator to disclose, even if there policy is not to do 
>> so. Thus, I think the minimum requirement is that the document needs 
>> to clearly state that node 9 needs to be able to handle incoming 
>> encaps and needs to be able to generate outgoing encaps.
>>
>> The lesser issue is "why bother?"  Why not always encaps.  Given that 
>> the network has to have an MTU big enough to handle an encaps packet 
>> (due to incoming packets from out the SR domain), there is no MTU 
>> issue wiht the encaps.  As such, we are talking about reducing the 
>> security and robustness of the solution in exchange for saving a few 
>> bytes.  That almost never turns out well.
>>
>> Yours,
>> Joel
>>
>> On 10/30/18 3:30 PM, Darren Dukes (ddukes) wrote:
>>> I think we’re almost concluded so once more inline at <dd></dd>
>>>> On Oct 26, 2018, at 2:28 PM, Joel Halpern <[e-mail] 
>>>> <mailto:[e-mail]>> 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 <[e-mail] 
>>>>>> <mailto:[e-mail]>> 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 
>>>>>>>> <[e-mail] <mailto:[e-mail]>> 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?
>>>>>> ..
>