Subject: SRv6 - SRH in encaps or base header

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 22 Oct 2018 19:21:30 -0400

I have earlier asked for clarification on when encapsulation can be 
used, when a base IPv6 packet with an SRH can be used, and when either 
must be accepted by a recipient.

The document seems to say in section 3.1 that a host in an SR domain 
that understands SRv6 and wants to use an SRH does so by inserting the 
header in the SRv6 packet it generates.  The text also seems to say that 
an SR domain ingress router wanting to put an SRH on a received packet 
does so by encapsulating the packet.

The dichotomy seems to create difficulties and complexities.

1) If an SR Node in the SR Domain wishes to use SRH to steer the packet 
across the domain (presumably in compliance with policy, unless it is 
compromised), it does so by putting the SRH in the packet, and ssetting 
the IPv6 destiantion to the first SRH entry.  So far, so good.  What 
happens if this packet is destined outside the SRH domain.  The SRH MUST 
be removed.  But the SRH is in the base IPv6 packet.  It can not be removed.

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.

Issue 1) above seems an important violation of our constraints.  Issue 2 
requires at least explicit documentation.

One might be tempted to deal with issue one by saying that SR Hosts 
sending to destinations outside the domain MUST encapsulate the packets 
as a domain ingress would.  That would fix the problem.

I would then suggest that it would be simpler if SR Hosts simply always 
encapsulated.

Yours,
Joel

---

From: Tom Herbert <[email-masked]>
Date: Mon, 22 Oct 2018 16:38:51 -0700

On Mon, Oct 22, 2018 at 4:21 PM, Joel M. Halpern <[email-masked]> wrote:
> I have earlier asked for clarification on when encapsulation can be used,
> when a base IPv6 packet with an SRH can be used, and when either must be
> accepted by a recipient.
>
> The document seems to say in section 3.1 that a host in an SR domain that
> understands SRv6 and wants to use an SRH does so by inserting the header in
> the SRv6 packet it generates.  The text also seems to say that an SR domain
> ingress router wanting to put an SRH on a received packet does so by
> encapsulating the packet.
>
> compromised), it does so by putting the SRH in the packet, and ssetting the
> IPv6 destiantion to the first SRH entry.  So far, so good.  What happens if
> this packet is destined outside the SRH domain.  The SRH MUST be removed.
> But the SRH is in the base IPv6 packet.  It can not be removed.

Joel, why would it be a MUST to remove the SRH? I would presume in
this case that the final destination could be set by the egress router
of the domain and the packet could be forwarded over the Internet with
SRH present. The ultimate receiver will need to process the SRH, but
otherwise I don't see why this shouldn't work (although it's probably
not very practical or secure to do this).

Tom

>
> 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.
>
> One might be tempted to deal with issue one by saying that SR Hosts sending
> to destinations outside the domain MUST encapsulate the packets as a domain
> ingress would.  That would fix the problem.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 22 Oct 2018 19:44:13 -0400

If they can not be removed, than the system consistently leaks topology 
information.  That seems a pretty clear problem.

Maybe I was naive in assuming the original "must be an isolated domain" 
instruction applied to exit as well as entry.

Yours,
Joel

PS: If the problem were actually unsolvable, and rare, I might be 
tempted to see if we could get away with breaking the rules.  But it is 
neither rare nor difficult to solve.

---

From: Tom Herbert <[email-masked]>
Date: Mon, 22 Oct 2018 16:57:13 -0700

> information.  That seems a pretty clear problem.

Right, but that's a problem with how it might be used, not a problem with
the protocol itself. If I deployed this, I'd want a firewall to not leak
SRH. I agree with your point that SRH can't be removed (or inserted) in the
network. If that is required then encapsulation should be used.

Tom

> used,
> that
> the
> SR
> sending

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 23 Oct 2018 00:04:15 +0000

inline.

> On Oct 22, 2018, at 7:21 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> I have earlier asked for clarification on when encapsulation can be used, when a base IPv6 packet with an SRH can be used, and when either must be accepted by a recipient.
> 
> The document seems to say in section 3.1 that a host in an SR domain that understands SRv6 and wants to use an SRH does so by inserting the header in the SRv6 packet it generates.  The text also seems to say that an SR domain ingress router wanting to put an SRH on a received packet does so by encapsulating the packet.
> 
> 1) If an SR Node in the SR Domain wishes to use SRH to steer the packet across the domain (presumably in compliance with policy, unless it is compromised), it does so by putting the SRH in the packet, and ssetting the IPv6 destiantion to the first SRH entry.  So far, so good.  What happens if this packet is destined outside the SRH domain.  The SRH MUST be removed.  But the SRH is in the base IPv6 packet.  It can not be removed.
> 

