Subject: [dns-dir] Preliminary agenda for the 8/14 IESG Telechat

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 8 Aug 2008 18:55:02 +0200

Please find below the preliminary agenda of the 8/14 IESG telechat.
Please send me your questions, concerns and comments until 8/13 COB the
latest. 

Thanks and Regards,

Dan

2. Protocol Actions 
Reviews should focus on these questions: "Is this document a
reasonable basis on which to build the salient part of the Internet
infrastructure? If not, what changes would make it so?" 

2.1 WG Submissions
2.1.1 

- Information Model and XML Data Model for Traceroute Measurements
(Proposed Standard) - draft-ietf-ippm-storetraceroutes-10.txt 
- Transport Mapping for Syslog (Proposed Standard) -
draft-ietf-syslog-transport-tls-13.txt 
- Definitions of Textual Conventions for Pseudowires (PW) Management
(Proposed Standard) - draft-ietf-pwe3-pw-tc-mib-14.txt 
- Guidelines for Application Designers on Using Unicast UDP (BCP) -
draft-ietf-tsvwg-udp-guidelines-09.txt  
- Simple Network Management Protocol (SNMP) Context EngineID Discovery
(Proposed Standard) - draft-ietf-opsawg-snmp-engineid-discovery-03.txt
- Internet Message Store Events (Proposed Standard) -
draft-ietf-lemonade-msgevent-06.txt 

2.1.2 Returning Item        

- A Two-way Active Measurement Protocol (TWAMP) (Proposed Standard) -
draft-ietf-ippm-twamp-09.txt 

2.2 Individual Submissions
2.2.1 New Item         

- IANA Considerations for the IPv4 and IPv6 Router Alert Option
(Proposed Standard) - draft-manner-router-alert-iana-03.txt 
- Extensions to the IODEF-Document Class for Reporting Phishing, Fraud,
and Other Crimeware (Proposed Standard) -
draft-cain-post-inch-phishingextns-05.txt   
  
3. Document Actions

3.2 Individual Submissions Via AD 
Reviews should focus on these questions: "Is this document a reasonable
contribution to the area of Internet engineering which it covers? If
not, what changes would make it so?"

3.2.1 New Item         

- Basic Password Exchange within the Flexible Authentication via Secure
Tunneling Extensible Authentication Protocol (EAP-FAST) (Informational)
- draft-zhou-emu-fast-gtc-04.txt 
- Dynamic Provisioning using Flexible Authentication via Secure
Tunneling Extensible Authentication Protocol (EAP-FAST) (Informational)
- draft-cam-winget-eap-fast-provisioning-09.txt
- Media Gateway Control Protocol Fax Package (Informational) -
draft-andreasen-mgcp-fax-08.txt 

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

---

From: Peter Koch <[email-masked]>
Date: Tue, 12 Aug 2008 11:09:49 +0200

Dan,

> Please send me your questions, concerns and comments until 8/13 COB the

a couple of drafts match DNS related keywords.  I've looked into the following

> draft-ietf-tsvwg-udp-guidelines-09.txt  

Interesting from the DNS perspective is that our use of EDNS0 would likely
be in conflict with "3.2.  Message Size Guidelines".

Another size related issue is asymmetry between requests and responses
in UDP based protocols intended for Internet wide use.  Under particular
circumstances, this asymmetry can be abused for "amplification attacks".
We know this for a subset of DNS, but any UDP based protocol that would
respond with large chunks to arbitrary data would be vulnerable.
As an unrealistic example, imagine a re-invention of the "chargen" protocol.

Full disclosure: I've already mentioned this latter issue to the authors,
  but the conclusion was to wait for security review.

> draft-cain-post-inch-phishingextns-05.txt   

See extra message with more detailed comments.  No idea what to recommend
here;  the overall diction and idea don't seem to fit IETF style very
well, but then I understand this is a leftover from the INCH WG - the
history of which I just don't know.  Generally appears gTLD centric
with a couple of editorial and/or language issues.

-Peter

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 12 Aug 2008 11:44:05 +0200

Hi Peter,

Thanks for your reviews. 

See in-line wrt. draft-ietf-tsvwg-udp-guidelines-09.txt 

Dan

