Subject: [Dots] How constrained due to attack congestion

From: Robert Moskowitz <[email-masked]>
Date: Thu, 24 Sep 2015 08:05:08 -0400

One of the requirements for DOTS is to be able to message an attack 
while the attack is congesting the link.

Are we going to put any measure on this or recommend any approach to 
communicate over a constrained link.

As I view where I am coming from on this, I have spent considerable time 
down in IEEE 802.15 dealing with very constrained and lousy links.  A 
lot of thought goes into what CAN be transmitted and to what degree of 
effort is made at what level to improve likelihood of success.

To this end, do we recommend that the DOTS message about an attack MUST 
fit wtihin a single datagram?  And if so how do we count the bytes?  
That is figure out the transmission overhead:  TCP or UDP and what 
security envelope?

Consider what CORE has done to design CoAP as a binary RESTful protocol 
to work over a constrained link.  Is IPFix thus a good approach?

Does anyone have any actual measurements of what size messages CAN get 
through during an attack?

thank you

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 24 Sep 2015 14:04:22 +0100

Hi Rob,

As I see this, the congested link can be in one of two directions (or
possibly both).  "Local" is signalling to "Remote" about what is happening.

Direction Inbound Congestion.
Any protocol that requires an acknowledgement (e.g. TCP) will fail when
trying to send an outbound "Help Attack" message.  As there is no outbound
congestion, the "Help Attack" messages would not be constrained to a minimal
size, but, in my opinion, should be able to fit in a standard packet (see
Protocols below).

Direction Outbound Congestion
Any "Help Attack" message will not get through - but as this is Outbound,
then the remote end cannot respond, but will be able to detect the lack of
any "Heart Beat" messages getting through.  The local end will need to put
mitigation defences in place to stop the outbound congestion.

Direction Both Congestion
The Outbound Congestion needs to be fixed locally.

Protocols
This then leans towards the use of a protocol such as UDP for sending "Help
Attack" messages.  If this protocol has to have a security wrapper (most
would say yes), then any key exchange updates may not successfully take
place during this congestion period - thus there would have to be support
for being able to use old keys during this congestion period.

Whether IPFix is the correct layer 7 protocol is open for debate.

Regards

Jon

-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of Robert Moskowitz
Sent: 24 September 2015 13:05
To: dots
Subject: [Dots] How constrained due to attack congestion

One of the requirements for DOTS is to be able to message an attack while
the attack is congesting the link.

As I view where I am coming from on this, I have spent considerable time
down in IEEE 802.15 dealing with very constrained and lousy links.  A lot of
thought goes into what CAN be transmitted and to what degree of effort is
made at what level to improve likelihood of success.

To this end, do we recommend that the DOTS message about an attack MUST fit
wtihin a single datagram?  And if so how do we count the bytes?  
That is figure out the transmission overhead:  TCP or UDP and what security
envelope?

Consider what CORE has done to design CoAP as a binary RESTful protocol to
work over a constrained link.  Is IPFix thus a good approach?

thank you

_______________________________________________
Dots mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dots

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 24 Sep 2015 15:14:37 +0000

> From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
> Sent: Thursday, September 24, 2015 6:34 PM
> To: [email-masked]
> Subject: Re: [Dots] How constrained due to attack congestion
> 
> Hi Rob,
> 
> As I see this, the congested link can be in one of two directions (or possibly
> both).  "Local" is signalling to "Remote" about what is happening.
> 
> congestion, the "Help Attack" messages would not be constrained to a
> minimal size, but, in my opinion, should be able to fit in a standard packet
> (see Protocols below).
> 
> place during this congestion period - thus there would have to be support for
> being able to use old keys during this congestion period.

TLS session resumption without server-side state RFC5077 can possibly be used, but it still consumes 1 round trip before the "Help attack" message can be signaled. Another alternative is to go with TLS 1.3 which supports zero round-trip.

-Tiru

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 24 Sep 2015 14:54:45 -0400

this all sounds like 'bikeshedding' at this point... we don't yet (I
think) have 'what will be communicated' between the endpoints in
question. Once we agree on that, perhaps we can decide how to pack
10lbs into the 5lb bag.

