[dns-operations] Link-local IP addresses for a resolver?

[Mark Andrews]

> On 25 Sep 2019, at 12:31 pm, Mark Andrews <marka at isc.org> wrote:
> 
> 
> 
>> On 25 Sep 2019, at 11:52 am, John Levine <johnl at taugh.com> wrote:
>> 
>> In article <9CA43B29-1345-4FD4-9766-36C624589DA0 at isc.org> you write:
>>> 	         ISP SITE <-> CPE <-> CUSTOMER SITE
>>> 
>>> The CPE is a SITE boundary.  It is also a Link-Local Boundary. ULA source
>>> packets DO NOT cross the CPE by default it the CPE is properly configured.
>> 
>> Really?  Are you sure you're not confusing LL and ULA addresses?  Why
>> would CPE filter ULA addresses?  In the normal case where the ISP
>> provides the customer with a default route, they're like global
>> addresses.
> 
> Because the CPE is a site boundary.
> 
> RFC 7084. Basic Requirements for IPv6 Customer Edge Routers
> 
> 3.2.1
>                            The IPv6 CE router defaults to acting as the
>   demarcation point between two networks by providing a ULA boundary, a
>   multicast zone boundary, and ingress and egress traffic filters.
> 
> Which is referenced in the CableLabs documents.

and then there is:

RFC 6092           Simple Security in IPv6 Gateway CPE

   REC-7: By DEFAULT, packets with unique local source and/or
   destination addresses [RFC4193] SHOULD NOT be forwarded to or from
   the exterior network.

CableLabs® Access Network Independent

Standalone Router Specification CL-SP-sRouter-I02-170111

The sRouter MUST enable a stateful firewall by default. In particular, the sRouter SHOULD support functionality sufficient for implementing the set of recommendations in [RFC 6092], section 4. The sRouter MUST support ingress filtering in accordance with BCP 38 [RFC 2827]. Management and configuration of the stateful firewall may be by either or both the operator or the end user; however, the firewall SHOULD be remotely configurable by the operator. All features of the firewall MUST be able to be remotely enabled or disabled by the operator. Implementation method of the firewall by vendors is beyond the scope of the document.


Annex D [RFC 6092] Simple Security Recommendations (Normative)

This section categorizes the recommendations from [RFC 6092] into recommendations for sRouter devices. While the RFC provides a good foundation for the development of a stateful inspection packet filtering firewall, it is not without omission and not all of its recommendations conform with best practices for cable networks. Additionally, the cable industry has developed several security mechanisms that supersede those provided in the recommendations. Where conflicts or recommendations other than those supplied by the RFC occur, they are called out explicitly.

D.1 Summary of Simple Security Requirements

This section provides a quick reference to the [RFC 6092] recommendations required by sRouter.

Critical - see Table 15
REC-3, REC-4, REC-5, REC-7, REC-10, REC-12, REC-14, REC-16, REC-18, REC-19, REC-21, REC-22, REC- 23, REC-24, REC-25, REC-31, REC-32, REC-35, REC-36, REC-37, MSO-REC.


> 
>> R's,
>> John
>> _______________________________________________
>> dns-operations mailing list
>> dns-operations at lists.dns-oarc.net
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: marka at isc.org
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org