Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

[Mark Smith <[e-mail]>]

Hi Jingrong,

On Sat, 16 May 2020, 18:18 Xiejingrong (Jingrong), <[e-mail]>
wrote:

> Hi Mark
>
> Thanks for the introduction of RFC4193.
>
> The RFC8754 boundary security mechanism is still unique IMO.
>
> The IPv6 ULA is just a candidate element of the mechanism, instead of the
> mechanism itself.
>

So the ULA address space inherently has a lot of the security properties of
the measures described in RFC8754, and that is by design.

If packets with ULA DAs leak because of a default route pointing out of the
local network, they'll be dropped by the first default free Internet router
they encounter.

By default, the ULA prefix of fc00::/7 and longer are not supposed to be
advertised to or accepted by external networks, unless there is an
agreement to route their ULA /48s between them, so interdomain routing of
ULAs is not the default, unlike IPv6 public GUA addresses.

Packets that leak with a ULA source addresses will be caught by an upstream
BCP38 source address filter.

ACLs should be used with ULA address spaces, however they only add to the
existing inherent ULA security properties. ACLs used with global IPv6
addresses would be the only security measure, making the ACL
mechanism/enforcement a single point of failure.

A lot of things have to go wrong for a packet that leaks with a ULA source
or destination address to cause a negative effect on an external node. If
that is still a concern, AH could be used so the packet fails
authentication when it arrives at the external node, or ESP could be used
so the payload looks like a bunch of random bits.

The intended forwarding and reachability domain for a network 's ULA prefix
is the local network only, in contrast to global IPv6 GUA addresses where
the forwarding and reachability domain is anywhere on the Internet.

So the ULA address space is a natural fit for traffic that is intended to
be constrained to the local network, such as this case for the local
network imposed tunnelling encapsulation to add information via the CRH.

Regards,
Mark.

>
>
> Thanks
>
> Jingrong
>
>
>
> *From:* Mark Smith [mailto:[e-mail]]
> *Sent:* Saturday, May 16, 2020 11:05 AM
> *To:* Xiejingrong (Jingrong) <[e-mail]>
> *Cc:* Bob Hinden <[e-mail]>; IPv6 List <[e-mail]>
> *Subject:* Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
>
>
>
>
>
> On Sat, 16 May 2020, 12:43 Xiejingrong (Jingrong), <[e-mail]>
> wrote:
>
> Hi WG,
> My main concern is the security aspect.
> It has been in discussion in another thread "Questions regarding the
> security mechanisms".
> Hope it could be carefully considered and discussed, especially there is
> the painful example of RH0 deprecated by RFC5095.
> There is of course RFC6554 and RFC8754 which is designed later after the
> deprecation and which could be carefully learned and referenced.
>
> Ole said and repeated that "In fact I don't see how the CRH draft prevents
> the RFC5095 attack to happen inside of the CRH limited domain."
> https://mailarchive.ietf.org/arch/msg/ipv6/UyXsGeI7IDM9_Z1lipG70gIzTLY/
>
> I was even worried about whether such attack could happen from Internet if
> there is no mandatory and deployable security mechanism on the wide
> boundary of a network.
>
> Brian observed the "limited-domain" pattern that is widely used in modern
> protocol design and put the heavy emphasis on the domain boundary security.
> https://tools.ietf.org/html/draft-carpenter-limited-domains-13
>
> The RFC8754 section 5.1 IMO is the only boundary security mechanism
> operable/controllable/deployable so far I've seen for an IPv6 network that
> is widely connected to Internet.
> Please correct me if you have some other better ones.
> https://tools.ietf.org/html/rfc8754
>
>
>
> RFC4193, a limited domain and local network only address space.
>
>
>
> See also slide 50.
>
>
>
> "Getting IPv6 Private Addressing Right"
>
>
> https://www.ausnog.net/sites/default/files/ausnog-2019/presentations/2.3_Mark_Smith_AusNOG2019.pdf
>
>
>
>
>
>
>
>
>
> BTW:
> I don't think it deserved to throw away everything that SRv6/SRH have
> worked out (e.g., the RFC8754 section 5.1) just to claim the independence
> on them.
> I have an I-D of IPv6-EH using many of the design patterns of SRv6/SRH
> with a reference to RFC8754 but I still insist and show its independent
> part.
>
> Thanks and Best wishes,
> Jingrong
>
> -----Original Message-----
> From: ipv6 [mailto:[e-mail]] On Behalf Of Bob Hinden
> Sent: Saturday, May 16, 2020 6:14 AM
> To: IPv6 List <[e-mail]>
> Cc: Bob Hinden <[e-mail]>
> Subject: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
>
> This message starts a two-week 6MAN call on adopting:
>
>  Title:          The IPv6 Compact Routing Header (CRH)
>  Authors:        R. Bonica, Y. Kamite, T. Niwa, A. Alston, L. Jalil
>  File Name:      draft-bonica-6man-comp-rtg-hdr-21
>  Document date:  2020-05-14
>
>  https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr
>
> as a working group item. Substantive comments regarding adopting this
> document should be directed to the mailing list.  Editorial suggestions can
> be sent to the authors.
>
> Please note that this is an adoption call, it is not a w.g. last call for
> advancement, adoption means that it will become a w.g. draft.  As the
> working group document, the w.g. will decide how the document should change
> going forward.
>
> This adoption call will end on 29 May 2020.
>
> The chairs note there has been a lot of discussions on the list about this
> draft.   After discussing with our area directors, we think it is
> appropriate to start a working group adoption call.  The authors have been
> active in resolving issues raised on the list.
>
> Could those who are willing to work on this document, either as
> contributors, authors or reviewers please notify the list.   That gives us
> an indication of the energy level in the working group
> to work on this.
>
> Regards,
> Bob and Ole
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>