The vast majority of 'oh crap, I'm under attack' problems are 'my
inbound link is full, holy crap!', so outbound traffic ought to 'just
work', presuming you don't require timely replies...

anyway, it seems like we jumped ahead of ourselves, it's good to keep
in mind for later though.

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 24 Sep 2015 15:41:07 -0400

Not quite so if this goes into the requirements document.  Of which 
Tiru, Andy, and I are the joint editors...

"The protocol design needs to be cognizant of transmission limitations 
during an attack and minimize the number of datagrams and return 
acknowledgments to send to initiate a mitigation action."  Is really 
vague but covers the concern.  More meat would be good for the meal...

Or "If the controller has not heard a heartbeat (if supported) within a 
reasonable time, an attack may be underway and mitigation should be 
initiated."

---

From: Stefan Fouant <[email-masked]>
Date: Thu, 24 Sep 2015 19:52:02 +0000

Is the plan to work on the requirements doc at the same time as the use
case? Because I envision the use case doc could cover some of this from a
high level.

I like the idea of using a connectionless oriented methodology coupled w/
heartbeats but there are caveats to such an approach - we may not want to
initiate a mitigation action solely based on loss of such as any number of
maintenance activities or other things could potentially trigger a
mitigation. 

Stefan Fouant
JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI, CISSP
Senior Security Engineer
Corero Network Security
Mobile: +1.703.625.6243
 
Your Solution for Real-Time  DDoS Protection
<http://www.corero.com/ddos_defense_overview_video>

On 9/24/15, 3:41 PM, "Dots on behalf of Robert Moskowitz"
<[email-masked] on behalf of [email-masked]> wrote:

>>>>possibly
>>> TLS session resumption without server-side state RFC5077 can possibly
>>>be used, but it still consumes 1 round trip before the "Help attack"
>>>message can be signaled. Another alternative is to go with TLS 1.3
>>>which supports zero round-trip.
>>>
>>> -Tiru
>>>
>>>>lot of
>>>>security

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 24 Sep 2015 15:54:13 -0400

They are two separate editing teams.  Both needing to get a document 
ready for November.

Do the math.

Well I am consulting with one of the use case members...

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 24 Sep 2015 16:00:28 -0400

> question. Once we agree on that, perhaps we can decide how to pack

With regard to 5lb in 10lb bags.  We do that a lot in IoT networking.  
You should see the IEEE 11073 data model.  Or maybe it is better if you 
did not.  Afterall, it is in many of those wonderful new wireless 
medical devices coming to market.

