Subject: [AAA-DOCTORS] FW: PRELIMINARY Agenda and Package for December 14, 2006 Telechat

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Fri, 8 Dec 2006 12:08:12 +0200

Please see below the preliminary agenda of the December 14, 2007 IESG
telechat. If there are any comments or issues with the documents brought
to the IESG for approval, please send me an e-mail until December 13,
2007 COB. 

Thanks and Regards,

Dan

-----Original Message-----
From: IESG Secretary [mailto:[email-masked]] 

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 New Item
  o draft-ietf-ccamp-rsvp-te-exclude-route-06.txt
    Exclude Routes - Extension to RSVP-TE (Proposed Standard) - 1 of 6 
    Token: Ross Callon
  o draft-ietf-ips-iscsi-nodearch-key-03.txt
    Declarative Public Extension Key for iSCSI Node Architecture
(Proposed
 
    Standard) - 2 of 6 
    Note: Document Shepherd: David Black ([email-masked]) 
    Token: Lars Eggert
  o draft-ietf-tsvwg-sctp-padding-02.txt
    Padding Chunk and Parameter for SCTP (Proposed Standard) - 3 of 6 
    Note: PROTO Document Shepherd: James Polk 
    Token: Lars Eggert
  o draft-ietf-dkim-base-07.txt
    DomainKeys Identified Mail (DKIM) Signatures (Proposed Standard) - 4
of 6 
    Token: Russ Housley
  o draft-ietf-mpls-rsvp-te-p2mp-06.txt
    Extensions to RSVP-TE for Point-to-Multipoint TE LSPs (Proposed
Standard) - 
    5 of 6 
    Token: Ross Callon
  o draft-ietf-rohc-rfc3095bis-framework-04.txt
    The RObust Header Compression (ROHC) Framework (Proposed Standard) -
6
of 6 
    Token: Magnus Westerlund

2.1.2 Returning Item
  o draft-ietf-mip6-ikev2-ipsec-07.txt
    Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture 
    (Proposed Standard) - 1 of 2 
    Note: PROTO Shepherd is Basavaraj Patil
<[email-masked]> 
    Token: Jari Arkko
  o draft-ietf-radext-delegated-prefix-05.txt
    RADIUS Delegated-IPv6-Prefix Attribute (Proposed Standard) - 2 of 2 
    Note: PROTO Shepherd: Bernard Aboba <[email-masked]>. Back
on 
    the agenda to check whether Mark's concerns have been addressed. 
    Token: David Kessens

2.2 Individual Submissions
2.2.1 New Item
  o draft-andersson-rtg-gmpls-change-07.txt
    Change Process for Multiprotocol Label Switching (MPLS) and
Generalized 
    MPLS (GMPLS) Protocols and Procedures (BCP) - 1 of 1 
    Note: Brian shepherds on behalf of the Routing ADs 
    Token: Brian Carpenter

2.2.2 Returning Item
NONE

3. Document Actions

3.1 WG Submissions
	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.1.1 New Item
  o draft-ietf-dccp-tfrc-voip-07.txt
    TCP Friendly Rate Control (TFRC): the Small-Packet (SP) Variant 
    (Experimental) - 1 of 4 
    Note: PROTO Document Shepherd: Gorry Fairhurst 
    Token: Lars Eggert
  o draft-ietf-mboned-maccnt-req-04.txt
    Requirements for Accounting, Authentication and Authorization in
Well

    Managed IP Multicasting Services (Informational) - 2 of 4 
    Note: Marshall Eubanks is the Document Shepherd 
    Token: David Kessens
  o draft-ietf-bmwg-hash-stuffing-07.txt
    Hash and Stuffing: Overlooked Factors in Network Device Benchmarking

    (Informational) - 3 of 4 
    Note: Al Morton is the Document Shepherd 
    Token: David Kessens
  o draft-ietf-v6ops-ipsec-tunnels-04.txt
    Using IPsec to Secure IPv6-in-IPv4 Tunnels (Informational) - 4 of 4 
    Note: Fred Baker is the document shepherd 
    Token: David Kessens

3.1.2 Returning Item
NONE

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
  o draft-heffner-frag-harmful-03.txt
    IPv4 Fragmentation Considered Very Harmful (Informational) - 1 of 1 
    Token: Lars Eggert

_______________________________________________
AAA-DOCTORS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/aaa-doctors

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 9 Dec 2006 14:50:50 -0800 (PST)

Review of draft-ietf-mboned-maccnt-req-04.txt

Overall:  

Although this document mentions MSEC in Section 3.2, 
in a number of places it makes assertions that seem to 
ignore MSEC, or imply that it is deficient in some way,
without explaining why this is true.  

One of the reasons that MSEC was developed was because
of the security issues inherent in attempting to authenticate
and account for usage via IGMP.   Since any listener on the 
path can access multicast traffic,  access to content can't be
controlled by authenticating IGMP, it can only be controlled 
by encrypting the content.  While Section 3.3 talks about
why the document does not apply to shared media,  the
use of shared media multicast is quite widespread so that
this restriction seems quite severe. 

This document talks about usage-based billing. As noted in RFC 2975, 
there may be legal requirements associated with usage-based billing, 
such as requirements on the reliability of accounting transport as well
as the accuracy of usage determination.  It was not clear that  this 
document takes those issues into account, and as a result, solutions based 
on this requirements document may not pass scrutiny. 

In a number of places, it is unclear why requirements relate specifically 
to AAA, as opposed to management facilities made available in switches 
and routers. 

Overall, there are enough problems with this document, that publication
in its current form is inadvisable. 

More detailed comments
----------------------------------

