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?
1.2 : How to inform the destination of the segments in the SRH? Any indicator
in SRH? Or through signaling?
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.
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.
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
