Subject: Re: [OPSEC] draft-ietf-opsec-ip-security-03

From: John Kristoff <[email-masked]>
Date: Mon, 3 May 2010 16:43:11 -0500

On Sun, 18 Apr 2010 11:05:15 -0700
Joel Jaeggli <[email-masked]> wrote:

> if yu have anything to add it would be helpful if it were done this
> week.

Sorry about being a little late, but I finally got some time to finish
reading through it.

This is a substantial piece of work and kudos to Fernando for it.
There is a lot of good stuff in here.  I have some comments and some
criticisms, but I think in the grand scheme of this work they are all
relatively minor.

One overriding comment is what will become of this document.  The title
says it is an assessment, but throughout there are recommendations,
advice and suggestions for implementations and operators on how to
mitigate the enumerated threats. It reads more like a BCP or standards
track document to me. Trouble may arise if things get built to this
document.  At best, the predictability of the net would erode further
if that happens.

1.1. Introduction

  Awkward or redundant wording "to the point that, to some extent,".

2. The Internet Protocol

  Another convenient characteristic is that with reduced complexity and
  minimum functionality comes, presumably, a limited set of security
  threats. This document could have been much larger with a different
  protocol.  :-)

3.5. Identification (ID)

  "[Sanfilippo2998a] examined to determine" - grammar.

3.8. TTL

  While considered obsolete by the IP multicast operators, specific TTL
  values (e.g. 1, 16, 32, 64) have been used to control the scope of IP
  multicast packets. I don't know that this was officially documented
  in an RFC and I don't think it was ever officially obsoleted, but it
  was at least referred to as "difficult" and "complex" in RFC 2365.

3.11. Source Address

  BCP 84 is the new ingress filtering doc.

3.13.2. Issues with specific options

  Some of the address (i.e. bogon, nonsensical) concerns apply to the
  route options.  Should loose/strict routing verify them and should an
  egress system look for leaks (i.e. bogons, private) being recorded?

4.1.1.2. Problems that arise from the length of the IP Identification
         field

  I'd note that in the networks of today, a dropped frame on the 1 Gb/s
  LAN is going to be very rare.  Later in this section, spoofing is
  mentioned only in the last paragraph, but should probably be
  mentioned at the beginning of the prior one.

4.3. Addressing

  Maybe not appropriate in the end result document, but since you
  mentioned the Spoofer project elsewhere, you might also mention the
  bogon service Team Cymru offers.  At the least, maybe make note that
  static lists of addresses are troublesome since they can and do
  change.

John

---

From: Fernando Gont <[email-masked]>
Date: Mon, 03 May 2010 20:50:49 -0300

Hi, John,

Thanks so much for your feedback!

Meta-comment/question: May I address your comments as part of the
(upcoming) IETF LC, or do you think I should address them before we ship
the document?

Comments in-line....

> Trouble may arise if things get built to this

Actually, I'd argue the opposite. Real-world implementations do not
follow the RFCs, because they are outdated. So everybody has been doing
what they think is "best" to mitigate the security implications of IP.

This documents a lot of what implementers/operators have done, trying to
point out what makes sense, and what doesn't. And tries to provide
advice so that implementations converge to "something".

>   Awkward or redundant wording "to the point that, to some extent,".

Really? (sorry, English as second language here).

>   threats. This document could have been much larger with a different

(Yeah... wait for the v6 version ;-) )

BTW, any text I should add something to address this comment?

>   multicast packets. 

Isn't this already mentioned in the I-D? See the text in Section 3.8:

--- cut here ----
   However, it can also be used to perform important functions such as:

   o  Improving the security of applications that make use of the
      Internet Protocol (IP).

   o  Limiting spread of packets.
---- cut here ----

>   I don't know that this was officially documented

Should I add a small note on this "difficult and complex" thing, and a
pointer to RFC 2365?

>   BCP 84 is the new ingress filtering doc.

Thanks! I will update it.

>   egress system look for leaks (i.e. bogons, private) being recorded?

