(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.
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 <j...@joelhalpern.com> 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>
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>
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>
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 <j...@joelhalpern.com> 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
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
