Subject: RE: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 1 Feb 2005 03:41:59 -0800

Hi Steve/ Karen,

After the discussion with Brian (and checking rfc2983), I think the
following minor change can be added in section 5.1.2.1 and 5.1.2.2, for
the Inner Header at decapsulator: -

DSCP - constructed (9)

9. If the DSCP values changes a diffserv domain, the diffserv traffic
conditioning SHOULD be done in order to ensure that traffic exiting the
node is compatible with the egress node's diffserv domain.

Regarding the ECN part, I think I understand. The values ECT (0) and ECT
(1) can be there as is and CE is copied to make sure that in case of
congestion it is signaled to the endpoint. However this can lead to an
intermediate router changing the value maliciously to CE (but packets
could as well have been dropped by the intermediate router). I hope my
understanding is right here?

Thanks,
Vishwas
-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Tuesday, February 01, 2005 2:55 PM
To: Vishwas Manral
Cc: [email-masked]
Subject: Re: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt

The background for this is in RFC 2983 (and David Black <[email-masked]>
might be interested in this topic). But I think you're correct; my only
concern was to check that the decapsulator behavior is unchanged as far
as the QOS fields are concerned.

I believe the behavior required by RFC 2401, in the tables in section
5.1, remains correct: a decapsulator must not change the inner
TOS/DSCP value because any change that has ocurred in the the outer
header is potentially an exposure (to QOS-based DOS for example).

The prohibition is even stronger for the IPv6 Flow Label which now is
defined as immutable, so that is a very strong MUST NOT change.

The tables in 5.1.2.1 and 5.1.2.2 of 2401bis are the same (except
for ECN) so this is fine as-is. I really can't judge whether
there are any attacks available due to ECN twiddling in the outer
header.

    Brian

Vishwas Manral wrote:
> Hi Brian,
> 
> I hope this gets through before you leave. There are two points I
wanted
> to state: -
> 
> 1. The only fields we copy from the outer to the inner header are the
> DSCP/ ECN fields. The idea is the DSCP field in the inner header may
not
> be recognized in the domain and the best value would be the outer
field
> itself. Besides dropping ECN field (not copying the outer header)
could
> result in wrong treatment of packets.
> 2. If a router in the middle wanted to disrupt traffic by changing
DSCP
> it could easily do so by dropping the packet itself. So not copying
does
> not help at all.
> 
> Do let me know if I am off track completely?
> 
> Thanks,
> Vishwas
> 
> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Tuesday, February 01, 2005 1:03 PM
> To: Vishwas Manral
> Cc: [email-masked]
> Subject: Re: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt
> 
> I am about to leave for 3 weeks so I have no time to check the text,
> but it has always been considered wrong on security grounds to
> copy bits from the outer (unprotected) header into the decapsulated
> (protected) header. That is very clear in the IPsec RFCs and I hope
> it remains clear in the new ones.
> 
>      Brian
> 
> Vishwas Manral wrote:
> 
>>Hi Steve/ Karen,
>>
>>I am resending an older mail, in case it got missed in transit. 
>>
>>Although the security architecture talks about how the outer header is
>>generated from the inner header in tunnel mode while encapsulation, I
>>think the document completely misses the part of fields being copied
>>back into the inner header while decapsulation.
>>
>>I am CC'ing Brian Carpenter too, as he would probably have the best
> 
> view
> 
>>on this.
>>
>>Thanks,
>>Vishwas
>>________________________________________
>>From: [email-masked] [mailto:[email-masked]] On Behalf
>>Of Vishwas Manral
>>Sent: Monday, January 31, 2005 9:37 AM
>>To: [email-masked]
>>Subject: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt
>>
>>Hi Steve,
>>
>>I think the security architecture does not specify copying of DSCP and
>>ECN values from the outer header to the inner header in the case of
>>decapsulation for tunnel mode for both IPv4 and IPv6.
>>
>>DSCP values will not be copied directly however, depending on the
> 
> change
> 
>>of domain.
>>
>>Thanks,
>>Vishwas
>>
> 

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

---

From: Stephen Kent <[email-masked]>
Date: Tue, 1 Feb 2005 11:11:26 -0500

>node is compatible with the egress node's diffserv domain.

So, what you are suggesting is that if the receiver is in a different 
diffserv domain, then it should change the DSCP value apropos the 
receiver's domain, right? How would this be done, in practice, e.g., 
would one require a table to map between the DSCP values for each 
domain? I'm tempted to say this should be done outside the IPsec 
context, by the receiver, so that this is not another IPsec 
configuration item, e.g., part of the SPD.  We could  insert a note 
to that effect if folks agree.

>understanding is right here?

The ECN value is copied from the outer header to the inner header as 
described in the text, based on analysis David Black did a few years 
ago, and codified in RFC 2983. The notion is that a malicious router 
could do other evil things to packets comparable to what it can 
effect via changes to the ECN value, so it makes sense to copy the 
bit as directed, to support ECN functionality.

Steve