Re: [Pana] on PANA's requirement to use the unspecified address

> > >    PANA SHOULD not assume that the PaC has acquired an IP address before
> > >    PANA begins.

> It is a "SHOULD" above. Perhaps you are saying that it should be a
  "MAY" ?

What I'd prefer, is that it not be even a MAY. I.e, just drop this
completely. The basic problem here is that we are talking about a
capability that the PANA protocol would need to support, even if it is
only a MAY. It's like being a little pregnant. If there is a need
(however rare in practice) that the unspecified address needs to be
used, the PANA protocol has to include this and implementations will
need to support it. So you have to deal with all the ramifications in
the PANA protocol.

> > a) the address depletion one is significant in the overall scheme  of
> >    things.
> >
> > b) using the unspecified address would not leave the network
> >    vulnerable to other DOS attacks that make solving the previous one
> >    a waste of time. Note: folk might want to look at
> >    draft-ietf-vrrp-spec-v2-09.txt where they _removed_ security
> >    mechanisms after concluding they were useless due to bigger DOS
> >    issues related to IP's reliance on ARP.
> >
> The basic idea is to see whether it is possible to mitigate against
> address depletion attack assuming there are good tradeoffs. I am
> not sure why this DoS attack needs special treatment compared
> to other DoS attacks.

Yep. That is what I'm trying to understand.

> > Second, there are significant stack complications to allowing generic
> > communication with an unspecified address. Things to consider:
> >
> > - IP fragmentation doesn't work reliably anymore (a recieving machine
> >   might think two fragments that are actually from two different
> >   machines are from the same machine, and reassemble them improperly).
> >
> Agreed. Some stacks maintain the reassembly queue per interface which solves
> problem with link-local addresses in general. But for unspecified address,
> unless mac addresses are used (which may not be reasonable), the problem
> will exist.

It is not reasonable, IMO, because this is a change to the IP stack
itself. Not in the scope of PANA to require.

Thomas

_______________________________________________
Pana mailing list
Pana@ietf.org
https://www1.ietf.org/mailman/listinfo/pana