Subject: Re: Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06

From: "C. M. Heard" <[email-masked]>
Date: Tue, 4 Dec 2018 14:56:32 -0800

On Tue, 4 Dec 2018 15:17:33 -0500 Christopher Morrow wrote:
> A solution might be to have a mode where  a router may just ignore all
> headers except the src/dst-ip and simply forward all packets, trusting
> that the conversing adults will sort out problems with unknown/new/
> experimental headers or with a tortured ordering of headers (for
> instance).

Glad to hear you say that, because that's exactly what RFC 7045
envisions as the default forwarding behavior:

   Any forwarding node along an IPv6 packet's path, which forwards the
   packet for any reason, SHOULD do so regardless of any extension
   headers that are present [...]

Recognizing that processing of Hop-by-Hop Options in the fast path is
costly, RFC 8200 formally dropped the requirement for every router to
process them by default:

   NOTE: While [RFC2460] required that all nodes must examine and
   process the Hop-by-Hop Options header, it is now expected that nodes
   along a packet's delivery path only examine and process the
   Hop-by-Hop Options header if explicitly configured to do so.

What some of us would like to see is a statement in the draft that it's
just fine to operate this way (Christian Huitema made that suggestion
earlier in this thread, and so did I in my detailed last-call comments).

Mike Heard

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 4 Dec 2018 18:23:55 -0500

> envisions as the default forwarding behavior:
I'm glad I'm not too nuts :)

>    headers that are present [...]
this does mean that: "please filter the flarbly protocol traffic, eh-1234"
is going to be very hard to do in the network.

>    Hop-by-Hop Options header if explicitly configured to do so.
it's important to note that some platforms can't look beyond a certain
number of headers, and that ordering of the headers us up to the src, which
when they are being mean is ... bad :( Even platforms that can look more
than a few headers deep pay for that with clock cycles, so 100g -> 400g ->
1tbps interfaces are less and less likely to see further into the packet(s).

> earlier in this thread, and so did I in my detailed last-call comments).
oh, good. I like that idea... noting that: "makes filtering bad traffic
pretty impossible" though.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 5 Dec 2018 13:56:19 +1300

> is going to be very hard to do in the network.

Yes. But extension headers were explicitly defined to be from end system
to end system, not for middleboxes. So that difficulty was designed in.

> 1tbps interfaces are less and less likely to see further into the packet(s).

Yes. The IPv6 header was designed so that all the information needed for
*forwarding* was at the front. The extension headers were designed on
the assumption that they would be analysed by a CPU, not by an ASIC
or FPGA, so that the linked-list model seemed fine.

I think people believed that endpoints would take over DPI
filtering: https://www.cs.columbia.edu/~smb/papers/distfw.pdf

    Brian

---

From: Joe Touch <[email-masked]>
Date: Tue, 4 Dec 2018 17:17:21 -0800

It’s difficult to reconcile the text from other RFCs below with the fact that 8200 kept the 01, 10, and 11 option types.

Joe

> On Dec 4, 2018, at 2:56 PM, C. M. Heard <[email-masked]> wrote:
> 
>   headers that are present […]r

This text is in direct contradiction to RFC2460 as per above. 

>   Hop-by-Hop Options header if explicitly configured to do so.

That is an expectation of the inadequacy of others. It does not clearly drop the requirement.

> _______________________________________________
> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art

---

From: Joe Touch <[email-masked]>
Date: Tue, 4 Dec 2018 17:18:25 -0800

> On Dec 4, 2018, at 4:56 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Not HBH ones...

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 5 Dec 2018 15:59:10 +1300

> This text is in direct contradiction to RFC2460 as per above.

Of course. RFC 7045 updated RFC2460.

> That is an expectation of the inadequacy of others. It does not clearly drop the requirement.

If so, that was a drafting error. RFC 7045 already formally changed
it to a SHOULD.

And IMHO it's entirely correct. For example, making the open Internet completely transparent to HbH means that a HbH-using application has a chance of crossing the open Internet successfully. By contrast, expecting line-speed routers on multi-Gbit
intercontinental links to process HbH condemns such an application to failure.

This was all thrashed out when we drafted RFC 7045 and again when we
drafted RFC 8200.

What's new here is that OPSEC wants to legitimise filtering for reasons
other than performance, and that's contentious.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 5 Dec 2018 16:00:03 +1300

>> to end system, not for middleboxes. So that difficulty was designed in.