I'd argue that if they are processed, they should probably verify these
addresses. However, my take is that packets with route options should be
dropped by default. Actually, I'll be adding a note (in response to
feedback received off-list), that some ISP-grade routers simply ignore
IP options.

>   LAN is going to be very rare.  

Where, exactly, should I make this note? (i.e., I miss the context)

>   Later in this section, spoofing is

Suggestions?

>   static lists of addresses are troublesome since they can and do

I can't believe I missed to mention it. :-(  Will fix this, and add a
ref to the Team Cymru site. Thanks for catching this one!

Thanks!

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

---

From: John Kristoff <[email-masked]>
Date: Fri, 7 May 2010 13:45:42 -0500

On Mon, 03 May 2010 20:50:49 -0300
Fernando Gont <[email-masked]> wrote:

> (upcoming) IETF LC, or do you think I should address them before we
> ship the document?

Doesn't matter to me.
 
> This documents a lot of what implementers/operators have done, trying
> to point out what makes sense, and what doesn't. And tries to provide

Which circles back to my overriding comment.  Is this a standards track
document or not?  The assessment is good stuff, but advice is sometimes
ambiguous about what the best approach is.

> Really? (sorry, English as second language here).

Alternative sentence:

   However, the success of the protocols led to their early and lasting
   adoption in production environments, where the world's economy
   now depends on them.
  
> > 2. The Internet Protocol
> > 
> >   Another convenient characteristic is that with reduced complexity
> > and minimum functionality comes, presumably, a limited set of
> > security threats. This document could have been much larger with a
> > different protocol.  :-)
> 

It might be more appropriate for the Introduction, but maybe something
like:

  The limited functionality provided by IP and the flexibility
  available to independent system designers has bred both success
  and trouble.  Success through an efficient and malleable
  infrastructure that has adapted to new innovations.  Trouble from
  a loose set of guidelines on where and how to implement security
  services.

> > 3.8. TTL
> > 
> >   While considered obsolete by the IP multicast operators, specific
> > TTL values (e.g. 1, 16, 32, 64) have been used to control the scope
> > of IP multicast packets. 
> 

Yes, sufficiently so.  Just pointing out that not specifically in the
way IP multicast had historically used the TTL for scoping.

> >   in an RFC and I don't think it was ever officially obsoleted, but
> > it was at least referred to as "difficult" and "complex" in RFC
> > 2365.
> 

I don't think its necessary.  In hindsight I was being pedantic.  :-)

> I'd argue that if they are processed, they should probably verify
> these addresses. However, my take is that packets with route options
> should be dropped by default. Actually, I'll be adding a note (in
> response to feedback received off-list), that some ISP-grade routers
> simply ignore IP options.

Maybe they should be dropped, but if this is an advice document on all
of IPv4, then I would recommend a note about verifying them if they are
enabled.

> > 4.1.1.2. Problems that arise from the length of the IP
> > Identification field
> > 
> >   I'd note that in the networks of today, a dropped frame on the 1
> > Gb/s LAN is going to be very rare.  
> 

Probably nowhere, just a comment.  The whole section just didn't seem
very realistic or practical the way it was written, especially when it
started out by saying how the original specification was built for a
different time. A 1000BASE-T link is specified to have less than one
bit error in every 10 billion transmitted.  From the other perspective,
if someone is causing buffers to overflow such that packets are being
dropped somewhere, that DDoS is likely the bigger problem than fragment
ID collisions.

> >   mentioned at the beginning of the prior one.

Suggested paragraph (added 'source address spoofed' bit):

   An attacker could exploit this fact to intentionally cause a system
   to discard all or part of the fragmented traffic it gets, thus
   performing a Denial-of-Service attack.  Such an attacker would simply
   establish a flow of source address spoofed fragments with different
   IP Identification numbers, to trash all or part of the IP
   Identification space.  As a result, the receiving system would use
   the attacker's fragments for the reassembly of legitimate datagrams,
   leading to corrupted packets which would later (and hopefully) get
   dropped.

John