"    IP multicasting is becoming widely used as a method to save 
     network resources such as bandwidth or CPU processing power of the 
     sender's server for cases where a large volume of information 
     needs to be distributed to a large number of receivers."

While IP multicasting always saves resources on the sender, on wireless
link it does not necessarily save network resources, because multicast 
traffic may  have to be sent at lower rate than unicast traffic.   For example, in 
IEEE 802.11 networks an Access Point will send multicast/broadcast traffic 
at the lowest supported rate, in order to be assured of reaching all 
potential receivers, whereas unicast traffic can be sent at the highest rate that 
can be supported by link conditions.   As a result, sending a packet via 
link layer multicast may consume more resources than replicating the same packet via 
link layer unicast.  

As an example, consider an IEEE 802.11n network with a minimum supported 
rate of 1 Mbps, and a maximum supported rate of 200 Mbps.  In this 
situation, a frame sent via link layer multicast would consume as much network 
resources as 100 frames sent at the maximum rate.  Unless there were 100 potential 
receiver, it would therefore make more sense to send the packet via 
unicast.  Of course these considerations do not apply on wired links where multicast 
traffic is sent at the same rate as unicast traffic. 

     IP multicasting can be used to distribute free material 
     efficiently, but there are limitations to multicasting in usage 
     models where usage accounting is necessary, such as many 
     commercial applications. These limitations have prevented the 
     widespread deployment of multicasting.

I believe that it is an exaggeration to state that accounting issues are 
the primary reason why multicast has not been deployed on a widespread 
basis.   I say this as someone who was involved in one of the earliest 
commercial multicast service offerings.   In my experience, there were 
quite a few issues that were as or more important, including problems of 
traffic engineering, diagnostics, user-interest, etc.  Later on the 
document does talk about the "on demand" versus other multicast delivery 
mechanisms, but I think the document could be more balanced here. 

    Then, the 
     multicast router replicates the data to any link which has at 
     least one client requesting the information.    In this process, no 
     eligibility check is conducted.  Any client can receive information 
     just by requesting it.  In other words, the current standards do 
     not provide multicasting with authorization or access control 
     capabilities sufficient to meet the requirements of accounting. 

Given the discussion of MSEC in Section 3.2 I do not understand
this statement.   If MSEC is used, why wouldn't it be possible to
authenticate receivers and account for usage? 

    This is the major reason why multicasting is only used for cases 
     where no user-based accounting capabilities are necessary.    

I also don't understand this statement given the discussion of MSEC. 
Are you saying that MSEC is inadequate or undeployable?  If so, then
the reasons should be stated.  

    For example, accounting is needed if one 
     wants to charge for distributed information on a non-flat-fee 
     basis.

RFC 2975 describes the requirements for usage-based billing;  among
other things, the requirements are considerably greater for usage-based
billing because in those situations packets = money.  That means that
accurate usage-determination and reliable transport is not just a "nice to 
have" as it might be if the accounting data were only used for traffic 
engineering;  they may actually be a legal requirement. 

Section 3.2
      
"   The functional requirements do not require content 
     encryption although it might solve some of the related problems.  
     At this point, it is not yet clear whether encryption would be 
     part of a solution and if so, what other components (if any) would 
     also be required. "

The document does not discuss what the "related problems" are, or
provide a reference to such a discussion.  The result is that on
reading  this paragraph I'm left without an understanding of what
the issues are -- or why content encryption is not a requirement. 

Section 3.3

    "However, IP 
     multicast solutions with shared Layer 2 access media between the 
     user and multicast router and no logical user separation (e.g. 
     Ethernet with shared links and no VLAN) are out of scope of this 
     memo. "

Why is this out of scope?  As I understand it, virtually all wireless 
media fit within this category, as do technologies such as EPON.   Earlier 
an argument is made that the accounting functionality is more or less the
same for MSEC as opposed to other methods, so why not just say that
the IGMP-based approach doesn't work for these cases?

Section 4

     Also, it is necessary to identify the source 
     (user) of each request (e.g., join/leave) for user accounting 
     purposes. 

Identifying the IP address originating a request is not the same thing as 
determining
the user.   

     With current protocols (IGMP/MLD), the sender cannot distinguish 
     which receivers (end hosts) are actually receiving the information.  
     The sender must rely on the information from the multicasting 
     routers. This can be complicated if the sender and routers are 
     maintained by different entities. 

I think you need to distinguish the inability to determine which 
receivers are receiving the information on a shared media (which will be
the case even with authentication).

     (2) Issue of Network Resource Protection 
      
     In order to guarantee certain QoS it is important for network 
     providers to be able to protect their network resources from being 
     wasted, (either maliciously or accidentally). 
      
     For comparisons sake, in the case of unicast this issue can be 
     resolved e.g. by using RSVP. 

Why is RSVP not relevant to the multicast case (particularly since it
supports authentication)? 

     The network may need to control the combined bandwidth for all 
     groups at the physical port of the edge router or switch so that 
     these given physical entities are not overflowed with traffic. 

Why is this a AAA requirement and not a QoS requirement? 

     (2.3) Control mechanism of number of groups delivered from a 
          physical port of edge router and switch 

Why is this a AAA requirement (as opposed to a requirement for
management functionality on a switch or router)?  

     To assemble such an understanding of end-user behavior, it is 
     necessary to precisely log information such as who (host/user) is 
     accessing what content at what time (join action) until what time 
     (leave action).  The result of the access-control decision (e.g. 
     results of authorization) would also be valuable information.

If we are talking about usage-based billing, we will need more than 
this.  We will need some assurance that the accounting data itself
is being transported reliably.  There may be also issues arising
from loss of IGMP join/leave messages.  For example, if a leave
is lost, will a user be charged inappropriately?