Subject: [Isis-wg] Meeting minutes ...

From: Tony Przygienda <[email-masked]>
Date: Thu, 23 Aug 2001 12:16:45 -0700

For London from my sketchy notes since I didn't get the notes that Alex
was taking yet

. Administrativa
    . isis-transient has been updated and called again, should go to
RFC now
    . isis-3way passed last call, will need addition of TLV codepoint
consideration for RFC
    . isis-snp-checksum same, TLV assignment conflict has been resolved
    . isis-ipv6 same
    . large ether frames in editing, under discussion

. Presentations
    . m-isis: Mike had some questions on flooding optimizations
mentioned, the discussion
        that came out of it basically lead to agreement that it's mostly
a dangerous idea not
        worth pursuiting and due to the lack of specifics in the draft
lacked in quality.
        IPv6 has been mentioned and authors answered that the problem is
being ignored at
        the moment due to the lack of requirements from the ISP side.

    . hermelin-ext-lsp-frags: Mike & Stefano thought that it would make
more sense
        to have a method to issue LSPs > 255 under different system
ID and tie those
        together using some proxy TLV with the original node, concern
with presented
        proposal was that without SPF changes it only presents a
restricted functionality
        (leaf-node).

        Motion to make it workgroup document. Agreement was that within
8 weeks
        Stefano & Mike submit an alternative draft and things will be
discussed further
        or merged or otherwise hermelin draft becomes a WG item.

    . ietf-isis-transient: Danny did not show up to present

    .  shand-isis-restart: After presentation a discussion started WHY
it should be done at
        all and enough reasons have been found to make it a wg item
(backups, software
        upgrades)

    . ietf-ospf-p2p: Dino brought up some simplifying ideas on the
ISIS side that have
        been considered but would make layer violations worse (taking
MAC directly from
        hellos). Request to make it working group document has been
delayed and should
        be posted by the authors to the mailing list for a wider
discussion.

    . auth-anti-replay: Request has been made to make it a workgroup
document. No
        comment from the room due to the early morning hour and jetlag
probably.
        Tony came up to the mike and brought up several reasons why it
does not make
        sense to accept the draft as it is. Either ISPs with burning
desire for that partial
        solutions should be vocal or we should spend serious time on a
clean security
        solution for ISIS that would encompass proper nonce negotiation
for replay
        protection, source authentication and other
best-known-practices. Up to Alex to see
        whether he wants to pursuit either path.

    . tlv-codepoints: All drafts taking new TLV values should please
refer to that draft

    -- tony

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 23 Aug 2001 13:05:46 -0700

>>         been considered but would make layer violations worse (taking

    This layer violation is already in IS-IS when processing LAN IIH's.

Dino

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 23 Aug 2001 13:52:46 -0700

>     This layer violation is already in IS-IS when processing LAN IIH's.

layer violation meaning that ISIS would probably take to ARP tables to
teach them
the MAC address of the neighbor if such a scheme is employed (and proxy
ARP's not being
run) ... That is more than the usual MAC-on-hellos layer violation ;-)

    -- tony

---

From: Vijay Gill <[email-masked]>
Date: 23 Aug 2001 21:14:13 +0000

>  > it should be done at> all and enough reasons have been found to
>  make it a wg item  (backups, software upgrades)

I would strongly suggest checking the archives of the OSPF wg mailing
list (http://discuss.microsoft.com/archives/ospf.html) as there has
been significant discussion on a somewhat similar topic.

>     document. No comment from the room due to the early morning hour
>     and jetlag probably.  Tony came up to the mike and brought up
>     several reasons why it does not make sense to accept the draft
>     as it is. Either ISPs with burning desire for that partial
>     clean security solution for ISIS that would encompass proper
>     nonce negotiation for replay protection, source authentication
>     and other best-known-practices. Up to Alex to see whether he
>     wants to pursuit either path.

In general, the entire aspect of control plane security in IP networks
has been of secondary importance (maybe because it is hard to get the
control plane working to our satisfaction. The codebase probably
comprises as good an attack on our infrastructure as anything the
black hats could come up with).  That being said, it is probably of
use to pursue _a_ solution, and a solution that gets us most of the
way there and is codeable and deployable is of more use than the all
singing, all dancing undeployable solution which introduces
significant amounts of codebase upheaval.

/vijay

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 23 Aug 2001 14:16:45 -0700

>> run) ... That is more than the usual MAC-on-hellos layer violation ;-)

    IS-IS deals with layer-2 addresses. If the implementation chooses to add
    ARP entries, it is a local matter. Just like Russ said.

    A traditional "layer violation" means a layer-n protocol looks at a 
    layer-(n-1) protocol's header.

Dino

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 23 Aug 2001 14:01:15 -0700

>     layer-(n-1) protocol's header.

ok, let's call it 'protocol-crosstalk' ;-) then ...

    -- tony

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 23 Aug 2001 18:59:58 -0400

>significant amounts of codebase upheaval.

Vijay,
        My apologies for my being dim-witted.  I'm having trouble 
interpreting your remarks above:  

        Are you saying you'd be happy with just documenting the 
already widely deployed (but not yet RFC) IS-IS HMAC-MD5 approach 
in the current tli draft as an RFC ?

XOR 
        Are you saying that you want to forget the installed base,
