Subject: Re: [BEHAVE] [Int-area] WGLC: draft-ietf-behave-nat-icmp-09

From: Fernando Gont <[email-masked]>
Date: Wed, 08 Oct 2008 16:15:07 -0300

At 05:31 p.m. 07/10/2008, Dan Wing wrote:

>    REQ-9: A NAT device MAY implement a policy control that prevents
>    ICMP messages being generated toward certain interface(s).
>    Implementation of such a policy control overrides the MUSTs in
>    REQ-10.

Then.... shouldn't the requirements be "SHOULD"s rather than "MUST"s?

>    REQ-10: Unless overridden by REQ-9's policy, a NAT device needs to
>    support ICMP messages as below, some conforming to Section 4.3 of
>    [RFC1812] and some superseding the requirements of Section 4.3 of
>    [RFC1812].
>        a. MUST support:
>          1. Destination Unreachable Message, as described in
>              Section 7.1 of this document,
>           2. Time Exceeded Message, as described in Section 7.2 of
>              of this document,
>           3. Parameter Problem Message, as described in
>              Section 4.3.3.5 of [RFC1812],
>           4. Echo Request/Reply Messages, as described in REQ-1,
>           5. Router Advertisement and Solicitations, as described in
>              Section 4.3.3.10 of [RFC1812].

Does anybody actually use these ICMPv4 messages? I do recall Windows 
systems sending these messages when they are bootstrapped, but...

>        b. MAY support:
>           1. Redirect Message, as described in Section 4.3.3.2 of
>              [RFC1812],

If anything, I'd add that support should default to "off".

>           2. Source Route Options, as described in Section 7.3 of
>              this document,

The draft says:
"If a NAT device does not support forwarding packets with
    the source route option, the NAT device SHOULD NOT forward
    outbound ICMP messages that contain source route option in the
    outer or inner ICMP header."

s/ICMP header/IP header/

>           4. Address Mask Request/Reply Message, as described in
>              Section 7.4 of this document.

AFAIK, these messages are not used in practice (even when a number of 
systems support them). Shouldn't they be deprecated as with the 
information request/response?

Last, but not least:

In Section 7.1.2, the draft says:
"   When NAT device is the recipient of "Packet Too Big" ICMP message
    from the network, the NAT device MUST forward the ICMP message back
    to the intended recipient, pursuant to the previously stated
    requirements REQ-3, REQ-4, REQ-5 and REQ-6."

Does REQ-6 really apply here? (ICMP PTBs are not query/response messages)

Kind regards,

--
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 8 Oct 2008 16:38:21 -0700 (PDT)

Fernando, 

Thank you for the comments. Please see my responses inline.

regards,
suresh

--- On Wed, 10/8/08, Fernando Gont <[email-masked]> wrote:

> From: Fernando Gont <[email-masked]>
> Subject: Re: [BEHAVE] [Int-area] WGLC: draft-ietf-behave-nat-icmp-09
> To: "Behave WG" <[email-masked]>, "'Internet Area'" <[email-masked]>
> Cc: [email-masked]
> Date: Wednesday, October 8, 2008, 12:15 PM

[suresh] Essentially, the objective is not to dilute the MUST or SHOULD requirement on the NAT device, but to give the device admin an override capability. So, if the admin chooses to enforce local policies to override NAT operation, then the NAT device MAY enforce the local policy control. Would the following revised wording work for you?

Implementation of such a policy control overrides the MUSTs and SHOULDs in REQ-10.

> systems sending these messages when they are bootstrapped,

[suresh] If the WG believes any of these ought to be obsoleted for NAT devices, one option would be to dilute the requirement to MAY for NATs in this document. However, we need to provide sufficient justification for any deviation for NATs from RFC 1812.

> If anything, I'd add that support should default to

[suresh] RFC1812 already has MAY requirement on this and doesnot mandate this. RFC 1812 says:

   Contrary to [INTRO:2], a router MAY ignore ICMP Redirects when
   choosing a path for a packet originated by the router if the router
   is running a routing protocol or if forwarding is enabled on the
   router and on the interface over which the packet is being sent.

>     outer or inner ICMP header."

[suresh] OK. Thanks.

> information request/response?

[suresh] I believe, It is not in the scope of this document to deprecate ICMP messages or their use outside of NATs. 

For this reason, the requirement for Address mask request/Reply support for NATs is diluted to MAY (from MUST in RFC 1812). 

Information Request/response message is already obsoleted by RFC 1812. RFC 1812 recommends SHOULD NOT for the message and says the following on this.

      The Information Request/Reply pair was intended to support self-
      configuring systems such as diskless workstations, to allow them
      to discover their IP network prefixes at boot time.  However,
      these messages are now obsolete.  The RARP and BOOTP protocols
      provide better mechanisms for a host to discover its own IP
      address.

> Does REQ-6 really apply here? (ICMP PTBs are not

[suresh] You are right, REQ-6 is not applicable here. It should have been just REQ-3, REQ-4 and REQ-5.

regards,
suresh

---

From: Fernando Gont <[email-masked]>
Date: Wed, 08 Oct 2008 21:37:05 -0300

Hello, Pyda,

Comments in-line...

>[suresh] Essentially, the objective is not to dilute the MUST or 
>SHOULD requirement on the NAT device, but to give the device admin 
>an override capability. So, if the admin chooses to enforce local 
>policies to override NAT operation, then the NAT device MAY enforce 
>the local policy control. Would the following revised wording work for you?
>

Any would work for me. I was just wondering if it was correct (from a 
the perspective of RFC2119) to include a MUST that could be overiden. 
That is, I was wondering if that means that the "requirements" should 
be a "SHOULD" rather than a "MUST".

>[suresh] If the WG believes any of these ought to be obsoleted for 
>NAT devices, one option would be to dilute the requirement to MAY 
>for NATs in this document. However, we need to provide sufficient 
>justification for any deviation for NATs from RFC 1812.

While these messages are a "MUST" in RFC1812, my take is that RFC1812 
is outdated in this respect, and that we should not *require* them 
for NATs. I'm not saying we should obsolete these messages here (it 
would be out of the scope of the document), but rather that we should 
not require NATs to support these messages that nobody (that I know 
of) is depending on.

>mandate this. RFC 1812 says:

MAYs are less of a concern to me (as they give you the option to 
support them, but do not require you to).

>    router and on the interface over which the packet is being sent.

My take here is that the spirit f RFC1812 is that you can discard 
redirects *if* you are running a routing protocol (i.e., you're 
knowledgeable about routing). However, it would be insane to honor 
redirects nowadays.... unless you're enforcing something like GTSM 
(the TTL hack). If not, basically anybody could DoS you by sending 
you a forged ICMP redirect.

In anycase, as I said above, given that this is a MAY in your 
document, no changes are needed (i.e., you are not mandating support 
for redirects).

>[suresh] I believe, It is not in the scope of this document to 
>deprecate ICMP messages or their use outside of NATs.
>
>For this reason, the requirement for Address mask request/Reply 
>support for NATs is diluted to MAY (from MUST in RFC 1812).

Same here. I have no real concerns here.

Kind regards,

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 8 Oct 2008 22:49:50 -0700 (PDT)

--- On Wed, 10/8/08, Fernando Gont <[email-masked]> wrote:

> To: [email-masked], "Behave WG" <[email-masked]>, "'Internet Area'" <[email-masked]>
> Date: Wednesday, October 8, 2008, 5:37 PM
> Hello, Pyda,
> 
> Comments in-line...
> 
> 
> > > >    REQ-9: A NAT device MAY implement a
> policy control
> > > that prevents
> > > >    ICMP messages being generated toward
> certain
> > > interface(s).
> > > >    Implementation of such a policy control
> overrides
> > > the MUSTs in
> > > >    REQ-10.
> > >
> > > Then.... shouldn't the requirements be
> > > "SHOULD"s rather than
> "MUST"s?
> >
> >Implementation of such a policy control overrides the
> MUSTs and 
> >SHOULDs in REQ-10.
> 
> > > >           5. Router Advertisement and
> Solicitations,
> > > as described in
> > > Does anybody actually use these ICMPv4 messages?
> I do
> > > recall Windows
> > > systems sending these messages when they are
> bootstrapped,
> > > but...
> > >
> >
[suresh] Agreed. Do you suggest diluting both of the below MUSTs into MAY for NATs. 

          3. Parameter Problem Message, 
          5. Router Advertisement and Solicitations 

> 
> 
> 
> > > >        b. MAY support:
> > > >           1. Redirect Message, as described
> in Section
> > > 4.3.3.2 of
> > > >              [RFC1812],
> > >
> > > If anything, I'd add that support should
> default to
> > > "off".
> >
> >[suresh] RFC1812 already has MAY requirement on this
> and doesnot 
> >mandate this. RFC 1812 says:
> 

[suresh] OK.

> document, no changes are needed (i.e., you are not

[suresh] Right.

> 
> 
> 
> > > >           4. Address Mask Request/Reply
> Message, as
> > > described in
> > > AFAIK, these messages are not used in practice
> (even when a
> > > number of
> > > systems support them). Shouldn't they be
> deprecated as
> > > with the
[suresh] OK. 

Regards,
suresh

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 13 Oct 2008 06:58:50 -0700 (PDT)

Folks,

The "Router advertisements and solicitations" message appears to be rarely used in Ipv4 networks. Please let me know if anyone has objections to changing the requirement for this message to MAY from MUST for NATs. If I dont hear any objection, I will convert this to MAY in the next rev of the draft.

Thanks.

regards,
suresh

--- On Wed, 10/8/08, Pyda Srisuresh <[email-masked]> wrote:

> From: Pyda Srisuresh <[email-masked]>
> To: "Behave WG" <[email-masked]>, "'Internet Area'" <[email-masked]>, "Fernando Gont" <[email-masked]>
> Date: Wednesday, October 8, 2008, 10:49 PM
> > To: [email-masked], "Behave WG"
> <[email-masked]>, "'Internet Area'"
> <[email-masked]>
> > >[suresh] Essentially, the objective is not to
> dilute
> > the MUST or 
> > >SHOULD requirement on the NAT device, but to give
> the
> > device admin 
> > >an override capability. So, if the admin chooses
> to
> > enforce local 
> > >policies to override NAT operation, then the NAT
> device
> > MAY enforce 
> > >the local policy control. Would the following
> revised
> > wording work for you?
> > >
> > the perspective of RFC2119) to include a MUST that
> could be
> > overiden. 
> > >[suresh] If the WG believes any of these ought to
> be
> > obsoleted for 
> > >for NATs in this document. However, we need to
> provide
> > sufficient 
> > While these messages are a "MUST" in
> RFC1812, my
> > take is that RFC1812 
> > would be out of the scope of the document), but rather
> that
> > we should 
> > >    Contrary to [INTRO:2], a router MAY ignore
> ICMP
> > Redirects when
> > >    is running a routing protocol or if forwarding
> is
> > enabled on the
> > >    router and on the interface over which the
> packet
> > is being sent.
> > 
> > My take here is that the spirit f RFC1812 is that you
> can
> > discard 
> > redirects *if* you are running a routing protocol
> (i.e.,
> > you're 
> > knowledgeable about routing). However, it would be
> insane
> > to honor 
> > (the TTL hack). If not, basically anybody could DoS
> you by
> > sending 
> > In anycase, as I said above, given that this is a MAY
> in
> > your 
> > >support for NATs is diluted to MAY (from MUST in
> RFC
> > 1812).
> > 
> > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE
> A9EF
> > D076 FFF1

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 14 Oct 2008 07:24:13 -0700 (PDT)

Thanks, Julien. This is a good data point. DO you know if the network has NAT devices, that also respond to the router discovery messages?

