Subject: [OPSEC] post iesg final version of draft-ietf-opsec-ip-options-filtering (07)

From: joel jaeggli <[email-masked]>
Date: Wed, 11 Dec 2013 09:28:58 -0800

you can refer to the diff here.

http://tools.ietf.org/rfcdiff?url2=draft-ietf-opsec-ip-options-filtering-07.txt

if anyone has issue with any of the changes made to address iesg review
or post-last-call change please squawk soon.

thanks
joel

---

From: Seun Ojedeji <[email-masked]>
Date: Wed, 11 Dec 2013 19:53:56 +0100

Thanks for the share,

I am looking at the section below and i am wondering whether the part in
bold could be removed to avoid un-necessary query from members of the
various groups who were not contacted "offlist". IMHO i think in an
environment like this, offlist contacting which does not really have its
inputs publicly available to the working group should not necessarily be
added

1.2. Operational Focus

All of the recommendations in this document have been made in an

effort to optimise for operational community consensus, as best the

editors have been able to determine that. This has included not only

accepting feedback from public lists, *but also accepting off-list*

*feedback from people at various network operators (e.g. ISPs,*

*content providers, educational institutions, commercial firms).*

Kind Regards

On Wed, Dec 11, 2013 at 6:28 PM, joel jaeggli <[email-masked]> wrote:

> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec
>
>

-- 
------------------------------------------------------------------------

*Seun Ojedeji,Federal University Oye-Ekitiweb:      http://www.fuoye.edu.ng
<http://www.fuoye.edu.ng> Mobile: +2348035233535**alt email:
<http://goog_1872880453>[email-masked]
<[email-masked]>*

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 11 Dec 2013 14:26:54 -0500

On 11  Dec 2013, at 13:53 , Seun Ojedeji wrote:
> various groups who were not contacted "offlist". 

The IETF's basic principle is that ALL feedback is considered
for an IETF track document.

The specific text was added to this document during handling
of Last Call comments in an effort to clarify that all inputs
also were considered in this specific case.

Accepting off-list feedback, in addition to accepting on-list 
feedback, has been both common and acceptable practice within 
the IETF for more than 20 years (from my own first-hand knowledge).

As an example, for many I-Ds where I am the person commenting
on someone else's document, I send the authors/editors unicast
email in order to avoid disturbing an entire mailing list with
my humble suggestions.  It is the choice of the person sending
the comments whether they wish to send those to a list or just
send them to the authors/editors.

Yours,

Ran

---

From: Seun Ojedeji <[email-masked]>
Date: Thu, 12 Dec 2013 00:59:51 +0100

Hello Ran,

Thanks for those clarification, especially with reference to IETF
historical approach to handling last call comments period.

Kind Regards

sent from Google nexus 4

---

From: joel jaeggli <[email-masked]>
Date: Sat, 14 Dec 2013 11:13:11 -0800

I am calling this good.

Thanks all.
joel

---

From: "Smith, Donald" <[email-masked]>
Date: Sun, 15 Dec 2013 01:29:15 +0000

Shouldn't this be environment not environments ?
1....
Additionally, it outlines what a network operator might do in a typical enterprise or Service Provider environments.

1.2.  Operational Focus  
      
       All of the recommendations in this document have been made in an  
       effort to optimise for operational community consensus, as best the  
       editors have been able to determine that.  

optimize not optimiSe and that isn't English. That is it isn't a complete thought/sentence that I can understand anyways?

Technical against the draft not just the iesg additions!!
I swear I said this before but ISPs and others are going to want at least one more option (possibly two) here.

4.3.5.  Advice  
      
Routers, security gateways, and firewalls SHOULD implement an option-       
specific configuration knob whether packets with this option are dropped, packets with this IP option are forwarded as if they did not contain this IP option, or packets with this option are processed and  forwarded as per [RFC0791].  

Does drop that imply silently drop? (I think it does as opposed to deny where an icmp error should be sent). Shouldn't there be a deny with some icmp code being sent saying the packet contained unsupported options? Either 3,5 (source router failed for SSRR or LSRR) or 3,9 (admin prohibited) for other options?

Forwarded as if they did not contain ... is commonly called ignored or not processed. I like spelling it out but lets give it a short version name for router heads/configs.

Next we SHOULD permit a "clear" where by the device removes the unwanted options and repads/rechecksums the packet if it could potentially be dangerous to an "inner" device.

