Protection from leaking inwards is required by the RFCs as far as I know.
Note that there are multiple ways to apply such protection. It is
sufficient for the domain only to block packets addressed to its own SID
prefixes. If the domain is using SRv6 without compression or reduction,
it seems acceptable to block all packets with SRH. After all, they
should not be occurring. But we do not tell operators how to perform
the filtering. It is up to them what they do.
Yours,
Joel
On 10/10/2022 9:49 AM, Robert Raszuk wrote:
All,
So protection not to leak outside the domain is all cool.
But we now see a notion of "leaking inwards" which is exactly my
observation .. as if applied by any transit will kill SRv6
"limited domain" interconnect over Internet.
Best,
R.
On Mon, Oct 10, 2022 at 3:45 PM Eric Vyncke (evyncke)
<evyn...@cisco.com> wrote:
Hi Joel,
So, your sentence below "We require, per the RFC, blocking SRH
outside of the limited domain for many reasons" was to be read as
"do not leak SRH outside your own domain" ? If so, I guess we
agree for 99%, the remaining 1% seems to be related to Robert's
use case, which is valid in my mind. All in all, I really hope
that IPv6 packets with extension headers could travel safely the
global public Internet without being dropped, hence my original reply.
And of course, this email and the previous one are written without
any hat and are not related to Suresh's I-D.
Regards
-éric
*From: *Joel Halpern <j...@joelhalpern.com>
*Date: *Monday, 10 October 2022 at 15:36
*To: *Eric Vyncke <evyn...@cisco.com>, Robert Raszuk
<rob...@raszuk.net>
*Cc: *6man <i...@ietf.org>, SPRING WG List <spring@ietf.org>
*Subject: *Re: [spring] 6MAN WGLC: draft-ietf-6man-sids
Eric, you seem to be objecting to something I did not say. I have
not asked, and do not expect, for the document to mandate or even
suggest that arbitrary domains should drop packets with SRH. I
will note that given that SRH is explicitly for limited domains,
an operator who chooses to drop such packets is well within his
rights. And I am told there are such operators. But that is not
what I asked for this document.
What I asked, and I believe Suresh has agreed to, and I beleive
the WG supports, is that the document note that an operator using
SRv6 who does not use the allocated SID, and block the allocated
SID at his boundaries, has to be more careful to define his
ingress and egress filters to comply with the existing RFCs which
require that SRv6 not leak inwards or outwards.
Robert objected to that requirement. And propounde3d a use case
that he says he needs. I pointed out that the use case violates
the RFC. And then pointed out one of the many reasons why the
IETF has put in the requirement which he wants to violate.
Yours,
Joel
On 10/10/2022 5:57 AM, Eric Vyncke (evyncke) wrote:
Hmmm I really wonder why a transit network should look into my
packets (to check for SRH) and decide to drop my packets;
assuming of course that my packets are not damaging the
transit network (like some hop-by-hop years ago) or attempting
to trick my network (anti-spoofing or using transit provider
own SID -- both being layer-3 filters BTW).
-éric
*From: *ipv6 <ipv6-boun...@ietf.org>
<mailto:ipv6-boun...@ietf.org> on behalf of Joel Halpern
<j...@joelhalpern.com> <mailto:j...@joelhalpern.com>
*Date: *Sunday, 9 October 2022 at 16:38
*To: *Robert Raszuk <rob...@raszuk.net> <mailto:rob...@raszuk.net>
*Cc: *6man <i...@ietf.org> <mailto:i...@ietf.org>, SPRING WG
List <spring@ietf.org> <mailto:spring@ietf.org>
*Subject: *Re: [spring] 6MAN WGLC: draft-ietf-6man-sids
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> 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://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>> 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
> Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6
>
--------------------------------------------------------------------
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
