RE: IPv6 Security Overview

["Vishwas Manral" <Vishwas@sinett.com>]

Hi Francis,

=> I am sorry to have to say that but I don't believe we should change
protocols to make the life of middleboxes better, i.e., middleboxes
have to adapt, not the opposite. And here I say middleboxes because
fragments are transparent for routers (i.e., a lot of fragments or
a lot of packets are the same thing for a router).

Routers also do basic load balancing (ECMP) based on deeper packet
inspection, this is where things can be affected (ACL's etc). I agree to
what you say above. However I think we are doing a security analysis of
the protocol and hence noting down the possible places where we can have
issues.

The draft also talks about issues with overusing "Router Alert option"
or having excessive "hop-by-hop" options; it does not however mean we
are removing the options totally or putting a limit on it (Seemed to me
that way from the spirit of the draft, the authors could probably
clarify).

Thanks,
Vishwas
-----Original Message-----
From: Francis.Dupont@point6.net [mailto:Francis.Dupont@point6.net] 
Sent: Friday, January 06, 2006 4:02 AM
To: Vishwas Manral
Cc: v6ops@ops.ietf.org
Subject: Re: IPv6 Security Overview 

    In your previous mail you wrote:
   
   => I don't think it matters.
   VM> I agree the TTL/ Hop Limit changes etc. However by keeping
address
   alternating i.e. Address [2x] = A, Address [2x+1] = B for x = 1 to n,
we
   make a packet transit the same router n times, thus increasing the
load
   on a router. It is a simple amplification attack.
   
=> it is a low order attack against an intermediate slow link when
the real issue is bad security policies (bad = not prepared to see
packets following strange routes).

   => as AH is no more used this is an academic discussion. I do not
think
   so.
   VM> I agree AH has been downgraded to a MAY in RFC4301. However one
   point I can think of is that AH is more amenable to middleboxes than
ESP
   authentication only service. I am not sure if we can say AH is no
more

=> just ask IPsec people.

   used, we just had an RFC4302 for the same. I also think that AH
should
   take care that Flow Label, however that is an IPsec(and backward
   compatibility) discussion.
   
=> it was an IPsec discussion and backward compatibility won.

      10. One more thing about Padding option is that we should have
only
   one padding option, either 1 instance of PadN or one of Pad1.
   => this is not so clear: PadN can be a nice hidden channel.
   VM> We should not allow multiple Pad1 or PadN options. Is there
   something I am missing?
   
=> yes, people want to be free to use Pad1 and PadN as they believe it
is the best. BTW adding a constraint here shall kill compatibility.

   => do you mean we should forbid fragments for any transport which has
   its own segmentation (i.e., not UDP)?
   VM> We are talking about security issues. I am just listing that
having
   too many fragments can cause state exhaustion in middleboxes as well
as
   other routers which send fragments to slow path along the way. We are
   not giving a solution here in my view.
   
=> I am sorry to have to say that but I don't believe we should change
protocols to make the life of middleboxes better, i.e., middleboxes
have to adapt, not the opposite. And here I say middleboxes because
fragments are transparent for routers (i.e., a lot of fragments or
a lot of packets are the same thing for a router).

Regards
   
Francis.Dupont@point6.net