Indeed, which is why RFC 7045 changed the requirement.

    Brian

---

From: Joe Touch <[email-masked]>
Date: Tue, 4 Dec 2018 19:43:43 -0800

> On Dec 4, 2018, at 7:00 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Except it didn’t. The bits are still there in 8200 and 7045 never deprecated their meaning.  

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 4 Dec 2018 19:48:09 -0800

On Dec 4, 2018, at 6:59 PM, Brian E Carpenter <[email-masked]> wrote:

> And IMHO it's entirely correct.

It makes the notion of option flag bits irrelevant but never removed them. 

The trouble is that the flags were there to prevent silently ignoring explicit direction to each router. If that isn’t what HBH options are, then what are they?

If they were disabled as you say, they should have been completely removed from 8200. But they were - and are - not. 

Joe

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 4 Dec 2018 22:57:43 -0500

> to end system, not for middleboxes. So that difficulty was designed in.
sure, that's all well an good, but when 1mpps of eh-1234 show up on your
door... uhm, you're going to want "relief" :)
speaking from experience ... you really will want your
ISP/carier/transit/peer to help you NOT get lit on fire.
Them saying: "Well I COULD do that... but ... no, sorry I'm just the bit
carrier, have fun!"
is going to go 'not well' (again, having had this conversation, though not
about ipv6 extension headers).

> filtering: https://www.cs.columbia.edu/~smb/papers/distfw.pdf
HA! ok. As gert/nick noted ... we have Nx100G links today (at the edge) and
coming nx400G ... there's just not a reasonable story for "dpi" there. (I
suppose: "yet" and "without paying the approximate value Coca-Cola
Companies yearly advertising budget")

-chris

---

From: Gert Doering <[email-masked]>
Date: Wed, 5 Dec 2018 09:52:27 +0100

Hi,

> Companies yearly advertising budget")

Indeed.

Unfortunately, there *is* a story for being able to rate-limit incoming
crap by protocol type - "give me no more than 200 Mbit/s of UDP packets
coming from source port 53".

Which implies that as soon as the evil guys out there find a way to
generate DDoS streams carrying EHs that our border routers will (have to)
apply very strict rate limiting to everything they do not understand.

 - pass TCP
 - rate-limit UDP on well-known reflective attacks port
 - pass rest of UDP
 - rate-limit ICMP
 - rate-limit fragments
 - rate-limit all the rest to something which can never exceed a customer's
   access-link

game over, EH

(We're not doing this today, because as of today, "volume DDoS" comes in
without EHs [except fragment] - but this is just a matter of time)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 6 Dec 2018 13:14:54 +1300

>  - rate-limit all the rest to something which can never exceed a customer's

Just to point out that this is equivalent to saying "game over, any new layer 4 protocol" too. For example, you just killed SCTP. And the same goes for new protocols over IPv4.

    Brian

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 6 Dec 2018 00:38:33 +0000

Hiya,

On 06/12/2018 00:14, Brian E Carpenter wrote:
> Just to point out that this is equivalent to saying "game over, any
> new layer 4 protocol" too. For example, you just killed SCTP. And the
> same goes for new protocols over IPv4.
Well, there is port 443 and quic etc.

While I don't have a position in the discussion so far, it
does seem to validate the proposition that encrypting as a
counter to ossification is a valid (but not the only valid)
argument.

Interestingly, this discussion could be read to imply that
encrypting transports like quic may better support higher
throughput networks with fast-path routers (where anything
other than fast-path is basically /dev/null) by taking some
models of DPI off the table. That somewhat sharply contrasts
with arguments against such encrypting transports that I've
seen offered by operators. I'm not claiming this is a winning
argument, nor anything like one, but perhaps noteworthy.

Cheers,
S.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 5 Dec 2018 23:37:56 -0300

> Just to point out that this is equivalent to saying "game over, any new layer 4 protocol" too. For example, you just killed SCTP. And the same goes for new protocols over IPv4.

Not exactly the same. If you are using a new transport protocols (*)
without any EHs, you have already found the upper-layer protocol. May
allow or drop, but that's it. With EHs, if you need to do packet
filtering or ECMP, you need to follow the EH chain.The later
(particularly if the EH) is normally going to cause issues, where the
former would not.

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Gert Doering <[email-masked]>
Date: Thu, 6 Dec 2018 10:31:54 +0100

Hi,