This:
Please note that treating packets with LSRR as if they did not  
       contain this option can result in such packets being sent to a  
       different device that the initially intended destination.  With  
       appropriate ingress filtering this should not open an attack vector  
       into the infrastructure.  Nonetheless, it could result in traffic  
       that would never reach the initially intended destination.  Dropping  
       these packets prevents unnecessary network traffic, and does not make  
       end-to-end communication any worse.  

Should be this:
Please note that treating packets with LSRR as if they did not  
       contain this option can result in such packets being sent to a  
       different device THAN the initially intended destination.  With  
       appropriate ingress filtering this should not open an attack vector  
       into the infrastructure.  Nonetheless, it could result in traffic  
       that would never reach the initially intended destination.  Dropping  
       these packets prevents unnecessary network traffic, and does not make  
       end-to-end communication any worse.  
                                            
It also isn't true:(

Consider a LSRR A-B-C-D 
If A received it and ignores it (including the record route part) and hands it off to something next to A (1 hop away) that device could hand it back to A (since it should be in the RR path but isn't) causing a loop that bounces between A and it neighbor until the ttl expires right? So not only did it not arrive at the destination it also could be used to ddos A.

4.4.5

different device that 

should be:
different device than

(coffee != sleep) & (!coffee == sleep)
 [email-masked]

From: OPSEC [[email-masked]] on behalf of joel jaeggli [[email-masked]]
Sent: Wednesday, December 11, 2013 10:28 AM
To: [email-masked]; [email-masked]
Subject: [OPSEC] post iesg final version of draft-ietf-opsec-ip-options-filtering (07)

thanks
joel

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 15 Dec 2013 15:08:25 +0000

Donald,

Thank you for your comments, please see inline.

> Additionally, it outlines what a network operator might do in a typical enterprise or Service Provider environments.

Seems like something the RFC Editor would catch if it is incorrect.

"Environment" in singular potentially 'sounds' better; however, your proposal seems incorrect without an "a" before "Service Provider". In any case -- to me, if the sentence intends to convey "in a typical enterprise environment or a typical SP environment" (i.e., "environment" applying to both), then "in a typical enterprise or SP environments" should be correct as-is.

That said, we could make a note and ask the RFC Editor. Thank you. 

> optimize not optimiSe and that isn't English. That is it isn't a complete thought/sentence that I can understand anyways?

I can say the same thing about your comment :-) What exactly is not English? It is not clear :-)

We can make an RFC Editor note to replace "optimise" with "optimize". Thank you.

I think "optimize" is American and "optimise" is British, but the dictionary recognizes (and recognises) both.

> Does drop that imply silently drop? (I think it does as opposed to deny where an icmp error should be sent). Shouldn't there be a deny with some icmp code being sent saying the packet contained uns…

To prevent misuse of CPU resources, this does not send an ICMP. Similar to 4.11.3.

Additionally, both your proposals would be incorrect. ICMP 3/5 is incorrect since it is not a failure of the source route, ICMP 3/9 as well as ICMP3/10 are also incorrect, because what is admin prohibited is neither the network nor the host. There is no ICMP type that says "option admin prohibited", and we do not want to create one.

> Forwarded as if they did not contain ... is commonly called ignored or not processed. I like spelling it out but lets give it a short version name for router heads/configs.

Yes, we use "ignore" throughout.

> Next we SHOULD permit a "clear" where by the device removes the unwanted options and repads/rechecksums the packet if it could potentially be dangerous to an "inner" device.

Do you know of any device that supports that? This is a BCP for current practices.

>       end-to-end communication any worse.  

OK, we can have an RFC Editor note to replace "that" with "than".