But my point is this road is well worn by others and there is much to 
take away from what they have done.  Particularly in industrial control 
where timing is everything even when the network is lousy. Then you get 
to wireless building security controls and how they handle RF DOS 
attacks (or don't as the case may be).

---

From: "Teague, Nik" <[email-masked]>
Date: Thu, 24 Sep 2015 20:00:49 +0000

Hi,

>case? Because I envision the use case doc could cover some of this from a

Hi the use case and requirements should compliment each other.

>maintenance activities or other things could potentially trigger a

A heartbeat shouldn’t be enough to trigger an automitigation in my mind
but should signal that comms are lost somewhere

Thanks,

-Nik

---

From: Stefan Fouant <[email-masked]>
Date: Thu, 24 Sep 2015 20:08:16 +0000

On 9/24/15, 4:00 PM, "Teague, Nik" <[email-masked]> wrote:

>A heartbeat shouldn¹t be enough to trigger an automitigation in my mind

Perhaps some type of signaling like we have in Graceful Restart where when
a reboot is planned we can signal to peers to hold off a bit before
reconverging might be of useŠ in equivalent terms, I think a method for
indicating upstream that a planned maintenance is taking place might be
warranted, such that simply loss of heartbeats doesn¹t automatically imply
mitigation.

Stefan Fouant

---

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 25 Sep 2015 06:37:39 +0700

> Well I am consulting with one of the use case members...

It would be good to consult with all of us.

As has been noted both on this list and during the DOTS WG meeting in 
Prague, both stateless and stateful transports are necessary.  It's 
unclear why this is being rehashed yet again.

With regards to single-packet, the most basic DOTS supplicant request 
should fit into one, yes.  But there are additional desirable options 
which would include multiple packets.

-----------------------------------
Roland Dobbins <[email-masked]>

---

From: Tobias Gondrom <[email-masked]>
Date: Thu, 24 Sep 2015 16:53:09 -0700

>unclear why this is being rehashed yet again.

+1 

Best regards, Tobias 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Stefan Fouant <[email-masked]>
Date: Fri, 25 Sep 2015 00:27:15 +0000

>unclear why this is being rehashed yet again.

Agreed and apologies as I was not in Prague so I have not been synced up
on all that was discussed during that meeting. Looking forward to working
with all of you as we has out the use case requirements.

Stefan Fouant

---

From: Jelena Mirkovic <[email-masked]>
Date: Thu, 24 Sep 2015 17:36:48 -0700

It really sounds as if we'd need to start with use cases and work to
implementations, then turn back, revisit, rehash, etc. There are several
possible scenarios and we should give them names and support/work with all
of them.

1. On-demand trust establishment, sign for protection service. This
requires key exchange and TCP. Will work in some cases

2. I'm so clogged I cannot get messages back. I doubt that this is the case
for acks which are usually super-small and will fit in router queues where
larger packets won't but certainly in this case we cannot do on-demand
trust establishment.

3. I'm so clogged I cannot get messages out. I'd like automated mitigation
when this happens.

etc.

=========================

Jelena Mirkovic
Research Faculty
USC Information Sciences Institute
4676 Admiralty Way, Suite 1001
Marina del Rey, CA 90292
310-448-9170

On Thu, Sep 24, 2015 at 4:37 PM, Roland Dobbins <[email-masked]> wrote:

> Prague, both stateless and stateful transports are necessary.  It's unclear
> why this is being rehashed yet again.
>
> should fit into one, yes.  But there are additional desirable options which
> would include multiple packets.
>

---

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 25 Sep 2015 07:39:18 +0700

On 25 Sep 2015, at 7:36, Jelena Mirkovic wrote:

> implementations, then turn back, revisit, rehash, etc.

If we were starting from first principles in an intellectual vacuum, 
yes.

Fortunately, we aren't.

We've already discussed in a reasonable degree of detail the broad 
requirements, and we've also discussed the broad requirements; couple 
that with the skills and experience of those who're participating in 
this effort, and we can start at each and work simultaneously towards 
the middle.

---

From: Gilbert Clark <[email-masked]>
Date: Thu, 24 Sep 2015 20:46:24 -0400

> warranted, such that simply loss of heartbeats doesn¹t automatically imply

Well, my thought here is that a lost heartbeat is not necessarily 
indicative of a DDoS, only of a more general network issue somewhere 
between points A and B.  I would think heartbeats should therefore never 
be used (on their own) to trigger an automated mitigation.

-Gilbert

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 24 Sep 2015 22:02:14 -0400

On Thu, Sep 24, 2015 at 3:41 PM, Robert Moskowitz
<[email-masked]> wrote:
> Not quite so if this goes into the requirements document.  Of which Tiru,
> Andy, and I are the joint editors...
>
> acknowledgments to send to initiate a mitigation action."  Is really vague
> but covers the concern.  More meat would be good for the meal...

as a requirement: "Be stingy with network resources" seems ok, sure. I
don't think it's relevant if it's "during an attack" or not.

> reasonable time, an attack may be underway and mitigation should be

yikes, that seems like a poor plan... what if my detector is simply
offline for reasons not related to dos? (power cycle, power problems
in that rack/row, 'bad hardware')

-chris

>>> TLS session resumption without server-side state RFC5077 can possibly be
>>> used, but it still consumes 1 round trip before the "Help attack" message
>>> can be signaled. Another alternative is to go with TLS 1.3 which supports
>>> zero round-trip.
>>>
>>> -Tiru
>>>
>>>> to

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 24 Sep 2015 22:02:55 -0400

> maintenance activities or other things could potentially trigger a

this was my thinking, I should have read more of the thread :)

---

From: Andrew Mortensen <[email-masked]>
Date: Thu, 24 Sep 2015 23:34:09 -0400