On Thu, Dec 06, 2018 at 01:14:54PM +1300, Brian E Carpenter wrote:
> Just to point out that this is equivalent to saying "game over,
> any new layer 4 protocol" too. For example, you just killed SCTP.
> And the same goes for new protocols over IPv4.

Well.  Since nobody is using SCTP, it can nicely live in the 
"rate-limit all the rest to something ..." bucket...

But yes, "any new layer 4 protocol" is likely to not work in an Internet
that is basically full of hostile packets *in high volumes*.

Trying to run large volume traffic over UDP/443 is going to be the next
excercise in "operators told you that is isn't going to work"...

Gert Doering
        -- NetMaster

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Thu, 6 Dec 2018 11:15:11 +0100

hi Brian, all,

> On 6 Dec 2018, at 01:14, Brian E Carpenter <[email-masked]> wrote:
> 

Indeed, it is, and I think it's a nice honest assessment of the current state of the Internet.

We lost the ability to deploy new layer 4 protocols (in terms of the value of the protocol or next header fields in the network layer) universally within the Internet at least a decade ago. The argument here seems to be whether we, as the IETF, want to acknowledge this fact, or not -- and all of the evidence I've seen would seem to confirm the situation is the same for HbH (and to a lesser extent, DO) EH for v6 -- and whether there are degrees of freedom to be won from said acknowledgment.

I note that current work in TSV on transport evolution pretty much seems to acknowledge this, if tacitly, for layer 4, and to actively design for this situation:

- the original concept behind TAPS, runtime transport stack agility, was designed to make "new" protocols deployable (whether over v4 or over v6) when not impaired by the network, and to fall back to less impaired protocol stacks when they are the only ones available.

- QUIC explicitly uses UDP in part because only protocols 6, 17, and to a lesser extent 1 are assumed to be widely passed in the network (and numbers from Google and RIPE Atlas, presented in MAPRG, show that even here there's about a one-in-thirty chance that a given path won't support QUIC over UDP, necessitating TCP fallback), and the primary utility of encryption of the QUIC protocol header is avoiding the deployment of in-network functions using any part of the QUIC header not explicitly designed for on-path use, thereby (we hope) keeping this decay from impairing our ability to change QUIC as it has our ability to change L4 otherwise.

Cheers,

Brian

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 6 Dec 2018 10:28:53 +0000

> Just to point out that this is equivalent to saying "game over, any new layer 4 protocol" too. For example, you just killed SCTP. And the same goes for new protocols over IPv4.
.. a consequence of the original design decision to make options and 
next protocols indistinguishable other than by knowing the full set of 
next protocol types.

However, aren't we moving to a world where new protocols get carried 
over UDP anyway?  This is needed so that those protocols can pass 
through NATS and firewalls, and be subjected to ECMP to spread them 
across the available paths.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 6 Dec 2018 12:40:02 +0000

> (particularly if the EH) is normally going to cause issues, where the
I think the problem is that it is very difficult to teach the core about 
any new
transport protocol.

- Stewart

---

From: Gert Doering <[email-masked]>
Date: Thu, 6 Dec 2018 13:57:26 +0100

Hi,

On Thu, Dec 06, 2018 at 10:28:53AM +0000, Stewart Bryant wrote:
> over UDP anyway?

Over HTTPS, you intended to say?

Gert Doering
        -- NetMaster

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 6 Dec 2018 13:38:24 +0000

> Over HTTPS, you intended to say?
Some and some.  It depends on what aspect of the stack you spend your 
time thinking about.

- Stewart

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 6 Dec 2018 08:05:53 -0600

Speaking as an individual who ballots on working group charters ...

> Some and some.  It depends on what aspect of the stack you spend your

"you're both right" :-) ...

As noted earlier in this thread, we punted new transport protocols into UDP
encapsulation at roughly the "we can't get SCTP deployed at scale, we can't
get DCCP deployed at scale, and we don't see any reason to think that any
new transport protocol will be any different" stage, at least a decade ago.
So, when I see people talking about SCTP, it's usually in a context like
RTCWeb, where the stack looks like SCTP/DTLS/UDP, and QUIC is only defined
over UDP.

(I suspect the world would have been a slightly better place if we'd done
the DCCP encapsulation in UDP from day 1, because DCCP functionality could
have been really useful when we started encapsulating every known network
protocol in UDP, but that's not relevant to this discussion)

But since QUIC's initial deliverable includes its HTTP mapping,
https://datatracker.ietf.org/doc/draft-ietf-httpbis-bcp56bis/ comes into
play. I would oversimplify that draft as saying "we are way more excited
about applications using HTTP as a substrate now, than we were in 2002",
so, yes, the future smells a lot like HTTPS over (mumble) over UDP, at
least to me.

I don't know that's a perfect plan, but I've been balloting on working
group charters for at least 3 years, assuming that it's a plan.

Spencer

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 6 Dec 2018 10:58:01 -0800

On Thu, Dec 6, 2018 at 1:32 AM Gert Doering <[email-masked]> wrote:
> > >  - rate-limit all the rest to something which can never exceed a
> > >    customer's access-link
> > >
> > > game over, EH
> >

Is that a prediction, or a self-fulfilling prophecy? I would certainly hope
that filtering UDP/443 is not done preemptively without actual evidence that
it is in fact a DDoS vector.

Mike Heard

---

From: Jared Mauch <[email-masked]>
Date: Thu, 6 Dec 2018 14:12:02 -0500

> On Dec 6, 2018, at 1:58 PM, C. M. Heard <[email-masked]> wrote:
> 

It is done as UDP is where the majority of the abuse has been.  I’ve been responsible for implementing these types of controls at operator networks due to the damage it does to our infrastructure.

People are very unhappy then their service is down because they’re staring down a cannon that took out their country/continent with UDP abuse.

I would say I find it shocking that the transport area folks seem to keep ignoring the feedback from operators, but this feeds into the longstanding meme of operators don’t show up at the IETF because they aren’t heard.

I’ve had folks at $dayjob say they “Well that network will then have poor performance and people will switch”.  This may be the case for those that have choice, but as was recently pointed out in home net, much of the complexity perhaps isn’t used or desired by the consumers.

Yes, the ad networks want to serve me ads faster.  I don’t expect the transport area to listen to those that operate networks as it’s been demonstrated the conversation about harm to the network by these behaviors isn’t listened to.

Let me state it clearly:

UDP is filtered or policed by network operators not because they want it, but as self-defense.  Nothing personal.  If you are on the end of a long subsea circuits, you may not be able to use UDP based protocols.  If you are trying to SNMP poll over public internet because you think you can e2e, you will become sad.  No operator wants to deploy these configurations, they must because of the problems.

- jared

(Feels like a broken record on this topic)

---

From: Jared Mauch <[email-masked]>
Date: Thu, 6 Dec 2018 14:24:13 -0500

> On Dec 6, 2018, at 9:05 AM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> On Thu, Dec 6, 2018 at 7:38 AM Stewart Bryant <[email-masked]> wrote:
> 
> 
> As noted earlier in this thread, we punted new transport protocols into UDP encapsulation at roughly the "we can't get SCTP deployed at scale, we can't get DCCP deployed at scale, and we don't see any reason to think that any new transport protocol will be any different" stage, at least a decade ago. So, when I see people talking about SCTP, it's usually in a context like RTCWeb, where the stack looks like SCTP/DTLS/UDP, and QUIC is only defined over UDP. 
> 
> (I suspect the world would have been a slightly better place if we'd done the DCCP encapsulation in UDP from day 1, because DCCP functionality could have been really useful when we started encapsulating every known network protocol in UDP, but that's not relevant to this discussion)
> 
> But since QUIC's initial deliverable includes its HTTP mapping, https://datatracker.ietf.org/doc/draft-ietf-httpbis-bcp56bis/ comes into play. I would oversimplify that draft as saying "we are way more excited about applications using HTTP as a substrate now, than we were in 2002", so, yes, the future smells a lot like HTTPS over (mumble) over UDP, at least to me.
> 
> I don't know that's a perfect plan, but I've been balloting on working group charters for at least 3 years, assuming that it's a plan. 

Yes, we’ve also seen the security/crypto all the things overreach impact the routing area as well.  We’ve not seen a suitable option to replace TCP transport that is viable due to the timescales involved.  I’ve provided feedback at the mic in London in SAAG about the problems of this for people who need very reliable transport, some level of transport security but do not want or require transport privacy. 

- Jared

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 6 Dec 2018 11:41:28 -0800

On Thu, Dec 6, 2018 at 11:12 AM Jared Mauch wrote:
> UDP is filtered or policed by network operators not because they want
> it, but as self-defense.  Nothing personal.  If you are on the end of
> a long subsea circuits, you may not be able to use UDP based
> protocols.  If you are trying to SNMP poll over public internet
> because you think you can e2e, you will become sad.  No operator wants
> to deploy these configurations, they must because of the problems.

I do get the need for self-defense. But ...

Does this apply to all UDP or just specific UDP-based protocols?

What I commented on specifically was UDP/443 (QUIC), something
that people are actually trying to deploy.

If you block it, is that based on evidence of actual UDP/443 attacks?

Mike Heard

---

From: "Smith, Donald" <[email-masked]>
Date: Thu, 6 Dec 2018 20:00:00 +0000

In the past nearly all UPD:443 traffic was part of an attack. Frequently it is the src port for a reflective attack towards UPD:1900, 123, … pick a reflector port that amplifies well.

UDP:80 same.

Those are the two most common trigger packet src ports for RA attacks.

It is my belief that the bad guys choose that because some (many?) filters are port based only not protocol based.
I have no evidence of that (you would have to ask a bad guy... DDoS for hire) but it is common.

 Don't take my word for it :)
https://asert.arbornetworks.com/ddos-attacks-iot-botnets-dont-mean-game/

" As most (not all) UDP reflection/amplification attacks tend to target UDP/80 or UDP/443 in order to confuse defenders who might not notice that the attackers are using UDP instead of TCP (TCP/80 is typically used for non-encrypted Web servers, and TCP/443 for SSL-/TLS-encrypted Web servers), "

if (initial_ttl!=255) then (rfc5082_compliant==0)
[email-masked]

________________________________________
From: OPSEC [[email-masked]] on behalf of C. M. Heard [[email-masked]]
Sent: Thursday, December 06, 2018 12:41 PM
To: Jared Mauch
Cc: IETF; [email-masked]; OPSEC; TSV-ART; Brian E Carpenter
Subject: Re: [OPSEC] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06]

