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
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:[email protected]] On Behalf Of C. M. Heard
Sent: Wednesday, October 4, 2017 11:08 PM
To: OPSEC <[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
