Subject: [tcpm] icmp type 3, code 13

From: "Dan Wing" <[email-masked]>
Date: Thu, 5 Apr 2007 11:07:24 -0700

In section 6 of draft-ietf-behave-nat-icmp-03, it is recommended to use ICMP
type 3, code 13 to indicate an administratively-prohibited flow.  ICMP type
3, code 13 was originally specified in RFC1812:

  "...
   13 = Communication Administratively Prohibited - generated if a
        router cannot forward a packet due to administrative filtering;
   ...
   Routers SHOULD use the newly defined
   Code 13 (Communication Administratively Prohibited) if they
   administratively filter packets.

   Routers MAY have a configuration option that causes Code 13
   (Communication Administratively Prohibited) messages not to be
   generated.  When this option is enabled, no ICMP error message is
   sent in response to a packet that is dropped because its forwarding
   is administratively prohibited.
   ..."

For the purposes of draft-ietf-behave-nat-icmp, ICMP type 3, code 13 needs
to be considered a hard error.  However, I am unable to find a reference
indicating if ICMP type 3, code 13 is considered a hard error or soft error.
Is there such a reference?  I doubt existing stacks consider it a hard
error, though, as code 13 is not on RFC1122's list of hard errors (which
makes sense, as RFC1122 predates RFC1812's publication).

(The use of Code 13 was originally my suggestion, but perhaps it is
ill-suited if it hasn't been interpreted as a hard error since RFC1812's
publication.)

-d

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Thu, 05 Apr 2007 11:27:20 -0700

Hi, all,

> ill-suited if it hasn't been interpreted as a hard error since RFC1812's

I don't see a place where type 3 code 13 is defined in terms of host
behavior.

I don't know if you can or should require hard or soft error response to
this code. Code 10 - communication with destination host
    administratively prohibited - is similar in spirit (it's a "won't"
rather than a "can't"), and 1122 doesn't require either a hard or soft
error on that one.

IMO, it's up to the host to decide how to handle that error, just like
12, and that seems reasonable.

That said, why are you using code 13, vs code 10? This isn't really
because of a router doing administrative filtering; IMO, code 10 is
sufficient.

Joe

-- 
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment

---

From: Pekka Savola <[email-masked]>
Date: Tue, 10 Apr 2007 10:21:17 +0300 (EEST)

On Thu, 5 Apr 2007, Joe Touch wrote:
...
> because of a router doing administrative filtering; IMO, code 10 is

10 is:

            10  Communication with Destination Host is
                Administratively Prohibited

while 13 is:

            13  Communication Administratively Prohibited      [RFC1812]

'10' seems to (at least more strongly) imply that all communication 
with the destination address is administratively prohibited.

13 is less specific; the same code applies even if you filtered the 
whole network, just one host, or only one port of a host.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: [email-masked]
Date: Tue, 10 Apr 2007 08:17:29 -0700

> whole network, just one host, or only one port of a host.

If the entire network is filtered, 9 should be appropriate:

                    9 = communication with destination network
                            administratively prohibited

If a single port is filtered, a port-unreachable (code 3) should be generated.

Administrative prohibition, as indicated in RFC1812, is based on policy:

I don't think NATs are considered filters per se, so 13 doesn't seem appropriate
regardless.

Joe

---

From: [email-masked]
Date: Tue, 10 Apr 2007 09:15:12 -0700

Quoting [email-masked]:

..
> > whole network, just one host, or only one port of a host.

Let me be more specific:

If you care that the source host acts with a hard error, you need to use an ICMP
message that indicates that further attempts are not useful (codes 2-4). Other
codes imply that there might be a change - e.g., administrative responses may
differ later - and so should not be taken as a hard error.

I disagree that 13 is less specific than 9 or 10; it's more specific, indicating
that the reason for prohibition is filtering, vs. other administrative reasons.
At the very least, draft-ietf-behave-nat-icmp-03.txt should be updated to
indicate that 13 is used because of a *filter* based restriction. If this is
not filter-based, then I think 9 or 10 is more appropriate.

So, to get back to Dan's original issue and to summarize:

- type 3 code 13 is NOT a hard error
   - nor, however, are corresponding type 3 codes 9 or 10
   - if you want a hard error, use an existing one (safest) or
     define a new one with hard error behavior (IMO, more appropriate
     if that's your goal)

- if we're talking about filtering, draft-ietf-behave-nat-icmp-03.txt needs
  to be updated where it discusses code 13 ICMP errors
   - if this isn't filtering, then code 9 or 10 should be used

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 10 Apr 2007 09:33:36 -0700

Faisal Siyavudeen (fsiyavud) wrote:
> | '10' seems to (at least more strongly) imply that all 
> | communication with the destination address is 
> | administratively prohibited.
> 
> Does NAT administrative filtering referred to by
> draft-ietf-behave-nat-icmp-03 cover filtering of application traffic
> based on destination port? If yes, what error would be generated by a
> NAT filtering out a certain type of application traffic to a certain set
> of hosts? In that case, code 10 would not be the right one, as the host
> might still be reachable on a different port. I feel that the actual
> choice of error code would vary - it could be code 10 or code 13
> depending on the type of filtering.

I don't see that difference; code 10 just says administratively
prohibited, and code 13 says administratively prohibited because of
filtering. In either case, other ports could be reachable.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 10 Apr 2007 10:31:55 -0700

Faisal Siyavudeen (fsiyavud) wrote:
> | > it could be code 10 or code 13 depending on the type of filtering.
> | 
> | I don't see that difference; code 10 just says 
> | administratively prohibited, and code 13 says 
> | administratively prohibited because of filtering. In either 
> | case, other ports could be reachable.
> | 
> 
> I agree.
> 
> I am sorry I was not clear - my point was that 10 cannot be used where
> other ports on the hosts are still accessible, while 13 can be used in
> any of these cases. BTW, the following note in RFC 1812 makes me wonder
> if NAT devices can send code 10 at all as they are more like routers:

Uh, routers decrement the TTL. NATs do not. I don't think NATs behave
like routers per se.

> <quote>
> Codes 9 and 10 were intended for use by end-to-end encryption devices
> used by U.S military agencies. Routers SHOULD use the newly defined Code
> 13 (Communication Administratively Prohibited) if they administratively
> filter packets.
> </quote>

That argues that NATs should generate their own codes. This is NOT
router administrative filtering either.

Joe

> | -----Original Message-----
> | From: Joe Touch [mailto:[email-masked]] 
> | Sent: Tuesday, April 10, 2007 10:04 PM
> | To: Faisal Siyavudeen (fsiyavud)
> | Cc: Pekka Savola; Dan Wing (dwing); [email-masked]; 
> | [email-masked]; Mahesh Govind (mgovind)
> | Subject: Re: [tcpm] icmp type 3, code 13
> | 
> | 
> | 
> | Faisal Siyavudeen (fsiyavud) wrote:
> | > | '10' seems to (at least more strongly) imply that all 
> | communication 
> | > | with the destination address is administratively prohibited.
> | > 
> | > Does NAT administrative filtering referred to by
> | > draft-ietf-behave-nat-icmp-03 cover filtering of 
> | application traffic 
> | > based on destination port? If yes, what error would be 
> | generated by a 
> | > NAT filtering out a certain type of application traffic to 
> | a certain 
> | > set of hosts? In that case, code 10 would not be the right 
> | one, as the 
> | > host might still be reachable on a different port. I feel that the 
> | > actual choice of error code would vary - it could be code 
> | 10 or code 
> | > 13 depending on the type of filtering.
> | 
> | I don't see that difference; code 10 just says 
> | administratively prohibited, and code 13 says 
> | administratively prohibited because of filtering. In either 
> | case, other ports could be reachable.
> | 
> | Joe
> | 
> |

---

From: Pekka Savola <[email-masked]>
Date: Tue, 10 Apr 2007 20:54:43 +0300 (EEST)

> Uh, routers decrement the TTL. NATs do not. I don't think NATs behave

YMMV but all NATs I have seen and used do decrement TTL. (I've heard 
reports about ones that don't, but never seen one myself.)

I'd be interested in knowing in which conditions access to a network, 
host, or a subset of a host should be considered "administratively 
prohibited", but that administrative prohibition is not due to 
filtering (be it a firewall rule, access list, configuration toggle, 
or whatever).

---

From: Joe Touch <[email-masked]>
Date: Tue, 10 Apr 2007 11:59:26 -0700

Pekka Savola wrote:
...
> reports about ones that don't, but never seen one myself.)

One of the nasty things about NATs (or the people who design them) is
that anything that makes them visible is likely to be disabled by some
subset, in the hopes of making it 'transparent'.

Although many NATs do decrement the TTL, there is no such requirement.
RFC3022 (traditional NATs, informational) doesn't even mention it, and
RFC2766 (NAT proposed standard) talks about setting TTL to 0 for DNS,
but says specifically that TTLs are not decremented for statically
mapped addresses (and has nothing to say about dynamic ones). Other docs
(MIDCOM, arch implications of NATs) don't require TTL decrement either.

> prohibited", but that administrative prohibition is not due to filtering
> (be it a firewall rule, access list, configuration toggle, or whatever).

source address/reverse path validation comes to mind.

Yes, it might be set with a toggle, but it's not what most people
consider when then talk about packet filtering (at least IMO).

IMO, because a NAT behaves like an endpoint (to the Internet side), it
should send ICMPs like one, and issue ICMP host/port unreachables, not
administrative filtering that routers would send. That would also 'do
the right thing' by making the ICMPs result in hard errors.

Joe

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 22 Apr 2007 07:00:03 -0700 (PDT)

Faisal,

Sorry for the delay in responding. You are absolutely right. ICMP type 3, code
13 was selected for exactly the reasons you cite below. Thanks.

regards,
suresh

--- "Faisal Siyavudeen (fsiyavud)" <[email-masked]> wrote:

> rgds
> Faisal
> Behave mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/behave
>

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 22 Apr 2007 07:06:20 -0700 (PDT)

> router administrative filtering either.

[suresh] NAT forwards packets between nodes in private domain and public
domain. If NAT cannot forward a packet due to resource constrains or
administrative restrictions, NAT needs to specify a reason to the sender. 
ICMP code 13 closely matches the description of the cause. What is your
argument against using code 13?  

regards,
suresh

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 22 Apr 2007 07:43:39 -0700 (PDT)

> RFC3022 (traditional NATs, informational) doesn't even mention it, and

[suresh] You are right, there is no mention of TTL in RFC 3022. And, we donot
have a BEHAVE recommendation on NATs at IP level to suggest a BCP. That said,
it does not take away the fact that NAT is fundamentally a router. As Pekka
said, most NAT devices do decrement TTL in the IP heder, 

> mapped addresses (and has nothing to say about dynamic ones). 

[suresh] Joe - the TTL above refers to the time-to-Live of the DNS RR, not the
TTL of the IP header. 

>                                                               Other docs

[suresh] You are saying that a router can send ICMP code 13 if source address
of a packet it receives is invalid. This is some sort of an administrative
configuration/restriction. It seems reasonable for NAT to use the same error
code 13  when it runs out of resources or has another type of administrative
restriction.

> consider when then talk about packet filtering (at least IMO).

[suresh] I do not understand your above comment. What might be set with a
toggle? 

> the right thing' by making the ICMPs result in hard errors.
[suresh] Joe - NAT is not an endpoint device. NAT does not run applications on
itself. If it does, that is not within the scope of BEHAVE. 

You may be stuck on some semantics. But, most people would agree NAT is a
routing device. NAT forwards packets between private and public nodes. When NAT
doesnt allow a flow to go through it, it must do what is right for an
intermediate device and send the appropriate ICMP error code to the sender - be
it a public node or a private node. I dont know of any other error code that is
more appropriate than ICMP code 13 to do this.

regards,
suresh

---

From: Joe Touch <[email-masked]>
Date: Sun, 22 Apr 2007 10:45:57 -0700

NATs are not routers. Using a code defined in RFC1812 for this purpose
is to inappropriately imply that a router is generating the code.

Joe

---

From: Joe Touch <[email-masked]>
Date: Sun, 22 Apr 2007 10:50:04 -0700

...
> it does not take away the fact that NAT is fundamentally a router.

No, it is not.

It would need to follow the entirety of RFC1812 to be a router; since
decrementing the TTL is not required, it is *clearly* not a router.

> As Pekka

Thanks for the detail; that is further evidence that NATs have nothing
to do with routers, and are not routers.

...
> itself. If it does, that is not within the scope of BEHAVE. 

A NAT sources packets with its own IP address; to the rest of the
Internet, it behaves like an IP address source, and so IMO it is
required to obey RFC1122 in all respects.

> more appropriate than ICMP code 13 to do this.

To the rest of the Internet (the public side), a NAT is clearly an IP
source, and so must obey 1122. *IF* we want, we can require that NATs
also obey 1812 on the private side - if we believe that the private
device thinks the NAT is a router. I think that part isn't as clearly
required.

Joe

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 22 Apr 2007 14:04:10 -0700 (PDT)

Below is what RFC 1812 has to say about what constitutes a router.

  This memo defines and discusses requirements for devices that perform
  the network layer forwarding function of the Internet protocol suite.
  The Internet community usually refers to such devices as IP routers or
  simply routers.

NATs forward IP packets from one network to another. That makes NAT a router.
And, it is appropriate for NAT to use the error codes a router device would
use.

If you insist NAT is not a router, I am not going to argue or get into a debate
with you on this. I will simply disagree. So do the vast majority of people
taht use NATs to connect to public networks.

regards,
suresh

---

From: Joe Touch <[email-masked]>
Date: Sun, 22 Apr 2007 14:11:32 -0700

>   The Internet community usually refers to such devices as IP routers or

The rest of that document is what defines what is an Internet router.
Being a device that does network layer forwarding and violates any of
the rest of that doc means that device is not an Internet router.

> NATs forward IP packets from one network to another. That makes NAT a router.

NATs don't follow the requirement of:
	- decrement the TTL
	- do not modify the source or destination IP address
		(except as per source-routing options)

...
> taht use NATs to connect to public networks.

They can and have disagreed before, but this isn't up for a popular
vote. It's utterly useless to talk about using any sort of IETF standard
- including ICMP type 3 code 13 - and expect the rest of the Internet to
follow that standard when NATs violate the standard of what it means to
be a router.

Joe

---

From: "Anantha Ramaiah \(ananth\)" <[email-masked]>
Date: Sun, 22 Apr 2007 15:46:07 -0700

Firstly, why is this being disussed in tcpm? This doesn't apply to TCP
directly. [ even in-directly it might apply to all other transport
protocols who can/may want to act on these errors] Maybe tsvwg is more
appropriate? 

As far as the current discussion goes, there is a thin line of
distinction between hosts and routers, today. Today's routers do all
sort of things which were only done by end-hosts at one point of time.
So any discussion which is based on the semantics of a
router/switch/host is IMO, useless, since things have evolved. 

Also, actually, when you say "NAT's are not routers", there is a lot of
ambiguity there :

Typical case where NAT is configured in a router, which means that this
device, applies NAT rule and route's the packets. So are you saying :-

- generate a ICMP error code if the error is a result of a "routing
operation" and NOT as a result of "NAT operation"? I really don't see a
value in seperating these and it boils down to pure semantic argument,
IMO, without considering the characteristics of the deployed Internet
today. 

-Anantha 

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]] 
> Sent: Sunday, April 22, 2007 2:12 PM
> To: Pyda Srisuresh
> Cc: [email-masked]; [email-masked]; Mahesh Govind (mgovind); 
> Dan Wing (dwing); Faisal Siyavudeen (fsiyavud)
> Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13
> 
> 
> 
> Pyda Srisuresh wrote:
> Being a device that does network layer forwarding and 
> violates any of the rest of that doc means that device is not 
> an Internet router.
> 
> > If you insist NAT is not a router, I am not going to argue 
> or get into 
> > a debate with you on this. I will simply disagree. So do the vast 
> > majority of people taht use NATs to connect to public networks.
> 
> They can and have disagreed before, but this isn't up for a 
> popular vote. It's utterly useless to talk about using any 
> sort of IETF standard
> - including ICMP type 3 code 13 - and expect the rest of the 
> Internet to follow that standard when NATs violate the 
> standard of what it means to be a router.
> 
> Joe
> 
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 23 Apr 2007 07:14:03 -0700