Mike Heard

_______________________________________________
OPSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsec
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.

---

From: Gert Doering <[email-masked]>
Date: Thu, 6 Dec 2018 21:02:17 +0100

Hi,

> that people are actually trying to deploy.

We currently rate-limit NTP, DNS, memcached, LDAP/UDP and *fragments*
(because LDAP and NTP usually bring along large fragments).

We *currently* see no attacks on UDP/443, so we do not rate-limit that.

Gert Doering
        -- NetMaster

---

From: Nico Williams <[email-masked]>
Date: Thu, 6 Dec 2018 14:03:20 -0600

On Thu, Dec 06, 2018 at 10:58:01AM -0800, C. M. Heard wrote:
>                                               [...]? I would certainly hope

I'd expect that networks that filter / rate-limit UDP do it mostly
indiscriminately, and wouldn't already have exceptions for port 443.
Exceptions would mostly be for things like DNS and NTP (not filtered,
obviously, but maybe rate-limited).

The port number / application has a lot to do with DDoS potention.

E.g., DNS has great amplification potential, so it needs rate limits.
TCP has much smaller amplification potential, and more of the TCP state
machine is visible to the network than any non-TCP protocol's state
machine, so maybe TCP SYNs and maybe even RSTs get rate-limited, but
others do not.  With TCP there's no need to discriminate by port number
or know what the application protocol is.  With UDP all you have is port
numbers to discriminate by.