> On Sep 24, 2015, at 10:02 PM, Christopher Morrow <[email-masked]> wrote:
> 
>> case?

Yes, please see the list archives:

<https://mailarchive.ietf.org/arch/msg/dots/ZcHZFvJzSE1zJopMDrjafjlQMDE <https://mailarchive.ietf.org/arch/msg/dots/ZcHZFvJzSE1zJopMDrjafjlQMDE>>

My expectation, based on my reading of other contemporary drafts at this stage, is that each draft will inform the other.

> this was my thinking,

Mine as well. Given the reasons you’ve both cited, I’ll go further and say servers/mitigators MUST NOT treat loss of heartbeat in either direction—client messages failing to reach the server, and vice versa—as grounds to begin mitigation. Loss of heartbeat/signal from the client is not an attack canary.

With respect to heartbeats generally, I discussed signal channel health a bit in my initial rough requirements draft prior to the last meeting:

	<https://tools.ietf.org/html/draft-mortensen-threat-signaling-requirements-00#section-3.1.1>

In my view, any successfully delivered message acts as a heartbeat.

andrew

---

From: "Teague, Nik" <[email-masked]>
Date: Fri, 25 Sep 2015 04:00:33 +0000

On 24/09/2015 23:34, "Dots on behalf of Andrew Mortensen"
<[email-masked] on behalf of [email-masked]> wrote:
>
>With respect to heartbeats generally, I discussed signal channel health a
>bit in my initial rough requirements draft prior to the last meeting:
>
>

It strikes me that we should allow for either end to initiate operator
triggered heartbeats to act as a ping across the signal channel to aid in
path troubleshooting.  I’m also inclined to think that padding may also be
an option in order to ensure a complete signal packet can be delivered
from the signaler to the handler.

Thanks,

-Nik

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 25 Sep 2015 00:17:21 -0400

> which would include multiple packets.

I was not rehashing stateful/less.  Rather what does constrained do to 
congested links mean and thus what are the requirements.

But I have some things to go on now.

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 25 Sep 2015 00:19:53 -0400

>>>>> through during an attack?

So that one did not stick on the wall...

:)

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 25 Sep 2015 02:06:42 -0400

>>>>>> work over a constrained link.  Is IPFix thus a good approach?

it's not clear (to me) what part ipfix has in the 'oh crap, attack!'
message process, let's skip that for now.

> So that one did not stick on the wall...

i've seen customers get 'far more than' 10gbps of traffic inbound to
them and end up with essentially empty outbound link. So... in that
case, with connectionless protocols the answer is: "full packets,
almost at line rate" (not realistic to expect 'line rate', but...

in the end there's lots of ways to mix this cake batter, but first:
"What do you want to say, to whom, with credentials or not?" sorts of
things really ought to get sorted out.

---

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 25 Sep 2015 16:08:21 +0700

On 25 Sep 2015, at 7:46, Gilbert Clark wrote:

> I would think heartbeats should therefore never be used (on their own) 
> to trigger an automated mitigation.

Normally, I would agree.  However, this is an implementation decision 
and has nothing to do with the DOTS protocol itself.

---

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 25 Sep 2015 16:09:17 +0700

On 25 Sep 2015, at 11:00, Teague, Nik wrote:

> path troubleshooting

Triggered re-registration can serve this purpose.

> .  I’m also inclined to think that padding may also be

Concur.

---

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 25 Sep 2015 16:10:31 +0700

On 25 Sep 2015, at 11:17, Robert Moskowitz wrote:

> Rather what does constrained do to congested links mean and thus what 
> are the requirements.

It's highly situationally-specific.

Retry beaconing until supplicant status change is the answer for this.

---

From: Stefan Fouant <[email-masked]>
Date: Fri, 25 Sep 2015 13:11:33 +0000

>things really ought to get sorted out.

Another thing we may want to consider, almost all networking vendors worth
their salt allocate by default ~5% of bandwidth to Network Control via
precedence bit 111. Tagging DOTS signaling as such could ensure delivery
even in periods of high congestion (assuming end user has done nothing to
change classifications and schedulers).

Stefan Fouant

---