> protocols who can/may want to act on these errors] Maybe tsvwg is more

That's possible; someone in Behave might start by posting a summary of
the question there as well.

> distinction between hosts and routers, today.

There may be many devices that do both functions, but to the extent they
do they must then obey both the host and router requirements.

> Today's routers do all

Such as? Other than acting like end hosts for connections that terminate
at routers, which they have always done, and always required
RFC1122-level support...

> router/switch/host is IMO, useless, since things have evolved.

Until the requirements in the IETF are updated to reflect this opinion,
it is irrelevant.

> device, applies NAT rule and route's the packets. 

Then the part that routes must obey RFC1812 rules. If the part that
routes can respond in lieu of the part that NATs, then that's fine. But
when the part that NATs acts, it can't act like the router.

> So are you saying :-
...
> operation" and NOT as a result of "NAT operation"? 

Yes.

> I really don't see a

First, there are plenty of devices that do not combine both functions,
and that's where we're talking about.

However, in the case of the combined device, it still makes sense to
determine WHY an error code is being generated. If because of a routing
issue, then RFC1812 works; if because of a NAT issue, then RFC1812 is
NOT the guiding document.

Joe

---

From: Ted Faber <[email-masked]>
Date: Mon, 23 Apr 2007 09:10:21 -0700

> is to inappropriately imply that a router is generating the code.

