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]
--------------------------------------------------------------------
