> 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 <wangai...@tsinghua.org.cn>
>>>> *发送时间：* 2023-07-14 11:19
>>>> *收件人：* 'Alvaro Retana' <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
>>>> <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
>>>> listspring@ietf.orghttps://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
