Re: [shara] [BEHAVE] TR:I-DAction:draft-boucadair-pppext-portrange-option-00.txt

["Dan Wing" <[e-mail]>]

 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> Sent: Thursday, February 05, 2009 11:37 PM
> To: [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: RE: [shara] [BEHAVE] 
> TR:I-DAction:draft-boucadair-pppext-portrange-option-00.txt
> 
> Dan,
> 
> The attached document should appear shortly in the ietf 
> directories. Section 2 tries to justify the need for 
> non-contiguous port range allocation. Sections 4 and 5 
> explain how the non-contiguous port range and random port 
> delegation works.

(dropped BEHAVE)

Thanks.  I finally had time to look at this again.  It is
now posted at http://tools.ietf.org/html/draft-bajko-pripaddrassign-00

Thanks for providing explanation for the bit-mask.  I now understand 
why a bit mask is being proposed.  The two schemes described in
your draft (bit mask and cryptographic function) appear to be the
best achievable.

More complex mechanisms such as changing the secret key [1] would 
require even more coordination between the customer premise 
equipment and the service provider's equipment, which seems 
untenable.

[1]
http://tools.ietf.org/html/draft-ietf-tsvwg-port-randomization-02#section-3.4

-d



> - gabor
> 
>   >-----Original Message-----
>   >From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of
>   >ext Dan Wing
>   >Sent: Thursday, February 05, 2009 11:11 PM
>   >To: [e-mail]; 
> [e-mail];
>   >[e-mail]
>   >Cc: [e-mail]; [e-mail]
>   >Subject: Re: [shara] [BEHAVE] TR: I-DAction:draft-boucadair-pppext-
>   >portrange-option-00.txt
>   >
>   >
>   >
>   >
>   >> -----Original Message-----
>   >> From: [e-mail]
>   >> [mailto:[e-mail]]
>   >> Sent: Thursday, February 05, 2009 10:35 PM
>   >> To: [e-mail]; [e-mail]; [e-mail]
>   >> Cc: [e-mail]; [e-mail]
>   >> Subject: RE: [BEHAVE] [shara]TR:
>   >> I-DAction:draft-boucadair-pppext-portrange-option-00.txt
>   >>
>   >>
>   >> Thank you for your comment.
>   >>
>   >> There is a subtlety between subnet mask and port mask:
>   >> subnets need to be hierarchical but not port ranges!
>   >
>   >I disagree.  Port ranges all belong to the same IP address --
>   >from the view of the rest of the Internet.  This is akin to the
>   >rest of the Internet's view of a subnet.  It is only the local
>   >IP address (subnet) that is aware of the separation of ports
>   >(or IP addresses) to individual hosts.
>   >
>   >> Non contiguous port range is proposed as a solution to assign
>   >> with a single mask for instance "M" Port Ranges with "n" Port
>   >> Ranges within the well-known Port Range. This means that
>   >> well-known PR won't be assigned to the same user.
>   >>
>   >> I see other advantages on the usage of non contiguous PR:
>   >> e.g. an attacker would have more difficulty to "guess" a port
>   >> value within the Port Range.
>   >
>   >draft-boucadair-pppext-portrange-option does not describe
>   >this advantage.  I am not convinced this would thwart an
>   >attacker significantly.  If a user is permitted XXXX ports,
>   >an attacker can determine what ports they are by a range
>   >of contiguous bits or a range of non-contiguous bits.  I
>   >agree the attacker has to perform more probes to learn
>   >the non-contiguous bit pattern, of course.  But an analysis
>   >of this advantage would be useful.
>   >
>   >> By the way, I have the same question as Randy.
>   >
>   >I am not talking about the proverbial Grandma or "Joe
>   >Sixpack" when I say "users".  Those users have no
>   >need to understand 255.255.255.0, or IP addresses,
>   >or ARP.
>   >
>   >However, network administrators are users, and they need
>   >to understand these bit-masks in order to successfully
>   >configure equipment.  Based on industry experience with
>   >IP, non-contiguous subnet masks are not used in very
>   >many networks.  This is because the complexity to use
>   >them exceeds their value.
>   >
>   >Justification of the value of non-contiguous port masks
>   >would be useful.
>   >
>   >-d
>   >
>   >
>   >>
>   >>
>   >> Med
>   >>
>   >>
>   >>
>   >> -----Message d'origine-----
>   >> De : [e-mail] [mailto:[e-mail]]
>   >> De la part de Dave Thaler
>   >> Envoyé : vendredi 6 février 2009 02:10
>   >> À : Randy Bush; Dan Wing
>   >> Cc : [e-mail]; [e-mail]
>   >> Objet : Re: [BEHAVE] [shara]TR:
>   >> I-DAction:draft-boucadair-pppext-portrange-option-00.txt
>   >>
>   >> Yes.  :)
>   >>
>   >> I had the same feedback last IETF.
>   >> This is the same thing all over again as a non-contiguous
>   >> subnet mask, which the industry effectively got rid of as
>   >> having too many problems in practice (but being fine in theory).
>   >>
>   >> -Dave
>   >>
>   >> -----Original Message-----
>   >> From: [e-mail] [mailto:[e-mail]]
>   >> On Behalf Of Randy Bush
>   >> Sent: Thursday, February 05, 2009 3:35 PM
>   >> To: Dan Wing
>   >> Cc: [e-mail]; [e-mail]
>   >> Subject: Re: [shara] [BEHAVE] TR:
>   >> I-DAction:draft-boucadair-pppext-portrange-option-00.txt
>   >>
>   >> > I like this draft overall, but I would restrict this 
> so that only
>   >> > contiguous port ranges are permitted.  Non-contiguous
>   >> subnet masks are
>   >> > difficult for many people to understand (even today) 
> and I expect
>   >> > there would be similar confusion with non-contiguous 
> port ranges.
>   >>
>   >> do people have to understand these?
>   >>
>   >> randy
>   >> _______________________________________________
>   >> shara mailing list
>   >> [e-mail]
>   >> https://www.ietf.org/mailman/listinfo/shara
>   >>
>   >> _______________________________________________
>   >> Behave mailing list
>   >> [e-mail]
>   >> https://www.ietf.org/mailman/listinfo/behave
>   >
>   >_______________________________________________
>   >shara mailing list
>   >[e-mail]
>   >https://www.ietf.org/mailman/listinfo/shara
>