On Mon, May 22, 2023 at 10:53 AM Michael Richardson <mcr+i...@sandelman.ca> wrote:
> > David Farmer <farmer=40umn....@dmarc.ietf.org> wrote: > > "permissionless innovation." That being said, we MUST balance these > > multiple priorities. which means we can not completely sacrifice > > "permissionless innovation" to "security" and "privacy" either. > > +1 > > > 1. Certain EH constructs SHOULD never be allowed; we need reasonable > > and practical limits; I think Tom's draft makes significant progress > > here. 2. Certain EHs SHOULD be allowed in certain places and SHOULD > > NOT be allowed in others; this thread is at least a good starting > point > > for some recommendations along these lines. 3. Certain EHs almost > > always need to be allowed; these need to be enumerated similarly to > RFC > > 4890 for ICMPv6. > > I think that many of us are still reeling from default configuration of > certain "firewalls" that banks seemed like, which dropped packets > containing > ECN, and TCP options, and made it very very difficult to deploy new things. > Even when at the IETF standards level... (so "innovation with permission") > So, I think we need "permissionless innovation" at the Internet level. Nevertheless, that doesn't mean "innovation with permission" isn't appropriate in some or even many situations. For example, in a situation involving public safety, like a nuclear reactor or a missile control system. We can all agree that "permissionless innovation" isn't necessarily appropriate in situations like these. > > Dropping EHs just because they are unknown, especially by transit > > providers, probably isn't appropriate in most situations. Dropping > > unknown EHs by a host or by a middlebox very close to the host could > be > > appropriate, at least in some situations. Nevertheless, that doesn't > > mean there are no EHs that it is appropriate for transit providers to > > drop. > > I guess I'd be okay if it were the EH itself that was dropped, but I > suspect > it's still the entire packet. I don't even really want to drop the EH, so > much as write over it with an EH that is blank. I don't think that's a > defined action. > If it's not ok to add an EH on the fly, why should it be ok to remove or blank it out? We only allow relatively minor alterations to EHs on the fly, removing or completely blanking them out seems too far. > > third-party server, often referred to as firewall traversal. > Similarly, > > we should think about techniques for hosts wanting the communicate > > using EHs that are not allowed on the network path between them. > Maybe > > call this EH traversal, and it likely involves a tunnel or > > encapsulating the packet with the unknown EHs between the two > > hosts. I'll note that adding EHs in flight is not allowed, and a > common > > technique is to add a new IPv6 header with the new EHs encapsulating > > the old packet. > > Hmm. That's an interesting idea. > -- =============================================== David Farmer Email:far...@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================
_______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec
