Subject: RE: [Diffserv] IPsec and DSCP/TOS values

From: Shahram Davari <[email-masked]>
Date: Thu, 7 Sep 2000 11:22:37 -0700

Hi,

Take a look at:

http://www.ietf.org/internet-drafts/draft-ietf-diffserv-tunnels-02.txt

regards,
Shahram

-----Original Message-----
From: Dave Hotlosz [mailto:[email-masked]]
Sent: Thursday, September 07, 2000 1:17 PM
To: [email-masked]'; dave hotlosz
Subject: [Diffserv] IPsec and DSCP/TOS values

Hi,
Has there been any resolution to the problem of IPsec and the DSCP
values being able to coexist? If there is could you please point me to
it.

If not I have a couple of suggestions and one recommendation..

Would it make sense for QoS to encapsulate the IPsec packets?
This would require a consistent data stream plumbing supported by all
implimentations to work and should be defined by the IETF.

One other approach could be to swap the  outer IP header IPsec value and
the inner IP header QoS value . This will also require that IPsec know
that this is a DSCP value.

The best approach I can think of right now may be to encapsulate the
IPsec packet and route it to a port address which is only used by IPsec
or QoS when IPsec packets are encapsulated by QoS. This will require
IPsec or Qos to have a port deamon listening or having QoS, IPsec or IP
route the packet to QoS or IPsec to strip the QoS encapsulation off and
pass it to IPsec.

Has any progress been made on the similar problem of IPsec and ECN
values?

Obviously QoS should supported IPsec packets but I don't see how in the
current specifications it would work.

Also in the case of tunnels (which may have IPsec packets), should QoS
classification be done on the IPsec packet and repeated for the tunnel
or should the tunnel just repeat the data already in the header in the
QoS area.

And one last question, related to tunnels,  is it recommended to
configure QoS per physical interface card or per assigned IP addresses?

I just think the DS domain ingress and egress plumbing and interaction
with other protocols has not been defined completly in any RFC/doc's to
date.

And if I' missed something I'll be happy to read any RFC/doc you can
point me too :)

Thanks,
    Dave

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: [email-masked]
Date: Mon, 11 Sep 2000 09:21:46 -0400

For a comprehensive treatment of ECN and IPsec, see:

http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ecn-02.txt

Both this and the diffserv-tunnels draft noted
earlier will be coming out as RFCs; the ECN draft
should be standards track and is intended to mandate
the necessary changes in handling the ECN bits by
IPsec tunnels.

The corresponding diffserv changes to IPsec aren't
in the offing at the moment because it's really not
possible to do a security analysis of diffserv to
the degree that ECN security was analyzed in the
above draft.

> implimentations to work and should be defined by the IETF.

Given that the problem involves IPsec tunnel mode
(IPsec transport mode is transparent to diffserv),
I don't see how another encapsulation helps.  At
egress the outer encapsulation would be stripped
and the result passed to IPsec, recreating the
original problem scenario.

> that this is a DSCP value.

Such a swap in the middle of an IPsec tunnel is impossible
for obvious reasons.  At tunnel egress, RFC 2401 currently
says that the outer DSCP is to be discarded.

> or should the tunnel just repeat the data already in the header in the

Both are applicable depending on the situation.  See
the diffserv-tunnels draft.

--David (author co-author of both drafts)

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------