Subject: [drinks] DRAFT minutes of the DRINKS design team call on 2012-05-08

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 9 May 2012 14:21:16 +0000

DRINKS Design Team Call DRAFT minutes - May 08 2012, 10am - 11am EST
====================================================================

Participants:
-------------
- Ken Cartwright
- Sumanth Channabasappa 
- Vikas Bhatia
- Alexander Mayrhofer
- Dean Willis

Agenda
------

1/ Document open issues

Action items
------------

0/ Research and describe status of the four remaining issues (as below)

Minutes of the call
-------------------

Sumanth opens the call, proposes in order to address the open issues to:

- list all open items
- get a clear definition of each of them
- decide how to proceed with each item

There was one open item from posting the new docs, which was the discussion
about "peering" (combined with the "route group offer" generalisazion)

Furthermore, the internationalization issue is also still open. Then 
more open items were added in Paris
 
(Sumanth opens up the .rtf notes that he uploaded to the meetings 
material page - they seem to be different from what is shown on the 
tools.ietf.org page.)

Two more issues were discussed in Paris, which makes the total list of 
open issues:

- route group type issue (added during Paris meeting)
- denial of service considerations (added during Paris)
- peering / route group offer generalization 
- internationalization

(Ken noted that i18n is still open - added as fourth items)

The status of each of the items was then discussed.

No concensus was reached on the route group type in Paris - discussion 
about value of that mechanism.

Peering: had a few emails around that, Dean posted a proposal text to the 
mailing list.

Denial of Service: Jeremy presented, we might need additional text in the 
document to address those concerns.

Internationalization: Text proposed, comments from Ken received. 

Vikas an Ken note that they have limited resources during this and 
the next week.

Sumanth proposes that we should assign each item to a participant of the call,
who should then research the current status of the item, so that we 
could address the item with all available information during one of the next 
calls.

Sumanth proposes to take on DoS considerations, Alex proposes taking on i18n.

There is an discussion about what exactly the "Peering / route group offer" 
open item should compromise, and whether that wasn't already solved? There 
is agreement that we won't change the core of the protocol

Ken notes: if we removed it, do we create a "peering protocol" 
without any peering? 
Ken said he didn't like the new intro text, but he can live with it.

Dean: The problems of of how/whether we do peering, and the route record generalization (using URIs) are differnt problems. ("SED data type" thread).

DoS: Ken notes that for example EPP do not mention DoS considerations at all.. Sumanth says that DoS is part of the security considerations in most cases.

Dean: RFC3552 describes how to consider DoS in security consideration sections. 

Alex: summing up the individual issues was to be assigned to a certain person:

- route group type issue (added during Paris meeting) => Alex
- denial of service considerations (added during Paris) => Ken 
- peering / route group offer generalization => Sumanth
- internationalization => Alex

Sumanth originally offered to take the DoS issue, Ken offeres to take 
that one over.

Ken: keep i18n simple. 
Alex: Yes, should be limited to things that are required to ensure interopability.

Next call: next wed at usual time. summarize issues until then.

Call concludes.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 9 May 2012 14:37:57 +0000

> DoS: Ken notes that for example EPP do not mention DoS considerations
> at all.. Sumanth says that DoS is part of the security considerations
> in most cases.

It's most definitely mentioned in the EPP specs. Please see the last paragraph of section 8 of RFC 5734, "Extensible Provisioning Protocol (EPP) Transport over TCP".

Scott

---

From: "Cartwright, Ken" <[email-masked]>
Date: Wed, 9 May 2012 12:53:53 -0400

My apologies.  I missed it in there at the end of the security considerations section:

EPP TCP servers are vulnerable to common TCP denial-of-service
   attacks including TCP SYN flooding.  Servers SHOULD take steps to
   minimize the impact of a denial-of-service attack using combinations
   of easily implemented solutions, such as deployment of firewall
   technology and border router filters to restrict inbound server
   access to known, trusted clients.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hollenbeck, Scott
Sent: Wednesday, May 09, 2012 10:38 AM
To: Alexander Mayrhofer; [email-masked]
Subject: Re: [drinks] DRAFT minutes of the DRINKS design team call on 2012-05-08

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

This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

---

From: Dean Willis <[email-masked]>
Date: Wed, 9 May 2012 14:11:59 -0500

>   access to known, trusted clients.

Yep. By RFC 4732 standards, it's not much of an analysis of DoS in the context of EPP. It's like the good old days when "Use a firewall" was considered an adequate Security Considerations section.

On the other hand, it may well be enough of an analysis for the constituency of the protocol, which might as well be published by the WGNETF (that's Walled Garden Network Engineering Task Force). There's no apparent expectation of using this protocol on the public net. Should there be?

--
Dean

---

From: "Cartwright, Ken" <[email-masked]>
Date: Wed, 9 May 2012 15:48:42 -0400

EPP is used on the "public net" (at least it was when I implemented and ran my EPP clients several years ago, and I'm fairly certain it still is, by multiple implementers).  And SPP will be used on the "public net".

Ken

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Wednesday, May 09, 2012 3:12 PM
To: Cartwright, Ken
Cc: Hollenbeck, Scott; Alexander Mayrhofer; [email-masked]
Subject: Re: [drinks] DRAFT minutes of the DRINKS design team call on 2012-05-08

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 11 May 2012 00:22:58 -0500

> EPP is used on the "public net" (at least it was when I implemented and ran my EPP clients several years ago, and I'm fairly certain it still is, by multiple implementers).  And SPP will be used on…

OK, then that argues for a slightly higher standard of documentation on things like security/DoS analysis.  This shouldn't be a huge amount of work, just a couple of paragraphs citing the usual fixes for TCP servers like edge filters, etc. from the RFC, and whatever we conclude about the DoS concern.  Almost everything is doable "by reference" now.
--
Dean