The issue is that if the packet is classified prior to being
encrypted, what do you do if a downstream ISP declines to
believe the classification (DCSP value) and wishes to reclassify
the packet? The proposal is to put enough semantics in the flow
label to allow some degree of classification.
Brian
Michael Thomas wrote:
>
> Bill Sommerfeld writes:
> > > Huh? I thought that one of the requirements for ESP was to
> > > copy the DSCP to the outer header. If I recall correctly,
> > > this bothers some people from a traffic analysis standpoint,
> > > but that seems to be part and parcel with QoS so that doesn't
> > > hold much water IMO.
> >
> > It seems that it would be appropriate for an implementation to
> > "reclassify" packets at the time of encapsulation into ESP -- the
> > packet is, after all, going through a logical trust boundary as it's
> > being encrypted..
>
> If I understand Brian's concern correctly, that may
> not necessarily be the case. The security gateway may
> be on egress from my network and hence controlled by me.
> If the service provider wants to reclassify those packets,
> it would need to be done at the next hop router from the
> security gateway (ie on a router they controlled).
>
> I'm still not sure I understand the policing they are
> trying to accomplish though; it seems sort of weird
> to have port level classification on the other side of the
> trust boundary to set the proper DSCP, unless it's just
> provide a service that could (should?) have been done at
> your egress router. Otherwise it seems like
> the user would be shooting themselves in the foot since
> the normal method is for the policer to police to a
> certain SLA on a given aggregate traffic class. This
> to my mind would argue for the classification to be
> done on *before* it is encapsulated with ESP, but the
> policing done on the aggregate where it doesn't care
> about the port data.
>
> Ie:
>
> luserdata------------>SG---------------------->AR
> (classifies, (polices
> remarks dscp, SLA against
> encrypts) DSCP, remarks)
>
> Mike
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page: http://playground.sun.com/ipng
> FTP archive: ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [EMAIL PROTECTED]
> --------------------------------------------------------------------
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished Engineer, Internet Standards & Technology, IBM
On assignment for IBM at http://www.iCAIR.org
Board Chairman, Internet Society http://www.isoc.org
"We shall need a number of efficient librarian types
to keep us in order." - Alan Turing, 1947.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
