On 10-Oct-22 05:15, Robert Raszuk wrote:
Hi Suresh,
> One thing that is for certain is that this draft (draft-ietf-6man-sids) does
not specify any
> restrictions or provide any recommendations on filtering if this allocated
prefix is not used
OK many thx for this clarification I was not clear on this hence comments made.
In general I would consider such a block to be part of my infra and naturally
do filter on ingress.
However one point still remains unclear. What if a distributed domain
interconnected over the Internet is using a mix of these new allocated prefixes
within each site and publicly routable IPv6 addressing to jump between sites
within SRH ?
Then still blind filtering based on SRH presence would be a bad thing.
Easily avoided by another layer of encapsulation, surely? Personally I would
want to do that, and to use an encrypted encapsulation, to make sure that the
SR domain is not penetrated.
Or to quote RFC8402: "By default, SR operates within a trusted domain. Traffic MUST
be filtered at the domain boundaries." The only way a distributed SR domain can
provide that trust and filtering is by encrypted encapsulation, as far as I can see.
Not sure if this could be reflected in the document with a bit more precision
...
It doesn't, IMHO, belong in this draft. It really looks like an update to 8402:
how to build a distributed SR domain.
Brian
Cheers,
R.
On Sun, Oct 9, 2022 at 6:01 PM Suresh Krishnan <suresh.krish...@gmail.com
<mailto:suresh.krish...@gmail.com>> wrote:
Hi Robert,
Thanks for your further clarifications on the topic. I think I do
understand your concern now based on your discussions with Joel and Brian. If I
understand it correctly, the concern exists whether or not someone is using
their own allocated address block or if they use the prefix allocated in this
draft (Please correct me if this is not right). One thing that is for certain
is that this draft (draft-ietf-6man-sids) does not specify any restrictions or
provide any recommendations on filtering if this allocated prefix is not used,
and that would be covered by what Section 5.1 of RFC8754 states.
The generic concern you mentioned is something that needs to be discussed
in the scope of the operational guidelines draft. I certainly do see this as a
polarizing topic between the transit operators who would carry SR traffic and
those who do not wish to do so and as you say below we can only provide
recommendations.
Regards
Suresh
On Oct 9, 2022, at 11:42 AM, Robert Raszuk <rob...@raszuk.net
<mailto:rob...@raszuk.net>> wrote:
Joel,
> You can't tell a packet validly from another piece of your domain from a
packet being
> sourced by an attacker and spoofing its source address.
Please rest assured that it is way easier to filter unplanned actions
carried in SRH inserted by an attacker than to protect all end systems from
globally reachable IPv6 destinations.
So the former is a "bad idea" and the latter great one ... very interesting
observation.
Nevertheless it is great that all you can do is to write an operational
recommendation. What will be actually done in the production networks is beyond
your control.
Cheers,
R.
On Sun, Oct 9, 2022 at 5:26 PM Joel Halpern <j...@joelhalpern.com
<mailto:j...@joelhalpern.com>> wrote:
It is accurate that transits that do not use SRH do not need to worry
about SRH. And arguably, even those that do use SRH do not need to worry about
SIDs not in their usage ranges. Getting that right is non-trivial, but...
The point in this particular case is that connecting pieces of your
domain in the clear over the Internet puts you at significant risk. You can't
tell a packet validly from another piece of your domain from a packet being
sourced by an attacker and spoofing its source address. So if you deploy the
use case you have described, that causes you to object to other folks filtering
SRH, you are doing something that the IETF has good reason to say is a bad idea.
So folks who filter the SRH, even if you do not like it, are doing what
we told them to do. SRv6 was approved only for limited domains.
While you have said you do not like limited domains, and there is a lot
of ambiguity and bending of rules around such things, it does seem appropraite
and legitimate for us to write in restrictions based on that property that the
RFCs require.
Yours,
Joel
On 10/9/2022 10:49 AM, Robert Raszuk wrote:
Joel,
> it turns SRH into a powerful attack vector
Really ?
How is this possible if IPv6 destination address of the packet does not
belong to the block of locally allocated range used as ASN's infra subnet ? I
am talking about a pure IPv6 transit case.
Isn't this the case that SRH should be examined by the node listed in
the destination address of the packet ?
And of course it is common and very good practice to filter any
external attempt to reach my own address blocks use for management and node
configuration. But this is way more granular then to say kill all packets
entering my network which have SRH.
Thx,
R.
On Sun, Oct 9, 2022 at 4:37 PM Joel Halpern <j...@joelhalpern.com
<mailto:j...@joelhalpern.com>> wrote:
We require, per the RFC, blocking SRH outside of the limited domain
for many reasons.
One example is that it turns SRH into a powerful attack vector,
given that source address spoofing means there is little way to tell whether an
unencapsulated packet actually came from another piece of the same domain.
So yes, I think making this restriction clear in this RFC is
important and useful.
Yours,
Joel
On 10/8/2022 5:07 PM, Robert Raszuk wrote:
Hi Brian,
Completely agree.
One thing is not to guarantee anything in respect to forwarding
IPv6 packets with SRH (or any other extension header) and the other thing is to
on purpose recommending killing it at interdomain boundary as some sort of evil.
Cheers,
R.
On Sat, Oct 8, 2022 at 9:51 PM Brian E Carpenter
<brian.e.carpen...@gmail.com <mailto:brian.e.carpen...@gmail.com>> wrote:
Robert,
> If there is any spec which mandates that someone will drop my
IPv6 packets only because they contain SRH in the IPv6 header I consider this an
evil and unjustified action.
The Internet is more or less opaque to most extension headers,
especially to recently defined ones, so I don't hold out much hope for SRH
outside SR domains.
https://www.rfc-editor.org/rfc/rfc9098.html
<https://www.rfc-editor.org/rfc/rfc9098.html>
https://datatracker.ietf.org/doc/html/draft-elkins-v6ops-eh-deepdive-fw
<https://datatracker.ietf.org/doc/html/draft-elkins-v6ops-eh-deepdive-fw>
Regards
Brian Carpenter
On 09-Oct-22 07:52, Robert Raszuk wrote:
> Hi Joel,
>
> I was hoping this is apparent so let me restate that I do not buy into
"limited domain" business for SRv6.
>
> I have N sites connected over v6 Internet. I want to send IPv6 packets
between my "distributed globally limited domain" without yet one more encap.
>
> If there is any spec which mandates that someone will drop my
IPv6 packets only because they contain SRH in the IPv6 header I consider this an
evil and unjustified action.
>
> Kind regards,
> Robert
>
> On Sat, Oct 8, 2022 at 7:40 PM Joel Halpern <j...@joelhalpern.com
<mailto:j...@joelhalpern.com> <mailto:j...@joelhalpern.com
<mailto:j...@joelhalpern.com>>> wrote:
>
> Robert, I am having trouble understanding your email.
>
> 1) A Domain would only filter the allocated SIDs plus
what it chooses to use for SRv6.
>
> 2) Whatever it a domain filters should be irrelevant to
any other domain, since by definition SRv6 is for use only within a limited
domain. So as far as I can see there is no way a domain can apply incorrect
filtering.
>
> Yours,
>
> Joel
>
> On 10/8/2022 3:16 AM, Robert Raszuk wrote:
>> Hi Suresh,
>>
>> NEW:
>> In case the deployments do not use this allocated
prefix additional care needs to be exercised at network ingress and egress points so
that SRv6 packets do not leak out of SR domains and they do not accidentally enter SR
unaware domains.
>>
>>
>> IMO this is too broad. I would say that such ingress
filtering could/should happen only if dst or locator is within locally
configured/allocated prefixes. Otherwise it is pure IPv6 transit and I see no harm
not to allow it.
>>
>> Similarly as stated in Section 5.1 of RFC8754
packets entering an SR domain from the outside need to be configured to filter out
the selected prefix if it is different from the prefix allocated here.
>>
>>
>> Again the way I read it this kills pure IPv6 transit for
SRv6 packets. Why ?
>>
>> (Well I know the answer to "why" from our endless
discussions about SRv6 itself and network programming however I still see no need to mandate in
any spec to treat SRv6 packets as unwanted/forbidden for pure IPv6 transit.)
>>
>> Thx,
>> R.
>
>
>
--------------------------------------------------------------------
> IETF IPv6 working group mailing list
> i...@ietf.org <mailto:i...@ietf.org>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
<https://www.ietf.org/mailman/listinfo/ipv6>
>
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
i...@ietf.org <mailto:i...@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
<https://www.ietf.org/mailman/listinfo/ipv6>
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
i...@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