From: "Teague, Nik" <[email-masked]>
Date: Fri, 25 Sep 2015 13:23:53 +0000

Hi,

>change classifications and schedulers).

It also assumes that no bleaching occurs so would not be assured to
survive network boundaries.

Thanks,

-Nik

---

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 25 Sep 2015 20:24:24 +0700

On 25 Sep 2015, at 20:11, Stefan Fouant wrote:

> Tagging DOTS signaling as such could ensure delivery even in periods 
> of high congestion (assuming end user has done nothing to change 
> classifications and schedulers).

The BCP is to re-color on ingress, and we certainly don't want to 
interfere with control-plane traffic in high-congestion situations, 
thereby contributing to an outage.

Instead, one of our deployment recommendations should be to utilize QoS 
where/when available to reserve appropriate headroom for DOTS signaling. 
  Same idea, but under the control of the respective operators.

---

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 25 Sep 2015 20:28:14 +0700

On 25 Sep 2015, at 20:24, Roland Dobbins wrote:

> Instead, one of our deployment recommendations should be to utilize 
> QoS where/when available to reserve appropriate headroom for DOTS 
> signaling.  Same idea, but under the control of the respective 
> operators.

Note that this is in the absence of an out-of-band signaling channel, 
which is the ideal, but which sadly is going to be available in a 
minority of deployments.  We should recommend out-of-band where/when 
feasible, of course.

---

From: Stefan Fouant <[email-masked]>
Date: Fri, 25 Sep 2015 13:29:02 +0000

>survive network boundaries.

Very true, as many network operators do clear and/or reclassify code
points at the edge of their network. However, in this case all we are
concerned with is ensuring the scheduler on the outbound link from CPE or
similar device will treat such traffic with higher priority so as to get
the signal out in face of congested resources.

Stefan Fouant

---

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 25 Sep 2015 20:48:02 +0700

On 25 Sep 2015, at 20:29, Stefan Fouant wrote:

> However, in this case all we are concerned with is ensuring the 
> scheduler on the outbound link from CPE or

Again, the correct way to achieve this goal is via QoS.  We must not 
abuse precedence values.

---

From: "Teague, Nik" <[email-masked]>
Date: Fri, 25 Sep 2015 13:56:47 +0000

Hi,

>the signal out in face of congested resources.

I would need a lot of assurances that Vendor X was going to play nice with
my protected NC resources.  I agree with the view that this should be
managed by the operator to decide on their network.

Thanks,

-Nik

---

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 25 Sep 2015 21:01:46 +0700

On 25 Sep 2015, at 20:56, Teague, Nik wrote:

> my protected NC resources.

Stefan has the right idea; QoS is the best way to implement it.

---

From: Paul Ferguson <[email-masked]>
Date: Fri, 25 Sep 2015 07:05:07 -0700

On 9/25/2015 7:01 AM, Roland Dobbins wrote:

>> I would need a lot of assurances that Vendor X was going to play
>> nice with my protected NC resources.
> 

If you do not own the end-to-end path, 'QoS' is exactly like Pixie
Dust and unicorns,

- - ferg

- -- 
Paul Ferguson
PGP Public Key ID: 0x54DC85B2
Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2

---

From: Jérôme François <[email-masked]>
Date: Fri, 25 Sep 2015 16:08:21 +0200

Hi,

When a congestion occurs, the DOTS signaling could also be transmitted
through other, even non standard, channels. For example, the signaling
could be sent through available mobile communications with a chance they
are not under attack. This is of course highly dependent of the attacker
knowledge. Although selecting and evaluating what are the best
communication channels is probably not in the scope of the signaling
itself, the client and the controller should negotiate such channels
information beforehand (during the subscription or discover dynamically).

If using heartbeats, alternatives channels could be specified in the
heartbeat messages such that the controller can contact the client on
another channel if heartbeats are not received anymore.

jerome

Le 25/09/2015 16:05, Paul Ferguson a écrit :
> - ferg

---

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 25 Sep 2015 21:08:26 +0700

> If you do not own the end-to-end path, 'QoS' is exactly like Pixie 

We all know this, Paul, thanks.

The same constraint applies to dorking around with precedence.