I agree that a NAT that doesn't follow 1812 is not a compliant router.
However if this is only a semantic issue there are plenty of words out
there that could get around the semantic issue, e.g. "... in this case
a NAT may send an ICMP type 3 code 13 packet as a proxy for the router
inside its name space in order to simplify the translation ...".

Is there a deeper issue here?  Will the ICMP being issued with the NAT's
address cause functional confusion or malfunction in a host receiving
it?  Is this a distinction that matters, or are words sufficient?

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Mon, 23 Apr 2007 09:25:49 -0700

> inside its name space in order to simplify the translation ...".

There need not be a router on either side of a NAT; in that case, what
router is the NAT being a proxy for?

Besides, if I configure either such router to never send such messages,
the NAT has no right to generate them for me.

> it?  Is this a distinction that matters, or are words sufficient?

I think the issue is "eating cake and having it too".

The fundamental goal of most NATs is invisibility; you can't be
invisible and scream when something goes wrong.

Joe

---

From: Ted Faber <[email-masked]>
Date: Mon, 23 Apr 2007 11:18:22 -0700

> router is the NAT being a proxy for?

Oh I bet I can find a router on a non-trivial Internet path. :-)

I don't want to spend too much time defending a hypothetical rewording.
I'd rather talk about the issue that you get to below.

