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

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 1 Feb 2005 00:48:07 -0800

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: Brian E Carpenter <[email-masked]>
Date: Tue, 01 Feb 2005 10:25:22 +0100

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