[IPv6] Routing Headers and limited domains (Was Re: Adoption call for draft-bonica-6man-comp-rtg-hdr

[Tom Herbert <[e-mail]>]

On Mon, Oct 30, 2023 at 6:33 PM Joel Halpern <[e-mail]> wrote:
>
> Maybe I am dense, but I have trouble seeing how a node could have enough information to compose a useful CRH source route, and not have enough information to know where the relevant decapsulator is.  The most obvious candidate would be simply to decapsulate at the last entry in the source route.  it doesn't matter if that is (as is likely) not actually the egress.

Hi Joel,

Yes, that would probably be the most obvious candidate, and it's also
a candidate for removing the RH. Once segments left is zero, the
routing header is not operationally relevant to any downstream nodes.

But even if that were the obvious choice for an encapsulation, I still
don't see how the source could know when to encapsulate and when not
to. A possible solution might be to tunnel all packets, but then
that's a lot of per packet overhead especially if most packets never
actually leave the limited domain.

More generally, constraining protocols like routing header to a
limited domain is required and it's clear that *something* needs to
happen at edge routers of the limited domain.
draft-raviolli-intarea-trusted-domain-srv6 has a good description of
the problem. That's focused on SR, but other routing headers like CRH,
and other use cases of extension headers also have similar
requirements-- I would hope that there might be a general solution to
limiting protocol to limited domains (IMO, a new Ethertype like
described in that draft isn't the best solution and is likely to
create a set of new problems)

Another variant is the possibility in segment routing that segment
routing could be applied to a packet without a routing header. I
assume the rationale for this is to avoid the overhead of the routing
header, and presumably this could be done for CRH. IMO, this is going
to be more problematic than removing routing headers. As you pointed
out, if we remove a RH then we no longer would know how the packet got
to where it is in the network; but, if there's no routing header to
begin with then not only would we not know how the packet got to the
point it was sampled, but we wouldn't know what the final destination
is either. This is true over the whole path even in the limited domain
and would make debugging very difficult. There are other problems as
well, for instance it might be tempting to allow transport layer
checksum like TCP and UDP to be incorrect while the packet is inflight
(IMO that will also make debugging difficult, it would be better to
maintain a correct checksum on the wire when the destination address
changes similar to how NAT does it). There's also the problem of
filtering these packets at the edge since they don't have a routing
header, I suppose this is one of the motivations to define a new
Ethertype for segment routing but as I mentioned I believe Ethertype
entails a new set of problems.

>
> I also admit that I wonder how common this case is, since the reverse direction traffic either ends up without a soruce route, or ends up with a source route applied by an unknown entity?    Again, if the purpose of the source rotue is to apply policy inside the domain, then it is likely that the specifying entity can pick a suitable decapsualtion point.  Maybe not a symmetric one, but symmetry is a different issue.

Wouldn't that aslo be true of traffic that never leaves the limited
domain? I don't believe there's any requirement for routing headers to
be symmetric and that probably doesn't make a lot of sense anyway with
something like SFC which may be asymmetric anyway. I suppose a
destination might just try to reverse the segment list to send on the
return path, but that may or may not be the right thing to do. FAST
has a concept of reflecting the HBH Option, but I don't see how
reflection could work with routing headers.

Tom

>
> Yours,
>
> Joel
>
> On 10/30/2023 7:54 PM, Tom Herbert wrote:
>
>
>
>
> On Mon, Oct 30, 2023, 4:34 PM Joel Halpern <[e-mail]> wrote:
>>
>> Interesting question about what is supposed to happen with a packet originating in the limited domain, using the CRH to traverse the limited domain, but intending to be sent otuside of the domain after the CRH is exhausted.  I tend to assume that would be done with encapsulation to make sur ethe CRH has to be removed at the domain edge, rather than hoping the edge device gets it right.
>
>
> Joel,
>
> If encapsulation is used then a host would need to know for which destinations it needs to encapsulate, and if it does encapsulate then it needs to the destination address of the encapsulation. It's not obvious that a host would readily know either of those pieces of information.
>
> As for hoping the edge device gets things right, the draft already mentions requirements that edge devices can drop packets with CRH at the egress, so there are already assumptions that the network edge is doing the right thing. Such assumptions are probably going to exist for any protocol that is intended to be restricted to a limited domain.
>
>> However, I grant that the draft does not say that.  It's security discussion is focussed in the case of an external packet entering the limited domain.  While that is more important, the case you describe should also be properly covered.
>
>
> Yes. I think the draft should discuss the handling of packets at the edge with a CRH and segments left == 0. IMO, dropping is too austere as required tunneling would be. Just forwarding could be a security liability. Hence, removing the RH seems reasonable to me.
>
> Anyway, I support adoption of this draft.
>
> Tom
>
>> Yours,
>>
>> Joel
>>
>> On 10/30/2023 7:29 PM, Tom Herbert wrote:
>>
>>
>>
>> On Mon, Oct 30, 2023, 4:14 PM Joel Halpern <[e-mail]> wrote:
>>>
>>> As I expect you knew when you wrote that, I at least do not think that
>>> is a good way to achieve the security properties.   On the one hand, if
>>> the CRH is applied along with an encapsulating IPv6 header, then it will
>>> be removed along with the IPv6 header according to the current specs.
>>> So the final destination of the tunnel takes care of it.  (If the packet
>>> is initially sent and finally received inside the limited domain, then
>>> there is no issue to even discuss.)
>>
>>
>> Joel,
>>
>> Sure, if the packet is tunneled.
>>
>>>
>>> On the other hand, removing the CRH when it is exhausted but still
>>> within the domain has the effect of leaving a packet in an odd place in
>>> the domain with no trace of how it got there.  This does not seem an
>>> operationally desirable behavior.
>>
>>
>> I suggest only to remove it when the packet exits the domain (for case where packet is not tunneled).
>>
>>>
>>> In general, I think removing IPv6 header fields along the way
>>> cintroduces more problems than it solves.  And even your arguments for
>>> doing so do not seem to apply to this case.
>>
>>
>> If packets are always tunneled then it might not be applicable, but I don't believe tunneling should be required (and if it is, people will certainly be complaining about packet overhead for tunnels)
>>
>> Tom
>>
>>>
>>> Yours,
>>>
>>> Joel
>>>
>>> On 10/30/2023 6:39 PM, Tom Herbert wrote:
>>> > On Mon, Oct 30, 2023 at 3:06 PM Joel Halpern <[e-mail]> wrote:
>>> >> I think it is a little subtler than that.  If the operator's rotuer requires that the incoming DA is a ULA before it will look for a CRH, then I believe you are correct.  But there is no such restriction in the document, even if the operator requires that all CRH-FIB entries have ULA IPv6 addresses in the mapping table.
>>> >>
>>> >> There are a number of ways to strengthen the filtering beyond what is specified currently in the draft.  I presume it would be up to the working group to decide which, if any, of the possible enhancements we want to require.  The draft as currently written says that part of the experiment is to determine if the specified filtering is sufficient.  We can of coruse change that once we adopt the draft if we conclude we should.
>>> > One possible enhancement is removing the routing header from packets
>>> > at an egress router when segments left == 0
>>> > (draft-herbert-eh-inflight-removal-01). This prevents leaking the
>>> > segment list beyond the domain.
>>> >
>>> > Tom
>>> >
>>> >> Yours,
>>> >>
>>> >> Joel
>>> >>
>>> >> On 10/30/2023 6:01 PM, Mark Smith wrote:
>>> >>
>>> >> *RFC 4193
>>> >>
>>> >> On Tue, 31 Oct 2023, 08:41 Mark Smith, <[e-mail]> wrote:
>>> >>>
>>> >>>
>>> >>> On Tue, 31 Oct 2023, 05:55 Nick Buraglio, <[e-mail]> wrote:
>>> >>>> I support adoption of this draft and experiment. I would also be
>>> >>>> interested in seeing any code that comes out of it, especially
>>> >>>> something I can run to poke at the filtering tooling, which I think is
>>> >>>> the elephant in the room.
>>> >>>
>>> >>>
>>> >>> It's a baby elephant if a ULA prefix is used for this function.
>>> >>>
>>> >>> May leak into the Internet via a default route, however upsteam should drop it with a BCP38 filter, if you don't drop ULA source and destination packets yourself, as you should be per RFC 4194 operational advice.
>>> >>>
>>> >>> You can't receive any packets with the CRH in them from the Internet if your CRH packets can only have ULA addresses.
>>> >>>
>>> >>>
>>> >>>> nb
>>> >>>>
>>> >>>> On Sun, Oct 29, 2023 at 1:09 PM Ron Bonica
>>> >>>> <rbonica=[e-mail]> wrote:
>>> >>>>> Hi Alvaro,
>>> >>>>>
>>> >>>>> Thanks. I will clean up both issues in the next revision.
>>> >>>>>
>>> >>>>>                                                 Ron
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> Juniper Business Use Only
>>> >>>>> -----Original Message-----
>>> >>>>> From: Alvaro Retana <[e-mail]>
>>> >>>>> Sent: Sunday, October 29, 2023 8:43 AM
>>> >>>>> To: 6man <[e-mail]>; Ron Bonica <[e-mail]>; Jen Linkova <[e-mail]>
>>> >>>>> Cc: [e-mail]
>>> >>>>> Subject: RE: [IPv6] Adoption call for draft-bonica-6man-comp-rtg-hdr
>>> >>>>>
>>> >>>>> [External Email. Be cautious of content]
>>> >>>>>
>>> >>>>>
>>> >>>>> On October 28, 2023 at 7:07:47 PM, Ron Bonica wrote:
>>> >>>>>
>>> >>>>> Ron:
>>> >>>>>
>>> >>>>> Hi!
>>> >>>>>
>>> >>>>>
>>> >>>>> ...
>>> >>>>>>> (1) Limited domain -- what is it? The Introduction says that the CRH
>>> >>>>>>> "Is designed to operate within a limited domain. (See Section 9)." I
>>> >>>>>>> expected Section 9 to include a definition or discussion of "limited
>>> >>>>>>> domain", but one is not present.
>>> >>>>>> [RB] The best definition of a “limited domain” is in RFC 8799. Sadly,
>>> >>>>>> RFC
>>> >>>>>> 8799 is not an IETF consensus document. I can add a reference to it if
>>> >>>>>> you like.
>>> >>>>> The main observation is that the text pointed to Section 9, but there's nothing there about it.  FWIW, I'm ok with you either including a reference to something else, adding text in Section 9, or taking the pointer out.
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> ...
>>> >>>>>>> (2) Incoming Filtering -- from the Security Considerations section:
>>> >>>>> ...
>>> >>>>>>> "MUST NOT accept" and "SHOULD discard" are in normative
>>> >>>>>>> contradiction: it is either required to discard packets containing a
>>> >>>>>>> CRH or it is just recommended.  I can't imagine the cases when it
>>> >>>>>>> would be ok to not discard them.
>>> >>>>>> [RB] The router MUST NOT accept the packet. The Security Consideration
>>> >>>>>> section offers several methods for filtering the packet. The router
>>> >>>>>> SHOULD use the first method, because it causes the least collateral
>>> >>>>>> damage. However, if it can’t do that, it MAY do the second and so forth.
>>> >>>>> Ahh, I see what you mean -- I clearly didn't read the text that way.
>>> >>>>>
>>> >>>>> The MUST NOT, SHOULD or MAY construct is not clear because it gives the impression that the SHOULD clause can be bypassed (with good clause), and the MAY clause is optional -- which could result in no filtering. :-(
>>> >>>>>
>>> >>>>> Suggestion>
>>> >>>>>
>>> >>>>>    SHOULD NOT accept packets received from outside their domain if a
>>> >>>>>    CRH is present and the DA is inside the domain.
>>> >>>>>
>>> >>>>>    The border MAY not filter an incoming packet in which the CRH SL
>>> >>>>>    field has a value of 0.
>>> >>>>>
>>> >>>>>
>>> >>>>> IOW, the only exception is if SL=0.
>>> >>>>>
>>> >>>>> I trust you'll make the logic clear.
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>>> (3) Outgoing Filtering -- also from the Security Considerations section:
>>> >>>>> ...
>>> >>>>>>> I'm not sure why a border router would send a packets with an
>>> >>>>>>> internal DA through an external interface (under normal
>>> >>>>>>> circumstances). I also don't understand why the action is optional. Please explain.
>>> >>>>>> [RB] This packet would be from an external attacker. Under normal
>>> >>>>>> circumstances, it would not exist.
>>> >>>>>>
>>> >>>>>> See above for MUST v SHOULD v MAY
>>> >>>>> Yeah, I misread the text.
>>> >>>>>
>>> >>>>> Should there be any outgoing filtering considerations?
>>> >>>>>
>>> >>>>>
>>> >>>>> Thanks!
>>> >>>>>
>>> >>>>> Alvaro.
>>> >>>>>
>>> >>>>> --------------------------------------------------------------------
>>> >>>>> IETF IPv6 working group mailing list
>>> >>>>> [e-mail]
>>> >>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> >>>>> --------------------------------------------------------------------
>>> >>>> --------------------------------------------------------------------
>>> >>>> IETF IPv6 working group mailing list
>>> >>>> [e-mail]
>>> >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> >>>> --------------------------------------------------------------------
>>> >>
>>> >> --------------------------------------------------------------------
>>> >> IETF IPv6 working group mailing list
>>> >> [e-mail]
>>> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> >> --------------------------------------------------------------------
>>> >>
>>> >> --------------------------------------------------------------------
>>> >> IETF IPv6 working group mailing list
>>> >> [e-mail]
>>> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> >> --------------------------------------------------------------------