Without exposing that sort of detail (SYN, RST, ...) to the network, I'd
expect operators to scoff, and QUIC to have trouble in the public
Internet until operators / kit learn how to handle QUIC.  Not that we
can expect kit to understand new upper level protocols, or new UDP
application protocols, in with any kind of celerity.  So it's all a mess
:(

Also, we can run HTTP and HTTPS over TCP on any ports, not just 80 and
443.  That won't be true for QUIC.  Each alternative port number will
have to get middlebox relaxation de novo.  That could be a problem, or
maybe a blessing: maybe QUIC should mux multiple apps on one port.
(QUIC muxes streams, but not apps).  Then again, QUIC is done, right?

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 6 Dec 2018 14:40:00 -0800

On Thu, Dec 6, 2018 at 11:24 AM Jared Mauch <[email-masked]> wrote:

> > As noted earlier in this thread, we punted new transport protocols into
> UDP encapsulation at roughly the "we can't get SCTP deployed at scale, we
> can't get DCCP deployed at scale, and we don't see any reason to think that
> any new transport protocol will be any different" stage, at least a decade
> ago. So, when I see people talking about SCTP, it's usually in a context
> like RTCWeb, where the stack looks like SCTP/DTLS/UDP, and QUIC is only
> defined over UDP.
> >
> > (I suspect the world would have been a slightly better place if we'd
> done the DCCP encapsulation in UDP from day 1, because DCCP functionality
> could have been really useful when we started encapsulating every known
> network protocol in UDP, but that's not relevant to this discussion)
> >
> Yes, we’ve also seen the security/crypto all the things overreach impact
> the routing area as well.  We’ve not seen a suitable option to replace TCP
> transport that is viable due to the timescales involved.  I’ve provided
> feedback at the mic in London in SAAG about the problems of this for people
> who need very reliable transport, some level of transport security but do
> not want or require transport privacy.
>

Jared,

I'm not entirely sure I know what you're talking about here. If I recall
your comments at the microphone correctly, they were about the challenges
with TCP-AO. However, I wouldn't really call TCP-AO an example of
security/crypto overreach. Rather, it was an attempt to fulfill what we
understood to be asks from the routing area (key agility, a stronger
algorithm than MD5). And of course TCP-AO doesn't attempt to provide
privacy. Perhaps you can elaborate on what you're referring to here?

-Ekr

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 7 Dec 2018 00:10:02 -0500

On Thu, Dec 6, 2018 at 5:41 PM Eric Rescorla <[email-masked]> wrote:

>
> routing area (key agility, a stronger algorithm than MD5). And of course
> TCP-AO doesn't attempt to provide privacy. Perhaps you can elaborate on
> what you're referring to here?
>
>>
>>
"TCP-AO is a lie, there is zero deployable code anywhere that supports it"

was that the gist of his comment?
it'd be the whole of mine... because honestly it's the truth.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 7 Dec 2018 05:02:13 -0800

> was that the gist of his comment?

A rather more elaborated version of this

Sure, but as I said, I don't think of TCP-AO as an example of crypto
overreach. It's not something that security people tried to force on the
routing people, but rather something that was designed to what we
understood the requirements of the routing community. It's of course
possible, perhaps even likely, that we got it wrong, but that's a very
different thing.

-Ekr

---

From: Jared Mauch <[email-masked]>
Date: Fri, 7 Dec 2018 15:46:15 -0500

> On Dec 7, 2018, at 12:10 AM, Christopher Morrow <[email-masked]> wrote:
> 
> 
> 
> routing area (key agility, a stronger algorithm than MD5). And of course TCP-AO doesn't attempt to provide privacy. Perhaps you can elaborate on what you're referring to here?
> 
> 

I had written out a series of concerns around the requirements operators have.. I can’t find the paper around my office right now I wrote them on, but the went roughly like this:

1) We have long-lived TCP sessions, measured in years.  (Implied: many of the transport people really prefer stable routes without flapping/jitter/reordering from us)
2) We use protocols that are stable as a result as transports
3) Security area does review and says “why is MD5 still a thing” without considering #2 and #1 above
4) When doing routing things like an iBGP mesh, key rotation can be complex in a multivendor environment when the catastrophic failure of the network substrate is the consequence of a software bug
5) If these keys (md5) are in use, they’re not rotated because we got that support much later than the ability to set/rotate them and coordination with a network partner to rotate them is feasible but reaches operational impossibility.
6) We need protection from tampering with the transport, not encryption of the transport.  You will know where the routes go because I assume you’ve used a tool like traceroute before.

There was a longer list.

The point of this thread is if you do something “interesting” with your transport, be it IP options, EH, shift your protocol into a space that operators have policed out of necessity (not because we want it), expect broken things to happen.  

It’s not the early 90s anymore and rolling these things back is much harder than it was.  I see daily attacks of hundreds of gigs of UDP against customers, and these won’t make it far because we won’t build network infrastructure to carry them to their destination.  We will mitigate the issue, and as always there is collateral damage.

If your protocol uses an ephermal port from Gert’s list to connect to a well known port, expect there to be problems.  (Look at the history in the early 2000’s why this was built => http://www.zytrax.com/books/dns/ch7/hkpng.html#avoid )

This is not a limited problem to any single protocol, network, device role, etc.  It’s not clear to me the IETF is presently equipped to respond to this, but I hope people are listening.

- Jared

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 7 Dec 2018 12:59:09 -0800

On Fri, Dec 7, 2018 at 12:46 PM Jared Mauch <[email-masked]> wrote:

> I had written out a series of concerns around the requirements operators
> have.. I can’t find the paper around my office right now I wrote them on,
> but the went roughly like this:
>
> 1) We have long-lived TCP sessions, measured in years.  (Implied: many of
> the transport people really prefer stable routes without
> flapping/jitter/reordering from us)
> 4) When doing routing things like an iBGP mesh, key rotation can be
> complex in a multivendor environment when the catastrophic failure of the
> network substrate is the consequence of a software bug
> 5) If these keys (md5) are in use, they’re not rotated because we got that
> support much later than the ability to set/rotate them and coordination
> with a network partner to rotate them is feasible but reaches operational
> impossibility.
> 6) We need protection from tampering with the transport, not encryption of
> the transport.  You will know where the routes go because I assume you’ve
> used a tool like traceroute before.
>

I think most of these points are reasonable (I'd quibble about #3) but
they're not very actionable.

If you're position is that TCP-MD5 is all you need (and maybe not even
that) then OK.

If what you want is some protocol with other, different, functions, then
you're going to need to be a lot clearer about what it is you *do* want,
not just what you *don't* want.

-Ekr

---

From: Joe Touch <[email-masked]>
Date: Fri, 7 Dec 2018 13:10:33 -0800

> On Dec 6, 2018, at 2:40 PM, Eric Rescorla <[email-masked]> wrote:
> ...
> And of course TCP-AO doesn't attempt to provide privacy.

It can, by changing the association parameters and packet processing algorithm, without changing the rest or the protocol. 

See draft-touch-tcp-so-encrypt

Joe

---

From: Jared Mauch <[email-masked]>
Date: Fri, 7 Dec 2018 16:17:12 -0500

> On Dec 7, 2018, at 3:59 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> I think most of these points are reasonable (I'd quibble about #3) but they're not very actionable.
> 
> If you're position is that TCP-MD5 is all you need (and maybe not even that) then OK.

It has problems, I’d like something “better” and a path to get to that better thing.  I just built a Greenfield network and we used some better methods than my prior employer was able to use.  We often get technology lock-in when we use things for “security” purposes.

> If what you want is some protocol with other, different, functions, then you're going to need to be a lot clearer about what it is you *do* want, not just what you *don't* want. 

I’m speaking about the operator challenges we have.  I don’t have a draft that’s getting caught up in sec-dir review because it still uses TCP-MD5 because there are no TCP-AO or other implementations, or a migration path to them.

What I am is an operator that has experience in running a network, trying to be minimalist in my responses to the badness, and keep it up so the higher protocols can do their thing.  When it gets problematic is when I can’t differentiate something good from something bad as easily and people decide to shift that line.  I’m warning you where the guard rails are, they may get moved.

This entire draft I see in the subject/cc line is part of that, here’s what operators are doing.  EH’s are a cool idea, but they are also a security risk in that they may end up in the punt path or significantly impact performance of the forwarding plane in a way that could cause the networking substrate to cease to function as desired.  These are things operators will work hard to protect to ensure it’s working.  The network has limits and just because it works in some hardware doesn’t mean it will work in it all.

We are stuck today in many cases with whatever we get in a BCM Chipset and that doesn’t appear to be changing (although I hope it does change, and there continue to be options in the market).

There are many protocols that need to be cleaned up, just like most people stopped running chargen on their routers after it was used as an attack vector.  The same was done with changing the defaults around “ip directed-broadcast” behavior.  Expecting intermediate network elements to honor requests in EH’s is not likely to change.

- Jared

---

From: Jared Mauch <[email-masked]>
Date: Fri, 7 Dec 2018 16:22:37 -0500

> On Dec 7, 2018, at 4:10 PM, Joe Touch <[email-masked]> wrote:
> 
> 
> 

This is why routing folks were sent in that direction..

> See draft-touch-tcp-so-encrypt

Sure, the issue still is we need running code for TCP-AO and it’s not yet available.

- jared

---

From: Joe Touch <[email-masked]>
Date: Fri, 7 Dec 2018 14:30:36 -0800

> Sure, the issue still is we need running code for TCP-AO and it’s not yet available.

Not free.  Nobody wanted to pay for one. 

Joe

---

From: Nico Williams <[email-masked]>
Date: Fri, 7 Dec 2018 16:44:46 -0600

On Fri, Dec 07, 2018 at 03:46:15PM -0500, Jared Mauch wrote:
> 1) We have long-lived TCP sessions, measured in years.  (Implied: many
> of the transport people really prefer stable routes without

<rhetorical>
I've long wondered why BGP has to be this way and why it still is after
so many years.
</rhetorical>

---

From: Jared Mauch <[email-masked]>
Date: Fri, 7 Dec 2018 17:48:40 -0500

> On Dec 7, 2018, at 5:44 PM, Nico Williams <[email-masked]> wrote:
> 

I have seen BGP sessions up for over 7 years on some routers. One can argue if this is a good thing or bad.  It’s quite an interesting thing to see and go “wow, someone forgot about this one …”

- jared

---

From: Nico Williams <[email-masked]>
Date: Fri, 7 Dec 2018 17:03:03 -0600

On Fri, Dec 07, 2018 at 05:48:40PM -0500, Jared Mauch wrote:
> I have seen BGP sessions up for over 7 years on some routers. One can
> argue if this is a good thing or bad.  It’s quite an interesting thing
> to see and go “wow, someone forgot about this one …”

What I meant is that I don't understand why resetting a connection
should still cause routes to flap.  Instead I'd expect session
management negotiation to determine whether the thing that failed (e.g.,
a BGP daemon) implies that the routes are gone or not.  Then RST
injection would not be a problem.  You'd still need integrity
protection, but then that could always have been done with TLS.

Basically, it feels like BGP is stuck in the stone age.

I'm not asking the routing area to fix it.  I'm not saying that we
should not cater to their needs.  My point truly was rhetorical.  I do
hope the routing area does improve session management in BGP some day.

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 7 Dec 2018 21:49:15 -0800

On Fri, Dec 7, 2018 at 1:17 PM Jared Mauch <[email-masked]> wrote:

> > > routing area (key agility, a stronger algorithm than MD5). And of
> course TCP-AO doesn't attempt to provide privacy. Perhaps you can elaborate
> on what you're referring to here?
> > >
> > >
> > 5) If these keys (md5) are in use, they’re not rotated because we got
> that support much later than the ability to set/rotate them and
> coordination with a network partner to rotate them is feasible but reaches
> operational impossibility.
> > 6) We need protection from tampering with the transport, not encryption
> of the transport.  You will know where the routes go because I assume
> you’ve used a tool like traceroute before.
> >
> It has problems, I’d like something “better” and a path to get to that
> better thing.  I just built a Greenfield network and we used some better
> methods than my prior employer was able to use.  We often get technology
> lock-in when we use things for “security” purposes.
>
> I’m speaking about the operator challenges we have.  I don’t have a draft
> that’s getting caught up in sec-dir review because it still uses TCP-MD5
> because there are no TCP-AO or other implementations, or a migration path
> to them.
>