regards,
suresh

--- On Tue, 10/14/08, Julien Laganier <[email-masked]> wrote:

> From: Julien Laganier <[email-masked]>
> Subject: Re: [Int-area] [BEHAVE]  WGLC: draft-ietf-behave-nat-icmp-09
> To: [email-masked], [email-masked]
> Cc: "Behave WG" <[email-masked]>, "Fernando Gont" <[email-masked]>, [email-masked]
> Date: Tuesday, October 14, 2008, 4:07 AM
> Suresh,
> 
> FWIW, I've seen ICMP router discovery being used
> extensively in at least 
> one large managed network.
> 
> --julien
> 
> On Monday 13 October 2008, Pyda Srisuresh wrote:
> > Folks,
> >
> > The "Router advertisements and
> solicitations" message appears to be
> > rarely used in Ipv4 networks. Please let me know if
> anyone has
> > objections to changing the requirement for this
> message to MAY from
> > MUST for NATs. If I dont hear any objection, I will
> convert this to
> > MAY in the next rev of the draft.
> >
> > Thanks.
> >
> > regards,
> > suresh
> >
> > > Subject: Re: [BEHAVE] [Int-area] WGLC:
> > > draft-ietf-behave-nat-icmp-09 To: "Behave
> WG" <[email-masked]>,
> > > "'Internet Area'"
> <[email-masked]>, "Fernando Gont"
> > > <[email-masked]> Cc:
> [email-masked]
> > > --- On Wed, 10/8/08, Fernando Gont
> > >
> > > <[email-masked]> wrote:
> > > > From: Fernando Gont
> <[email-masked]>
> > > > Subject: Re: [BEHAVE] [Int-area] WGLC:
> > >
> > > draft-ietf-behave-nat-icmp-09
> > >
> > > > > > >    Implementation of such a
> policy
> > > control
> > > > Any would work for me. I was just wondering
> if it was
> > > > correct (from a
> > > > That is, I was wondering if that means that
> the
> > > > "requirements" should
> > > > be a "SHOULD" rather than a
> > >
> > > "MUST".
> > >
> > > > > > >           5. Router
> Advertisement and
> > > >
> > > > Solicitations,
> > > >
> > > > > > as described in
> > > > > >
> > > > > > >              Section 4.3.3.10
> of
> > >
> > > [RFC1812].
> > >
> > > > > > Does anybody actually use these
> ICMPv4
> > >
> > > messages?
> > >
> > > > I do
> > > >
> > > > > > recall Windows
> > > > >NAT devices, one option would be to
> dilute the
> > > >
> > > > requirement to MAY
> > > >
> > > > >justification for any deviation for NATs
> from RFC
> > >
> > > 1812.
> > >
> > > > is outdated in this respect, and that we
> should not
> > > > *require* them
> > > > for NATs. I'm not saying we should
> obsolete these
> > > > messages here (it
> > > > not require NATs to support these messages
> that nobody
> > > > (that I know
> > > > of) is depending on.
> > >
> > > [suresh] Agreed. Do you suggest diluting both of
> the below
> > > MUSTs into MAY for NATs.
> > >
> Solicitations
> > > > > > >           1. Redirect
> > > described
> > > > >[suresh] RFC1812 already has MAY
> requirement on
> > >
> > > this
> > >
> > > > and doesnot
> > > >
> > > > MAYs are less of a concern to me (as they
> give you the
> > > > option to
> > > > >    choosing a path for a packet
> originated by the
> > > >
> > > > router if the router
> > > >
> > > > redirects nowadays.... unless you're
> enforcing
> > > > something like GTSM
> > > > document, no changes are needed (i.e., you
> are not
> > > > mandating support
> > > > for redirects).
> > >
> > > [suresh] Right.
> > >
> > > > > > >           4. Address Mask
> Request/Reply
> > > >
> > > > Message, as
> > > >
> > > > > > described in
> > > > > >
> > > > > > >              Section 7.4 of
> this
> > >
> > > document.
> > >
> > > > > > AFAIK, these messages are not used
> in
> > >
> > > practice
> > >
> > > > (even when a
> > > >
> > > > > > number of
> > > > > > systems support them).
> Shouldn't they be
> > > >
> > > > deprecated as
> > > >
> > > > > > with the
> > > > >[suresh] I believe, It is not in the
> scope of this
> > > >
> > > > document to
> > > >
> > > > >deprecate ICMP messages or their use
> outside of
> > >
> > > NATs.
> > >
> > > > >For this reason, the requirement for
> Address mask
> > > >
> > > > request/Reply
> > > >
> > Int-area mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/int-area
> 
> 
> 
> -- 
> --julien
> 
> [ New email address: [email-masked] ]

---

From: Julien Laganier <[email-masked]>
Date: Tue, 14 Oct 2008 13:07:24 +0200

Suresh,

FWIW, I've seen ICMP router discovery being used extensively in at least 
one large managed network.

--julien

On Monday 13 October 2008, Pyda Srisuresh wrote:
> Folks,
>
> The "Router advertisements and solicitations" message appears to be
> rarely used in Ipv4 networks. Please let me know if anyone has
> objections to changing the requirement for this message to MAY from
> MUST for NATs. If I dont hear any objection, I will convert this to
> > draft-ietf-behave-nat-icmp-09 To: "Behave WG" <[email-masked]>,
> > "'Internet Area'" <[email-masked]>, "Fernando Gont"
> > <[email-masked]> Cc: [email-masked]
> > > > > >    Implementation of such a policy
> >
> > control
> >
> > > overrides
> > >
> > > > > the MUSTs in
> > > > >
> > > > > >    REQ-10.
> > > > >
> > > >Implementation of such a policy control overrides
> >
> > the
> >
> > > MUSTs and
> > >
> > > >SHOULDs in REQ-10.
> > >
> > > > > >              Section 4.3.3.10 of
> > > > > Does anybody actually use these ICMPv4
> >
> > messages?
> >
> > > I do
> > >
> > > > > recall Windows
> > > >NAT devices, one option would be to dilute the
> > >
> > > requirement to MAY
> > >
> > > >justification for any deviation for NATs from RFC
> >
> > 1812.
> >
> > > > > >           1. Redirect Message, as
> > > >[suresh] RFC1812 already has MAY requirement on
> >
> > this
> >
> > > and doesnot
> > >
> > > >    choosing a path for a packet originated by the
> > >
> > > router if the router
> > >
> > > > > >              Section 7.4 of this
> > > > > AFAIK, these messages are not used in
> >
> > practice
> >
> > > (even when a
> > >
> > > > > number of
> > > >[suresh] I believe, It is not in the scope of this
> > >
> > > document to
> > >
> > > >deprecate ICMP messages or their use outside of
> >
> > NATs.
> >
> > > >For this reason, the requirement for Address mask
> > >
> > > request/Reply
> > >

-- 
--julien

---

From: Julien Laganier <[email-masked]>
Date: Wed, 15 Oct 2008 13:30:58 +0200

On Tuesday 14 October 2008, Pyda Srisuresh wrote:
> Thanks, Julien. This is a good data point. DO you know if the network
> has NAT devices, that also respond to the router discovery messages?

To my knowledge the network had no NAT devices.

--julien

> --- On Tue, 10/14/08, Julien Laganier 
<[email-masked]> wrote:
> > Subject: Re: [Int-area] [BEHAVE]  WGLC:
> > draft-ietf-behave-nat-icmp-09 To: [email-masked],
> > [email-masked]
> > Cc: "Behave WG" <[email-masked]>, "Fernando Gont"
> > <[email-masked]>, [email-masked] Date: Tuesday,
> > October 14, 2008, 4:07 AM
> > Suresh,
> >
> > > --- On Wed, 10/8/08, Pyda Srisuresh
> >
> > <[email-masked]> wrote:
> > > > > From: Fernando Gont
> > <[email-masked]>
> > > > > To: [email-masked], "Behave
> >
> > WG"
> >
> > > > <[email-masked]>, "'Internet
> >
> > Area'"
> >
> > > > <[email-masked]>
> > > >
> > > > > > > >    REQ-9: A NAT device MAY
> > implement a
> > > > > > > >    ICMP messages being
> > generated toward
> > > > > > > Then.... shouldn't the
> > requirements be
> > > > > >[suresh] Essentially, the objective is
> >
> > not to
> >
> > > > dilute
> > > >
> > > > > the MUST or
> > > > >
> > > > > >SHOULD requirement on the NAT device,
> >
> > but to give
> >
> > > > the
> > > >
> > > > > device admin
> > > > >
> > > > > >an override capability. So, if the admin
> >
> > chooses
> >
> > > > to
> > > >
> > > > > enforce local
> > > > >
> > > > > >policies to override NAT operation, then
> >
> > the NAT
> >
> > > > device
> > > >
> > > > > MAY enforce
> > > > >
> > > > > >the local policy control. Would the
> >
> > following
> >
> > > > revised
> > > >
> > > > > wording work for you?
> > > > >
> > > > > the perspective of RFC2119) to include a
> >
> > MUST that
> >
> > > > could be
> > > >
> > > > > overiden.
> > > > > > > >           5. Router
> > Advertisement and
> > > > > > > systems sending these messages
> >
> > when they are
> >
> > > > > bootstrapped,
> > > > >
> > > > > > > but...
> > > > > >
> > > > > >[suresh] If the WG believes any of these
> >
> > ought to
> >
> > > > be
> > > >
> > > > > obsoleted for
> > > > >
> > > > > >for NATs in this document. However, we
> >
> > need to
> >
> > > > provide
> > > >
> > > > > sufficient
> > > > >
> > > > > While these messages are a "MUST"
> >
> > in
> >
> > > > RFC1812, my
> > > >
> > > > > take is that RFC1812
> > > > > would be out of the scope of the document),
> >
> > but rather
> >
> > > > that
> > > >
> > > > > we should
> > > > > > > If anything, I'd add that
> >
> > support should
> >
> > > > > default to
> > > > >
> > > > > > > "off".
> > > > > >
> > > > > >    Contrary to [INTRO:2], a router MAY
> >
> > ignore
> >
> > > > ICMP
> > > >
> > > > > Redirects when
> > > > >
> > > > > >    is running a routing protocol or if
> >
> > forwarding
> >
> > > > is
> > > >
> > > > > enabled on the
> > > > >
> > > > > >    router and on the interface over
> >
> > which the
> >
> > > > packet
> > > >
> > > > > is being sent.
> > > > >
> > > > > My take here is that the spirit f RFC1812 is
> >
> > that you
> >
> > > > can
> > > >
> > > > > discard
> > > > > redirects *if* you are running a routing
> >
> > protocol
> >
> > > > (i.e.,
> > > >
> > > > > you're
> > > > > knowledgeable about routing). However, it
> >
> > would be
> >
> > > > insane
> > > >
> > > > > to honor
> > > > > (the TTL hack). If not, basically anybody
> >
> > could DoS
> >
> > > > you by
> > > >
> > > > > sending
> > > > > In anycase, as I said above, given that this
> >
> > is a MAY
> >
> > > > in
> > > >
> > > > > your
> > > > > > > >           4. Address Mask
> > Request/Reply
> > > > > > > systems support them).
> > Shouldn't they be
> > > > > >support for NATs is diluted to MAY (from
> >
> > MUST in
> >
> > > > RFC
> > > >
> > > > > 1812).
> > > > >
> > > > > e-mail: [email-masked] ||
> >
> > [email-masked]
> >
> > > > > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9
> >
> > 3945 96EE
> >
> > > > A9EF
> > > >
> > > > > D076 FFF1
> > > >

-- 
--julien