> invisible and scream when something goes wrong.

This is a fair point.  If a NAT is otherwise acting transparently, it is
certainly alarming that it will occasionally pop up with an ICMP
message.  I can imagine the pain of trying to debug such an error
message using standard tools like traceroute or even ping.  ("I got an
ICMP from something that doesn't respond to a ping!?")

I think that the nail you're hitting is that partial visibility is
clearly confusing to applications and administrators and needs to be
avoided.  I'd agree that a device that emits an ICMP but is otherwise
invisible to endpoints is difficult enough to deal with in the real
world that the behavior needs to be discouraged.  If you agree with
that, we agree.

---

From: Joe Touch <[email-masked]>
Date: Mon, 23 Apr 2007 11:40:18 -0700

> Oh I bet I can find a router on a non-trivial Internet path. :-)

Unless you can find one on EVERY such path, you can't assume you're
generating the message as a proxy for that router. I.e., if a router
isn't a required part of that path, then sending one as a proxy isn't an
option.

...
> world that the behavior needs to be discouraged.  If you agree with

Yes. The issue, IMO, is that generating a non-NAT ICMP is what's being
requested exactly to hide the fact that there's a NAT here, and that's
self-contradictory.

Joe

---

From: Ted Faber <[email-masked]>
Date: Mon, 23 Apr 2007 11:50:08 -0700

> isn't a required part of that path, then sending one as a proxy isn't an

I am so not having that argument.
> requested exactly to hide the fact that there's a NAT here, and that's

That seems a more compelling objection to me.