One document matched: draft-boucadair-pppext-portrange-option-08.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-boucadair-pppext-portrange-option-08"
ipr="trust200811">
<front>
<title abbrev="Port Range IPCP Options">Huawei Port Range Configuration
Options for PPP IPCP</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange-ftgroup.com</email>
</address>
</author>
<author fullname="Pierre Levis" initials="P." surname="Levis">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Caen</city>
<country>France</country>
</postal>
<email>pierre.levis@orange-ftgroup.com</email>
</address>
</author>
<author fullname="Gabor Bajko" initials="G." surname="Bajko">
<organization>Nokia</organization>
<address>
<postal>
<street></street>
</postal>
<email>gabor(dot)bajko(at)nokia(dot)com</email>
</address>
</author>
<author fullname="Teemu Savolainen" initials="T." surname="Savolainen">
<organization abbrev="Nokia">Nokia</organization>
<address>
<email>teemu.savolainen@nokia.com</email>
</address>
</author>
<author fullname="Tina Tsou" initials="T." surname="Tsou">
<organization>Huawei Technologies (USA)</organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95050</code>
<country>USA</country>
</postal>
<phone>+1 408 330 4424</phone>
<email>tina.tsou.zouting@huawei.com</email>
</address>
</author>
<date day="31" month="August" year="2011" />
<keyword>Port Range, IPv4 Address Exhaustion, IPv4 service continuity,
IPv6, A+P</keyword>
<abstract>
<t>This document defines two Huawei IPCP (IP Configuration Protocol)
Options used to convey a set of ports. These options can be used in the
context of port range-based solutions or NAT-based ones for port
delegation and forwarding purposes.</t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>Within the context of IPv4 address depletion, several solutions have
been investigated to share IPv4 addresses. Two flavors can be
distinguished: NAT-based solutions (a.k.a., Carrier Grade NAT (CGN,
<xref target="I-D.ietf-behave-lsn-requirements"></xref>)) or port range
based ones (e.g., <xref target="RFC6346"></xref> <xref
target="I-D.boucadair-port-range"></xref><xref
target="I-D.despres-sam"></xref>). Port range-based solutions do not
require an additional NAT level in the service provider's domain.
Several means may be used to convey Port Range information.</t>
<t>This document defines the notion of Port Mask which is generic and
flexible. Several allocation schemes may be implemented when using a
Port Mask. It proposes a basic mechanism that allows the allocation of a
unique port range to a requesting client. This document defines Huawei
IPCP options to be used to carry Port Range information.</t>
<t>IPv4 address exhaustion is only provided as an example of the usage
of the PPP IPCP Options defined in this document. In particular, Port
Range Options may be used independently of the presence of IP-Address
IPCP Option.</t>
<t>This document adheres to the consideration defined in <xref
target="RFC2153"></xref>.</t>
<t>This document is not a product of pppext working group.</t>
<t>Note that IPR disclosures apply to this document (see
https://datatracker.ietf.org/ipr/).</t>
<section title="Use Cases">
<t>Port Range Options can be used in port range-based solutions (e.g.,
<xref target="RFC6346"></xref>) or in a CGN-based solution. These
options can be used in a CGN context to bypass the NAT (i.e., for
transparent NAT traversal and avoid involving several NAT levels in
the path) or to delegate one or a set of ports to the requesting
client (e.g., avoid ALG (Application Level Gateway) or for port
forwarding).</t>
<t>Architecture considerations are out of scope of this document.
<xref target="RFC6346"></xref> specifies an architecture using the
options defined in this document.</t>
</section>
<section title="Terminology">
<t>To differentiate between a Port Range containing a contiguous span
of port numbers and a Port Range with non contiguous and possibly
random port numbers, the following denominations are used:</t>
<t><list style="symbols">
<t>Contiguous Port Range: a set of port values which form a
contiguous sequence.</t>
<t>Non Contiguous Port Range: a set of port values which does not
form a contiguous sequence.</t>
<t>Random Port Range: a cryptographically random set of port
values.</t>
</list>Unless explicitly mentioned, Port Mask refers to the tuple
(Port Range Value, Port Range Mask).</t>
<t>In addition, this document makes use of the following terms:</t>
<t><list style="symbols">
<t>Delegated port or delegated port range: a port or a range of
ports belonging to an IP address managed by an upstream device
(such as NAT), which are delegated to a client for use as source
address and port when sending packets.</t>
<t>Forwarded port or forwarder port range: a port or a range of
ports belonging to an IP address managed by an upstream device
such as (NAT), which is/are statically mapped to the internal IP
address of the client and same port number of the client.</t>
</list>This memo uses the same terminology as per <xref
target="RFC1661"></xref>.</t>
</section>
</section>
<section anchor="values" title="Port Range Options">
<t>This section defines the IPCP Option for Port Range delegation. The
format of vendor-specific options is defined in <xref
target="RFC2153"></xref>. Below are provided the values to be conveyed
when the Port Range Option is used:<list style="symbols">
<t>Organizationally Unique Identifier (OUI): This field is set to
781DBA (hex).</t>
<t>Kind: This field is set to F0 (hex).</t>
<t>Value: The content of this field is specified in <xref
target="value_1"></xref> and <xref target="value_2"></xref>.</t>
</list></t>
<section anchor="value_1"
title="Description of Port Range Value and Port Range Mask">
<t>The Port Range Value and Port Range Mask are used to specify one
range of ports (contiguous or not contiguous) pertaining to a given IP
address. Concretely, Port Range Mask and Port Range Value are used to
notify a remote peer about the Port Mask to be applied when selecting
a port value as a source port. The Port Range Value is used to infer a
set of allowed port values. A Port Range Mask defines a set of ports
that all have in common a subset of pre-positioned bits. This set of
ports is also called Port Range.</t>
<t>Two port numbers are said to belong to the same Port Range if and
only if, they have the same Port Range Mask.</t>
<t>A Port Mask is composed of a Port Range Value and a Port Range
Mask:</t>
<t><list style="symbols">
<t>The Port Range Value indicates the value of the significant
bits of the Port Mask. The Port Range Value is coded as follows:
<list style="symbols">
<t>The significant bits may take a value of 0 or 1.</t>
<t>All the other bits (a.k.a., non significant ones) are set
to 0.</t>
</list></t>
<t>The Port Range Mask indicates, by the bit(s) set to 1, the
position of the significant bits of the Port Range Value.</t>
</list></t>
<t>This IPCP Configuration Option provides a way to negotiate the Port
Range to be used on the local end of the link. It allows the sender of
the Configure-Request message to state which Port Range associated
with a given IP address is desired, or to request the peer to provide
the configuration. The peer can provide this information by NAKing the
option, and returning a valid Port Range (i.e., (Port Range Value,
Port Range Mask)).</t>
<t>When a peer issues a request enclosing IPCP Port Range Option, and
if the server does not support this option, the Port Range Option is
rejected by the server.</t>
<t>The set of ports conveyed in an IPCP Port Range Option belong to
all transport protocols.</t>
<t>The Port Range IPCP option adheres to the format defined in Section
2.1 of <xref target="RFC2153"></xref>. The "value" field of the option
defined in <xref target="RFC2153"></xref> when conveying Port Range
IPCP Option is provided in <xref target="Figure_1"></xref>.</t>
<t><figure anchor="Figure_1"
title="Format of the Port Range IPCP Option">
<preamble></preamble>
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Reserved | Port Range Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Range Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure></t>
<t><list style="symbols">
<t>M: mode bit. It indicates the mode the port range is allocated
for. A value of zero indicates the port ranges are delegated,
while a value of 1 indicates the port ranges are port
forwarded.</t>
<t>Port Range Value (PRV): PRV indicates the value of the
significant bits of the Port Mask. By default, no PRV is assigned.
</t>
<t>Port Range Mask (PRM): Port Range Mask indicates the position
of the bits which are used to build the Port Range Value. By
default, no PRM value is assigned. The 1 values in the Port Range
Mask indicate by their position the significant bits of the Port
Range Value.</t>
</list></t>
<t><xref target="Figure_3"></xref> provides an example of the
resulting Port Range:</t>
<t>- Port Range Mask is set to 0001010000000000 (5120) and</t>
<t>- Port Range Value is set to 0000010000000000 (1024).<figure
anchor="Figure_3"
title="Example of Port Range Mask and Port Range Value">
<preamble></preamble>
<artwork><![CDATA[
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0| Port Range Mask
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| | (two significant bits)
v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0| Port Range Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x 0 x 1 x x x x x x x x x x| Usable ports (x may be set to 0 or 1)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure>Port values belonging to this Port Range must have the 4th
bit (resp. the sixth one), from the left, set to 0 (resp. 1). Only
these port values will be used by the peer when enforcing the
configuration conveyed by PPP IPCP.</t>
</section>
<section title="Description of Cryptographically Random Port Range option">
<t>A cryptographically random Port Range Option may be used as a
mitigation tool against blind attacks described in <xref
target="RFC6056"></xref>.</t>
<section anchor="function" title="Random Port Delegation Function">
<t>Delegating random ports can be achieved by defining a function
which takes as input a key 'k' and an integer 'x' within the range
(1024, 65535) and produces an output 'y' also within the port range
(1024, 65535).</t>
<t>The cryptographical mechanism ensures that the entire 64k port
range can be efficiently distributed to multiple nodes in a way that
when nodes calculate the ports, the results will never overlap with
ports other nodes have calculated (property of permutation), and
ports in the reserved range (smaller than 1024) are not used. As the
randomization is done cryptographically, an attacker seeing a node
using some port X cannot determine which other ports the node may be
using (as the attacker does not know the key). Calculation of the
random port list is done as follows:</t>
<t>The cryptographic mechanism uses an encryption function y =
E(K,x) that takes as input a key K (for example, 128 bits) and an
integer x (the plaintext) in range (1024, 65535), and produces an
output y (the ciphertext), also an integer in range (1024, 65535).
This section describes one such encryption function, but others are
also possible.</t>
<t>The server will select the key K. When the server wants to
allocate e.g. 2048 random ports, it selects a starting point 'a'
(1024 <= a <= 65536-2048) in a way that the port range (a,
a+2048) does not overlap with any other active client, and
calculates the values E(K,a), E(K,a+1), E(K,a+2), ..., E(K,a+2046),
E(K,a+2047). These are the port numbers allocated for this node.
Instead of sending the port numbers individually, the server just
sends the values 'K', ' a', and '2048'. The client will then repeat
the same calculation.</t>
<t>The server SHOULD use different K for each IPv4 address it
allocates to make attacks as difficult as possible. This way,
learning the K used in IPv4 address IP1 would not help in attacking
IPv4 address IP2 that is allocated by the same server to different
nodes.</t>
<t>With typical encryption functions (such as AES and DES), the
input (plaintext) and output (ciphertext) are blocks of some fixed
size; for example, 128 bits for AES, and 64 bits for DES. For port
randomization, we need an encryption function whose input and output
is an integer in range (1024, 65535).</t>
<t>One possible way to do this is to use the 'Generalized-Feistel
Cipher' <xref target="CIPHERS"></xref> construction by Black and
Rogaway, with AES as the underlying round function.</t>
<t>This would look as follows (using pseudo-code):</t>
<figure>
<artwork><![CDATA[ def E(k, x):
y = Feistel16(k, x)
if y >= 1024:
return y
else:
return E(k, y)]]></artwork>
</figure>
<t>Note that although E(k,x) is recursive, it is guaranteed to
terminate. The average number of iterations is just slightly over
1.</t>
<t>Feistel16 is a 16-bit block cipher:</t>
<t><figure>
<artwork><![CDATA[ def Feistel16(k, x):
left = x & 0xff
right = x >> 8
for round = 1 to 3:
temp = left ^ FeistelRound(k, round, right))
left = right
right = temp
return (right << 8) | left]]></artwork>
</figure>The Feistel round function uses:</t>
<t><figure>
<artwork><![CDATA[ def FeistelRound(k, round, x):
msg[0] = round
msg[1] = x
msg[2...15] = 0
return AES(k, msg)[0]]]></artwork>
</figure>Performance: To generate list of 2048 port numbers, about
6000 calls to AES are required (i.e., encrypting 96 kilobytes).
Thus, it will not be a problem for any device that can do, for
example, HTTPS (web browsing over SSL/TLS).</t>
</section>
<section anchor="value_2"
title="Description of Cryptographically Random Port Range Option">
<t></t>
<t><figure anchor="Figure_8"
title="Format of the cryptographically Random Port Range option">
<preamble>The cryptographically Random Port Range IPCP Option
adheres to the format defined in Section 2.1 of <xref
target="RFC2153"></xref>. The "value" field of the option
defined in <xref target="RFC2153"></xref> when conveying
cryptographically Random Port Range IPCP Option is illustrated
in <xref target="Figure_8"></xref></preamble>
<artwork><![CDATA[
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Reserved | function |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| starting point | number of delegated ports |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key K ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure></t>
<t><list style="symbols">
<t>M: mode bit. It indicates the mode the port range is
allocated for. A value of zero indicates the port ranges are
delegated, while a value of 1 indicates the port ranges are port
forwarded.</t>
<t>Function: A 16 bit field whose value is associated with
predefined encryption functions. This specification associates
value 1 with the predefined function described in <xref
target="function"></xref>.</t>
<t>Starting Point: A 16 bit value used as an input to the
specified function</t>
<t>Number of delegated ports: A 16 bit value specifying the
number of ports delegated to the client for use as source port
values.</t>
<t>Key K: A 128 bit key used as input to the predefined function
for delegated port calculation.</t>
</list></t>
<t>When the option is included in the IPCP Configure-Request 'key
field' and 'starting point' field SHALL be set to all zeros. The
requester MAY indicate in the 'function' field which encryption
function requester prefers, and in the 'number of delegated ports'
field the number of ports the requester would like to obtain. If
requester has no preference it SHALL set also the 'function' field
and/or 'number of delegated ports' field to zero.</t>
<t>The usage of the option in IPCP message negotiation
(Request/Reject/Nak/Ack) follows the logic described for Port Mask
and Port Range options at <xref target="value_1"></xref>.</t>
</section>
</section>
<section title="Illustration Examples">
<t></t>
<section title="Overview">
<t>These flows provide examples of the usage of IPCP to convey the
Port Range Option. As illustrated in <xref
target="Figure_4"></xref>, IPCP messages are exchanged between a
Host and a BRAS (Broadband Access Server).</t>
<t><list style="numbers">
<t>The first example illustrates a successful IPCP exchange;</t>
<t>The second example shows the IPCP exchange that occurs when
Port Range Option is not supported by the server;</t>
<t>The third example shows the IPCP exchange that occurs when
Port Range Option is not supported by the client;</t>
<t>The fourth example shows the IPCP exchange that occurs when
Port Range Option is not supported by the client and a non null
IP (i.e., an address different from 0.0.0.0) address is enclosed
in the first configuration request issued by the peer.</t>
</list></t>
</section>
<section title="Successful Flow: Port Range Options supported by both the Client and the Server">
<t>The following message exchange (i.e., <xref
target="Figure_4"></xref>) provides an example of successful IPCP
configuration operation when the Port Range IPCP Option is used.</t>
<t><figure anchor="Figure_4" title="Successful flow">
<preamble></preamble>
<artwork><![CDATA[
+-----+ +-----+
| Host| | BRAS|
+-----+ +-----+
| |
| (1) IPCP Configure-Request |
| IP ADDRESS=0.0.0.0 |
| PORT RANGE VALUE=0 |
| PORT RANGE MASK=0 |
|===============================================>|
| |
| (2) IPCP Configure-Nak |
| IP ADDRESS=a.b.c.d |
| PORT RANGE VALUE=80 |
| PORT RANGE MASK=496 |
|<===============================================|
| |
| (3) IPCP Configure-Request |
| IP ADDRESS=a.b.c.d |
| PORT RANGE VALUE=80 |
| PORT RANGE MASK=496 |
|===============================================>|
| |
| (4) IPCP Configure-Ack |
| IP ADDRESS=a.b.c.d |
| PORT RANGE VALUE=80 |
| PORT RANGE MASK=496 |
|<===============================================|
| |
]]></artwork>
<postamble></postamble>
</figure></t>
<t>The main steps of this flow are listed below:<list style="empty">
<t>(1) The Host sends a first Configure-Request which includes
the set of options it desires to negotiate. All these
Configuration Options are negotiated simultaneously. In this
example, Configure-Request carries information about IP-address,
Port Range Value and Port Range Mask. In this example,
IP-address Option is set to 0.0.0.0, Port Range Value is set to
0 and Port Range Mask is set to 0.</t>
<t>(2) BRAS sends back a Configure-Nak and sets the enclosed
options to its preferred values. In this example: IP-Address
Option is set to a.b.c.d, Port Range Value is set to 80 and Port
Range Mask is set to 496.</t>
<t>(3) The Host re-sends a Configure-Request requesting
IP-address Option to be set to a.b.c.d, Port Range Value to be
set to 80 and Port Range Mask to be set to 496.</t>
<t>(4) BRAS sends a Configure-Ack message</t>
</list>As a result of this exchange, Host is configured to use as
local IP address a.b.c.d and the following 128 contiguous Port
Ranges resulting of the Port Mask (Port Range Value == 0, Port Range
Mask == 496):</t>
<t><list style="empty">
<t>- from 80 to 95</t>
<t>- from 592 to 607</t>
<t>- ...</t>
<t>- from 65104 to 65119</t>
</list></t>
</section>
<section title="Port Range Option Not Supported by the Server">
<t>This example (<xref target="Figure_5"></xref>) depicts an
exchange of messages when the BRAS does not support IPCP Port Range
Option.</t>
<t><figure anchor="Figure_5"
title="Failed flow: Port Range Option not supported by the server">
<preamble></preamble>
<artwork><![CDATA[
+-----+ +-----+
| Host| | BRAS|
+-----+ +-----+
| |
| (1) IPCP Configure-Request |
| IP ADDRESS=0.0.0.0 |
| PORT RANGE VALUE=0 |
| PORT RANGE MASK=0 |
|===============================================>|
| |
| (2) IPCP Configure-Reject |
| PORT RANGE VALUE=0 |
| PORT RANGE MASK=0 |
|<===============================================|
| |
| (3) IPCP Configure-Request |
| IP ADDRESS=0.0.0.0 |
|===============================================>|
| |
| (4) IPCP Configure-Nak |
| IP ADDRESS=a.b.c.d |
|<===============================================|
| |
| (5) IPCP Configure-Request |
| IP ADDRESS=a.b.c.d |
|===============================================>|
| |
| (6) IPCP Configure-Ack |
| IP ADDRESS=a.b.c.d |
|<===============================================|
| |
]]></artwork>
<postamble></postamble>
</figure></t>
<t>The main steps of this flow are listed hereafter:<list
style="empty">
<t>(1) The Host sends a first Configure-Request which includes
the set of options it desires to negotiate. All these
Configuration Options are negotiated simultaneously. In this
example, Configure-Request carries the codes of IP-address, Port
Range Value and Port Range Mask options. In this example,
IP-address Option is set to 0.0.0.0, Port Range Value is set to
0 and Port Range Mask is set to 0.</t>
<t>(2) BRAS sends back a Configure-Reject to decline Port Range
option.</t>
<t>(3) The Host sends a Configure-Request which includes only
the codes of IP-Address option. In this example, IP-Address
Option is set to 0.0.0.0.</t>
<t>(4) BRAS sends back a Configure-Nak and sets the enclosed
option to its preferred value. In this example: IP-Address
Option is set to a.b.c.d.</t>
<t>(5) The Host re-sends a Configure-Request requesting
IP-Address Option to be set to a.b.c.d.</t>
<t>(6) BRAS sends a Configure-Ack message.</t>
</list>As a result of this exchange, Host is configured to use as
local IP address a.b.c.d. This IP address is not a shared IP
address.</t>
</section>
<section title="Port Range Option not Supported by the Client">
<t>This example (<xref target="Figure_6"></xref>) depicts exchanges
when only shared IP addresses are assigned to end-user's devices.
The server is configured to assign only shared IP addresses. If Port
Range Options are not enclosed in the configuration request, the
request is rejected and the requesting peer will be unable to access
the service as depicted in <xref target="Figure_6"></xref>.</t>
<t><figure anchor="Figure_6"
title="Port Range Option not supported by the Client">
<preamble></preamble>
<artwork><![CDATA[
+-----+ +-----+
| Host| | BRAS|
+-----+ +-----+
| |
| (1) IPCP Configure-Request |
| IP ADDRESS=0.0.0.0 |
|===============================================>|
| |
| (2) IPCP Protocol-Reject |
|<===============================================|
| |
]]></artwork>
<postamble></postamble>
</figure>The main steps of this flow are:<list style="empty">
<t>(1) The Host sends a Configure-Request requesting IP-Address
Option to be set to 0.0.0.0 and without enclosing the Port Range
Option.</t>
<t>(2) BRAS sends a Protocol-Reject message.</t>
</list>As a result of this exchange, Host is not able to access
the service.</t>
</section>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>No action is required from IANA since this document adheres to <xref
target="RFC2153"></xref>.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document does not introduce any security issue in addition to
those related to PPP. Service providers should use authentication
mechanisms such as CHAP <xref target="RFC1994"></xref> or PPP link
encryption <xref target="RFC1968"></xref>.</t>
<t>The use of small and non-random port range may increase host exposure
to attacks described in <xref target="RFC6056"></xref>. This risk can be
reduced by using larger port ranges, by using Random Port Range Option
or by activating means to improve the robustness of TCP against Blind
In-Window Attacks <xref target="RFC5961"></xref>.</t>
</section>
<section title="Contributors">
<t>Jean-Luc Grimault and Alain Villefranque contributed to this
document.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank C. Jacquenet, J. Carlson, B.
Carpenter, M. Townsley and J. Arkko for their review.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.1661'?>
<?rfc include='reference.RFC.1968'?>
<?rfc include='reference.RFC.1994'?>
<?rfc include='reference.RFC.2153'?>
<?rfc include='reference.RFC.5961'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.ietf-behave-lsn-requirements'?>
<?rfc include='reference.RFC.6346'?>
<?rfc include='reference.I-D.boucadair-port-range'?>
<?rfc include='reference.I-D.despres-sam'?>
<?rfc include='reference.RFC.6056'?>
<reference anchor="CIPHERS"
target=" CT-RSA 2002, Lecture Notes in Computer Science vol. 2271">
<front>
<title>Ciphers with Arbitrary Finite Domains Topics in
Cryptology</title>
<author fullname="John Black" initials="J." surname="Black">
<organization>Geoff Huston</organization>
</author>
<author fullname="Phillip Rogaway" initials="P." surname="Rogaway">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date month="" year="2002" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:59:52 |