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).

-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