Subject: Re: [OPSEC] Fwd: New Version Notification for draft-gont-opsec-ipv6-eh-filtering-02.txt

From: "C. M. Heard" <[email-masked]>
Date: Mon, 1 Sep 2014 10:27:36 -0700 (PDT)

Greetings,

I'm pretty happy with what I see in the new revision.  It now treats 
extension headers and options on an equal footing, leaving the 
specification of protocol requirements (including configuration 
defaults) to standards-track documents and concentrating on advice 
for what configuration options operators should choose.  The 
standards-track document for extension headers is RFC 7045, and the 
authors have submitted a draft to 6man to cover IPv6 options:

http://tools.ietf.org/html/draft-gont-6man-ipv6-opt-transmit

Folks who are interested in draft-gont-opsec-ipv6-eh-filtering will 
doubtless want to look at that draft too.

As far as I can see, the major substantive things that need to be 
done before draft-gont-opsec-ipv6-eh-filtering is ready for prime 
time are to fill in the TBDs.  These mainly deal with specific 
security implications, but in the case of three hop-by-hop options 
(SMF_DPD, MPL, IP_DFF) there are some additional gaps.  Here is the 
full list of gaps:

EH: Mobility, HIP, Shim6
HbH (a): Jumbo Payload, RPL
HbH (b) SMF_DPD, MPL, IP_DFF [also needs impact if blocked and advice]
Dest: Tunnel Encapsulation Limit, Home Address, EID, ILNP Nonce, Line ID

The three EHs mentioned above are basically upper-layer protocols 
with the ability to tunnel another ULP (though in the cases of 
Mobility and HIP this capability is for further study -- the specs 
require that they contain a Next Header type of No Next Header).  
The security considerations of the respective specs (RFCs 5201, 
6275, and 5553) seem to provide the necessary information to craft 
specific security implication text.  If I have time in the next 
couple of weeks I'll see if I can propose something, assuming that 
the authors (or other interested parties) do not beat me to it.

I also noticed one nit:

3.3.2.4.  Operational and Interoperability Impact if Blocked

   Blocking packets containing a RHT0 or RTH1 has no operational

s/RTH1/RHT1/

//cmh

On Tue, 26 Aug 2014, Fernando Gont wrote:
> Folks,
> 
> We have posted a revision
> (http://www.ietf.org/internet-drafts/draft-gont-opsec-ipv6-eh-filtering-02.txt)
> of the aforementioned document, that addresses all the comments we have
> received so far.
> 
> Any further comments will be highly appreciated.
> 
> Thanks!
> 
> Best regards,
> Fernando (and co-authors)
> 
> 
> 
> 
> -------- Forwarded Message --------
> Subject: New Version Notification for
> draft-gont-opsec-ipv6-eh-filtering-02.txt
> Date: Tue, 26 Aug 2014 08:21:14 -0700
> From: [email-masked]
> To: Will(Shucheng) Liu <[email-masked]>, Shucheng LIU (Will)
> <[email-masked]>, Fernando Gont <[email-masked]>, Ron
> Bonica <[email-masked]>, Fernando Gont <[email-masked]>,
> Ronald P. Bonica <[email-masked]>
> 
> 
> A new version of I-D, draft-gont-opsec-ipv6-eh-filtering-02.txt
> has been successfully submitted by Fernando Gont and posted to the
> IETF repository.
> 
> Name:		draft-gont-opsec-ipv6-eh-filtering
> Revision:	02
> Title:		Recommendations on Filtering of IPv6 Packets Containing IPv6
> Extension Headers
> Document date:	2014-08-26
> Group:		Individual Submission
> Pages:		30
> URL:
> http://www.ietf.org/internet-drafts/draft-gont-opsec-ipv6-eh-filtering-02.txt
> Status:
> https://datatracker.ietf.org/doc/draft-gont-opsec-ipv6-eh-filtering/
> Htmlized:
> http://tools.ietf.org/html/draft-gont-opsec-ipv6-eh-filtering-02
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-gont-opsec-ipv6-eh-filtering-02
> 
> Abstract:
>    This document provides advice on the filtering of IPv6 packets based
>    on the IPv6 Extension Headers and the IPv6 options they contain.
>    Additionally, it discusses the operational and interoperability
>    implications of discarding packets based on the IPv6 Extension
>    Headers and IPv6 options they contain.
> 
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> 
> 
>

---

From: Jen Linkova <[email-masked]>
Date: Tue, 30 Sep 2014 06:24:36 +0200

Hi Fernando,

Some comments:

1) Section 2.2
" - Permit this IPv6 Extension Header or IPv6 Option type;
 - Ignore this IPv6 Extension Header or option type (forwarding
      packets that contain them)"

