Re: [BEHAVE] CGN REQ: Port Set Assignment

> -----Original Message-----
> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> Behalf Of mohamed.boucadair@orange-ftgroup.com
> Sent: Tuesday, March 15, 2011 11:28 PM
> To: Dan Wing; 'Reinaldo Penno'; draft-ietf-behave-lsn-
> requirements@tools.ietf.org
> Cc: DENG Xiaohong ESP/PEK; behave@ietf.org
> Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment
> 
> 
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> -----Message d'origine-----
> De : Dan Wing [mailto:dwing@cisco.com]
> Envoyé : mardi 15 mars 2011 23:59
> À : 'Reinaldo Penno'; BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-
> behave-lsn-requirements@tools.ietf.org
> Cc : DENG Xiaohong ESP/PEK; behave@ietf.org
> Objet : RE: [BEHAVE] CGN REQ: Port Set Assignment
> 
> > -----Original Message-----
> > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> > Behalf Of Reinaldo Penno
> > Sent: Tuesday, March 15, 2011 3:52 PM
> > To: Dan Wing; mohamed.boucadair@orange-ftgroup.com; draft-ietf-
> behave-
> > lsn-requirements@tools.ietf.org
> > Cc: 'DENG Xiaohong ESP/PEK'; behave@ietf.org
> > Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment
> >
> >
> >
> >
> > On 3/15/11 3:33 PM, "Dan Wing" <dwing@cisco.com> wrote:
> >
> > >> -----Original Message-----
> > >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> > >> Behalf Of Reinaldo Penno
> > >> Sent: Tuesday, March 15, 2011 3:19 PM
> > >> To: Dan Wing; mohamed.boucadair@orange-ftgroup.com; draft-ietf-
> > behave-
> > >> lsn-requirements@tools.ietf.org
> > >> Cc: 'DENG Xiaohong ESP/PEK'; behave@ietf.org
> > >> Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment
> > >>
> > >> That are security considerations that need to be understood in
> > relation
> > >> to
> > >> port block. But many of those can be mitigated. Having said that,
> I
> > >> would
> > >> guess there are at least 3 CGN vendors that implement such a
> > feature.
> > >> Therefore, CGN vendors already do that today.
> > >>
> > >> As for your example, If the attacker has this access to your
> machine
> > >> the victim should be worried about his credit card, not ports. (;-
> )
> > >
> > > Yes, there are always more severe risks.  Could get run over by a
> > bus, too.
> > >
> > > But building a system which has predictable ports is risky for two
> > reasons:
> > >
> > >   * security, which everyone likes to discount as "not important".
> > >   * the port limit will be wrong
> >
> > There are many ways to overcome the issues you point below. I think
> you
> > might have a specific implementation in mind.
> 
> I am thinking of A+P-like schemes.
> 
> Med: Which ones? Dynamic modes have been proposed in A+P; see
> http://tools.ietf.org/html/draft-rqb-dynamic-port-ranges-02. Port
> randomization requirement can be fairly honored.
> 
>  No implementation magic can
> change the number of ports allocated by those schemes, because
> those schemes generally stick port information into the IPv6
> address or into a tunnel header.
> 
> Med: This is true for the stateless A+P mode but not the binding mode
> (see: http://tools.ietf.org/html/draft-ymbk-aplusp-09#section-4.4 for
> more details).

Most of the benefits attributed to A+P is that it's stateless in the
SP's network.  I haven't seen anyone excited about that, but I don't
talk to everyone.

-d

> 
> 
> -d
> 
> 
> > >       o It will be either too high (too many ports, costing money
> > >         in the future ("why are we spending $30 for each IPv4
> > >         address, giving everyone 1000 ports, but the average user
> > >         only consuming 10 ports?  We are throwing money away"),
> > >       o It will be too low (too few ports, harming an application,
> > >         causing support calls).  This will be expensive to correct,
> > >         with some fixed-port schemes, because it requires re-IP'ing
> > >         the access network for some users or for all users.  Some
> > >         other fixed-port schemes could be changed with a single
> > >         CLI setting, and don't have this risk.
> > >
> > > -d
> > >
> > >
> > >>
> > >> On 3/15/11 2:28 PM, "Dan Wing" <dwing@cisco.com> wrote:
> > >>
> > >>>> A "Port Set" does not mean necessarily "contiguous port range"!
> > >>>
> > >>> It is not relevant if they are contiguous or not.  This is a
> false
> > >> sense of
> > >>> security.
> > >>>
> > >>> If they are fixed, the ports can be determined by causing the
> > victim
> > >> to view
> > >>> HTML which opens img1.example.com, img2.example.com,
> > >> img3.example.com, etc.,
> > >>> to servers controlled by the attacker.  The attacker can then
> have
> > >>> Javascript release one of those mappings, wait, and the  attacker
> > >> will know
> > >>> the victim will re-use that port -- because it's the only port
> > >> available.
> > >>> Proof of concept code that does this has been circulating.
> > >>
> > >> _______________________________________________
> > >> Behave mailing list
> > >> Behave@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/behave
> > >
> >
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://www.ietf.org/mailman/listinfo/behave
> 
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave