Sriram,
regarding the implementer input, here are my thoughts:
To comment 1:
==============
It is not uncommon to have a length field not include its own size. An example
is the length field of the capabilities which does specify the length (size) of
the
following capability (payload). In our case the length field specifies the
length (size)
of the signature itself (payload) and not the total length of all the signature
fields (ski, length, signature) as do the other length fields.
In addition, adding the 2 bytes for the field itself, will add more complexity
to the
processing regarding the crypto. Currently we can use the value “as is” without
any
additional math applying to it which will change once we include the 2 bytes
for the field itself.
So, I prefer to keep it as is.
To comment 2:
==============
I do not believe that by sending 2 separate capabilities we really “waste”
anything. The reason
is that compared to the overall BGP traffic, a handful of bytes exchanged
during the session
establishment doesn’t do any harm.
But on a more serious note, introducing a 2-bit encoding adds additional
complexity. The proposed
encoding 01 – 10 – 11 (or 1, 2, 3) is fine except that it leaves out two
additional stages.
(A) the encoding 00 and
(B) no capability sent at all.
Looking at other capabilities, the “non-existence” of a capability states no
support. Now by adding
an unused 00, what does this mean? Does it mean we don’t support the capability
which means we have
two forms of signaling no support? And if it does not mean that, is it an error
in which we need to add
error handling.
I think this adds unnecessary complexity that the implementer must check for 00
and the non-existence
and deal with them the same way or differently?
To keep it simple, I prefer to keep it as it is, this way we do not add
additional confusion:
(I) Announce the proper capability if supported
(II) and if not supported don’t announce the capability.
This is straight forward and falls in line with other capabilities. (As Example
MPNLRI, 4 Byte ASN, etc.)
Thanks,
Oliver
From: Kotikalapudi Sriram <kotikalapudi.sri...@nist.gov>
Date: Thursday, December 22, 2016 at 12:41 PM
To: sidr list <sidr@ietf.org>
Cc: Russ Housley <hous...@vigilsec.com>, "ba...@tislabs.com"
<ba...@tislabs.com>, Oliver Borchert <oliver.borch...@nist.gov>,
"sidr-cha...@ietf.org" <sidr-cha...@ietf.org>
Subject: Implementer inputs requested (Fw: SecDir Review of
draft-ietf-sidr-bgpsec-protocol-20)
Russ Housley had suggested these changes (#1 and #2 below) as part of his
SecDir review.
But he also suggested to me to put it out on the mailing list so that
implementers in particular and anyone having an opinion can have a say.
Russ's comment:
Minor:
#1
In Section 3.2, the Signature Length within the Signature Segment does
not count the length field itself. It seems that all of the other
length values in this specification count the size of the length too.
Consistency will avoid implementation errors.
Russ's comment:
Minor:
#2
Section 2.1 says:
... The BGP speaker
sets this bit to 0 to indicate the capability to receive BGPsec
update messages. The BGP speaker sets this bit to 1 to indicate the
capability to send BGPsec update messages.
It seems a bit wasteful to repeat the whole capability for each
direction. Wouldn't it be better to follow the example used in
other capability definitions (such as RFC 7911) by using one of the
unassigned bits? The Send/Receive pair of bits would have these
semantics:
This field indicates whether the sender is (a) able to receive
BGPsec update messages from its peer (value 1), (b) able to send
BGPsec update messages to its peer (value 2), or (c) both (value 3)
for the address family identified in the AFI.
[Sriram] Observation: Two implementations exist and
they were shown to interoperate at the IETF-97 in Seoul.
The changes would cause those implementations to make code modifications.
Sriram
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
