Subject: [IPsec] Acquiring DSCP value(s)

From: Joy Latten <[email-masked]>
Date: Fri, 14 Sep 2007 15:57:37 -0500

RFC 4301 makes reference to DSCP and says "the IPsec implementation
MUST permit establishment and maintenance of multiple SAs between a 
given sender and receiver, with the same selectors." DSCP
acts as "classifier".
It also specifies in section 4.4.2.1 a DSCP field in an SAD entry.
This field holds DSCP values allowed for packets using the SAD entry.

I do not understand how the DSCP values are acquired
for the SA entry? Is DSCP values acquired via IKE negotiation 
and/or manual SA configuration?  

Regards,
Joy

_______________________________________________
IPsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Dan McDonald <[email-masked]>
Date: Fri, 14 Sep 2007 17:41:06 -0400

> and/or manual SA configuration?  

The RFC says something about this already:

RFC4301> Distribution of traffic among these parallel SAs to support QoS is
RFC4301> locally determined by the sender and is not negotiated by IKE.

The same code that sets the DSCP on outbound packets can add data to your
outbound-SA-selection routine.  As for the SAs themselves, their DSCP values
are set locally by your implementation, whether it's a manual-SA program or a
key management daemon.

Thanks for the reminder, BTW, that yet-another input to any PF_KEYv3 work is
having a DSCP value on ACQUIRE which is taken from the triggering packet,
which is then in turn fed back into any ADDed or UPDATEd SAs done by a local
Key Management daemon on behalf of that ACQUIRE.

For automated key management, the responder-side of such a negotiation can
get tricky, and perhaps that's what generated your question.  The first time
you get a child-SA request for selectors <laddr, raddr, lport, rport, proto>,
how do you know which DSCP to use on your response traffic?

I honestly haven't worked enough with diffserv & friends to know the answer
to that question, but I think I've reduced the problem scope to
responder-side processing for automated key management (like IKEv2).

Dan

---

From: Joy Latten <[email-masked]>
Date: Fri, 14 Sep 2007 18:09:25 -0500

> RFC4301> locally determined by the sender and is not negotiated by IKE.
Yes, I saw this statement... I had assumed, for example, that if I have
3 SAs with same selectors, but different DSCP values, I thought the
outbound packet would select the SA whose DSCP value matched his own.
I had assumed the DSCP value differentiated the SAs.
I don't know much about DSCP and am reading/scanning its rfc, but I had
also assumed the outbound packet would have its DSCP value by this time.

RFC 4301, section 4.4.2.1 said that the DSCP field in SA was the set of
values allowed for packets carried over this SA. So I had assumed
that determined how the traffic would be distributed over the parallel
SAs. So when I read rfc again and saw the statement you pointed out, I
worried that I'd misinterpreted and needed clarification.

> are set locally by your implementation, whether it's a manual-SA program or a
Ok, thanks for clearing that up for me. 
I had read/scanned rfc 4306 but didn't see anything specific. 
It would be an attribute as far as IKE is concerned, right? But what
transform type? Or does it matter?

> Key Management daemon on behalf of that ACQUIRE.

I have not thoroughly examined some of the other SA entries, but am
wondering would bypass-dscp, bypass-df, and stateful fragment checking
flag be candidates too?   

> how do you know which DSCP to use on your response traffic?
Yep, I had wondered about that too.  

Thanks!

Regards,
Joy Latten

---

From: <[email-masked]>
Date: Mon, 17 Sep 2007 11:12:15 +0300

Joy Latten wrote:

> > The same code that sets the DSCP on outbound packets can add data
> > to your outbound-SA-selection routine.  As for the SAs themselves,
> > their DSCP values are set locally by your implementation, whether
> > it's a manual-SA program or a key management daemon.
> 
> It would be an attribute as far as IKE is concerned, right? But 
> what transform type? Or does it matter?

It's not an IKE attribute or transform type, because it's not
negotiated in the protocol. 

In other words: you can use IKE to create multiple IPsec SA pairs, 
but it's not possible to negotiate which SA pair gets used for 
which DSCP. That's left as a local matter: your implementation
might send outbound packets with DSCP values A,B,C via one SA, 
and all other DSCPs via a second one. Or you might create more 
than two SA pairs. And so on...

Best regards,
Pasi