> -----Original Message-----
> From: Peter Koch [mailto:[email-masked]] 

> Interesting from the DNS perspective is that our use of EDNS0 
> would likely be in conflict with "3.2.  Message Size Guidelines".

This is not something new or unexpected. The Transport Considerations
section of RFC2671 would be probably written differently today. I do not
think that the document needs to be modified in any way, do you or
somebody else think differently? 

> 
> Another size related issue is asymmetry between requests and 
> responses in UDP based protocols intended for Internet wide 
> use.  Under particular circumstances, this asymmetry can be 
> abused for "amplification attacks".
> We know this for a subset of DNS, but any UDP based protocol 
> that would respond with large chunks to arbitrary data would 
> be vulnerable.

I do not know if SEC-DIR included this in their review, and I do not see
yet the SEC Ads having entered a position.  How would this change the
guidelines as they currently show up in the document? Should asymmetry
between requests and responses be discouraged, or does it need to be
mentioned in the Security considerations sections of protocol documents
that may have this characteristic?

---

From: Peter Koch <[email-masked]>
Date: Tue, 12 Aug 2008 18:36:57 +0200

Hi Dan,

> somebody else think differently? 

no, the document is fine, as I understand it won't be in the way of advancing
EDNS0 on the standards track.

> > abused for "amplification attacks".
[...]

> that may have this characteristic? 

I think it's difficult to generally discourage the size asymmetry, because
its effect depends on multiple factors only known when the protocol is
designed.  Pointing out the issue to be addressed in that particular
protocol's security considerations is absolutely sufficient IMHO
and up to the security folks whether any such pointer is necessary here.

-Peter

---

From: Ron Bonica <[email-masked]>
Date: Thu, 14 Aug 2008 12:36:26 -0400

Peter,

Thanks for the heads up. The Transport ADs didn't post a ballot for this 
draft, so we couldn't vote on it or register comments. This document 
will return to the agenda in two weeks.

                                     Ron

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 15 Aug 2008 11:57:37 +0200

Actually a ballot was possible (accessed from the IETF tracker) and I
entered a DISCUSS on the asymmetry issue. Lars proposed the following
solution: 

> How about adding this sentence to the first paragraph of the security
considerations section: "Applications that respond to short requests
with potentially large responses are vulnerable to amplification
attacks, and SHOULD authenticate the sender before responding. The
source IP address of a request is not a useful authenticator, because it
can be spoofed."

Dan

> From: Ron Bonica [mailto:[email-masked]] 
> Sent: Thursday, August 14, 2008 7:36 PM
> To: Peter Koch
> Cc: Romascanu, Dan (Dan); IETF DNS Directorate
> Subject: Re: [dns-dir] Preliminary agenda for the 8/14 IESG Telechat
> 
> Peter,
> 
> Thanks for the heads up. The Transport ADs didn't post a 
> ballot for this draft, so we couldn't vote on it or register 
> comments. This document will return to the agenda in two weeks.
> 
>                                      Ron
> 
> 
> Peter Koch wrote:
> > Dan,
> > 
> >> Please send me your questions, concerns and comments until 
> 8/13 COB 
> >> the latest.
> > 
> > a couple of drafts match DNS related keywords.  I've looked 
> into the 
> > following
> > two:
> > 
> > Interesting from the DNS perspective is that our use of EDNS0 would 
> > likely be in conflict with "3.2.  Message Size Guidelines".
> > 
> > in UDP based protocols intended for Internet wide use.  Under 
> > particular circumstances, this asymmetry can be abused for 
> "amplification attacks".
> > We know this for a subset of DNS, but any UDP based protocol that 
> > would respond with large chunks to arbitrary data would be 
> vulnerable.
> >> - Extensions to the IODEF-Document Class for Reporting Phishing, 
> >> Fraud, and Other Crimeware (Proposed Standard) -
> > See extra message with more detailed comments.  No idea what to 
> > recommend here;  the overall diction and idea don't seem to 
> fit IETF 
> > style very well, but then I understand this is a leftover from the 
> > INCH WG - the history of which I just don't know.  
> Generally appears 
> > gTLD centric with a couple of editorial and/or language issues.
> > 
> > -Peter