Re: [IPv6] draft-ietf-6man-hbh-processing WGLC comments

[Mike Simpson <[e-mail]>]

Answer below. 

> On 25 Aug 2023, at 09:52, Toerless Eckert <[e-mail]> wrote:
> 
> Inline.
> 
> Btw: Is there a github ? Would make it easier to address multiple smaller
> textual points individually and discuss them.
> 
>> On Wed, Aug 23, 2023 at 02:10:11PM +0100, Gorry Fairhurst wrote:
>>> On 22/08/2023 18:32, Toerless Eckert wrote:
>>> To follow up on my generic comments,
>> Thanks, the comments were helpful, and the new revision will respond to
>> these, and will be better for this insight.
>>> a few more generic concerns:
>>> 
>>> 1. I am worried that by constraining the document to HBH, we will have to duplicate
>>>    probably all of the work for routing headers as well. It would be preferrable to
>>>    see how much more work it would be to make the document address both
>>>    headers that can be processed by routers along the path (HBH and routing).
>>> 
>>>    Conceptually i think it should be easy, but textually given how the draft
>>>    refers to so much detailled rfc8200 text, it might lead to equal amount of
>>>    duplication of text to fix *sigh*.
>> 
>> This could be a much bigger question.
>> 
>> - First, I agree there are things in common - and I think key parts can be
>> carried forward to any work on the routing header.
> 
> Well, if you do not want to take this on now, how about cloning and working
> (at a slower pace on that second draft).
> 
> But multiple draft will just create risk of more undesirable discrepanices.
> 
> Maybe worst existing discrepancy: draft-raviolli-intarea-trusted-domain-srv6,
> 
> If we had a doc like your HBH doc for RH. Would that have avoided the problems
> that draft attempts to address ? Would the authors of that draft still think it's
> the safer, easier solution ?
> 
> Aka: How can we best avoid discrepancies.
> 
> IMHO: I would not want to see the process rushed at this point...
> 
>>> 2. As seen from the other threads, i think we want to move into a direction where
>>>    we remove the hurdles from applications to send EH (HBH/routing). But we then
>>>    need to make sure we can feel safe with that recommendations and not be beaten
>>>    up by opeators to open floodgates of attacks.
>>>    The draft does a good base level of asking for MUST configure (to process),
>>>    but i wonder if the granularity that is specified (aka: pretty much none)
>>>    is sufficient. For example, i would think that one at least wants to have
>>>    ACLs to permit/deny individual option header processing, and extended ACLs
>>>    at that (aka: only for TCP or UDP traffic, or based on source/dest combinations).
>>> 
>>>    (and no, i am not paid for by Tom to create pain with ACLs that FAST would
>>>     solve/remove, but pretty much those ACLs would be the cost of doing EH business
>>>     without FAST. And igoring the cost by not specifying the need for them would just backfire).
>> 
>> From my perspective, I could see configuration to allow/deny forwarding
>> packets with a HBH EH and for processing individual HBH Options, and I hope
>> the draft says that. Is there a need for specific text?
> 
> See above reply re. the risks at a domain edge and how well you want to harden it.
> 
> Practically speaking i think we need to think about the actual policies required
> and see how to best apply them to requirements text. The one we have is very
> hand waiving.
> 
> Aka: It seems we want interface level filters If we want to make an argument that
> something like draft-raviolli-intarea-trusted-domain-srv6 was not needed
> (assuming similarily successfully deployed, but intradomain intended HBH header
> with similar attack options for traffic from interdomain).
> 
> But we also need router - wide filter (which i think is what you may have implied,
> but the text is not specific about the context of the policy).
> We may also want to have src/dst filters at the edge or hop-by-hop to be able
> to e.g.: distinguish intradomain from transit traffic (based on ACL recognition
> of intradomain traffic as opposed to put it onto edge interface).
> 
> Wrt to the discuss re. which headers can be used in conjunction with differnt
> transport protocols. I can see a lot of interaction between transport protocol
> and HBH, so it would be very prudent to mandate support for extended ACL
> (5-tuple filter).
> 
> Wrt. reaction: I think the draft ignores the problem, that ignoring of option
> headers/options in existing routers may not work at the desired rate (not
> to say linerate as i have issues with that, see prior response from me).
> 
> In this case it seems routers should be able to discard and ICMP reply to such
> headers. Aka: Force senders to not insert such headers/options - or else traffic
> will not make it through.
> 
> Of course, we wouldn't want such future routers, but we MUST be able to support
> such existing routers.
> 
> And for example, we have a lot of history with such discarding when packet has
> something routers do not like. At least we should have a SHOULD raise ICMP
> errors so apps can react faster.
> 

Yeah. ACLs so that others can block when these packets escape their limited domain and ICMP notifications that they’ve done so. 

All very 1990s style with mountains of proof that it doesn’t enforce MUST at all. 

I’m not sure why innovation means that I get the burden of someone else’s  misconfiguration or why the most heavily loaded kit - core routers that ITIL ensures  can never be touched  - gets to take time out from switching packets to inform them that it doesn’t understand the headers their (by definition) new kit is sending it. 

What will happen in reality is that everyone gets to process switch this stuff when it leaks at best and have their kit fall over at worst. 

And yeah other than the types necessary for path MTU discovery in v6  and I suspect I’m somewhat rare in doing so for this but I really like ipv6, you’re getting and will always get precisely zero ICMP packets back from my routers and that’s right now. 
How do my routers know about headers that weren’t even thought of when their OS was compiled or is my vendor of choice going to give me free updates for kit that is very eol so that I can let people know when *their* packets aren’t understood? 

How about always defaults to off. 
Can’t be enabled on an external interface unless that interface is a point to point. Gets to leave the limited domain with a TTL of 1 or 2 so that when it does get firehosed out of somewhere then the blast radius is reduced as much as possible. 

Or if folk wish the new options to be able to cross the RFC8200 compliant internets then encapsulate it in an RFC8200 compliant packet?


If the lack of “useful” extra headers is what’s holding back adoption of v6 then just go for it and start creating ipv?8 with all the header stuff that’s missing and at that point the principles laid out by Darwin will kick in and everyone will move to the new protocol at which point curmudgeons like me will either have to go back to v4 or get new kit and move to v8 so that our applications can be allowed to pass lots of signals to core switchgear in other peoples networks. 


How you’re going to secure that seems a bit difficult but I suspect selling kit that is capable of PKI on every packet to allow for non-repudiation is going to be someone’s wet dream. Sort of per packet zero trust with hardware processing requirements that will blot out the sun. 


We are in a world where criminals have moved into a form of malware that wouldn’t exist if people patched their kit and did backups that worked. 

We are in a world where having security devices on your edge, coz that’s where security devices go, massively increases your chance of being owned because security companies making security kit can’t do supply chain security or security testing of their security products. 

History has taught us that not taking into account the real world leads to a 100% failure rate no matter how well the technology is “engineered” 

Mike