open the hood, tinker, and do something else ?

Thanks,

Ran
[email-masked]

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 23 Aug 2001 16:25:26 -0700

> been significant discussion on a somewhat similar topic.

aware of that, was not hurting repeating the arguments since some of the
crowd
does not overlap between ISIS and OSPF ;-)

> significant amounts of codebase upheaval.

Vijay, nice tirade but pls read Alex's draft and tell me whehter you
desperately need his-flavor-of-partial-replay-protection today.
If you do, we make the draft working group item and we'll make sure that you
deployed it  after the
vendors rolled it. If you (as placeholder for any major ISP) don't need it
desperately today, it is not worth doing and we should
concentrate on a proper framework  (if we want to do it at all) that won't
be openly picked apart at the mike
by some security wizard 6 months from now. I saw couple of chairs standing
with their pants down in such a
situation and it is mucho embarassing. The only excuses are 'it was
desperately needed to be deployed
then so little hacky was fine' (case HMAC today) or 'we did thorough work
and took into account
all the then-known security paranoia'. Anything else does not stand the test
of time and based on
 that observations I was trying to steer the work ...

    -- tony

---

From: Vijay Gill <[email-masked]>
Date: 24 Aug 2001 01:58:38 +0000

> aware of that, was not hurting repeating the arguments since some of
> the crowd does not overlap between ISIS and OSPF ;-)

Just thought I'd err on the side of caution. The OSPF discussions
were not pretty at all.

> desperately need his-flavor-of-partial-replay-protection today.

Thanks to Ran ([email-masked]) for clearing up some errors.  The HMAC
solution as proposed by tli appears to be sufficient for now. 

> vendors rolled it. If you (as placeholder for any major ISP) don't
> need it desperately today, it is not worth doing and we should
> concentrate on a proper framework (if we want to do it at all) that
> won't be openly picked apart at the mike by some security wizard 6
> months from now. I saw couple of chairs standing with their pants

A secure solution is needed, I am not sure if the costs of imposing
a very complete, unbreakable solution are worth the return given
_current_ and past performance [ insert past performance
is not a guarantee of future result boilerplate here ]

> excuses are 'it was desperately needed to be deployed then so little
> hacky was fine' (case HMAC today) or 'we did thorough work and took
> into account all the then-known security paranoia'. Anything else
> does not stand the test of time and based on that observations I was
> trying to steer the work ...

I'm basing this on a mandate after an incident some time ago.  Senior
mangement said 'you will run authentication on all routing protocols
or you will find another job'

Others mileage may and probably should, vary.

/vijay

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 23 Aug 2001 23:35:37 -0700

> Just thought I'd err on the side of caution. The OSPF discussions

ok ...

> solution as proposed by tli appears to be sufficient for now.

we're in sync then ...

> is not a guarantee of future result boilerplate here ]

neither am I, I was only saying if somebody has cycles to put into that,
he rather do a good job rather than come up with a hacky solution for
a problem that the ISPs don't have and not solving a problem they may
or will have properly either ...

> or you will find another job'

<irony>
of course we know that most of senior managers that cluefull and determined

tend to find or being found new jobs way before us techies do ;-)
</irony>

    Points taken

    -- tony

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 24 Aug 2001 09:36:14 -0400

>or will have properly either ...

Tony,

        My own sense is that the next useful increase in attacker work 
function (beyond the tli HMAC draft) is probably to go to full Digital 
Signatures (along the lines of RFC-2154).  

        I am only aware of one implementation of RFC-2154 (done by 
its authors) and zero deployments of RFC-2154.  I interpret that 
state of implementation and deployment as indicating that:

        "most of the community doesn't think the current threats 
        justify that level of security complexity and adverse 
        performance impact today"

Regards,

Ran
[email-masked]

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 24 Aug 2001 13:01:02 -0700

>         performance impact today"

agreed, once at it and since as you say things would not be pressing
timewise,
time could be spend on nonce-negotiation on hellos and possibly
key, encryption negotiation so all exchanges between 2 peers could not
only be secure but also private. Combined with a method to propagate
with an LSP the information whether it was only flooded across
encrypted and negotiated links, we could claim all best practical
security known to at least me incl. privacy. I have nothing against such far
forward-looking
work, especially if each of those pieces is standardized as optional. Time
may
come when we need it.

Again, I completely agree that practical deployment of security has far
lagged the lip-service being paid to it and therefore the work only makes
sense if someone really wants to spend cycles to do it right and is willing
to wait
long-time for deployment. That is to be attributed probably
to the cynical truth that security  is not an inherent need mostly, it's
rather an acquired taste like horror movies ;-)

    thanks

    -- tony

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 24 Aug 2001 16:56:53 -0400

At 16:01 24/08/01, Tony Przygienda wrote:
>...since as you say things would not be pressing timewise,
>security known to at least me incl. privacy. I have nothing against 
>such far forward-looking work, especially if each of those pieces 
>is standardized as optional. Time may come when we need it.

        One approach worth examining if confidentiality were an 
objective would be implementation/deployment of the IEEE 802.10 
security specification.  It has not been widely implemented or 
deployed, as far as I know, but some good folks did work on that 
spec.  I do not have a copy, so don't know precisely what is 
in the 802.10 specification.

Ran