You may not subscribe to the notion of limited domains. But the RFCs
do. Hence, the WG is required to do so. An operator can of course do
anything they want, and they choose their risks. But IETF
standardization work is subject to the restrictions we as a community
agree to.
Yours,
Joel
On 7/14/2023 12:25 PM, Robert Raszuk wrote:
> then anyone, almost anywhere in the Internet, can inject such packets.
Sure can. And just like without SRv6 I am protecting my hosts from
such injections.
See SRv6 has a very broad range of use cases. But it does not promise
a secure and encrypted pipe (at least last time I checked). There are
better protocols focusing just to do that.
So imagine I want to enhance my packets between v6 speaking hosts with
demux value so when the packet arrives it goes to its own dedicated
namespace. And as before I am protecting such namespaces from attacks
the same way I protect my default namespace (as example I do have on
secure machines a whitelisted set of rules who can talk to me directly).
That is why I never subscribed to this notion of limited domain in
respect to building SRv6 walls :)
Cheers,
Robert
On Fri, Jul 14, 2023 at 6:15 PM Joel Halpern
<jmh.dir...@joelhalpern.com> wrote:
If a deployment of SRv6 uses unsecured tunnels as a means to
deliver SRv6 packets between pieces of the domain, then anyone,
almost anywhere in the Internet, can inject such packets. That is
not a limited domain. It is a wide open domain.
Yours,
Joel
On 7/14/2023 12:01 PM, Robert Raszuk wrote:
Why would you expect this to always unconditionally use "secure
tunnels" ? For lot's of applications basic encapsulation is
sufficient. Note that I mentioned the case where my sites are
connected over ISP not the Internet.
Besides if there is concern about data protection or data
integrity lot's of applications use app level encryption so
asking for transport tunnel security would be redundant at best.
Thx,
R.
On Fri, Jul 14, 2023 at 5:42 PM Joel Halpern
<j...@joelhalpern.com> wrote:
If they want to specify in the draft that the CPE are
operator managed by a single operator, and that they use
secure tunnels (not just arbitrary overlay) between the BRAS
then we can as a WG see if that suffices. But the draft
doesn't currently say that.
Yours,
Joel
On 7/14/2023 11:40 AM, Robert Raszuk wrote:
Joel,
Limited domain (if you will) can be also build in
the overlay - unless you point me to any standards track RFC
which says otherwise. If I connect over ISP with v6 I can
run my own limited domain over such ISP between hosts in my
sites.
Of course ISP may recognize that I am actually sending v6
packets with extension headers and drop those ... but
this is not a concern for this thread nor for IETF. In such
a case I will would switch an ISP :)
Cheers,
R.
On Fri, Jul 14, 2023 at 5:33 PM Joel Halpern
<j...@joelhalpern.com> wrote:
Nope.
The host case for SRv6 is for hosts run by the operator
within their domain. 8986 explicitly requires that SRv6
be used only within a limited domain.
It is clear from other comments that you do not like
this restriction. That is your priviledge as an
individual. But IETF work has to respect the restriction.
Yours,
Joel
On 7/14/2023 11:28 AM, Robert Raszuk wrote:
Joel,
*Point 1: *
Reading RFC8986 I see in section 4.16.2 clear
definition of SRv6 running on user hosts.
/One of the applications of the USP flavor is when a
packet with an SRH is destined to an /
/application on hosts with smartNICs ("Smart Network
Interface Cards") implementing /
/SRv6. The USP flavor is used to remove the consumed
SRH from the extension header /
/chain before sending the packet to the host.
/
*Point 2: *
*
*
If two hosts want for whatever reason to use SRv6 over
the provider's IPv6 underlay (and they may possibly
benefit from DHCP allocation of locators) they can
happily do so and I see nowhere in any SRv6 spec any
mandate which would state a word against such
deployment model.
Thx,
Robert
PS, This entire notion of "limited domain" is as you
very well know the history is not a very technical
thing ...
On Fri, Jul 14, 2023 at 5:08 PM Joel Halpern
<j...@joelhalpern.com> wrote:
Speaking as an individual participant, it seems to
me that the description of using CPE as SRv6
endpoints needs to state explicitly and clearly
that this assumes that the CPE are managed by the
access operator, and that all of the relevant
endpoints are part of a single operator / domain.
Otherwise, this usage violates the base rules for SRv6.
Personally, I would like to see this fixed before
adoption completes.
Yours,
Joel
On 7/14/2023 9:44 AM, Joel Halpern wrote:
I probably need to re-read the draft. Does the
draft assume the CPE is part of the operator
domain? Remember that SRv6 MUST be used ONLY
within a limited domain?
Yours,
Joel
On 7/14/2023 2:22 AM, Weiqiang Cheng wrote:
Hi Aijun,
Thank you very much for your comments.
We will add some text to describe that the CPE
utilizes locators obtained through DHCP to
provide differentiated services.
Best Regards
Weiqiang Cheng
*发件人：* Aijun Wang
<mailto:wangai...@tsinghua.org.cn>
*发送时间：* 2023-07-14 11:19
*收件人：* 'Alvaro Retana'
<mailto:aretana.i...@gmail.com>; spring@ietf.org
*抄送：*
draft-cheng-spring-distribute-srv6-locator-by-d...@ietf.org;
spring-cha...@ietf.org
*主题：* 答复: [spring] spring WG Adoption Call
for
draft-cheng-dhc-distribute-srv6-locator-by-dhcp
Support its adoption.
It will be more convincible to add some
descriptions in the document that the CPE
itself needs to obtain different IPv6 address
that can differentiate the services that it
can provide.
Best Regards
Aijun Wang
China Telecom
-----邮件原件-----
发件人: spring-boun...@ietf.org
[mailto:spring-boun...@ietf.org
<mailto:spring-boun...@ietf.org>] 代表 Alvaro
Retana
发送时间: 2023年7月5日 20:00
收件人: spring@ietf.org
抄送:
draft-cheng-spring-distribute-srv6-locator-by-d...@ietf.org;
spring-cha...@ietf.org
主题: [spring] spring WG Adoption Call for
draft-cheng-dhc-distribute-srv6-locator-by-dhcp
Dear WG:
This message starts a two-week adoption call
for
draft-cheng-dhc-distribute-srv6-locator-by-dhcp,
ending on July/19.
It "describes the method of assigning
locators to SRv6 Endpoints through DHCPv6".
https://datatracker.ietf.org/doc/draft-cheng-spring-distribute-srv6-locator-by-dhcp/
Please review the draft and consider whether
you support its adoption by the WG. Please
share any thoughts with the list to indicate
support or opposition -- this is not a vote.
If you are willing to provide a more in-depth
review, please state it explicitly to give
the chairs an indication of the energy level
in the working group willing to work on the
document.
WG adoption is the start of the process. The
fundamental question is whether you agree the
proposal is worth the WG's time to work on
and whether this draft represents a good
starting point. The chairs are particularly
interested in hearing the opinion of people
who are not authors of the document.
Thanks!
Alvaro (for the Chairs)
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