In other words: A SR Domain Source Node which sends a packet via an SR Policy where the last segment in the segment list is destined to a node outside the SR Domain.  In this case the segments in the SRH may be learned by nodes outside the domain; either the destination or intermediate nodes outside the SR Domain.  To avoid such a leak of topology, an SR Source node may choose to encapsulate an inner packet with out an SRH in an outer IPv6 header to traverse the SR Domain.

Is this what you’re saying?  Perhaps 7.3 is a good location for such a statement.

> 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?

> Issue 1) above seems an important violation of our constraints.  Issue 2 requires at least explicit documentation.
> 
> One might be tempted to deal with issue one by saying that SR Hosts sending to destinations outside the domain MUST encapsulate the packets as a domain ingress would.  That would fix the problem.
> 
> I would then suggest that it would be simpler if SR Hosts simply always encapsulated.
> 
> Yours,
> Joel
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 22 Oct 2018 20:29:10 -0400

The way the text is currently written, you can not deploy such a firewall.

I think we are getting closer and will respond to Darren's message on 
the topic with the rest.

Yours,
Joel

On 10/22/18 7:57 PM, Tom Herbert wrote:
> 
> 
> On Mon, Oct 22, 2018, 4:44 PM Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> Right, but that's a problem with how it might be used, not a problem 
> with the protocol itself. If I deployed this, I'd want a firewall to not 
> leak SRH. I agree with your point that SRH can't be removed (or 
> inserted) in the network. If that is required then encapsulation should 
> be used.
> 
> Tom
> 
> 
>      > On Mon, Oct 22, 2018 at 4:21 PM, Joel M. Halpern
>     <[email-masked] <mailto:[email-masked]>> wrote:
>      >> [email-masked] <mailto:[email-masked]>

---

From: Joel Halpern Direct <[email-masked]>
Date: Mon, 22 Oct 2018 20:41:40 -0400

I would prefer that the SR node in the text you propose SHOULD (or some 
would argue in order to permit firewalls removing the information MUST) 
use such encapsulation.  MAY seems very weak.

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 22 Oct 2018 20:49:42 -0400

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.

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.

Thus, 9 needs to be able to check for both cases.  We at least need to 
tell implementors that.

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. 
  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.

Yours,
Joel

>> On Oct 22, 2018, at 7:21 PM, Joel M. Halpern <[email-masked]> wrote:
..
> Can you be more precise here.  Perhaps use the example from section 5.2 or 6.2.1?
..

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 22 Oct 2018 20:57:35 -0400

If we always encapsulate, and assume that 8 has the same access to 
mapping 9-non-SID to 9-SID, then we do not have any issue of two modes. 
And we do not have any split DNS issue.  And we don't have to worry 
about whether 8 SHOULD / MUST / MAY encapsulate when it wants to send a 
packet to 8, by way of 1 with an SRH.

Yours,
Joel

On 10/22/18 8:49 PM, Joel M. Halpern 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.
>>>
>>
> ...

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 22 Oct 2018 21:08:39 -0400

That last line is 8 sending to 1 by way of 3.
Sorry,
Joel

On 10/22/18 8:57 PM, Joel M. Halpern wrote:
>> Hosts (not just hosts within the domain, they are capable of and 
>> expect to deal with SRHs, and therefore have local SIDs, ...)
>>
>> 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.
>>
>> 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.
>>
>> that is a valid SID, so it can be the last entry in the SRH from 8 to 
>> 9.   However, if 1 were to send the packet to that SID for 9, router 3 
>> 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. 
>>>> 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.
>>>>
>>>

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Fri, 26 Oct 2018 17:29:46 +0000

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-masked]> 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”.

> 
> 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.

> 
> 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.
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

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Fri, 26 Oct 2018 18:22:17 +0000

+spring

On Oct 22, 2018, at 8:49 PM, Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:

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-masked]<mailto:[email-masked]>> 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.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 26 Oct 2018 14:27:30 -0400

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

> 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>

> 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>
>>   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 th…
<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>

---

From: Joel Halpern <[email-masked]>
Date: Fri, 26 Oct 2018 14:28:37 -0400

(resending, +spring as requested)

Yours,
Joel

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 30 Oct 2018 19:30:45 +0000

I think we’re almost concluded so once more inline at <dd></dd>

> On Oct 26, 2018, at 2:28 PM, Joel Halpern <[email-masked]> wrote:
> 
> 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>

> <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> 

> <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>

> <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>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 30 Oct 2018 15:42:32 -0400

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

---

From: "Chengli (IP Technology Research)" <[email-masked]>
Date: Wed, 31 Oct 2018 03:41:52 +0000

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-masked]] On Behalf Of Darren Dukes (ddukes)
Sent: Wednesday, October 31, 2018 3:31 AM
To: Joel Halpern <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: SRv6 - SRH in encaps or base header - point 2

>> 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.
> 
>>> 
> <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>

> 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>