> It also isn't true:(
> 
> Consider a LSRR A-B-C-D 
> If A received it and ignores it (including the record route part) and hands it off to something next to A (1 hop away) that device could hand it back to A (since it should be in the RR path but isn't) causing a loop that bounces between A and it neighbor until the ttl expires right?

Wrong.

If A ignores the option, it means if performs forwarding based on the destination IP address in the IP Header. If it sends it to B, B does the same IP header address destination-based forwarding, why would it send it to A? I mean, of course unless there is a routing loop regardless of the presence of LSRR...

The only reason for that paragraph is that strictly, based on the LSRR presence, the packet could be destined to a different end device than the one on the IP address destination, based on the pointer. In other words, the ip address points to an intermediate device. Now, that does not create loops.

> So not only did it not arrive at the destination it also could be used to ddos A.
> 

No. See above.

> different device than

Yes.

Net-net: "optimise" -> "optimize", and "that" -> "than".

Thank you,

Carlos.

---

From: joel jaeggli <[email-masked]>
Date: Sun, 15 Dec 2013 07:56:17 -0800

fwiw the rfc editor will do a scrub of the text.

thanks

joel

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 15 Dec 2013 07:57:13 -0800 (PST)

>        end-to-end communication any worse.  

Actually, it IS true.

> Consider a LSRR A-B-C-D

In this case, when the packet is originated the destination address 
in the IP header is A and the LSRR route contains BCD with the 
pointer pointing to B.

> If A received it and ignores it (including the record route part) 
> and hands it off to something next to A (1 hop away) that device 
> could hand it back to A (since it should be in the RR path but 
> isn't) causing a loop that bounces between A and it neighbor until 
> the ttl expires right? So not only did it not arrive at the 
> destination it also could be used to ddos A.

No.  If A receives the packet and ignores LSRR it won't forward the 
packet at all; rather, it will assume that the packet is destined 
for itself because the destination address in the IP header is A.  
In other words, the packet will be delivered to A and not to D.

//xmh

---

From: "Smith, Donald" <[email-masked]>
Date: Mon, 16 Dec 2013 16:02:09 +0000

From: C. M. Heard [[email-masked]]
Sent: Sunday, December 15, 2013 8:57 AM
To: Smith, Donald
Cc: [email-masked]; [email-masked]
Subject: Re: [OPSEC] post iesg final version of draft-ietf-opsec-ip-options-filtering (07)
>        in the IP header is A and the LSRR route contains BCD with the

Yea I could be confused as most of us don't support any type of SRR so I haven't had much experience in it.
I am always willing to learn so thanks for any education you can provide me!

It states what to do if you receive a SRR and the pointer is still valid. But I don't see where it defines the creation of the original SRR packet with A in the destination field?
>From rfc791. 
 If the address in destination address field has been reached and
        the pointer is not greater than the length, the next address in
        the source route replaces the address in the destination address
        field, and the recorded route address replaces the source
        address just used, and pointer is increased by four.

Does that mean when created the host must copy the first octet from the option ssr field into the destination address field?
Or is that defined somewhere else?
I assumed a host with a default router would, in at least LSRR, send the packet to it's default gateway (as the destination addr) is that incorrect?

>        In other words, the packet will be delivered to A and not to D.
In which case we can and should expect a response if you sent a packet to most routers on a closed port it would send back a tcp reset or a icmp error saying the port was closed (or maybe silently drop as that is an option too).

But I don't see where the initial packet assembly is defined only what to do when a system receives a SSR with options and valid pointer (not complete yet).

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 16 Dec 2013 09:15:55 -0800 (PST)

On Mon, 16 Dec 2013, Smith, Donald wrote:
> [ ... ] 
[ ... ]
> It states what to do if you receive a SRR and the pointer is still 
> valid. But I don't see where it defines the creation of the 
> original SRR packet with A in the destination field?
> From rfc791.

The explanation in RFC 791 is, shall we say, just a bit terse.  Excellent supplemental explanation may be found in RFC 1122 
and RFC 1812.  For this particular question see the DISCUSSION at the top of Page 37 in RFC 1122 for a picture of the correct 
way to format a source route option at the originating host.

> I assumed a host with a default router would, in at least LSRR, send the packet to it's default gateway (as the destination 

The originating host would typically send te packet to its default gateway, though it could in principle choose another gateway if it 
knew about one.  For LSRR the destination address in the IP header would not necessarily be the address of that gateway.  For SSRR the 
destination is required to be the addess of the first-hop gateway.

> In which case we can and should expect a response if you sent a  packet to most routers on a closed port it would send back a tcp 
> reset or a icmp error saying the port was closed (or maybe silently drop as that is an option too).

Yes, those are possible outcomes.  Even if the port is not closed and the router accepts the packet for processing, it would probably 
fail the checksum test if the payload was TCP or UDP because the IP address in the pseudo-header is the final destination address.  
This would cause a silent drop too.  It's possible to concoct examples where the packet would not be rejected in this way but all 
the ones I've come up with are rather far-fetched.

The effect on end-to-end communication is of course the same as dropping the packet, but just ignoring the option can put an extra 
processing load on an intermediate router, and that is not an especially desirable outcome.  The purpose of the note in
draft-ietf-opsec-ip-options-filtering-07 is to alert operators to this possibility.

> pointer (not complete yet).

Hopefully the reference to RFC 1122 that I provided above answers the question of initial packet assembly.

A good explanation of what to do when the source route option is complete can be found in Section 5.2.4.1 of RFC 1812, which is at 
the top of page 72.

If these references don't answer your questions please feel free to contact me on or off list and I'll see if I can dig up some better 
ones.

Mike Heard