What the difference?

2) Section 3.4 discussed the unknown EHs and it says:
-  impossible to determine specific security implications
- filtering might break new protocols and makes the deployment harder

and then you make a conclusion 'it's recommended to filter' - does not
look too logical to me ;)

3) Section 4.3.6. Router Alert (Type=0x05):
  - you suggest to permit 'only in specific environments where support
for RSVP or similar protocols is desired', while mentioning MLD
earlier. IMHO you might want to mention multicast here as well.

4)

   NOTE: [RFC7112] specifies that non-fragmented IPv6 datagrams and
      IPv6 First-Fragments MUST contain the entire IPv6 header chain
      [RFC7112].  Therefore, intermediate systems can always enforce the
      filtering policies discussed in this document, or resort to simply
      discarding the offending packets when they fail to comply with the
      requirements in [RFC7112].

I'd not say ' intermediate systems can always enforce the policy'. To
be always able to do it the system must be able to inspect the *whole*
packet - it is not the case for various hardware.

5) 3.3.2. Routing Header for IPv6 (Protocol Number=43)
You suggest to 'discard packets containing a RHT0 or
   RHT1.  As required by [RFC7045], packets containing standardised and
   undeprecated Routing Headers should be permitted.'. Should it say
'permit all other types', otherwise you do not specify what to do with
new/unknown  types.

6)" 4.3.5.5. Advice
   Intermediate systems should not discard packets based on the
presence of this option."

The rest of the document says 'should permit' or 'should discard', so
could you change it to 'should permit'?

7) Section 4 IPv6 Options

As you already discussed HbH and Destination options - so why do you
have a separate section? Unless I'm really missing smth here, we have
only HbH and Destination ;) IMHO it would be more logical to have a
section about 'IPv6 Options Headers and two sub-sections for HbH and
Destination.
BTW in many places in the document you say 'IPv6 Extension Headers
and/or Ipv6 Options' which I read like 'there are such things as IPv6
EH and smth different called IPv6 Options'. IMHO it should be smth
like 'Ipv6 extension headers (incl. individual option type)'.

In general I'm a bit concern about the message of this document as it
is quite long and I'm afraid that people might read it as 'filter 'em
all, let God sort 'em out' which would make the current situation even
worse. Is it what you trying to say? If not - would it help to have a
short summary saying 'filter this, rate limit thas, permit everything
else' or 'permit this, rate-limit that, block everything else' and
then provide with all details you currently have in the document?

On Tue, Aug 26, 2014 at 5:28 PM, Fernando Gont <[email-masked]> wrote:
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec

-- 
SY, Jen Linkova aka Furry

---

From: Fernando Gont <[email-masked]>
Date: Tue, 30 Sep 2014 04:10:40 -0300

Hi, Jen,

Thanks so much for your feedback! Please find my comments in-line...

>       packets that contain them)"

With "permit", you honor the IP option (act on it) and forward the
packet. With "ignore", you do not act on the option, but still forward
the packet. Please let us know if you think this should be made more
clear in the I-D.

> look too logical to me ;)

The thing here is that a standardized IPv6 EH is not "unknown" anymore.

[I've suppressed those comments that we will apply as suggested]

> section about 'IPv6 Options Headers and two sub-sections for HbH and

The reason was to discuss filtering on both per-EH-type (Section 3) and
per-option-type (Section 4) granularities.

How renaming the section (somehow) make things more clear?

> worse. Is it what you trying to say?

Certainly not -- actually, kind of quite the opposite. :-)

> If not - would it help to have a

Yes. This is what we did in RFC7126. We should definitely do it for this
document, too.

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492