Well, drafts don't get stuck in sec-dir review, because those reviews are
non-blocking. And I'm pretty sure that neither Ben or I are holding
discusses on any such drafts. If so, can you list them, please?

> What I am is an operator that has experience in running a network, trying
> to be minimalist in my responses to the badness, and keep it up so the
> higher protocols can do their thing.  When it gets problematic is when I
> can’t differentiate something good from something bad as easily and people
> decide to shift that line.  I’m warning you where the guard rails are, they
> may get moved.
>
> This entire draft I see in the subject/cc line is part of that, here’s
> what operators are doing.  EH’s are a cool idea, but they are also a
> security risk in that they may end up in the punt path or significantly
> impact performance of the forwarding plane in a way that could cause the
> networking substrate to cease to function as desired.  These are things
> operators will work hard to protect to ensure it’s working.  The network
> has limits and just because it works in some hardware doesn’t mean it will
> work in it all.
>

I have no position on IPv6 EHs.

-Ekr

> We are stuck today in many cases with whatever we get in a BCM Chipset and
> that doesn’t appear to be changing (although I hope it does change, and
> there continue to be options in the market).
>
> There are many protocols that need to be cleaned up, just like most people
> stopped running chargen on their routers after it was used as an attack
> vector.  The same was done with changing the defaults around “ip
> directed-broadcast” behavior.  Expecting intermediate network elements to
> honor requests in EH’s is not likely to change.
>
> - Jared
>
>
>
>

---

From: Gert Doering <[email-masked]>
Date: Sat, 8 Dec 2018 10:25:53 +0100

Hi,

> protection, but then that could always have been done with TLS.

We do have BGP graceful restart.  Which just causes a bit of CPU load
on both ends while they walk multiple millions of VPNv4 routes to
reestablish common state.

Gert Doering
        -- NetMaster