Subject: RE: [Ieprep] TCP PEPs and Priority-based Mechanisms

From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" <[email-masked]>
Date: Mon, 22 Dec 2003 14:55:50 -0600

> Actually you hit the one compelling reason, IMHO, for shifting to IPv6.
> Note that I'm here at the network layer, not transport.  IPv6 supports
> header extensions -- the extension+payload get encrypted but the base
> header (which includes DSCP) does not.  So any network level QoS you
> choose to use is unaffected by IPSec.
 
This will lead to denial of QoS attacks. One can easily change the 
subscription by modifying the headers. But, lets first see some 
flow-label enabled packets across the Internet to talk about the 
operational security implications. btw, one can still encrypt 
flow-labels using tunnel mode. please read the recently approved
proposed standard ( IPv6 flow label spec)

> Back at the transport layer, I'm just not terribly turned on by PEPs.
> The RFC is useful because it surveys a fairly wide set of bandaids that
> fall under the general PEP category.   But these remain bandaids until
> we grapple with the nextgen transport protocol issue.
 
nextgen transport protocol? DCCP is not a next generation protocol; it 
just provides option for various cc profiles, mibility and multihoming
support and security features. As for tranport, incremental approach by 
TCP extenstions works better (e.g., widespread SACK deployment.) The one 
you mention, XCP does major changes; its a interesting research work but 
support for high speed networks is not a pressing problem. In short, we 
will never see any nextgen transport protocol.
 
btw, protocol boosters like PEP are not paper model; they have seen a lot 
of deployment. So, we should know to live with them. We have came a long
way from the pilc work. 

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

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 22 Dec 2003 17:08:02 -0600

At 11:50 AM 12/22/2003 -0800, Rex Buddenberg wrote:
>Kimberly,

How does IPv6 behave differently than v4 with respect to IPsec?

What do you do to limit or prevent remarking DSCPs to mean something other 
than what the sender (or domain at the edge) legitimately mean?

In other words, where is the integrity protection for DSCP marking? Where 
is the authorization mechanism for DSCP marking?

How do you prevent an eavesdropper from looking for the pattern of packets 
(perhaps with the same length) occurring every 20ms or so to see if a 
particular stream is a call or not (perhaps to do something to that stream 
- or just the IPv4 or v6 header to muck with it (like change the DSCP value))?

>On Mon, 2003-12-22 at 11:16, King, Kimberly S. wrote:
> > > The use of Performance Enhancing Proxies introduces several issues
> > >    which impact security.
> >
> > Yes, you are right to point that out but unfortunately that's just the way
> > it is.  Even if we forget about PEPs for the moment.
> >
> > Use IPsec but mark the packets using DSCPs kept in the clear.  Consider
> > traffic analysis...sit back and watch the codepoints (lots of high priority
> > MLEF?)
> >
> > "
> > * Security UP =>Â­ Bandwidth Utilization DOWN
> > * Security UP =>Â­ Performance DOWN
> > * Tunnels Tunnels Tunnels and more Tunnels
> > * Performance DOWN => Security DOWN
> > =>  User turns OFF Security to make system usable!
> > * Thus, we need more bandwidth to ensure security.
> > "
> > http://spacecom.grc.nasa.gov/icnsconf/docs/2002/10/Session_E1-5_Ivancic.pdf
> >
> > I think one makes the choices that best fit because there is no free lunch.
> > :-(
>--
>b
>
>

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented

---

From: "Eagan, Christopher" <[email-masked]>
Date: Tue, 23 Dec 2003 09:40:14 -0500

> than what the sender (or domain at the edge) legitimately mean?

1.  In some scenarios can you assume all nodes are trusted to behave well (possibly by virtue of them being able to encrypt/decrypt at a lower network layer - "they can speak on this encrypted link layer therefore I trust them at the higher layers")?  Obviously this does not satisfy the problems for security purely in the internet layer but may be practical.

2.  Has anyone considered dynamic and pseudo-random codepoints?  Ingress nodes sharing time-based pseudo-randomly sequenced dscp->traffic class mappings - starting values updated periodically generated from a real random sequence?  This will promote the precedence of some packets that should not be promoted but all in all could work?  Anybody looked at this?  Too organizationally infeasible for IANA perhaps?

> (perhaps with the same length) occurring every 20ms or so to see if a 

The issues of unencrypted headers being altered and traffic analysis are not unique to dscp's.  Again these can both be solved by requiring lower layer bulk encryption and requiring lower layers to send random junk when there is no legitimate traffic (so the observer sees a random stream of bits at all times independent of the actual traffic).  Not satisfying the security requirements in the internet layer but may be most practical solution.

Chris