Re: [BEHAVE] CGN REQ: Port Set Assignment

[<[e-mail]>]

|> >> -----Original Message-----
|> >> From: [e-mail] [mailto:[e-mail]] On 
|> >> Behalf Of Reinaldo Penno
|> >> Sent: Tuesday, March 15, 2011 3:19 PM
|> >> To: Dan Wing; [e-mail]; draft-ietf-
|> behave-
|> >> [e-mail]
|> >> Cc: 'DENG Xiaohong ESP/PEK'; [e-mail]
|> >> 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. 

Xiaohong: When you refer to A+P-like schemes, I can imagine B4 element
 with port set restricted NAT and AFTR with by passing port set feature,
and 
Address + Port embedded IPv6 prefix is not necessary for Port Set
Assignment.
 Does that make sense?

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

Xiaohong: Right, the binding mode doesn't require  stick port
information into
 the IPv6  address or into a tunnel header.


Cheers,
Xiaohong
opensource A+P: http://opensourceaplusp.weebly.com/

|
|
|
|-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" <[e-mail]> 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
|> >> [e-mail]
|> >> https://www.ietf.org/mailman/listinfo/behave
|> >
|> 
|> _______________________________________________
|> Behave mailing list
|> [e-mail]
|> https://www.ietf.org/mailman/listinfo/behave
|
|