A great deal of these deployments will consist of supplicants on 
endpoint networks signaling upstream to their transit providers.  So, in 
that very common deployment scenario, QoS can work just fine.

It's a different story with overlay MSSPs, of course.  But dorking 
around with precedence wouldn't help there, either.

---

From: Stefan Fouant <[email-masked]>
Date: Fri, 25 Sep 2015 14:09:26 +0000

On 9/25/15, 10:05 AM, "Dots on behalf of Paul Ferguson"
<[email-masked] on behalf of [email-masked]> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA256
>

My take is end-to-end path is orthogonal to the discussion. The main issue
is the last mile where the sending device might be contending for
resources. Typically, that¹s not a problem in the service provider core,
so I don¹t care how it¹s treated upstream, so long as the message gets out.

Stefan Fouant

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 25 Sep 2015 10:37:36 -0400

> Retry beaconing until supplicant status change is the answer for this.

I am guessing here that you do not mean 'beaconing' in the RF sense (eg 
802.11 BEACON of 802.15.4 SUPERBEACON frames).

I see that my work in RF networks has colored my view of bandwidth 
attacks.  Kind of forget that MANY wired PHYs are full duplex. (note 
that PHYs used in BACnet are shared bus, but not of interest here).

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 25 Sep 2015 10:39:14 -0400

> change classifications and schedulers).

Will ISPs buy into this?

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 25 Sep 2015 10:41:31 -0400

On 09/25/2015 09:24 AM, Roland Dobbins wrote:
> signaling.  Same idea, but under the control of the respective operators.

Sounds much better.  More leeway to how an ISP runs their network.

---

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 25 Sep 2015 21:42:17 +0700

> Will ISPs buy into this?

Nope.

They will in some cases buy into QoS, however.

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 25 Sep 2015 10:45:04 -0400

> If you do not own the end-to-end path, 'QoS' is exactly like Pixie

Very true, but here we are 'just' trying to get the message out of the 
congested attack area into a more congeal network.

---

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 25 Sep 2015 21:46:09 +0700

On 25 Sep 2015, at 21:37, Robert Moskowitz wrote:

> I am guessing here that you do not mean 'beaconing' in the RF sense 
> (eg 802.11 BEACON of 802.15.4 SUPERBEACON frames).

Correct!

;>

---

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 25 Sep 2015 21:47:52 +0700

> congested attack area into a more congeal network.

Concur 100%.

---

From: Stefan Fouant <[email-masked]>
Date: Fri, 25 Sep 2015 14:49:34 +0000

>congested attack area into a more congeal network.

Could not agree more. Most provider cores are over engineered. Our main
objective is getting the message out along that congested last mile.

Stefan Fouant

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 25 Sep 2015 10:52:20 -0400

> so I don¹t care how it¹s treated upstream, so long as the message gets out.

Depends on the solution fielded.  Some will and some won't the 
customer/provider decides.  Not us.

---

From: Jelena Mirkovic <[email-masked]>
Date: Fri, 25 Sep 2015 10:18:35 -0700

My point was not that we should wait or serialize. Instead I was saying
that we need not exclude use cases. We should list all/most possible use
cases and then designing protocol *modes* to work for each. Even if some
cases seem less likely to some of us. They may become more likely in some
environments.

Jelena Mirkovic
Research Faculty

On Thu, Sep 24, 2015 at 5:39 PM, Roland Dobbins <[email-masked]> wrote:

> If we were starting from first principles in an intellectual vacuum, yes.
>
> Fortunately, we aren't.
>
> requirements, and we've also discussed the broad requirements; couple that
> with the skills and experience of those who're participating in this
> effort, and we can start at each and work simultaneously towards the middle.
>
>

---

From: "Roland Dobbins" <[email-masked]>
Date: Sat, 26 Sep 2015 00:50:01 +0700

On 26 Sep 2015, at 0:18, Jelena Mirkovic wrote:

> Instead I was saying that we need not exclude use cases.

We will include a variety of likely use cases.

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 25 Sep 2015 16:40:29 -0400

>> (eg 802.11 BEACON of 802.15.4 SUPERBEACON frames).

Ah, I just 'found' it in the requirements document terminology section 
that I am going through for edits...