Re: [OPSEC] WGLC for draft-ietf-opsec-ipv6-eh-filtering-03

[joel jaeggli <[e-mail]>]

On 10/5/17 11:04, Ron Bonica wrote:
> Mike,
> 
>  
> 
> I think that you just struck the note that Fernando and I missed.
> Transit routers filter extension headers for one of the following reasons:
> 
>  
> 
> -          To protect themselves (as in RFC 6192)
> 
> -          To protect downstream devices
> 
>  
> 
> Therefore, the document should contain two clearly marked sections, one
> regarding EH filtering policies that protect the transit router and one
> regarding EH filtering policies that protect downstream devices.
> 
>  
> 
> The first section can:
> 
>  
> 
> -          Be very short (2 pages max)
> 
> -          Be guided largely by RFC 8200
> 
> -          Speak with some degree of authority (while still INFORMATIONAL)
> 
>  
> 
> The second section should begin with a discussion of the relationship
> between the transit router and the downstream devices. Let’s assume that
> the transit router belongs to an ISP, while downstream devices fall into
> the following three classes:
> 
>  
> 
> 1)      Belong to the ISP
> 
> 2)      Belong to parties who want to be protected by the ISP (e.g., its
> customers)
> 
> 3)      Belong to other parties

Traffic on a isp either the isp's traffic or a customers (customer is
transitive, a customer of a customer is customer traffic). traffic which
neither to a customer or the isp is party to unwanted, whether it's
there due to malice or intention.

what services one offers to a customer seems entirely like a contractual
detail.

strictly speaking the destination of a packet may not be the destination
address in the ip header as when the TTL is lowered or when hop by hop
options are employed.

>  
> 
> Therefore, the transit router MAY discard packets that pose a threat to
> the first two classes of downstream device, but MUST NOT discard packets
> that are required by the third class of downstream device.

>  
> 
> From this point, we formulate a policy that **might** satisfy the above
> mentioned requirement. We mark this policy with the following caveats:
> 
>  
> 
> -          It is a best guess
> 
> -          If the policy is too permissive, downstream devices belonging
> to the ISP and those who it protects will not receive all of the
> protection possible
> 
> -          If the policy is too restrictive, downstream devices
> belonging to other parties will experience collateral damage
> 
> -          One size doesn’t fit all
> 
>  
> 
> If we were to rework the document into this shape, would it address your
> concerns.
> 
>  
> 
>                                                                Ron
> 
>  
> 
>  
> 
>  
> 
> *From:*OPSEC [mailto:[e-mail]] *On Behalf Of *C. M. Heard
> *Sent:* Wednesday, October 4, 2017 11:08 PM
> *To:* OPSEC <[e-mail]>
> *Subject:* Re: [OPSEC] WGLC for draft-ietf-opsec-ipv6-eh-filtering-03
> 
>  
> 
> On Thu, 5 Oct 2017 11:10:06 +1300, Brian E Carpenter wrote:
> 
>> On 05/10/2017 02:12, Joe Touch wrote:
> 
>> 
> 
>>> On 9/29/2017 1:12 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> 
>>>> 
> 
>>>> This is to open a two week WGLC
> 
>>>> for https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-03
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dopsec-2Dipv6-2Deh-2Dfiltering-2D03&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=pDMOABefbu8JHcDH3rcHvzOABmSLo8X0KGbiPvLqnpA&s=M7xHnDuuJxhA21iLVXO_-AZjAhvXwgaN__niQRcoBwc&e=>.
> 
>>>> 
> 
>>> 
> 
>>> I do not agree with the claims of this document. It "informationally"
> 
>>> advises against support for key IPv6 capabilities and undermines the
> 
>>> extensibility of IPv6 by making recommendations about discarding
> 
>>> currently unassigned codepoints.
> 
>> 
> 
>> Here's the problem, Joe. It's a fact of life that many firewalls
> 
>> discard a lot of stuff that they shouldn't - that's why we wrote
> 
>> RFC 7045 - but in the real world, operators blunder around based
> 
>> on folklore and vendors' defaults. We can't change any of that, but
> 
>> we can try to issue sensible advice that, overall, will limit the
> 
>> resulting breakage. IMHO this document, positioned correctly as
> 
>> Informational, will do that: on balance, it makes the world a better
> 
>> place.
> 
>  
> 
> I am afraid that I do not agree that the document, in its present form,
> 
> will do that. It says:
> 
>  
> 
>    The filtering policy typically depends on where in the network such
> 
>    policy is enforced: when the policy is enforced in a transit network,
> 
>    the policy typically follows a "black-list" approach, where only
> 
>    packets with clear negative implications are dropped.  On the other
> 
>    hand, when the policy is enforced closer to the destination systems,
> 
>    the policy typically follows a "white-list" approach, where only
> 
>    traffic that is expected to be received is allowed.  /_The advice in_/
> 
> /_   this document is aimed only at transit routers that may need to_/
> 
> /_   enforce a filtering policy based on the EHs and IPv6 options a packet_/
> 
> /_   may contain, following a "black-list" approach, and hence is likely_/
> 
> /_   to be much more permissive that a filtering policy to be employed_/
> 
> /_   e.g. at the edge of an enterprise network._/  The advice in this
> 
>    document is meant to improve the current situation of the dropping of
> 
>    packets with IPv6 EHs in the Internet [RFC7872
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7872&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=pDMOABefbu8JHcDH3rcHvzOABmSLo8X0KGbiPvLqnpA&s=KqV5UiI6Ie51NtocuTw9zMCtHX8aMheboGCPVCzdepA&e=>].
> 
> 
> while at the same time promoting a **/_default deny_/** policy with
> 
> respect to unrecognized options and unrecognized extension headers.
> 
> That is antithetical to the mission of a **/_transit router_/**, which
> 
> is to get packets transparently from point A to point B. It is
> 
> especially egregious to dispense this advice for unrecognized
> 
> extension headers, since they are indistinguishable from unrecognized
> 
> transport protocols. If these things are blocked by **/_transit routers_/**
> 
> it becomes  impossible to deploy any new options or transport protocols.
> 
> But we already know that, don't we?
> 
>  
> 
> If we want to give constructive advice that really will make the
> 
> world a better place, we should:
> 
> 
> 1.) Advise operators of **/_transit routers_/** to be transparent to
> 
> everything other than the Hop-by-Hop extensions header, and provide
> 
> detailed advice on what to do (based on the updates in RFC 8200)
> 
> about Hop-by-Hop options. The default should be IGNORE unless there
> 
> is an option you need to process.
> 
> 
> 2.) Reserve all the detailed filtering advicee for operators of
> 
> firewalls, enterprise routers, and other systems whose mission it
> 
> is to protect the end systems behind them (or to prevent misbehavior
> 
> by said end systems). A default deny for unrecognized stuff is not
> 
> unreasonable for such systems.
> 
> 
> 3.) Remind implementors of the following requirement from RFC 7045:
> 
> 
>    Forwarding nodes MUST be configurable to allow packets containing
> 
>    unrecognised extension headers, but the default configuration MAY
> 
>    drop such packets.
> 
> 
> and add similar advice for options.
> 
> 
> Thanks and regards,
> 
> 
> Mike Heard
> 
> 
> _______________________________________________
> OPSEC mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsec
>